Three.js: WebGL2Renderer

Muito agradável. :) Na verdade, eu estava um pouco preocupado em como lidar com a complexidade do WebGL 2 e 1.

Seria ótimo preferir usar UBO. :) E eu adoro a idéia de apenas apoiar BufferGeometry - isso deve simplificar as coisas tremendamente.

Seria legal oferecer suporte principalmente aos mesmos shaders se mantivermos a renderização avançada (que parece ser o que o UE4 está fazendo para velocidade para VR.) Acho que provavelmente podemos mudar isso? O que você acha?

Acho que gostaria de manter a compatibilidade do shader para que, se o WebGL2 não estiver disponível, possamos voltar para algo semelhante, apenas mais lento.

@mrdoob Hip hip hooray! E ótimo saber que BufferGeometry será usado exclusivamente. 👍

Eu apoio a sugestão de @bhouston de preferir UBOs.

Seria possível também dissociar mais totalmente a iluminação e o manuseio de sombras do renderizador? Os padrões são realmente úteis, mas quando você deseja controle completo sobre a lógica de iluminação e sombra, WebGLRenderer e co. sentir que eles lutaram.

E enquanto estou listando itens do tipo lista de desejos, os algoritmos de classificação podem ser 'conectáveis'? Eu tenho necessidades de classificação que estão fora do escopo de três e parece desnecessariamente difícil substituir as funções de classificação no WebGLRenderer atual. Talvez isso possa ser uma configuração opcional ao criar o objeto renderizador?

Eu quase me pergunto se alguém deveria apenas modificar o WebGLRenderer 1 e remover o suporte para qualquer coisa, exceto objetos BufferGeometry. Esse pode ser um caminho mais fácil a seguir. Se existe uma função simples para converter Geometry em BufferGeometry que força as pessoas a chamar...

Acho que digo isso porque estou preocupado em tentar manter a paridade de recursos entre WebGLRenderer e WebGLRenderer2. É mais fácil evoluir uma única base de código do que manter duas em paralelo.

Eu quase me pergunto se alguém deveria apenas modificar o WebGLRenderer 1 e remover o suporte para qualquer coisa, exceto objetos BufferGeometry. Esse pode ser um caminho mais fácil a seguir. Se existe uma função simples para converter Geometry em BufferGeometry que força as pessoas a chamar...

Já existe uma função assim. Mas não é tão simples...

Acho melhor construir WebGLRenderer2 do zero para que possamos reconsiderar a API e os recursos suportados.

Firefox 51 agora tem suporte WebGL 2: https://www.mozilla.org/en-US/firefox/51.0/releasenotes/

Mal posso esperar por isso!

Chrome 56 com suporte para WebGL 2.0 foi lançado!
https://developers.google.com/web/updates/2017/01/nic56

Bom momento para avançar WebGLRenderer2 ? XD

Devemos também criar um WebGLDeferredRenderer2?

Planejando começar a analisar tudo isso na próxima semana! ✌️

Alguma chance você já teve algum tempo para olhar para ele! Muuuuito ansiosa por isso! (texturas 3D)

@mrdoob
Alguma atualização?
Se você tiver alguma dúvida, compartilhe conosco!
Podemos discutir e ajudar ;D

Ainda não tive tempo. Breve, breve! 😇

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

Alguma atualização? Estou especialmente interessado em texturas 3D para renderização de volume de algumas imagens médicas. Também estou disposto a ajudar a fazer com que essa solicitação de pull seja bem-sucedida.

A sandbox webgl2 atual do three.js não funciona :( https://threejs.org/examples/webgl2_sandbox.html
Pode ser um problema de compilação da versão three.js?

Se o <script type="module"> online já tivesse sido implementado...
https://groups.google.com/a/chromium.org/d/msg/blink-dev/uba6pMr-jec/tXdg6YYPBAAJ

Pelo menos a Mozilla está trabalhando nisso https://bugzilla.mozilla.org/show_bug.cgi?id=1240072

@mrdoob , Isso significa que podemos esperar que a API Three.js aproveite <script type="module"> quando atualizada para WebGL 2.0? ;)

