Hi,
when using the dx11 text node, I have problems when using depth.
The frontmost text is occluded by the text in the back.
Apparently text is just rendered using the order of the slices.
I suppose this is not the intended behaviour… Did I perhaps miss something?
Patch attached. The problem also occurs with the “text advanced” node.
Tested with 33.3 and 33.7 x64
Cheers Elio
dx11-text-depth-bug.v4p (12.1 kB)
use blend renderstate with text mode
and ur picture is correct, since layer rendering is working on reverse.
eg. ur green text get’s overwritten by purple text…
easy fix would be to transform ur text on Z
you need to open the DX11 renderer in the Inspektor and set the depthbuffer type in the config pin before you can use the Enable Depth Buffer pin.
Thanks for your help guys,
the depth buffer in the renderer had already been configured (that’s why I checked if the quads’ depth order works).
The blend mode “Text Default” helps to bring the correct order (also selecting any other blend mode helps). But then I start to get alpha artifacts as seen in the first image on the right.
To fix this “Alpha to coverage” helps to make the edges smooth (second image on the right).
But when using small scale text, this turns out to bring new artifacts that make it unreadable (third image on the right) - especially when compared to the depthbuffer-less constellation on the left.
Any ideas?
anyone?.. no text …
Hey Elio,
try changing the scale of the text with the size pin on the Text node instead of using a Scale transform.
I need to position the text in 3d. I cannot change the size to simulate distance. This would break the depth order once again.
And then when animating it, font-size of the text node creates even more artifacts because it only works integer-wise.
Does anyone have a clue why for dx11-text the depth order does not work by default and why rendering differs so much when using blend modes???
I just want to understand…
since dx11 is quite big, the text node was made “fast” mode
it still works ok if u maintain size of the font depending on resolution(not saying about other crap)
but basically this text node is an microsoft implementation, that why bugs there…
;) thanks for the info.
Knowing this I’ll stay with my workaround to dynamically change the order of spreads depending on the proximity to the camera (using the “Sort” node).
This works best for me regarding quality.
Since text is using discard, and uses alpha, you have the common issue with alpha + depth buffer, which are not big friends indeed.
Nothing to do with whatever microsoft implementation since they did not write that
For alpha sprites best way to render is indeed back to front sorting if you need the best quality.
Another option is text as geometry, but of course can (depending on case), become more expensive.