3 ms·

For Wayland-based 3D VR Compositor in the works: http://GitHub.com/SimulaVR/Simula http://GitHub.com/SimulaVR/Simula Good Wayland tutorials are rare in the wil

For Wayland-based 3D VR Compositor in the works: http://GitHub.com/SimulaVR/Simula http://GitHub.com/SimulaVR/Simula Good Wayland tutorials are rare in the wild. A guide like this would have been helpful when starting this projec several months ago. :]

mncharity 9y ago
When it is useful to point at the future? And when not? Looking back, did all the discussion of whether PCs had a role in homes actually accomplish anything? Or all the "well, there's only the Vatican archive so far, but the WWW is going to be big!" conversations? Or about tablets and phones? People often don't picture design spaces and their critical constraints; and don't track tech changes and their impact on those constraints; and say so many silly things. So here we are again, this time with VR/AR. GNOME, KDE, Qt? Well, I guess Motif still exists. And MUMPS. It was clear in the early 1990's that tablets would be a thing a decade later (eg, DEC was showing a prototype and nice year-vs-performance/size/cost curves), and that mice wouldn't be sufficient. We ended up writing a lot of Java (from 1995) and Objective-C (1985) and C++ (1985). And fought Microsoft over JavaScript. But a lot of known programming language features, which would have helped us, we didn't get to use. I really wish our programming languages today, were a little further along towards not sucking. Because we're about to rewrite the world again. But when/where is it worth taking the time to discuss such?
- shmerl 9y ago
  > So here we are again, this time with VR/AR. Until OpenXR will be ready, there won't much movement in this regard. See: https://www.khronos.org/openxr https://www.khronos.org/openxr
  - mncharity 9y ago
    > Until OpenXR will be ready, there won't much movement in this regard. Maybe. I can't comment on the market economics. But I've learned to be very careful about attributing XR design space constraints. Because such care is often skipped. And I suspect it matters. When Varjo says their high-resolution HMD users will need dual Optimuses, there's an implicit assumption that users will be running Autodesk monsters. When Valve says Vive and WMR require 90 fps and low-variance latency and a gtx 1060, they're assuming immersive gaming. In contrast, I normally run my HMDs at 30 fps on an old laptop with integrated graphics. Using a full-screen web browser as compositor, and a little WebVR-like hack. How? It's remote desktop not gaming; with a ducktaped-on camera for passthrough AR (helps with low-fps tolerance); and no lens correction (also helps); and mixed-resolution 3D rendering; and desktop windows not participating in the 3D rendering. And it's ok. Different VR/AR "markets" have very very different constraints. Silly example: Vive HMDs have an table of their measured OLED-pixel brightnesses. Because individual pixels vary. And the Valve render compensates for that. Because otherwise, as you turn your head, you would notice the pattern. For Valve, that would be a "horrible" (quote) immersion-breaking visual artifact. Gasp. But for me, meh. I don't pretend the screen on my laptop is my desk, and I see no reason to pretend the screen on my face is my office. Sometimes you want to fix annoyances, but sometimes you simply want to get used to them. So yes, XR stacks can be crazy hard. But they can also be pretty easy. And people with markets that require the hard, often speak as if the easy didn't exist. But does that matter? Let's imagine Xmas 2018 gets us inexpensive laptops with discrete GPUs, and an HMD with 2k-pixel-square/eye and rectangular subpixels (for subpixel rendering). And let's say that's still without eye tracking. From the perspective of "hard", that's merely a larger market for low-end VR gaming. But from the perspective of "easy"... that may be tipping point on software dev being better done in XR than on physical monitors. So I look forward to OpenXR. And it seems likely that movement, in some directions, really does have it as a blocking dependency. But as with so many other suggestions of VR hardware and software blockers, perhaps some transformational disruptive change may be possible without it.
- georgewsinger 9y ago
  FWIW, Simula (linked to above) is written in Haskell.
  - mncharity 9y ago
    Apropos the need for better programming languages, > FWIW [...] Haskell Sigh. So the wizziest Haskell programmer I know, has repeatedly done the following. They build a model of the mathematics of a problem domain. And then they mentally/manually compile that down to Haskell. Sometimes extending GHC internals to get an adequate target. He's the compiler. It's a compilation process built of wizzy wet-ware, and Coq, and ... with very little tooling support. GHC is just the compiler target. I'm not good enough to do that. I can't bridge that gap manually. That gap between insightful description of problem domain, and inexpressive language. I can't be the primary compiler, floating unsupported in air. I need a language and environment that has at least some clue what I'm trying to do. That participates and checks and supports me. That has a type system rich enough to directly describe problem domains, to describe math. Not merely a low-level target for a mental compiler. Otherwise, everything I write is still just sculpting kludges. GHC makes a nifty compiler target. All we need now, is a nifty compiler. ;)