BTW, acho que é mais fácil adicionar suporte WebGL 2.0 ao WebGLRenderer. Acho que isso permitiria a adoção incremental e podemos fazer a detecção de recursos para ver se podemos usar os recursos do WebGL 2. Não acho que seja a coisa mais difícil de fazer. Eu sei que isso leva a um pouco de complexidade em oposição a um renderizador WebGL 2 puro, mas é o caminho mais fácil a curto e médio prazo. E evoluímos lentamente, onde eventualmente deixamos para trás o WebGL 1, uma vez que o WebGL 2 tenha algo acima de 90% de adoção.

Khronos acabou de fazer um webinar sobre webgl2:
https://docs.google.com/presentation/d/11-mTDNmSJzJnRVGu9Vu6AUzOt34yV3PO7oqw4E5wc2o/edit#slide =id.gd15060520_0_38
A mídia sairá em breve, mas a apresentação foi principalmente a narração dos slides e demonstrações associadas nos slides.

Está bem claro que isso requer um novo começo, não uma "atualização" do WebGLRenderer existente.

Em termos de módulos es6, acho que a abordagem atual da fonte sendo módulos es6, então usar rollup para um pacote ainda é a maneira de suportar uma "compilação dupla".

Eu fiz isso agora por uma semana ou mais, testando módulos no Safari Tech Preview e o pacote em todos os navegadores. Realmente resulta em construir/ter a árvore de origem, bem como o pacote atual. Rollup de uma linha como você tem atualmente e uma cópia da árvore de origem para uso do módulo.

@bhouston tentador...

Status mais recente?

Eu tenho um sentimento misto de alguma forma sobre isso. Inicialmente, eu estava pensando no mesmo caminho proposto pelo @bhouston , adicionando recursos webgl2 de forma incremental ao atual WebGLRenderer . Mas isso tornaria o renderizador mais complexo e difícil de lidar com recursos que diferem mais entre as duas versões, acabando com um código confuso cheio de ramificações e verificações de condição.
Uma opção pode ser clonar WebGLRenderer como ponto de partida para WebGL2Renderer e continuar removendo/adicionando recursos sem mexer no renderizador original.
Se dermos uma olhada em mecanismos como o Playcanvas, que provavelmente é aquele com o suporte mais antigo ao webgl2, podemos ver que ele nem aproveita os novos recursos do webgl2 como UBO ou VAO porque é algo que vai modificar muitas partes do motor.

Eu acredito fortemente que se tentarmos misturar as duas versões no mesmo renderizador, acabaremos com um código mais difícil de manter e assim que o webgl2 tiver suporte total, precisaremos refatorar isso de qualquer maneira, pois acho que estaremos forçado a seguir um design para manter essa compatibilidade, em vez de projetá-lo do zero tendo em mente o webgl2.

Então meu voto é começar WebGL2Renderer do zero mesmo se formos devagar (ainda temos espaço para melhorias até que o webgl2 chegue perto de 100% de suporte por aí).

Alguns arquivos além do próprio renderizador devem ser modificados, por exemplo, texturas, programas e assim por diante. Devemos criar uma subpasta renderer\webgl2 e continuar adicionando os arquivos que serão criados especificamente para esse renderizador?

Poderíamos criar um problema com a lista de mudanças que devemos fazer para ter um renderizador totalmente compatível com webgl2 para tê-los em mente ao escrever o renderizador e também criar uma lista de recursos que gostaríamos de ter para o MVP concentrar nossos esforços em discutir estes neste estado inicial para iniciar uma conversa mais profunda sobre a implementação.

Alguma atualização sobre seu desenvolvimento?

Ainda não. Eu estava dando prioridade ao WebVR este mês.

Eu tentei uma conversão in-loco rápida para a linguagem de sombreador WebGL2 e ES3, conforme sugerido por @fernandojsg acima. Aqui está o diff esmagado: https://github.com/tstanev/three.js/compare/master...tstanev :traian/webgl2 Na verdade, não parece tão ruim quanto eu esperava inicialmente. Está quase parecendo que não seria super feio suportar ambos através de alguns ifdefs estrategicamente posicionados.
[Editar: link atualizado.]

@tstanev Você tem um exemplo de trabalho?

