<div dir="ltr"><div dir="ltr"><div dir="ltr">YAY, standard shaders! What an opportunity!<div><br></div><div>Thanks for the link.  I know X_ITE uses #version 300 es in the shader file.  Getting it to work is another matter.</div><div><br></div><div><a href="https://create3000.github.io/x_ite/custom-shaders">Custom Shaders | X_ITE X3D Browser (create3000.github.io)</a><br></div><div><br></div><div>Reports are welcome, but I know a lot of people want to discuss this at a conference.</div><div><br></div><div>Thanks!</div><div><br></div><div>John</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 16, 2023 at 6:43 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Thank you, Michalis and Doug, for your comments.<br>
<br>
Looking around I found that WebGPU is partially based on Vulcan and as such related. Perhaps concepts and strategies would map over. Interestingly, WebGPU or wgpu is also apparently considered a desktop API and not just restricted to the web, probably due to cross-platform considerations.<br>
<br>
One aspect of WebGPU is better support for general, massively parallel computation on the GPU, as Doug points out.<br>
<br>
One of the simpler points is that X3D custom shaders would move away from glsl to wgsl and spirv. There are translators as well (<a href="https://github.com/gfx-rs/naga" rel="noreferrer noreferrer" target="_blank">https://github.com/gfx-rs/naga</a>). As has been discussed, for portability X3D could have a standard set of uniforms.<br><br>Andreas<br>
<br>
<br>
On Sat, Jul 15, 2023 at 4:52 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" rel="noreferrer" target="_blank">michalis.kambi@gmail.com</a>> wrote:<br>
><br>
> We do plan to add Vulkan renderer to Castle Game Engine. Some plans<br>
> and initial insights are on <a href="https://castle-engine.io/roadmap#vulkan" rel="noreferrer noreferrer" target="_blank">https://castle-engine.io/roadmap#vulkan</a> .<br>
><br>
> In the meantime, I think OpenGL will remain available for a long time.<br>
> At this point in time, the "OpenGL family" (OpenGL + OpenGLES + WebGL)<br>
> is the only way to really have cross-platform API, the includes all<br>
> desktops (Windows, Linux, macOS, FreeBSD...), mobile (Android, iOS),<br>
> web (WebGL in all browsers) and even console (Nintendo Switch; ANGLE<br>
> allows to use OpenGL on Xbox). So I think there's still plenty of time<br>
> to migrate... but indeed, Khronos explicitly said that after OpenGL<br>
> 4.6, focus is on Vulkan.<br>
><br>
> Regards,<br>
> Michalis<br>
><br>
> sob., 15 lip 2023 o 05:35 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" rel="noreferrer" target="_blank">andreasplesch@gmail.com</a>> napisał(a):<br>
> ><br>
> > Although X3D is a high level scene graph, it is influenced by OpenGL<br>
> > and many, perhaps all X3D browsers use OpenGL or the similar WebGL as<br>
> > an API to draw pixels.<br>
> ><br>
> > OpenGL is not updated anymore and other APIs are now dominant: Metal,<br>
> > Vulcan, Direct3D12 and now WebGPU. It is already available in most web<br>
> > browsers as an alternative to WebGL2. WebGPU is cross-platform, close<br>
> > to GPU instructions and can be very performant.<br>
> ><br>
> > Did anybody think about or actually try to use something other than<br>
> > OpenGL for X3D rendering ?<br>
> ><br>
> > It is time to start speculating and mind mapping how one would go<br>
> > about designing a new X3D browser which uses another low-level API.<br>
> > Ideally, X3D is abstract enough that the choice of graphics API does<br>
> > not matter much. But there are certainly many aspects that an<br>
> > implementation has to consider which depend on the low-level API, from<br>
> > the design stage to actual coding.<br>
> ><br>
> > <a href="https://webgpufundamentals.org/webgpu/lessons/webgpu-from-webgl.html" rel="noreferrer noreferrer" target="_blank">https://webgpufundamentals.org/webgpu/lessons/webgpu-from-webgl.html</a><br>
> > has a detailed comparison between WebGL and WebGPU.<br>
> ><br>
> > WebGPU is lower level. One example mentioned above is ImageTexture.<br>
> > With WebGL it is possible to just change the source image for the<br>
> > texture, and everything else in the rendering process can stay the<br>
> > same. With WebGPU it is necessary to destroy the old texture, and<br>
> > rebuild a pipeline in case the ImageTexture is changed.<br>
> ><br>
> > A Shape corresponds to a draw call in WebGL. For WebGPU a Shape<br>
> > presumably still could correspond to a draw call but it is also<br>
> > possible to bundle all draw calls for a Scene and submit those in one<br>
> > call. That seems interesting but it is unclear how event flow may<br>
> > affect this option.<br>
> ><br>
> > Any experience with nonGL APIs may be insightful.<br>
> ><br>
> > Andreas<br>
> ><br>
> > --<br>
> > Andreas Plesch<br>
> > Waltham, MA 02453<br>
> ><br>
> > _______________________________________________<br>
> > x3d-public mailing list<br>
> > <a href="mailto:x3d-public@web3d.org" rel="noreferrer" target="_blank">x3d-public@web3d.org</a><br>
> > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
<br>
<br>
<br>
--<br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</div></div>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>