Babylon.js 3.0(blogs.windows.com)
blogs.windows.com
Babylon.js 3.0
https://blogs.windows.com/buildingapps/2017/07/12/announcing-babylon-js-3-0/
34 comments
After briefly testing on Mac OS:
- Chrome ~60fps
- Firefox ~25fps + fans spinning up
- Safari (hangs on loading screen)
Many of the WebGL demos I try in Safari just don't work, but the demo doesn't provide any kind of error message other than in the console. I have two wishes:
- Apple would get their act together with WebGL support
- demos would handle WebGL errors more gracefully
- Chrome ~60fps
- Firefox ~25fps + fans spinning up
- Safari (hangs on loading screen)
Many of the WebGL demos I try in Safari just don't work, but the demo doesn't provide any kind of error message other than in the console. I have two wishes:
- Apple would get their act together with WebGL support
- demos would handle WebGL errors more gracefully
I'm getting buttery smooth 60fps on chrome, safari, and firefox. I'm on MacOS 10.12.6 and the most up-to-date mainstream release of each browser
Which version of MacOS are you on?
Which version of MacOS are you on?
I'll add my experience with the "PBR Glossy" demo:
Windows 8.1
Chrome: 144fps
Firefox: 144fps
IE11: 72fps
Not sure why IE11 is getting exactly half the framerate of the other two, which are maxing at my monitor's refresh rate. At least none of them hanged or crashed.
Windows 8.1
Chrome: 144fps
Firefox: 144fps
IE11: 72fps
Not sure why IE11 is getting exactly half the framerate of the other two, which are maxing at my monitor's refresh rate. At least none of them hanged or crashed.
requestAnimationFrame is designed to animate on whole frame boundaries for the monitor on which it is running, to avoid screen tearing. So if IE can't do 144hz, the next option is 72hz. You'll similar see 60hz displays running at 60, 30, or 15 FPS.
The next one after 30 is 20 (one frame every 3 syncs).
If we want to be picky about it, the next one after 30 is "shut the app down, tear it apart, and rewrite from scratch. Anything less than 30 is completely unacceptable."
It depends on the application. In one of my jobs for an educative platform I automatically maintained it over 15 but under or at 30 (if it was over 30, it improved quality).
For the PBR Glossy demo:
Safari - 60fps, no fans.
Chrome - 59fps, no fans but notably hotter and more CPU usage.
Seems like Apple has their act together and the errors are somehow on your end?
Safari - 60fps, no fans.
Chrome - 59fps, no fans but notably hotter and more CPU usage.
Seems like Apple has their act together and the errors are somehow on your end?
I had experimental WebGL 2 support turned on. Turning it off, fixed the problem.
Got it running in Safari with no problems. Impressive considering I tried it on a mid 2011 MBA.
Mac OS here and I'm getting 60fps in FF, Chrome and Safari
60fps on Chrome for Android
Interesting, I get ~28fps on Safari w/o measurable increase in CPU utilization
On a brand new MBP, though. Maybe that has an effect.
On a brand new MBP, though. Maybe that has an effect.
Safari on a new 13" MBP gets ~50 fps here on the Sponza demo and maxes out at 60 fps on the PBR demo, without any trouble, and with plenty of other stuff running on my laptop simultaneously.
Both seem to hang at load if I turn on Safari’s experimental support for WebGL 2.0 though, so that might be what was happening to kevinb7.
Both seem to hang at load if I turn on Safari’s experimental support for WebGL 2.0 though, so that might be what was happening to kevinb7.
Only slightly on topic question, but are there a lot of webgl games out there, or only demos? Any games I find are either toys or incredibly poorly performing.
WebGL seems to mainly be used for demos.
WebGL seems to mainly be used for demos.
Purely speculation here, but I would think that devs would want to invest their time in established gaming platforms with established customer bases. Native applications with large amounts of engine / tooling built around them.
Again shooting from the hip here, but given the restricted environment of the web browser, it would seem difficult to believe that you could make a high performing full game given that you need to download THE ENTIRE GAME essentially every single time you play, no? So that restricts the size / complexity I would wager.
Again shooting from the hip here, but given the restricted environment of the web browser, it would seem difficult to believe that you could make a high performing full game given that you need to download THE ENTIRE GAME essentially every single time you play, no? So that restricts the size / complexity I would wager.
I assume the idea would be to stream in the content as required, rather than a giant upfront download, and maybe there'd be a way to prompt the user for a LocalStorage limit bump so that you could put player models or other common stuff in there?
Either way, in a world where people are regularly streaming Blu-ray quality content over the internet, downloading a few 100MB per session doesn't seem unreasonable.
Either way, in a world where people are regularly streaming Blu-ray quality content over the internet, downloading a few 100MB per session doesn't seem unreasonable.
You'd definitely be using IndexedDB, not LocalStorage for that.
I believe there's not much value in making games that run in browser and served from website. But real value of Babylon like Javascript libraries lies in their portability. I would use Electron like framework to create desktop app for my Javascript game created using Babylon, then sell it on Steam. Unity and Unreal are good portable options, but they lack the complete open nature of web technologies. They have their own private scripting languages that are not portable. A game engine written in Javascript is therefore more valuable.
https://www.starbreak.com/ uses WebGL.
Not-so-on-topic question: although I see that Babylon is more of a 3D-engine (like three.js) than a game engine, I see it has game-engine features too... How would it compare with a clear web-game-engine like playcanvas?
Are people building webgl games actually using babylon?
Are people building webgl games actually using babylon?
I would actually say it is more of a game engine, especially when compared to three.js. Babylon.js supports physics plug-ins and collisions. They also have an action manager and other useful built in methods. Their tutorials are a really good place to start: https://doc.babylonjs.com/tutorials
Since babylon.js is more of a library, though, it doesn't have quite the tools to that something like Unity has, but they have great documentation and community support, and have a nice playground for testing small snippets. If you find an issue and post a question in the forum, I've gotten a fix in a matter of hours.
Note: User of babylon.js
Since babylon.js is more of a library, though, it doesn't have quite the tools to that something like Unity has, but they have great documentation and community support, and have a nice playground for testing small snippets. If you find an issue and post a question in the forum, I've gotten a fix in a matter of hours.
Note: User of babylon.js
I just found out recently FreeCiv is working on a WebGL implementation.
Waiting for Babylon.js 5.0.
Even looks great on Mac OS + Chrome!
I hope this opens some doors...
I hope this opens some doors...
Can someone do a feature comparison between this and three.js?
I switched my current project from Three to Babylon about two years ago. At first it was just to experiment, and because I found Babylon's API way more intuitive.
But the main reason I've stuck with it is that Babylon has a compact, active set of devs (I've made bug reports and seen the fix in the next nightly build multiple times). So it's been really easy to get help and get bugs fixed. Three has way more people working on/with it, but the flip side of that is that it's way harder to find help, unless you know a good forum where some experts hang out, or similar.
The other big difference is that Babylon is more of a "game engine" than a "3D engine" - it has built-in subsystems for stuff like bone animations, audio triggers, etc. I imagine Three has similar stuff, but I believe they'd be plugins or modules that you'd need to manage separately. I don't actually use any of these Babylon subsystems though, so I can't say if they're useful or not.
But the main reason I've stuck with it is that Babylon has a compact, active set of devs (I've made bug reports and seen the fix in the next nightly build multiple times). So it's been really easy to get help and get bugs fixed. Three has way more people working on/with it, but the flip side of that is that it's way harder to find help, unless you know a good forum where some experts hang out, or similar.
The other big difference is that Babylon is more of a "game engine" than a "3D engine" - it has built-in subsystems for stuff like bone animations, audio triggers, etc. I imagine Three has similar stuff, but I believe they'd be plugins or modules that you'd need to manage separately. I don't actually use any of these Babylon subsystems though, so I can't say if they're useful or not.
three.js seems to be more well known/established than babylon and I had initially picked that for playing around. However, I got to go to a session on babylon at a microsoft conference and it was given by one of the authors and was pretty impressed. I had a freelance contract that needed some webgl and went with babylon and i'm glad i did. It better performance and the object names and concepts seemed easier to follow and a little less obtuse. IIRC, the presenter said that they are extremely diligent about working through bugs and issues on github and that three.js had quite the backlog. It helps that babylon is essentially being underwritten/subsidized by MS, where as three.js is more your typical open source project.
If you've invested tons of time working in three.js, then it may not be worth switching over. But if you're dabbling, it is definitely worth checking out.
However, all of this was about 2 years ago, and you never know what has changed.
If you've invested tons of time working in three.js, then it may not be worth switching over. But if you're dabbling, it is definitely worth checking out.
However, all of this was about 2 years ago, and you never know what has changed.
[deleted]
FWIW (probably not much) I've looked at both briefly, to build a tool with a 3d component. I know nothing about graphics (basically flunked it at uni) but Babylon seemed much more approachable than three for basic stuff (a box and a camera). However there is a lot more written about three than Babylon.
Babylon.js is an amazing framework. The 3d concepts are ingrained into the API and framework. The ability to read 3d model data from Blender and things just work is awesome.
Babylon Spector is a fully functional WebGL debugger, it is an extension in Chrome which makes 3D development on the web so much easier, works with Three.js too!