5 ms·

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

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 9y ago
What kind of performance do you get with Three.js? Do you ever wish you didn't chose the browser for rendering tech?
- avaer 9y ago
  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.
- moron4hire 9y ago
  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.

aaron-lebo 9y ago

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

avaer 9y ago
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.
moron4hire 9y ago
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.