LOD listener for custom user Lod (at least impostor)

[tuan kuranes]

Lod strategie SoC didn't make it, but we're indeed in need of something like that, for impostoring, user needs (disabling ragdolls at certain lod, etc...)

- Mesh format that has list of distance that call a Lod listener.
- Listener would fill an Event with gives entity Name/ptr, distance, sqDistance, Lod Level.

Could be mixed with current lod distance list, which would switch mesh only if loded mesh exists at this lod ?

Ideas, toughts ?

[sinbad]

Yeah, that's an interesting idea - I assume you mean a callback when a LOD level is changed?

[tuan kuranes]

I assume you mean a callback when a LOD level is changed?

yes, primary idea being to save a distance comparison on all mesh and all means every single mesh loaded as application don't know if mesh is visible or not.
Impostor, replacement mesh (billboard clouds, lots of tree => forest mapped box ), application LOD (AI, physics, ...), anything may take advantage

- Listener would fill an Event with gives entity Name/ptr, distance, sqDistance, Lod Level.

forgot that we need a Camera pointer too, or at least camera position=.

[sinbad]

Yep, camera pointer would be best I think (this will be chaining down from _notifyCurrentCamera after all). The generalisation of LOD up to MovableObject level would be advisable here too.

[Vectrex]

nice, I'd use this for unusual things like 'lodding' client side interpolation of network entities (vehicles). So far away they would just lerp between the updates, but up close they would have full physics to fill inbetween updates and look cool

[pxL]

Since my SoC request I have taken on other tasks. So I won't have enough time to fully work on it (Not to mention the experience). So someone else (with time) should take the lead on this.

But my offer still stands I would still be happy to help someone with implementing this request .

[Crashy]

I sincerly also want to add impostor to the instancing , but after the SoC

[klauss]

I'm thinking of a generic way to do lodding.
It's in my interest to have group LODding, or what I call "arbitrary imposters". That is... imposters aren't just dynamically-rendered quads... maybe they're pre-rendered representations of a more complex group of objects.
I'm thinking about a specific case: dense asteroid fields. You may want to have a separate instance for each asteroid up close, but on the distance you'll be content with having a single mesh represent a lot of them (the mesh would contain some alpha-blended quads with pics of the asteroids, one quad would hold many asteroids). That is... a specific way of LODding an asteroid field as a whole.
Well... imagine a similar technique applied to clouds - at a distance, you imposter lots of clouds with a single "group" representation.
Or some other stuff, that can be globally LODded like that.

Common imposters would be a specific case of this generalized scheme.

I'm having a bit of trouble making it fit Ogre's organization. Basically, I think LODding would have to be moved up to the SceneManager.

[spookyboo]

It is on my wish list too. I haven't given it a lot of thoughts yet, but it should be something generic, as tuan kuranes states. Even something simple as reducing the number of emitted particles of a particle system in the distance could benefit from this.

[Praetor]

Well related to this LOD business, is someone still pursuing a complete imposter system for ogre? Is there a true owner who is developing and maintaining it. It sounds like this LOD callback is needed to facilitate making it a plugin (as opposed to merging it into the core).

[pxL]

I think tuan was working on it, but he has to much stuff to do atm so he is looking for someone else to pick up the 'batton'.

There is enough to do when it comes to LOD checking in OGRE itself :
- Generalizing LOD checking (ie. in MovableObject)
- LOD Listener methods (LOD events)

- Add another LOD checking method (ie. size on screen instead of distance)
- Maybe generalize the way you add a LOD check
- Maybe a 'Nothing' level of detail

And ofcourse impostering .

[spookyboo]

One thing that came to mind was to create a new function
MoveableObject::addCustomTechnique(CustomTechnique* customTechnique)
CustomLodTechnique would then be a specialisation of CustomTechnique and is responsible for handling the custom lod of that MoveableObject at a specific squaredDistance.
If you add a specific CustomLodTechnique instance to multiple MoveableObjects you could even let it be the link between MoveableObjects (an Entity that will be replaced by a BillboardSet).

Just a thought.

[klauss]

I've been toying with that.
But you just can't have MoveableObject link themselves in that way, without messing the current scene structure.

Because... either subordinate movables aren't included in the Moveable list in the SceneManager, and the master Movable acts as proxy, or you have to change the whole way in which Movables are tracked in scene managers.

Rather, I was hoping the scene graph could be used to that effect. I mean, you could have Loddable nodes. Movables under those nodes have their LOD controlled by the node, and adding the nothing LOD would be mandatory. Then, a special kind of node (custom LODding techniques attached to nodes) would control which subtree under the node gets which LOD. Switching between one or other representation of the subtree means toggling visibility of one direct child over the others. It's very neat, but requires quite some support from SceneManagers. I think it makes most sense that LODding would be handled by SceneManagers, but I don't want to force SceneManager implementors to have to worry about LODding if they're not intending to override functionality, and that gets somewhat difficult.
I'm also trying to figure out if subclassing SceneNodes could be a better idea than listener interfaces. I'm not sure, but I think it would. The problem is that Scene exploration (for rendering) becomes affected, as invisible subtrees would have to be ignored for optimum performance. That also depends on the SceneManager implementation, not all implementations will be able to efficiently decide whether a node is under an invisible LODding node or not, so I'm trying to make such data widely available to child nodes so that scene managers can exploit it.
It's complex, but I might be able solve it eventually.
If I do, I'm certainly posting the idea, and I might even take the batton and implement it.

[syedhs]

So is that mean LOD listener will get into Eihort release?

[tuan kuranes]

@spookyboo & klauss : Listener allows to do that, but application side, which is IMHO the best place. It's up to application to "link" different "movableObject" it needs to. CustomLodTechniques sounded more like using size on screen instead of distance to cam for lod switching.
And listener allows a lot of other things too on physics, ai, network, etc

@syedhs: if someone submits a patch... it sure would be faster.

[syedhs]

Yes sure, it is just that I am not in the 'league' yet to submit a patch to ogre engine - although I do understand what is this all about.

[klauss]

I'm not sure a movable-level listener would be able to speed up visibility discovery. That is... the SM would still have to take the LODded entities into account, even if they won't be rendered. For simple SMs, like the generic one (even the octree), that would imply an important performance impact if there are many entities (for instance, again, the asteroid field - it is composed of 1 or 2 thousand entities - and sometimes there are multiple fields).

I'm also talking about listeners, but having the listener (or otherwise overridable implementation) at the SM level.

I'll try to work on that soon, but I have a busy week/weekend, I have some exams and quite some work waiting for me.

[tuan kuranes]

That is... the SM would still have to take the LODded entities into account, even if they won't be rendered.

In the impostor code, I do remove scene node of impostored entity when "loded" into impostor, thus making loded entity no more slowing visibility scene lookup. There's no reason we cannot do that using listener.

[klauss]

Hm... are you certain you can?
Modifying the scene graph in the LOD listener might be messy. You don't know if you're allowed to do that inside a render loop. If that was to be allowed, I'd pull the LOD listener callbacks out of the render loop (that is... there would have to be a previous iteration over the scene graph, prior to visibility checks, otherwise changes on the scene graph may not get reflected on the "visibility discovery" results).

[tuan kuranes]

@klauss: good point, current code isn't inside SM visibility determination graph.
Listeners should then be called at end of frame on that render target.

[Vectrex]

did anything come of these ideas? I think a lod listener would be great.

[sinbad]

No, it got buried and the implementation details are a little tricky regarding efficiency. I haven't put a lot of thought into it as yet.