протестировал это с компонентом aframe и прямой сборкой тройки и примером на
https://troika-examples.netlify.com/#text
Гугл Хром | 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
хорошо, последняя рабочая версия
f4fcbb8d v0.12.1
v0.13.0 ломает рендеринг
Ой! Спасибо, что сообщили об этом и определили точную версию, в которой произошел сбой. Я просматриваю эти коммиты на наличие чего-либо очевидного, но я обеспокоен тем, что не смогу проверить исправление, если оно относится к вашему дистрибутиву Linux или драйверам графического процессора.
Пытаюсь догадаться... Видите ли вы в своем браузере летающие спагетти? https://troika-examples.netlify.com/#bezier3d
да это выглядит нормально
сделал небольшое видео проблемы, похоже, если рендер использовать только SDF (маленький размер), он работает
на окулус го работает нормально
Черт, это разрушило мою догадку.
Это видео завораживает. Я могу назвать несколько причин такого поведения, но они также не должны были работать в версии 0.12.1. Будет продолжать искать...
Чтобы удостовериться, что мы не имеем дело с несколькими разными проблемами в разные периоды времени, не могли бы вы убедиться, что следующие сборки не работают одинаково?
да все терпят неудачу с тем же
Ну, на данный момент я в тупике на этом. Просматривая различия https://github.com/protectwise/troika/compare/v0.12.1...v0.13.0 , я не вижу разницы, которая должна вызывать такое поведение. Единственное изменение, которое должно повлиять на рендеринг текста, — это переключение на абстракцию createDerivedShader
для манипулирования шейдером. Я сравнил выходные данные шейдера из этих двух версий построчно, и я не вижу никакой разницы во внедряемой логике, только небольшие различия в том, где она происходит (например, внутри функции glsl, а не в void main или в немного другом порядке). .) Я не понимаю, почему это может вызвать эту проблему, но я полагаю, что в этом конкретном драйвере OpenGL может быть ошибка/причуда, которую он может вызвать.
Не знаю, куда идти дальше, кроме как попробовать некоторые изменения, основанные на догадках, и протестировать их. Неспособность легко воспроизвести это - боль.
Хорошо, я понимаю, и да, я тоже думаю, что это больше проблема с драйвером opengl: / Один вывод: когда я масштабирую, я вижу видео шрифта ->
для справки здесь версии 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 ура! нашел кое-что интересное, если я добавлю туман в сцену, это сработает!
с добавленным рамочным туманом со sceneEl.setAttribute("туман", "тип: линейный; далеко:300;цвет: 0xefd1b5");
Все любопытнее и любопытнее. Чекбокс "Туман" на странице примеров тройки тоже работает?
хм нет это ничего не меняет
да, это работает, если я устанавливаю MeshBasicMaterial и выбираю туман!
ОК, спасибо, что, возможно, дает мне ключ к дальнейшему расследованию.
Сегодня я попытаюсь найти время, чтобы отправить ветку с некоторыми попытками изолированных изменений и посмотреть, помогут ли какие-либо из них.
ОК, вот первая попытка - дайте мне знать, если нет изменений, изменений, но все еще с ошибками или исправлено: https://5dc9dc90ab55b5000a1db32c--troika-examples.netlify.com/#text
похоже очень хороший кадр! :>
нормальное использование с MeshStandard и MeshBasic Material выглядит исправленным для меня
только с Custom Shader Material глючит
это изменение исправило это для меня 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 с ненулевым значением для опции "штрих"
В этих примерах используются те же методы, что и в шейдере текстовых фрагментов, поэтому я хочу посмотреть, есть ли что-то общее в их поведении.
Спасибо за скриншоты. Я ожидал, что по крайней мере один из них выйдет из строя аналогично тексту, поскольку они используют одну и ту же утилиту для модификации своего фрагментного шейдера. Но ни один из них не терпит неудачу. Так что, возможно, это что-то конкретное в тексте 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
И можете ли вы проверить, работает ли флажок «Тени», пожалуйста?
хм, не работает... странно :>
Это на самом деле хорошая новость! Это указывает на очень конкретное условное выражение, вызывающее проблему:
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, о которых вы упоминали ранее.