Three.js: Procesador WebGL2

Muy agradable. :) De hecho, estaba un poco preocupado sobre cómo manejar la complejidad de WebGL 2 y 1.

Sería genial preferir usar UBO. :) Y me encanta la idea de solo admitir BufferGeometry, eso debería simplificar enormemente las cosas.

Sin embargo, sería genial admitir la mayoría de los mismos sombreadores si nos mantenemos con el renderizado directo (que parece ser lo que UE4 está haciendo para la velocidad de la realidad virtual). Creo que probablemente podamos cambiar eso. ¿Qué piensas?

Supongo que me gustaría mantener la compatibilidad con sombreadores para que, si WebGL2 no está disponible, podamos recurrir a algo que se vea similar, solo que más lento.

@mrdoob Hip hip hurra! Y es bueno saber que BufferGeometry se usará exclusivamente. 👍

Secundo la sugerencia de @bhouston de preferir UBO.

¿Sería posible también desacoplar más completamente la iluminación y el manejo de sombras del renderizador? Los valores predeterminados son realmente útiles, pero cuando desea un control completo sobre la lógica de iluminación y sombras, WebGLRenderer y compañía. sienten que dieron pelea.

Y mientras estoy enumerando elementos de tipo lista de deseos, ¿podrían ordenarse los algoritmos 'conectables'? Tengo necesidades de clasificación que están fuera del alcance de tres, y parece innecesariamente difícil anular las funciones de clasificación en el WebGLRenderer actual. ¿Quizás esta podría ser una configuración opcional al crear el objeto renderizador?

Casi me pregunto si uno debería simplemente modificar WebGLRenderer 1 y eliminar el soporte para cualquier cosa que no sean objetos BufferGeometry. Esa puede ser una manera más fácil de avanzar. Si hay una función simple para convertir Geometry a BufferGeometry que obliga a la gente a llamar...

Supongo que digo esto porque me preocupa tratar de mantener la paridad de características entre WebGLRenderer y WebGLRenderer2. Es más fácil desarrollar una sola base de código que mantener dos en paralelo.

Casi me pregunto si uno debería simplemente modificar WebGLRenderer 1 y eliminar el soporte para cualquier cosa que no sean objetos BufferGeometry. Esa puede ser una manera más fácil de avanzar. Si hay una función simple para convertir Geometry a BufferGeometry que obliga a la gente a llamar...

Ya existe una función como esa. Pero no es tan simple...

Creo que es mejor crear WebGLRenderer2 desde cero para que podamos reconsiderar la API y las funciones admitidas.

Firefox 51 ahora es compatible con WebGL 2: https://www.mozilla.org/en-US/firefox/51.0/releasenotes/

¡No puedo esperar por esto!

¡Se lanzó Chrome 56 compatible con WebGL 2.0!
https://developers.google.com/web/updates/2017/01/nic56

¿Es buen momento para avanzar WebGLRenderer2 ? XDD

¿Deberíamos crear también un WebGLDeferredRenderer2?

¡Planeando comenzar a investigar todo esto la próxima semana! ✌️

¡Cualquier posibilidad de que ya hayas tenido algo de tiempo para investigarlo! ¡Muuuuuchas ganas de hacerlo! (texturas 3D)

@mrdoob
¿Alguna actualización?
Si tiene alguna inquietud, ¡compártala con nosotros!
Podemos discutir y ayudar ;D

Aún no he tenido tiempo. ¡Pronto pronto! 😇

https://blog.chromium.org/2017/03/rendering-3d-más-rápido-con-webgl-20.html

¿Alguna actualización? Estoy especialmente interesado en las texturas 3D para el renderizado de volumen de algunas imágenes médicas. También estoy dispuesto a ayudar a que esta solicitud de extracción tenga éxito.

El sandbox webgl2 de three.js actual no funciona :( https://threejs.org/examples/webgl2_sandbox.html
¿Podría ser un problema de compilación de la versión three.js?

Si en línea <script type="module"> ya se hubiera implementado...
https://groups.google.com/a/chromium.org/d/msg/blink-dev/uba6pMr-jec/tXdg6YYPBAAJ

Al menos Mozilla está trabajando en ello https://bugzilla.mozilla.org/show_bug.cgi?id=1240072

@mrdoob , ¿significa esto que podemos esperar que la API Three.js aproveche <script type="module"> cuando se actualice a WebGL 2.0? ;)

