[Solved] Gain performance by entities in viewport detection

[kubatp]

Hi,
I would like to know an opinion of OGRE experts on one idea which came to my mind.
In my game I have several thousands objects: units - usually not moving (not changing position) but animated (skeleton animation) and animals, which constantly move and are also animated.

I would like to create an in-viewport-detection and if

• Unit is not in the viewport, it will stop calling AddTime of running AnimationStates
• Animal is not in viewport, it will also stop calling AddTime of running AnimationStates, but it will also not change the location. Instead the location change will be called (lets say) every 10s and update the location on longer distances (so player can still see that new animals can pop up from time to time).

What do you think about this? Does it make sense to implement this (from the performance point of view)? If this makes any difference, I still run OGRE 1.7.4

[kubatp]

No views on this?

[farrer]

I remember read somewhere that Ogre 1.x do frustum culling on animation/skeleton update, if it's the case for 1.7.x, culling it again is probably a waste of time.

"Somewhere" is: here:

In Ogre 1.x, culled (as in: not visible in the view frustum) objects do not have their animation and skeleton updated. Sounds sensible at first, but this can cause problems when the animation drives collision objects or other gameplay elements.

and here:

Ogre 1.9 applied frustum culling before updating the skeletons.

[kubatp]

Hi Farrer,
thank you very much for your reply.
That sounds reasonable. I would still like to try the performance difference at least for animals, which changes locations almost all the time.
Do you know what function would immediately tell me if entity is in view frustrum?

[farrer]

Do you know what function would immediately tell me if entity is in view frustrum?

Use Ogre::Camera::isVisible passing to it the entity's bounding box.

[kubatp]

Hi Farrer,
once again, thank you for your reply. I decided to spend some time on this to find out real values of performance gain. I was surprised that the performance change (once I applied the rules described in previous posts) was pretty big. I was able to increase the FPS around 20%. The problem was that I couldnt use Ogre::Camera::IsVisible because once it got off the frustrum and animals movement was stopped, in some cases you could still see the shadows of the animals (not moving). I had to create my own frustrum viewport detection, however it seems to work pretty well now.
I am not sure if the performance gain would still be there for newer version of Ogre (1.8 and higher), however I suggest to try this if performance is a bottleneck.

Once again, thank you for your help.

[Zonder]

If your working in a 2D plane meaning things moving on a terrain.

You could keep a list of entities currently in a grid slot and just update around the camera virtual location in the grid.

What I mean is :

GridSize = ViewDistance / 3

GridLocation = Camera \ GridSize

Compute animation/movement only for

GridLocation - 1 to GridLocation + 1 in real time and -2 and +2 every other frame and -3 and +3 every 3rd frame etc.

You obviously would have to play with those numbers they are just examples

[kubatp]

Hi Zonder,
thank you for the reply, but I am not sure I understand. Some of the animals are not moving on terrain, there are birds flying pretty far from terrain. But lets say all are on terrain, can you please try to explain your suggestion a bit more?
Thank you

[Zonder]

I mean deal with your world as if it was a 2d Grid say your world is 1000m2 each grid tile could be 25m2 in size meaning a grid of 40x40. You then have a list of entities per tile which you update as required, so tile 1,1 might have 10 entities but tile 1,2 has 1000 for instance.

So which ever tile the camera ends up in update the tiles around it in real time, then update tiles further away less often.

Grid Size = 25m
Position = 624m,100m
Tile = Camera Position \ Grid Size which is 24,4

[kubatp]

So which ever tile the camera ends up in update the tiles around it in real time, then update tiles further away less often.

Interesting approach, thank you for explanation. I will give it a try.