 |
Is this something related to a specific game? Can an idTech engine handle such high values properly? If yes, I'd be inclined to make the maximum configurable through the settings in the .game file. |
 |
With Quake IV, Radiant complains about the subdivisions exceeding 32, but (anyway) will actually display, save, and "dmap" successfully, and the patches do show up in the game properly. It's sluggish, but using DR with other newer engines using LOD, numbers like 32 quickly become trivial. |
|
|
Please see here for evidence:- https://www.violae.net/temp/Q4patchtess64.jpg |
|
|
Ok, I'd go for making this limit a configurable value in the .game file and set the Q4 game to, I don't know, 128 maybe? Would this be ok for your needs? (Not sure if such high subdivision values make any difference in the game visually, can it get any smoother?) |
|
|
No offense, but, every generation says this... The answer is yes, it definitely can. Imagine if this were a giant silo. Quake IV itself probably won't ever need more than 32, but our game project already needs it, because of heavy use of vertex-buffer LOD. DarkRadiant is the only (idTech4) Radiant that currently forces these tessellations to 32, even if the patchDef3 has a higher value. |
|
|
The upper limit in the code has been removed now. The UI will restrict this to 16384 subdivisions for X and Y, respectively. (Setting this to 2048x2048 on a cylinder sent DR into a hang on my end. When lowered to 1024 it was rendering in DR, but TDM crashed on dmapping.) |
- Anonymous
