Polishing the 2.0 branch.

[Crashy]

Hi,

As a user of the Ogre 2.0 branch which is not really maintained any more, I'd like to refresh it a little bit, to have something more stable, clean and polished ( there is a lot of "dead code" in this branch)

Ogre 2.0 is right in the middle of 1.10 and 2.1 (you don't say ?), and is kinda bastard, as it takes from 2.x:

• The new scene manager design
• The new compositor system design

and from 1.x:

• Entities, materials, etc..
• Render systems & low level layers are really close, or at least have the same architecture.
• almost everything else in fact..

So here is my plan, in a few steps:

• Merge as much as possible the fixes Paroj did to the GL* Render systems in the Ogre 2.0 branch
• Same thing for the D3D11 Render system.
• Integrate the state cache manager in the GL3+ render system, already did it in my fork, I just need to take Paroj's improvements before. Maybe make a pull request in the default branch before.
• Eventually drop the GL1 & D3D9 Render systems.
• Test & fix all the samples if any error on Windows & Linux.
• If possible, merge the 2.1 fixes & enhancements that Dark Sylinc did to the shadow projection & compositor node back to the 2.0, as they are really interesting.
• If possible, strip all in place but unfinished HLMS code and merge the HLMS from the 1.10 (yes, not from the 2.1)

The question is now: how should I proceed ?

• Try to cherry pick commits from the default/2.1 branches and merge them into the 2.0 branch. That could be great but not always possible in case of interface changes. Tracking the right changesets isn't easy too.
• Manually look for changes in source and re-do the changes in the 2.0 branch. A little less difficult, and less prompt to generate errors, but we'll loose original changeset history.

I may do it in my forked repository and send atomic pull requests as much as possible, but before I start this big task, does anybody have objections/advices ?

Thanks.

[paroj]

you could also try merging 2.0 into 1.10 and see whether there are less merge conflicts.

generally I would recommend diffing the branches directly instead of tracking the commits. Based on the diffs you can then move the code that you want.
There are tools that can assist you here by showing incoming/ outgoing changes only. E.g. http://help.eclipse.org/luna/index.jsp? ... tion_State

[dark_sylinc]

[*]Eventually drop the GL1 & D3D9 Render systems.

I just wanted to point out last time I checked, the D3D9 RS was the best RenderSystem in Ogre 1.x and 2.0 (performance, stability, compatibility and quality wise); so dropping it would be suicidal.

Also beware of making 2.0 too different from 1.x and 2.1; otherwise it could become a useless Frankenstein.

1.10 is starting to diverge a lot from 2.x branches, and probably continue to diverge further. We welcomed paroj to the team because he stepped up to maintain Ogre 1.10, he gets shit done (a rare, valuable skill), and there is a need for users (mostly in simulation, VFX movie industry, scientific and medical uses) who still want the 1.x branch being maintained, who don't want to shake their existing codebases too much; and don't feel the need or have the resources/time to port to 2.1 (or they support legacy systems 2.1 no longer supports such as pre-SSE2 CPUs, 2002-era GPUs like GeForce 2/3/4/5000/6000/7000, S3 & Matrox cards, OpenGL 2.1 drivers, etc).
Users who are in existing Ogre 1.9 and older will find 2.0 a middle step for porting to 2.1

If you're not careful, you may end up putting yourself in the worst of both worlds: too different from 1.x to consider it "easy to port to", too different from 2.1 to consider it "a middle step", faster but not enough to consider it worthwhile, and without support for legacy systems (if you end up removing GL / D3D9).

What paroj said about incorporating some changes from 2.0 back to 1.10 may also worthwhile analyzing.

These are my 2 cents; I'm not in charge of 1.x development at all (paroj is) and I am barely maintaining 2.0 now; I'm just voicing my opinion and I just want to make sure we're all making sense with each other to avoid confusing our users.

[Crashy]

I totally agree with the desire to avoid a Frankenstein version. What I'd like to achieve is to have a 2.0 branch with the same features and interface as it has right now, but more polished, and with the HLMS fully implemented.

I don't want to diverge from the other active Ogre branches and take a new direction (in this case I wouldn't have write this post, but I'd have done it in my fork), just takes from the other branch the various improvements made to parts which are the most similar

When I say I'll take parts from the 1.10 and from the 2.0, its because, for instance, the GL3+ RS has evolved a lot both on the default & 2.1 branch, but not in the same way, due the major changes in the rendering pipeline of 2.1 branch, and it'll be easier to merge bugfixes and improvements from the 1.10

For the shadow compositor improvements, I've not looked at the code right now, but from what I've read it'll be mostly code located in shadow camera setups and compositor nodes, am I right ? In this case I don't see any reason not to merge it in the 2.0 branch.

Okay for the D3D9, I know it's the most efficient rendersystem in Ogre 1.x & 2.0, so I won't strip it.

As a conclusion, I really want to keep it as it is to my eyes: Mostly a 1.x (entites, materials, etc..), but faster (thanks to the scene manager redesign), and with the new compositor system.

[syedhs]

As a conclusion, I really want to keep it as it is to my eyes: Mostly a 1.x (entites, materials, etc..), but faster (thanks to the scene manager redesign), and with the new compositor system.

Yes I guess that is the gist, faster scene manager and new compositor system.

[Crashy]

Hi,
Time to update this post with some infos.

• I successfully merged some parts of the new 2.1 compositor shadow nodes to 2.0. It's now possible to use atlas shadow map.
• Using shadow atlas with PF_FLOAT32_R wastes a lot of vram, as it needs to create a depth buffer with the same size.
• So I've added the format PF_D32_FLOAT to use a depth texture without needing a separated depth buffer. (GL3+ only for now, need to add it to D3D11)
• To generate shadow maps for point lights, which may need a dedicated shadow casting material, I've added "point_light_shadow_caster_vertex_program_ref" & "point_light_shadow_caster_fragment_program_ref" directives to materials.

All of this is still in a WIP state, but I'm using it for a few weeks in my own projects with good results, and I'll surely need some advices for a few design points.
I'm working slowly, as I have very little time & a lot of other stuff to do


However, I've spot some memory leaks related to the way compositors manages textures.

I: potential garbage in texture manager/unreferenced textures
Very similar to this issue I've spot a few time ago : https://ogre3d.atlassian.net/projects/O ... openissues
When creating two workspace using the same nodes, local compositor texture names are identical, and the texture manager resource list is not reflecting the reality.
In some cases, it can lead to a leak, where texture is never freed when unused.
Suggested fix: tell the compositor node to use unique texture names in all cases. It has no side effect, as compositor texture references in materials are resolved using the texture definition name, not the real texture name.
Doing this, every texture is properly referenced & deleted.

II: Compositor textures referenced in unused materials.
Another case is when you create a compositor workspace, use it, then destroy it. As the quad pass material isn't cloned, destroying the compositor leaves the compositor material with a reference to the compositor texture.
Texture is never freed, as it's still referenced by the material, unless a new compositor pass using the same material is created.

Suggested fix: when destroying the compositor quad pass, set the texture unit state to a dummy texture (as it's invalid to set a null texture pointer to the texture unit state)
Safe as if the destroyed pass's texture is the one set to the material, it will release it, and if it's not the same (texture from another quad pass), it will be changed next time pass us used anyway.

[zxz]

However, I've spot some memory leaks related to the way compositors manages textures.

I: potential garbage in texture manager/unreferenced textures
Very similar to this issue I've spot a few time ago : https://ogre3d.atlassian.net/projects/O ... openissues
When creating two workspace using the same nodes, local compositor texture names are identical, and the texture manager resource list is not reflecting the reality.
In some cases, it can lead to a leak, where texture is never freed when unused.
Suggested fix: tell the compositor node to use unique texture names in all cases. It has no side effect, as compositor texture references in materials are resolved using the texture definition name, not the real texture name.
Doing this, every texture is properly referenced & deleted.

I have run into the very same issue myself. I discussed it briefly with dark_sylinc. His suggestion was the same as yours (forcing unique texture names), and I have been running with a local workaround forcing unique textures since then. I have also not seen any negative side effects.

[paroj]

depending on your performance requirements, going with 2.0 is maybe not worth it any more:
https://github.com/OGRECave/ogre/issues/440

[Crashy]

Wow, interesting.

However I've built my engine around the new compositor system, so going back to 1.10 is a no go

But it's nice to see how much the state cache for GL 3 is improving performances for this kind of scene.