Seeing some of the other comments reminded me that most of the work went into trimming the word lists so that it wasn't rude or randomly impossibly difficult.
Developing offline with the engine-only (https://github.com/playcanvas/engine) is obviously an option, but I wouldn't hold your breath for an offline editor.
That issue was opened in 2022. Honestly if you really get into the nitty gritty of PC it becomes quickly apparent there’s some very strange design choices and priorities.
You can produce some great stuff but there are many dev-exp headaches
Any idea how close Apple is to shipping stable WebGPU? They are the main bottleneck in terms of marketshare, Chrome has shipped it on Windows and Android already.
It’s in advanced safari iOS feature flags right now, and has been for a while. It works on the demos for PlayCanvas, but I can’t speak to long term stability .
What sort of things will compute shaders on the web unlock that wasn't possible before? Asking as someone with only a little graphics programming experience
They unlock a lot of advanced graphics techniques that are too slow to do CPU-side but work well in parallel on GPU. It's a pretty wide variety of things, but e.g. lighting, mesh manipulation, terrain, voxels, post-processing.
I think you'll begin to see more advanced particle systems and physical simulations for a start. And 3D Gaussian Splatting will probably benefit too (since compute will probably enable much faster sorting of splats). So it's not really that this stuff wasn't possible before...but compute will enable these techniques to run far faster.
With WebGPU, Stable Diffusion in the browser (watch out, once you click the "Generate" button, it will fetch 2 GByte of daaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaata) (and probably make your laptop hang whiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiile generating, as you can tell by my typing).
PlayCanvas[0] is the probably the closest "web-first" solution compared to Unity. Used by lots of Snap Games & Instant Games. It's written in JS which means that it's way smaller ~350kB for an empty scene if I recall.
> It's written in JS which means that it's way smaller
There's nothing inherently large about WebAssembly, it's just that most practical wasm demos bundle emscripten (essentially an entire OS's standard library) or another very heavy layer in order to interop between the JS and WASM world.
As a bit of an experiment to see how small wasm could practically be with a minimal interop layer, I built this little project - the web demo is 90KB of JS + 70KB of wasm:
There's a lot of room for improvement in terms of size optimisation in most projects, but it's still early days and for now most of them just bundle an OS compatibility layer to get things working quickly.
We went with ImageMagick and PVRTexToolCLI driven from a node.js script. I'd go with GraphicsMagick now that I know about it; IM doesn't yield good DXT compression quality.
lots of systems are that vintage or older, and do not have update-able graphics drivers due to being laptop OEM specific stuff (this was the case for all nvidia/ati mobile chips until recently, the OEM provided the driver, generic nvidia/ati drivers cannot be installed).
Unity has basically said that they will not be able to make a good WebGL export until something like web assembly exists. It's just not possible. The entire Unity game engine + your game code compiled to javascript is too much for browsers to load in any reasonable time frame if you have to use plain javascript.
One of the biggest issues we see people run into with Unity WebGL right now is browsers (especially Chrome) running out of memory on trying to run Unity WebGL content. There are separate issues here:
The need to allocate a continuous block of XXX MB of space for the WebGL content. This is the memory Unity will operate on. The size of this can be configured in the WebGL Player settings. This needs to be large enough to fit all the objects and assets Unity will have loaded at a specific point in time. You can use the Memory Profiler in Unity to debug how this space is being used. This needs to be a continuous block of memory in the browser’s heap. If the browser is low on memory, or it’s heap is fragmented, it may fail allocating such a block of memory.
Browsers needing too much memory to parse the JavaScript. The JavaScript code emitted by Unity for a WebGL player build is several orders of magnitude larger than other common uses of JavaScript, and JavaScript VMs may require a lot of memory to parse all this code. In particular, Chrome’s V8 sometimes runs into issues with this, causing it to crash, because it cannot allocate enough memory to parse the code. In Firefox, this is not as much of an issue, as Firefox uses asm.js to AOT compile the JavaScript, which has a smaller memory overhead.
For a lot of use cases, this is currently the biggest show-stopping issue on WebGL, and it is not an easy one to fix. Right now, the best we can do on our side is to emit less code. We have been experimenting with this at our last HackWeek, where we had a project to see how far we can reduce the output size of our WebGL export. At the end of the week, we were able to build a simple Unity project to WebGL with a distribution size of 1.2 MB, by improving code stripping, improving compiler settings, and removing things we don’t need among other things. While this value is somewhat theoretical, as some of these improvements were made given assumptions we cannot make in general, we did learn a lot from this week, and I expect to see a lot of changes which benefit build output size to be rolled back into Unity starting with version 5.2. Also, we have build tools to visualize which code modules got included in the build, how much code was generated for those, and what caused them to be included. We plan to make these tools available in a future Unity release (5.3 at earliest), which should greatly help users to analyze and optimize their build output sizes. Reducing code output size also helps a lot with startup times, as it reduces the delay needed to parse the code.
But, ultimately, we expect that these memory issues will be helped much more by advances in browser technology. All browsers are moving towards 64-bit builds, which lets them use larger address spaces. And, more importantly, Mozillla, Google and Microsoft are working on a new technology called WebAssembly which packages asm.js code into a bytecode format, which can then be very efficiently be compiled into native code. We are pretty excited about this, as this will greatly reduce load times, memory overhead and distribution size of WebGL content.
https://conundrum.fun/
Seeing some of the other comments reminded me that most of the work went into trimming the word lists so that it wasn't rude or randomly impossibly difficult.