Polygonjs Maker here.

Thanks a lot for your questions.

Yes, the SDK being limited to jai beta is absolutely not something I'm happy about. I was hoping it would be public by the time polygon v2 was ready, but of course that was a gamble. Now the rumor is that it will be in 2027, so this is hopefully just a matter of waiting a bit more time. So I completely appreciate presenting Polygon like this isn't ideal.

But depending on what projects you have in mind, the node-based editor is already quite flexible. Feel free to let me know what you're thinking of building and I can tell you what you could try.

To your questions:

- Is the dev environment still web first or is that a secondary target?: I personally mostly dev in native, do most of the work and tests there, and then do final checks in wasm/js. Most of the projects I deliver using it still are web-based, so this target remains as solid as I can make it.

- [...]see changes reflected in your running app without a refresh or losing state within a second: I used to rely on that, but as projects scale grew, I always found that state would become stale in ways I did not understand, so I stopped chasing that. And when working in native against the SDK, re-compiling a project takes about 1-2seconds, so I have not needed to make this work as smoothly as in js. But I could look into it. And when you scaffold a SDK project, the wasm is reloaded without a page reload, but I think your app state my still need vuejs or react to handle that. In short: not fully sure, but it's most likely possible.

- How complete is the PBR support?: You can use env maps. The materials of imported GLTF are decent (see example: https://polygonjs.com/gui/gltf_import). Several things are still missing like clearcoat, and maybe others I am not fully aware of. There are advanced features like order-independent-transparency, volume rendering, raymarching.

- Lightprobes or lightprobe grid supported?: no light probes at the moment. I want to look into it. And I'm evaluating/experimenting with various GI solutions, which may vary depending if you're rendering polygons, SDF or voxels.

- I didn’t see support for skeleton meshes: There is none yet, but that's definitely on my roadmap.

- Also, how feasible is WebXR support?: not implemented yet, but also high on my roadmap.

▲

manuisin 3 hours ago | parent [-]

Thank you for the reply! I will be keeping an eye out.

Just to preface, I’m the developer of an nsfw bdsm game that’s getting some traction. That might not be something you’d be interested in supporting. But it is built using three.js webgl, its is VR-first but optimized enough for even iphones (memory wise to avoid crashing) with very high quality 3d models and physics. It’s also got a story/narrative/dialogue system with multiple worlds/stages. And everything is done in such a way to not spike memory usage even as different stages and parts of the story with hundreds of audio files, animations load over the web with pre-emptive caching.

It’s very hard to ensure memory usage stays low and make the right trade offs for browsers like Safari that don’t give you too much insight into it. Not to mention the limits of webgl for reducing gpu and cpu time which I’m currently also constrained by in terms of scale.

I’ve been considering migrating to babylon lite as webgpu webxr is nearly ready and already out for devices like vision pro, and it’s the only framework that in my testing actually reliably compares to threejs webgl renderer (threejs webgpu and og babylon are way behind).

But all in all having complete control over the memory seems amazing.

And regarding HMR, yeah it does require careful setup with r3f/react and obv has edge cases. But as my game’s story has increased to be hours long, it is quite handy to able to not wait for majority of changes as reloads which themselves can take a few seconds etc.

If you’re interested in chatting more, I can share the project with you if give me an email or another private avenue.

▲

frading an hour ago | parent [-]

If you want to know when/if I realise any of those features, I send a newsletter every friday with what's new: https://polygonjs.com/newsletter

And the type of project you're describing isn't my personal interest, so no need to share it with me. But I'm curious about tools you've used to control memory with just javascript. I know there are extensions or browser flags you can toggle on, but those still seemed cumbersome. That was one of the main reason that motivated the rewrite, and I find it a relief that I can now detect memory leaks in the test suite, or have an easy way to have arenas (and arenas of arenas) so many objects can be freed/recycled very quickly.

So if you have a good way to control/manage memory in js, I'd be curious to hear.

And you mention "webgpu webxr" as if those worked together, but isn't webxr completely decorrelated from the render api? Or do you mean threejs implementation where those might be intertwined? I assumed webxr would work equally well under webgl or webgpu, since my understanding is that it mostly provides camera projection matrices and ray hit functions. But it could be that my knowledge is out of date, since I haven't touched webxr in the last 2 years.

> But as my game’s story has increased to be hours long

For those situations, on most projects I work on, I create a specific control node, which allows changing the state to predefined scenarii, or saving your current state. This requires the SDK for now unfortunately. But this can then be used with or without the editor, and allows you to quickly change from one state to a completely different one with 1 click or hotkey. I found that's the kind of technique that replaced hot reload for me. This made sure that only the state is updated, which limits the chance of bugs due to side-effects. Now that I write this, I realise this needs a proper documentation, I'll work on that.

	▲	manuisin an hour ago \| parent [-]
		Sounds good! Yeah so I have no sophisticated tools, just guessed calculations done mostly at run time (add up how much do gpu compressed textures should take for a model, mesh+blendshape memory estimates, other data structures). And obv for audio and animations just ensuring what’s not needed is never in memory and just knowing how much the biggest ones cost. To come up with an estimate of an upper bound and obv with lots of testing. ios safari doesn’t even publicly expose how much memory usage is allowed to a tab (and it changes) so really the final test is that stuff stops crashing. But my testing put the crash window between 500mb-1gb on an iphone pro. over 1gb usually guarantees a crash. Not really enough to make a proper game by today’s standards but hey they shipped gta san andreas at 32mb ram on ps2 so I’m sure I can push things further. To answer your webxr webgpu question, no, it still doesn’t mostly work. If you’re interested in reading up on it: https://github.com/immersive-web/WebXR-WebGPU-Binding/blob/m... Post by a Chrome dev: https://toji.dev/2025/03/03/experimenting-with-webgpu-in-web... Webxr webgpu attempts iirc some advanced reprojection for increasing FPS that takes into account the depth buffer. And vision pro at least today has some nausea inducing bugs around that for at least the official immersive web examples hosted on github.io. so its better if a depth texture isn’t supplied today. the fallback reprojection works better more smoothly. For the story stuff, I have similar things setup in my project to essentially reload the game at a certain point in the story but still I personally find HMR to be much faster wherever possible.