71–80 of 136 posts
Earlier quoted context omitted.
Totally agree! We switched https://flux.ai from vanilla ThreeJS to R3F and it’s been a huge productivity gain for the whole team! Less code, that is more capable and more reusable! In case anyone is interested, we are hiring: https://coda.io/@flux-ai/flux-jobs
Is this AR/VR? It looks like 2D circuit schematics.
PCB layouting hasn’t publicly shipped yet though
Earlier quoted context omitted.
No; that's not the test in question. The tweet I started the conversation with [0] shows a bunch of cubes, not text geometry. It's not the text geometry test. It's just creating and manipulating a bunch of cubes. Unfortunately, it was removed from the react-three-fiber examples, so it can't be easily run unless you check out an old version of the repo. It contains two switches, one for React vs. Zustand, and the othe…
i've written them. the first pits react against zustand, it naively lets react churn through the whole graph 60 times per sec, you wouldn't do that ever, but zustand could. i initially tweeted it for people interested in that lib. some got it in the wrong throat, so i changed the test to actually pit it against a vanilla counterpart, and they were silent. the real test, contest that please, let the zustand thing go.
That said, I don't know why you entered into the conversation by asserting properties about a different test than the one that started the conversation. I recognize that TextGeometry is slow and CPU-heavy, and that the deferred work approach has some value in helping to manage that, but the cube test we started the discussion with had no artificial delay as far as I can tell, nor do I see it really doing any CPU-heavy work. For cases without any obvious CPU-heavy work, where does the 700ms overhead come from?
> and it stupidly and naively lets react churn through the whole graph 60fps, something you would under no circumstance do
Iterating over 2,000 objects is something we do all the time in game engines (where I'm from and where I work). I've written particle systems that handle far more than that; I just checked the particle system for a game I'm working on, and the simulation time maxes out at And yes, I would argue against React 18 Concurrency's approach as a general design. Deferring work between frames is an incredibly valuable tool, but I don't believe it's something that validly can be done globally, or that it's a solid basis for a 3D framework. It trades low latency for high throughput, and I believe that's a tradeoff that should be made by the application author.
Multiplayer games and VR often require very careful controlled latency, and having unpredictable latency can make your game unplayable, or make someone incredibly motion sick.
We're clearly going in circles on this point; I'll shut up at this point because clearly we're at an impasse, and you're (completely validly) unwilling to discuss the cubes example that started things, which I would prefer to cross-examine in more detail. My approach to performance analysis is to profile things, understand bottlenecks, and come up with targeted fixes before going with more global approaches with large tradeoffs, so I'd be personally be more interested in knowing where the time is spent.
Finally, and this is my experience speaking as a game engine engineer, I think you should think more about how much work you expect to be able to do in one frame, and set your sights there. You can easily update 2,000 objects with minimal overhead.
Earlier quoted context omitted.
As a counterpoint, I've enjoyed building VR on the web using C++ (with WebAssembly/WebGL/WebXR) and not having to touch the DOM or JS, see: https://twitter.com/nobbis/status/1425266634982248451 Benefits include complete control at frame and pixel level, being cross-platform (same code runs on web, iOS, macOS, Linux), and having access to third-party C/C++ libraries for 3D graphics.
I have not put a lot of time into learning WebAssembly. But isn't WebGL a JavaScript API? Meaning wouldn't you be going from WebAssembly -> JavaScript engine -> WebGL? I was under the impression WebAssembly had no access to the outside world and could only access the relevant JavaScript APIs. But if it is true you can basically do WebAssembly -> native GL then that would be amazing.
There's some overhead but it's negligible (assuming you're not making overly redundant API calls.)
Earlier quoted context omitted.
i've written them. the first pits react against zustand, it naively lets react churn through the whole graph 60 times per sec, you wouldn't do that ever, but zustand could. i initially tweeted it for people interested in that lib. some got it in the wrong throat, so i changed the test to actually pit it against a vanilla counterpart, and they were silent. the real test, contest that please, let the zustand thing go.
Ah, so you're @0xca0a. Sorry, I didn't recognize you at first. The examples and documentation I'm quoting at you are your own; my mistake. That said, I don't know why you entered into the conversation by asserting properties about a different test than the one that started the conversation. I recognize that TextGeometry is slow and CPU-heavy, and that the deferred work approach has some value in helping to manage tha…
try racing game for instance: https://twitter.com/0xca0a/status/1400164834243719173
or space game: https://twitter.com/0xca0a/status/1184586883520761856
you won't find react in the browsers perf readout except for short blips when the tree structure is changed. you do not update fast things with setState. since games are render-loop driven, you mutate, and that is also how r3f works.
as for react 18, yes, it works global. the entire component tree is virtual and can be prioritized. you could say, this thing back there is less important than physics driving my rocket, defer please. this will be an incredible tool for games going forward.
Earlier quoted context omitted.
I've built "vanilla" Three.js projects, and worked with react-three-fiber. It is incredibly useful. Having a new set of "primitives" that map to three.js objects and being able to render them in a React application makes so many things easier. It's also just way less code to write compared to standard three.js. RE: animation performance, I haven't had any issues with it. I presume either they're doing a bunch of opti…
It’s just what you’re rendering is getting nowhere near pushing the limits of what can be done with the gpu.
R3F gets you up to speed really quick and helps to easily onboard a larger engineering team and stay productive
At some point your scenes will become complex enough that you will want to start using instanced meshes or just move all critical things into shaders all together…and you totally can do that.
In our case r3f made these performance optimization even easier because it’s so modular
How are they making custom Tags with lowercase names. I assumed react would render that as native tags.
but they also allow you to make your own renderer (https://github.com/facebook/react/tree/main/packages/react-r...) which then defines its own elements. you can try a mini threejs renderer here: https://codesandbox.io/s/reurope-reconciler-hd16y
Earlier quoted context omitted.
As a counterpoint, I've enjoyed building VR on the web using C++ (with WebAssembly/WebGL/WebXR) and not having to touch the DOM or JS, see: https://twitter.com/nobbis/status/1425266634982248451 Benefits include complete control at frame and pixel level, being cross-platform (same code runs on web, iOS, macOS, Linux), and having access to third-party C/C++ libraries for 3D graphics.
I have not put a lot of time into learning WebAssembly. But isn't WebGL a JavaScript API? Meaning wouldn't you be going from WebAssembly -> JavaScript engine -> WebGL? I was under the impression WebAssembly had no access to the outside world and could only access the relevant JavaScript APIs. But if it is true you can basically do WebAssembly -> native GL then that would be amazing.
[0] https://github.com/emscripten-core/emscripten/blob/main/src/... [1] https://github.com/emscripten-core/emscripten/blob/main/test...
When AR/VR finally happens, UI developers will have to deal with complexity from a completely different paradigm. For me, React's biggest strength has always been its ability to organize complexity into a manageable order. Combine this with the large pool of developers and extensive ecosystem, I think React will be the go-to tool for AR/VR apps. For this reason, I'm super hyped for R3F.
I think they need to take a very serious and hard look at performance before it can go anywhere near VR (where rendering speed and stability are paramount). I'm sure it works for simple things and can handle GUIs fine, but the overhead seems huge currently.
Earlier quoted context omitted.
I've built "vanilla" Three.js projects, and worked with react-three-fiber. It is incredibly useful. Having a new set of "primitives" that map to three.js objects and being able to render them in a React application makes so many things easier. It's also just way less code to write compared to standard three.js. RE: animation performance, I haven't had any issues with it. I presume either they're doing a bunch of opti…
It’s just what you’re rendering is getting nowhere near pushing the limits of what can be done with the gpu.