RenderingDistance with MovableObjects (in a SCALED Node)

[edoardo]

Hi guys,

I've recently had a problem with RenderingDistance (with SCALEd Nodes), so I'm gonna clear my point and do a Request For Comments.

I don't agree with the policy to make the renderingDistance dependent from the MovableObject's SCALE (as it is now), I really think it should be simpler and just check if current distance from camera is lesser than renderingDistance (if it has been set - so if its value is greater than zero).

My point is that Ogre shouldn't consider MovableObject's SCALE, it should simply check the rendering Distance (code from beginning of MovableObject::_notifyCurrentCamera(Camera* cam), modified commenting out what is incorrect for me, i.e. SCALE infos):

Code: Select all

         mBeyondFarDistance = false;

         if (cam->getUseRenderingDistance() && mUpperDistance > 0)
         {
            //Real rad = getBoundingRadius();
            Real squaredDepth = mParentNode->getSquaredViewDepth(cam->getLodCamera());

            //const Vector3& scl = mParentNode->_getDerivedScale();
            //Real factor = std::max(std::max(scl.x, scl.y), scl.z);

            // Max distance to still render
            Real maxDist = mUpperDistance;// + rad * factor;
            if (squaredDepth > Math::Sqr(maxDist))
            {
               mBeyondFarDistance = true;
            }
         }

