Thanks for the feedback. I agree that the performance improvements are the biggest win here. The PWA support is essentially the starting point, bringing installation and file association. Next up, we'll tackle file save using the File System API (instead of relying on sending exported scenes to the Downloads folder). I'm also keen to implement an offline mode (via Service Worker) soon too. Almost all SuperSplat users launch it in a desktop OS...so the PWA testing was done there. But out of curiosity, what should we tackle to make the experience great on mobile in your view?
I don't think you need to - as you say, the use-case doesn't make sense on mobile. My comment was more in appreciation of your desktop-first PWA. Look forward to seeing where you take it.
Understood! As a little update, the PWA got offline mode support in v0.18.0. We're now adding improved file open+save support which should be done by the end of the week.
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.
It's a bit more complicated than than. The front-end framework that the PlayCanvas Editor is built on (PCUI) is also open source:
https://github.com/playcanvas/pcui
Other open source tools like the glTF viewer are also built on it:
https://github.com/playcanvas/playcanvas-viewer
The rest of the Editor code is unminified and unobfuscated. The is done deliberately so devs can write extensions, report bugs and generally understand how it works. More of the Editor codebase will be open sourced over time.
No, it's also designed for developers building AR/VR, playable ads, 3D configurators, architectural visualizations and more. Basically, if you want to build and publish any WebGL content, PlayCanvas has your back. The 'Awesome List' has a selection of interesting use cases: https://github.com/playcanvas/awesome-playcanvas#awesome-pla...
Thanks for the feedback! Good to hear that you experienced good performance from PlayCanvas in your tests. The majority of PlayCanvas users to opt for the Editor rather than using the Engine standalone, so yeah, the developer resources are biased a bit in that direction. But we are working hard to rebalance things towards the engine. For example, we're about to release a new engine-only examples browser app that's really cool. Key an eye out for it. :)
This seems really tone-deaf to me, to sorta market a mostly unrelated feature that's upcoming when a developer just decided against using your product for practical reasons.
I suppose it's nice to know that you've at least acknowledged that there's an issue, but it seems weird to take so lightly someone using your product, finding it so difficult to deal with that they dropped it, and then even dropping an emoticon at the end.
No problem! Thanks for your feedback too. The examples browser is really designed to be a vehicle to learn and experiment with the engine run-time. It should be a great resource for engine-only developers - so hopefully the dvh will find it interesting. We've done a ton of work on the API reference recently too (https://developer.playcanvas.com/en/api/). It's a huge task, but yeah, we're working night and day to make the runtime easier to work with.
It seems like none of that work solves the underlying issue that was raised which was specifically search ambiguity between the library and the editor. Any response should discuss the possibility to changing the library name or creating search friendly alternative name (such the use of "golang" to alow easy searching for content related to the highly ambiguously searchable Go programming language.
PlayCanvas was started by ex-EA/Activision/Sony devs. But Mozilla partnered with PlayCanvas to open source the engine and later launch Firefox's WebGL 2 support with the After the Flood demo: http://aftertheflood.playcanvas.com/
