Thank you very much for these info dark_sylinc.
What will be discouraged:
- Use of entities. There are now Items. They're very similar. Both derive from MovableObject, and have SubEntity/SubItem that derive from Renderable. Items can only use Hlms materials. Entities can use both low level and Hlms materials. Entities can be auto instanced; and they're added to the RenderQueue in a single threaded. Items are not just auto instanced, they have low overhead even if you have multiple meshes (think instancing with different meshes). They're added to the RenderQueue from multiple threads.
- Note that Items use a different Mesh and Submesh classes than Entity and SubEntity.
- Use of low level materials. Low level mats. are useful for post processing effects, or rendering a special model with a very specific shader. But for most of the objects in the scene, you'll wanna use the HLMS for much more efficient rendering.
Ok these changes should be easy in my case, I purposedly only used basic Ogre types and in a very simple way (except temporarilly use OgreProcedural to generate everything, but that will change soon). The code is isolated enough that I can change everything easily.
The "They're added to the RenderQueue from multiple threads." part is not 100% clear to me: do you mean that if I own several thread, they can all create Items concurrently? Or is it something internal to Ogre?
What is broken:
- Multi pass materials (low level). Right now they're not working. We plan on restoring support for them, but they will be in their own RenderQueue ID (i.e. the RenderQueue when put in "multi pass mode" will use a slower path).
- Anything with the word "RenderQueue" on it. The old classes have been removed. RenderQueueInvocation, RenderQueueListener, RenderQueueSortingGroup, the RenderQueue's groups, etc. This is the new RenderQueue class. That is an older version, but the public interface and even the internal code doesn't differ too much from the final one. We just added a few more routines for AZDO.
Ok so for the RenderQueue at the moment I put everything, even the UI into the normal rendering (for game-specific purpose) so I don't need to touch it.
I believe at some point in the future I will have to use it but not in the coming 3 months at least.
What is unclear:
- InstanceManager. The new RenderQueue provides automatic instancing. However, initial testing suggests that if you have lots (and I mean A LOT) instance of the same mesh; InstanceManager may surpass Items; as the RenderQueue has to spend some time adding each individual MovableObject to the RenderQueue analyzing whether the it can be instanced or not; while the InstanceManager can just assume lots of stuff. But it's not clear whether this is worth it, as the difference starts showing up at very insane high numbers which aren't realistic for most use cases. Also Items don't degrade performance when using multiple meshes and/or multiple materials. We're just scratching the surface with AZDO.
I believe I am in the case of "a lot of instances" but depending on some details in the mesh structure, I'm not sure if I will be able to benefit from instancing in all cases.
At the moment I just use Entities and will do so until I reach performance issues (surprisingly, I don't, but I don't have any special shader effect so even with a great number of entities I see slowdown only in releaseDebug). I planned to switch to instanciated entities later.
- Use MovableObject and Renderable as much as possible. The former is the base class of Entity, InstancedEntity and Items; the latter is the base class of SubEntity, InstanceBatch, and SubItem. When you port over, you'll just have to modify the parts where "Entity" shows up.
[*]Code in mind that you may want to choose between between using an Entity or an Item. There could be reasons to use an v1 object (that's how we call them, Entity is a v1 object vs Item is a v2 object). So don't assume you'll replace all entities with Items when 2.0 Final arrive.
The issue here is that even after having read all I can about Ogre 2.0, I don't clearly see the difference between both. Other than Items being a new Entity implementation interface breaking and using a different organization, I don't see the point of Entity in this context. Said in another way: what rule do you follow between using Entity and Items? Prefer Items until you understand what is the difference with Entity?
[*]Don't spend too much time writing your material system with your own shaders.[/list]
Ok, I will probably do this as last core features anyway, so not now.