Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The HTTP of VR

roderickkennedy.com

Post reply on HN
Print view View original

61–70 of 75 posts

Re: The HTTP of VR

#61

Post by usrbinbash »

charcircuit wrote: post #58
usrbinbash wrote: post #56

Earlier quoted context omitted.

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.

How can I use my keyboard in VR?

There are only 2 options:

Either I see the keyboard through some sort of passthrough, in which case the entire VR experience is basically just an overly expensive desktop background.

Or the keyboard is replaced by a VR representation, which relies on the device knowing where the keyboard is. Obviously, that will require a special keyboard with IR markers, so good bye custom keyboard, good bye laptop keyboard.

Oh, and I cannot see my hand movements on it, which kinda defeats the purpose of seeing the keyboard, because current hand tracking technology cannot keep up.

Neither of these offer me any benefit over the cheaper, easier and functional technology that I am using right now.

Re: The HTTP of VR

#62

Post by andrewmcwatters »

jayd16 wrote: post #59
andrewmcwatters wrote: post #40

Earlier quoted context omitted.

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.

Great, so do I, and we can disagree all day.

Re: The HTTP of VR

#63

Post by bullen »

Animats wrote: post #54
sbierwagen wrote: post #51

Earlier quoted context omitted.

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 th…

I think that the open part of the metaverse needs to be code and legal before aestetic. Mostly because skin mesh animation is the hardest part of game dev. because of pipeline costs and code complexity.

The Roblox solution looks terrible; bloated, bug prone and poor performing. I manage 2000 non-instanced characters (each with a interchangeable weapon) on a 1050Ti.

I'm going with royalty free assets that I happen to have a custom agreement to because of an early adopter advantage which allows me to redistribute them not only in a game but also with my open-source engine.

The content being editable creates headaches and decreases improvement of technology since more time is wasted on supporting more and more data for zero gameplay benefit.

Physics is the gameplay changer for MMO games, and it needs to be implemented in the game and not in some external library to be efficient/specialized enough to scale in a MMO setting.

Re: The HTTP of VR

#65

Post by jayd16 »

gfxgirl wrote: post #37

I think there is a different problem that needs to be solved and it's probably impossible. I've dreamed of the metaverse since Snow Crash and maybe before (Tron?) but ... when it comes to actually making it, lets assume unlimited CPU/GPU power and unlimited memory. Ideally, I want the Metaverse to allow people to run their own code. Whether its VR or AR it's a shared 3D space. So I want my Nintendo "Nintendogs" to be…

Seems like you could share collision meshes without much risk of spying, no?

Re: The HTTP of VR

#66

Post by jayd16 »

moron4hire wrote: post #35
Animats wrote: post #33

Since I'm writing a new client, in Rust, for Second Life/Open Simulator, I'm very aware of these issues. A metaverse client for a high-detail virtual world has most of the problems of an MMO client plus many of the problems of a web browser. First, much of what you're doing is time-sensitive. You have a stream of high-priority events in each direction that have to be dealt with quickly but don't have a high data volu…

This is why I think it's a joke to be building metaverse apps in Unity. Unity and dynamic asset loading are not happy bed fellows. There's not a lot I liked about Unity when I was working with it full-time a few years ago. But the one thing I could acknowledge that it has that was generally missing from open source web development was the asset pipeline. But dynamic, user-uploaded assets won't be able to use the asse…

You can do some level of dynamic asset loading. The real issue to get around in Unity is dynamic script loading. There's some progress being made with Unity's new visual scripting system. The visual scripts are stored as assets.

Re: The HTTP of VR

#67

Post by ahupp »

jayd16 wrote: post #60
ahupp wrote: post #34

Earlier quoted context omitted.

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…

This isn't about saving 10ms in latency. In the case of a dropped packet, TCP can wait multiple seconds for a retransmission which blocks the whole stream. You aren't going to client-side-predict your way out of that.

QUIC in theory can support this kind of lossy transport but it's not really exposed to browsers AFAIK. WebRTC is somewhat complicated to use but can support lossy streams.

Re: The HTTP of VR

#68

Post by jayd16 »

ahupp wrote: post #67
jayd16 wrote: post #60

Earlier quoted context omitted.

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…

This isn't about saving 10ms in latency. In the case of a dropped packet, TCP can wait multiple seconds for a retransmission which blocks the whole stream. You aren't going to client-side-predict your way out of that. QUIC in theory can support this kind of lossy transport but it's not really exposed to browsers AFAIK. WebRTC is somewhat complicated to use but can support lossy streams.

Again, you're solving for a very specific type of interaction that is not necessarily needed.

Does every virtual web app need server authoritative position? No. We could imagine a world where much of the physics and rendering is client side for most apps.

Does it make sense that every virtual web app should pay for low latency server authoritative position? Also no.

Sure, some apps will want this level of synchronicity and maybe there's a place for another web standard but its silly to say that http is not feasible or that this is the only way web VR should work.

Re: The HTTP of VR

#69

Post by ahupp »

jayd16 wrote: post #68
ahupp wrote: post #67

Earlier quoted context omitted.

This isn't about saving 10ms in latency. In the case of a dropped packet, TCP can wait multiple seconds for a retransmission which blocks the whole stream. You aren't going to client-side-predict your way out of that. QUIC in theory can support this kind of lossy transport but it's not really exposed to browsers AFAIK. WebRTC is somewhat complicated to use but can support lossy streams.

Again, you're solving for a very specific type of interaction that is not necessarily needed. Does every virtual web app need server authoritative position? No. We could imagine a world where much of the physics and rendering is client side for most apps. Does it make sense that every virtual web app should pay for low latency server authoritative position? Also no. Sure, some apps will want this level of synchronici…

Ok I see what you're getting at. Yes, there are plenty of VR apps that don't require that kind of latency control. A game that's 99% local, but shows you a leaderboard of top scorers, etc. Even an app that has a significant real-time component will have plenty of HTTP requests as well.

But the word "metaverse" appears in the first sentence of the post we're discussing, and real-time interaction with other people's avatars does call for this kind of protocol.

Re: The HTTP of VR

#70

Post by jayd16 »

ahupp wrote: post #69
jayd16 wrote: post #68

Earlier quoted context omitted.

Again, you're solving for a very specific type of interaction that is not necessarily needed. Does every virtual web app need server authoritative position? No. We could imagine a world where much of the physics and rendering is client side for most apps. Does it make sense that every virtual web app should pay for low latency server authoritative position? Also no. Sure, some apps will want this level of synchronici…

Ok I see what you're getting at. Yes, there are plenty of VR apps that don't require that kind of latency control. A game that's 99% local, but shows you a leaderboard of top scorers, etc. Even an app that has a significant real-time component will have plenty of HTTP requests as well. But the word "metaverse" appears in the first sentence of the post we're discussing, and real-time interaction with other people's av…

But that's entirely my point. Even for the metaverse, the majority will be cheap async http-like calls and not always connected game servers. If IKEA is joining the metaverse, do they want to spin up a realtime game they maintain or will they want to statically host client heavy VR content?

We should focus on how we bring the lessons of past 20 years into these sci-fi concepts. We need to consider how businesses find success today and bring that to VR to be successful.

Post reply on HN