<p>troika-3d-text render problem sans erreur</p>

Créé le 6 nov. 2019  ·  43Commentaires  ·  Source: protectwise/troika

testé cela avec le composant aframe et la construction directe de la troïka et l'exemple sur

https://troika-examples.netlify.com/#text

Bildschirmfoto von 2019-11-06 21-33-50
Bildschirmfoto von 2019-11-06 21-33-34

Tous les 43 commentaires

GoogleChrome | 78.0.3904.87 (version officielle) (64 bits)
Linux
JavaScript | V8 7.8.279.19

FOURNISSEUR = 0x1002 [X.Org], APPAREIL= 0x67ef [Graphiques AMD Radeon (TM) RX 460 (POLARIS11, DRM 3.33.0, 5.3.7-301.fc31.x86_64, LLVM 9.0.0)] ACTIF

je me souviens si j'ai trouvé ça la première fois ça marche

donc j'essaie une version plus ancienne! et oui ça marche avec e600d2cd v0.12.0
Bildschirmfoto von 2019-11-06 22-00-02

ok la dernière version de travail est
f4fcbb8d v0.12.1

v0.13.0 casse le rendu

Aïe ! Merci de l'avoir signalé et d'avoir précisé la version exacte où il s'est cassé. Je vais examiner ces commits pour tout ce qui est évident, mais je crains de ne pas pouvoir vérifier un correctif s'il est spécifique à votre distribution Linux ou à vos pilotes GPU.

Essayer de travailler une intuition... Dans votre navigateur voyez-vous les spaghettis volants ici ? https://troika-examples.netlify.com/#bezier3d

oui ça a l'air bien

Bildschirmfoto von 2019-11-07 11-58-41

fait une petite vidéo du problème, on dirait que si le rendu n'utilise que SDF (petite taille) cela fonctionne

sur oculus go ça marche bien

ezgif com-video-to-gif

Dang, ça a cassé mon intuition.

Cette vidéo est fascinante. Je peux penser à quelques raisons pour lesquelles un comportement pourrait se produire, mais celles-ci auraient également dû échouer dans la version 0.12.1. Va continuer à chercher...

Pour vous assurer que nous ne traitons pas plusieurs problèmes différents au fil du temps, pourriez-vous vérifier que les versions suivantes échouent toutes de la même manière ?

oui tous échouent avec le même

Eh bien pour le moment je suis perplexe sur celui-ci. En parcourant le https://github.com/protectwise/troika/compare/v0.12.1...v0.13.0 diff, je ne vois pas de différence qui devrait provoquer ce comportement. Le seul changement qui devrait affecter le rendu du texte est le passage à l'abstraction createDerivedShader pour la manipulation du shader. J'ai comparé la sortie du shader de ces 2 versions ligne par ligne et il n'y a aucune différence dans la logique injectée que je peux voir, juste de légères différences dans l'endroit où cela se produit (par exemple dans une fonction glsl plutôt que dans void main ou dans un ordre légèrement différent .) Je ne vois pas pourquoi cela causerait ce problème, mais je suppose qu'il est possible qu'il y ait un bogue/une bizarrerie dans ce pilote OpenGL particulier qu'il puisse déclencher.

Vous ne savez pas où aller à partir d'ici, à part essayer des changements basés sur des intuitions et vous les faire tester. Ne pas pouvoir reproduire facilement cela est une douleur.

OK, je comprends, et oui je pense aussi que c'est plus un problème de pilote opengl :/ Une constatation est que lorsque je redimensionne, je vois la vidéo de la police ->
ezgif com-video-to-gif (1)

pour référence ici les versions opengl
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 (profil de base) Mesa 19.2.2

LOL c'est une sorte d'effet soigné! 🤣

une idée de ce que je pourrais tester ?

@lojjic wuha ! trouvé quelque chose d'intéressant si j'ajoute un brouillard à la scène ça marche!

Bildschirmfoto von 2019-11-11 11-54-36

avec ajout d'un brouillard aframe avec sceneEl.setAttribute("fog", "type: linear; far:300;color: 0xefd1b5");

De plus en plus curieux. La case à cocher "Brouillard" sur la page des exemples de troïka fonctionne-t-elle également alors ?

hum non ça ne change rien

ha oui ça marche si je mets MeshBasicMaterial et sélectionne le Fog!

OK merci ça me donne peut-être une piste pour approfondir.

Je vais essayer de trouver un peu de temps plus tard dans la journée pour pousser une branche avec quelques tentatives de modifications isolées, et voir si l'une de ces aides.

OK, voici la première tentative - faites-moi savoir s'il n'y a pas de changement, un changement mais toujours bogué ou corrigé : https://5dc9dc90ab55b5000a1db32c--troika-examples.netlify.com/#text

ça a l'air d'être un très bon coup ! :>

Bildschirmfoto von 2019-11-11 23-40-48

l'utilisation normale avec MeshStandard et MeshBasic Material me semble fixe

seulement avec Custom Shader Material est bogué
Bildschirmfoto von 2019-11-11 23-42-22

