Horde3D

Next-Generation Graphics Engine
It is currently 19.03.2024, 12:07

All times are UTC + 1 hour




Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: 15.05.2011, 15:56 
Offline

Joined: 09.05.2007, 23:57
Posts: 6
Location: Philadelphia, PA
It'd be nice to be able to attach user data (void *) to scene nodes, so I don't have to maintain a separate hashtable indexing game entities by H3DNode.


Top
 Profile  
Reply with quote  
PostPosted: 19.05.2011, 21:04 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
I assume you have some entity class which stores all your game-specific data. Can't you just store the horde scene node handle there? This is a much cleaner design than trying to store game specific data in or with the rendering subsystem.


Top
 Profile  
Reply with quote  
PostPosted: 19.05.2011, 22:47 
Offline

Joined: 09.05.2007, 23:57
Posts: 6
Location: Philadelphia, PA
I've got the node stored in my entity, yes. But when using h3dCastRay or h3dutPickNode, I only get an H3DNode back. So I can either search my entities for correct one, or maintain a separate map. It would be much more efficient to be able to maintain a reference back to my entity, at the cost of 1 pointer per node.

I was thinking something like H3DNodeParams::UserData along with h3dGetNodeParamPtr/h3dSetNodeParamPtr. It's a pretty common pattern, used by ODE Physics, for example.

It's not a big deal, but since it is something of an API change, I thought it might be worth dropping in before 1.0 is released.


Top
 Profile  
Reply with quote  
PostPosted: 20.05.2011, 23:38 
Offline

Joined: 11.09.2010, 20:21
Posts: 44
Location: Germany
Although I can understand marciano's arguments, I also think a simple pointer attribute could be quite useful.


Top
 Profile  
Reply with quote  
PostPosted: 23.05.2011, 01:22 
Offline

Joined: 08.11.2006, 03:10
Posts: 384
Location: Australia
Yeah I agree with marciano's point that the renderer shouldn't need to be able to point back up to the high-level game systems...

...however, if the high-level game code is going to make use of h3dCastRay then it probably needs a way to determine which game-object the returned node belongs to - a user-data pointer is a good candidate to solve this problem.


I'm also of the opinion that h3dCastRay doesn't actually belong in a rendering API :P but it is so useful to a lot of people that it would be a shame to remove it now ;)


Top
 Profile  
Reply with quote  
PostPosted: 23.05.2011, 07:59 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
I understand that there is the need to map back h3d handles to game objects in the described case but I'm not convinced that this mapping should be stored on the h3d side.

If you use a lookup table (not a hashmap or map), you also get a quick and direct mapping from handle to game object, without any additional performance cost over a h3d private-data function. In theory it would even be faster because your lookup table would be more memory coherent and hence cache friendly compared to storing the pointers directly in the h3d scene node objects and you also have less indirections to get it.

DarkAngel wrote:
I'm also of the opinion that h3dCastRay doesn't actually belong in a rendering API but it is so useful to a lot of people that it would be a shame to remove it now

I agree on both points. Maybe it can be moved to the utils lib at some point.


Top
 Profile  
Reply with quote  
PostPosted: 23.05.2011, 18:46 
Offline

Joined: 09.05.2007, 23:57
Posts: 6
Location: Philadelphia, PA
DarkAngel wrote:
Yeah I agree with marciano's point that the renderer shouldn't need to be able to point back up to the high-level game systems...


A renderer shouldn't, but a scene graph should. I'm all for the scene graph being moved out of the main renderer, but that's a big project.

marciano wrote:
If you use a lookup table (not a hashmap or map), you also get a quick and direct mapping from handle to game object, without any additional performance cost over a h3d private-data function. In theory it would even be faster because your lookup table would be more memory coherent and hence cache friendly compared to storing the pointers directly in the h3d scene node objects and you also have less indirections to get it.


Ok, that's what I'll do. I was viewing the fact that H3DNodes are sequential as more of an implementation detail.


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

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 6 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