Os exemplos do three.js empacotados no branch vinculado estão funcionando (como você pode ver no diff, converti os que exigiam extensões anteriormente). Você pode clonar o repositório/ramificação e executá-los localmente.

@tstanev Que tal fazer uma comparação de desempenho para as alterações do webgl2 online?) Seria bom ver isso. (three.js vs three.js no webgl2)

Oi
obrigado por esta melhor ideia.
Eu quero usar o webgl2renderer no meu programa, mas não consegui usá-lo na versão pré-compilada (r86), então eu pego o código-fonte e descomente o webgl2renderer na importação de três.js e depois o construo.
agora meu código e seu exemplo (webgl2-sandbox) serão executados sem nenhum erro, mas não mostram nada

EDIT: eu testei no firefox 54 e chrome 60
meu exemplo usando bufferGeometry e ShaderMaterial e funcionará corretamente no webglrenderer

ninguém me responde? qual é o problema do webgl2renderer agora?

@MHA15 presumivelmente não está incluído na compilação porque ainda não está pronto para produção.

Olá pessoal, como está o desenvolvimento do WebGL2Renderer?
Eu sei que foi tomada a decisão de recriá-lo do zero. Mas já faz um tempo e o desenvolvimento é meio lento neste tópico, pois é uma grande quantidade de trabalho para recriá-lo, eu acredito.

Neste ponto, podemos reconsiderar a criação de um clone do WebGLRenderer e alterá-lo para WebGL2, como o @mattdesl fez em https://github.com/mrdoob/three.js/issues/8125 ?? Podemos então modificar o renderizador com base em alguns novos recursos, como o UBO, como disse @fernandojsg . Eventualmente, removeremos todos esses códigos legados webgl 1.

Na minha opinião, criar o renderizador do zero requer muito trabalho e, idealmente, só pode começar com alguns contribuidores. Esta conversa começou há um ano. E, a menos que cheguemos ao ponto de termos um salvador que passaria alguns meses em tempo integral construindo-o do zero, acredito que provavelmente estaremos na mesma página no próximo ano.

Na minha opinião, criar o renderizador do zero requer muito trabalho e, idealmente, só pode começar com alguns contribuidores.

Isso é verdade. Mas mesmo assim, acho que é mais fácil do que tornar WebGLRenderer mais difícil de manter adicionando condicionais em todos os lugares. Passei a maior parte dos meus últimos 5 anos tentando tornar WebGLRenderer mais fácil de ler e manter.

Além disso, acho que @fernandojsg estava planejando tentar nas próximas semanas.

Fantástico. Ansioso pelo ótimo trabalho do @fernandojsg!!

PS Devo dizer... Obrigado a todos os colaboradores deste projeto por ampliarem meu horizonte da computação gráfica. Espero poder contribuir com alguns exemplos no futuro.

Concordo com @mrdoob que será mais fácil criar um novo renderizador do zero do que modificar o atual.
Como ele disse, eu queria tentar nas semanas seguintes. Minha abordagem é começar a criar apenas o que é necessário para uma caixa simples na tela e continuar adicionando recursos a ela passo a passo, em vez de pegar o que já está lá e tentar refatorá-lo.
Como exemplo, dê uma olhada no estado atual do WebGLRenderer , tem havido muitas discussões sobre torná-lo mais modular e personalizável, mas ainda assim, mesmo que o código interno continue melhorando ao longo do tempo, fora disso é apenas uma caixa preta.
Assim que tiver alguma coisa funcionando abro um PR para continuarmos discutindo lá os próximos passos.

Enquanto estamos nisso... 5f889ce296aaf447ec5992a6df726691098a9110 8aab6e0382cd6ba8fd3fb943e7f65141bf3a50bc
webgl2_sandbox funciona novamente (requer módulos es6).

@mrdoob você tem alguma estimativa aproximada de quando estará disponível no master / release? :) Estou feliz que está acontecendo! :)

@wdanilo Não realmente... Quais recursos do WebGL2 você precisa?

@mrdoob as maiores melhorias viriam dos Uniform Buffer Objects e do Sampler2DArray. A matriz de texturas seria seriamente benéfica para o meu projeto atual porque estamos enfrentando os limites da unidade de textura, pois estou usando um sombreador complexo que coloca em camadas vários materiais mascarados por mapas alfa.

