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.

[Thaina]

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

Unfortunately, I regret to inform you that: In ios, all web browser need to remove all they web engine. And force to use safari under their mask

Really, Google Chrome and Firefox in ios are just safari with some browser UI code added on top. So underlying all of the capability are provided by safari ios. They try to sue Apple as anti competitive and EU are trying to fix this. But there are no enforcement possibility in near future

[ykafia]

Ah well, I guess it's not surprising from Apple 🙁

Besides, Apple is the company that has been pushing for WebGPU, they're the ones that made the initiative. Google and Mozilla have added to the discussions later and they all agreed on the design in the end. Here are their position.

I don't think we should worry about webgpu not being well supported by Apple

[Thaina]

According to caniuse investigation it seem they even remove webgpu experimental from current version onward though

https://caniuse.com/webgpu

There was a person state that they need to rewrite webgpu because first they made it to be similar to metal and it seem too difference from standard

https://developer.apple.com/forums/thread/692979

[mmarinchenko]

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

To make some clarity, this article is from 2020. A lot has happened since then.

1. Wave Engine has been re-branded as Evergine in 2021. So, this is actually the same engine I referenced above.
2. .NET 7 has introduced a new way to interop with JavaScript, which is much more performant thanks to source code generators and the elimination of dependence on Blazor.
3. To be honest, Emscripten's EGL can now be even more performant, given that .NET 7 also introduced the LibraryImport attribute, which can be used instead of traditional DllImport attribute for P/Invokes.

[mmarinchenko]

As for Apple... I hope they will implement WebGPU support. But I wouldn't be surprised if they eventually implement something proprietary, call it WebMetal or something, and ban the use of any other technology on their platforms.

---

Considering what @ykafia is talking about in the comment above I think it would be a good desision for Stride to try implementing WebGPU support first. And then we can discuss the need (and possibility) for WebGL support.

[DaveMS]

+1 for this . I'm also looking for an engine that can target browsers

[JegoMx]

+1 for web support. I only target web so cannot use Stride right now, even though I'd love to jump over to the engine.

[chkworks]

For everyone requesting this, I hope you have considered to donate for Stride to actually make this happen. https://opencollective.com/stride3d

Maybe it would make sense to set up a project on OpenCollective, so people can specifially donate towards web export of projects. Or to outline a roadmap into clear milestones / single projects that are required for this.

[manio143]

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.

I think I said this originally, but I'm no longer sure it's correct. I believe the animation system might not be emitting stuff, but just is doing very unsafe operations on memory.

[ykafia]

Oh well I hallucinated this 😅

[froce]

there is this thing: https://github.com/stride3d/stride/blob/master/sources/core/Stride.Core.AssemblyProcessor/UpdateEngineProcessor.IL.cs

[manio143]

there is this thing: https://github.com/stride3d/stride/blob/master/sources/core/Stride.Core.AssemblyProcessor/UpdateEngineProcessor.IL.cs

Nice catch - this a compile time modification of the IL, which would be occurring before AOT compilation (I think). We will need to see how this code is portable to actual C# (if at all) as we try to rewrite assembly processor into source generators.

[manio143]

Leaving this here https://perksey.com/blog/blazor-silkdotnet.html There's potential to use Silk.NET in the future to target web platform. However, it is still a very long shot at the moment.

[BenMcLean]

Unfortunately, I regret to inform you that: In ios, all web browser need to remove all they web engine. And force to use safari under their mask

Apple users could just stop using Apple.

[Thaina]

As some of us might already know. Currently now EU has been forcing Apple to comply with their DMA. However Apple are trying to execute as maliciously compliance scheme as possible. Start from only lift their ban on the EU users only to cause pain of fragmentation. Destroying ios' ability to do web standard properly. And stall the development of every web standard that might allow competition with their appstore

Their intent is clear, and situation is in dire state. I cannot hope they will do feature such as webgpu and webxr properly on their system

[ykafia]

Ah well, I don't think this is going to matter much in gamedev, we're not bound to web renderers as Stride is supposed to be the renderer through webgl or webgpu.

WebGPU was removed but is back into WebKit so I guess everything is still fine for us

[Thaina]

Ah well, I don't think this is going to matter much in gamedev, we're not bound to web renderers as Stride is supposed to be the renderer through webgl or webgpu.

WebGPU was removed but is back into WebKit so I guess everything is still fine for us

As of the argument go here, I have seen stride try to not support webgl and argue that only webgpu is needed, and then they wait for webgpu to support everywhere, which I argue that ios might not let it become reality. They try to hinder every kind of development in web standard as much as possible

webxr had been in there for years, just to make available only in vision pro alternative web engine only allow in EU webgpu could be the same

[ykafia]

That was my opinion and proposition, I'm pushing to simplify things with WebGPU and the use of wgpu-native. That doesn't mean everyone agrees on my opinion.

Webgl could be a thing since Silk.NET.OpenGL runs on the web thanks to hacky hacks.

[Elevons]

Commenting just to add that this feature would probably make me switch from Unity. There's hardly any engines out there that can compile to desktop, web and android. I think it's only Unity, Unreal and Godot.

[BenMcLean]

I think it's only Unity, Unreal and Godot.

Godot 3 had some support for C# on web via Mono, but Godot 4 does not. It is planned for sometime in the future but probably not until 2025 or later.