Por cierto, creo que es más fácil mientras tanto simplemente agregar soporte WebGL 2.0 a WebGLRenderer. Creo que esto permitiría una adopción incremental y podemos hacer una detección de funciones para ver si podemos usar las funciones de WebGL 2. No creo que sea lo más difícil de hacer. Sé que genera un poco de complejidad en comparación con un renderizador WebGL 2 puro, pero es el camino más fácil a corto y mediano plazo. Y evolucionamos lentamente donde finalmente dejamos atrás WebGL 1 una vez que WebGL 2 tiene una adopción superior al 90%.

Khronos acaba de tener un seminario web sobre webgl2:
https://docs.google.com/presentation/d/11-mTDNmSJzJnRVGu9Vu6AUzOt34yV3PO7oqw4E5wc2o/edit#slide=id.gd15060520_0_38
Los medios saldrán en breve, pero la presentación fue principalmente voz en off de las diapositivas y demostraciones asociadas en las diapositivas.

Está bastante claro que esto requiere un nuevo comienzo, no una "actualización" del WebGLRenderer existente.

En términos de módulos es6, creo que el enfoque actual de la fuente son los módulos es6, luego usar el paquete acumulativo para un paquete sigue siendo la forma de admitir una "compilación dual".

He hecho esto durante una semana más o menos, probando módulos en Safari Tech Preview y el paquete en todos los navegadores. Realmente da como resultado compilar/tener el árbol de fuentes, así como el paquete actual. Paquete acumulativo de una sola línea como el que tiene actualmente y una copia del árbol fuente para uso del módulo.

@bhouston tentador...

¿Último estado?

De alguna manera tengo sentimientos encontrados acerca de esto. Inicialmente, estaba pensando en el mismo camino que propuso @bhouston , agregando gradualmente características de webgl2 al WebGLRenderer actual. Pero eso haría que el renderizador fuera más complejo y difícil de manejar con características que difieren más entre las dos versiones, lo que terminaría con un código desordenado lleno de bifurcaciones y verificaciones de condición.
Una opción podría ser clonar el WebGLRenderer como punto de partida para WebGL2Renderer y seguir eliminando/agregando funciones sin alterar el renderizador original.
Si echamos un vistazo a los motores como Playcanvas, que es probablemente el que tiene la compatibilidad más antigua con webgl2, podemos ver que ni siquiera aprovecha las nuevas características de webgl2 como UBO o VAO porque es algo que modificará muchas partes del motor.

Creo firmemente que si tratamos de mezclar ambas versiones en el mismo renderizador, terminaremos con un código más difícil de mantener y tan pronto como webgl2 obtenga soporte completo, necesitaremos refactorizar esto de todos modos, ya que supongo que seremos obligado a seguir un diseño para mantener esa compatibilidad, en lugar de diseñarlo desde cero teniendo en cuenta webgl2.

Así que mi voto es comenzar WebGL2Renderer desde cero incluso si vamos lento (todavía tenemos espacio para mejorar hasta que webgl2 se acerque al 100 % de soporte).

Se deben modificar algunos archivos además del renderizador, por ejemplo, texturas, programas, etc. ¿Deberíamos crear una subcarpeta renderer\webgl2 y seguir agregando los archivos que se crearán específicamente para ese renderizador?

Podríamos crear un problema con la lista de cambios que debemos hacer para tener un renderizador totalmente compatible con webgl2 para tenerlos en cuenta al escribir el renderizador, y también crear una lista de características que nos gustaría tener para que MVP centre nuestro esfuerzo en discutir estos en este estado inicial para iniciar una conversación más profunda sobre la implementación.

¿Alguna actualización sobre su desarrollo?

Aún no. Estaba dando prioridad a WebVR este mes.

Intenté una conversión rápida y sucia en el lugar al lenguaje de sombreado WebGL2 y ES3, como lo sugirió @fernandojsg arriba. Aquí está la diferencia aplastada: https://github.com/tstanev/three.js/compare/master...tstanev :traian/webgl2 En realidad, no se ve tan mal como esperaba inicialmente. Casi parece que no sería muy feo admitir ambos a través de algunos ifdefs colocados estratégicamente.
[Editar: enlace actualizado.]

@tstanev ¿Tiene un ejemplo de trabajo?

