AnimatedMeshSceneNode versus OctTreeSceneNode versus???

bearSoft · Post by **bearSoft** » Sun Dec 11, 2005 11:35 am

a thread on the forum made me pay attension to the differens in nodes.
In most tuts the nodes used are 'AnimatedMeshSceneNode' and they are
invoked with node = smgr->addAnimatedMeshSceneNode(mesh0).
That makes perfectly sence when the node is a ferrie, dwarf or Sidney,
but it does not make sense in the gfx-tut where the node is a static
non-animated 3ds-mesh.
Some overhead must be the price -or?
It works perfectly to use
node = smgr->addOctTreeSceneNode(mesh)
..But, is that an effiecient / recomended aproach?
Is there an even better method? (and if the octtree is the best aproach
i think the tutorials should use that..)

tyia

terefang · Post by **terefang** » Sun Dec 11, 2005 11:59 am

AnimatedSceneNodes are best for that (animated), OctTreeSceneNodes are best for static meshes (for doodads or terrain).

Guest · Post by **Guest** » Sun Dec 11, 2005 1:39 pm

yes but, does that apply to static meshes that are FULLY on screen at all times? so no octree occlusion is going on anyway.

I wish Niko could clear this up once and for all as it is still a source of confusion on what is best for performance when using STATIC (non animated) meshes and not talking about large FPS style levels that obviously need octree or bsp style for culling/performance.

Imagine a top down 3D pacman game with ALL of the "level" in view at all times. If you load that static level mesh as AnimatedMesh (frames=0) it apparently has no overhead (at least I belive that to be true) - but then people say "load it as octree if it is static" but I can't see how octree will help as it won't need splitting up into regions.???

In the above scenario it may even be better to just use animatedmesh (because it doesn't actually animate anyway) instead of any overhead associated with octree analysing/testing per loop???

Also the ambiguity of IMesh and ISmesh and IAnimatedMesh needs clearing up - they all seem interchangable to people who are just scratching the surface.

terefang · Post by **terefang** » Mon Dec 12, 2005 5:39 pm

you're right, animated mesh with only one frame would be ok for your purposes to avoid occlusion overhead.

for your understanding:

IMesh - is the unimplemented (imaginary) base class from which all the mesh-types derive.

SMesh - is a simple implementaion of the IMesh interface.

IAnimatedMesh - is the unimplemented (imaginary) base class from which all the animated mesh-types derive.

SAnimatedMesh - is a simple implementaion of the IAnimatedMesh interface.

there is no ambiguity -- at least not to me.

Guest · Post by **Guest** » Mon Dec 12, 2005 7:51 pm

thnx for info