Earlier quoted context omitted.
It's worth noting for anyone curious: the Quest 2 can't actually interact with or enter the majority of worlds because of technical constraints (they aren't even offered to Quest 2 users unless the author of the world explicitly opts into it and designs their world for it). Most adults are on private, PC-focused servers. The application is not a stunning technical achievement, but it's unfair to judge the program by…
While all of this is true, one should also note that none of this is obvious at any point while using VR Chat. It might be the most popular social VR app right now (Altspace has even more problems, and RecRoom is pretty much strictly children), but that doesn't mean the software is actually any good. We're in the Friendster/MySpace/Neopets days of social VR, with Facebook seemingly interested in making the LinkedIn.
Linux in a Pixel Shader – A RISC-V Emulator for VRChat
41–50 of 104 posts
Re: Linux in a Pixel Shader – A RISC-V Emulator for VRChat
#42Earlier quoted context omitted.
While all of this is true, one should also note that none of this is obvious at any point while using VR Chat. It might be the most popular social VR app right now (Altspace has even more problems, and RecRoom is pretty much strictly children), but that doesn't mean the software is actually any good. We're in the Friendster/MySpace/Neopets days of social VR, with Facebook seemingly interested in making the LinkedIn.
Honestly, the game starts at the point where you meet a group of people you enjoy interacting with and stop visiting public instances. Much easier to get in to with a friend to guide you along the way.
Re: Linux in a Pixel Shader – A RISC-V Emulator for VRChat
#43Earlier quoted context omitted.
https://youtu.be/G2u7NOpzcBQ?t=5054
this is atrocious. Bunch of visual distractions made by avatars, horrible and disrespectful background noise/chatter, graphics like it's 1998..
The graphics are indeed really bad.
The background noise also seems to be poorly managed.
And the avatars are visually striking just to the point of being very distracting.
But I have not the first clue how to fix any of these issues. The graphics have to exceed 70fps cannot drop frames or you risk users getting nausea (and not using the platform!), the audio chat works just like every other audio chat out there - badly, and the I looked into the avatar situation and discovered that, contrary to my own intuition (where avatars would incorporate lightweight, aggressively CPU-throttled control programs that could arbitrarily direct how emoting works etc), you basically get a restrictive SDK that's just *upgraded* to the point where you have like 16 different things your avatar can do.
It's simultaneously utterly inspiring and an absolute dumpster fire. I "got" VRChat for the first time when I discovered this last week and have been awkwardly conflicted about it ever since.
Re: Linux in a Pixel Shader – A RISC-V Emulator for VRChat
#44reminds me of this https://dolphin-emu.org/blog/2017/07/30/ubershaders/
Interesting. If I would want to solve that problem, first thing I would have tried is bypassing text representation of these shaders. For a few things in the past I have generated, and dynamically patched, D3D11 shaders directly in DXBC byte code, without HLSL anywhere. The byte code format is even documented by Microsoft. Not the complete DXBC files though, but some people on the internets have reverse engineered th…
Re: Linux in a Pixel Shader – A RISC-V Emulator for VRChat
#45This is outrageous. I'm making a text editor / game where you have a mechanical typewriter, and I've mused quite a few times about giving someone a beige computer running linux inside the game at some point, but it's all seemed unreasonable / impossible.. With this it's suddenly reasonable (if expensive performance wise) Thank you for this, haha.
That sounds kinda interesting/fun.
FWIW, given that you're running a game, and most people run games fullscreen, without anything else going, you can probably get away with not using virtualization, aka eating 100% CPU (or at least 100% of one core)... and even then, with most systems having >4 cores nowadays, you probably needn't worry at all.
But just to clarify the corollary, this implementation is running at around 250kHz (!). You wouldn't viably run Linux like this in a practical context anytime soon.
Re: Linux in a Pixel Shader – A RISC-V Emulator for VRChat
#46Earlier quoted context omitted.
Why are the majority of avatars small children or furry-things? I'm really not one of those people who bashes nerdy or alternative culture but I can't deny that it weirds me out a bit. It's a clear barrier of entry for me.
I bought an Oculus Quest 2 earlier this year to check out the whole VR situation. It was basically a ghost town with pockets of children and, IMHO, sketchy folks having childlike conversation. I don't really know what I expected but it wasn't that. Aside from some focus issues the goggle hardware was pretty great but the VR world was not a good experience at all. :/
Re: Linux in a Pixel Shader – A RISC-V Emulator for VRChat
#47Re: Linux in a Pixel Shader – A RISC-V Emulator for VRChat
#48Definitely watch the presentation by the developer in VR Chat: https://www.youtube.com/watch?v=G2u7NOpzcBQ I haven't played VR Chat in a few years, and holy cow this makes me want to jump back in. Seeing fully captured motion avatars of people is SO immersive. It's absolutely insane how the experience of interacting with people can feel so natural even when they're on the other side of the planet. I just love watchin…
Re: Linux in a Pixel Shader – A RISC-V Emulator for VRChat
#49Earlier quoted context omitted.
Interesting. If I would want to solve that problem, first thing I would have tried is bypassing text representation of these shaders. For a few things in the past I have generated, and dynamically patched, D3D11 shaders directly in DXBC byte code, without HLSL anywhere. The byte code format is even documented by Microsoft. Not the complete DXBC files though, but some people on the internets have reverse engineered th…
Even if you use byte code, the driver will have to compile your shader for the target hardware. It won't be nearly as fast as what the game does on console - loading a blob in GPU memory. It will definitely be faster than compiling a text representation, but still not fast enough to skip the uebershader.
It’s possible the DXBC byte code generation might work fast enough for their application without the overhead of the ubershader, or the complexity of their hybrid approach.
Re: Linux in a Pixel Shader – A RISC-V Emulator for VRChat
#50This is outrageous. I'm making a text editor / game where you have a mechanical typewriter, and I've mused quite a few times about giving someone a beige computer running linux inside the game at some point, but it's all seemed unreasonable / impossible.. With this it's suddenly reasonable (if expensive performance wise) Thank you for this, haha.