Los ejemplos de three.js incluidos en la rama vinculada están funcionando (como puede ver en la diferencia, convertí los que requerían extensiones anteriormente). Puede clonar el repositorio/sucursal y ejecutarlos localmente.

@tstanev ¿Qué tal hacer una comparación de rendimiento para los cambios de webgl2 en línea?) Sería bueno verlo. (tres.js frente a tres.js en webgl2)

Hola
gracias por esta mejor idea.
Quiero usar webgl2renderer en mi programa, pero no pude usarlo en la versión de precompilación (r86), así que obtengo la fuente y elimino el comentario de webgl2rendrer en la importación de three.js y luego lo construyo.
ahora mi código y su ejemplo (webgl2-sandbox) se ejecutarán sin ningún error pero no muestran nada

EDITAR: los probé en Firefox 54 y Chrome 60
mi ejemplo usando bufferGeometry y ShaderMaterial y funcionará correctamente en webglrenderer

nadie me responde? ¿Cuál es el problema de webgl2renderer ahora?

@ MHA15 presumiblemente no está incluido en la compilación porque aún no está listo para la producción.

Hola chicos, ¿cómo va el desarrollo de WebGL2Renderer?
Sé que se tomó la decisión de recrearlo desde cero. Pero ha pasado un tiempo y el desarrollo es un poco lento en este tema, ya que creo que es una gran cantidad de trabajo recrearlo.

En este punto, ¿podemos reconsiderar hacer un clon de WebGLRenderer y cambiarlo a WebGL2 como lo hizo @mattdesl en https://github.com/mrdoob/three.js/issues/8125 ? Luego podemos modificar el renderizador en función de algunas características nuevas como UBO como dijo @fernandojsg . Eventualmente, eliminaremos todos esos códigos heredados de webgl 1.

En mi opinión, crear el renderizador desde cero requiere una gran cantidad de trabajo e, idealmente, solo puede comenzar con unos pocos colaboradores. Esta conversación se inició hace un año. Y a menos que lleguemos al punto en que tengamos un salvador que pasaría unos meses a tiempo completo construyéndolo desde cero, creo que probablemente estemos en la misma página el próximo año.

En mi opinión, crear el renderizador desde cero requiere una gran cantidad de trabajo e, idealmente, solo puede comenzar con unos pocos colaboradores.

Eso es verdad. Pero incluso entonces, creo que es más fácil que hacer que WebGLRenderer sea ​​más difícil de mantener agregando condicionales en todas partes. Pasé la mayor parte de mis últimos 5 años tratando de hacer que WebGLRenderer sea ​​más fácil de leer y mantener.

Además, creo que @fernandojsg planeaba intentarlo en las próximas semanas.

Eso es genial. Espero con ansias el gran trabajo de @fernandojsg!!

PD Debo decir... Gracias a todos los colaboradores de este proyecto por ampliar mi horizonte de los gráficos por computadora. Espero poder contribuir con algunos ejemplos en el futuro.

Estoy de acuerdo con @mrdoob en que será más fácil crear un nuevo renderizador desde cero que modificar el actual.
Como dijo, quería probarlo en las próximas semanas. Mi enfoque es comenzar a crear justo lo que se necesita para un cuadro simple en la pantalla y seguir agregando funciones paso a paso, en lugar de tomar lo que ya está allí e intentar refactorizarlo.
Como ejemplo, solo eche un vistazo al estado actual de WebGLRenderer , ha habido muchas discusiones sobre cómo hacerlo más modular y personalizable, pero incluso si el código interno sigue mejorando con el tiempo, fuera de allí es solo una caja negra.
Tan pronto como tenga algo funcionando, abriré un PR para que podamos seguir discutiendo allí los próximos pasos.

Mientras estamos en eso... 5f889ce296aaf447ec5992a6df726691098a9110 8aab6e0382cd6ba8fd3fb943e7f65141bf3a50bc
webgl2_sandbox funciona de nuevo (aunque requiere módulos es6).

@mrdoob , ¿tiene algún cálculo aproximado de cuándo estará disponible en la versión maestra/versión? :) ¡Estoy feliz de que esté sucediendo! :)

@wdanilo No realmente... ¿Qué características de WebGL2 necesitas?

