<div dir="auto">Hey guys, I’m interested in converting glTF to WebGPU ECMAScript code, but I can’t spend a lot of time on it, that is, I really need an “SAI-like” API to convert to.  Do we have something in mind?</div><div dir="auto"><br></div><div dir="auto">John</div><div dir="auto"><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 19, 2023 at 5:33 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Yes, that was the most helpful article I have seen.  Since WebGPU is low-level and does not do anything automatically there will be many pitfalls, and places for optimization. </div><div dir="auto"><br></div><div dir="auto">I saw there is a planned extension for hardware supported raytracing. Perhaps it would make sense to make this the main target since replacing shaders and pipelines by itself may not be super exciting.</div></div><div dir="auto"><div dir="auto"><br></div><div dir="auto">Andreas<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Jul 19, 2023, 4:14 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank you for posting this,<br>
<a href="https://toji.github.io/webgpu-gltf-case-study/" rel="noreferrer noreferrer" target="_blank">https://toji.github.io/webgpu-gltf-case-study/</a> is very valuable. Lots<br>
of information I needed given in a practical form :)<br>
<br>
Regards,<br>
Michalis<br>
<br>
<br>
<br>
pon., 17 lip 2023 o 22:57 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" rel="noreferrer" target="_blank">andreasplesch@gmail.com</a>> napisał(a):<br>
><br>
> I came across this lengthy, in depth write up:<br>
><br>
> <a href="https://toji.github.io/webgpu-gltf-case-study/" rel="noreferrer noreferrer" target="_blank">https://toji.github.io/webgpu-gltf-case-study/</a><br>
><br>
> It goes into how to use WebGPU appropriately to render glTF, from a<br>
> probably OpenGL inspired, straight-forward approach, to an optimized<br>
> approach. These are the design patterns which will be helpful.<br>
><br>
> For example, it is important to reduce the number of pipelines.<br>
> Easiest would be one pipeline per shape but there are strategies to<br>
> reduce that by collecting reused geometries.<br>
><br>
> The authors does not like shader variants which is what x3dom is<br>
> doing, eg. building a custom shader for each combination of requested<br>
> features, and caching it. A change in shader requires a different<br>
> pipeline.<br>
><br>
> StaticNodes may become more important for performance enhancements.<br>
><br>
> Perhaps there will be an opportunity to take advantage of DEF/USE for<br>
> GPU instancing, possibly with special DEF names advertising targets<br>
> for GPU instancing.<br>
><br>
> There is not too much discussion in the article on how to approach a<br>
> general purpose renderer which needs to render anything such as the<br>
> glTF <model-viewer> but there are some ideas.<br>
><br>
> -Andreas<br>
><br>
><br>
><br>
><br>
><br>
> On Sun, Jul 16, 2023 at 7:42 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" rel="noreferrer" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
> ><br>
> > 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>
><br>
><br>
><br>
> --<br>
> Andreas Plesch<br>
> Waltham, MA 02453<br>
</blockquote></div></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></div>