Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React Renderer for Three.js

github.com

Post reply on HN
Print view View original

101–110 of 136 posts

Re: React Renderer for Three.js

#101

Post by strbean »

tuckerconnelly wrote: post #95
miklosme wrote: post #5

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 really don't think React will be the go-to tool for VR; it's based on the DOM and trees of function calls, which are both hierarchical, which necessarily means you have the gorilla-banana problem. If you have a coffee cup on a table in VR, is that coffee cup a child of the table? How do you move the coffee cup off the table and put it onto another table? Is it now a child of that other table? What about the coffee…

I don't see why an ECS would be incompatible with a DOM tree.

As for the gorilla-banana problem, I would think all objects in a scene would be under the root, with the exception of pieces that make up a thing and rarely separate (wheels on a car, for example).

Re: React Renderer for Three.js

#103

Post by shadowgovt »

nobbis wrote: post #73
nightski wrote: post #67

Earlier quoted context omitted.

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.

You're correct. WebGL does require extra validation compared to native GL, but it's effectively the same API as OpenGL ES 2.0/3.0 and Emscripten handles the translation from C/C++ for you. There's some overhead but it's negligible (assuming you're not making overly redundant API calls.)

And that last part is key: for modern high-performance graphics acceleration, the name of the game is "maximum throughput with minimum API interactions."

If your data isn't structured for fast rendering, it doesn't matter much what language you're using; they'll all be too slow.

Re: React Renderer for Three.js

#104

Post by Jasper_ »

tylerhou wrote: post #100
brundolf wrote: post #41

Earlier quoted context omitted.

> otherwise it would have been pretty widely adopted across the industry I'm not sure that's a fair explanation for why. It's totally possible to come up with new paradigms that are useful even though nobody's thought of them before. I would think the main issue will be around JavaScript's tendency (cultural, syntactic, etc) to casually create and release objects all over the place, constantly. There's nothing intrin…

Practically, if that function is somewhat hot, I wouldn't be surprised if V8 omitted the allocation altogether when generating optimized bytecode — internally, properties on objects already have an "order," so V8 could push each property into the stack in that order/reverse order (depending on calling convention). And if it doesn't yet, that's not a difficult optimization to make.

That requires substantial escape analysis, which I've noticed v8 does not handle too well. There are similar issues with the new for...of iteration protocol which makes a new object on every iteration, and from my experiments it is about 10-15% slower than a C-style for loop and generates actual GC garbage.

Re: React Renderer for Three.js

#105

Post by Jasper_ »

arcanon wrote: post #94

The age of WebGPU is almost upon us. Chrome 94 comes out this quarter. I doubt React will be the major player in this next epoch. It will be something new that can pull off an instant load shared world game.

In my experience ths issue with this has always been asset download speeds, not web frameworks. The lack of a storage solution means we can't ship game quality assets and have things be instant load.. I run a large WebGL application and the Chrome network cache is still my biggest issue ( e.g. this unsolved bug despite me having an 100% repro https://bugs.chromium.org/p/chromium/issues/detail?id=770694 )

Re: React Renderer for Three.js

#106

Post by rock_hard »

Jasper_ wrote: post #105
arcanon wrote: post #94

The age of WebGPU is almost upon us. Chrome 94 comes out this quarter. I doubt React will be the major player in this next epoch. It will be something new that can pull off an instant load shared world game.

In my experience ths issue with this has always been asset download speeds, not web frameworks. The lack of a storage solution means we can't ship game quality assets and have things be instant load.. I run a large WebGL application and the Chrome network cache is still my biggest issue ( e.g. this unsolved bug despite me having an 100% repro https://bugs.chromium.org/p/chromium/issues/detail?id=770694 )

Agree that the framework issnt the bottleneck here but asset loading is!

We have been investing in building ourselves a asset pipeline backend and it’s been a dramatic improvement.

Simply scripting Blender and other tools on a EC2 instance to optimize assets and then deliver them via cloudfront. Works really well

Re: React Renderer for Three.js

#107

Post by chrisco255 »

tuckerconnelly wrote: post #95
miklosme wrote: post #5

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 really don't think React will be the go-to tool for VR; it's based on the DOM and trees of function calls, which are both hierarchical, which necessarily means you have the gorilla-banana problem. If you have a coffee cup on a table in VR, is that coffee cup a child of the table? How do you move the coffee cup off the table and put it onto another table? Is it now a child of that other table? What about the coffee…

https://codesandbox.io/embed/simple-physics-demo-with-debug-...

There's some excellent demos of how this works with this library with a full physics engine. Loads great even on my phone.

Re: React Renderer for Three.js

#108

Post by runawaybottle »

rock_hard wrote: post #106
Jasper_ wrote: post #105

Earlier quoted context omitted.

In my experience ths issue with this has always been asset download speeds, not web frameworks. The lack of a storage solution means we can't ship game quality assets and have things be instant load.. I run a large WebGL application and the Chrome network cache is still my biggest issue ( e.g. this unsolved bug despite me having an 100% repro https://bugs.chromium.org/p/chromium/issues/detail?id=770694 )

Agree that the framework issnt the bottleneck here but asset loading is! We have been investing in building ourselves a asset pipeline backend and it’s been a dramatic improvement. Simply scripting Blender and other tools on a EC2 instance to optimize assets and then deliver them via cloudfront. Works really well

I think we are not verbalizing the elephant in the room. I know game developers have their ship tight and will use the gpu to it’s fullest (the proof is in the pudding).

The thing I’ve been trying say all along is, I want applications using the same renderer at a primitive level.

Re: React Renderer for Three.js

#109

Post by Unit520 »

nightski wrote: post #67
nobbis wrote: post #19

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.

WebAssembly has no access to the outside world at the moment, that is correct. It is only able to call (and be called by) JS.

A C++ application compiled via Emscripten ships (a fairly large amount) of JS glue code that exposes all relevant Browser APIs like WebGL, Fetch or other HTML5 stuff to the actual WASM program. As others commented, for WebGL an additional API translation is applied. If the source targets OpenGL ES 2 (or 3 for WebGL 2), this step has almost no overhead however.

Re: React Renderer for Three.js

#110

Post by tills13 »

mlajtos wrote: post #65
tills13 wrote: post #58

Earlier quoted context omitted.

To clarify, I'm not talking about the ref _prop_, I'm talking about them using the ref as the element.

It’s lowercase, so it will act as plain-old tag. If the name would be uppercase, that would be a bug you described.

hm, interesting. I didn't know that -- I knew about custom tags / variable tags but never knew it _required_ them to be PascalCased. I feel like if I saw code like this come from one of my team members I'd ask them to change the name of the ref.
Post reply on HN