@mrdoob, las mayores mejoras vendrían de Uniform Buffer Objects y Sampler2DArray. La matriz de texturas sería muy beneficiosa para mi proyecto actual porque nos enfrentamos a los límites de unidades de textura ya que estoy usando un sombreador complejo que superpone múltiples materiales enmascarados por mapas alfa.

@mrdoob Nuevas palabras clave como flat en glsl también serían muy útiles.

Mi proyecto necesita texturas 3D.

Interesante...
Súper útil para estar al tanto de los casos específicos para los que las personas necesitan WebGL 2.0.
¡Manténlos viniendo!

Texturas 3D es también la gran característica para nosotros. Creo que también usamos algunas funciones de sombreado.

A veces quiero MRT

+1 para múltiples objetivos de renderizado también

WebGL1 ya admite múltiples objetivos de renderizado a través de una extensión, e incluso hay un PR para ello en ThreeJS: https://github.com/mrdoob/three.js/pull/9358 ( demostración ).

Creo que los objetivos de representación multimuestra son mi función favorita. La mayoría de los clientes solicitan el posprocesamiento (bloom, LUT, etc.), pero están decepcionados por la falta de suavizado adecuado una vez que se implementan los efectos posteriores. Con los objetivos de renderizado de MSAA, finalmente podemos tener una escena agradablemente suavizada y posprocesada.

Estoy de acuerdo. Los sombreadores alternativos para el antialiasing en escenas posprocesadas con el compositor de efectos no son suficientes para un verdadero antialiasing.

+1 para comentarios de dibujo. ¿O ya es compatible como extensión webgl1 en
¿Tres?

El jueves, 14 de diciembre de 2017 a las 9:45 p. m. Kyle [email protected] escribió:

Estoy de acuerdo. Sombreadores alternativos para antialiasing en escenas posprocesadas
con el compositor de efectos no son suficientes para un verdadero antialiasing.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/mrdoob/tres.js/issues/9965#issuecomment-351815640 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AHTX1RhYdGuTVSpmOy1ka-6gy1eslHQAks5tAXrFgaJpZM4Kj_9l
.

Tengo un par de casos de uso aquí:

1. Necesito MRT: actualmente estoy renderizando el mismo sombreador 4 o 5 veces, cambiando un atributo solo para obtener diferentes búferes.
2. La renderización de textura con antialiasing es una característica importante para nosotros: creamos un "editor de nodos" con vista previa de visualización. Cada visualización es solo una textura que dibujamos algo también y ningún antialiasing adecuado es un dolor aquí.
3. La palabra clave "plana": ahora estoy indexando geometría con un atributo flotante, que obviamente es subóptimo, peor que indexar con uint one. Estoy pasando este atributo de vertex a fragment shader y no puedo usar uint ahora, porque carecemos del soporte de kwrd "plano".
4. Las texturas 3D (más pequeñas) son excelentes para visualizaciones de alto nivel que nos gustaría admitir en un futuro cercano.

Usar anti-aliasing y post-procesamiento juntos es lo más importante para mí.

@mrdoob Mis 3 principales características/casos de uso de WebGL 2 (en orden de importancia):

1. Destinos de renderizado de muestras múltiples: para (MS) AA adecuado en el posprocesamiento.
2. Texturas enteras: para hacer algoritmos basados ​​en imágenes como campos de distancia firmados, así como para usar datos basados ​​en texturas más exóticos como DEM (modelos de elevación digital).
3. Transform Feedback: Para hacer sistemas de partículas.

@mrdoob por cierto, ¿sabe por qué #9358 PR no se fusionó? Como ha escrito @mattalat , trae renderizado multiobjetivo a threejs. Se comprometió hace 2 años, se corrigió varias veces para estar al día con otros cambios y hasta ahora no está :(

Lo pregunto porque tengo una escena que usa mucho las descripciones de formas SDF. Cada forma genera 6 salidas diferentes, así que ahora lo calculo 6 veces pasando los números de sombreador de 0 a 5. Sería mucho mejor usar múltiples salidas y solo traerá un aumento de rendimiento de 5x.

@wdanilo Probablemente no era el momento adecuado (muchas cosas se movían en el renderizador en ese momento). Además, parece que incluyó las compilaciones que causan conflictos fácilmente. ¿Alguien se anima a hacer un nuevo PR?

/cc @edankwan

Necesitamos texturas 3D y objetivos de renderizado multimuestra.

