Horde3D

Next-Generation Graphics Engine
It is currently 28.03.2024, 09:57

All times are UTC + 1 hour




Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: New LOD system
PostPosted: 24.01.2009, 04:01 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: New LOD system
PostPosted: 24.01.2009, 04:49 
Offline

Joined: 21.08.2008, 11:44
Posts: 354
Viva new LOD system :D


Top
 Profile  
Reply with quote  
 Post subject: Re: New LOD system
PostPosted: 24.01.2009, 14:13 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
Sounds like a very nice change! I look forward to messing around with it.

_________________
Tristam MacDonald - [swiftcoding]


Top
 Profile  
Reply with quote  
 Post subject: Re: New LOD system
PostPosted: 24.01.2009, 14:43 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
swiftcoder wrote:
Sounds like a very nice change! I look forward to messing around with it.

The code is already in the SF svn...


Top
 Profile  
Reply with quote  
 Post subject: Re: New LOD system
PostPosted: 24.01.2009, 17:12 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
marciano wrote:
swiftcoder wrote:
Sounds like a very nice change! I look forward to messing around with it.
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]


Top
 Profile  
Reply with quote  
 Post subject: Re: New LOD system
PostPosted: 25.01.2009, 10:24 
Offline

Joined: 11.06.2008, 10:34
Posts: 119
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: New LOD system
PostPosted: 25.01.2009, 10:37 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
Pug wrote:
Im not sure, I found the group LOD fairly useful for large chunks of objects in close proximity, for example room content.

I think that can be solved with the upcoming Multibounds

Pug wrote:
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?

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


Top
 Profile  
Reply with quote  
 Post subject: Re: New LOD system
PostPosted: 02.02.2009, 02:25 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
Volker wrote:
Pug wrote:
Im not sure, I found the group LOD fairly useful for large chunks of objects in close proximity, for example room content.
I think that can be solved with the upcoming Multibounds
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]


Top
 Profile  
Reply with quote  
 Post subject: Re: New LOD system
PostPosted: 03.02.2009, 09:19 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
swiftcoder wrote:
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?

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.

swiftcoder wrote:
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?

Yes, this should be possible to do.


Top
 Profile  
Reply with quote  
 Post subject: Re: New LOD system
PostPosted: 18.02.2009, 05:35 
Offline

Joined: 02.12.2008, 21:25
Posts: 8
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: New LOD system
PostPosted: 18.02.2009, 13:15 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
philippec wrote:
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".
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.

Quote:
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.
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.) :smile:

_________________
Tristam MacDonald - [swiftcoding]


Top
 Profile  
Reply with quote  
 Post subject: Re: New LOD system
PostPosted: 18.02.2009, 13:52 
Offline

Joined: 08.11.2006, 03:10
Posts: 384
Location: Australia
philippec wrote:
Additionally, it would be cool to be able to define other properties like shadow, or animation update frequency.
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: New LOD system
PostPosted: 18.02.2009, 14:12 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
DarkAngel wrote:
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]


Top
 Profile  
Reply with quote  
 Post subject: Re: New LOD system
PostPosted: 18.02.2009, 20:23 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
swiftcoder wrote:
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.

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

DarkAngel wrote:
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.

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.

DarkAngel wrote:
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.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: New LOD system
PostPosted: 19.02.2009, 01:48 
Offline

Joined: 08.11.2006, 03:10
Posts: 384
Location: Australia
swiftcoder wrote:
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.)
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 38 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group