The HTTP of VR • Hacker News Board

Re: The HTTP of VR

#51

Post by sbierwagen » Sat, Dec 11, 2021, 7:16 PM UTC

bullen wrote: post #46

Animats wrote: post #43

Earlier quoted context omitted.

Unity and dynamic asset loading are not happy bed fellows. Not Unreal Engine 4, either. UE5 has "asset streaming" and "open worlds", but mostly static and loaded from a local SSD on a Playstation 5. That's working nicely. Asset management from the network is the real difference with seamless, modifiable virtual world systems. Otherwise, it's a minute of "...LOADING..." when you move to the next area. You need clients…

But why does it have to load dynamically, when you can just package releases instead?

For Second Life at least, it's hard to package stuff. World geometry, player models, lighting and props can all be edited in realtime. You can't use most of the tricks that video game devs are used to: no simple way to prebake lighting or reflections, no occlusion culling or binary space partition. The asset base is enormous: hundreds or thousands of terabytes. You can bet that every player character will have a completely unique set of textures and models, very little is shared between characters. This is why long time SL users tend to stick to one location, because actually exploring is painful-- move 100 meters, then stand still for a few minutes as your framerate plummets and everything slowly loads in. Many clubs or hangout spaces are on islands or boxes in the sky high enough that nothing else loads in. This reduces the problem just to rendering avatars, which is hard enough by itself.

It's also very hard to depreciate old systems. The game is 18 years old, but there were real money transactions from day one. If a user bought something ten years ago, they expect to still be able to use it!

You can imagine a clean-sheet design that does away with all this. Make the world static, player avatars pre-baked. Most SL competitors do this. (Facebook Spaces, Playstation Home etc) This gives you better FPS and a much more consistent aesthetic, since all the assets are made in-house. But now what? The classic Metaverse problem, there's just not that much to do. Cutting features from SL makes this worse, not better.

Re: The HTTP of VR

#52

Post by usrbinbash » Sat, Dec 11, 2021, 7:23 PM UTC

AnotherGoodName wrote: post #8

usrbinbash wrote: post #2

What exactly is the "metaverse" supposed to be, other than a marketing term to sell a more expensive class of IO devices? People will not switch over in droves to do their text/image/video editing in VR all of a sudden, because other than a few special design applications, there is no point in doing so...it's slower, clumsier and the input devices are much less precise than mouse&keyboard. Another supposed target dem…

The Motorola DynaTAC mobile phone was about the same size as a VR headset is today. Imagine the same improvements are made to VR that were made to phones. The VR headsets are expensive bricks right now but they'll be in glasses form factor (or better) with extraordinary usability in the relatively near future. An overlay on the real world that brings remote and nearby contacts into the same room seamlessly.

What if I don't want an overlay but actual VR? Goodbye prism-projection, hello splitlense-screen and all the form restrictions to the device that brings with it.

Besides, the hardware doesn't get much smaller than it is. The chips are not the problem, the problem is the power supply.

We have already reached a limit for phones, and that only because advertising somehow managed to convince people that it's okay for one of their most important personal electronic devices to go flat in less than a day (quick reminder that mobile phones used to last 4-5 without recharging ;-) )

So, what do we do? Put super small Li-Ion batteries into our "metaverse" devices? Not much of an immersive experience if the thing goes down after 20 minutes. So, big heavy battery it is then, and that's that about slim, cool, SciFi VR glasses.

And what about input? Displaying information is not enough, the whole thing is supposed to be interactive. Voice control only gets you so far, and is unsuitable for most interesting things we want to do (virtual keyboards, games, movement, etc.), not to mention it's not even possible in most scenarios without being permanently online to contact the ASR service (oh, did I mention that the WiFi and LTE/5G modules also gobble up power like noones business?).

So it's not just the headset, I also need an input device, or rather 2.

Re: The HTTP of VR

#53

Post by Animats » Sat, Dec 11, 2021, 8:09 PM UTC

bullen wrote: post #46

Animats wrote: post #43

Earlier quoted context omitted.

Unity and dynamic asset loading are not happy bed fellows. Not Unreal Engine 4, either. UE5 has "asset streaming" and "open worlds", but mostly static and loaded from a local SSD on a Playstation 5. That's working nicely. Asset management from the network is the real difference with seamless, modifiable virtual world systems. Otherwise, it's a minute of "...LOADING..." when you move to the next area. You need clients…