Estoy buscando usarlo para poder configurar depthTexture.type = THREE.FloatType ... a menos que haya otra forma de hacer tal cosa actualmente.

¿Existe la esperanza de que LineThickness distinto de 1 funcione en Windows y WebGL 2.0? En caso afirmativo, mejoraría algunos de nuestros resultados.

Y aquí me respondo a mí mismo. Al leer el grosor de las líneas usando material básico de tres líneas en SO , entendí que las líneas gruesas necesitarán una geometría en el futuro de todos modos.

@Richard004 Esto no tiene nada que ver con WebGL 2. Ya tenemos un PR para esta solicitud de función, vea #11349 👍

Hola @mrdoob y @Mugen87
Necesito manipulaciones de bits dentro del sombreador de fragmentos, así como la indexación de matrices dinámicas. El primero probablemente no sea muy común, pero lo necesito de todos modos porque estoy tratando de transferir un kernel CUDA a WebGL (GLSL) y otros lenguajes de sombreado permiten manipulaciones de bits, pero WebGL 1.0 (GLSL) no.

Creo que muchos desarrolladores podrían beneficiarse del segundo: es decir, acceder a un elemento de matriz con una variable. Actualmente en WebGL 1.0 (GLSL), un programa como este fallará:

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

Sin embargo, en WebGL 2.0, puede hacer esto. A menudo se necesita dentro de un ciclo, donde necesita obtener diferentes valores de una matriz, pero no puede simplemente hacer un ciclo iterativo (0 a 199 en el ejemplo anterior, por ejemplo), porque entonces necesitaría verificar cada uno elemento y eso es muy lento.

Antialiasing en Postprocesamiento definitivamente sería beneficioso.

Debajo de todo esto está la pregunta: ¿es hora de una nueva arquitectura para Three?

Recientemente comencé a usar D3, versión 4. Fue un rediseño completo . Es6
módulos. Y mucho más importante, 30 módulos, cada uno de los cuales era propio
repositorio Realmente recomiendo mirar la arquitectura D3.

No digo que necesitemos esto para Three, pero creo que podríamos considerar una
golpe de versión principal. En parte debido a webgl2. Pero también por la necesidad de
submódulos.

Un ejemplo: hay un repositorio/submódulo de "selecciones" D3. es tu basico
módulo jQuery DOM pero con toda la verbosidad del DOM escondida en un
Diseño funcional y encadenado. Se puede usar tal cual sin usar el resto de
D3.

¿No te encantaría un módulo independiente de tres que hiciera todo el webgl
desaparezca la verbosidad? Tal vez incluso varios submódulos para webgl ctx/shader
administración, administración de búfer, etc. De hecho, la geometría del búfer es una
mucho como esto Lo mismo ocurre con la creación de shaders a partir de partes.

Solo un pensamiento.

@ fetox74 Bastante seguro de que ya puedes hacer AA https://threejs.org/examples/?q=fxaa#webgl_postprocessing_fxaa

@elunty the FXAAShader no produce un resultado lo suficientemente bueno en comparación con el antialiasing original, lo he usado en la naturaleza.

Estoy principalmente interesado en VAO y escribir en mipmaps, lo que espero sea posible bajo esa especificación.

@pailhead Relacionado #8705 :guiño:

Esperando el soporte nativo para EXT_shader_texture_lod .
Puede resolver los artefactos que se generan al usar MeshStandardMaterial y MeshPhysicalMaterial en la mayoría de los dispositivos Android y MS Edge e Internet Explorer.

@mrdoob , ¿tiene algún plan suyo o de su equipo para actualizar Threejs a Webgl 2.0? Este hilo lleva literalmente años y nada cambia realmente mientras todos los demás marcos ya avanzaron. Tendré que tomar una decisión difícil pronto, probablemente tendríamos que migrar a Babylon o algo así y realmente me gustaría quedarme con Three. Lo haré, si hubiera alguno, solo cualquier plan para su modernización.

@wdanilo si WebGL 2.0 es una prioridad para su proyecto, le recomendaría migrar a Babylon. Sé que algunos colaboradores de three.js planean trabajar en él, pero personalmente estoy enfocado en WebVR y flujos de trabajo de artistas (soporte de svg, etc.).

