Hi!
Another question: according to the sample, it's nice to duplicate the objects and render it twice, but it looks like cloning objects would make our code hard to maintain due to its dynamica nature?
I understand the frustration as well.
The Ogre samples offer a solution for this limitation (this is one of the reasons the samples were specifically designed for this):
GameEntity.
You can see that we have:
- GameEntity::mMovableObject (it's not Item)
- GameEntity::mMoDefinition
That last one is no coincidence. The samples provide MoTypeItem and MoTypeEntity. But you can code more. For example in my custom engine I've added one called MoTypeMultiItem (could as well be MoTypeRefractiveMultiItem specifically tailored for dealing with submeshes having refractive materials and requiring multiple instances).
When mMoDefinition == MoTypeMultiItem; I programatically create multiple items based on mMoDefinition; and mMoDefinition->submeshMaterials specifies which materials go on each SubItem.
Hence the central place to manage everything is GameEntity.
Moving, rotating and scaling the object is done either via GameEntity::mSceneNode directly, or better if your engine designs allow it, via mTransform[mTransformBufferIdx] (to allow fixed tick count for logic, and variable framerate for graphics; including multithreading logic and graphics), while mMoDefinition indicates how the Item(s) are prepared visually.
What Ogre is lacking and should provide out of the box but doesn't, is a simple way to split a Mesh into multiple Items, e.g.
Code: Select all
MeshUtils::splitMesh( "meshName.mesh" );
thus creating meshName0.mesh meshName1.mesh meshName2.mesh in memory.
It doesn't even have to clone GPU memory, since the Vertex and Index buffers could be shared.
Or optionally:
Code: Select all
MeshUtils::splitMesh( "meshName.mesh", { { 0, 1, 3 }, { 2 } } );
thus meshName0.mesh gets created containing submeshes 0, 1 and 3; and meshName1.mesh containing submesh 2.
al2950 wrote: Thu Jan 16, 2020 2:42 pm
TBH I dont really see the benefit of sub meshes anymore.
I admit that's true. Submeshes do have their uses when you need multiple materials, but you have limited options if these materials are transparents, as only SubQueues is available (and the main reason to use multiple materials is often because some of them have different "hard" properties that can't be affected with a texture, such as transparency or culling mode).
and many of our transparent objects are "hybrid" so only very few transparent objects would actually have refractions
Rasterization isn't good for this type of material combination. Even ray/pathtracing has issues with these materials (as they require lots of bounces or samples)