[2.1] Make depth-bias a field of Item rather than MacroBlock Topic is solved

[hyyou]

Fact 1: I love to set depth bias per Ogre::Item with a custom value like this :-

Code: Select all

item->setDepthBias(5.0f); 
item->setDepthBias(2.3f);
.... other 30 unique values for my own satisfaction ....
 

Fact 2: Ogre 2.1 love to set depthBias with pointer of MacroBlock like this :-

Code: Select all

datablock->setMacroblock(macroblockPointer); 

Conclusion: I have to create at least 30*(other-combination) unique macro blocks.
I think it is not so good for performance. More important, it looks dirty.

IMHO, depthBias should be a field of Ogre::Item, not MacroBlock.
I may miss a good reason that depthBias resides in MacroBlock, though. :)

[dark_sylinc]

I'm afraid that is not up to us.

Conclusion: I have to create at least 30*(other-combination) unique macro blocks.
I think it is not so good for performance. More important, it looks dirty.

If we were to make it the way you propose (per Item), performance would still be bad, because under the hood APIs and GPUs don't like having the depth bias changing that often(*).
By making it part of Macroblock, we make it more evident that it is slow.

(*)Some GPUs have no problem, some do (but still the API works that way, so the CPU cycles will be consumed)

Also please beware depth bias is not well defined. While most GPU vendors seem now to agree how depth bias works now; there is not a clear definition of what unit of measure depth bias is; thus making rendering inconsistent between GPUs. It was exposed because "a little bias" tends to workaround Z-fighting. Depth Slope Bias is clearly defined though and thus doesn't have this problem.

[hyyou]

I am sorry. I misunderstand.
I thought that the depth-bias is a value that interfere/hack Ogre's depth sort algorithm.
(e.g sort as if an Ogre::Item moved toward camera by X unit)

I have never known that GPU has such feature.
Thank for detailed explanation. XD

[dark_sylinc]

I see. That is... not entirely a bad idea.
You do have some sort of similar control if you call Renderable::setRenderQueueSubGroup (but subGroup must be between 0 and 7, inclusive) but your idea may be more flexible.

[hyyou]

Without touching Ogre code, I have just implemented it by setting offset-ed transformation to sceneNode.
Then in my custom HLMS, I used the original transformation for rendering.

The design of HLMS is very flexible! I praise HLMS again. (Are you the one who design it?)

The only limitation I saw is that each camera need different vector3d offset.
Thus, 1 Ogre::Item can appear only on <= 1 Ogre::Camera.

I am not sure whether Ogre has a callback virtual function like this :-

Code: Select all

virtual std::vector<Ogre::Item*> callback(std::vector<Ogre::Item*> items, Ogre::Camera* camera);

Thank.