Browser/Web as target platform

[tebjan]

Just an idea, probably quite complicated to get the engine to work with WebGL, browser restrictions and so on. However, the audience one can reach with shiny 3d web applications / browser games is huge of course.

[xen2]

Probably not goint to happen for a while. However, our best bet is maybe to wait for CoreRT or Mono to support WebAssembly (cf https://github.com/dotnet/corert/blob/master/Documentation/design-docs/WebAssembly-design.md)

[xen2]

BTW, 9 years ago, I worked on a side project which used C# to javascript tech (JSIL if I remember right) to convert OpenGL ES to WebGL. So if it was possible then... (of course Xenko is much more complex!)

[aurodev]

Good wish list item. Long term wish list! :D

[tzachshabtay]

However, our best bet is maybe to wait for CoreRT or Mono to support WebAssembly

Mono already supports WebAssembly, though, doesn't it? That's how Blazor works.

[aurodev]

So it's here at last... "An experimental .NET web framework using C#/Razor and HTML that runs in the browser via WebAssembly" https://github.com/aspnet/Blazor

https://dzone.com/articles/blazor-running-c-on-browser-using-web-assembly

Triage is important though and the community has a multitude of priorities.

[tebjan]

There might be some hints in here as well: https://blogs.unity3d.com/2018/08/15/webassembly-is-here/

[cyberpunk2099]

Blazor now in official preview: https://devblogs.microsoft.com/aspnet/blazor-now-in-official-preview/ I hope this simplifies adding WebGL support to Xenko Engine.

[ykafia]

I'd like to add this : https://github.com/BlazorExtensions/Canvas

Officially Blazor can access webgl, if I'm not wrong we would need to add webgl's api to the set of gpu apis that stride has ?

[ykafia]

Just to update my previous comment on it (i am still learning about it). With .NET 5, compiling to WASM is easier (and integrated?). We could use wgpu-native headers to use the WebGPU api to run games on the web (aside from having native support for DX12/VK/Metal). Other than that, it seems we would have issues with web workers and asset management to solve since they are more intricate in wasm.

[Thaina]

@ykafia Do you have any branch working on that?

I wish we would have a framework and editor that just tied to dotnet for build process and exporting to every platform without any custom meddling, only make our life easier in scene and asset and scripting management. And I hope stride would be that dream engine, unlike unity

[immovablewisdom]

I was pitching my game idea, today, and was asked about targeting web browsers as the client platform. Notwithstanding my practical ignorance of WebGL and Blazor, it seemed like a really smart idea. ... Perhaps this would give me my authoritative server for free, too :)

[Thaina]

Any progress on this?

[ykafia]

Nope, we need to wait for .NET to be able to compile libraries to wasm before anything then rework the asset system + add WGPU as a backend and many other stuff.

There are some good news regarding wasm, some future features currently in development will make it easier to use async code and exception handling.

[Thaina]

They said it was already possible

https://blog.jetbrains.com/dotnet/2022/12/15/the-future-of-net-with-wasm/#CompilingaWASM.NETapplication

[datadelft]

I think adding webGL as target platform would have a LOT of unity users jump from unity to Stride, especially everybody doing LDjam and other gamejams who can't use this engine right now because the lack of this

[LinusSwahn]

Even though I'm 95% sure Unity will backtrack their insane runtime fee idea for a revenue share program instead, webgl is such a good opportunity if it is indeed technically possible of course. Me personally, I hadn't made the switch to Stride yet just because of webgl support in Unity. But with their install based fee webgl would be a dead platform anyway unless they reverse that desicion. For indie-devs being able to quickly iterate and deploy demos without being on the big platforms is really cool even though it might be a niche.

[TylerCode]

I'm one of the Unity users trying to leave, I do a lot of work in WebGL for digital twins, advertising, and games. So want to add a plus one to this issue. Educational games are a big place where this is a must have.

[kevinlakhani]

I'd like to add that WebGL opens up a lot of non-game application use cases. For example, someone could use Stride to create a product customization app on their website or a web-based open source data visualization tool

[LukeSawyers]

+1 also seeking an alternative to Unity for non-game applications. At the moment the toss up is between this and Godot. The up to date C# support is a big draw card, but WebGL platform targeting support is essential.

[mmarinchenko]

Hi, folks! Big +1 from me! And a few thoughts that may be useful.

1. There are 3 graphical backends in web browser context:

• WebGL 1 (legacy)
• WebGL 2 (current)
• WebGPU (experimental)

2. There are several third-party projects that could potentially provide bindings for them:

• https://github.com/dotnet/Silk.NET (official .NET Foundation project, MIT license)
• https://github.com/EvergineTeam/OpenGL.NET (Evergine OpenGL bindings, also used for WebGL 2 backend via Emscripten's EGL, Evergine is closed-source for now, but bindings have MIT license)
• https://github.com/EvergineTeam/WebGPU.NET (Evergine WebGPU bindings, Evergine is closed-source for now, but bindings have MIT license)

3. My wish is to have a WebAssembly target in Stride, but not to have a hard dependency on Blazor or any other web framework.

For example, Uno Platform uses its own approach to target WebAssembly:

• https://github.com/unoplatform/Uno.Wasm.Bootstrap (Apache-2.0 license)