@mrdoob Novas palavras-chave como flat em glsl também seriam muito úteis.

Meu projeto precisa de texturas 3D.

Interessante...
Super útil estar ciente dos casos específicos para os quais as pessoas precisam do WebGL 2.0.
Mande-os vir!

Texturas 3D também é o grande recurso para nós. Acho que também usamos alguns recursos de sombreamento.

Às vezes eu quero MRT

+1 para vários destinos de renderização também

Vários destinos de renderização já são suportados no WebGL1 por meio de uma extensão, e há até um PR para isso no ThreeJS: https://github.com/mrdoob/three.js/pull/9358 ( demo ).

Acho que os alvos de renderização multisample são meu recurso favorito. A maioria dos clientes solicita pós-processamento (bloom, LUTs, etc), mas ficam desapontados com a falta de anti-aliasing adequado uma vez que o pós-FX é implementado. Com os alvos de renderização do MSAA, podemos finalmente ter uma cena pós-processada bem anti-aliased.

Eu concordo. Sombreadores de solução alternativa para anti-aliasing em cenas pós-processadas com compositor de efeitos não são suficientes para um verdadeiro anti-aliasing.

+1 para feedback de empate. Ou já é suportado como extensão webgl1 em
três?

Em qui, 14 de dezembro de 2017 às 21:45 Kyle [email protected] escreveu:

Eu concordo. Sombreadores de solução alternativa para anti-aliasing em cenas pós-processadas
com o compositor de efeitos não são suficientes para um verdadeiro anti-aliasing.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/mrdoob/three.js/issues/9965#issuecomment-351815640 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AHTX1RhYdGuTVSpmOy1ka-6gy1eslHQAks5tAXrFgaJpZM4Kj_9l
.

Eu tenho alguns casos de uso aqui:

1. Eu preciso do MRT - atualmente estou renderizando o mesmo shader 4 ou 5 vezes, alterando um atributo apenas para obter buffers diferentes.
2. Renderizar para textura com antialiasing é um recurso importante para nós - criamos um "editor de nós" com visualização de visualização. Cada visualização é apenas uma textura, desenhamos algo também e nenhum antialiasing adequado é uma dor aqui.
3. A palavra-chave "flat" - agora estou indexando a geometria com um atributo float, que obviamente é sub-ótimo - pior do que indexar com uint one. Estou passando este atributo do vertex para o fragment shader e não posso usar o uint agora, porque não temos o suporte do kwrd "flat".
4. (menores) As texturas 3D são ótimas para visualizações de ponta que gostaríamos de oferecer suporte em um futuro próximo.

Usar anti-aliasing e pós-processamento juntos é o mais importante para mim.

@mrdoob Meus 3 principais recursos/casos de uso do WebGL 2 (em ordem de importância):

1. Alvos de renderização multiamostrados: Para (MS)AA adequado no pós-processamento.
2. Texturas inteiras: Para fazer algoritmos baseados em imagem, como Campos de distância assinados, bem como usar dados baseados em texturas mais exóticas, como DEM (Digital Elevation Models).
3. Transform Feedback: Para fazer sistemas de partículas.

@mrdoob a propósito, você sabe por que o #9358 PR não foi mesclado? Como o @mattalat escreveu, ele traz a renderização de vários alvos para o threejs. Foi cometido há 2 anos, corrigido várias vezes para manter-se atualizado com outras alterações e até agora não está lá :(

Estou perguntando sobre isso porque tenho uma cena usando descrições de forma SDF. Cada forma gera 6 saídas diferentes, então agora eu calculo 6 vezes passando para os números de shader de 0 a 5. Seria muito melhor usar várias saídas e isso trará simplesmente 5x aumento de desempenho.

@wdanilo Provavelmente não era o momento certo (muitas coisas em movimento no renderizador no momento). Além disso, parece que incluiu as compilações que causam conflitos facilmente. Alguém afim de fazer um novo PR?

/cc @edankwan

Precisamos de texturas 3D e alvos de renderização multisample.

Eu estou olhando para usá-lo para que eu possa definir depthTexture.type = THREE.FloatType .. a menos que haja outra maneira de fazer tal coisa.