But why does it have to load dynamically, when you can just package releases instead?

Because, in a real metaverse, everybody can make changes to their own stuff. That's the difference between a metaverse and an MMO.

Re: The HTTP of VR

#54

Post by Animats » Sat, Dec 11, 2021, 8:30 PM UTC

sbierwagen wrote: post #51

bullen wrote: post #46

Earlier quoted context omitted.

But why does it have to load dynamically, when you can just package releases instead?

For Second Life at least, it's hard to package stuff. World geometry, player models, lighting and props can all be edited in realtime. You can't use most of the tricks that video game devs are used to: no simple way to prebake lighting or reflections, no occlusion culling or binary space partition. The asset base is enormous: hundreds or thousands of terabytes. You can bet that every player character will have a comp…

Which is why I'm working on a multi-threaded Second Life / Open Simulator client in Rust. The frame rate problem can be overcome. Another example of mine:

https://vimeo.com/640175119

Runs 55-60FPS in a crowded area.

Over-complicated avatar clothing is a separate problem. This is a huge deal in Second Life, because it's the greatest dress-up virtual world ever built. Users expect a lot. The tattoo layer has to show through mesh stockings, for example. I have some ideas on speeding that up but haven't implemented anything. What's needed is an optimization step that takes place when an avatar changes clothes. All the layers of meshes need to be crunched down to a simplified game-type combined mesh. In a game, that would be done during asset building. In a world where you can change clothes, mixing and matching items, it has to be done somewhere near run time. But not on every frame, just at clothing changes. This is already done for textures; all the texture clothing layers of an avatar are baked down to one. Roblox does something like this in their experimental mesh avatar system.

There's a mindset that this is impossible, shared by the low end of metaverse developers. It's not shared by Roblox or Epic or IMVU, who are busy solving the problem. This is a moderately hard problem, but it's not impossible.

Linden Lab staff had convinced themselves that it was impossible to speed up the viewer. After some people in Linden Lab management saw what I'd done, somehow there suddenly was much more effort going into improving the viewer FPS in their C++ client.

Re: The HTTP of VR

#55

Post by jimmySixDOF » Sat, Dec 11, 2021, 8:31 PM UTC

binarynate wrote: post #24

binarynate wrote: post #23

> By far the greatest reason to look beyond HTML and HTTP for spatial computing is simply this: these technologies will continue to develop, and will always be driven by their primary purpose: to deliver webpages, websites and static, or marginally dynamic content. This is a valid point, but I believe there's still enormous potential to innovate on top of WebXR. Since browser engines are open source, it's possible fo…

