dmap and LOD implementation

[HMart]

Ok, apparently there is some tricky hardcoded total polycount limit in BFG engine. Instead of going all crazy with 13M tris, I reduced polycount per entity (highest LOD iteration) to ~2900 (since it's just suppose to be rocks and foliage) and now I have no issues. Having LOD is still twice faster than bruteforce rendering, so I assume engine still batches surfaces in runtime based on matching materials.

 

The sad truth that idTech 4 / BFG is definitely not an outdoor engines. I tested my massive outdoor map with LOD entities and issue with corrupted surfaces popped up again. Maybe splitting terrain into smaller enclosed sections, connected with tunnels and having vizportals should do the trick.

 

Did Splash Damage made big modifications to idtech4 for Quake Wars? Afaik they and John Carmack only updated the Mega Textures tech? About your engine it is known that floating point problems come if very far from the origin in big maps, perhaps is that? If you haven't already you can try moving the world origin to the player origin dynamically? Yes cutting the terrain in small and manageable pieces does help performance.

[New Horizon]

They did a bunch of other enhancements in terms of the mapping tools. They had a bunch of different portals mappers could use. Audio portals were separate from vis-portals for example.

 

http://wiki.splashdamage.com/index.php/Portal_Basics

[motorsep]

Did Splash Damage made big modifications to idtech4 for Quake Wars? Afaik they and John Carmack only updated the Mega Textures tech? About your engine it is known that floating point problems come if very far from the origin in big maps, perhaps is that? If you haven't already you can try moving the world origin to the player origin dynamically? Yes cutting the terrain in small and manageable pieces does help performance.

 

ETQW engine was a significant step ahead of idTech 4 in Doom 3. That's why I was in line to be released next as GPL. Maps are still not big there. Even RAGE had maps which had walkable surface withing +/-32k (or that's what I was told by ID). Moving world's origin at player's coordinate won't fix any issues. Player needs to be always at 0 0 0 and the world needs to "scroll" under. Or the world needs double float, which is not trivial to implement in idTech 4, and not only because everything uses common matrices (rendering and physics and coordinate system do at least).

 

Anyhow, rendering was improved, megatextures were improved, networking, multithreading got better, AAS was reworked, etc.

Edited December 2, 2014 by motorsep

[motorsep]

Well, I already tried it:

 

http://forums.thedar...post__p__243243

 

 

The models are cloned dynamically, then combined into larger models automatically. On LOD changes, the model is recompiled.

 

You (or someone else?) said SEED is _slow_ Did you implement actual instancing to clone models?

 

Supposedly RAGE does it the same way, but on a separate thread. The issue that I have with this is that the engine culls on per surface basis. So if you have one massive surface and part of it is in the view - it won't be culled. So it will be drawn even if you don't see most of it. That's why I question the need to merge surfaces into one. My test case with ~13M tris shows that LOD is twice as fast than no LOD. And I am not doing any merging. It would be nice to investigate what's really happening with culling and batching in idTech 4 :/