Existe a esperança de que LineThickness diferente de 1 funcione no Windows e WebGL 2.0? Se sim, melhoraria alguns de nossos resultados.

E aqui eu respondo a mim mesmo. Lendo espessura de linhas usando material básico de três linhas no SO eu entendi que linhas grossas precisarão de uma geometria no futuro de qualquer maneira.

@Richard004 Isso não tem nada a ver com WebGL 2. Já temos um PR para esta solicitação de recurso, consulte #11349 👍

Olá @mrdoob e @Mugen87
Eu preciso de manipulações de bits dentro do sombreador de fragmentos, bem como indexação de matriz dinâmica. O primeiro provavelmente não é muito comum, mas eu preciso dele independentemente porque estou tentando portar um kernel CUDA para WebGL (GLSL) e outras linguagens de sombreamento permitem manipulações de bits, mas o WebGL 1.0 (GLSL) não.

A segunda eu acho que muitos desenvolvedores poderiam se beneficiar: ou seja, acessar um elemento de array com uma variável. Atualmente no WebGL 1.0 (GLSL), um programa como este falhará:

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

No entanto, no WebGL 2.0, você pode fazer isso. Muitas vezes é necessário dentro de um loop, onde você precisa obter valores diferentes de um array, mas você não pode simplesmente fazer um loop iterativo (0 a 199 no exemplo acima, por exemplo), porque então você precisaria verificar cada elemento e isso é muito lento.

Antialiasing no pós-processamento definitivamente seria benéfico.

Sob tudo isso está a pergunta: é hora de uma nova arquitetura para Três?

Recentemente comecei a usar o D3, versão 4. Foi um redesenho completo . Es6
módulos. E muito mais importante, 30 módulos, cada um deles próprio
repo. Eu realmente recomendo olhar para a arquitetura D3.

Não estou dizendo que precisamos disso para Três, mas acho que poderíamos considerar um
colisão da versão principal. Parcialmente devido ao webgl2. Mas também pela necessidade de
submódulos.

Um exemplo: Existe um repositório/submódulo de "seleções" D3. É o seu básico
módulo jQuery DOM mas com toda a verbosidade do DOM escondida em um
funcional, design de encadeamento. Ele pode ser usado como está sem usar o resto do
D3.

Você não adoraria um módulo independente Three que fizesse todo o webgl
verbosidade desaparecer? Talvez até vários submódulos para webgl ctx/shader
gerenciamento, gerenciamento de buffer e assim por diante. De fato, a geometria do buffer é uma
muito assim. Idem para a criação de shaders a partir de peças.

Apenas um pensamento.

@fetox74 Tenho certeza que você já pode fazer AA https://threejs.org/examples/?q=fxaa#webgl_postprocessing_fxaa

@elunty o FXAAHader não produz um resultado bom o suficiente em comparação com o antialiasing original, eu o usei na natureza.

Estou principalmente interessado em VAOs e escrevendo para mipmaps que espero que seja possível sob essa especificação.

@pailhead Relacionado #8705 :wink:

Aguardando o suporte nativo para EXT_shader_texture_lod .
Ele pode resolver os artefatos gerados ao usar MeshStandardMaterial e MeshPhysicalMaterial na maioria dos dispositivos Android e MS Edge e Internet Explorer

@mrdoob há algum plano seu ou de sua equipe para atualizar o Threejs para o Webgl 2.0? Este segmento leva literalmente anos e nada realmente muda enquanto todos os outros frameworks já avançaram. Eu terei uma decisão difícil em breve, provavelmente teríamos que migrar para a Babilônia ou algo assim e eu realmente gostaria de ficar com o Três. Farei, se houver, apenas quaisquer planos para sua modernização.

@wdanilo se o WebGL 2.0 for uma prioridade para o seu projeto, recomendo que você migre para o Babylon. Eu sei que alguns contribuidores do three.js estão planejando trabalhar nisso, mas estou pessoalmente focado em WebVR e fluxos de trabalho de artistas (suporte a svg, etc).

