well the collsion detection is output to a animator same for the user cameras.
And they are actually only there to allow to quickly look through the 3d scene. i actually never used the irrlicht collision system after i found out how crappy it is and that it is really only there to allow quick prototyping of some area. Bc everything beyond that already kills it and makes it fail. Its a nice gimmic for starters but not worth using for a bigger project than walking the included quake3 map.
Besides that irrlicht is really only a 3d graphics engine and pretty good at it. So lets keep the little gimmics for starters as much out of the core as possible and using an animator for fetching ur userdata can't be so hard. What are u trying? maybe i have a better idea to solve it.
Connect node with custom class? (ISceneNode User data)
Walking a map with an integer key is extremely fast. Inserting and removing can take a bit """long""" (as far as comp time is concerned) but that depend of your std implementation. But an optimized trickle down of a binary tree with int as key is amongst the fastest access to your data if it is not stored within.
As a new user, I'd like to chime in and say that a void* userdata pointer in Irrlicht nodes would be very useful. I'd use it, for instance, to link each node with its Bullet physics information, in the project I'm currently starting. The other options proposed (using some type of search, or hijacking the ID, or other more complicated hacks) are not very attractive compared to the speed and simplicity of a pointer.
Box2D (2D physics library) provides this for its objects and it's very useful. If I remember well, it does provide a callback you can register with to be notified of an object's destruction, so you can cleanup whatever your void* was related to. Irrlicht can probably provide the same thing with ease.
Obviously, the pointer should not be serialized. And there should be a clear warning in the Irrlicht API that whatever the user points to is his responsibility.
Box2D (2D physics library) provides this for its objects and it's very useful. If I remember well, it does provide a callback you can register with to be notified of an object's destruction, so you can cleanup whatever your void* was related to. Irrlicht can probably provide the same thing with ease.
Obviously, the pointer should not be serialized. And there should be a clear warning in the Irrlicht API that whatever the user points to is his responsibility.
A friggin binary tree! If you can't structure code to have a minimum of info tied to a custom node (yes, you can do those, you know?) nor can you satisfy yourself with the speed of an optimized binary tree look up, then you can ESPECIALLY NOT afford the extra weight of that pointer slowing you down everywhere the object is passed, taking 32/64 bits for nothing in the vast majority of cases.
I think any search would be inefficient : imagine you have a lot of nodes but only 3 are visible. You pick the first with your mouse, and you want to retrieve the entity (or whatever you want) associated with this node.
A binary search is not performant here - event if you have walked on only 25 node (for example) there is 24 nodes which shouln't have been walked on...
And there is the stability reason : if everytime you add/delete a node you have to update the binary tree the probability of errors is higher than if every sn have a pointer to user data.
At least, each sn could have a referenceCounted object which contains the pointer, this approach is similar to what is done with Ogre, Qt, etc... with a string containing the name of the data (example : Entity, etc...)
Last but not least : irr::io::IAttributes already have a UserPointer...
A binary search is not performant here - event if you have walked on only 25 node (for example) there is 24 nodes which shouln't have been walked on...
And there is the stability reason : if everytime you add/delete a node you have to update the binary tree the probability of errors is higher than if every sn have a pointer to user data.
At least, each sn could have a referenceCounted object which contains the pointer, this approach is similar to what is done with Ogre, Qt, etc... with a string containing the name of the data (example : Entity, etc...)
Last but not least : irr::io::IAttributes already have a UserPointer...
A binary search over 25 nodes, really?
33,554,432 nodes in your table? (Or 16,777,216 in an optimized one, in which case you really are bad lucky if you got that deep.)
Do you even HAVE that much nodes that need custom data?
For that matter, do you even HAVE CLOSE to that many nodes?
Me thinks thou doth not know how to organize data.
Split it per zones/room/whatever.
Make it relational or per class
Have it in a custom class
Then use a std::map for those few cases you'd still need.
No, it will not be slow. No, it will not be a time sink. No, it will not be a memory hog.
33,554,432 nodes in your table? (Or 16,777,216 in an optimized one, in which case you really are bad lucky if you got that deep.)
Do you even HAVE that much nodes that need custom data?
For that matter, do you even HAVE CLOSE to that many nodes?
Me thinks thou doth not know how to organize data.
Split it per zones/room/whatever.
Make it relational or per class
Have it in a custom class
Then use a std::map for those few cases you'd still need.
No, it will not be slow. No, it will not be a time sink. No, it will not be a memory hog.
All my nodes exept the terrain and the camera, are attached to an entity.
My nodes are already organized in octrees ( it is not irrlicht's octtrees, but one I have made).
And finally I think that a userData pointer could be in each scene node for convenience, you have no map to update, thus you can be sure that there is no false pointer in the map ( and it add just 4 or 8 bytes to each sn whereas a map consume a lot more memory )
Using pointer instead of arrays is easier to debug than an array of pointers, I think.
My nodes are already organized in octrees ( it is not irrlicht's octtrees, but one I have made).
And finally I think that a userData pointer could be in each scene node for convenience, you have no map to update, thus you can be sure that there is no false pointer in the map ( and it add just 4 or 8 bytes to each sn whereas a map consume a lot more memory )
Using pointer instead of arrays is easier to debug than an array of pointers, I think.
A map would only be bigger if all or close to all nodes had a pointer.
You have this crazy assumption every node needs an extra data pointer. Why? What would particles do with it? What would most obstacles do with it? What would most normal instances of a scene node do with it?
Finally, what is stopping you from deriving from the scene node you need and implementing your version on top, with a pointer to whatever data you need? That way it can even be typed, thus stronger.
You are just stating your "need" for such a thing, yet you do not give a single example of a case where you'd actually need it except out of sheer laziness and bad design.
You have this crazy assumption every node needs an extra data pointer. Why? What would particles do with it? What would most obstacles do with it? What would most normal instances of a scene node do with it?
Finally, what is stopping you from deriving from the scene node you need and implementing your version on top, with a pointer to whatever data you need? That way it can even be typed, thus stronger.
You are just stating your "need" for such a thing, yet you do not give a single example of a case where you'd actually need it except out of sheer laziness and bad design.
-
hybrid
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
False pointers would just mean that your own scene organization (which is not and must not be related to Irrlicht scene graph at all, because the scene graph is hierarchically organized, not based on the position) has failed. I don't think that a scene node would be removed without you noticing it, and with probably quite some computational effort (for checks, organization, etc.) in advance. So a few checks in the map won't make a difference. Simply don't belive that ignoring the model-view-controller pattern will increase your program's reliability.
The problem with adding the user pointer is not the additional memory consumption. Even with 100k scene nodes this would only mean an additional 1MB of RAM. The transformation and stuff are much more demanding. Also passing this data is not a problem, as only pointers to scene nodes are passed. The only (but very important) problem is that people will tend to use this pointer for everything. They will blame Irrlicht to not update their things stored in this pointer, will ask for consistency constraints, and lots of other stuff which belongs to the actual game engine, not to Irrlicht. Using a reference counted object instead of a raw pointer would make this a little safer to use, but would easily lead to scene nodes being kept in memory due to forgotten grabs.
So, I don't think that we need such a pointer. If someone has a well designed app which would benefit from this pointer, please show up. This might be a reason to change my mind.
The problem with adding the user pointer is not the additional memory consumption. Even with 100k scene nodes this would only mean an additional 1MB of RAM. The transformation and stuff are much more demanding. Also passing this data is not a problem, as only pointers to scene nodes are passed. The only (but very important) problem is that people will tend to use this pointer for everything. They will blame Irrlicht to not update their things stored in this pointer, will ask for consistency constraints, and lots of other stuff which belongs to the actual game engine, not to Irrlicht. Using a reference counted object instead of a raw pointer would make this a little safer to use, but would easily lead to scene nodes being kept in memory due to forgotten grabs.
So, I don't think that we need such a pointer. If someone has a well designed app which would benefit from this pointer, please show up. This might be a reason to change my mind.
There is no particles, no obstacles. All sn (except terrain and camera) are user-controllable and selectable. Moreover, they can be anything (AnimatedMeshSN, etc...) so it would mean reimplement and update each SN interface everytime I update Irrlicht...
I use the scene manager just for dynamic octrees (just for optimizing render), entities are organized differently. You will say that I have just to search in the visible octree's list of sn, but in case there is a lot of sn it could be a bit slow...
At least, we can create the two functions setUserData and getUserData, and activate/desactivate them using a define. And by default irrlicht won't have these methods until users haven't defined _IRR_COMPILE_WITH_SCENE_NODE_USERDATA_ (for example)
I use the scene manager just for dynamic octrees (just for optimizing render), entities are organized differently. You will say that I have just to search in the visible octree's list of sn, but in case there is a lot of sn it could be a bit slow...
At least, we can create the two functions setUserData and getUserData, and activate/desactivate them using a define. And by default irrlicht won't have these methods until users haven't defined _IRR_COMPILE_WITH_SCENE_NODE_USERDATA_ (for example)
As it doesn't look currently like that will be added to Irrlicht I would say if you really need some UserData then add it to your engine version. It is always good to avoid changing the engine, but well, we have the sources and in a larger project it will happen sooner or later anyway. Just make sure you create a patch-file for every change you make as it will make updating to newer versions a little easier. Myself I haven't needed UserData for SceneNodes so far, but I added a similar pointer in the GUI when the alternatives would have produced a worse design.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm