[2.1] orthographic camera : depth-sort impacted by X-axis too much Topic is solved

Problems building or running the engine, queries about how to use features etc.
Post Reply
hyyou
Gremlin
Posts: 173
Joined: Wed Feb 03, 2016 2:24 am
x 17
Contact:

[2.1] orthographic camera : depth-sort impacted by X-axis too much

Post by hyyou »

My custom HLMS tends to call fillBuffersFor() for the more-right Item AFTER the more-near Item.
The z-position of Ogre::Item impacts the rendering order only a little. (noticeable only when the x value of 2 items are very near each other.)

Image
^ Blue is always closer to camera.
Both objects appear around lower-left corner of the window.

Below is my set-up (pseudo-code).

Code: Select all

Green position = (150,150,-10)
Blue position = ( move 100 to 200 ,100,0)  
Both Ogre::Item are :-
- setMacroblock( ... mDepthWrite=false );
- setBlendblock( ... setBlendType(Ogre::SBT_TRANSPARENT_ALPHA) );
Here is the camera :-

Code: Select all

position.z = 200
orientation = identity
setNearClipDistance(150); setFarClipDistance(500);
setFixedYawAxis(false);
setProjectionType(Ogre::PT_ORTHOGRAPHIC);
The problem seems to occur only for orthographic camera.
I think my code may have bug.
Question: Which Ogre files should I look for debugging? Where is the depth-sort algorithm in Ogre?

(Sometimes, the glitch is solved when position of camera is close to the scene.)

Related topic : viewtopic.php?t=77462 .
Less related topic : viewtopic.php?t=79536, viewtopic.php?t=56279
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: [2.1] orthographic camera : depth-sort impacted by X-axis too much

Post by al2950 »

The sorting algorithms happen within the RenderQueue, they are a little complicated due to the way Ogre will order opaque objects to try and improve performance. However transparent objects should always be rendered back to front.

Each render queue can have differet modes though, its worth checking out RenderQueue::setSortRenderQueue

The stable sort render queue may help you.
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: [2.1] orthographic camera : depth-sort impacted by X-axis too much

Post by dark_sylinc »

Is there a quick modified sample I can test? (i.e. take Tutorial02_VariableFramerate and make a quick repro there)

I've been wanting to take a look again at our render order.

Possible suspects:
  • quantizedDepth is wrong in RenderQueue::addRenderable
  • transparent not being true
  • The value "depth" (obtained from pMovableObject->getCachedDistanceToCamera()) is wrong. Compare if getCachedDistanceToCameraAsReal makes sense
  • Nothing is wrong, and you're just being a victim of our "rough" depth sorting. The depth sorting is approximate. If the objects are too close together, for Ogre it's the same as if they're in the same Z position. We only devote 15 bits for depth sorting.
hyyou
Gremlin
Posts: 173
Joined: Wed Feb 03, 2016 2:24 am
x 17
Contact:

Re: [2.1] orthographic camera : depth-sort impacted by X-axis too much

Post by hyyou »

Thank al2950 and dark_sylinc!
I will look into the "RenderQueue::setSortRenderQueue".
dark_sylinc wrote: Sun Mar 04, 2018 11:58 pm We only devote 15 bits for depth sorting
I never knew about it (I thought 32). It can explain some (if not all) cases of the glitch.
dark_sylinc wrote: Sun Mar 04, 2018 11:58 pm Is there a quick modified sample I can test?
I would love to, but I modified my environment too much, so the official demo crashes. (from SDL, resource_d.cfg)
If I may find that it is Ogre's glitch/flaw or any Ogre concern, I will create the repro. Thank.
hyyou
Gremlin
Posts: 173
Joined: Wed Feb 03, 2016 2:24 am
x 17
Contact:

Re: [2.1] orthographic camera : depth-sort impacted by X-axis too much

Post by hyyou »

dark_sylinc wrote: Sun Mar 04, 2018 11:58 pm quantizedDepth is wrong in RenderQueue::addRenderable
Thank. Finally, I found the cause.
Let's say I have an orthographic camera that have direction = -z as default.
I have 2 transparent Ogre::Item, a = green, b = blue. Their shape is a 2D plane with Z-normal.
Image
From the image, b (blue) should be rendered before a (green).

Due to Ogre's algorithm in Ogre::MovableObject::cullFrustum (i.e. OgreMovableObject.cpp):-

Code: Select all

*distanceToCamera = cameraPos.distance( objData.mWorldAabb->mCenter ) - *worldRadius;
Assume worldRadius is equal , the difference boil down to the term :-

Code: Select all

da OR db = cameraPos.distance( objData.mWorldAabb->mCenter ) 
In this situation, absolute distance between Ogre::Item and Ogre::Camera (da > db) suggests that a is behind b.
Thus Ogre think that a should be rendered before b.

