Three.js: WebGL2рендерер

Очень хорошо. :) На самом деле я немного беспокоился о том, как справиться со сложностью WebGL 2 и 1.

Было бы здорово предпочесть использовать UBO. :) И мне нравится идея поддержки только BufferGeometry - это должно сильно упростить ситуацию.

Было бы здорово поддерживать в основном одни и те же шейдеры, если мы будем придерживаться прямого рендеринга (что, кажется, делает UE4 для скорости для VR). Я думаю, что мы, вероятно, сможем изменить это? Что вы думаете?

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

@mrdoob Хип-гип ура! И приятно слышать, что BufferGeometry будет использоваться исключительно. 👍

Я поддерживаю предложение @bhouston отдать предпочтение UBO.

Можно ли также более полно отделить освещение и обработку теней от рендерера? Значения по умолчанию очень удобны, но если вам нужен полный контроль над освещением и логикой теней, WebGLRenderer и др. такое ощущение, что они устроили драку.

И пока я перечисляю элементы типа списка желаний, можно ли сделать алгоритмы сортировки «подключаемыми»? У меня есть потребности в сортировке, которые выходят за рамки трех, и кажется излишне сложным переопределить функции сортировки в текущем WebGLRenderer . Возможно, это может быть необязательным параметром при создании объекта рендерера?

Я почти задаюсь вопросом, следует ли просто изменить WebGLRenderer 1 и удалить поддержку чего-либо, кроме объектов BufferGeometry. Это может быть более легкий путь вперед. Если есть простая функция для преобразования Geometry в BufferGeometry, которая заставляет людей вызывать...

Думаю, я говорю это, потому что беспокоюсь о попытках сохранить паритет функций между WebGLRenderer и WebGLRenderer2. Легче развивать одну кодовую базу, чем параллельно поддерживать две.

Я почти задаюсь вопросом, следует ли просто изменить WebGLRenderer 1 и удалить поддержку чего-либо, кроме объектов BufferGeometry. Это может быть более легкий путь вперед. Если есть простая функция для преобразования Geometry в BufferGeometry, которая заставляет людей вызывать...

Такая функция уже есть. Но не все ли так просто...

Я думаю, что лучше создать WebGLRenderer2 с нуля, чтобы мы могли пересмотреть API и поддерживаемые функции.

Firefox 51 теперь поддерживает WebGL 2: https://www.mozilla.org/en-US/firefox/51.0/releasenotes/

Не могу дождаться этого!

Выпущен Chrome 56 с поддержкой WebGL 2.0!
https://developers.google.com/web/updates/2017/01/nic56

Подходящее время, чтобы продвинуть WebGLRenderer2 вперед? XD

Должны ли мы также создать WebGLDeferredRenderer2?

Планирую начать изучать все это на следующей неделе! ✌️

Есть шанс, что у вас уже было время изучить его! Оооочень жду! (3D текстуры)

@мрдуб
Любые обновления?
Если у вас есть какие-то опасения, пожалуйста, поделитесь с нами!
Мы можем обсудить и помочь ;D

Еще не успел. Скоро скоро! 😇

https://blog.chromium.org/2017/03/faster-3d-rendering-with-webgl-20.html

Любые обновления? Меня особенно интересуют 3D-текстуры для объемного рендеринга некоторых медицинских изображений. Я также готов помочь сделать этот запрос на вытягивание успешным.

Текущая песочница three.js webgl2 не работает :( https://threejs.org/examples/webgl2_sandbox.html
Может быть проблема со сборкой версии three.js?

Если бы онлайн <script type="module"> уже был реализован...
https://groups.google.com/a/chromium.org/d/msg/blink-dev/uba6pMr-jec/tXdg6YYPBAAJ

По крайней мере, Mozilla работает над этим https://bugzilla.mozilla.org/show_bug.cgi?id=1240072.

@mrdoob Означает ли это, что мы можем ожидать, что Three.js API воспользуется преимуществами <script type="module"> при обновлении до WebGL 2.0? ;)

Кстати, я думаю, что сейчас проще всего просто добавить поддержку WebGL 2.0 в WebGLRenderer. Я думаю, что это позволит постепенное внедрение, и мы можем определить функции, чтобы увидеть, можем ли мы использовать функции WebGL 2. Я не думаю, что это самое сложное. Я знаю, что это приводит к некоторой сложности по сравнению с чистым средством визуализации WebGL 2, но это самый простой путь в краткосрочной и среднесрочной перспективе. И мы медленно развиваемся, и в конечном итоге мы оставляем позади WebGL 1, как только WebGL 2 будет принят где-то выше 90%.

