Ogre Forums

StaticGeometry can currently only be built by attaching Entities with the following function

addEntity (Entity *ent, const Vector3 &position, const Quaternion &orientation=Quaternion::IDENTITY, const Vector3 &scale=Vector3::UNIT_SCALE)

The Entity is itself just an instance of a Mesh and every tutorial for use of staticGeometry I've seen warns you that you need to destroy the entity after assigning it to the Geometry or you will end up rendering both at a huge waste. Now if I'm correct the only thing addEntity dose is immediately rip the Mesh pointer and Material pointers out of Entity and works with them directly. So why are you forced to make Entities which are serving as nothing but temporary containers for this function and are then a liability. Lets have at least the option of doing this cleanly with the following function.

addMesh (Mesh* mesh, Material* mat, const Vector3 &position, const Quaternion &orientation=Quaternion::IDENTITY, const Vector3 &scale=Vector3::UNIT_SCALE)

As long as the entity is not attached to a scene node there's no way for it to get rendered twice after StaticGeometry::addEntity(). Also, passing direct pointers to reference-counted objects is something you should never do, FYI.

Use MeshPtr then if its an issue, but is this even a valid point when talking about staticGeometry, I though static geometry re-compiles all its data into a NEW mesh so unlike Entity it is not actually adding reference counts to the Mesh and the reference counter purpose of MeshPtr is moot.

My main point is still that the Entity is superfluous and people frequently stumble over this issue of not destroying the Entity, even if its not being rendered it's a waste of space storing it and a waste of time to create and destroy it.

Yes I think this is valid concern, probably the code can be changed in manner of few minutes:-

1) remove 'const MeshPtr& msh = ent->getMesh();' replaced with function parameter
2) line 'SubEntity* se = ent->getSubEntity(i);' is not needed.
3) line 'q->submesh = se->getSubMesh();' replaced with 'q->submesh = msh->getSubMesh(i);'
4) line 'q->materialName = se->getMaterialName();' replaced with 'q->materialName = msh->getSubMesh(i)->getMaterialName();'

I didn't test the code changes, but it seems ok (no compile error).

addEntity() is not superflous. The addMesh() code won't be equivalent because the main point of using entities there is that you can override materials both on an entity as a whole and on it's sub-entities if required. So at least replacing addEntity() with addMesh() would be a regression. Having addMesh() as a separate method won't hurt though.

Yes you are right, although in most cases, the entity's material name is the same as mesh material.

Any Progress on this? Do people actually do what your describing, build static geometry out of entities with altered materials on sub-entities? It sounds like a real edge case at best.