Horde3D

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.

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.

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.

Although I can understand marciano's arguments, I also think a simple pointer attribute could be quite useful.

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 but it is so useful to a lot of people that it would be a shame to remove it now

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.


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

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.



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