If there's a motivation (that's very probable), I'm sorry but I don't get it (I think that if I scale a MovableObject, I should know - at Application level - if I should update its renderingDistance to match the new scale, or if I'm happy with the original value, that should always be "absolute", i.e. pure distance not influenced by scale).

The renderingDistance check in Ogre should really be plain and simple, the Application should care about the Scale...
that's what I think, and I'll support my theory with a practical case that occurred to me, if you have the patience to read until the conclusions.


---------------------------------------------------------------------------------------------------------
PRACTICAL CASE STUDY
I've recently completed a 3D Label (about which you can read in this post), so only a quick recap: it consist of 2 MovableObjects (Entities) that encapsulates Meshes, one for the Text of the Label (textEntity) and one for the background panel (panelEntity).
With textEntity everything is fine because it ISN'T SCALED, but with panelEntity there are problems because it's a 1x1 unit quad (2 triangles) mesh created only once and then instantiated in each panelEntity of each 3D Label; it is then scaled (through its SceneNode) accordingly to match 3D Label's panel dimensions.

Here follows a couple of debug messages I've printed from my application when they disappear (further away from the wanted renderingDistance), and also a when they become visible (rendered) again.

Code: Select all

'3DLabel#1' is now BEYOND far distance! {if (squaredDepth > Math.Pow(maxDist,2)}
	[RenderingDistance: 1500,0| depth: 1812,36| radius: 35,4| factor: 50,0| maxDist: 1767,8| squaredDepth: 3284652,0| squaredMaxDist: 3125000,1]
'3DLabel#2' is now BEYOND far distance! {if (squaredDepth > Math.Pow(maxDist,2)}
	[RenderingDistance: 1500,0| depth: 3976,51| radius: 52,8| factor: 74,7| maxDist: 3944,4| squaredDepth: 15812660,0| squaredMaxDist: 15558284,8]

'3DLabel#2' is now NEARER than far distance!
	[RenderingDistance: 1500,0| depth: 3851,73| radius: 52,8| factor: 74,7| maxDist: 3944,4| squaredDepth: 14835850,0| squaredMaxDist: 15558284,8]
'3DLabel#1' is now NEARER than far distance!
	[RenderingDistance: 1500,0| depth: 1689,53| radius: 35,4| factor: 50,0| maxDist: 1767,8| squaredDepth: 2854517,0| squaredMaxDist: 3125000,1]

[Messages are printed from the main program that is written in C#, not C++; using Mogre - wrapping Ogre 1.7.1 DLL; commas are there because in Italy we use them to separate the decimal part, so the .NET CultureInfo prints them instead of dots]

As you can note, the desired RenderingDistance is 1500 (is it a bit small? Maybe, it depends on may aspects, but if I want that I should get it - as I do for textEntity that isn't scaled); now, the point is that (for "3DLabel#1") with a radius of 35 and a (scale) factor of 50 (the width of the 3D Label, thus the x scale of the panelEntity), their multiplication give us 1750.
But if I want the test to pass at 1500 World units, I should initially assign the RenderingDistance to 1500 (desired distance) - 1750 (radius * factor) = -250; the problem is that if I assign a NEGATIVE value to the RenderingDistance, it has the same effect to assign NOTHING and keep it zero (default value); as you can see from the Ogre code (you can find it at the beginning of MovableObject::_notifyCurrentCamera(Camera* cam)), it will be taken into account only if the mUpperDistance (assigned when you call setRenderingDistance()) is greater than zero!
|!| In this (my) case it's IMPOSSIBLE to assign to my panelEntity a RenderingDistance value that will cut it at 1500 units from the Camera, because of the current code of Ogre.

That's why I'm stating that Ogre shouldn't take the MovableObject's SCALE into account when checking for the maxDistance.
---------------------------------------------------------------------------------------------------------

If this isn't the right place, where should I state my point, I mean in what Forum, what Topic?
If you have understood, do you share my point of view about this argument?
|_ If yes, what's the procedure to prepare/propose a patch to the dev team?
|_ If not, can you explain to me why it's important to take the MovableObject's scale into account? And in that case, how can I possibly set my desired renderingDistance in my panelEntity?

Thanks a lot in advance to anyone for you reply!

[Klaim]

I'm not certain but I think I agree with you because it don't seem correct behaviour anyway.

Whatever the team advice, you can already submit a patch by following this procedure : http://www.ogre3d.org/developers/submit-patch
Also, you can clone the repository on bitbucket and let those who want it clone your modified version of Ogre there.

[edoardo]

Ok Klaim,

thanks for the reply and indications. I will clone the repository and dig a bit with the procedure in the next days, I hope to file a patch to the dev team very soon.

In the meanwhile, if anyone else would share his thoughts and reply to my statement like Klaim kindly did, you are very welcome!

Cheers

[edoardo]

Patch submitted with ID 3509348, you can see it in the Patch Tracking System.

Cheers

[Eugene]

Motivation is very simple.
Lets suppose your view distance is set to 100 meters, and you are on the surface of the small moon that was created as spherical mesh with radius 1 with applied scale of 200, i.e. your is 200 meters from its center. With current behavior your will see it under your feet, but with your patch it disappeared. Think also about disappearing castles when you are inside, but located more than view distance limit from castle origin point.

Therefore, original behavior is perfectly valid - we should test visibility of nearest point of object, and not it center.

This visibility test is intended to make rendering faster, therefore false positives are allowed, as it can be with long objects like a wall or your text label, where bounding sphere is much bigger than bounding box. Other visibility checks can be performed later by culling frustum, BSP or OctTree scene managers, but all of them can return false positive if computational efforts for more precise check are too high. Therefore, you should not rely on this check to hide your objects, remove them from scene instead.

[edoardo]

You almost convinced me, but I think my point is still valid: in the cases you have described, the Application (that uses Ogre) should care about the changed RenderingDistance because of the modified scale.

With my patch the check is even more efficient, as you said it's important, and I think it enforces the separation between Application logic and Ogre.

I understood the idea of the nearest point, but I still don't agree, beacause you (via the Application) should know that the moon is scaled and therefore you should increase its RenderingDistance value, that I still think should be referred to the center (pivot) of a MovableObject, and not to its nearest ("surface") point (that implies other calculations for the Scale and also produces false positives).

Please think about it and let me know what's your opinion...

[edoardo]

So, don't you agree? Are you the only one in charge to take the decision, Eugene? Have you asked somebody else for comments?

Thanks for the reply.

[Klaim]

I think (I m not in the team and Eugene either) that both cases are valid.

Sometimes you want LOD for graphical reasons.
Sometimes you want to use LOD for more applicatino-specific reasons, like google map changing even the size of symbols depending on the distance.
In games you can use LOD to draw symbols instead of 3D models (this is my case) then switch back to 3D models when you're near.

The thing is, the first one should focus on closest point of the graphic object, while the second one is more abstract and the center of the object might be a really bettter alternative (and helps when scaling by hand).

So I think both are good. Maybe it would be best to make it a choice of the user? Something like "distance calculation strategy" that would be one or the other?

[edoardo]

Yes, I agree with you Klaim, we can take "best of both worlds" and expose a choice to the user, maybe maintaining the current default behavior, but letting the user decide if he wants the "absolute distance" (for my case, I will choose that option).

Let's think about it, do you know how it is done elsewere, to maintain the code similar to other parts already done (I think like you suggested)?

Thanks for the help and sharing opinions!