troika-3d-text render problem without error

Google Chrome | 78.0.3904.87 (Offizieller Build) (64-Bit)
Linux
JavaScript | V8 7.8.279.19

VENDOR = 0x1002 [X.Org], DEVICE= 0x67ef [AMD Radeon (TM) RX 460 Graphics (POLARIS11, DRM 3.33.0, 5.3.7-301.fc31.x86_64, LLVM 9.0.0)] ACTIVE

i remember if i found this at first time it works

so i try some older version! and yes its works with e600d2cd v0.12.0

ok last working version is
f4fcbb8d v0.12.1

v0.13.0 breaks the rendering

Yikes! Thanks for reporting this, and for narrowing down the exact version where it broke. I'll look through those commits for anything obvious but I'm concerned I won't be able to verify a fix if it's specific to your Linux distro or GPU drivers.

Trying to work a hunch... In your browser do you see the flying spaghetti here? https://troika-examples.netlify.com/#bezier3d

yes this looks fine

made a small video of the problem, looks like if the rendere only use SDF ( small size) it works

on oculus go it works fine

Dang, that busted my hunch.

That video is fascinating. I can think of a few reasons that behavior could occur, but those should have also failed in 0.12.1. Will keep looking...

To make sure we're not dealing with multiple different issues across time, could you verify the following builds all fail in the same way?

• https://5d558de9c4cf7557986a02c7--troika-examples.netlify.com/#text (v0.14.1)
• https://5d57371a2d6a70000806fcc3--troika-examples.netlify.com/#text (v0.15.0)
• https://5d5ec24a45f45f00089451cc--troika-examples.netlify.com/#text (v0.15.1)

yes all fail with the same

Well for the moment I'm stumped on this one. Going through the https://github.com/protectwise/troika/compare/v0.12.1...v0.13.0 diff, I'm not seeing a difference that should cause this behavior. The only change there that should affect text rendering is the switch to the createDerivedShader abstraction for the shader manipulation. I've compared the shader output from those 2 versions line by line and there's no difference in the injected logic that I can see, just slight differences in where it occurs (e.g. within a glsl function rather than in void main or in slightly different order.) I don't see why that would cause this issue but I suppose it's possible there's a bug/quirk in that particular OpenGL driver that it may trigger.

Not sure where to go from here other than trying out some changes based on hunches and having you test them. Not being able to readily reproduce this is a pain.

OK, i understand, and yes i think too this is more a opengl driver problem:/ One finding is when i scale i see the font video ->

for reference here a the opengl versions
GL_VENDOR X.Org GL_RENDERER AMD Radeon (TM) RX 460 Graphics (POLARIS11, DRM 3.33.0, 5.3.8-300.fc31.x86_64, LLVM 9.0.0) GL_VERSION 4.5 (Core Profile) Mesa 19.2.2

LOL that's kind of a neat effect! 🤣

any idea what i could test?

@lojjic wuha! found something interesting if i add a fog to the scene it works!

with added aframe fog with sceneEl.setAttribute("fog", "type: linear; far:300;color: 0xefd1b5");

Curiouser and curiouser. Does the "Fog" checkbox on the troika examples page also work then?

hmm no this does not change anything

ha yes it works if i set MeshBasicMaterial and select the Fog!

OK thanks that maybe gives me a clue to investigate further.

I'm going to try to find some time later today to push a branch with some attempts at isolated changes, and see if any of those help.

OK here's the first attempt - let me know if there's no change, a change but still buggy, or fixed: https://5dc9dc90ab55b5000a1db32c--troika-examples.netlify.com/#text

looks like a very good shot! :>

normal usage with MeshStandard and MeshBasic Material looks fixed for me

only with Custom Shader Material is buggy

this change fixed it for me https://github.com/protectwise/troika/commit/85c71d6af2c1e09966c5e588745008dc4b923ae2

That's great! We're getting somewhere.

Can you try this one now please: https://5dc9e7dcea3f6e00084d01a6--troika-examples.netlify.com/#text
I'm trying to isolate one of two potential root causes with this one.

ok this only works correct with MeshBasicMaterial and Fog enabled

So it's some weird quirk with the order of execution. The only difference between those last 2 tests was what amounts to an identity assignment (gl_FragColor = functionThatReturnsArg(gl_FragColor);) happening either after or before the custom text shader logic. If it comes after it works, and if it comes before then it fails (unless the fog is enabled, which adds an extra gl_FragColor.rgb = ... before the text logic, and that works too but only in MeshBasicMaterial. sigh.

Here's a nasty hack just seeing if adding a gl_FragColor = gl_FragColor; at the end gives it a kick: https://5dc9f0d8e82cdf00089f6b6c--troika-examples.netlify.com/#text

ok same with the last only works with BasicMaterial and Fog on ...

OK a few more tries for you...

1) https://5dcadbdfa8565d0008ff1af5--troika-examples.netlify.com/#text
2) https://5dcadfaac107620008043289--troika-examples.netlify.com/#text
3) https://5dcae02c8de52400077b3a8b--troika-examples.netlify.com/#text

all three the same only works with BasicMaterial and Fog enabled

Ugh. Thank you for being so patient with testing all my wild guesses. This is still making no sense to me.

Testing yet another hypothesis: https://5dcaea1c9bbf6e00074b3c7a--troika-examples.netlify.com/#text

np, this always breaks with fog on off and all Materials

Could you please grab a few more screenshots from other examples for me when you get a moment:

1) https://troika-examples.netlify.com/#arcs with the "Double-Derived" shader selected
2) https://troika-examples.netlify.com/#ui
3) https://troika-examples.netlify.com/#bezier3d with a nonzero value for the "dashed" option

These examples use similar techniques as the text fragment shader so I want to see if there's commonality in their behavior.

Thanks for the screenshots. I was expecting at least one of them to fail in a similar way to the text, since they use the same exact utility for modifying their fragment shader. But none of them fail. So maybe it's something specific in the text glsl. I guess I'll start removing/tweaking things one by one in the text glsl and see if we can maybe narrow down the exact trigger.

A few tries:
1) https://5dcc2b581b644200098d5e75--troika-examples.netlify.com/#text
2) https://5dcc302d78835c00089437e2--troika-examples.netlify.com/#text
3) https://5dcc31b70765f2000991ad0f--troika-examples.netlify.com/#text

ok all 1. 2. and 3. works with all material and with and without fog!

😮 Amazing!

OK one last thing to check and then I should have enough info for a final fix:
https://5dcc47d956b59f00070bea55--troika-examples.netlify.com/#text

And can you verify the Shadows checkbox works too please?

hmm this does not work ... strange :>

That's actually good news! It points to a very specific conditional as causing the problem:

if (uTroikaSDFDebug) {
    gl_FragColor *= 0.5;
  } else {
    discard;
  }

It looks like replacing that conditional with just discard is what made it start working. Which is very weird, because uTroikaSDFDebug is a uniform so it should always go go the else anyway. But for some reason your system doesn't like that.

So I'll just remove the conditional. I could try to reformulate it as a DEFINE or something but it's not all that useful anyway.

I'll work this up into a final fix on master, have you verify that one more time, and then publish a new version and update it in the aframe component. May take a day or two though.

Master build to test, when you get a chance: https://troika-examples.netlify.com/#text

yes this works with all Materials and fog on/off!

@arpu Thank you once again for your time and patience in helping me track down this issue. This fix has been published in 0.15.7.

I have also bumped aframe-troika-text to version 0.1.2 which uses the fixed version. It also contains fixes for ThreeJS r110 which you had mentioned before.