Khronos только что провел вебинар на webgl2:
https://docs.google.com/presentation/d/11-mTDNmSJzJnRVGu9Vu6AUzOt34yV3PO7oqw4E5wc2o/edit#slide =id.gd15060520_0_38
Медиа скоро выйдет, но презентация в основном состояла из озвучки слайдов и связанных с ними демонстраций в слайдах.

Совершенно очевидно, что для этого требуется новый запуск, а не «обновление» существующего WebGLRenderer.

Что касается модулей es6, я думаю, что текущий подход к исходному коду — это модули es6, тогда использование объединения для пакета по-прежнему является способом поддержки «двойной сборки».

Я делал это уже неделю или около того, тестируя модули в Safari Tech Preview и пакет во всех браузерах. Действительно приводит к сборке/имению исходного дерева, а также текущего пакета. Однострочный накопительный пакет, который у вас есть в настоящее время, и копия исходного дерева для использования модуля.

@bhouston заманчиво...

Последний статус?

У меня какое-то смешанное чувство по этому поводу. Первоначально я думал о том же пути, который предложил @bhouston , постепенно добавляя функции webgl2 к текущему WebGLRenderer . Но это сделало бы средство визуализации более сложным и трудным для работы с функциями, которые больше всего различаются между двумя версиями, что привело бы к беспорядочному коду, полному ветвей и проверок условий.
Одним из вариантов может быть клонирование WebGLRenderer в качестве отправной точки для WebGL2Renderer и дальнейшее удаление/добавление функций без вмешательства в исходный рендерер.
Если мы взглянем на такие движки, как Playcanvas, который, вероятно, является одним из первых с поддержкой webgl2, мы увидим, что он даже не использует преимущества новых функций webgl2, таких как UBO или VAO, потому что это что-то, что изменит многие детали двигателя.

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

Поэтому я голосую за то, чтобы начать WebGL2Renderer с нуля, даже если мы будем работать медленно (у нас еще есть возможности для улучшения, пока webgl2 не получит почти 100% поддержку).

Некоторые файлы, помимо самого рендерера, должны быть изменены, например, текстуры, программы и т.д. Должны ли мы создать подпапку renderer\webgl2 и продолжать добавлять файлы, которые будут специально созданы для этого средства визуализации?

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

Есть новости о его разработке?

Еще нет. В этом месяце я отдавал приоритет WebVR.

Я попробовал быстрое и грязное преобразование на месте в язык шейдеров WebGL2 и ES3, как это было предложено @fernandojsg выше. Вот сжатый diff: https://github.com/tstanev/three.js/compare/master...tstanev :traian/webgl2 На самом деле все выглядит не так плохо, как я ожидал изначально. Похоже, что было бы неплохо поддерживать оба через некоторые стратегически расположенные ifdef.
[Изменить: обновлена ​​ссылка.]

@tstanev У вас есть рабочий пример?

Связанные примеры three.js в связанной ветке работают (как вы можете видеть в diff, я преобразовал те, для которых ранее требовались расширения). Вы можете клонировать репозиторий/ветку и запускать их локально.

@tstanev Как насчет сравнения производительности изменений webgl2 онлайн?) Было бы неплохо увидеть это. (три.js против трех.js на webgl2)

Привет
спасибо вам за эту лучшую идею.
Я хочу использовать webgl2renderer в своей программе, но я не мог использовать его в версии для предварительной компиляции (r86), поэтому я получаю исходный код и раскомментирую webgl2renderer в импорте three.js, а затем создаю его.
теперь мой код и ваш пример (webgl2-sandbox) будут работать без ошибок, но ничего не показывают

РЕДАКТИРОВАТЬ: я тестировал их в Firefox 54 и Chrome 60.
мой пример с использованием bufferGeometry и ShaderMaterial и будет корректно работать в webglrenderer

мне никто не ответит? в чем проблема webgl2renderer сейчас?

@ MHA15 , предположительно, не включен в сборку, потому что еще не готов к производству.

Привет, ребята, как продвигается разработка WebGL2Renderer?
Я знаю, что было принято решение воссоздать его с нуля. Но прошло много времени, и развитие этой темы идет медленно, так как воссоздание ее требует большого объема работы, я считаю.

На данный момент, можем ли мы пересмотреть возможность создания клона WebGLRenderer и заменить его на WebGL2, как это сделал @mattdesl в https://github.com/mrdoob/three.js/issues/8125 ?? Затем мы можем изменить средство визуализации на основе некоторых новых функций, таких как UBO, как сказал @fernandojsg . В конце концов, мы удалим все эти устаревшие коды webgl 1.

