<div><div dir="auto">That is, is there a suitable ECMAScript API that I target, I don’t mind, X3DOM, X_ITE/VRMLScript, Three.js, glTF->webGPU,  or Babylon.js? It would make sense that they already support WebGPU, perhaps using “headless” Node.js for video rendering.   The primary requirement is hiding the WebGPU  layer, but perhaps later using an “unrolling” method to remove API calls and use WebGPU directly—think of WebGPU as a sort of Assembly language.   I realize that the shaders will likely be precompiled.  Perhaps WASM already supports WebGPU?</div><div dir="auto"><br></div><div dir="auto">Is Chrome the primary WebGPU target presently?</div><div dir="auto"><br></div><div dir="auto">Would it make sense to use Node.js puppeteer (wainwright disappeared?) or the like to record WebGPU videos?</div><div dir="auto"><br></div><div dir="auto">I’ve tried a bit to write a serializer for X3D DOM document (read JavaScript object) conversion to Three.js.   Perhaps it’s time to return there?</div><div dir="auto"><br></div><div dir="auto">I don’t want to get into a big discussion about the merits of generating code.   Compilers do it all the time.</div><div dir="auto"><br></div><div dir="auto">I’m also fully supporting CLI.  Thanks, Michalis, so there’s other ideas in the pipeline (support for a Pascal generator).</div></div><div><div dir="auto"><br></div><div dir="auto">John </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 19, 2023 at 6:47 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><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" target="_blank">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">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>
</blockquote></div></div>
</div>