@mrdoob Realmente aprecio su respuesta rápida aquí. Realmente me gustaría no abandonar three.js. Me gusta cómo se construye la lib debajo del capó y sus suposiciones para ser un marco "general", no "centrado en el juego", etc. De todos modos, gracias por la información y por dejar esto claro.

(Gracias de nuevo @takahirox , estaba al tanto de este hilo). Acabo de hacer una solicitud de extracción n.º 13692. Entiendo que el enfoque no está en eso, pero para nuestros propósitos, ha estado funcionando bien.

Relacionado #13702

Hice la rama base de WebGL2 siguiendo #9965 y #12250

Repositorio: https://github.com/takahirox/three.js/tree/WebGL2Base
Ejemplos: https://rawgit.com/takahirox/tres.js/WebGL2Base/examples/index.html

Puede iniciar WebGL2.0 + Three.js con él.

(Perdón por el conflicto con el trabajo de @yoshikiohshima )

@mrdoob ¿Podemos tener una rama para WebGL2Renderer como three.js/dev-2.0? ¿O podemos fusionarlo con dev aunque todavía hay muchos códigos duplicados entre webgl1 y webgl2?

Soy nuevo en el desarrollo pasado sobre este tema. @takahirox , ¿puede resumir la estrategia que está adoptando y qué admite https://github.com/takahirox/three.js/tree/WebGL2Base? (y nuevamente perdón por mi ignorancia) pero no vi la necesidad de una gran cantidad de código duplicado para admitir WebGL2. ¿Cuáles son los problemas?

@mrdoob ¿Podemos tener una rama para WebGL2Renderer como three.js/dev-2.0? ¿O podemos fusionarlo con dev aunque todavía hay muchos códigos duplicados entre webgl1 y webgl2?

No estoy seguro de por qué esto necesitaría una nueva sucursal. ¿Por qué habría código duplicado?

Parece que no hay conflictos. Hay dos demandas para WebGL2.0 ahora.

1. Ganar WebGL2Renderer para admitir todas las funciones de WebGL2.0 y optimizar bien
2. Agregar webgl2 soporte a WebGLRenderer existente. Pero no admitimos completamente las características de WebGL2.0 y no optimizamos para WebGL2.0 porque no queremos que el renderizador se estropee. Básicamente, esto es solo para el acceso anticipado de Three.js + WebGL2.0 + GLSL3.0

El mío es para 1. Su trabajo es para 2. No tenemos código duplicado y no necesitamos crear una nueva rama para 2.

@takahirox Creo que sería mejor trabajar en la misma sucursal por el momento.

Si mejoras...

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

y los ejemplos webgl2 importan clases directamente (sin necesidad de compilaciones)...

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

no debe haber conflictos.

Puede olvidar mi WebGL2Base hasta ahora porque parece que comenzamos el soporte de WebGL2.0 en un WebGLRenderer .

¿Todavía estamos pensando en implementar un WebGL2Renderer?
He estado buscando mucho últimamente para agregar soporte WebGL2, y estoy esperando cambios de takahirox para reorganizar el mío. Pero después de hacer algunos cambios, comencé a pensar que reescribir el renderizador sería una muy buena idea, así como el objeto WebGLTextures. Si sigue siendo actual, me encantaría participar.

Pienso que si. Creo que agregar soporte webgl 2.0 básico al WebGLRenderer actual es solo para tener algo mientras trabajamos en WebGL2Renderer .

Siéntase libre de comenzar a reescribir el renderizador y enviar relaciones públicas (idealmente paso a paso).

Disculpas si pregunto lo obvio, pero después de leer todo este problema, con la última publicación hace medio año y encontrar algunas referencias a webgl2 tanto en el código fuente maestro como en los ejemplos, todavía parece que no puedo resolverlo. .

¿Se pregunta si webgl2 se puede usar en su estado actual en Three.js? (incluso si solo renderiza mallas de geometría de búfer simples) ¿Funcionaría EffectComposer con un renderizador habilitado para contexto webgl2? ¿Tendría que ajustarse el objetivo de renderizado de alguna manera?

La pregunta más importante, por supuesto, es si actualmente es posible obtener un antialiasing adecuado cuando se usa el compositor con pases personalizados.

Parece que al final terminamos agregando características de WebGL 2.0 a WebGLRenderer .
Sin embargo, WebGPU seguramente necesitará un WebGPURenderer .