Show HN: LÖVR – VR framework for Lua
lovr.org
lovr.org
From a brief look at the github, though, it looks like a custom 3D engine with VR capabilities. Still, it's not like Love2D's API is particularly complex to imitate. That's one of its major appeals.
I was writing one of these in C++ a little while ago, and I remember being impressed at how easy it was to integrate OpenVR with my random OpenGL application. I got to a simple 'stand behind a barrier and shoot box-zombies with the controllers acting as raycast pistols before I dropped the project...
Anyways, cool stuff! I love seeing more open-source work in low-level graphics, even with existing solutions. I was frustrated by the lack of resources to learn 3D graphics math/APIs, and stuff like this can only help.
Cross Platform
LÖVR projects work on Windows, macOS, and Linux.
[0] https://github.com/bjornbytes/lovr/blob/master/COMPILING.md#...
Darude in the examples. Now I know this is legit.
In game development, a fully-encompassed system would be something like Unity or Unreal and people usually call them "engines".
This is a little more comparable to a library like Three.js. I'm not sure I'd call Three.js a framework, either. It's got lot of tools, but it doesn't try to take care of absolutely everything. Three.js, for example, doesn't have physics built in. LOEVR does have physics, but there doesn't seem to be a spring type in the documentation. There is this DistanceJoint thing:
> http://lovr.org/docs/lovr.physics.newDistanceJoint
> A distance joint tries to keep the two colliders a fixed distance apart.
Checking up on some other major differentiating factors between young projects and projects that have been used by a lot of people:
> http://lovr.org/docs/lovr.graphics.newModel
> Creates a new Model from a file. Most 3D file formats are supported.
For example, the supported audio formats are enumerated completely:
> http://lovr.org/docs/lovr.audio.newSource
> Creates a new Source from an ogg file.
There are no built-in materials or lights, so looks like you'll be on your own writing those shaders. Three.js has its own Physically-Based Rendering shaders that have been in the wild for over two years now. Who knows, maybe you could copy them over?
There's no built-in support for animations. This also ties back into the model format support. Some formats like FBX, Collada, and glTF support skinned mesh animations. That's super important. There's also no timeline system, so you're on your own for synchronizing actions and animations.
There's no entity/component system. That's not too hard to roll on your own, but it's such a common thing in game development these days that it's odd to see it missing. There is an event system, but the documentation makes it sound like you're not intended to use it, it's internal to the library.
I don't know. I've spent the last 3 years building my own VR environment on top of Three.js. The stuff missing here would make my life a lot harder. The stuff that is, like controller and headset pose, spatialized audio, wouldn't make things significantly easier, because the respective APIs for working with them are much more straight-forward than graphics.
There are tons of gotchas though, especially for VR render loops. If you naively add even a medium amount of stuff to the scene graph, it's easy for the management overhead to eat up your budget.
On the plus side, it's all Javascript, the code is solid, and it's easy to profile with browser tooling. But Three.js isn't going to do any voodoo magic for you if you don't know what you're doing, whereas Unity might. A double edged sword.
I don't wish I hadn't chosen the browser because then I wouldn't be in the browser.
There is a lot of good that comes from being in the browser and using web technologies. Progressive Web Apps, when done right, are a great user experience compared to downloading apps out of an app store. Web apps are far more discoverable than apps in the app stores, as your web app is constantly being crawled and indexed by a plethora of competing search engines. You can share a web app with someone by just sending them the link. You don't pay a hefty vig to any app stores just for the pleasure of getting buried at the bottom of the new releases list after a few hours. You don't get throttled on how often or delayed on when you can update. You don't get censored on content. It's completely cross-platform. Everyone is allowed on the Web whenever they want.
I do a lot of work in Unity, too, and I like some things about it. I like working in C# over JavaScript. It's certainly somewhat easier to get good looking graphics, but definitely not a lot easier. You have to have good art assets to begin with, and the whole interaction has to be designed around how Unity's asset pipeline works, which basically means you're locked into Unity harder than most any other proprietary platform I've ever dealt with. It's a lot worse than, say, trying to migrate from Oracle to Postgres, or something. A lot of times, a few, small compromises on the art can get you 90% of the graphical quality on WebGL. Most of the really awesome Unity demos you've seen are as a result of their material and lighting baking process and are actually very static. Unity's primary value is its asset pipeline. The graphics could be done just the same by just about anything if they had a decent asset pipeline.
And it's not even really all that great of an asset pipeline, it's just a lot easier than hand-baking all those textures. But it comes at a cost. Unity doesn't play well with source control. Collaborating with others is fraught with peril. It doesn't deploy over the Web very well, either. There's no automated testing in Unity. There's no continuous integration. You can pay extra for a cross-compilation service, but unless you pay big bucks you get queued for quite a while. If you don't like something in Unity, you're kind of stuck with it. With WebGL, if I don't like Cannon.js for my physics system, I can replace it with something else.
So for my WebGL projects, I actually don't care about graphics that much. I think the focus on graphics is actually a significant harm to VR right now. I'd much rather have flat-poly cartoon graphics that were cheap to build and leave me at least a few MS of processing time per frame than so-called "AAA" graphics, if it means I don't have any app cycles left or I start missing frames and really need to lean on Asynchronous Space Warp to fix it for me.
It's not always possible to satisfy all constraints, they're just very strong suggestions. So "try" means exactly what it does in any other physics engine.
> It would be nice to have a list of exactly which file formats are supported, and have it available on this particular page.
LOVR uses assimp. So it can load anything assimp can. The documentation on that could be better, but it's an open source project; feel free to contribute some cycles.
> they can't claim some sort of open-source ideology driving the decision to not support MP3
Importing assimp takes little to no effort. Importing MP3 means dealing with patents. Not worth it, especially considering it's a terrible format for high quality sound. Think about the implementation details for a second.
> There's no *
Two things: for one, this project seems to only have been running for about a year, as a solo show. I'm sure more features are coming.
The other is that this is modeled after Love2D, the 2D Lua games framework. In Love2D, the same choices were made in terms of not including animations or entities etc., allowing you to use libraries instead. This keeps the framework lightweight, and allows people to choose what library they'd like to use. The design is not purely borne of ignorance.
I have my own work to do, hopefully some of it not for free.
> Importing MP3 means dealing with patents.
No it doesn't. The MP3 patents have expired. http://www.audioblog.iis.fraunhofer.com/mp3-software-patents...
> This keeps the framework lightweight
This is neither lightweight nor a framework.
Meanwhile, the author of this software did this for free, and shared it. Are you against open source software, or just against contributing back to it yourself?
> the MP3 pateets have expired.
the patents expired <4 months ago. Give the author a break. If it's so important to you, why don't you pay him to implement the feature seeing as you're not willing to contribute
>neither lightweight nor a framework
Weight - relative to UE4, unity or lumberyard, this seems lightweight. Unsure about the framework vs engine part - I always felt that when something comes bundled with batteries included, you can still call it a framework, but once it starts providing tools (scene editor), pipelines (asset processing), packaging for platforms, it becomes an engine. Debating over semantics of framework vs engine is pointless however.