I think the formula is counter-intuitive in 2 aspects :-
  • 1. For Ortho-camera, Ogre should sort by Z (i.e. vector-dot with direction of camera), not Euclidean distance.
    This can be workarounded by moving orthographic camera very-far from the scene.
    It was also requested in a very old post Sort by depth and not by distance + naming difficulties.
  • 2. Ogre should not concern about scale of Ogre::Item. I suggest to remove the term worldRadius (?).
    With current design, just scaling b up / down make b appear more-front / more-back!
    It is good for sphere-like shape, but bad for billboard-like.
    I can't find any pretty workaround for it without changing Ogre's code. :(
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: [2.1] orthographic camera : depth-sort impacted by X-axis too much

Post by dark_sylinc »

Hi! Thanks for the detailed report,
hyyou wrote: Tue Mar 13, 2018 6:00 am I think the formula is counter-intuitive in 2 aspects :-
  • 1. For Ortho-camera, Ogre should sort by Z (i.e. vector-dot with direction of camera), not Euclidean distance.
    This can be workarounded by moving orthographic camera very-far from the scene.
    It was also requested in a very old post Sort by depth and not by distance + naming difficulties.
[/list]
It affects projection cameras too! Therefore I've pushed the fix. There is no doubt euclidean distance is wrong, as we only use that calculation for depth sorting.
hyyou wrote: Tue Mar 13, 2018 6:00 am
  • 2. Ogre should not concern about scale of Ogre::Item. I suggest to remove the term worldRadius (?).
    With current design, just scaling b up / down make b appear more-front / more-back!
    It is good for sphere-like shape, but bad for billboard-like.
    I can't find any pretty workaround for it without changing Ogre's code. :(
That is harder to consider. "It depends", as you said, objects with volume (cubes, sphere, complex shapes) do need their radius to be affected by world scale. Even if the object is thin, it may be viewed from any angle.
But billboards always facing towards the camera reorient themselves and have no depth thus considering scale into the radius makes no sense and can harm.

Ultimately the problem is that these are approximations to "more or less render transparents ok". True sorting would have to occur per pixel (or per triangle, and split intersecting triangles).

I'm trying to think of ideas this could be toggled per Item (i.e. "ignore scale flag") but I can't think of a method that does not waste 4 bytes per Item (I'm trying to see if we can avoid penalizing everyone for a corner case); unless you're ok with adding a macro flag:

Code: Select all

#if OGRE_CONSIDER_SCALE_WORLD_RADIUS
    *worldRadius = (*localRadius) * parentScale.getMaxComponent();
#else
    *worldRadius = (*localRadius);
#endif
Thus tweakable with global granularity while avoiding penalizing everyone.

I'm open to suggestions.
hyyou
Gremlin
Posts: 173
Joined: Wed Feb 03, 2016 2:24 am
x 17
Contact:

Re: [2.1] orthographic camera : depth-sort impacted by X-axis too much

Post by hyyou »

Yea! Thank for the fix!

Yes, I don't like macro.
I think it is more of a render-protocol than Ogre::item's attribute.
Make it camera's attribute may be fine (granular) enough.

To avoid significant cost for most users, here are some ways I guess. Top=I like it more :-
  • 1. Create an option to let the strange user do the depth-sort himself.
    I also fancy to use it for sorting decal e.g. :-

    Code: Select all

    class Ogre::DepthSortCallback {  
        virtual std::vector<Ogre::Item*> setSortCallback(std::vector<Ogre::Item*>);
        //"Ogre::ObjectData"  might be more suitable than Ogre::Item*.  
    };   
    ogreCameraPtr->setDepthSortCallback(Ogre::DepthSortCallback* userCustomCallback);
  • 2. Create a flag per camera :-

    Code: Select all

    camera->setIgnoreObjectScale(bool)
    //Need to appraise whether it is compatible with the existing Ogre architecture
  • 3. Create a global static flag :-

    Code: Select all

    sceneMgr->setIgnoreObjectScale(bool);  //desperate 
  • 4. Do nothing e.g. let user hack it himself.
    I will always pass scale = 0.0000001f to ogre, and pass the correct scale using a custom HLMS.
    Frustum culling may become wrong near border of the camera view, though.
There might be some better ways...
QuestOfDreams
Gnoblar
Posts: 6
Joined: Fri Nov 11, 2016 5:56 pm
Location: Austria
x 1

Re: [2.1] orthographic camera : depth-sort impacted by X-axis too much

Post by QuestOfDreams »

dark_sylinc wrote: Wed Mar 14, 2018 9:04 pm Hi! Thanks for the detailed report,
hyyou wrote: Tue Mar 13, 2018 6:00 am I think the formula is counter-intuitive in 2 aspects :-
  • 1. For Ortho-camera, Ogre should sort by Z (i.e. vector-dot with direction of camera), not Euclidean distance.
    This can be workarounded by moving orthographic camera very-far from the scene.
    It was also requested in a very old post Sort by depth and not by distance + naming difficulties.
[/list]
It affects projection cameras too! Therefore I've pushed the fix. There is no doubt euclidean distance is wrong, as we only use that calculation for depth sorting.
Objection! This method only gives better results in the illustrated case, i.e. if the objects are more or less aligned with the projection plane. Imagine the same scene with the objects rotated such that they are facing the camera. Then the right part of the green object may actually be behind the left part of the blue object. The point is, that there's no general method to sort arbitrary extended objects properly by just comparing their centers (you yourself are calling it 'rough depth sorting'). That's why there are methods such as order independent transparency.
hyyou
Gremlin
Posts: 173
Joined: Wed Feb 03, 2016 2:24 am
x 17
Contact:

Re: [2.1] orthographic camera : depth-sort impacted by X-axis too much

Post by hyyou »

QuestOfDreams wrote: Thu Mar 15, 2018 11:53 am Objection! This method only gives better results in the illustrated case, ...
Thank for your point of view. XD

I will defense!

Are you talking about orthographic camera?
It is the case that the position of camera is presumably very far away.

In most case, the new behavior is more correct than before.
It is possible to prove by gradually rotate (e.g. 1 deg) the green and the blue and check how many times each technique win.

Here is a very rough prove (45 deg step, total 180 degree = 4 step).
Victory point of new approach vs old approach = 2 : 1. (another 1 is draw)
Image
It is just a sample. The real prove should use rotate both objects randomly + random object, and test a lot of times.
In every permutation, I think the thrend is obvious.
User avatar
TaaTT4
OGRE Contributor
OGRE Contributor
Posts: 267
Joined: Wed Apr 23, 2014 3:49 pm
Location: Bologna, Italy
x 75
Contact:

Re: [2.1] orthographic camera : depth-sort impacted by X-axis too much

Post by TaaTT4 »

Hey hyyou, did you choose the approach without the worldRadius multiplication at the end? Do you have any empirical results about it? I have the same feeling as you that this approach would be superior in the mayority of situations (and especially in my scenario where artists break transparent meshes into planes and every item has uniform scale), but I'd like to have a feedback before proceeding further.

Senior programmer at 505 Games; former senior engine programmer at Sandbox Games
Worked on: Racecraft EsportRacecraft Coin-Op, Victory: The Age of Racing

User avatar
TaaTT4
OGRE Contributor
OGRE Contributor
Posts: 267
Joined: Wed Apr 23, 2014 3:49 pm
Location: Bologna, Italy
x 75
Contact:

Re: [2.1] orthographic camera : depth-sort impacted by X-axis too much

Post by TaaTT4 »

dark_sylinc wrote: Wed Mar 14, 2018 9:04 pm
hyyou wrote: Tue Mar 13, 2018 6:00 am I think the formula is counter-intuitive in 2 aspects :-
  • 1. For Ortho-camera, Ogre should sort by Z (i.e. vector-dot with direction of camera), not Euclidean distance.
    This can be workarounded by moving orthographic camera very-far from the scene.
    It was also requested in a very old post Sort by depth and not by distance + naming difficulties.
[/list]
It affects projection cameras too! Therefore I've pushed the fix. There is no doubt euclidean distance is wrong, as we only use that calculation for depth sorting.
I'm not totally agree with this. Sorting by Z instead of euclidean distance causes the following behaviour (look at the top of the railing):
Image
As soon as the bounding sphere center of the railing "goes behind" the camera (dot product is negative), the stained glass window goes in front. Breaking the railing mesh in tiny meshes can alleviate the issue, but the problem persists. And, in my opinion, this kind of artifact (that can pop in and out continuously) is a way more bad than a wrong sorting (but consistent at least) order.

I believe we're all agree that transparency sorting is a classic "too-short-blanket-problem". In consideration of this, I believe that forcing users to adhere to one solution or another isn't the best approach. In fact, other engines (see UE4 and Unity) let users to choose between different sorting strategies.

So, my proposition is to create a set of functors that calculate the distance to the camera in different ways (Z, euclidean, with or without taking in account bounding sphere radius, etc.). Then, some get/set methods to let the user choose among these different sorting strategies per-camera (could be a fair trade off between per-item vs per-scene manager). The use of functors shouldn't affect cache-misses here and could also open the way (in a future) to let users provide custom distance calculation formulas.

Senior programmer at 505 Games; former senior engine programmer at Sandbox Games
Worked on: Racecraft EsportRacecraft Coin-Op, Victory: The Age of Racing

User avatar
TaaTT4
OGRE Contributor
OGRE Contributor
Posts: 267
Joined: Wed Apr 23, 2014 3:49 pm
Location: Bologna, Italy
x 75
Contact:

Re: [2.1] orthographic camera : depth-sort impacted by X-axis too much

Post by TaaTT4 »

TaaTT4 wrote: Wed Dec 23, 2020 11:29 am So, my proposition is to create a set of functors that calculate the distance to the camera in different ways (Z, euclidean, with or without taking in account bounding sphere radius, etc.). Then, some get/set methods to let the user choose among these different sorting strategies per-camera (could be a fair trade off between per-item vs per-scene manager). The use of functors shouldn't affect cache-misses here and could also open the way (in a future) to let users provide custom distance calculation formulas.
Feel free to contribute/express your thoughts about the following PR.

Senior programmer at 505 Games; former senior engine programmer at Sandbox Games
Worked on: Racecraft EsportRacecraft Coin-Op, Victory: The Age of Racing

Post Reply