ISceneNode::getSceneManager()
-
- Posts: 68
- Joined: Sat May 10, 2008 11:30 am
- Contact:
ISceneNode::getSceneManager()
This method lacks... ISceneNode has a SceneManager member but offers no way to access it, which is a shame because it leads to tricky code (either acces the global scene manager or manually keep track of the scene manager...)
Although ISceneNode::SceneManager exists, I'm not sure if it's a good idea to expose it through get/set methods in the interface (though this is in my local copy)
Thinking about it, the only place nodes actually use the SceneManager pointer is inside OnRegisterSceneNode. So it would probably make more sense to make OnRegisterSceneNode take an ISceneManager pointer as an argument instead, and remove the ISceneNode::SceneManager pointer completely.
Though maybe I'm being selfish here, my impostors implementation could really use a nice clean way to redirect draw calls to another scene manager when rendering the impostors to billboards, temporarily setting another scene manager seems a rather hacky way of doing it.
What does everyone else think?
Thinking about it, the only place nodes actually use the SceneManager pointer is inside OnRegisterSceneNode. So it would probably make more sense to make OnRegisterSceneNode take an ISceneManager pointer as an argument instead, and remove the ISceneNode::SceneManager pointer completely.
Though maybe I'm being selfish here, my impostors implementation could really use a nice clean way to redirect draw calls to another scene manager when rendering the impostors to billboards, temporarily setting another scene manager seems a rather hacky way of doing it.
What does everyone else think?
I suppose it has it's essential uses for cases where multiple scene managers exist, it may be necessary to check the value against several scene manager pointers to ascertain which scene the scene node belongs in.
Is there currently another way of achieving this without double book keeping such information from the get-go? If not I think this will be a welcome addition.
If the scene manager pointer is removed from the scene node, and passed into OnRegisterSceneNode manually, we may end up with troublesome cases where a scene manager from another device could be passed, causing problems if the mesh and texture caches that the scene node references do not exist in the other context. Maybe a tad pedantic but OnRegisterSceneNode is an exposed function.
But in reality, I don't really care if this function gets put in or not, I can't see any significant personal use for it.
Is there currently another way of achieving this without double book keeping such information from the get-go? If not I think this will be a welcome addition.
If the scene manager pointer is removed from the scene node, and passed into OnRegisterSceneNode manually, we may end up with troublesome cases where a scene manager from another device could be passed, causing problems if the mesh and texture caches that the scene node references do not exist in the other context. Maybe a tad pedantic but OnRegisterSceneNode is an exposed function.
But in reality, I don't really care if this function gets put in or not, I can't see any significant personal use for it.
Last edited by BlindSide on Mon Aug 18, 2008 8:16 am, edited 1 time in total.
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
The scene manager is currently the scene graph and some additional global info which defines general rendering information (and other stuff which could be shared among all scene managers, but that's another story). Rendering happens by a call to smgr->drawAll() which draws the full scene graph recursively.
I don't see why rendering a scene graph should change the graph layout, even not for a short time. Moreover, information gathered in OnRegister would be probably wrong, due to changes of the node hierarchies and non-updated absolute positions. I'd need some code example to get the full benefits of the proposed solution and check whether there are alternatives, though.
I don't see why rendering a scene graph should change the graph layout, even not for a short time. Moreover, information gathered in OnRegister would be probably wrong, due to changes of the node hierarchies and non-updated absolute positions. I'd need some code example to get the full benefits of the proposed solution and check whether there are alternatives, though.