It's a page about a VR headset, but neither this page nor the 'shop' page that lets you waitlist it has any pictures of the thing even by itself, let alone someone wearing it. What an absolutely bizarre choice.
I've been following SimulaVR/Simula for a while now, but really did not want to buy a (legacy) HTC Vive headset. This idea of a standalone Linux machine in a headset is something I'd definitely put some money towards given a bit more detail and timelines.
Also pretty excited by John Carmack's recent tweets on sideloading stuff to the Quest. It feels like that would provide a much bigger opportunity for this project (cameras and all), than building/shipping new hardware.
They're pretty cheap second hand. I recently got one for €200, including base stations (forward-compatible to a point) and "pro" audio strap. It's my first VR headset though, I understand not wanting to spend too much on something you already have a better version of.
Also, the Valve Index is pretty much last (tethered) gen.
I sincerely hope VR will change the way we compute one day, but the wait will be decade or more, as the progress is small and incremental. Unless everything turns out to be proprietary, in which case it'll be never.
For oculus quest 2 there is already a focus on office work. From the start we've had Virtual Desktop and from v28 software update Oculus itself has had several office focused moves.
I have played around with it, and the resolution just isn't there. The desktop space in VR is ironically less than on a laptop, because every window has to be massive to be usable at all. In a future with 2x4K res or something in that ballpark, this might be interesting.
I suppose that's an alternative use case for the tech - to simulate and get an understanding of how to build UX that is friendly towards those with poor eyesight. Haha.
For a work VR headset to work I think you need a couple of things.
One is that it needs to be comfortable enough to wear for long periods of time. I usually get quite warm when wearing one. You also often end up with impressions on your face. This is fine for gaming or shorter sessions but would be a distraction if trying to focus for longer periods of time.
It would also need to have a higher resolution than most (all?) current VR headsets. Text needs to be huge so even though you can have lots of virtual screens you can't fit much on each.
Finally, I imagine that there could be a more innovative interface than just screens in a virtual space. Something that embraces the close-to-physical-reality illusion of VR.
Resolution is the killer. The distance I'm currently typing this on my 32" monitor is much larger then the virtual draw distance I can "see" in VR at current resolutions.
Regarding comfort: I have been curious whether you could take the weight off the head by suspending the headset off the back of a chair so it "floats" at face level via a tether or something.
The issues you're presenting seem real for some, but enthusiasts seem to be making it work[1: post from yesterday].
I like the call in your last point, but personally I think an innovation like 360 degree resizable and movable windows is a reasonable step up from where we're currently at. It would be nice to integrate the work we do into physical space a bit more though. I've wondered about doing practical programming work in an infinifactory-type[2] interface. I don't think it's necessarily a good idea, but it'd be fun to see attempts at no-code tooling embedded in the space.
No, you will still work 8 hours, maybe even 10; it's the great paradox of productivity increases: e.g., teachers had to write way fewer reports before the computers became ubiquitous but when they did, the amount of reports increased slightly out of proportion so that teachers now spend more time on reports than they used to. Progress!
I'm glad someone pointed this out. What is it with this obsession to be 1000x productive all the time? I will not get paid more for it, will I?
And how is this going to make me more productive anyway? By removing "distractions"? I doubt anything can make me solve problems twice as fast as I already do, let alone 10x. This is ridiculous.
Right, and it's most important that text be crisp. Maybe they could re-render all of the visible text every frame with the VR perspective matrix, so you could have helmet-pixel-sharp antialiasing and hinting.
Comfort is a bigger blocker. Headsets with a high enough resolution already exist, but they are too large and uncomfortable to wear for more than a short session.
I'm very keen for this market to open up, but we need to talk about the quality of the desktop before moving on.
On the website, the demo has the person drinking coffee, the youtube window is the wrong ratio, the text is too tall. For me, I really want picture perfect rendering before jumping. I don't want to look at badly rendered stuff, its part of the reason linux was so hard back in the day, getting your text to render and screen resolution to work right.
Now, for me, it looks like I can fit about as many terminals on "screen" as I can on two 1280x1024 screens. In all the demos, there are at most 5 windows open. On my current screen I have one browser, and 8 terminals, and there is still loads more space.
The thing that makes me a little sad is that we still all appear to be stuck at rendering everything on the inside of a sphere. If we are in VR, then we don't have to limit our selves to laying out windows on a single primitive. Where are the virtual shelves? where is the quick change, what about hotspots to bring groups of windows back into near field.
We have unlimited z depth, surely this is time to start using it? unlike a normal screen, we have parallax and gaze sensors, we really need to start using them.
(it looks like they don't have room tracking, so feels like they have limited 6dof source: coffee video, I'd expect much more sideways translation if they had proper headset tracking)
Maintain context. I might have several terminals up, each ssh'd to a different server. At least one terminal per software project. It helps that I use a tiling manager, so I can keep them all visible at the same time.
In Emacs I have tens of eshells open, not to mention SSH sessions, etc! I use one shell per task and then context switch using Emacs buffer switching machinery.
depending on the project, it'll normally be browser for reference (or if its web based testing as well, but thats rare)
then I have about between 1/2 and 2/3rds of the screen space left to have terminals in.
I'll have one/two long terminals open with vim for the main file(s) I'm working on, then 1-4 smaller terminals for running the program/tests. if its a big project, then more terminals for reference (ie library one, library two etc.).
Think of it more as having a really big desk, with loads of copies of the same reference book open to different pages. Its quicker to glance than it is to alt-tab. For me (and i'm not claiming this is a universal trait) that flash of screens where we switch context from one full screen to the other makes me loose context on what I'm working on.
I have virtual monitors as well, all split into contexts, so one will have email/slack/$messenger one will have "personal" internets (ie timewasting sites) and a professional browser, thats logged into company services. If I'm doing graphics, then drawing/editing screens as well.
I used to be a proponent of many monitors. I bought a matrox parhelia new to support triple monitors when they came out. (yes I am that old). However due to the way my mind works, I found that with three screens I would end up in a spinlock with two browsers open, one in each monitor, and not do any work.
My eyesight is bad, and I use a 15" laptop with about 300 views open at a time. I feel no need for a bigger screen.
I keep one window on screen at any time, full screen. I use 2 sets of 16 virtual desktops, tmix, emacs and brave. Maybe 10 instances of each app, and of within each maybe ten tabs. So that's a total of about 300 windows. It gives me zero visibility problems. I much prefer using my hands to change whatn I'm looking at instead of my neck.
Vim can, but why in the world would I have vim do that itself when that means I have to learn/use both vims windowing system and my window managers windowing system? What advantage does it give me...
I spend more time interacting with Emacs than I do my window system, so I am quite happy arranging terminals, database clients, REPLs and code inside that, and there are huge advantages to all those being able to communicate frictionlessly. It'd be very annoying having to constantly multitask.
I feel like emacs makes a much better case for this than vim, because it actually takes advantage of everything being one program (at the expense of rewriting the world, and basically being it's own operating system).
I think they'll get there. This is still early, they're probably focusing on the core rendering right now.
> If we are in VR, then we don't have to limit our selves to laying out windows on a single primitive. Where are the virtual shelves? where is the quick change, what about hotspots to bring groups of windows back into near field.
From playing VR games, actually the best implementation of this I've seen is to put them on a "belt" of sorts. Like an oversized toolbelt (so they're away from your body) so you can simply look down and grab stuff.
Spheres do work well, though. It keeps all the text at the same distance from you, so the edges aren't out of focus. I suspect it also makes zooming easier since you can just move the camera closer. If you have an actual 3D space, moving the camera can get weird, and the camera being weird in VR is really disorienting.
> (it looks like they don't have room tracking, so feels like they have limited 6dof source: coffee video, I'd expect much more sideways translation if they had proper headset tracking)
Not having room tracking doesn't prevent movement. You'd just move with wasd like before. Not having room tracking means you can move your chair 6 inches without all your windows getting shifted. Likewise, you can stand up in your standing desk without re-adjusting all the windows.
I would love to see VR/AR work cross paths with the concept of the "Memory Palace". Maybe groups of folders, websites, screens etc could be set up to be in different rooms of your house. Home automations could be configured to be in sync with your movement around the house.
Every time I stand up and walk to a different room the screens move to the periphery, and return when I sit. When a loud sound is heard, a notification identifies the sound and asks if you want to replay it. Etc.
I'm not sure the fullscreen video in the page background helps to promote working with a VR headset. It's lagging, tearing and blurry. If I get dizzy by just looking at the page, how on earth would I last more than 5 minutes in a VR office without throwing up?
The killer "corporate" app for VR in my opinion would be some kind of teleconference app. I absolutely HATE trying to have interactive brainstorming/collaborative design meeting remotely. There are various pancake tools, but none really compare to the experience of 2 people standing in front of a white board, and making wild motions with their arms that seemingly both people understand while drawing on a board.
Some of the experiences I've had in VR are unrivaled by any pancake game i've ever played for that very reason.
I'm not 100% sure I want to be in VR all day all the time. But VR should have a place in at the very least a remote workforce.
I absolutely agree. I'm very much a whiteboard hand-wavier guy. I explain with gestures as much as I do with the actual drawing (might be an Italian thing too).
That said, this "pancake" problem reminded me of the old Wii head-tracking project.[1] There might be an interesting hybrid opportunity with that idea and 3d avatars. I feel like the head-tracking hack never really took off because it only worked as a solo experience. But since remote work is mostly us all individually sitting at a computer I could see it working better.
Combine this idea with a large dedicated monitor/tv and now you have something that would literally just feel like a window/portal to the person you're talking to.
I'd expect conventional live footage of whiteboard hand-waving to wildly outdo VR for the entire foreseeable future. If you need two guys hand-waving in different rooms, focus the extra tech on the whiteboards, to somehow merge their content.
plug: this is along the lines of our thinking, at ShareTheBoard. rather than kill the whiteboard with VR, we use vision to give it new tricks.
step 1 is real-time content digitization and obstacle avoidance (available now). step n involves synchronizing cameras and projectors for a deviceless AR experience - true "remote whiteboarding." we've completed this in laboratory conditions, hope to release it next year.
Is it possible to use this with Teams or Zoom or does everyone need a new app? This seems like an ideal plug-in or app to use with those since it's essentially just a "filter" app from the presenter's side. Using your app as the video source seems like it'd be straightforward to do.
Indeed, most of our users simply open our app, then use Teams/Zoom/Meet to share that tab using the built-in screen-share. That gives you content legibility but none of the other benefits: by hitting our meeting link (in browser: no sign-up/download needed), all viewers can also save board contents at any time and even add digital content of their own.
Can't do that second part "through" videoconferencing apps - not without a deeper integration (read: participation with the companies in question). It's on our list of possible developments but will require dancing partners on the other side.
It's important to remember that this is on the way to being an MVP. It's not a finished, polished product. This is HN. Don't we like people hacking on startups any more?
I think it looks like a really positive first step. Yeah, the resolution is too low but that's solvable with a better headset. It's a bit laggy, but that's probably due to recording video of VR being hard. The windows are weird sizes, but that might be user choice. Heck, I personally don't want to code things floating in space, but that's just a matter of choosing a different background. All those problems are solvable.
There are loads more problems that are also likely solvable too. And maybe some that aren't. We don't know yet. I'm glad someone is working on the problem to find out. That's far better than not having, maybe, one day in the distant future, a VR option to use for work.
> It's important to remember that this is on the way to being an MVP. It's not a finished, polished product. This is HN. Don't we like people hacking on startups any more?
It doesn't need to be a finished product. Just give FOSS developers something to work with, and the finished product will automatically emerge ;)
Sometimes true, but sometimes not, it depends on how the hardware is designed to integrate with software. The Leap Motion failed miserably (my opinion) at this by expecting software to figure out where it fit as a human interface device rather than having a strong opinion based on software/reference drivers.
I think the conclusion is unfair. It IS an existing VR option for work right now if you have a compatible headset. No it's not perfect and many people will not want to stay in there for a long time with existing headsets. But that doesn't mean it's not an option.
I think that viability of an "option" is assumed. It's not viable in general today. I'd be surprised if there is even a single person that has actually fully replaced their conventional workspace with a VR desktop like this.
Agreed, I'm happy to see people working on this, but with VR there are so many limiting factors/dealbreakers that I don't envy anyone playing in this space without massive resources to tackle them all.
For me, the MVP for working in VR is replacing my fairly standard monitor setup (3x24-27", 12-14px text size, 60hz). I don't really care about virtual meetings or whiteboards or environments, I just want to make the transition to having what would be unreasonable/impossible in hardware (dozens of resizable windows I can easily rearrange and fill my whole FoV with. Nail that and I will gladly drop a couple of grand on it.
From the wiki on their Github [1] and looking at Github contributors, this is a 3 person project (and no Github commits since June 2021). They're clearly not making their own VR headset, they're using something off the shelf (from other comments seems like an HTC Vive). Making the website ambiguous about this is just confusing.
I saw a couple YC apps in there, so I'm sure they had to be ambitious, but thinking realistically there's a big difference between being:
I suppose it’s a difficult field to enter? Idk if it’s needed but my naive assumption is that I won’t be able to contribute without having a VR headset.
Speaking of, what’s a good VR headset that I can purchase in ‘21 that does not have anything to do with FB? I enjoyed playing Alyx on the Index so that’s my prime candidate for now, for both gaming and productivity.
We're making our own headset. Nothing off-the-shelf was available or satisfactory.
Most of the recent Github commits are in the dev branch, but right now it's 90% George working on the code. I'm busy on the hardware and wrangling vendors side, our third employee is the ME so no coding there.
Such a forgotten classic. I remember it took me hours to get the dependencies on my suse right and once it worked I was so overwhelmed by what's possible. It was so weird and beautiful at once.
Compiz desktop cubes [1] and native zooming were all the rage back then as well.
Fun note, almost all of it is written in Haskell. If I remember correctly they've also done a bunch of stuff that helps Godot, or at least something to do with the Haskell bindings. Very accessible guys, I once asked a question on the gitter, and got helpful replies almost immediately.
If it's written in Haskell, it's highly likely that it'll be far harder to modify than something written in, well, not-Haskell.
Haskell might be easy when you get the hang of it, but the vast majority of programmers haven't, and the language ideas are alien compared to the mainstream ones (Python, JS, C++, Lua).
The design of Haskell also encourages users to be very clever, which only makes code harder to read.
Haskell reduces the size of the developer pool, but increases their productivity (the Haskell ecosystem is enormous and astoundingly solid given the number of devs in that space), and also makes the docs a joy to read.
This. Im wondering how this is possible, high haskell reusability / easy to get familiar with codebases & extend them when familiar with hs or being a genius? I guess its the first
Strict static types reduce a giant class of errors (including most of the footguns I'm always triggering in my dayjob with Python). Purity reduces another giant class: It makes it easy (indeed kind of forces you) to restrict your IO to a thin, top-level error, hence keeping the vast majority of the code purely functional and thus easy to test.
Exactly how Haddock produces such wonderful automatic documentation, I don't know, but good God it does. The strict static types clearly help -- you can see exactly what every function inputs and outputs, what every data type needs, etc. And then you can jump to the definitions of any of those things, and if need be (almost never), the source code that defines them.
And what if it was the other way round? A steeper learning curve means that only the brightest, more motivated individuals can enter the realm, and those individuals are capable of doing more than the average developer.
I don't think writing Haskell ever gets easy, at least it hasn't for me over about ten years. Writing good code in any language is hard, but Haskell makes it harder to write bad code.
I have to write object-oriented bullshit all day for my job, if I started a fun new project like this I'd happily choose Haskell. If people who only know JS and won't learn anything new can't contribute then that's a cost worth bearing.
> If people who only know JS and won't learn anything new can't contribute then that's a cost worth bearing.
I think this is an unfair and unnecessarily-snarky take.
My list of languages is fairly long these days. I’ve written php, ruby, and go in reasonable volume for mostly personal projects. I used to teach embedded C at uni. I write python professionally every day. Recently I’ve even started playing with rust (and had some success thanks to the awesome book). The list is far longer, these are just the ones used the most. I’ve been writing code in some capacity for the last 20 or so years (first self-taught, then at university, and more recently professionally full-time).
Despite all that, and not for lack of trying, for whatever reason purely functional languages are the only ones that elude me. Every couple of years I try Haskell or erlang again and I just get nowhere fast.
Maybe it’s because I was never very good at maths, maybe it’s because I haven’t had sufficient motivation, or maybe I just haven’t found the right monad blog post to convert me. All I know is Haskell remains chronically out of reach to many experienced and inexperienced devs alike.
Yeah, I don't really see functional programming being that great of a fit for VR. I mean, the 3D environment is inherently object-oriented and stateful. And you're working in an extremely performance intensive task, such that pure immutability really starts to get in the way. Also, Haskell's lazy evaluation has a bad reputation for poor and/or unpredictable performance. It's better to have a higher mean execution time with an extremely narrow standard deviation so you can plan your frame budget and not occasionally blow it, dropping frames all over the floor.
What you want is something that puts the movement of memory between processes and threads front-and-center. Half the difficulty of writing a 3D rendering engine is coming up with a good memory model for loading 3D models and textures to push them onto the GPU. That really sounds more like Rust's wheelhouse than Haskell.
I disagree on the 3D environment being inherently OOP. ECS, a popular paradigm in 3D and 2D game making, can map pretty well to functional programming.
I would pick Rust as well here but just because Haskell has exceptions and it has less emphasis on safety and less pleasant defaults than Rust. In order to get the Haskell I want I need several pragmas and a different prelude...
I would say Rust is pretty functional itself, though.
What? ECS is soooo object oriented. It's basically the modern OOP attitude of poo-pooing inheritance in favor of composition, writ-large. Yet, somehow, all the components have deep inheritance hierarchies themselves, so [shrug].
> for whatever reason purely functional languages are the only ones that elude me
That's because all of the languages you listed are really similar conceptually. PHP, Ruby, Go, C, and Python (and others you didn't list: Java, C++, C#, Perl, Lua, JavaScript) are far more similar to each other than they are to Haskell - they have different syntax and slightly different semantics, but for the most part they're all in the same language family. It's much easier to pick up Java after learning PHP than it is to learn programming for the first time - or, alternatively, to learn a structured language after having written unstructured BASIC for your whole life.
Lisp users (of which I am one) frequently talk about how all of those languages are "basically the same" - but for all that, Common Lisp is still way more similar to Python than it is to Haskell (which I've also tried and failed to learn).
Also, Haskell isn't just a functional language - it also is a lazy language, which means you have to now learn two new ways of thinking at once.
Erlang is similarly in a different world from the mainstream imperative-OO languages, but I don't think that being functional is the only thing that makes it hard to learn - it also has a fundamentally different model of concurrency (as well as being designed around concurrency) that is difficult to learn if you're just used to pthreads.
Similarly, I think that Prolog (logic programming), Adga (is it a programming language, or a theorem prover?), Rust (maybe; lifetimes), and Forth (stack programming) all present unique challenges to people like us that have only written Python/Ruby/Perl/Go/Lisp...
Yeah, I agree with all this. Amusingly, from your extended list I have also written a non-trivial amount of Java, JS, and Perl too which perhaps demonstrates your point further.
I hadn’t before considered the laziness part of Haskell, perhaps I simply hadn’t made it far enough to be aware of it before. Maybe that perspective will help me next time I feel the urge to try out fp again.
fwiw to your point about other languages, Rust has certainly presented a challenge due to new paradigms but it’s never felt insurmountable. The rust book is truly an incredible piece of writing that imo makes the language so much more accessible than it would otherwise be.
I find Haskell to be absolutely impenetrable, but I run XMonad and work with my config file just fine.
So users will probably be able to hack together what they want, but they may struggle to grow a large developer community. But that can still work out okay.
> The design of Haskell also encourages users to be very clever, which only makes code harder to read.
This is BS - find me some "clever" code in one of these Haskell projects and I bet it's not clever but simply using a set of abstractions there maintainers like and grok and the reader just doesn't understand.
Maybe I'm being overly pedantic but I think that's a textbook description for overly "clever" code in any language- it makes perfect sense to the authors but is nontrivial for the reader to understand
Except in Haskell, it's not just some pet bit of code by the authors. It's a shared abstraction with well understood laws and theoretical underpinning.
What people call "clever" code in mainstream programming is not in any way similar to the Haskell being referred to.
Luckily in the Haskell world, we don't ascribe negative attributes like "cleverness" to code that isn't outsider-friendly. We gain a lot by not requiring that all our code is understandable by a mainstream programmer.
I often find myself wondering what the 'killer app' of purely functional programming languages is. For the longest time I assumed they would become much more popular as multi-core cpus proliferated, but pretty much every purely functional language out there is relegated to a dusty corner.
The absolute killer app is compilers, static analyzers, and similar. Other languages don't even come close for anything in that space.
However, I think that purely functional languages are useful for basically everything. Haskell is my general purpose language of choice, unless libraries or system constraints force me to another language.
We're evaluating 2880x2880 displays right now. With our upcoming optics, we can get up to 45PPD in the foveal area if everything works out as planned (they're basically a variable magnification optic).
Depending on vendor support we might have to go to 2.5k displays from another vendor, but hopefully we can get the support we need for the 3k displays.
Ok nice, that's better than G2. What about IPD? All HMDs have too narrow IPD for me, what is the challenge with offering wide IPD? The Human IPD range is 51 to 77. Quest 2 offers only up to 66 mm, the Index up to 70mm.
How's the lens glare?
Can you use Simula currently with Quest 2 air link or do you need to be tethered?
EDIT: So yeah, this is Linux only? There will not be a Windows version?
We're trying to hit as wide of an IPD as feasible. Right now with the BOE displays we can hit an IPD of 55-77mm, but the design isn't finalized yet.
Lens glare, too early in the design to tell yet. I'll have more info in late Oct.
It's Linux only as Windows doesn't have the APIs for what we're doing (being a window manager, basically). No idea if WSL will work nowadays; definitely not without a lot of finagling.
I feel the same. I'd be ready to pay good money for an AR headset focused on replacing external monitors (no gaming but very good text readability). AR and not VR because I don't want to be completely isolated from my surroundings.
And, if luminosity would allow, working outside with it would be a dream come true to me!
So much this!. I'm writing this while sitting in my desk, in front of it is my 27in monitor and to the left is my Mac's monitor in on a stand.
Behind all of this is my room's white wall with an area of around 4x2 meters. Imagine if I could change my monitor with an AR version of it that mapped/projected the "desktop" to my wall.
And then, let's say I want to get into a meeting with a colleague to do some diagrams, so we "map" some Whiteboard software into another wall in my room and a wall in my colleague's room. We will be looking at the same and could even "draw" with hand gestures or something.
Pretty cool. Personally, I would love AR for office work. I actually investigated this for my company and got to meet with Microsoft to try the Hololens. Cool stuff. It was too expensive for us though.
224 comments
[ 3.2 ms ] story [ 301 ms ] threadAlso pretty excited by John Carmack's recent tweets on sideloading stuff to the Quest. It feels like that would provide a much bigger opportunity for this project (cameras and all), than building/shipping new hardware.
Sideloading does work on the Quest. The Go work has been a more open OS.
Also, the Valve Index is pretty much last (tethered) gen.
https://portablesimula.github.io/github.io/doc/HiNC1-webvers...
The Quest 2 is already pretty much as sharp as my eyes can resolve - and that's with prescription glasses.
One is that it needs to be comfortable enough to wear for long periods of time. I usually get quite warm when wearing one. You also often end up with impressions on your face. This is fine for gaming or shorter sessions but would be a distraction if trying to focus for longer periods of time.
It would also need to have a higher resolution than most (all?) current VR headsets. Text needs to be huge so even though you can have lots of virtual screens you can't fit much on each.
Finally, I imagine that there could be a more innovative interface than just screens in a virtual space. Something that embraces the close-to-physical-reality illusion of VR.
Regarding comfort: I have been curious whether you could take the weight off the head by suspending the headset off the back of a chair so it "floats" at face level via a tether or something.
I like the call in your last point, but personally I think an innovation like 360 degree resizable and movable windows is a reasonable step up from where we're currently at. It would be nice to integrate the work we do into physical space a bit more though. I've wondered about doing practical programming work in an infinifactory-type[2] interface. I don't think it's necessarily a good idea, but it'd be fun to see attempts at no-code tooling embedded in the space.
[1] https://news.ycombinator.com/item?id=28678041 [2] https://www.zachtronics.com/infinifactory/
Maaayyyybe.
On the website, the demo has the person drinking coffee, the youtube window is the wrong ratio, the text is too tall. For me, I really want picture perfect rendering before jumping. I don't want to look at badly rendered stuff, its part of the reason linux was so hard back in the day, getting your text to render and screen resolution to work right.
Now, for me, it looks like I can fit about as many terminals on "screen" as I can on two 1280x1024 screens. In all the demos, there are at most 5 windows open. On my current screen I have one browser, and 8 terminals, and there is still loads more space.
The thing that makes me a little sad is that we still all appear to be stuck at rendering everything on the inside of a sphere. If we are in VR, then we don't have to limit our selves to laying out windows on a single primitive. Where are the virtual shelves? where is the quick change, what about hotspots to bring groups of windows back into near field.
We have unlimited z depth, surely this is time to start using it? unlike a normal screen, we have parallax and gaze sensors, we really need to start using them.
(it looks like they don't have room tracking, so feels like they have limited 6dof source: coffee video, I'd expect much more sideways translation if they had proper headset tracking)
In general, I often have up to 10 tabs open on Gnome terminal, and a GNU screen session in each with up to 10 screens. Maintaining lots of context.
Within a single GNU screen session, I'll often have a build window, some editing windows for code, editing windows for config files, etc.
depending on the project, it'll normally be browser for reference (or if its web based testing as well, but thats rare)
then I have about between 1/2 and 2/3rds of the screen space left to have terminals in.
I'll have one/two long terminals open with vim for the main file(s) I'm working on, then 1-4 smaller terminals for running the program/tests. if its a big project, then more terminals for reference (ie library one, library two etc.).
Think of it more as having a really big desk, with loads of copies of the same reference book open to different pages. Its quicker to glance than it is to alt-tab. For me (and i'm not claiming this is a universal trait) that flash of screens where we switch context from one full screen to the other makes me loose context on what I'm working on.
I have virtual monitors as well, all split into contexts, so one will have email/slack/$messenger one will have "personal" internets (ie timewasting sites) and a professional browser, thats logged into company services. If I'm doing graphics, then drawing/editing screens as well.
I used to be a proponent of many monitors. I bought a matrox parhelia new to support triple monitors when they came out. (yes I am that old). However due to the way my mind works, I found that with three screens I would end up in a spinlock with two browsers open, one in each monitor, and not do any work.
I keep one window on screen at any time, full screen. I use 2 sets of 16 virtual desktops, tmix, emacs and brave. Maybe 10 instances of each app, and of within each maybe ten tabs. So that's a total of about 300 windows. It gives me zero visibility problems. I much prefer using my hands to change whatn I'm looking at instead of my neck.
However a lot of the time the Vims are there for reference.
> If we are in VR, then we don't have to limit our selves to laying out windows on a single primitive. Where are the virtual shelves? where is the quick change, what about hotspots to bring groups of windows back into near field.
From playing VR games, actually the best implementation of this I've seen is to put them on a "belt" of sorts. Like an oversized toolbelt (so they're away from your body) so you can simply look down and grab stuff.
Spheres do work well, though. It keeps all the text at the same distance from you, so the edges aren't out of focus. I suspect it also makes zooming easier since you can just move the camera closer. If you have an actual 3D space, moving the camera can get weird, and the camera being weird in VR is really disorienting.
> (it looks like they don't have room tracking, so feels like they have limited 6dof source: coffee video, I'd expect much more sideways translation if they had proper headset tracking)
Not having room tracking doesn't prevent movement. You'd just move with wasd like before. Not having room tracking means you can move your chair 6 inches without all your windows getting shifted. Likewise, you can stand up in your standing desk without re-adjusting all the windows.
Plus I'm sure it'll help keep the cost down.
Every time I stand up and walk to a different room the screens move to the periphery, and return when I sit. When a loud sound is heard, a notification identifies the sound and asks if you want to replay it. Etc.
Some of the experiences I've had in VR are unrivaled by any pancake game i've ever played for that very reason.
I'm not 100% sure I want to be in VR all day all the time. But VR should have a place in at the very least a remote workforce.
That said, this "pancake" problem reminded me of the old Wii head-tracking project.[1] There might be an interesting hybrid opportunity with that idea and 3d avatars. I feel like the head-tracking hack never really took off because it only worked as a solo experience. But since remote work is mostly us all individually sitting at a computer I could see it working better.
Combine this idea with a large dedicated monitor/tv and now you have something that would literally just feel like a window/portal to the person you're talking to.
[1] https://www.youtube.com/watch?v=Jd3-eiid-Uw
step 1 is real-time content digitization and obstacle avoidance (available now). step n involves synchronizing cameras and projectors for a deviceless AR experience - true "remote whiteboarding." we've completed this in laboratory conditions, hope to release it next year.
Can't do that second part "through" videoconferencing apps - not without a deeper integration (read: participation with the companies in question). It's on our list of possible developments but will require dancing partners on the other side.
I think it looks like a really positive first step. Yeah, the resolution is too low but that's solvable with a better headset. It's a bit laggy, but that's probably due to recording video of VR being hard. The windows are weird sizes, but that might be user choice. Heck, I personally don't want to code things floating in space, but that's just a matter of choosing a different background. All those problems are solvable.
There are loads more problems that are also likely solvable too. And maybe some that aren't. We don't know yet. I'm glad someone is working on the problem to find out. That's far better than not having, maybe, one day in the distant future, a VR option to use for work.
It doesn't need to be a finished product. Just give FOSS developers something to work with, and the finished product will automatically emerge ;)
"Finished"? No. Somewhat usable and constantly being updated or rewritten? Probably.
I look at some of the Gnome 3 design choices and I start to question that.
To each their own. You might not be on the left of the S curve for that technology, that's all :)
https://en.wikipedia.org/wiki/Technology_adoption_life_cycle
I'm at the tail of that S-curve for sure, so maybe I'm just get-off-my-lawning. Thanks for sharing.
For me, the MVP for working in VR is replacing my fairly standard monitor setup (3x24-27", 12-14px text size, 60hz). I don't really care about virtual meetings or whiteboards or environments, I just want to make the transition to having what would be unreasonable/impossible in hardware (dozens of resizable windows I can easily rearrange and fill my whole FoV with. Nail that and I will gladly drop a couple of grand on it.
I saw a couple YC apps in there, so I'm sure they had to be ambitious, but thinking realistically there's a big difference between being:
1) A VR headset for work company
2) A VR operating system for work company
3) A window manager for VR for work company
[1] https://github.com/SimulaVR/Simula/wiki/Simula-Master-Plan
Speaking of, what’s a good VR headset that I can purchase in ‘21 that does not have anything to do with FB? I enjoyed playing Alyx on the Index so that’s my prime candidate for now, for both gaming and productivity.
Most of the recent Github commits are in the dev branch, but right now it's 90% George working on the code. I'm busy on the hardware and wrangling vendors side, our third employee is the ME so no coding there.
Compiz desktop cubes [1] and native zooming were all the rage back then as well.
[1] https://heise.cloudimg.io/width/993/q75.png-lossy-75.webp-lo...
Haskell might be easy when you get the hang of it, but the vast majority of programmers haven't, and the language ideas are alien compared to the mainstream ones (Python, JS, C++, Lua).
The design of Haskell also encourages users to be very clever, which only makes code harder to read.
Exactly how Haddock produces such wonderful automatic documentation, I don't know, but good God it does. The strict static types clearly help -- you can see exactly what every function inputs and outputs, what every data type needs, etc. And then you can jump to the definitions of any of those things, and if need be (almost never), the source code that defines them.
I have to write object-oriented bullshit all day for my job, if I started a fun new project like this I'd happily choose Haskell. If people who only know JS and won't learn anything new can't contribute then that's a cost worth bearing.
I think this is an unfair and unnecessarily-snarky take.
My list of languages is fairly long these days. I’ve written php, ruby, and go in reasonable volume for mostly personal projects. I used to teach embedded C at uni. I write python professionally every day. Recently I’ve even started playing with rust (and had some success thanks to the awesome book). The list is far longer, these are just the ones used the most. I’ve been writing code in some capacity for the last 20 or so years (first self-taught, then at university, and more recently professionally full-time).
Despite all that, and not for lack of trying, for whatever reason purely functional languages are the only ones that elude me. Every couple of years I try Haskell or erlang again and I just get nowhere fast.
Maybe it’s because I was never very good at maths, maybe it’s because I haven’t had sufficient motivation, or maybe I just haven’t found the right monad blog post to convert me. All I know is Haskell remains chronically out of reach to many experienced and inexperienced devs alike.
What you want is something that puts the movement of memory between processes and threads front-and-center. Half the difficulty of writing a 3D rendering engine is coming up with a good memory model for loading 3D models and textures to push them onto the GPU. That really sounds more like Rust's wheelhouse than Haskell.
GC hasn't been an noticeable issue as a result.
What does it mean for the 3D environment to be inherently object-oriented?
I would pick Rust as well here but just because Haskell has exceptions and it has less emphasis on safety and less pleasant defaults than Rust. In order to get the Haskell I want I need several pragmas and a different prelude...
I would say Rust is pretty functional itself, though.
That's because all of the languages you listed are really similar conceptually. PHP, Ruby, Go, C, and Python (and others you didn't list: Java, C++, C#, Perl, Lua, JavaScript) are far more similar to each other than they are to Haskell - they have different syntax and slightly different semantics, but for the most part they're all in the same language family. It's much easier to pick up Java after learning PHP than it is to learn programming for the first time - or, alternatively, to learn a structured language after having written unstructured BASIC for your whole life.
Lisp users (of which I am one) frequently talk about how all of those languages are "basically the same" - but for all that, Common Lisp is still way more similar to Python than it is to Haskell (which I've also tried and failed to learn).
Also, Haskell isn't just a functional language - it also is a lazy language, which means you have to now learn two new ways of thinking at once.
Erlang is similarly in a different world from the mainstream imperative-OO languages, but I don't think that being functional is the only thing that makes it hard to learn - it also has a fundamentally different model of concurrency (as well as being designed around concurrency) that is difficult to learn if you're just used to pthreads.
Similarly, I think that Prolog (logic programming), Adga (is it a programming language, or a theorem prover?), Rust (maybe; lifetimes), and Forth (stack programming) all present unique challenges to people like us that have only written Python/Ruby/Perl/Go/Lisp...
I hadn’t before considered the laziness part of Haskell, perhaps I simply hadn’t made it far enough to be aware of it before. Maybe that perspective will help me next time I feel the urge to try out fp again.
fwiw to your point about other languages, Rust has certainly presented a challenge due to new paradigms but it’s never felt insurmountable. The rust book is truly an incredible piece of writing that imo makes the language so much more accessible than it would otherwise be.
So users will probably be able to hack together what they want, but they may struggle to grow a large developer community. But that can still work out okay.
This is BS - find me some "clever" code in one of these Haskell projects and I bet it's not clever but simply using a set of abstractions there maintainers like and grok and the reader just doesn't understand.
What people call "clever" code in mainstream programming is not in any way similar to the Haskell being referred to.
Luckily in the Haskell world, we don't ascribe negative attributes like "cleverness" to code that isn't outsider-friendly. We gain a lot by not requiring that all our code is understandable by a mainstream programmer.
However, I think that purely functional languages are useful for basically everything. Haskell is my general purpose language of choice, unless libraries or system constraints force me to another language.
In other words, those problems that don't involve users and the outside world.
Pure languages for pure problems. Impure languages for impure problems. It computes.
From here: https://github.com/SimulaVR/Simula it seems like anything that will run steamvr should do it.
Depending on vendor support we might have to go to 2.5k displays from another vendor, but hopefully we can get the support we need for the 3k displays.
How's the lens glare?
Can you use Simula currently with Quest 2 air link or do you need to be tethered?
EDIT: So yeah, this is Linux only? There will not be a Windows version?
Lens glare, too early in the design to tell yet. I'll have more info in late Oct.
It's Linux only as Windows doesn't have the APIs for what we're doing (being a window manager, basically). No idea if WSL will work nowadays; definitely not without a lot of finagling.
And, if luminosity would allow, working outside with it would be a dream come true to me!
Behind all of this is my room's white wall with an area of around 4x2 meters. Imagine if I could change my monitor with an AR version of it that mapped/projected the "desktop" to my wall.
And then, let's say I want to get into a meeting with a colleague to do some diagrams, so we "map" some Whiteboard software into another wall in my room and a wall in my colleague's room. We will be looking at the same and could even "draw" with hand gestures or something.
I have more hope for AR than for VR as well.
Here's a video from a different company.
https://m.youtube.com/watch?v=0NogltmewmQ