Before the incoming merge...

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


Post Reply
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Before the incoming merge...

Post by Klaim »

I am organizing the work to switch to Ogre 2.0 and I think I don't use much Ogre features (for now - I'm not focusing on graphics yet) so it should be smooth.
However I just wanted to know if the changes which are currently non-public are interface breaking a lot or not.?
I need to estimate if it's worth switching to Ogre 2.0 before these changes are merged or once they are made public.
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: Before the incoming merge...

Post by Transporter »

https://bitbucket.org/sinbad/ogre/src/c ... dt?at=v2-0

There are a lot of changes. For example you have to setup the compositor system instead of a viewport. The result is really good, except of using a multi core target: https://ogre3d.atlassian.net/browse/OGRE-458
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Before the incoming merge...

Post by Kojack »

I believe he means if the currently private version of 2.0 that matias has is interface breaking to the public 2.0 that we already have.
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: Before the incoming merge...

Post by Transporter »

Kojack wrote:I believe he means if the currently private version of 2.0 that matias has is interface breaking to the public 2.0 that we already have.
Ahh, ok. I think there will be a couple of changes after the comunity preview, when DX9 will be dropped.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Before the incoming merge...

Post by dark_sylinc »

I think he means the HLMS branch.

The answer is yes and no. Sometimes the thing is not that it is broken, but rather "no longer the best approach".

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.
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.
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.
Also, take in mind Items will use the new Skeleton interface, while Entities are most likely going to keep the old one.

So, bottom line; if you're just starting up, and want to ease your porting in the future to 2.0 Final; follow the next guidelines:
  1. 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.
  2. 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.
  3. Don't spend too much time writing your material system with your own shaders.
I already used practices in 1 and 2 in Ogre 1.8 to allow my code to toggle between InstanceManager's InstancedEntity and Entities, so you just add Items to the mix.
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Before the incoming merge...

Post by Klaim »

Kojack wrote:I believe he means if the currently private version of 2.0 that matias has is interface breaking to the public 2.0 that we already have.
Yes exactly, sorry if I wasn't clear.
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Before the incoming merge...

Post by Klaim »

Thank you very much for these info dark_sylinc.
dark_sylinc wrote: 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.
  1. 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.
Ok
[*]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.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Before the incoming merge...

Post by dark_sylinc »

Klaim wrote: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?
Something internal to Ogre.
Basically, both v1 and v2 objects are added to the RenderQueue and calculate a hash for sorting the batches.
v1 objects must be done from one thread because neither _updateRenderQueue nor getRenderOperation guarantee thread safety. v2 objects can be processed in parallel.
Basically, it's one more step that can be done in parallel.
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
Certain features haven't been ported yet and may take a long time.
For example pose animations. If you want pose animations, you'll have to use an Entity.
Particle Effects and billboards haven't been ported either. They're v1 objects. They can use the HLMS, and can benefit from auto instancing, but don't enjoy all the benefits v2 objects do.
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Before the incoming merge...

Post by Klaim »

I see, so it's still a goal to make Item the new Entity in the end...but "maybe" because it's not certain yet.

Thanks for these precisions!
Post Reply