<p>проблема с рендерингом troika-3d-text без ошибок</p>

Созданный на 6 нояб. 2019  ·  43Комментарии  ·  Источник: protectwise/troika

протестировал это с компонентом aframe и прямой сборкой тройки и примером на

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

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

Все 43 Комментарий

Гугл Хром | 78.0.3904.87 (официальная сборка) (64-разрядная версия)
линукс
JavaScript | В8 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)] АКТИВНО

я помню, если бы я нашел это в первый раз, когда это работает

поэтому я пробую более старую версию! и да, он работает с e600d2cd v0.12.0
Bildschirmfoto von 2019-11-06 22-00-02

хорошо, последняя рабочая версия
f4fcbb8d v0.12.1

v0.13.0 ломает рендеринг

Ой! Спасибо, что сообщили об этом и определили точную версию, в которой произошел сбой. Я просматриваю эти коммиты на наличие чего-либо очевидного, но я обеспокоен тем, что не смогу проверить исправление, если оно относится к вашему дистрибутиву Linux или драйверам графического процессора.

Пытаюсь догадаться... Видите ли вы в своем браузере летающие спагетти? https://troika-examples.netlify.com/#bezier3d

да это выглядит нормально

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

сделал небольшое видео проблемы, похоже, если рендер использовать только SDF (маленький размер), он работает

на окулус го работает нормально

ezgif com-video-to-gif

Черт, это разрушило мою догадку.

Это видео завораживает. Я могу назвать несколько причин такого поведения, но они также не должны были работать в версии 0.12.1. Будет продолжать искать...

Чтобы удостовериться, что мы не имеем дело с несколькими разными проблемами в разные периоды времени, не могли бы вы убедиться, что следующие сборки не работают одинаково?

да все терпят неудачу с тем же

Ну, на данный момент я в тупике на этом. Просматривая различия https://github.com/protectwise/troika/compare/v0.12.1...v0.13.0 , я не вижу разницы, которая должна вызывать такое поведение. Единственное изменение, которое должно повлиять на рендеринг текста, — это переключение на абстракцию createDerivedShader для манипулирования шейдером. Я сравнил выходные данные шейдера из этих двух версий построчно, и я не вижу никакой разницы во внедряемой логике, только небольшие различия в том, где она происходит (например, внутри функции glsl, а не в void main или в немного другом порядке). .) Я не понимаю, почему это может вызвать эту проблему, но я полагаю, что в этом конкретном драйвере OpenGL может быть ошибка/причуда, которую он может вызвать.

Не знаю, куда идти дальше, кроме как попробовать некоторые изменения, основанные на догадках, и протестировать их. Неспособность легко воспроизвести это - боль.

Хорошо, я понимаю, и да, я тоже думаю, что это больше проблема с драйвером opengl: / Один вывод: когда я масштабирую, я вижу видео шрифта ->
ezgif com-video-to-gif (1)

для справки здесь версии 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 (основной профиль) Mesa 19.2.2

LOL, это своего рода аккуратный эффект! 🤣

Любая идея, что я мог бы проверить?

@lojjic ура! нашел кое-что интересное, если я добавлю туман в сцену, это сработает!

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

с добавленным рамочным туманом со sceneEl.setAttribute("туман", "тип: линейный; далеко:300;цвет: 0xefd1b5");

Все любопытнее и любопытнее. Чекбокс "Туман" на странице примеров тройки тоже работает?

хм нет это ничего не меняет

да, это работает, если я устанавливаю MeshBasicMaterial и выбираю туман!

ОК, спасибо, что, возможно, дает мне ключ к дальнейшему расследованию.

Сегодня я попытаюсь найти время, чтобы отправить ветку с некоторыми попытками изолированных изменений и посмотреть, помогут ли какие-либо из них.

ОК, вот первая попытка - дайте мне знать, если нет изменений, изменений, но все еще с ошибками или исправлено: https://5dc9dc90ab55b5000a1db32c--troika-examples.netlify.com/#text

похоже очень хороший кадр! :>

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

нормальное использование с MeshStandard и MeshBasic Material выглядит исправленным для меня

только с Custom Shader Material глючит
Bildschirmfoto von 2019-11-11 23-42-22

это изменение исправило это для меня https://github.com/protectwise/troika/commit/85c71d6af2c1e09966c5e588745008dc4b923ae2

Замечательно! Мы куда-то движемся.

Можете ли вы попробовать это сейчас, пожалуйста: https://5dc9e7dcea3f6e00084d01a6--troika-examples.netlify.com/#text
Я пытаюсь изолировать одну из двух потенциальных основных причин с помощью этого.