@mrdoob Eu realmente aprecio sua resposta rápida aqui. Eu realmente gostaria de não abandonar o three.js. Eu gosto de como a lib é construída sob o capô e suas suposições para ser uma estrutura "geral", não "focada no jogo" etc. De qualquer forma, obrigado pela informação e por manter isso claro.

(Obrigado novamente @takahirox , eu estava ciente deste tópico). Acabei de fazer um pull request #13692. Entendo que o foco não está nele, mas para nossos propósitos, está funcionando bem.

Relacionado nº 13702

Eu fiz o branch base WebGL2 seguindo #9965 e #12250

Repo: https://github.com/takahirox/three.js/tree/WebGL2Base
Exemplos: https://rawgit.com/takahirox/three.js/WebGL2Base/examples/index.html

Você pode iniciar o WebGL2.0 + Three.js com ele.

(Desculpe entrar em conflito com o trabalho de @yoshikiohshima )

@mrdoob Podemos ter uma ramificação para WebGL2Renderer como three.js/dev-2.0? Ou podemos mesclá-lo no dev embora ainda haja muitos códigos duplicados entre o webgl1 e o webgl2?

Eu sou novo para o desenvolvimento passado sobre esta questão. @takahirox , você pode resumir a estratégia que está adotando e o que é suportado por https://github.com/takahirox/three.js/tree/WebGL2Base? (e novamente desculpe minha ignorância) mas não vi a necessidade de muito código duplicado para suportar WebGL2. Quais são os problemas?

@mrdoob Podemos ter uma ramificação para WebGL2Renderer como three.js/dev-2.0? Ou podemos mesclá-lo no dev embora ainda haja muitos códigos duplicados entre o webgl1 e o webgl2?

Não tenho certeza por que isso precisaria de um novo ramo. Por que haveria código duplicado?

Parece não haver conflitos. Há duas demandas para WebGL2.0 agora.

1. Fazendo WebGL2Renderer para suportar recursos completos do WebGL2.0 e otimizando bem
2. Adicionando suporte webgl2 ao WebGLRenderer existente. Mas não suportamos totalmente os recursos do WebGL2.0 nele e não otimizamos para o WebGL2.0 porque não queremos deixar o renderizador confuso. Então, basicamente, isso é apenas para acesso antecipado de Three.js + WebGL2.0 + GLSL3.0

O meu é para 1. O trabalho dele é para 2. Não temos código duplicado e não precisamos fazer um novo branch para 2.

@takahirox Acho que seria melhor trabalhar no mesmo branch por enquanto.

Se você melhorar...

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

e os exemplos webgl2 importam classes diretamente (não precisando de builds)...

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

não deve haver conflitos.

Você pode esquecer meu WebGL2Base até agora porque parece que iniciamos o suporte WebGL2.0 em um WebGLRenderer .

Ainda estamos pensando em implementar um WebGL2Renderer?
Ultimamente, tenho procurado muito adicionar suporte ao WebGL2 e estou aguardando as alterações do takahirox para rebasear o meu. Mas depois de fazer algumas mudanças, comecei a pensar que reescrever o renderizador seria uma boa ideia, assim como o objeto WebGLTextures. Se ainda for atual, eu ficaria feliz em participar.

Eu acho que sim. Acho que adicionar suporte básico ao webgl 2.0 ao atual WebGLRenderer é apenas ter algo enquanto trabalhamos em WebGL2Renderer .

Sinta-se à vontade para começar a reescrever o renderizador e enviar PRs (de preferência passo a passo).

Desculpe se estou perguntando o óbvio, mas depois de ler todo esse problema, com o último post sendo meio ano atrás, e encontrando algumas referências ao webgl2 no código-fonte mestre e nos exemplos, ainda não consigo descobrir. .

Gostaria de saber se webgl2 é utilizável em seu estado atual em Three.js? (mesmo se apenas renderizando malhas de geometria de buffer simples) O EffectComposer funcionaria com um renderizador habilitado para contexto webgl2? O alvo de renderização teria que ser ajustado de alguma forma?

A maior questão, é claro, é se atualmente é possível obter o antialiasing adequado ao usar o compositor com passes personalizados?

Parece que no final acabamos adicionando recursos WebGL 2.0 a WebGLRenderer .
O WebGPU certamente precisará de um WebGPURenderer .