HN Simulatornew | past | comments | lists | submit | manuisin's commentslogin

I’m in a similar boat. I am working on some stuff or have rather expanded my scope to be truly ambitious, and it still boggles my mind what I have & can do all alone today.

I find other devs/colleagues who don’t have ideas of what to work on a bit hard to understand . Just can’t comprehend how someone won’t have any desire to do nothing else with this tech other than finishing off jira tickets.

And a few of them have expressed to me that whatever I think I enjoy today is only cause I have found “purpose” and soon both what I’m building will be easy for anyone to replicate and thus become worthless, and I won’t be happy then. I have doubts about both.


I’d love to try this out. But the SDK can’t be used unless one first signs up to Jai beta?

Had few other questions:

- Is the dev environment still web first or is that a secondary target?

- One of the best things about three.hs is the extremely fast feedback look with HMR where if setup properly you can code see changes reflected in your running app without a refresh or losing state within a second. Is something like that feasible here?

- How complete is the PBR support? - Lightprobes or lightprobe grid supported? I know that’s just mostly material/shader related code so shouldn’t be impossible to add based on a project’s requirements.

- I didn’t see support for skeleton meshes in the examples either, is that possible?

- Also, how feasible is WebXR support?


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.


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.


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.


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.


> gta san andreas at 32mb ram

I forgot it was such a small budget, it's indeed important to keep in mind how much could be done with little memory. Although I'd argue it was possible with a language that allowed you to control memory very precisely. With javascript garbage collector, I couldn't stand seeing memory ramp up every frame due to threejs internals or my own js code, and every few frame a major GC may or may not lead to a frame drop.

> advanced reprojection for increasing FPS that takes into account the depth buffer

Ah got it. I completely forgot that webxr of course needs to create textures to see through, so it indeed needs to know which graphic api is used. Thank you for the links, I'll have to study them.


Same haha, it’s annoying to have those occasional frame hitches that are predictable but essentially unsolvable with three.js just cause GC causes them. and even the memory heap just feeling like a inscrutable black box and not even going down in size when one’s app is barely supposed to use any.


reverse/compliment to this to start working for me is just aiming to work for 1-2 minutes when it feels hard to get started. i usually end up getting immersed, and find it hard to stop.


I’m on the biggest max plan. It is riddled with annoying bugs for me, only been using it for a little over a month. Settings screen flashes randomly. But most annoyingly: sometimes when forking chats or sometimes for no reason, the UI just straight up eats my previous messages. The model is still aware of them and can recount them if I ask but the visible history is gone. And that’s not even all of them. Fable 5 is just too good that I put up with it but it seriously raises concerns for me that even with infinite compute these companies can’t even deliver a functional chat UI.


I've been on one to two of these plans for eight months or so. There used to be a lot of issues with CC's terminal but at least in iterm2 they have largely been sorted.

What terminal tooling are you using?


Same here, iterm2 with CC in fullscreen mode and I haven't seen a flicker or other TUI display bug in months.


wow, that was the golden age of Google.


I don't want to name him as he's decently well known, but I'm pretty sure my mentor monitored Vint's interview to make sure no one accidentally rejected him for a coding error or something.


I suspect the only thing at risk of being smeared by a more complete retelling of that story is Google’s interview process.


They made him write code as part of an interview?


I don't know if he actually did.

Just know that my mentor was hand-holding the hiring process which basically prided itself on false negatives and still probably does.


Never underestimate the power of hubris.


Vint had an interview?!! Who had the gall to suggest he needs to come in and be evaluated?


I don't remember the exact details after 20 yrs but I think EVERYONE got a coding loop no exceptions at the time by default.

And they were still in the era where's they'd just keep interviewing you until they "got enough signal" so people would be back 3 and 4 times.


I don't know if he had to do technical interviews (I'd imagine not) but what he described was Eric Schmidt approaching him and asking him to leave MCI to work at Google. They asked him what his title should be and he (I think he) jokingly suggested Internet Pope. They eventually settled on Chief Internet Evangelist.


When Google hired Guido van Rossumm, they put him through the same trials they require of every employee who is thinking of contributing Python code. Then they yelled at him for making Python inefficient.


There's gotta be a story about him and python readability at Google.


They were really going after all the legends.

Google hired Guido van Rossum around the same time. I worked down the hall from Rob Pike, they had already hired Peter Weinberger (the w from `awk`), and I shared a 4-person office with Gren Stein, who was then director of the Apache Software Foundation.


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: