where are the static objects

[da_oAsch]

In the Ogre Manual are mentioned the Entities, which i use for objects that moves

My Problem is, that i couldnt find a class for static objects that dont move, like rocks, houses, trees, ...

May anyone tell me where i have to do such objects?

thanks for help
Tom

[haffax]

These can be entities too, but it will not be optimal performancewise. Two further options:
1. Use the DotSceneManager from the Ogreaddons. It allows you to define static meshes in a .scene file.
2. Wait for Ogre 1.0 (due in a few weeks). It will provide a geometry baker, that lets you glue static meshes to each other / to the ground.

This thread has also some information on this topic.

[SpannerMan]

2. Wait for Ogre 1.0 (due in a few weeks). It will provide a geometry baker, that lets you glue static meshes to each other / to the ground.

I have been meaning to ask this for a while, but is their a minimum limit of entities / polygons that you need before the new StaticGeometry class will really make optimal differences? I imagine that using only one static low-poly entity would not be worthwhile baking?

Take for example the OGRE athene model. Say I wanted to use this statue in my scenes, it would never move, its cemented to the floor. How many of these guys would I need before it becomes worthwhile baking them in the StaticGeometry class?

[monster]

Baking one static low-poly (or high-poly for that matter) entity wouldn't make any difference at all, since you'd still have one transform and render-op for that static object.

If you baked two you'd have a difference, since you'd have the equivalent polys of two entities but just one transform and render-op, whether you'd be able to notice that difference or not is a different matter entirely.

With my GroundCover class (and the new Ogre baking stuff is much more sophisticated) I noticed massive differences when you're into the hundreds of objects. And an unbeliveable difference once you get over 1000 entities, at which point it seems I hit the transformation limit of my card, since that's where a simple OpenGL test app bottlenecks too.

This is part of my reason for suggesting the SceneNode "freeze" / "thaw" idea, so that you can build your scene up as normal (i.e. with lots of entities), monitor performance/memory usage and make selected bits static/dynamic on the fly to tune the scene accordingly. Don't know if that idea's made it into Ogre though. Probably not.

[haffax]

Good question. It is basically the question if the overhead (applying transforms, culling checks, multiple renderops) for several objects outweights the overhead (less agressive culling). Without real knowledge in that part I'd guess it wouldn't hurt to bake even only two entities together.

[:wumpus:]

This is part of my reason for suggesting the SceneNode "freeze" / "thaw" idea, so that you can build your scene up as normal (i.e. with lots of entities), monitor performance/memory usage and make selected bits static/dynamic on the fly to tune the scene accordingly. Don't know if that idea's made it into Ogre though. Probably not.

I remember Sinbad found that a good idea, and is going to implement it but with a slightly different interface

[Kojack]

If multiple entities are baked together, do they maintain individual culling?

For close together objects (like items on a desk) you'd probably want to use one culling check against the baked group, but for more distance objects (anything the camera can fit between so some geometry from the one baked group can be both behind and in front of you) you'd want to keep per entity culling but still use one baked transform for it all.

[:wumpus:]

They are baked together into one rendering operation, so that they are culled together; otherwise it would make little sense as the transformations are not the thing slowing stuff down but queuing the renderops.

[sinbad]

I decided against the freeze / thaw idea, since 'thaw' came with too many caveats and I'm short of time.

My new interface is based on allowing you to add both individual Entities and SceneNodes to the static geometry. Adding a scene node still only adds Entities for simplicity (baking arbitrary types like billboardsets seemed pointless, and if you use custom renderables you really should be batching yourself), so adding a SceneNode is a kind of short cut. One thing it doesn't do is detach, delete or take ownership of the SceneNode from the scene graph for you. That's deliberate - I was thinking you might want to build the static geometry in advance and switch over at some later point, or keep the original version to provide your 'thaw' option. This was more practical than trying to pull apart the static geometry back into it's original form.

[SpannerMan]

Ahh ok I see. I had concerns whether the cost of OGRE managing a baked group having only a small amount of entities would exceed the cost of not having them baked at all, but that doesnt sound like the case, so thats good.

They are baked together into one rendering operation, so that they are culled together; otherwise it would make little sense as the transformations are not the thing slowing stuff down but queuing the renderops.

I was also wondering about the culling aspect, what you say makes obvious sense.
So I guess what people need to consider when looking at using StaticGeometry (like what Kojack said) is whether their scene will benefit more from simply allowing OGRE to cull entities/nodes out the equation, or to miss out on the individual culling but get the benefits of the fewer render operations. The more scenenodes that you have that are tightly grouped e.g. a forest of trees, then its obvious that baking them is going to be speedier.

[Cyberdigitus]

That sounds cool Sinbad, exactly like what i had planned for my manager.

Or wait... what do you mean with static objects here? those are a new entity right?

I suppose this system could also be seen as a world geometry system for the generic manager, but i hope it allows batching a scenenode hierarchy like you say, returning a mesh / entity / custom renderable that can be added to a node again, ie a way to combine buffers generally.