Ogre Forums

A while back there was some discussion of providing a listener for LOD changes. After reading the posts on the subject and doing some preliminary work to see what’s involved, I’d like to proceed with this feature.

The initial implementation would be relatively simple, but could be extended later if required. Each scene manager would maintain a set of LodListeners which may implement the meshLodChanged method. This method would be called whenever the mesh level of detail for an entity changes with respect to a camera (triggered from Entity::_notifyCurrentCamera) and would accept a MeshLodChangedEvent argument. This argument would contain the entity and camera in question along with the previous and new lod indexes and the squared depth of the entity relative to the camera.

I will need to finish the basic implementation and perform testing before releasing a patch. Let me know what you think of my plan and how it could be improved.

Can billboard set, particule system, even user static geometry can take advantage of that if you override this on entity/mesh level ?
Perhaps lower level would be better ?

Initially, billboard sets, particle systems, and static geometry would not produce events for the listener. Each subclass implements it's own level of detail system, so a single event is probably not desirable (unless I'm missing something). However, the listener could be extended with methods which could be called from other objects. I had not planned to implement this functionality in the initial release, but if it is an integral feature, I would be willing to work on it now.

each subclass implements it's own level of detail system, so a single event is probably not desirable (unless I'm missing something).

Well those implements "_notifycamera" but LodListener idea would be more 'userspace' so that if an user can switch from billboard to a static geometry to mesh, etc, using listener events.

And that has to be done async by the 'user' otherwise It would break current render.

if listener fire event in the middle of a render, and that user change part of the render (few isolated mesh becomes static geometry meshes.)

Thank you for your feedback.

I will try to unify the listener to all MovableObjects which implement LOD.

In my initial implementation I had assumed the user would be responsible for synchronization (not modifying the scene during the listener), as some listeners might not need to change the scene. However, I understand that it would be desirable not to burden the user with this task. Would an event queue which is handled after the scene is rendered be a good choice here?

Would an event queue which is handled after the scene is rendered be a good choice here?

If you make sure the performance/memory is not impacted when there's no user-listener provided...
Could be in two part, where user give a prequeueListener that return true if has to be queued... and a postqueuelistener that really fire event once culling/rendering pass is finished.

Otherwise documentation, comments, code has to prevent at maximum user mix renderqueue...

I'm going to go ahead and post what I have so far. I've implemented lod listeners with methods for movable object lod events. As tuan suggested, a pre-queue method is called during rendering to determine if the event should be added to the event queue. If it is, the post-queue method will be called after rendering is complete.

To use this, you will need to put OgreLodListener.h in your OgreMain/include directory and apply the supplied patch.

I've also included a simple demo.

Download:
(Required) OgreLodListener.h - http://www.mediafire.com/?fugtus122rg
(Required) Patch - http://www.mediafire.com/?hd1n9yl5gzt
(Optional) Demo - http://www.mediafire.com/?eg9egd9gjhd

Let me know what you think and how it could be improved.

Great !

Just lacking the renderquue::invocation info in event.

Please post your patch on sourceforge ogre patch tracker (you'll be able to update it overthere as well if needed)

I'll post a patch on sourceforge as soon as I add the render queue info to the events (hopefully tomorrow).

After looking through the code, it appears _notifyCurrentCamera is performed before the render queue invocations, so it doesn't have that info. The notifications could be moved to the render queue invocation level, but at that point, it is no longer dealing with MovableObjects, but Renderables. As a result, I don't see how to supply both the MovableObject and the RenderQueueInvocation to the listeners. Let me know if I'm missing something here.

If all you want is the render queue group id, that is available through MovableObject::getRenderQueueGroup.

I'm going to go ahead and submit this on SourceForge.

Thanks for the patch !

It could be done using a RenderQueueListener, getting the info there, once per renderqueue invocation, and then giving to user by your listener.

Or user has to suscribe himself a RenderQueueListener, which is perhaps better. (but must be documented.)

I looked at RenderQueueListener, and it doesn't appear to have any information about MovableObjects (which I assume is desirable for LOD). Unless I'm mistaken, the RenderQueue contains Renderables, not MovableObjects, and is at a lower level. I'm not quite sure why individual invocations of the queue should each produce LOD events.

Wasn't about getting an event for each object, but at each Renderqeue invocation change, so that user know how to handle all following individual lod events. (could be used to handle differently shadow LOD from standard LOD.)

I misunderstood what you were saying before. I can easily include render queue invocation events in the LOD listener. Would you prefer I do this or, as you suggested above, just include documentation stating that potentially useful render queue invocation events can be subscribed to with a RenderQueueListener?

The best would be to point the user to an existing interface. Thanks to multiple inheritance it is no problem getting both events in one class.

Sinbad has suggested that this be incorporated into the Summer of Code lod strategy project, so any future discussion should probably take place there: http://www.ogre3d.org/phpBB2/viewtopic.php?t=40308.