[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: 154
Joined: Wed Feb 03, 2016 2:24 am
x 2

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

Post by hyyou » Sun Mar 04, 2018 5:38 am

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
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1104
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 45

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

Post by al2950 » Sun Mar 04, 2018 2:21 pm

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.
1 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3706
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 121
Contact:

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

Post by dark_sylinc » Sun Mar 04, 2018 11:58 pm

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.
1 x

hyyou
Gremlin
Posts: 154
Joined: Wed Feb 03, 2016 2:24 am
x 2

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

Post by hyyou » Mon Mar 05, 2018 4:22 am

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.
0 x

hyyou
Gremlin
Posts: 154
Joined: Wed Feb 03, 2016 2:24 am
x 2

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

Post by hyyou » Tue Mar 13, 2018 6:00 am

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. :(
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3706
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 121
Contact:

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

Post by dark_sylinc » 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.
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.
1 x

hyyou
Gremlin
Posts: 154
Joined: Wed Feb 03, 2016 2:24 am
x 2

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

Post by hyyou » Thu Mar 15, 2018 3:29 am

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...
0 x

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 » Thu Mar 15, 2018 11:53 am

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.
0 x

hyyou
Gremlin
Posts: 154
Joined: Wed Feb 03, 2016 2:24 am
x 2

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

Post by hyyou » Thu Mar 15, 2018 1:37 pm

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.
0 x

Post Reply