4 ms·

Jeeeeziz. HTML/JS were designed to display interlinked text documents. Now you can use them for VR. It's like building a spaceship out of bicycle parts. That's

by rayalez 10y ago

Jeeeeziz. HTML/JS were designed to display interlinked text documents. Now you can use them for VR. It's like building a spaceship out of bicycle parts. That's crazy. Crazy cool maybe, but definitely crazy. Love React by the way, will definitely check this out.

lacker 10y ago
I love the line "like building a spaceship out of bicycle parts". Maybe we should use that as React VR's slogan ;-)
- stcredzero 10y ago
  That's a cool idea for a game. Maybe it could be done as a Kerbal mod? Have "etheric traction tires" provide inertialess drives?
  - kbenson 10y ago
    I think Scrap Mechanic[1] may basically be this. I haven't played it, but my son had me buy it for him the other day. I'll be trying it out with him in a day or two. 1: http://www.scrapmechanic.com/ http://www.scrapmechanic.com/
- andreasklinger 10y ago
  +1 for making this your frontpage claim "…like building a spaceship out of bicycle parts" - HackerNews comment
evan_ 10y ago
The first airplane was built from bicycle parts.
return0 10y ago
It's not the first time (or the last). VRML worked in 1996 even
avaer 10y ago
Technically _all_ of our software comes from interlinked text documents. The magic is in the software that eats the interlinked text and makes it real. HTML/JS are no different in this regard, VR or not. I'm constantly amazed and thankful to be living in a world of spaceships built out of bicycle parts.
- lacker 10y ago
  That is another fascinating point, that all of our software comes from interlinked text documents. The reactions to React VR are really leading to some great quotes ;-)
- greysphere 10y ago
  I like this sentiment a lot, as it applies to most computer uses. A couple standout exceptions however are images, videos, 3d models and animations. It's certainly possible to represent these in text, but most uses and tooling respect their visual/spatial content. This seems a major criticism of the 'just use existing web tech to make vr'. The former really was about digesting and emitting text documents, but vr is more about models/layout/animation - is text really the right foundation for the job?
  - meheleventyone 10y ago
    Sort of, binary formats are mostly optimisation for scene data specifically and working with human readable formats is quite normal for content creation. If you can put up with the time taken to parse then it's workable. If you think of declarative vr in those terms it's a lot like a web page where a portion arrives as text that describes the layout of the bulk of binary data for rich applications. Where it gets tricky is for large scenes and/or streaming scene data where generally you need better performance. But this sort of thing could still be pre-baked and live within a declarative wrapper.
    - greysphere 10y ago
      My point isn't so much text vs binary. It's text==1D vs much of VR content which is multi-dimensional. And the more multi-dimensional, the more the most human readable format becomes the non-text version (text -> trees -> images -> models/videos/animations). Honestly even html suffers from the translation between linear-text and the tree-like DOM. Many of the pain points of webdev are dealing with this boundary. Go even farther to scenarios where you'd want to interact with the 2D rep of a webpage and you're completely off the reservation. Imagine using javascript/dom to ask the question "what letter is below the 17th character of this this paragraph", the question almost comes across as absurd! "What about different fonts? What about phones? What if there's an image below, is that 'null' or should I skip to the text?" The question is meaningless! Then again, text selection is exactly this question... On the web we've found some very reasonable boundaries between webpage responsibilities, browser responsibilities, and accepted a large swath of functionality as impossible. In VR those boundaries are still in flux. VR scenes are a combination of all sorts of content, of all sorts of dimensionality, often including temporal components as well. Certainly for storage and transmission 'linear' is the only option, but what is the best working representation? Is it a tree with rich nodes? Well maybe, but that's going to make it that much harder for those nodes to interact. On the other extreme is it a 4d array of temporal-voxels? Probably not until we have petabyte DSL. Imo this is why this is a hard problem, why VRML has never really caught on, why after 25 years of making 3d games/movies there's still no standard scene description, why Facebook is taking a stab at this with this project, and why VR is a pretty exciting place to work :)
swalsh 10y ago
To be fair, it's not exactly the same. HTML doesn't have a "Pano" tag. This is really just a way to describe a VR world, or VR specification in markup. Which is kind of natural.
- BHSPitMonkey 10y ago
  Natural indeed; VR games made with Unity are also defined as declarative trees of objects in a similar fashion. In fact, if you added a "behaviors" prop to all of the React components in this system you would essentially have a basis for porting Unity-like scenes pretty directly (maybe even automatically).

