+1, LÖVE is my favorite prototyping framework. It's fast as blazes to develop on.
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.
Seems it's just inspired. Last I checked, LOVE used Bitbucket, and LOVR uses Github. Would be kinda strange to spread out your projects over multiple sites like that.
I really liked this framework. It was so well written and easy explained. I wished that there are more use cases of lua. But besides mpv i didn't find any usefull scenarios. And since i normally dont write any games at work, i had to drop lua sadly.
Cross Platform
LÖVR projects work on Windows, macOS, and Linux.
I'm only seeing a Windows executable on the website, a Windows executable and Linux source on GitHub releases, and no MacOS release or source anywhere. :(
This sort of thing is the absolute pits. Now that position: sticky is in CSS, are there any good reasons browsers don't rate limit onscroll event handlers?
Holy shit, you're right. It's so bad on mobile. It's broken in so many ways. It scrolls horizontally and vertically. At one point I somehow scrolled the header instead of the body. I want to debug the page just so I avoid the same issues on my own sites.
I've kind of noticed something recently. Game developers use the term "framework" differently than web developers. When a web developer says "framework", he or she usually means a fully-encompassing system that tries to take care of all of your needs.
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.
But there aren't any spring force parameters, so I don't think that's it. It's not clear what "try" means here.
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.
It would be nice to have a list of exactly which file formats are supported, and have it available on this particular page. There are a lot of different formats. I'm not sure I can trust that "most" of them 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.
Thought it's kind of annoying that only OGG is supported. If you're really supporting "most" 3D model formats, the majority of them are proprietary formats, so they can't claim some sort of open-source ideology driving the decision to not support MP3.
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.
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.
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.
Three.js can be as performant as WebGL, since it's not hard to drop down to buffers and shaders and sidestep any per-frame overheads.
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 have a few demos with physics running at an easy 90FPS on an HTC Vive. The same, exact demo ran at a rough 75FPS on the Gear VR, but that was a while ago and I understand Oculus has released some performance improvements, so it might be a solid 75 now. The difficulty is mostly in keeping the number of draw calls low (which is common to all VR apps), and avoiding any buffer copies (which is unique to WebGL). I've been trying to build some best-practice oriented components into my environment because of this.
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.
Take the course that Unity offers when you purchase a pro subscription. There are a lot of super arbitrary and half-hidden details that you just want to go directly to the source to find out about them. The hardest part is staying awake for it all. The narrators voice is extremely boring and slow. I personally had to set the playback speed to 1.5x just to not fall asleep during the videos.
