Horde3D

Next-Generation Graphics Engine
It is currently 25.06.2018, 13:09

All times are UTC + 1 hour




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: Model Resources
PostPosted: 09.05.2009, 19:15 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
In the current system models with their joints and meshes are represented as scene graph branches. This is a quite elegant and flexible design since the joints and meshes are not a special case on client side and they can easily be controlled with the common scene graph API. But this elegance and flexibility comes at a relatively high performance price.

Since every joint is a scene node, you can easily get huge scene graphs, especially when rendering many characters. The problem is that scene nodes have no memory locality which results in a lot of cache misses (cache misses are one of the worst performance penalties on modern platforms). All joint updates need to take the generice scene node update path which means recursive calls and invocation of virtual functions. Another serious issue are the dirty flags required for the lazy update mechanism: profiling has shown that a lot of time is spent just for marking all the nodes dirty.

It is not that the current system is unacceptably slow: in fact we can animate several hundred characters. But it is far from the optimum. Since Horde is supposed to be suitable for crowd simluation, it is quite clear that we should try to get the best performance for that. Another point is that Volker plans to port Horde to mobile devices. Their processors are less forgiving than desktop CPUs that are out-of-order CPUs and optimized to hide the latency of cache misses. So I think it is quite clear that we need to do some refactoring.

The idea is to introduce model resources. Model scene nodes will still exist but they just reference a Model resource instead of having child nodes for their data. Since the model resources will solely contain meshes and joints, it is a lot easier to optimize them. I assume that we will be able to get a much better data locaility and less function calls. We will need some more special API functions to control the models (manually setting joint transformations etc.) and lose some flexibility (you can't just add meshes and joints as you could with the scene graph approach) but in the end I don't see a serious disadvantage for practical usage.

Another related change is that the scene graph resources should be moved from the core to the utility library since they will no longer be required for loading models. A scene (level/map/world) definition is something that is quite application specific and usually includes more than graphics data (entities, gameplay data), so it does not make much sense to have a "sample implementation" in the engine core.


Top
 Profile  
Reply with quote  
 Post subject: Re: Model Resources
PostPosted: 10.05.2009, 01:31 
Offline

Joined: 08.11.2006, 03:10
Posts: 384
Location: Australia
I don't disagree with your new approach (it makes sense), but as an alternative you could think about optimising the locality of joint nodes by manually placing their memory inside their parent model node.
Code:
   ModelNode* parent = new ModelNode( ... );
   JointNode* j = new (*parent) ModelNode( ... );

   class JointNode
   {
   public:
      void* operator new   ( size_t, ModelNode& );
      void  operator delete( void*,  ModelNode& );
      void  operator delete( void*,  size_t );
   };
   void* JointNode::operator new( size_t size, ModelNode& n )
   {
      NiceLinearHeap& heap = n.GetHeap();
      return heap.Alloc( size );
   }


Top
 Profile  
Reply with quote  
 Post subject: Re: Model Resources
PostPosted: 11.05.2009, 20:00 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
I don't think that the current flexibility of joint hierarchy is really needed. Even the modification and reconfiguration of joint hierarchy is a seldom used feature I think. I couldn't think of a situation where non-joint "real inner" nodes are needed. The only thing that could be needed is to attach a node to a joint, like in the knight example.

AFAIK the current collada converter writes model data only, so real scene resources could be only created with hand or a custom editor.

Quote:
A scene (level/map/world) definition is something that is quite application specific and usually includes more than graphics data (entities, gameplay data), so it does not make much sense to have a "sample implementation" in the engine core.

I agree with this, too. While I quite like your editor, we chose to create a game entity centric level editor.


Top
 Profile  
Reply with quote  
 Post subject: Re: Model Resources
PostPosted: 12.05.2009, 21:06 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
DarkAngel wrote:
I don't disagree with your new approach (it makes sense), but as an alternative you could think about optimising the locality of joint nodes by manually placing their memory inside their parent model node.

Thanks, that is a good idea. I guess we would find even more tricks but I'm quite sure they will never make things as fast as with the model resource.

attila wrote:
The only thing that could be needed is to attach a node to a joint, like in the knight example.

This would still be possible. You can attach the object to the model node where the attach function would get an additional subobject parameter.


Top
 Profile  
Reply with quote  
 Post subject: Re: Model Resources
PostPosted: 08.09.2011, 21:04 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
Any progress on this? I'm really looking forward this change.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


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