On a related note, I develop libraries for embedding web browsers in Unity 3D ( https://vuplex.com ), including a library for embedding the Mozilla GeckoView library used by FireFox Reality. I plan to develop a WebXR driver for it, but haven't prioritized it yet. If you're interested in developing a WebXR driver for use with GeckoView (for example, to use with Oculus Quest), you can contact me, and I'll send you my n…

I'm interested in how you might be able to get through the CORS problem in WebXR/Browser standards ? In a VR Unity app with embedded browsers you can click through hyperlinks no problem but in WebXR the same hyperlink will trigger an origin mismatch and break out of immersion. Not having good 2D web content integration is a major blocker in WebXR for so many applications.

Re: The HTTP of VR

#56

Post by usrbinbash » Sat, Dec 11, 2021, 8:46 PM UTC

charcircuit wrote: post #6

usrbinbash wrote: post #2

What exactly is the "metaverse" supposed to be, other than a marketing term to sell a more expensive class of IO devices? People will not switch over in droves to do their text/image/video editing in VR all of a sudden, because other than a few special design applications, there is no point in doing so...it's slower, clumsier and the input devices are much less precise than mouse&keyboard. Another supposed target dem…

Nothing is stopping you from using your keyboard in VR.

Nothing is stopping me from writing a google-ASR powered program hooked into my terminal, and start yelling my code into the computer either.

But as long as this isn't faster, easier or more reliable than typing it on a keyboard, I won't.

People don't work a certain way because it's possible. People work a certain way because it saves time, money, sanity, or simply because it's convenient.

If wearing a VR headset while coding isn't providing substantial benefits over what my current system provides, why would I do it?

Re: The HTTP of VR

#57

Post by usrbinbash » Sat, Dec 11, 2021, 8:59 PM UTC

agar wrote: post #17

usrbinbash wrote: post #2

What exactly is the "metaverse" supposed to be, other than a marketing term to sell a more expensive class of IO devices? People will not switch over in droves to do their text/image/video editing in VR all of a sudden, because other than a few special design applications, there is no point in doing so...it's slower, clumsier and the input devices are much less precise than mouse&keyboard. Another supposed target dem…

John Carmack (consulting CTO for VR at Facebook/Meta) said in his most recent talk on VR (paraphrasing despite quotes), "The internet has been described as people and screens. I've been arguing that the metaverse is just more people and more screens. Trillions of dollars of investment have made 2D screens very effective tools for delivering information. If the metaverse can deliver that information anywhere, at scale…

> You can place that in any kind of environment you find comfortable working in.

That's exactly what I did with my 4 high resolution monitors. And my current setup even lets me go to the kitchen to make a really tasty espresso or a snack without having to disentangle myself from a headset first. And I can even continue to listen to the music from my speakers while sipping aforementioned coffee.

>If it means 4 screens on the balcony of a Tuscan villa instead of a tiny desk in a depressing space? Maybe.

But they still feel the tiny desk in front of them, and still see it through the mentioned "keyboard window", still hear the janitor vacuuming his merry way down the hallway.

So essentially, this would be a desktop background, which costs 400$ and requires recharging a headset every 2h.

> What about if it's a 100g headset

Then they better start making meetings REALLY short, unless they want the battery go flat halfway through the second slide.

> The benefits for shared movies, group gatherings, co-working, and social gaming are very compelling.

Shared movies: big screen + streaming + comfy couch

Group Gatherings: until such time as VirtualReality figures out how to get me an ActualReality beverage, I pass.

Co-Working: Teams/Zoom/etc.

Social Gaming: Already possible, metaverse not required.

Re: The HTTP of VR

#58

Post by charcircuit » Sat, Dec 11, 2021, 10:17 PM UTC

usrbinbash wrote: post #56

charcircuit wrote: post #6

Earlier quoted context omitted.

Nothing is stopping you from using your keyboard in VR.

Nothing is stopping me from writing a google-ASR powered program hooked into my terminal, and start yelling my code into the computer either. But as long as this isn't faster, easier or more reliable than typing it on a keyboard, I won't. People don't work a certain way because it's possible. People work a certain way because it saves time, money, sanity, or simply because it's convenient. If wearing a VR headset whi…

The difference is you can already use a keyboard in VR where your system sounds like you would have to go and mild it.

>If wearing a VR headset while coding isn't providing substantial benefits over what my current system provides, why would I do it?

You wouldn't.

Re: The HTTP of VR

#59

Post by jayd16 » Sat, Dec 11, 2021, 10:56 PM UTC

andrewmcwatters wrote: post #40

jayd16 wrote: post #27

Earlier quoted context omitted.

Unless you need twitch-shooter level ping times in your web app, websockets/TCP is fine. The rendering is client side after all. Nothing about VR rendering would involve the web stack anyhow. Http/3 is UDP. So whats wrong with http exactly?

You severely underestimate the application of real-time positioning needs in 3D software. "Twitch-shooter" is an amateur way to describe such an application; real-time positioning is desirable anywhere. Interp only gets you so far.

I work in games and it's definitely fine for a lot of applications.

Re: The HTTP of VR

#60

Post by jayd16 » Sat, Dec 11, 2021, 11:09 PM UTC

ahupp wrote: post #34

jayd16 wrote: post #27

Earlier quoted context omitted.

Unless you need twitch-shooter level ping times in your web app, websockets/TCP is fine. The rendering is client side after all. Nothing about VR rendering would involve the web stack anyhow. Http/3 is UDP. So whats wrong with http exactly?

Just having UDP somewhere in the stack isn't sufficient. The reason game protocols use UDP is because (among other things) they can precisely define when to block on missing data and when to ignore it and keep going. For example, lets say a client is sent 3 sequential packets, p0, p1, and p2. Sadly, p1 has been dropped by network goblins. What should the client do? Well, that depends on what is in the packets. If p0-…

It's really not that big a deal. You certainly don't need perfect 10ms packets for most games. Client side prediction goes a long way. For something like VR the physics would need robust client side handling anyway. 10ms isn't good enough.

If we're talking about a virtual web, we will not be spending the server resources on always connected apps the majority of the time. Surely we'll have heavy client side scripting for most interactions.