4 ms·

I can't take a 3d rendering framework seriously if it gets bogged down at updating 2000 untextured and non-interacting cubes @ 60 FPS. What on earth is all tha

I can't take a 3d rendering framework seriously if it gets bogged down at updating 2000 untextured and non-interacting cubes @ 60 FPS. What on earth is all that time spent on? Doing ~2000 3x3 matrix ops should take a modern processor a few hundred usec surely? To put the silliness of the 2000 number in context, look here at a showcase of the Unity ECS system from years (!) ago: https://software.intel.com/content/www/us/en/develop/articles/get-started-with-the-unity-entity-component-system-ecs-c-sharp-job-system-and-burst-compiler.html https://software.intel.com/content/www/us/en/develop/article... Their starting setup achieves 16000 textured and complex (relatively) models @ 30fps. Which is already much more than the "optimized" thing is achieving here. And it doesn't "cheat" by pretending to be fast via simply not doing to updates that are expected. And once they apply the various optimizations with memory layout etc... they get to 150000 (!) textured models moving about on screen @ 30 fps. So let's say 75000 @ 60fps, which is more than 35x as many objects, and the objects are much more complex. Am I missing something? Why is "2000 cubes @ 60fps" extraordinary?

Jasper_ 5y ago
You have to remember that this 700ms overhead is not the renderer. It's just setting fields on the underlying Three.JS Cube objects. The Three.JS renderer runs fine, and I don't even consider Three.JS to be a fast renderer. So yes, the overhead of React-Three-Fiber's tree reconciliation is seemingly massive. No, I do not have any answers for what it is doing. Nor do I have any guesses.
- short_sells_poo 5y ago
  Thanks for clarifying. 700ms overhead is massive. It sounds like the approach is just deeply suboptimal for any sort of high performance and complicated 3d scenes. Perhaps that was not their objective...
- mlsarecmg 5y ago
  there were multiple versions of that test, the fist had nothing to do with the subject matter, the ones that people refer to (spinning cubes) had an artificial delay that was added to simulate cpu stress.
  - Jasper_ 5y ago
    No artificial delay was added from what I can find. Here's the example from the tweet [0]. Feel free to tell me where the artificial delay is. [0] https://github.com/pmndrs/react-three-fiber/blob/e3a71baad421a8b431866483d7d519e90c604206/examples/demos/dev/Benchmark.js https://github.com/pmndrs/react-three-fiber/blob/e3a71baad42...
    - mlsarecmg 5y ago
      we're running in circles unfortunately and i've explained where the test you're referring to comes from and what it meant. i've posted the real test and if you want, engage in it. async function test() { const chars = `!"§$%&/()=?*#<>-_.:,;+0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz` const font = await new Promise((res) => new THREE.FontLoader().load("https://raw.githubusercontent.com/drcmda/scheduler-test/master/public/Inter%20UI_Bold.json", res)) console.time("test") for (let i = 0; i < 510; i++) { new THREE.TextGeometry(chars[Math.floor(Math.random() * chars.length)], { font, size: 1, height: 0.5, curveSegments: 80, bevelEnabled: false, }) } console.timeEnd("test") } test() // To really drive it home you'd have to repeat it every two seconds ... // setInterval(test, 2000) how react 18 concurrency works exactly, i think that's not the right place to churn through it. the react team has published tons of reading material as well as public talks.

Jasper_ 5y ago

You have to remember that this 700ms overhead is not the renderer. It's just setting fields on the underlying Three.JS Cube objects. The Three.JS renderer runs fine, and I don't even consider Three.JS to be a fast renderer. So yes, the overhead of React-Three-Fiber's tree reconciliation is seemingly massive. No, I do not have any answers for what it is doing. Nor do I have any guesses.

short_sells_poo 5y ago
Thanks for clarifying. 700ms overhead is massive. It sounds like the approach is just deeply suboptimal for any sort of high performance and complicated 3d scenes. Perhaps that was not their objective...
mlsarecmg 5y ago
there were multiple versions of that test, the fist had nothing to do with the subject matter, the ones that people refer to (spinning cubes) had an artificial delay that was added to simulate cpu stress.
- Jasper_ 5y ago
  No artificial delay was added from what I can find. Here's the example from the tweet [0]. Feel free to tell me where the artificial delay is. [0] https://github.com/pmndrs/react-three-fiber/blob/e3a71baad421a8b431866483d7d519e90c604206/examples/demos/dev/Benchmark.js https://github.com/pmndrs/react-three-fiber/blob/e3a71baad42...
  - mlsarecmg 5y ago
    we're running in circles unfortunately and i've explained where the test you're referring to comes from and what it meant. i've posted the real test and if you want, engage in it. async function test() { const chars = `!"§$%&/()=?*#<>-_.:,;+0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz` const font = await new Promise((res) => new THREE.FontLoader().load("https://raw.githubusercontent.com/drcmda/scheduler-test/master/public/Inter%20UI_Bold.json", res)) console.time("test") for (let i = 0; i < 510; i++) { new THREE.TextGeometry(chars[Math.floor(Math.random() * chars.length)], { font, size: 1, height: 0.5, curveSegments: 80, bevelEnabled: false, }) } console.timeEnd("test") } test() // To really drive it home you'd have to repeat it every two seconds ... // setInterval(test, 2000) how react 18 concurrency works exactly, i think that's not the right place to churn through it. the react team has published tons of reading material as well as public talks.