Sir_Cmpwn 9y ago
You might appreciate this: https://github.com/swaywm/hsroots https://github.com/swaywm/hsroots

mncharity 9y ago

When it is useful to point at the future? And when not? Looking back, did all the discussion of whether PCs had a role in homes actually accomplish anything? Or all the "well, there's only the Vatican archive so far, but the WWW is going to be big!" conversations? Or about tablets and phones? People often don't picture design spaces and their critical constraints; and don't track tech changes and their impact on those constraints; and say so many silly things. So here we are again, this time with VR/AR. GNOME, KDE, Qt? Well, I guess Motif still exists. And MUMPS. It was clear in the early 1990's that tablets would be a thing a decade later (eg, DEC was showing a prototype and nice year-vs-performance/size/cost curves), and that mice wouldn't be sufficient. We ended up writing a lot of Java (from 1995) and Objective-C (1985) and C++ (1985). And fought Microsoft over JavaScript. But a lot of known programming language features, which would have helped us, we didn't get to use. I really wish our programming languages today, were a little further along towards not sucking. Because we're about to rewrite the world again. But when/where is it worth taking the time to discuss such?

shmerl 9y ago
> So here we are again, this time with VR/AR. Until OpenXR will be ready, there won't much movement in this regard. See: https://www.khronos.org/openxr https://www.khronos.org/openxr
- mncharity 9y ago
  > Until OpenXR will be ready, there won't much movement in this regard. Maybe. I can't comment on the market economics. But I've learned to be very careful about attributing XR design space constraints. Because such care is often skipped. And I suspect it matters. When Varjo says their high-resolution HMD users will need dual Optimuses, there's an implicit assumption that users will be running Autodesk monsters. When Valve says Vive and WMR require 90 fps and low-variance latency and a gtx 1060, they're assuming immersive gaming. In contrast, I normally run my HMDs at 30 fps on an old laptop with integrated graphics. Using a full-screen web browser as compositor, and a little WebVR-like hack. How? It's remote desktop not gaming; with a ducktaped-on camera for passthrough AR (helps with low-fps tolerance); and no lens correction (also helps); and mixed-resolution 3D rendering; and desktop windows not participating in the 3D rendering. And it's ok. Different VR/AR "markets" have very very different constraints. Silly example: Vive HMDs have an table of their measured OLED-pixel brightnesses. Because individual pixels vary. And the Valve render compensates for that. Because otherwise, as you turn your head, you would notice the pattern. For Valve, that would be a "horrible" (quote) immersion-breaking visual artifact. Gasp. But for me, meh. I don't pretend the screen on my laptop is my desk, and I see no reason to pretend the screen on my face is my office. Sometimes you want to fix annoyances, but sometimes you simply want to get used to them. So yes, XR stacks can be crazy hard. But they can also be pretty easy. And people with markets that require the hard, often speak as if the easy didn't exist. But does that matter? Let's imagine Xmas 2018 gets us inexpensive laptops with discrete GPUs, and an HMD with 2k-pixel-square/eye and rectangular subpixels (for subpixel rendering). And let's say that's still without eye tracking. From the perspective of "hard", that's merely a larger market for low-end VR gaming. But from the perspective of "easy"... that may be tipping point on software dev being better done in XR than on physical monitors. So I look forward to OpenXR. And it seems likely that movement, in some directions, really does have it as a blocking dependency. But as with so many other suggestions of VR hardware and software blockers, perhaps some transformational disruptive change may be possible without it.
georgewsinger 9y ago
FWIW, Simula (linked to above) is written in Haskell.
- mncharity 9y ago
  Apropos the need for better programming languages, > FWIW [...] Haskell Sigh. So the wizziest Haskell programmer I know, has repeatedly done the following. They build a model of the mathematics of a problem domain. And then they mentally/manually compile that down to Haskell. Sometimes extending GHC internals to get an adequate target. He's the compiler. It's a compilation process built of wizzy wet-ware, and Coq, and ... with very little tooling support. GHC is just the compiler target. I'm not good enough to do that. I can't bridge that gap manually. That gap between insightful description of problem domain, and inexpressive language. I can't be the primary compiler, floating unsupported in air. I need a language and environment that has at least some clue what I'm trying to do. That participates and checks and supports me. That has a type system rich enough to directly describe problem domains, to describe math. Not merely a low-level target for a mental compiler. Otherwise, everything I write is still just sculpting kludges. GHC makes a nifty compiler target. All we need now, is a nifty compiler. ;)

Sir_Cmpwn 9y ago

You might appreciate this: https://github.com/swaywm/hsroots https://github.com/swaywm/hsroots