DotSceneOctree vs StaticGeometry

[Vectrex]

howdy, I'm a bit cunfused.. what would be the difference between
a) DotsceneOctree with it's processed/cut up static meshes and
b) cutting up large meshes into seperate entities in a modeller and loading it as a normal .scene file with the standard dotscene loader and ogre's default octree handling?

Is the cutting up part of DSO the only significant feature?

- also if DSO cuts up a large mesh into say 4 meshes, do these get added to ogre's staticGeometry? (I couldn't see any reference in the code)
- If not are those 4 meshes basically just 4 normal ogre entities that happen to be small enough so culling from the frustrum is better than the uncut version?
- would DSO benefit from adding it's cut up chunks to an ogre staticGeometry? With 'setRegionDimensions' you would loose the finer octree partitioning, but may gain from batching speed.
Thanks

[Zach Griffin]

I too would like to know the best method for doing this. I am at the point where I need to decide one or the other as it is halting me from progressing any further. It is cool to be able to have the mesh cut up for you, however if it sacrifices speed then I would rather manually make cuts in the mesh.

Any ideas?

[jacmoe]

My experiences with the DotSceneOctreeManager is that the speedgain is not that great.
I think it needs to support 32 bit indices, but then it would loose support for older cards.

The DotSceneOctree SceneManager cuts the meshes into chunks and builds scene geometry.

I haven't grokked the code fully, but I think it needs some revision.

I am waiting for the Summer of Code SceneManager, before looking into the innards of the DSO.

I think the best way of handling large scenes is to create several, connected meshes.
It's easier to manage.
Those meshes could be converted to Static Geometry, but that depends.

[Vectrex]

well we have a race track so DSO sped it up significantly, mainly because it was drawing the whole thing regardless without it. But I don't think it adds the chunks to static geometry. So I'll either manually split the track up or see if I can make DSO add it's chunks to static meshes.
Obviously it'd be better for the artists to not have to manually split stuff up as it makes it hard to edit, so I think DSO could be pretty good.
Maybe it could have a #define for 16bit vs 32bit indices? I think 32bit default would be fine.
Will the SOC manager do mesh splitting? I think it's pretty important for things like ours and probably alot of other scenarios.