Horde3D

Due to our ongoing optimization efforts, we have completely replaced the current (quite primitive) LOD system which was based on a minimum and maximum activation distance for Group nodes. This change was necessary for the upcoming scene processing optimizations and the refactoring to use a spatial graph. But I think the new system is also much more useful. I hope nobody is using or requiring the Group node LOD system since it won't work any more.

In the new system Mesh nodes have an LOD level and are only rendered when that level corresponds to the level calculated for the model (Model nodes have distances describing when the LOD level should be switched). To make that useful, we extended ColladaConv to support LOD. All LOD meshes are defined in a single asset. We have a special naming convention (postfixes _lod1 to _lod4 for mesh names) which ColladaConv translates to the LOD level.

To test the new system we created three LODs for the Chicago character with an automatic mesh simplification tool. The results are very satisfying: The framerate of the Chicago demo got a huge boost, especially when viewed from some distance. And there is hardly any popping noticable, although we did not spend much time on tweaking the distance values. Try it out yourself and tell us what performance gains you are getting

EDIT:
A few more reasons why the new system is more practical:
Before you had to attach three models to three group nodes with special distance settings to get a base model with two LODs. One problem here was animation handling: You had to animate all three LOD models independently. Even worse, IK which requires manual joint updates. For that you had to track all the LODs in your application to make sure they got synchronized. The LOD models were not connected in any way and skeleton sharing was not possible. Now, with the new system, you just need one model and the LOD handling is done on the mesh level in a much more transparent way. The skeleton is shared. It would also be possible to implement some skeletal LOD by giving a maximum LOD level to joints but this is left for the (far) future.

Viva new LOD system

Sounds like a very nice change! I look forward to messing around with it.

_________________
Tristam MacDonald - [swiftcoding]

The code is already in the SF svn...

Ja, but I don't have a computer capable of running Horde until I build my new desktop in a couple of weeks :p

_________________
Tristam MacDonald - [swiftcoding]

Sounds excellent, perhaps a LOD fade to stop the popping ? Im not sure, I found the group LOD fairly useful for large chunks of objects in close proximity, for example room content.

In regards to the assets, if I understand correctly all of the LODS have to be contained within one DAE file for the Converter to process?

_________________

Let's bring 'em out! Any old iron! Any old iron!
A door opens and a homewife brings out a rather sophisticated-looking ground-to-air missile system, and dumps it on the cart.
Thank you.

I think that can be solved with the upcoming Multibounds


I think that's right, although I didn't looked into the new system too much.

Is anyone in a position to elaborate on this a little more? I am planning to convert my planet oon to a system where each patch is it's own node, and it would be very beneficial to partition these hierarchically into sectors (including a root 'planet' node). I assume that multibounds will not be hard to add into the hierarchy once they are implemented?

As I see it now, utScene only calls calcLodLevel for ModelNodes. Can we have calcLodLevel be a virtual method of SceneNode, so that the Lod system in extension nodes is standardized?

_________________
Tristam MacDonald - [swiftcoding]

Multibounds (not a very common term but used here) are just a very lighweight version of a sector-portal system. Actually multibounds are just primitive spatial groups without connectivity info (e.g. portals) but they could be used in combination with hardware occlusion culling.


Yes, this should be possible to do.

I'm not entirely sure what the plan for the new lod system is but I always thought it would fit the style of horde3d to have a customizable lod setting much like the pipeline. This would allow to define not only geometry but render state for various levels based on a lod value. This way, it would be possible to have rules like "render trees as billboards when farther away than 300 m" or "disable transparency and bump mapping for objects that are far away". Additionally, it would be cool to be able to define other properties like shadow, or animation update frequency. What would be really cool is to have a dynamic lod system that would adjust the lod value used based on the current framerate. That way things would look great when the scene is simple but wouldn't bring the computer to its knees if the scene was complex.

The ability to change materials with LODs is pretty much a must - particularly for expensive effects such as steep parallax mapping, which need to fall back to normal mapping in the distance.

That is some pretty complex functionality there, and perhaps better suited to the application layer (the application typically load balances between rendering, physics, AI, etc.)

_________________
Tristam MacDonald - [swiftcoding]

The application can already control animation update frequency AFAIK. All that would be needed to tie this in to the new LOD system is for the application to be able to query the LOD level of a particular node for a given camera.

Shadows that use an infrequently-updated texture might be useful in some circumstances, but aren't supported... This could probably be implemented by allowing light nodes to choose whether they will store their own shadow-map, or if they will use the temporary (shared) shadow-map. The light node would also require a flag, which would indicate whether the shadow-map will be updated next frame, or whether the existing data will be re-used.

The light node could even use a texture-resource as a shadow-map...

Hypothetically, could these shadow-maps then be exported from/imported into Horde, allowing shadow-maps of static geometry to be precomputed? If so, it might be a useful feature for scenes with many large environmental lights.

I don't really see any technical barrier, but this is well outside the scope of Horde - perhaps better left to a dedicated solution, such as Giles (which supports radiosity, etc.)

_________________
Tristam MacDonald - [swiftcoding]

This is already possible. You can give an LOD mesh a different material which uses a cheaper shader combination.


We have a relatively new function checkNodeVisibility which can also calculate the current LOD. So controlling animation based on visbility or LOD is already possible.


That's a good idea, would be easy to realize and makes things more flexible for certain situations.

Giles looks a lot more advanced than what I was thinking about. I was really only asking about uploading texture data between the application and Horde (which is already supported), but for depth-textures.