Proposing new methods for Ogre::SceneManager::Listener

[mdias]

Hello

I've been developing my own game and engine using Ogre, and I believe users could benefit from new methods on SceneManager::Listener.

Methods I believe would be helpful:
- Listener::postNodeCreate
- Listener::postMovableObjectCreate
- Listener::preNodeDestroy
- Listener::preMovableObjectDestroy
(more for other object types)

Why
Associating user data with an object and destroying it when no longer needed.
Creating a custom SceneManager for this purpose seems overkill and would need different implementations if different SceneManagers are needed. Plus, it would be troublesome to use SceneManagers exposed via plugins.

Of course the user could implement this on his side too by having a custom scene manager that uses Ogre's scene manager to create the needed objects and allocating the custom data, but then if someone (including 3rd party libs) destroys the object using a SceneManager::destroy* method directly, leaks will occur and invalid pointers may be there somewhere (because the 3rd party lib doesn't know about the user data).

Personal need
I'm integrating scripting on my engine, and I feel the need to keep track of all the ogre objects created and destroyed at any time so I can expose Ogre objects to my scripts and call apropriate methods to notify the scripts about an object's destruction.

I know Ogre is not a game engine and that I could/should implement my own state/scene tracking, but the fact is that this functionality would be helpful for plugin developers, and would fit perfectly on my current design decisions. I know I could modify Ogre for this, but I think everyone would benefit if implemented in trunk.

What do you think?

[CABAListic]

I'm skeptical in so far that all of the events you suggest would be a direct consequence of a direct user call to Ogre's API in the first place. I.e. Ogre does not create Nodes or MovableObjects on its own, so whenever your code receives this event, it would have had to call the corresponding createXXX function beforehand. Therefore, any additional state/information you would want to attach to a created Node/MovableObject could happen directly where you created the Nodes.

I think in your case it would be more appropriate to create wrapper functions around createSceneNode etc. that incorporate the additional housekeeping you need, and then expose those functions to the scripting engine instead of the original Ogre versions.

[mdias]

I'm skeptical in so far that all of the events you suggest would be a direct consequence of a direct user call to Ogre's API in the first place. I.e. Ogre does not create Nodes or MovableObjects on its own, so whenever your code receives this event, it would have had to call the corresponding createXXX function beforehand. Therefore, any additional state/information you would want to attach to a created Node/MovableObject could happen directly where you created the Nodes.

I think in your case it would be more appropriate to create wrapper functions around createSceneNode etc. that incorporate the additional housekeeping you need, and then expose those functions to the scripting engine instead of the original Ogre versions.

This is exacly what I felt you'd say. However, think about what 3rd party plugins could create on their own without ever being noticed by my scene manager. I'm not yet sure if I want to expose Ogre objects to the scripting API directly or expose a wrapper, but I imagine if I would be creating a world editor of some sort with the ability of being extended via scripting, I would need this.

I believe this feature would give some nice extra power/tools to developers while sacrificing very little in performance.

I will go the wrapper way either way on my case, the thing is I could automate the wrapper creation and destruction in a way that I'd be sure I wouldn't be missing wrapping some nodes created by 3rd party libs.

[edit] pseudo code of the problem:

Code: Select all

_thirdPartyCloudGenerator.generateClouds( _ogreSceneManager, _parentNode );

// without the listener methods, I'd need these extra steps:
makeWrapperRecursive( _parentNode ); // <-- if there were already wrapped objects before generateClouds(), I'll have to extra check what's been created already and what not...

...

destroyWrapperRecursive( _parentNode ); // <-- how should I know which objects belong to the cloud generator so I only unwrap those?
_thirdPartyCloudGenerator.destroy();