by rayalez 10y ago

lacker 10y ago

I love the line "like building a spaceship out of bicycle parts". Maybe we should use that as React VR's slogan ;-)

stcredzero 10y ago
That's a cool idea for a game. Maybe it could be done as a Kerbal mod? Have "etheric traction tires" provide inertialess drives?
- kbenson 10y ago
  I think Scrap Mechanic[1] may basically be this. I haven't played it, but my son had me buy it for him the other day. I'll be trying it out with him in a day or two. 1: http://www.scrapmechanic.com/ http://www.scrapmechanic.com/
andreasklinger 10y ago
+1 for making this your frontpage claim "…like building a spaceship out of bicycle parts" - HackerNews comment

evan_ 10y ago

The first airplane was built from bicycle parts.

return0 10y ago

It's not the first time (or the last). VRML worked in 1996 even

avaer 10y ago

Technically _all_ of our software comes from interlinked text documents. The magic is in the software that eats the interlinked text and makes it real. HTML/JS are no different in this regard, VR or not. I'm constantly amazed and thankful to be living in a world of spaceships built out of bicycle parts.

lacker 10y ago
That is another fascinating point, that all of our software comes from interlinked text documents. The reactions to React VR are really leading to some great quotes ;-)
greysphere 10y ago
I like this sentiment a lot, as it applies to most computer uses. A couple standout exceptions however are images, videos, 3d models and animations. It's certainly possible to represent these in text, but most uses and tooling respect their visual/spatial content. This seems a major criticism of the 'just use existing web tech to make vr'. The former really was about digesting and emitting text documents, but vr is more about models/layout/animation - is text really the right foundation for the job?
- meheleventyone 10y ago
  Sort of, binary formats are mostly optimisation for scene data specifically and working with human readable formats is quite normal for content creation. If you can put up with the time taken to parse then it's workable. If you think of declarative vr in those terms it's a lot like a web page where a portion arrives as text that describes the layout of the bulk of binary data for rich applications. Where it gets tricky is for large scenes and/or streaming scene data where generally you need better performance. But this sort of thing could still be pre-baked and live within a declarative wrapper.
  - greysphere 10y ago
    My point isn't so much text vs binary. It's text==1D vs much of VR content which is multi-dimensional. And the more multi-dimensional, the more the most human readable format becomes the non-text version (text -> trees -> images -> models/videos/animations). Honestly even html suffers from the translation between linear-text and the tree-like DOM. Many of the pain points of webdev are dealing with this boundary. Go even farther to scenarios where you'd want to interact with the 2D rep of a webpage and you're completely off the reservation. Imagine using javascript/dom to ask the question "what letter is below the 17th character of this this paragraph", the question almost comes across as absurd! "What about different fonts? What about phones? What if there's an image below, is that 'null' or should I skip to the text?" The question is meaningless! Then again, text selection is exactly this question... On the web we've found some very reasonable boundaries between webpage responsibilities, browser responsibilities, and accepted a large swath of functionality as impossible. In VR those boundaries are still in flux. VR scenes are a combination of all sorts of content, of all sorts of dimensionality, often including temporal components as well. Certainly for storage and transmission 'linear' is the only option, but what is the best working representation? Is it a tree with rich nodes? Well maybe, but that's going to make it that much harder for those nodes to interact. On the other extreme is it a 4d array of temporal-voxels? Probably not until we have petabyte DSL. Imo this is why this is a hard problem, why VRML has never really caught on, why after 25 years of making 3d games/movies there's still no standard scene description, why Facebook is taking a stab at this with this project, and why VR is a pretty exciting place to work :)

swalsh 10y ago

To be fair, it's not exactly the same. HTML doesn't have a "Pano" tag. This is really just a way to describe a VR world, or VR specification in markup. Which is kind of natural.

BHSPitMonkey 10y ago
Natural indeed; VR games made with Unity are also defined as declarative trees of objects in a similar fashion. In fact, if you added a "behaviors" prop to all of the React components in this system you would essentially have a basis for porting Unity-like scenes pretty directly (maybe even automatically).