12 ms·

> Can we represent space in the DOM? Why would you want to represent this in DOM, of all places? It's uniquely unsuited for anything that's not a few paragraph

> Can we represent space in the DOM? Why would you want to represent this in DOM, of all places? It's uniquely unsuited for anything that's not a few paragraphs of text with a few images.

rektide 4y ago
> Why would you want to represent this in DOM, of all places? It's uniquely unsuited for anything that's not a few paragraphs of text with a few images. Your negative bias is showing. That's, just, like, your opinion man. One built around disdain & dislike, and not generally shared. There's no books that publish that opinion. You don't find that limited view abundant in trade publications. Use.GPU is here to enable 3D via the DOM, and is proof positive that this declarative setup is highly powerful. The heirarchical/acyclic-graph structure more than passingly resembles a scene-graph, which is ultra-common in 3d. Since the hierarchy is apparent, bindings all just work: > The shader snippets will end up inlined in the right places with all the right bindings, so you can just go nuts. This is just Use.GPU. It's a huge step up the vast amounts of rote work required to set up bindings in modern vulkan & 3d in general. Barely the tip of the ice-berg. As I said, Use.GPU is a tour-de-force demonstration of the value of Live, which is a much more general & competent way of representing compute on the DOM. Steven calls Live a DSL for DSLs; a small language which can keep representing more, all with common structure & form of the DOM language underneath, a much higher level base for computing that escapes much reinvention along the way. Steven touches numerous times across Live write-ups & this article about how the shape of the DOM is ultra-close to that of Lisp, another blissfully homoiconic computing representation known for it's flexible means of assembling compute. > Along the way Live has gained actual bona-fide <Quote> and <Unquote> operators, to drive this recursive <Reconcile>. This means Use.GPU now neatly sidesteps Greenspun's law by containing a complete and well-specified version of a Lisp. Score I think it's under-ambitious to stop at just Space, and that the DOM's S-exp like nature is a powerful & advanced tool for representing all manners of things. Outside of Steven's work, there's plenty of other material. Work like React-Router are extremely clear & direct means of expressing routing/addressability concerns, far cleaner than any other toolkit I've seen. I invite everyone to keep an open mind, and try to use their brain to escape the limited preconceptions they already know, & to explore openly & with active regard, looking for potential. I think the potential for the DOM is high.
jimmySixDOF 4y ago
But representing the DOM etc inside a 3D space is useful so you don't loose access to the world of 2D information. However there are no good solutions to this at present the Immersive Web Workgroup in W3C are looking at Layers or DOM Overlay which is for AR modes but might support 2D navigation but it seems low down on the priority list due to CORS and other security challenges. https://github.com/immersive-web/navigation https://github.com/immersive-web/navigation
- jaeh 4y ago
  hoisting divs as hud works nicely already, both in ios (webxr viewer) and android (chrome + google play services for ar) you just need a div directly below body, then you can actually enable it as a hud in augmented reality. at the moment we only use it to show announcements to the visitors, but i also have tested buttons with event listeners attached and you can even console.log from there. html <html> <body> <canvas id="three-canvas"></canvas> <div id="hud"> <button>Will be visible in ar</button> </div> </body> </html> js const xrSession = await window.navigator.xr.requestSession('immersive-ar', { // ...requiredFeatures, domOverlay: { root: $('#hud'), }, }) css #three-canvas { z-index: 999; } #hud { z-index: 1000; } edit: use window.navigator instead of W.NAV, my custom "window" global.

> Can we represent space in the DOM? Why would you want to represent this in DOM, of all places? It's uniquely unsuited for anything that's not a few paragraphs of text with a few images.

rektide 4y ago

> Why would you want to represent this in DOM, of all places? It's uniquely unsuited for anything that's not a few paragraphs of text with a few images. Your negative bias is showing. That's, just, like, your opinion man. One built around disdain & dislike, and not generally shared. There's no books that publish that opinion. You don't find that limited view abundant in trade publications. Use.GPU is here to enable 3D via the DOM, and is proof positive that this declarative setup is highly powerful. The heirarchical/acyclic-graph structure more than passingly resembles a scene-graph, which is ultra-common in 3d. Since the hierarchy is apparent, bindings all just work: > The shader snippets will end up inlined in the right places with all the right bindings, so you can just go nuts. This is just Use.GPU. It's a huge step up the vast amounts of rote work required to set up bindings in modern vulkan & 3d in general. Barely the tip of the ice-berg. As I said, Use.GPU is a tour-de-force demonstration of the value of Live, which is a much more general & competent way of representing compute on the DOM. Steven calls Live a DSL for DSLs; a small language which can keep representing more, all with common structure & form of the DOM language underneath, a much higher level base for computing that escapes much reinvention along the way. Steven touches numerous times across Live write-ups & this article about how the shape of the DOM is ultra-close to that of Lisp, another blissfully homoiconic computing representation known for it's flexible means of assembling compute. > Along the way Live has gained actual bona-fide <Quote> and <Unquote> operators, to drive this recursive <Reconcile>. This means Use.GPU now neatly sidesteps Greenspun's law by containing a complete and well-specified version of a Lisp. Score I think it's under-ambitious to stop at just Space, and that the DOM's S-exp like nature is a powerful & advanced tool for representing all manners of things. Outside of Steven's work, there's plenty of other material. Work like React-Router are extremely clear & direct means of expressing routing/addressability concerns, far cleaner than any other toolkit I've seen. I invite everyone to keep an open mind, and try to use their brain to escape the limited preconceptions they already know, & to explore openly & with active regard, looking for potential. I think the potential for the DOM is high.

jimmySixDOF 4y ago

But representing the DOM etc inside a 3D space is useful so you don't loose access to the world of 2D information. However there are no good solutions to this at present the Immersive Web Workgroup in W3C are looking at Layers or DOM Overlay which is for AR modes but might support 2D navigation but it seems low down on the priority list due to CORS and other security challenges. https://github.com/immersive-web/navigation https://github.com/immersive-web/navigation

jaeh 4y ago
hoisting divs as hud works nicely already, both in ios (webxr viewer) and android (chrome + google play services for ar) you just need a div directly below body, then you can actually enable it as a hud in augmented reality. at the moment we only use it to show announcements to the visitors, but i also have tested buttons with event listeners attached and you can even console.log from there. html <html> <body> <canvas id="three-canvas"></canvas> <div id="hud"> <button>Will be visible in ar</button> </div> </body> </html> js const xrSession = await window.navigator.xr.requestSession('immersive-ar', { // ...requiredFeatures, domOverlay: { root: $('#hud'), }, }) css #three-canvas { z-index: 999; } #hud { z-index: 1000; } edit: use window.navigator instead of W.NAV, my custom "window" global.