Hacker News Reader

Comment by FeepingCreature | Hacker News Reader

If Third Room can get custom avatars, content and VR up within the next two months, it has a chance of stealing the VRChat userbase. If not, some other project will do it and this will go the way of the Second Life: an eternal "hey, isn't this cool?"

The value proposition of 3D chatrooms and metaverse in general only makes sense in a VR context. I hope they focus on that.

View on HN

Second Life is still doing $50-70M a year. The company (Linden Lab) has 300 employees. I'd love to be considered an irrelevant failure and still banking $50M+ a year.

Interesting. Do you know how? When I tried it a few years back, it was a complete mess.

You only need to be slightly successful in a niche if you provide a lot of ‘value’ to them. Similar to other MMOs that have existed for ages, they can have small player bases in absolute terms but still take in a lot of money because they can charge more for access. So they don’t need to target ‘everyone’ and the product doesn’t have to bend to suit.

Hi vrchat thread! Yes, getting a next-best alternative to vrc would be awesome.

I am... somewhat sceptical as to why they feel they can just "VR/AR: We need to flip the bit to enable WebVR / OpenXR support", _especially_ with custom avatars. VRC has been 1, native, 2, using an engine very optimized for 3d pipeline rendering (unity) and yet it still has _major_ performance issues, on account of different avatars using different shaders, and high (80k++) polycount. I'm open to be proven wrong, but feel very strongly both that 1, the whole "metaverse" concept only makes sense in vr context, with physical intimacy being the core killer feature; and 2, in order to do that, you need an engine highly optimized for this purpose (to avoid vr fatigue / vr sickness), and 3, chrome is, as far as I can tell, not the delivery platform for that.

Specifically, in order to provide vr experience that people don't get sick in, you need an extremely high-grade, low-latency rendering pipeline, including fine things like pose prediction, timewarping, and other ways to generate hypothetical frames _before the user actually moved there_. I'd be intensively curious if chrome would provide that.

Otherwise, what you have here, will remain essentially a small sandbox for 5 minutes gameplay. Good luck!

All the timewarp and other pose prediction bits of the renderering for VR are done in the headset drivers and firmware. You do need to hit higher frame rate targets but there is plenty on the way in browsers to help there.

VRChat is in an interesting place right now, and the performance and moderation elements are real issues for sure.

I'd love to see a kind of local consensus/approval paired with distributed moderation to tackle the question of whether a user-agent should load/render any given asset.

Any client wanting to introduce a new avatar/shader/other asset to a session should go through a "proposal" stage first where the other peers can briefly inspect the metadata (polycount, moderation signatures, maybe even lightweight code analysis for scripted objects, etc) before signaling whether they intend to render it or not.

This gives participants (or rather, their user-agents) a chance to vote on whether or not an asset fits within their collective performance budgets, or if they trust a script to run without degrading the experience.

Personally, I'm of the opinion that we need a new kind of "browser" entirely; where the modern browser is focused on the traditional client-server document/application delivery and runtime, a "true" metaverse client should focus on p2p real time (or at least synchronous) shared experiences in an extensible compute environment. Not just 3d/VR either, it should be possible to connect to a session that's just a basic text or video chat room, then scale it into a 3d session.

There's also the matter of content hosting and distribution, I'd love to see native integration of IPFS or something like Bittorrent's DHT for p2p content-addressed file sharing. Popular scripts/application components and assets can be shared across the entire network, and peers can share their own personal content (avatars, applications) directly in active sessions.

If you'll indulge me a bit:

Matrix provides an extensible platform with identity and a shared, consistent, timeline of events. (You can also maybe get this with something web3, imagine a per-session blockchain somewhere between SSB and ETH)

With a consensus timeline, you have a shared history, and thus a shared reality.

On that timeline you can use extensible protocols to introduce assets, scripts/apps, and post events/messages.

Scripts all run inside a deterministic, message oriented compute environment, and the state of this environment gets checksummed and updates in lockstep for all peers. A new peer joining a session can either load a full state dump or just replay the event log to catch up.

For ephemeral/real-time data, like player look/point directions or video/voicechat, streams URIs can be posted to the log in a standard format.

A typical 3d interaction would start with two or more users connecting to each other, post messages announcing their preferred avatars, messages introducing an application package that supports 3D positioning and collision resolution, then loading an environment. Popular suites of code and assets can be bundled up and distributed with the browser and on the DHT.

Each user can have a set of public keys that represent moderators they trust, and require that each new asset be signed, or else allow "self-signed" content from other users at various trust levels, or just be open to everything.

I really feel like all the right ideas are floating around to build a truly p2p, personally liberating, extensible engine for synchronous shared experiences. Putting it all together is the hard part.

Why the next 2 months?

Yeah, curious why the next two months? We're definitely going to be implementing the VRM avatar format fairly soon, but not VR just yet. There are plenty of unsolved problems on desktop where there's a much larger user base. And we also still have mobile design and optimization to work on. I've worked on AltspaceVR and Mozilla Hubs and as much as I love VR, especially WebXR, it's still a relatively small market. We will support WebXR, but it's not our top priority right now.

I'm expecting other projects to try to do the same thing, and a large first-mover advantage. "Two months" was just a vague number thrown out: VRChat banned mods in July, that's two months ago, and I think a first prototype that zeroes in on the VRChat niche is viable after four months of work, especially if one is pivoting from an existing codebase.

I'm not saying "you should focus on VR", I'm saying "if then, else then." The value proposition for social 3D chat on desktop is just not there, IMO.

Ah, yeah what's happened with VRChat is a shame. I don't think we're building the same thing though. We'd like to go far beyond social 3D chat, that may be what it looks like right now, but our aspirations are towards building an open platform for publishing and hosting your own events, experiences, games, and applications. There's a much larger audience for that on desktop.

I think in general, from a product perspective, the way to build a big platform is to solve a small problem completely and then iterate. But that's your choice.

(Firefox made the same mistake, I believe: there's no market in being the second-best product for a large userbase, instead of being the very best for a smaller.)

Reply on news.ycombinator.com