хорошо, это работает правильно только с включенными MeshBasicMaterial и Fog

Так что это какая-то странная причуда с порядком исполнения. Единственная разница между этими двумя последними тестами заключалась в том, что присваивание идентификатора ( gl_FragColor = functionThatReturnsArg(gl_FragColor); ) происходило либо до, либо после логики пользовательского текстового шейдера. Если он приходит после того, как он работает, а если он приходит раньше, то он терпит неудачу (если только не включен туман, который добавляет дополнительные gl_FragColor.rgb = ... перед текстовой логикой, и это тоже работает, но только в MeshBasicMaterial. вздох .

Вот неприятный хак, который просто смотрит, если добавление gl_FragColor = gl_FragColor; в конце даст ему толчок: https://5dc9f0d8e82cdf00089f6b6c--troika-examples.netlify.com/#text

ок, то же самое с последним работает только с BasicMaterial и Fog on ...

Хорошо, еще несколько попыток для вас...

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

все три одинаково работают только с включенными BasicMaterial и Fog

Фу. Спасибо, что так терпеливо проверяли все мои дикие догадки. Это все еще не имеет для меня никакого смысла.

Проверяем еще одну гипотезу: https://5dcaea1c9bbf6e00074b3c7a--troika-examples.netlify.com/#text

np, это всегда ломается при выключенном тумане и всех материалах.

Не могли бы вы сделать еще несколько скриншотов из других примеров для меня, когда у вас будет время:

1) https://troika-examples.netlify.com/#arcs с выбранным шейдером "Double-Derived"
2) https://troika-examples.netlify.com/#ui
3) https://troika-examples.netlify.com/#bezier3d с ненулевым значением для опции "штрих"

В этих примерах используются те же методы, что и в шейдере текстовых фрагментов, поэтому я хочу посмотреть, есть ли что-то общее в их поведении.

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

Спасибо за скриншоты. Я ожидал, что по крайней мере один из них выйдет из строя аналогично тексту, поскольку они используют одну и ту же утилиту для модификации своего фрагментного шейдера. Но ни один из них не терпит неудачу. Так что, возможно, это что-то конкретное в тексте gsl. Думаю, я начну удалять/настраивать вещи одну за другой в текстовом glsl и смотреть, сможем ли мы сузить точный триггер.

Несколько попыток:
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 все 1. 2. и 3. работает со всеми материалами и с туманом и без него!

😮 Восхитительно!

ОК, последнее, что нужно проверить, и тогда у меня должно быть достаточно информации для окончательного исправления:
https://5dcc47d956b59f00070bea55--troika-examples.netlify.com/#text

И можете ли вы проверить, работает ли флажок «Тени», пожалуйста?

хм, не работает... странно :>
Bildschirmfoto von 2019-11-13 21-02-11
Bildschirmfoto von 2019-11-13 21-01-56
Bildschirmfoto von 2019-11-13 21-01-45

Это на самом деле хорошая новость! Это указывает на очень конкретное условное выражение, вызывающее проблему:

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

Похоже, что замена этого условного выражения discard заставила его начать работать. Что очень странно, потому что uTroikaSDFDebug — это униформа, поэтому в любом случае она всегда должна идти на else . Но по какой-то причине вашей системе это не нравится.

Поэтому я просто уберу условное. Я мог бы попытаться переформулировать его как DEFINE или что-то в этом роде, но в любом случае это не так уж полезно.

Я переделаю это в окончательное исправление на master, пусть вы еще раз это проверите, а затем опубликую новую версию и обновлю ее в компоненте aframe. Хотя это может занять день или два.

Освойте сборку для тестирования, когда у вас будет возможность: https://troika-examples.netlify.com/#text

да, это работает со всеми материалами и включенным/выключенным туманом!

@arpu Еще раз спасибо за ваше время и терпение, которые помогли мне разобраться с этой проблемой. Это исправление было опубликовано в версии 0.15.7.

Я также поднял aframe-troika-text до версии 0.1.2, которая использует фиксированную версию. Он также содержит исправления для ThreeJS r110, о которых вы упоминали ранее.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги

Смежные вопросы

lojjic picture lojjic  ·  11Комментарии

asbjornlystrup picture asbjornlystrup  ·  7Комментарии

drcmda picture drcmda  ·  11Комментарии

atlmtw picture atlmtw  ·  47Комментарии

Ocelyn picture Ocelyn  ·  13Комментарии