На мой взгляд, создание рендерера с нуля требует огромного количества работы, и в идеале его можно начать только с несколькими участниками. Этот разговор начался год назад. И если мы не дойдем до того, что у нас есть спаситель, который потратит несколько месяцев на полный рабочий день, создавая его с нуля, я полагаю, что в следующем году мы, вероятно, окажемся на той же странице.

На мой взгляд, создание рендерера с нуля требует огромного количества работы, и в идеале его можно начать только с несколькими участниками.

Что это правда. Но даже в этом случае, я думаю, это проще, чем усложнить поддержку WebGLRenderer , добавляя повсюду условные выражения. Я провел большую часть своих последних 5 лет, пытаясь сделать WebGLRenderer более легким для чтения и обслуживания.

Кроме того, я думаю, что @fernandojsg планировал попробовать это в ближайшие недели.

Это потрясающе. С нетерпением жду отличной работы от @fernandojsg!!

PS Должен сказать... Спасибо всем участникам этого проекта за расширение моего кругозора компьютерной графики. Надеюсь, что в будущем я смогу привести несколько примеров.

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

Пока мы в этом...
webgl2_sandbox снова работает (хотя требуются модули es6).

@mrdoob у вас есть приблизительная оценка, когда он будет доступен в основной версии / выпуске? :) Я счастлив, что это происходит! :)

@wdanilo Не совсем ... Какие функции WebGL2 вам нужны?

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

@mrdoob Новые ключевые слова, такие как flat в glsl, тоже были бы очень полезны.

Моему проекту нужны 3D текстуры.

Интересный...
Очень полезно знать, для каких конкретных случаев людям нужен WebGL 2.0.
Пусть они придут!

3D-текстуры также очень важны для нас. Я думаю, что мы также используем некоторые функции шейдеров.

Иногда я хочу МРТ

+1 также для нескольких целей рендеринга

Множественные цели рендеринга уже поддерживаются в WebGL1 через расширение, и для него даже есть PR в ThreeJS: https://github.com/mrdoob/three.js/pull/9358 ( демо ).

Я думаю, что мультисемпловые цели рендеринга — моя любимая функция. Большинство клиентов запрашивают постобработку (bloom, LUT и т. д.), но они разочарованы отсутствием надлежащего сглаживания после реализации постэффектов. С мишенями рендеринга MSAA мы, наконец, можем получить хорошо сглаженную и постобработанную сцену.

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

+1 за отзыв о розыгрыше. Или он уже поддерживается как расширение webgl1 в
три?

В четверг, 14 декабря 2017 г., в 21:45 Кайл уведомления[email protected] написал:

Я согласен. Обходные шейдеры для сглаживания на постобработанных сценах
с эффектами композитора недостаточно для настоящего сглаживания.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/mrdoob/three.js/issues/9965#issuecomment-351815640 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AHTX1RhYdGuTVSpmOy1ka-6gy1eslHQAks5tAXrFgaJpZM4Kj_9l
.

У меня есть пара вариантов использования:

1. Мне нужен MRT — в настоящее время я рендерю один и тот же шейдер 4 или 5 раз, меняя атрибут только для того, чтобы получить разные буферы.
2. Рендеринг в текстуру со сглаживанием для нас важная фича - делаем "редактор узлов" с предварительным просмотром визуализации. Каждая визуализация — это просто текстура, которую мы тоже рисуем, и отсутствие правильного сглаживания здесь не проблема.
3. Ключевое слово "flat" - сейчас я индексирую геометрию с атрибутом float, что явно неоптимально - хуже, чем индексирование с атрибутом uint. Я передаю этот атрибут из вершинного во фрагментный шейдер и не могу сейчас использовать uint, потому что у нас нет поддержки «плоского» kwrd.
4. (меньшие) 3D-текстуры отлично подходят для высококачественной визуализации, которую мы хотели бы поддерживать в ближайшем будущем.

Совместное использование сглаживания и постобработки является наиболее важным для меня.

@mrdoob Мои лучшие 3 функции / варианты использования WebGL 2 (в порядке важности):

1. Multisampled Render Targets: для правильного (MS)AA в постобработке.
2. Целочисленные текстуры: для выполнения алгоритмов на основе изображений, таких как поля расстояний со знаком, а также для использования более экзотических данных на основе текстур, таких как ЦМР (цифровые модели рельефа).
3. Transform Feedback: для создания систем частиц.

