tested this with the aframe component and direct troika build and example on
https://troika-examples.netlify.com/#text
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?
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.