Feature request: void ISceneNode::setData (void*) and ...

[kornerr]

Feature request: void ISceneNode::setData (void*) and void* ISceneNode::getData ()

This is very necessary for map editors for item selection (well, may be for other purposes?). In my own editor I certainly have my own classes representing items like MapMesh, MapLight, MapZone, etc, which contain an ISceneNode to be visible (editable, etc) in a map scene. I select items with getSceneNodeFromCameraBB (or whatever). This gives me pointer to ISceneNode. But how do I get MapMesh, or MapLight, or whatever from ISceneNode*, if it is CONTAINED WITHIN the above classes? Of course, here comes get/setID into play. I get ID and search all my arrays of MapMesh'es, or MapLight's, or whatever for this particular ID. Well, when I have 1000 objects I think it'll be taking goddamn much time to JUST SELECT an item. So, when (I hope it'll be added) ISceneNode has setData and getData (like ODE developer(s) already did - hooray) I'll be able to feed my MapMesh, MapLight or whatever to setData (void*) and then I'll be able to just dynamic_cast void* getData () to my MapMesh*, MapLight* or whatever and have an item selected without any searching withing arrays of objects!
It's not hard to implement (a minute or two indeed), so, please, do this for all those who create map editors (may be for others too?) based on Irrlicht (like I do).
Thanks in advance.

[hybrid]

Maybe just use a better search algorithm?! Why not using hash maps or trees to speed up searching. Moreover, I did not really understood what you did. If you already have the scene node you can easily get the data contained in it, but why would a getData inside a scene node help to find it

[Acki]

Well, you could add a void* to the ISceneNode class and recompile Irrlicht...
Or you could derive a new class from the ISceneNode class and add the void* to it...

But the simplest way would be to create a struct like this:

Code: Select all

struct datNode{
  ISceneNode* node;
  void* data;
};

Or you can wait until someone includes this to Irrlicht (but I don't think so)...

@hybrid: I know what he wants to do... For example a Newton body has this get/setUserData as void* to pass any struct/class to the body and get it later inside an event receiver... In Newton you usually pass the pointer to the scene node the body belongs to, so you can get access to the node without any search function...

[kornerr]

Why use ANY search algorithm if there's possiblity NOT TO PERFORM ANY search?
The problem is this:

Code: Select all

class MapPlaceTag {
  ISceneNode *sn;
  CustomMapPlaceTag pt;
}

I use scene nodes INSIDE OWN classes, since for all tasks other than Irrlicht only it's vital to use OWN classes. And getSceneNodeFromCameraBB returns ISceneNode* by getting which one cannot tell what class it's contained in. Adding this damn simple two functions solves the problem. A scene node now may contain ANY info one may need. I want to use it to tell which class (actually which particular instans of a class) constains this particular scene node.

The only way now is to modify Irrlicht source, but hell, it's SO SIMPLE and it's SO POWERFUL. Why not implement it like, I repeat, ODE and Newton devs did? Now I get WHY they did it, which wasn't clear for me at a first glance.

So, PLEASE, make Irrlicht more customizable
Thanks.

[hybrid]

So make a hashmap<ISceneNode*,yourclass*> and ask the hashmap which object contains a particular scene node. I really don't understand your concerns.

[sio2]

So make a hashmap<ISceneNode*,yourclass*> and ask the hashmap which object contains a particular scene node. I really don't understand your concerns.

CMyData *mydata = (CMyData *)somenode->getUserData();

Surely this has to be faster than using some sort of stl::map, no matter how fast a map is? get/setUserData() would simply use a void* internally.

I haven't encountered a need for getUserData() yet, though, so this is just me thinking aloud.

[bitplane]

<sarcasm>
Hmm... while we're adding void pointer methods to irrlicht's interfaces, lets throw in some function pointers and replace the event system with callbacks, they're faster than virtuals.
</sarcasm>

[hybrid]

Moreover, the interfaces are cluttered and quite ugly. And finally Niko told me some month ago that he won't add any void pointers unless unavoidable.

[Spintz]

[kornerr]

Ok, I'll be doing my own patch
I'll call it SimplePowerfulPatch

[Saturn]

I support the userdata in scenenodes. I really don't understand why people would be so against void*'s?

Seconded! It is obviously faster and simplier and easier to maintain than having a seperate map in your application.

If the void* type is the problem, then consider an interface for user data, that those classes have to inherit from, or use some Variant type.

[hybrid]

Yes, the interface was an option, but was never really handled for inclusion into the core. These requests come from time to time, but (apparently) never succeeded. Basically because the scene node tree is not intended to be used as the basic structure for the whole game/app, but only for the render part. So the app should provide means to group data from different libraries into new classes and thus also means to handle relations amongst those structures.

[Saturn]

But ISceneCollisionManager doesn't return my app's structures, it returns ISceneNode pointers. If my application doesn't require (and most of the time it really doesn't) a map of scene nodes, than I have to introduce it solely for node selection (or rather my app's structure behind it).
This has nothing to do with the scenegraph being "basic structure for the whole game/app", on the contrary. Irrlicht more or less outsources this intrinsic part of node selection and burdens the client app with it.

hybrid, think about it. Should every application using ISceneCollisionManager creating its own scenenode -> gameobject mapping, eventhough it is its sole use in the game for this mapping? Doesn't seem useful to me. And obviously if you use ISceneCollisionManager, you aren't interested in the node itself, but rather in the entity this node is representing.

[Saturn]

On a second thought: There is get/setID. At least in 32bit systems, you can cast it to a pointer. Makes void* looking save....

[Eternl Knight]

I am on the side of adding the void* accessor functions. Contrary to what the developers are saying here, Irrlicht is more than just a rendering/graphics engine. As has been pointed out already, there are collision detection interfaces that return an ISceneNode*. So that adds at least collision detection to the mix.

There is also file/resource handling, (limited) memory management extensions, and so on. Also, what harm is there to this approach? It doesn't need refactoring of existing code and adds only 4 bytes to an ISceneNode derived class. Given the current memory usage practices, this is a negligible addition.

Hybrid, bitplane - please let me know why you are so against this? It is common (almost standard) practice for libraries providing collision detection interfaces (such as ODE, Newton, Bullet, etc) to provide this and it has no impact on the usability or "proper use" of Irrlicht.

--EK