Trying to fix transparency sorting

[mdias]

Hi

I have created this bug: https://ogre3d.atlassian.net/browse/OGRE-157

I went on to look at the source code on how to implement the "OM_SORT_FORCEORTHOGRAPHIC" feature I talk about on the bug report, however I am stuck at trying to figure out how should I ask the Renderables about the orthographic distance to the Camera.
Sure, I can think of something, like creating a new virtual method Renderable::getOrthographicViewDistance( const Plane& plane ), however I would like to ask the developers what do you think of this, and do you like my solution? What about automatically using this for orthographic cameras?

I wouldn't mind implementing this myself and sending the patch, if it gets the developers' aproval.

[bstone]

You could easily use render queue group priorities for the "orthographic" sort ordering similar to how overlays do that. Pretty simple.

[mdias]

Sorry, but no. It wouldn't always achieve the same result:
- Rotating the camera would invalidate the priorities set before
- Moving objects on their depth axis would invalidate the priorities set before
- Multiple render groups would become almost useless

And yes, I could manually recalculate all objects' priorities, but that's something Ogre is supposed to handle. Plus, it would limit object count to 65536 (priority is a ushort).

I'm not just looking for a workaround, I'm looking for a proper fix to the issue.

Something like this would be great: http://docs.unity3d.com/Documentation/S ... tMode.html

[bstone]

Yeah, you have a point but if 65535 objects is not enough for you then you'll most likely have to resort to instancing and that can screw your ordering once again even if you have proper orthographic sorting.

[Knotanalt]

Sorry, but no. It wouldn't always achieve the same result:
- Rotating the camera would invalidate the priorities set before
- Moving objects on their depth axis would invalidate the priorities set before
- Multiple render groups would become almost useless

And yes, I could manually recalculate all objects' priorities, but that's something Ogre is supposed to handle. Plus, it would limit object count to 65536 (priority is a ushort).

I'm not just looking for a workaround, I'm looking for a proper fix to the issue.

Something like this would be great: http://docs.unity3d.com/Documentation/S ... tMode.html

It shouldn't handle it when it's not needed, especially since you usually won't have everything be transparent (or often anything).

There's no need to make it a virtual method, though. All you need is a location to compare to. If you want to check the nearest point on the object, it's not gonna happen in real time except for very small numbers and you'll need to go to a real collisions/physics library.

[mdias]

It wouldn't handle that when it's not needed. What I'm purposing is the ability to configure the current transparency sorting algorithm, which already runs only when needed.

A 2D game is mostly comprised of sprites which will in most ocasions use alpha blending.

A game like Rayman Origins[1] will have it's world composed of thousands of sprites, which if not ortogonally sorted, will make the sprites jump forward and backward while the camera moves.
This should be optimized by batching the geometry in the correct order, yes, but let's forget about optimization for now.

I understand that I could replicate Rayman's look by having multiple groups and priorities and precalculate them at level load, but if we go that route, this could also be said for the current transparency sorting algorithm. IMO configuring the transparency sorting behavior to use orthogonal distance should be possible. Plus, precalculating it would make it impossible to rotate the camera or have 3D elements in the scene that change depth.

The method should be virtual for the same reason the current getSquaredViewDepth method is; each Renderable may implement it differently. For instance, SubEntity doesn't just measure the distance to the origin point. Plus, you don't have easy access to the Renderable's transform from just within the Renderable scope.

[1] http://www.rayman-fanpage.de/rayman_ori ... ns_010.jpg

[mdias]

I have posted a new possible solution to the bug tracker: https://ogre3d.atlassian.net/browse/OGRE-157

What do Ogre devs think? Would it be welcome in trunk?

[mdias]

Implemented it on https://bitbucket.org/mdias/ogre-orthotransparencysort

Tested and working: http://www.youtube.com/watch?v=RmLOMsHT7hM