@mrdoob , кстати, вы знаете, почему # 9358 PR не был объединен? Как написал @mattalat , он обеспечивает многоцелевой рендеринг для threejs. Был зафиксирован 2 года назад, исправлялся несколько раз, чтобы быть в курсе других изменений и до сих пор его нет :(

Я спрашиваю об этом, потому что у меня есть сцена, в которой широко используются описания форм SDF. Каждая фигура выводит 6 разных выходных данных, так что теперь я вычисляю ее 6 раз, переходя к номерам шейдеров от 0 до 5. Было бы гораздо лучше использовать несколько выходных данных, и это даст просто 5-кратный прирост производительности.

@wdanilo Вероятно, это было неподходящее время (в то время в рендерере было много движущихся вещей). Кроме того, похоже, что он включал сборки, которые легко вызывают конфликты. Есть желающие сделать новый пиар?

/cc @edankwan

Нам нужны 3D-текстуры и цели Multisample Render.

Я хочу использовать его, поэтому я могу установить depthTexture.type = THREE.FloatType.. если нет другого способа сделать это в настоящее время.

Есть ли надежда, что LineThickness, отличная от 1, будет работать в Windows и WebGL 2.0? Если да, это улучшит некоторые из наших результатов.

И вот я отвечаю сам себе. Прочитав о толщине линий с использованием трехстрочного базового материала на SO , я понял, что толстым линиям в любом случае понадобится геометрия в будущем.

@Richard004 Ричард004 Это не имеет ничего общего с WebGL 2. У нас уже есть PR для этого запроса функции, см. # 11349 👍

Привет @mrdoob и @Mugen87
Мне нужны битовые манипуляции внутри фрагментного шейдера, а также индексация динамического массива. Первый, вероятно, не очень распространен, но мне он все равно нужен, потому что я пытаюсь перенести ядро ​​CUDA на WebGL (GLSL), а другие языки шейдеров позволяют манипулировать битами, а WebGL 1.0 (GLSL) — нет.

Второй, я думаю, может быть полезен многим разработчикам: доступ к элементу массива с помощью переменной. В настоящее время в WebGL 1.0 (GLSL) такая программа не работает:

int myData[200];
int x = 3; // 'x' might change later based on my lookup needs
int requestedData = myData[x];

Однако в WebGL 2.0 вы можете это сделать. Это часто необходимо внутри цикла, где вам нужно получить разные значения из массива, но вы не можете просто выполнить итеративный цикл (например, от 0 до 199 в приведенном выше примере), потому что тогда вам нужно будет проверить каждое отдельное значение. элемент, и это очень медленно.

Сглаживание в постобработке определенно было бы полезно.

Под всем этим вопрос: не пора ли новой архитектуре для Тройки?

Недавно я начал использовать D3 версии 4. Это был полный редизайн. Es6
модули. И что гораздо важнее, 30 модулей, каждый из которых был самостоятельным.
репо. Я действительно рекомендую взглянуть на архитектуру D3.

Я не говорю, что нам это нужно для Третьего, но я думаю, что мы могли бы рассмотреть
бамп основной версии. Частично из-за webgl2. Но и из-за необходимости
подмодули.

Пример: существует репозиторий/подмодуль "выборки" D3. это твой основной
модуль jQuery DOM, но со всей многословностью DOM, скрытой в
функциональный, цепной дизайн. Его можно использовать как есть, не используя остальные
Д3.

Разве вам не понравились бы три независимых модуля, которые сделали весь webgl
многословие исчезнет? Возможно, даже несколько подмодулей для webgl ctx/shader.
управление, управление буфером и так далее. Действительно, геометрия буфера
много такого. То же самое для создания шейдера из частей.

Просто мысль.

@fetox74 Почти уверен, что вы уже можете делать AA https://threejs.org/examples/?q=fxaa#webgl_postprocessing_fxaa

@elunty FXAAShader не дает достаточно хорошего результата по сравнению с оригинальным сглаживанием, я использовал его в дикой природе.

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

@pailhead Связанный #8705 :wink:

С нетерпением ждем встроенной поддержки EXT_shader_texture_lod .
Это может устранить артефакты, генерируемые при использовании MeshStandardMaterial и MeshPhysicalMaterial на большинстве устройств Android, а также MS Edge и Internet Explorer.

