[yodon]

Hmmm... no support for skinned character models (and looks like a lot of design and implementation work required on many fronts before this could support them). As cool as this is that makes it feel like a toy rather than a real product (even 3D that doesn't require humanoid characters tends to require deforming meshes to meet the visual quality bar customers expect).

I wish instead of trying to make their own renderer they had used their considerable react and coding skills and time to create a React UI for Unity3d and/or Unreal, which are what most serious app developers are using to create VR experiences (and which have pretty terrible/minimal/antiquated UI coding frameworks compared to what React offers)

[yodon]

Looking deeper into the docs, their scene graph/hierarchy design practically screams "I was designed by someone with zero experience designing 3D scene graphs" (I'm approaching this conversation as someone who has done that sort of thing for Disney, for Microsoft's 343 Halo studio, for startups and major effects houses, and as part of the original design process for the Collada open source format used by google earth and others.

Let's start with the <scene> tag, whose docs start out by saying the scene tag represents the camera location. You're not even at V1 and your docs already start out by saying "we picked a name for this but everyone else in the world thinks of it as having a different name." Worse, "scene" is an incredibly important keyword to be able to use in your 3D scene schema, and you've now tied it up representing something that isn't a scene in a way that prevents you from using the keyword to represent obvious future schema concepts (like multiple scenes you want to be able to switch between quickly).

On a more subtle or mathematical front, the handling of transform stacks is designed in a way that provides a small amount of needless advanced functionality for sophisticated/experienced 3d developers (who are not the target of this tech) while offering huge opportunities for needless confusion and errors in the hands of the novice 3D developers who are the target market for the tech. I'm looking specifically at the way in which individual transformation matrices are represented by an order-dependent javascript array of translate, rotate, and scale component "matrices" (putting matrices in quotes because they don't look like individual 4x4 matrices in the code but they act, combine, and commute (or don't commute) like 4x4 matrices). It's hard enough to help a novice programmer/3D developer to wrap their head around local and world space coordinate systems and the impact of non-uniform scaling on child objects. Expecting that novice tech customer to also need to learn about commutative rules for 4x4 matrix multiplication before they can understand why their slightly tweaked sample app is or isn't working is a terrible, needless complexity wrench to throw into the system.

I could go on for pages and pages here, but this isn't the format for that (and the tiny text box on iOS isn't helping), so I'll just say that I absolutely LOVE React and very much wanted to like this, but this looks like it was developed by people who don't even understand what's hard about designing a good 3D schema, much less how to address those challenges.

[TFortunato]

On this topic... this is something I've wondered a bit about before (logical representations of 3d scenes -- interested as someone who comes from the robotics world, and curious how the people who did video games, VR, graphics tools, etc. thought about this stuff).

Obviously not the same use case, but I've tried looking before for good information on how scene graphs are structured and used, and haven't found much out there that was useful for a beginner who was interested in learning the details. If you have any resources or stuff you would be willing to share, or a well designed library that does it right (any language), I'd love to know about it!

Thanks!

[yodon]

There are surprisingly few good representations for either 3d assets or 3d scenes.

Lots of people are pretty excited about the Universal Scene Description format that Pixar published and open sourced. It's great if you're a big film animation studio looking to manage huge scenes for offline rendering but it's explicitly not optimized for any of the kinds of speed/memory trade offs required for realtime rendering applications.

There are a couple efforts underway at the Khronos group that have lots of key folks from the Collada effort involved and there's a chance they'll come up with something good but this sort of schema design is such a subtle and forward-looking task that I personally am not optimistic about an open source effort being the first to get it right (you're trying to design a data format people will want to use two decades from now without getting trapped in a vicious cycle of analysis paralysis that can prevent you from being able to ship something usable today quickly, it's much like a language design problem where eventually you want to open source it but even then you need a Guido or an Anders or similar to guide the effort onto a good long term arc)

[andrewmcwatters]

Every time I see webdev encroach on 3D or gamedev here, it ends up a spectacular mess for developers in other fields to gawk at.