I've been using it for a couple years now and I can't stress enough how easily you can get started for VR, especially compared to "full" engines. And it might be tailored for VR but it's absolutely fine for general 2D/3D as well.
It feels like all the VR platforms are quite locked down and funneling users to app stores - so if you want something simple and not performant then a framework that works through the browser would in theory get traction more easily
Tangentially, I also always quite liked the idea of webpages being VR spaces. Has more of a "metaverse" vibe to it
We're a non-profit, and our code is entirely under the Apache License. Not only nothing is monetized, but the architecture is extremely monetization-unfriendly, and we ripped out what little there was in the original code. Oddly enough the codebase was built by a company with commercial ambitions (High Fidelity), but unsurprisingly failed to make any money.
So we picked that up and are continuing development.
So if you want freedom, I believe we're at the top of the list. Everything is open, nothing is centralized. Not even accounts are required. You can just easily set this up on your own hardware with no outside dependencies and do whatever you want.
Yeah, the line goes High Fidelity -> Vircadia -> Overte (where most devs are)
Vircadia started off well, but then the lead decided to go all in on crypto. Pretty much everyone just left and made a new project, while Vircadia as far as I can tell has almost no development going on. Or if there's anything it's not public.
Currently, probably not. We've got plenty of other things to work on including several big projects some of which have a deadline needed to satisfy a grant (thanks NLnet Foundation!), and we looked into the web functionality and were unimpressed.
Vircadia's web functionality technically works, and I think it's an okay effort for the tiny team that remains, but it's really at the proof of concept stage. It's slow, misses a whole lot of functionality including very basic things, and has extremely obvious bugs like falling through the floor and the camera getting stuck easily.
So far our take is that it's too broken to just merge as-is, somebody would need to have at least some interest in fixing it up a bit. And for the time being there isn't, and on Vircadia's side the development of it slowed down dramatically.
It's not impossible in the future, but so far things just don't line up right. And it'd be a huge project. The web client is its own thing written from scratch, it'd be an enormous amount of work to make it half as functional as the desktop one.
Sounds fair, though I had hopes for such a client (at least something to just check out on the virtual world state without spinning up a whole desktop client).
Since you seem rather active with the project, do you know whether openxr is on the roadmap, or if you're stuck with openvr for the foreseeable future?
> Sounds fair, though I had hopes for such a client (at least something to just check out on the virtual world state without spinning up a whole desktop client).
Even that would take some work. We've made a few improvements to the core code that Vircadia didn't and that would involve adapting the web client code to match.
I'm also worried about the effects it could have on the project. Will people start demanding that it be fixed now? What about when there's a security issue found in it? Will there be drama with Vircadia?
Merging the code means taking on a responsibility, and at the very least we'd have to properly review it and make sure it's good enough people are going to want to work on it.
So far I believe that this has to approached with some good planning and somebody willing to work on that code to account for any problems that might arise. So it'd help a lot if anybody was interested in maintaining the code.
> Since you seem rather active with the project, do you know whether openxr is on the roadmap, or if you're stuck with openvr for the foreseeable future?
If you're interested in testing that, you're welcome to give it a try. If you need any help getting started, we have Matrix, Discord and an in-world meeting in 5 hours from the time of this post.
For openness and simplicity look no further. LOVR is written in C with a hand-built Vulkan engine, and you script your games/apps in Lua. It's that simple. No app-stores, no subscriptions, no web technologies/browsers. You can have a VR "Hello World" in 3 lines of code.
Not a VR expert, but it seems to be about same thing for OpenXR+Vulkan as A-frame is for WebXR+WebGL. Minimalist 3D engine with simple API wrapping much more complex lower level APIs, "reducing number of things which can be done in exchange for making some things easy to do with it". Native, not web app.
OpenXR is "Vulkan for VR" by the way, every major HMD vendors runtime supports it. Though only SteamVR supports Linux, and there's mess with support of advanced tech like asynchronous reprojection, I hope Monado which is "Mesa for VR" will succeed. And Firefox gets WebXR.
Somewhat related, I'm trying to convert the Learn OpenGL tutorials [0] to LÖVR [1]. The main goal is to help me (and hopefully others) to understand the changes needed to convert the Open GL shaders to the LÖVR version, as there are some differences.
Not all tutorials are completed yet, this is still a work in progress.
Wow. This sounds really interesting. I've been trying to learn unity but it's kinda tough especially if you want to make something really cross platform in VR. There's so much boilerplate in terms of libraries that also constantly seem to change so tutorials or books I follow don't seem to match.
I wonder if this is powerful enough and easier to learn. Definitely will give it a look.
I have some questions though. Is it as performant as unity? Can you import external content as easily? Is there a performance penalty for using Lua?
Yes and if you have them in the wrong order in the tree, or a little setting (like an object reference) wrong on one of them it doesn't work right and it's really hard to find out why. Also what each one is actually for. The names are far from clear to me.
It's documented but I don't find it very clear. In the end I've started using the Oculus toolkit rather than the openxr one as it was the only one I managed to make work. Some things are implemented weirdly though. Like the fade to black when teleporting, it just draws a black rectangle in front of your face but that doesn't work if you're not looking straight ahead because you can look past the edges of the rectangle. So then I have to go and fix that.
I understand everything needs to be flexible, in an engine you can't make assumptions otherwise you can't do things that deviate from the norm. But this seems to be overly complicated to me.
I’ll give it another shot because there’s definitely some really good stuff including hot reload!
Last I tried it, there was definitely some missing love (pun intended) in setting it up to compile from source for custom Quest stuff I was working on… when the compilation instructions start with “here be dragons” you know it’s gonna be fun (https://lovr.org/docs/Compiling).
Cool! I remember messing around with LÖVE (2D) back in the day. This looks just as awesome, although I'm way too busy to do anything with it at the moment. There is always looming unemployment around the corner though :P
EDIT - WebXR target was removed from README in July 2023, with commit message "Don't trick people into thinking WebXR is supported right now, and spell macOS better."
LÖVR – An open source framework for rapidly building immersive 3D experiences - https://news.ycombinator.com/item?id=28081656 - Aug 2021 (122 comments)
Show HN: LÖVR – VR framework for Lua - https://news.ycombinator.com/item?id=15177549 - Sept 2017 (23 comments)