@mrdoob Есть ли у вас или вашей команды планы по обновлению Threejs до Webgl 2.0? Эта ветка занимает буквально годы и ничего особо не меняется, в то время как все остальные фреймворки уже продвинулись вперед. Скоро мне придется принять трудное решение, нам, вероятно, придется мигрировать через Вавилон или что-то в этом роде, и я бы очень хотел остаться с Третьим. Сделаю, если будут какие-то, хоть какие-то планы по его модернизации.

@wdanilo , если WebGL 2.0 является приоритетом для вашего проекта, я бы порекомендовал вам перейти на Babylon. Я знаю, что некоторые участники three.js планируют работать над этим, но я лично сосредоточен на WebVR и рабочих процессах художников (поддержка svg и т. д.).

@mrdoob Я очень ценю ваш быстрый ответ здесь. Я бы очень хотел не отказываться от three.js. Мне нравится, как библиотека устроена под капотом, и ее предположения о том, что это «общая» структура, а не «ориентированная на игру» и т. Д. В любом случае, спасибо за информацию и ясность.

(Еще раз спасибо @takahirox , я знал об этой теме). Я только что сделал запрос на включение # 13692. Я понимаю, что фокус не на этом, но для наших целей он работает хорошо.

Связанный # 13702

Я сделал базовую ветку WebGL2 после #9965 и #12250.

Репо: https://github.com/takahirox/three.js/tree/WebGL2Base
Примеры: https://rawgit.com/takahirox/three.js/WebGL2Base/examples/index.html .

Вы можете запустить WebGL2.0 + Three.js с ним.

(Извините за конфликт с работой @yoshikiohshima )

@mrdoob Можем ли мы создать ветку для WebGL2Renderer, например, three.js/dev-2.0? Или мы можем объединить его в dev, хотя между webgl1 и webgl2 все еще много дублированных кодов?

Я новичок в прошлой разработке по этому вопросу. @takahirox , можете ли вы обобщить стратегию, которую вы используете, и то, что поддерживается https://github.com/takahirox/three.js/tree/WebGL2Base? (и еще раз извините за мое невежество), но я не видел необходимости в большом количестве дублированного кода для поддержки WebGL2. Какие проблемы?

@mrdoob Можем ли мы создать ветку для WebGL2Renderer, например, three.js/dev-2.0? Или мы можем объединить его в dev, хотя между webgl1 и webgl2 все еще много дублированных кодов?

Не знаю, зачем для этого нужна новая ветка. Зачем дублировать код?

Вроде никаких конфликтов. Сейчас есть два требования к WebGL2.0.

1. Создание WebGL2Renderer для поддержки всех функций WebGL2.0 и хорошая оптимизация
2. Добавление поддержки webgl2 к существующим WebGLRenderer . Но мы не полностью поддерживаем функции WebGL2.0 и не оптимизируем для WebGL2.0, потому что не хотим, чтобы рендерер запутался. Так что в основном это только для раннего доступа к Three.js + WebGL2.0 + GLSL3.0

Мой для 1. Его работа для 2. У нас нет дублированного кода и не нужно создавать новую ветку для 2.

@takahirox Я думаю, что было бы лучше пока работать в той же ветке.

Если вы улучшите...

https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGL2Renderer.js

а примеры webgl2 импортируют классы напрямую (без сборки)...

https://github.com/mrdoob/three.js/blob/dev/examples/webgl2_sandbox.html#L39 -L47

не должно быть конфликтов.

Вы можете пока забыть мою WebGL2Base, потому что кажется, что мы начинаем поддержку WebGL2.0 в один WebGLRenderer .

Мы все еще думаем о реализации WebGL2Renderer?
В последнее время я много искал, чтобы добавить поддержку WebGL2, и я жду изменений takahirox, чтобы перебазировать мой. Но после внесения некоторых изменений я начал думать, что переписать рендерер было бы действительно хорошей идеей, как и объект WebGLTextures. Если еще актуально, буду рад поучаствовать.

Я думаю, что да. Я думаю, что добавление базовой поддержки webgl 2.0 к текущему WebGLRenderer просто для того, чтобы иметь что-то, пока мы работаем над WebGL2Renderer .

Не стесняйтесь начинать переписывать рендерер и присылать PR (в идеале пошагово).

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

Интересно, можно ли использовать webgl2 в его текущем состоянии в Three.js? (даже если просто рендерить простые сетки буферной геометрии) Будет ли EffectComposer работать с рендерером с поддержкой контекста webgl2? Нужно ли как-то корректировать цель рендеринга?

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

Похоже, в конце концов мы просто добавили функции WebGL 2.0 в WebGLRenderer .
Однако WebGPU наверняка понадобится WebGPURenderer .