4. Another wish is to ensure proper JavaScript interoperability in Stride (support for embedded mode).

This is very important for industrial applications. It would be great if Stride rendered the scene in an HTML Canvas provided by some external framework (whether it's Blazor, Uno or plain JS/HTML) and made it possible to interact with the scene from the outside.

For example, this is true for Evergine:

• https://github.com/EvergineTeam/WebWorkshop (React.js integration)
• https://github.com/EvergineTeam/UIWindowSystemsDemo (native UI integrations)

But as far as I can see, not for Godot, which has a WebAssembly target and its own UI controls, but no support for external web or native UI frameworks.

[Doprez]

The main thing I can speak on here is if we were to go with a library for webgl it would likely be Silk.Net as we are planning on using them as much as possible.

Since we are using .NET I dont thing it would be hard to integrate JS within a web application (assuming its already done by Microsoft or the .NET community). It should be similar to how a project is set up for a default Vue/React project in C#. This is purely assumption though so I could be very wrong.

[ykafia]

I've got a PoC in here.

Limitations

There are limitations to the web platform that i mentionned above but i'll try to list them in this comment :

1. WASM is not complete, parallelism is not fully implemented and mechanism for reflection is only available on chrome.
2. WebGPU has been released on chrome but not firefox, it still lacks some important features, it also dropped geometry/hull/domain shaders. ~~3. Stride emits some IL code for dynamically accessing properties of objects for the animation system , emitting IL is a big no-no for the web. There might be other parts of the engine using reflection at some point, but i'm not sure which kind of reflection has been added to AoT/wasm compilation~~
3. WebGPU only consumes WGSL, which is going to be super hard to implement in the current shader system.
4. WebGL is a no-no since it lacks a lot of graphics features that Stride provides, there would be a lot of questions to ask about the engine design.
5. I'm not sure if WebGPU with Silk.NET (the bindings that are the most up to date) can run with WASM yet.

(i'll add more later if they come to my mind)

The PoC, and status for the web.

It initially started as me learning WebGPU from the Silk.NET library, it grew to be a bit more complex, it led me to develop the SoftTouch.ECS library to create a minimal reflection free ECS implementation with property based reflection, and a reimplementation of Stride's shader system.

WebGPU only consumes WGSL which is inspired by SPIR-V and GLSL, a totally different language from SDSL (Stride's shader language). So we have to go through some code conversion tools (most likely naga as it is the main compiler for WGSL), to convert SDSL to WGSL and that would be thanks to SPIR-V.

Once the shader compiler is in a good state, i can continue my PoC on WebGPU.

[mmarinchenko]

@Doprez Thanks for your comment!👍

Since we are using .NET I dont thing it would be hard to integrate JS within a web application (assuming its already done by Microsoft or the .NET community).

.NET provides the facility to efficiently call methods from JavaScript (and vice versa), but the API must be explicitly exported on the .NET side to use this. There are some limitations, for example, not all type mappings are supported out of the box.

Documentation: https://learn.microsoft.com/en-us/aspnet/core/client-side/dotnet-interop

If we'll have the opportunity to play a game powered by Stride in a web browser using external UI controls supported by the browser's accessibility assistant technology, it will be amazing!

[mmarinchenko]

@ykafia Your PoC is something I'll definitely look at when I have more free time. Thanks!

5. WebGL is a no-no since it lacks a lot of graphics features that Stride provides, ...

I'm not sure I understood you correctly. I think we should still consider WebGL 2 support. From my point of view, WebGPU adoption evolves very slowly, even slower than WebAssembly. As a side note, I don't have much experience with Unity, but I've been working on a cross-platform mobile project in UE4. It still uses OpenGL ES 3.x renderer on Android by default, because Vulkan drivers are too buggy on many devices. So, I can imagine how long it will take to get production ready WebGPU support, even in Chromium.

If some engine supports high-end graphics features, this doesn't mean that it should only support high-end devices. I believe high-end features should be optional. WebGL 2 backend can be treated as low-end device (yes, something like the 10-year-old Adreno 300 / Mali T600 series 🙂).

[Nesh108]

+1 This would be huge for us. Moving away from unity is now a priority and we are looking around for alternatives.

Stride3D looks really good right now (at least for 3D work) but we are held back by the web export part.

[Thaina]

However WebGPU currently only working in chrome though. I think we should stick with webgl for safari and ios

[ykafia]

I'm sure we could add WebGL to the current abstraction, we would use EGL for emscriptem. But the main issue I see here is that the current abstraction doesn't have an api to handle barriers and other stuff for every GPU api that we have. This stops us from having parallel rendering.

Webgpu already has that implemented, even for webgl. Going for webgpu would help with supporting all gpu apis, parallel rendering and reduce our code base.

Besides, Safari and Firefox already have some working Webgpu implementation in "preview", the latest versions have flags to activate it.

[Thaina]

I would not recommend to put any trust in Apple's preview. If I remember correctly WebXR for safari was in preview for years. And now they only enabled it in VisionOS, even ios actually has full capability to do all WebXR feature since forever

[ykafia]

Apple users can still use chrome and Firefox instead of safari 😉

[ykafia]

According to wave engine engineers the Javascript interop is very slow, they're using EGL now through their opengl binding.