
Show HN: LÖVR – VR framework for Lua - bjornbytes
http://lovr.org
======
joemi
Is this related to or just inspired by LÖVE, the 2D game framework for Lua?
[https://love2d.org/](https://love2d.org/)

~~~
leggomylibro
+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.

------
Willamin

      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. :(

~~~
noonat
I haven't tried following them, but the compiling doc[0] has instructions for
macOS.

[0]
[https://github.com/bjornbytes/lovr/blob/master/COMPILING.md#...](https://github.com/bjornbytes/lovr/blob/master/COMPILING.md#macos)

------
jslakro
There is a VR library in LÖVE but not a proper lib for adventures or otjer
tons of great genres :/

------
davb
The scroll hijacking on the docs pages is annoying.

~~~
dexwiz
What scroll hijacking? Looks normal to me.

~~~
davb
When I scroll on mobile (Safari), inertial scroll is broken and scrolling
feels jerky and unnatural.

~~~
josephg
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?

------
jdc0589
> sound = lovr.audio.newSource('darude.ogg')

Darude in the examples. Now I know this is legit.

------
moron4hire
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.

~~~
aaron-lebo
What kind of performance do you get with Three.js? Do you ever wish you didn't
chose the browser for rendering tech?

~~~
moron4hire
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.

~~~
penney4611
Could you tell me how to understand Unity's asset pipeline works?

~~~
moron4hire
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.