C'est génial! Nous arrivons quelque part.

Pouvez-vous essayer celui-ci maintenant s'il vous plaît : https://5dc9e7dcea3f6e00084d01a6--troika-examples.netlify.com/#text
J'essaie d'isoler l'une des deux causes profondes potentielles avec celle-ci.

ok cela ne fonctionne correctement qu'avec MeshBasicMaterial et Fog activés

C'est donc une bizarrerie étrange avec l'ordre d'exécution. La seule différence entre ces 2 derniers tests était ce qui équivaut à une attribution d'identité ( gl_FragColor = functionThatReturnsArg(gl_FragColor); ) se produisant après ou avant la logique de shader de texte personnalisé. S'il vient après que cela fonctionne, et s'il vient avant, il échoue (à moins que le brouillard ne soit activé, ce qui ajoute un gl_FragColor.rgb = ... supplémentaire avant la logique du texte, et cela fonctionne aussi mais uniquement dans MeshBasicMaterial. soupir .

Voici un vilain hack juste pour voir si l'ajout d'un gl_FragColor = gl_FragColor; à la fin lui donne un coup de pied : https://5dc9f0d8e82cdf00089f6b6c--troika-examples.netlify.com/#text

ok pareil avec le dernier ne fonctionne qu'avec BasicMaterial et Fog on...

OK, encore quelques essais pour vous...

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

tous les trois identiques ne fonctionnent qu'avec BasicMaterial et Fog activés

Pouah. Merci d'avoir été si patient pour tester toutes mes suppositions folles. Cela n'a toujours aucun sens pour moi.

Tester encore une autre hypothèse : https://5dcaea1c9bbf6e00074b3c7a--troika-examples.netlify.com/#text

np, cela rompt toujours avec le brouillard et tous les matériaux

Pourriez-vous s'il vous plaît prendre quelques captures d'écran supplémentaires d'autres exemples pour moi quand vous aurez un moment:

1) https://troika-examples.netlify.com/#arcs avec le shader "Double-Derived" sélectionné
2) https://troika-examples.netlify.com/#ui
3) https://troika-examples.netlify.com/#bezier3d avec une valeur non nulle pour l'option "dashed"

Ces exemples utilisent des techniques similaires à celles du shader de fragment de texte, donc je veux voir s'il y a des points communs dans leur comportement.

Bildschirmfoto von 2019-11-13 14-49-48
Bildschirmfoto von 2019-11-13 14-49-18
Bildschirmfoto von 2019-11-13 14-49-02

Merci pour les captures d'écran. Je m'attendais à ce qu'au moins l'un d'entre eux échoue de la même manière que le texte, car ils utilisent exactement le même utilitaire pour modifier leur fragment shader. Mais aucun d'entre eux n'échoue. Alors peut-être que c'est quelque chose de spécifique dans le texte glsl. Je suppose que je vais commencer à supprimer/modifier les éléments un par un dans le texte glsl et voir si nous pouvons peut-être affiner le déclencheur exact.

Quelques essais :
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 tout 1. 2. et 3. fonctionne avec tout matériel et avec et sans brouillard !

😮 Incroyable !

OK une dernière chose à vérifier et ensuite je devrais avoir assez d'infos pour un correctif final :
https://5dcc47d956b59f00070bea55--troika-examples.netlify.com/#text

Et pouvez-vous vérifier que la case à cocher Ombres fonctionne également, s'il vous plaît ?

hmm ça ne marche pas... étrange :>
Bildschirmfoto von 2019-11-13 21-02-11
Bildschirmfoto von 2019-11-13 21-01-56
Bildschirmfoto von 2019-11-13 21-01-45

C'est effectivement une bonne nouvelle ! Il indique une condition très spécifique comme étant à l'origine du problème :

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

Il semble que le remplacement de cette condition par seulement discard est ce qui l'a fait commencer à fonctionner. Ce qui est très bizarre, parce que uTroikaSDFDebug est un uniforme donc il devrait toujours aller au else toute façon. Mais pour une raison quelconque, votre système n'aime pas cela.

Je vais donc supprimer le conditionnel. Je pourrais essayer de le reformuler en tant que DEFINE ou quelque chose comme ça, mais ce n'est pas très utile de toute façon.

Je vais travailler cela dans un correctif final sur master, vous demander de le vérifier une fois de plus, puis de publier une nouvelle version et de la mettre à jour dans le composant aframe. Peut prendre un jour ou deux cependant.

Version principale à tester, lorsque vous en aurez l'occasion : https://troika-examples.netlify.com/#text

oui, cela fonctionne avec tous les matériaux et le brouillard activé/désactivé !

@arpu Merci encore pour votre temps et votre patience pour m'aider à trouver ce problème. Ce correctif a été publié dans la version 0.15.7.

J'ai également déplacé aframe-troika-text vers la version 0.1.2 qui utilise la version corrigée. Il contient également des correctifs pour ThreeJS r110 que vous avez mentionnés précédemment.

Cette page vous a été utile?
0 / 5 - 0 notes