Question WebGL and DOTS

Does DOTS support WebGL?
I cant make build with "com.unity.platforms" (failed SubScene bla bla bla)

Spoiler: Error message

InvalidOperationException: Failed to build EntityScene for 'Assets/StreamingAssets/Boot/Boot Sub Scene.unity'
Unity.Scenes.Editor.EntitySceneBuildUtility.PrepareAdditionalFiles (Unity.Entities.Hash128 playerGuid, Unity.Entities.Hash128[] sceneGuids, UnityEditor.Experimental.ArtifactKey[] entitySceneArtifacts, UnityEditor.BuildTarget target, System.Action`2[T1,T2] RegisterFileCopy) (at ./Library/PackageCache/com.unity.entities@1.0.0-pre.65/Unity.Scenes.Editor/EntitySceneBuildUtility.cs:333)

I tried every unity version (2022.2+, 2023.1, 2023.2)

 

You can now use the Build Settings window to build your project, and don’t need to use Build Configuration assets. For any specialized use cases, you can use the Scriptable Build Pipeline.

I don't think that com.unity.platforms is still supported.

 

I was trying that too But no luck in getting working subscenes
Is there some trick to load them?

 

As far as I know entities.graphics is not supported by WebGL.

If you want to use it you need to use an hybrid approach with rendering done by game objects without the entities.graphics package.

If anyone as other info (maybe from GDC)
Let us know

 

Am i right that subscenes in webgl build Not working right now?
I managed to run build with working systems But subscenes still Not working/loading/included (i dont know which state is right)

 

Thanks for identifying this problem! Is this something that will be prioritized in the short term? My WebGL strategy currently involves a custom runtime conversion system and I'm wondering if I should continue to invest in it.

 

Any update on this? Just reproduced it with 2022.3.2f1 + entities 1.0.10 with the graphics package.

 

Graphics package dont work in webgl

 

Managed to get a game jam game to almost work in webgl. Using subscenes and hybrid it works in the editor. But the web build is not showing the level that is in the subscenes. Shows everything else and players still collide with the invisible walls lol. Any workarounds at least?

Is the wayn games approach still the best?

 

I made a duplicate of the subscene meshes and added it to the main scene. (Removed unneeded components).
I turned off the mesh for the subscene originals and everything works.
Ugly but sufficient

 

I am rendering not animated meshes via Graphics.RenderMeshInstanced

 

As far as I can see from forum posts by Unity staff it doesn't even seem to be actively worked on, It would be great to get a clear communication if this will even be supported at all in the short to mid-term as its been years now... Should we just call a spade a spade and move on?

Not having burst support is a massive design restriction for developers especially as WebXR, WASM & WebGPU is becoming extremely relevant and officially supported on most browsers (soon to be on iOS after v17 drops this year). Any VR or AR developer will want to take advantage of the growing number of packages from the community/asset store that are dependant on Burst, not to mention structuring their projects to use jobs from the get go.

Not being able to natively target OpenXR devices like Quest/ Apples Vision Pro and WebXR without reworking your entire codebase seems to defeat the fundamental purpose of the engine.

Understanding WASM is still developing and there are restrictions, and multithreaded rendering is not available until WebGPU formalises. But if there are hard technological restriction preventing development of the web player can this simply just be communicated to the community? All I see its that its "not a priority", "not on the roadmap".

 

I can understand no burst in WebGL and its ok. But is there any chance to have rendering entities?
Right now i have my workaround with Graphics.RenderMeshXXX via authority class
It is not something too hard to implement just to able to see entities
I mean if you making games on many platforms in the same time and WebGL is one of them it feels that there is can be some improvements just for support purposes to make life easier

 

Thank you for this statement. It makes sense and has saved me time. It might be a good idea to include it in your literature with an official statement that ECS/DOTS is not supported on WebGL.

 

Oh wow that just rocked my world... This is the first I learned that Entities Graphics relies on compute shaders. Are you saying that compute shaders are REQUIRED for Entities Graphics or are they just optional?? If they're required, that really hurts... if I had known that 3 years ago I would have definitely not chosen DOTS. That would rule out around half the mobile devices in circulation worldwide, and my game is primarily mobile phone based. My mother's iPhone 8 from 2017 wouldn't even make the cut. Converting all my DOTS code to another engine and OOP at this time would take over a year. Can you confirm?
It's disappointing to find out that WebGL is out - that kills about 15% of my target market. But this news about required compute shaders is the bigger problem.

 

I can confirm they are required, as that's how the sparse uploader works. It is a massive optimization. And Android mobile GPUs are really behind the times (Apple has no problem with the technique used whatsoever). For a significant performance hit, it is probably possible to emulate the compute shader work on the CPU. But that won't scale very well, and may even perform worse than GameObjects as you'd have to upload all instance data every frame.

 

Thanks DreamingImLatios, at least now I know what I'm up against.

I would rather switch game engines than rewrite code to emulate Entities.Graphics without compute shaders. So I spent the good part of a day researching and trying to figure out exactly what sort of phones are currently in use and what sort of phones can run a DOTS executable built with Unity. I attempted to get world-wide data that is recent and measures current use (ie from traffic gathering) instead of raw device sales numbers because I wanted to know what is in use as opposed what people are buying.

From what I gather, all versions of Apple hardware that supported Metal also support compute shaders, which allow arbitrary functions and parameters to be executed on the GPU in parallel. The documentation for Metal often doesn't use the term "compute shaders"... instead they used terms like "kernal functions" or "compute kernals". No doubt some of the older Apple chips couldn't handle very many threads, but I believe they still had the functionality. There are a lot of numbers out there for percentage of current phone traffic that is iOS, but currently it's somewhere between 23% and 28% based on companies like ScientiaMobile that collect phone traffic data and record phone models. So lets round it to 25%.

The Android world is super fragmented, with Samsung as the top dog and getting pretty similar numbers as Apple in terms of overall market share. The first thing I learned is that 2017 was the magic year - that's when Android phones starting hitting the shelf with compute shaders. I also learned that some of the early phones only allowed a maximum of 4 concurrent compute shaders compute buffer bindings. I was unable to determine how many concurrent compute shaders compute buffer bindings are used in Entities.Graphics - hopefully the number is low. Fortunately it was a lot easier to get Android's current web traffic information, and even better, it's broken up into OpenGL ES and Vulkan categories. https://developer.android.com/about/dashboards . Vulkan 1.0 onward supported compute shaders, while ES 3.1 onward did (although the definition of "support" is a little nebulous between manufacturers). The data was collected during a 7 day period in January of this year, and my best guess is that it was acquired through Google Play. The data shows that 85% of the Android devices supported Vulkan, and 86% supported GL ES 3.1 or higher. Quite a few people have been saying that those earlier Android phones were pretty spotty in their support for compute shaders (like that quote above by Matjio regarding VFX graph). So perhaps the true support number is a little less... like 80% or something?

Doing the math, we take 80% of 75% to get 60% for Android and add that to the 25% for iPhones. Thus, approximately 85% of phones in use today support compute shaders, though it could be less depending on how bad the situation with early phone models was. When I was debating using VFX and researching compute shader support 3 or so years ago, the number was closer to 50%. It seems that at lot has changed over the past 3 years and maybe batteries are finally dying on the old phones forcing people to upgrade. I would have preferred a number higher than ~85% but I guess it's better than 50%. If it had still been 50% I would have ditched DOTS and started over with a new engine. Scary.

It's disappointing that WebGL is not an option because it would have been pretty popular for the type of game I'm making. However, the reasons for it not being supported make perfect sense and I would have made the same call. Because many other game engines don't support web builds, it's mostly an even playing field (UE dropped it between 4 and 5). Mobile and web support were the biggest reason I chose Unity and DOTS over UE in the first place, but with this new knowledge, that equation has changed. To be fair, the documentation for Hybrid Renderer V1 and V2 did mention that it required Vulkan, but back then I was so new to game-dev-life that I just filed it away in the brain as something that would be fixed to work with older phones later.

As a sidenote... never use ChatGPT for research like this... it made up at least 5 outright lies about various phones and technologies regarding what they support, their hardware, and when they were released. I finally had to quit using it because it was easier to just dig up the information myself than to go down rabbit holes fact checking its numerous hallucinations. (It's the reason I incorrectly thought the iPhone 8 wouldn't support compute shaders )

 

It isn't the number of shaders, but the number of buffer bindings. I've never actually seen a device that had a working driver that only supported 4 bindings. The OpenGL spec only requires 4, but in practice I always saw a minimum of 8, which is what I target. The compute shader that Entities Graphics uses for non-skinned meshes (the sparse uploader) only uses two bindings, so unless there's some other buffer size alignment restrictions from really old devices, it should be supported by anything that supports compute.

All the modern Apple GPUs (the ones Apple designed themselves) do really well with the type of optimizations employed with Entities Graphics. The M1 punches way above its weight with the skinned mesh rendering technique I use (which also leverages compute shaders in a way many of the compute-supporting Android devices struggle with).

It really is just Android you have to watch out for, but that's not really Unity's fault. The hardware makers in that ecosystem are largely to blame, and I've heard some amazing rants from the best of the best regarding that situation. But they are slowly getting better. Also, just because the devices released with buggy drivers doesn't necessarily mean they still have them. And what the sparse uploader does is pretty mild all things considered, so even the broken ones might not be broken enough to be broken with Entities Graphics, if you follow that logic.

 

Touche, ChatGPT wouldn't just say IDK, instead, it makes up some sh*t and tells you that's true. That's a horrible thing if people rely on it when making decisions.