I wanted to see how far modern WebGL2 could actually be pushed, so I built a fairly large 3D game client around it.
Large worlds, GPU skinning, custom shaders, lighting, fog, particles, UI and moving environments, all running at 60+ FPS in the browser.
WoW 1.12.1 was basically my test case.
Hi everyone,
Not trying to promote anything here, just want honest feedback from people who understand render loops and WebGL far better than I do.
I have been building a free, open source, MIT licensed React game engine called CarverJS. It sits on top of Three.js and react three fiber, and my main hook for per frame logic runs in stages with priority ordering, something like an early update for input, a fixed update for physics, a general update stage, and a late update stage for camera and UI syncing. After all of that runs, react three fiber renders the scene automatically.
For anything that needs to be deterministic, like physics, I run it on a fixed timestep accumulator at a fixed rate instead of tying it to the raw frame delta. I also cap the maximum delta value so that if someone switches tabs and comes back, the simulation does not try to catch up all at once and spiral out of control.
What I am unsure about is whether staging updates by priority like this is actually the right mental model, or if I am overcomplicating something that could be simpler. I am also not sure if leaning on the renderer to auto render after my update stages is the right call, versus controlling the render step myself.
Everything here is completely free, open source, and MIT licensed, there is no paid version or hidden catch, I am just trying to figure out if the underlying approach holds up. If any of you have built your own game loops on top of WebGL or Three.js, I would like to know if this priority staged, fixed timestep approach is reasonable, or if there is an obvious mistake I am not seeing. Genuinely looking for criticism, not reassurance.
