Leaderboard

I've spent the last week or so putting together a fairly comprehensive plug-in for Phaser in the form of an isometric (axonometric and dimetric to be precise) renderer for Phaser. Not wanting to stop there, I decided to go the whole hog and port over Phaser.Physics.Arcade to the new renderer by adding in an extra dimension. You can get the plug-in here: http://rotates.org/phaser/iso/ - the page also contains a working example so feel free to view the source to get a feel for how it works. I'll be creating several more examples in the coming days and weeks, as well as improving the plug-in, fixing bugs and so on. As of yet, I am undecided as to whether to embark on trying to create an isometric equivalent to TileMap (with Tiled importer) but if there's enough interest I may see what I can do. Enjoy, and I'm looking forward to seeing what you do with it!

Hey guys, since we have a few beginners here on board, trying to make their first steps in the world of HTML5 games, I thought it might be good to point you to a few resources about how to learn to write good javascript code. JavaScript is a language where you have to be a bit careful about your syntax and code style if you want to write maintainable and readable code in the long run. The advice I give to most newcomers is: DONT dive right into developing a complex game! First learn how to handle the language properly. Spending a week or two with reading through a good JavaScript book and a couple of tutorials will give you enough knowledge that will increase your development speed a thousand times and helps you avoid common pitfalls for beginners. I would suggest every beginner to first decide for a good IDE that supports code completion and syntax checking. If they even support jshint you can't wish for much more! A few IDEs are: Netbeans, WebStorm, Microsoft Visual Studio, heck even Dreamweaver. Just pick one you like. Okay, lets throw a bit content at your brains! First out, a few books I can personally recomment reading: JavaScript - The Good Parts by Douglas Crockford O'Reilly, ISBN: 0596517742 Good for beginners JavaScript Patterns by Stoyan Stefanov O'Reilly, ISBN: 978-0-596-80675-0 Very good for beginners JavaScript - The Definitive Guide by David Flanagan O'Reilly, ISBN: 0596805527 JavaScript Cookbook by Shelley Powers O'Reilly, ISBN: 978-0-596-80613-2 JavaScript Web Applications by Alex MacCaw O'Reilly, ISBN: 978-1-449-30351-8 For advanced users High Performance JavaScript by Nicholas C. Zakas O'Reilly, ISBN: 978-0-596-80279-0 For users with basic to advanced knowledge You may find some of this books in digital PDF format, if you google for it. A list of more books in digital format: http://jsbooks.revolunet.com/ I also recommend a look at the digital books from Addy Osmani. ================================================================================================================ We don't stop there. When you read even only the top two books of this list, you are armed with a set of JavaScript knowledge to develop 99% of the games you want to. Lets continue with a list of online resources, for the more digitally aligned people out there Basic introduction into Javascript For beginners and advanced users. Explains what JavaScript is and how it works. https://developer.mozilla.org/en/JavaScript JavaScript learning portal by Mozilla Take this as your starting point for learning JS online. Mozilla gathers many notable sources and links of good tutorials and documentation on this page. This is one of the best sources for beginners, as well as for advanced users to learn something new. https://developer.mozilla.org/en-US/learn/javascript Google Code University: Videos for fundamental JavaScript understandment If you are looking for a quick introduction, watch this videos. The two JS videos are both about 17 minutes long and will give you a good basic understandment if you are a beginner. There are also videos about CSS and HTML on this page. http://code.google.com/intl/de-DE/edu/submissions/html-css-javascript/#javascript Learning advanced JavaScript by John Resig This information collection by John Resig covers basic mechanics of JavaScript but they are meant to be used as supportive content to his upcoming JS book, so lack descriptions and comments. We recommend to use this only if you already have a fundamental understandment of JS. http://ejohn.org/apps/learn/ Mozilla JavaScript Guide This advanced JS guide shows you how to work with JavaScript in the browser, what pitfalls and differences you have to watch out for in the different JS versions and good tips and best practices about debugging your JS code. https://developer.mozilla.org/en/JavaScript/Guide Best practices guide by the Opera guys This very long article covers many many good tips about what you should avoid when coding with JS. Many beginners mistakes are covered and explained why they should be avoided. http://dev.opera.com/articles/view/javascript-best-practices/ Usage cases for JavaScript by the Opera guys This article covers the topic what you can achieve with using JS on your websites in the first place. You have many resources for learning JavaScript now - so this one covers what it enables you to do. http://dev.opera.com/articles/view/javascript-uses/ JavaScript Garden A growing collection of documentation about the most quirky parts of the JavaScript programming language. It gives advice to avoid common mistakes and subtle bugs, as well as performance issues and bad practices, that non-expert JavaScript programmers may encounter on their endeavours into the depths of the language. http://bonsaiden.github.com/JavaScript-Garden/ Code Academy An interactive way to learn coding, with live examples, you solve directly in the browser. http://www.codecademy.com/ ================================================================================================================ Thats my 50 cent to help the beginners starting with JavaScript. If you want to add something here I forgot to cover, just post me suggestions. greetings, Chris

Hello, I thought to place this on the demos and projects thread, however I decided to post this here as it is more a topic for which framework to use and why. I was hired by an elite software development group at Sony Electronics to help them navigate through WebGL to build a pipeline to deliver content for the South By Southwest convention and to create a foundation to quickly develop games and online media for future projects. In short, I was tasked to escape the limitations of 2D media and help Sony move forward into 3D content taking advantage of the WebGL rendering standards. This was no esay task, as I was hired Dec. 11th, and was given a hard deadline of March 5 to deliver 2 multiplayer games which were to be the focus of Sony's booth at SXSW in Austin Texas. But first I had to run a quick evaluation and convince a very proficient team of Engineers which framework was the best fit for Sony to invest considerable resources into for SXSW and which was the right coice to take them into future projects. Yhis wa a huge consideration as the WebGL framework which was to be chosen was to play a much greater role at Sony Electronics considering the group I was assigned to works well ahead of the rest of the industry... developing what most likely will be native intelligent applications on Sony devices (especially smartphones) in the near future. These are applications which benefit the consumer in making their day to day interactions simple and informative. Thus the WebGL framework to be chosen needed to be an element in displaying information as well as entertainment for a greater core technology which is developing daily in a unique tool set used by the software engineers to build applications which allows Sony to remain the leader not only in hardware technology, but in the applications which consumers want to use on Sony devices. But as I was working for Sony, I also had a greater task as there were existing expectations in developing a game on Sony devices which needed to be on par with what consumers already were experiencing with their Playstation consoles. As unrealistic as this might initially appear, that had to be the target as we couldn't take a step back from the quality and playability the consumer was already accustomed to. So back to the first task... selecting the WebGL framework for Sony Electronics to use moving forward. Rather than telling a story, I'll simply outline why there was little discussion as to which framework to choose. Initially Sony requested someone with Three.js experience as is more than often the case. So when they approached me for the position, I told them I would only consider the position if they were open to other frameworks as well. They were very forthcoming to open their minds to any framework as their goal was not political in any way - as they only cared about which framework was going to provide them with the best set of tools and features to meet their needs. And one might certainly assume that since Sony Playstation is in direct competition with Microsoft Xbox, and Microsoft is now providing the resources in house to develop babylon.js, that Sony Electronics might see a PR conflict in selecting babylon.js as their WebGL development framework. However, I'm proud to say that there was never a question from anyone at Sony. I was very impressed that their only goal was to select the very best tools for the development work, and to look beyond the perceived politics and to develop the very best applications for the consumer and to fulfill their obligations to their shareholders in building tools that consumers want on their smartphones and other electronic devices. So once again... Three.js vs. Babylon.js. This was a very short evaluation. What it came down to was that three.js had far more libraries and extensions - however, this was not the strength of three.js since there is no cohesive development cycles with three.js and although many libraries, tools, and extensions exist, more than often they are not maintained. So it was easy to demonstrate that practically any tool or extension we would require for the SXSW production would require myself or the team updating the extension or tool to be compatible with the other tools we might use on the project. This was due to the failings of the framework since each developer who writes an extension for three.js is writing for a specific compatibility for their own project needs... and not for the overall framework... as this is not within the scope of any developer or group of developers. Thus I find that it requires weeks if not months of of maintenance in three.js prior to building content, just to ensure compatibility between all of the tools and extensions needed to use for most projects. As for babylon.js, the wheel is not generally re-invented as it is with three.js, as most extensions are quickly absorbed into a cohesive framework quickly - provided they have universal appeal - and this integration ensures compatibility as there are fewer and fewer extensions to use, but instead an integrated set of tools which are thoroughly tested and used in production revealing any incompatibilities quickly. The bottom line is that there are no alpha, beta, and development cycles in three.js, thus no stable releases. Whereas the opposite exists with babylon.js. There is a cohesive development of the tools, and Sony is smart enough to see beyond the politics and to realize that having Microsoft support the development of babylon.js is a huge bonus for an open source framework. And if anyone had to choose a company to support the development of a WebGL or any framework, who better than Microsoft? With practically every other useful WebGL framework in existence spawned by MIT, most all are barely useful at best. And why would anyone pay to use a limited WebGL framework such as PlayCanvas when Babylon.js is far more functional, stable, and free? This baffles me and most anyone who chooses one project using babylon.js. The only argument against babylon.js is that the development of the framework is now supported in house by Microsoft. But for myself and others, this is a positive, not a negative. I've been assured by the creators and lead developers of babylon.js that they have secured an agreement with Microsoft ensuring the framework remain open source and free. This ensures that anyone is able to contribute and review all code in the framework, and that it remains in the public domain. Sony gets this and we quickly moved forward adopting babylon.js as the WebGL framework within at least one division of Sony Electronics. At the end of this post I'll provide a link on youtube to a news report of not only the games we built for SXSW, but the exciting new technology on built on Sony phones which uses the phones camera to capture a hight resolution (yet optimized) 3D scan of a person's head. This is only a prototype today, but will be a native app on Sony phones in the future. So our task was not only to develop multiplayer games of 15+ players simultaneous in real-time, but to have a continuous game which adds a new player as people come through the booth and using a Sony phone, has their head scanned. This was an additional challenge, and I must say that I was very fortunate to work with a group of extremely talented software engineers. The team at Sony is the best of the best, I must say. All in all, it was an easy choice in choosing babylon.js for the WebGL framework at Sony Electronics in San Diego. Below is a news report from SXSW which shows the new scanning technoogy in use, as well as a brief example of one of the games on the large booth screen. And using Electron (a stand-alone version of Chromium), I was able to render 15 high resolution scanned heads, vehicles for each head, animation on each vehicle, particles on each vehicle, and many more animations, collisions, and effects without any limitations on the game - all running at approx. 40 fps. The highlight of the show was when the officers from Sony Japan came through the booth... which are the real people we work for... gave their thumbs up, as they were very happy with hat we achieved in such a short time. And these were the people who wanted to see graphics and playability comparable to what the Playstation delivered. And they approved. Link: Thanks to babylon.js. DB

The important thing to look at with those posts is the date on them, to appreciate what happened and when. But this is a perfectly fair question, so here goes a little history lesson When I left my previous company and started Photon Storm full time, my first project was to help build Kiwi.js for a company in New Zealand called Instinct Entertainment. It was just myself and one other part-time developer (the massively talented Ross Kettle). We had nothing to work from, no template as such, so we were literally creating it on the fly - and what's more, the html5 landscape was constantly shifting beneath us as well (back then even iOS hadn't accelerated canvas fully yet). After a few months we made the jump from plain JavaScript to TypeScript. This actually helped the project significantly at the time, as we had structure and clarity that was a bit lacking before. But I also needed to start doing client games as well (to pay the bills basically, as fun as frameworks are, they don't make you much money ) so my time was now split between Kiwi and client games. And I used Kiwi for most of those early games, which helped it grow and develop. But still I was essentially coding on my own most the time, and after a while that gets really tiring. Ross was doing loads as well, but like me he had his own projects too, so we'd get strange boughts of him not being able to do anything for a few weeks, and then doing loads, and the same from my end, and it all kind of gets mixed and muddled up (it's not a great way to run a project in hindsight). Even so I coded for months: days, nights, nights into mornings, literally thousands of lines of code. Kiwi was still closed-source at this point and was a quite monstrously sized project. Too much so really. At the time I really wanted it to support DOM as well as Canvas, and spent a good while refactoring to support this. In hindsight it probably didn't need it, but back then DOM was still significantly faster than Canvas in most browsers (you could argue, for certain games, it still is) but of course adding this dependency didn't help with the scale of the project. So I'm literally burning the candle at both ends, trying to manage a hugely growing small business and trying to keep Kiwi moving forwards with effectively zero project management. Remember no-one else was allowed to see what we were doing, we couldn't release it onto github (due to funding applications going on at the time) and it was all just getting too much. There weren't enough hours in the day to manage it all and I basically burnt out. To try and rekindle my love for it I literally spent a weekend while the family was away hacking together a crude conversion of Flixel. I literally copied it wholesale, having to rebuild classes that existed in AS3 and porting the others. A couple of days later I was done - it was small, clean and just worked, because it only tried to do a few things so it did them pretty well. It was called Kiwi Lite (a name that I feel is a strong indication of my mindset at the time) and I wanted to release it on github. I was told I couldn't use the name as Kiwi had to remain closed at that time. So I asked Adam (creator of flixel) if I could call it Flixel5, but he said he'd rather I didn't as it would confuse things with the Flash build. So I spent an hour brainstorming some names with my good friend Ilija and we settled on Phaser. He drew a cool little space dude sprite and logo and the first build was pushed to github on April 12th 2013. I had always intended it to be a 'younger brother' to the much more sophisticated and feature-complete Kiwi.js, and for a good while that is how it remained. But an interesting thing happened: other people started using it. It started to take on a life of its own, and a small but constant trickle of devs started submitting pull requests and bug fixes. And then people actually started making games with it. And this does a curious thing when you've been working effectively in isolation for so long: it motivates you, like nothing else possibly can. And although I carried on working on both for a while, I slowly drifted away to Phaser because I was getting real tangible feedback and support, and it was infectious. The team at Instinct hired other devs to work on Kiwi and they've done an excellent job of cleaning it up, adding in WebGL support and making it a really attractive framework, and they released the first beta late last year (and didn't even tell me ). It's still TypeScript to the core, something I moved away from with Phaser - a move that's well documented on the forum if you want to read about my troubles with it!, but it's well worth looking at and using, especially if you like TypeScript or come from AS3. And while they were finishing Kiwi, Phaser evolved. When I swapped to plain JavaScript that was the same time I swapped to using Pixi.js under the hood, mostly because Mat is such a great guy but also because it was tiny and clean and it made sense to me. Version 1.0 was released just under six months ago, and for some reason it's hit a real chord with developers. Just so we're clear there is (or was) no 'breach of contract' here. There was a simple agreement in place, and I literally poured my heart and soul in Kiwi development for months, way more time than agreed (or ever invoiced for!) because I believed in what I was building. I'm not involved in development of it any more though, because it's no longer my "baby". A lot of work has been done on it, lots of internals changed (for the better) and the new devs own it now. It's their creation and they don't need me sticking my oar in. I've really held back from promoting Phaser, I think in part because I felt guilty and somewhat humbled that people even liked it and used it! And I wanted to give Kiwi time to release and establish itself. You can count the number of posts about it on my blog on one hand for example, and even though it has been ready for months the web site is still just a single pager. But that didn't stop it growing in popularity. I'm genuinely amazed at how well it's going. I'm not really doing anything other than trying to constantly improve it and help people use it, but I guess those are 2 quite fundamental things Phaser 2.0 is finally the version I'm truly, genuinely 100% happy with. I've spent weeks fixing bugs, making it simpler under the hood, using Pixi.js more intelligently and improving it as much as I can. It's taken a long time and a lot of work to get to this point and as corny as it sounds, absolutely none of this would have happened if it hadn't been for the community around it. The more people that use it, the more I want to make it better. And for those that submit pull requests and help fix bugs, you're the best When 2.0 ships in March I'm no longer going to hold back from promoting it, so you'll see it appearing in a lot more places and things will step-up a gear around the site and tutorials. tl:dr - I spent a long time working on Kiwi, but am no longer part of that team. It's a great framework and well worth using. Phaser was a weekend creation born from a pit of frustration/depression that went mental and grew into what you see today, utterly unplanned, but utterly wonderful because of it.

Hello everybody, As you surely noticed it, the old debug layer has been reworked in something bigger... called the "inspector". This tool has the goal to become the 'F12 tool' of our beloved engine, without replacing the official editor. It's dedicated to HELP the developer by providing some debug features. You will find almost every feature from the debug layer, and much more: display shaders code, display textures used on materials, check stats, enable lights... All properties are refreshed almost in real time (actually every 200ms for performances reasons). AND you can update any value (among strings, numbers and booleans) by clicking on it and pressing 'enter'. Sure, there is still work to do and bugs to fix. But in the current state, we decided that it is already more useful than the debug layer was. I'm still working hard on it, don't worry ! You can also help me a lot by reporting every kind of bugs in this thread and even contribute to its development. In the next days, I'll first fix all the annoying display and integration bugs. Then, I'll work on : - Restore clickables labels from the old debug layer (for Dad72 and DK ) - Update the documentation (of course) - How to contribute (add a new tab, add a new tool, change panel color theme...) - Add new features ! (Cameras, particles, textures, audio, animations...) - <insert your suggestion here> I'm having a lot of fun to work on this, and I really hope you will find it as useful as I do ! Cheers

Hello good people of the babylon.js community! Update #14 from January 29th, 2017 Primitive Collision Manager (PCM, @ller request) The PCM is finally done! Well, first release, I've already spotted some not supported cases... Anyway, you can check a PG demonstrating the feature here: http://babylonjs-playground.com/#1PXWLR#2 (I've commented the PG for you to see how it works) Turned out that I didn't do what I wrote in the previous message, I didn't check for OOB and I've implemented a generic triangle set versus triangle set intersection algorithm right away. Basically all primitive types now create/update a Tri2DArray which contains a list of triangles describing the primitives surface. It needed to be that way because an Ellipse with a intersection of 8 is graphically not shaped like a perfect ellipse: there's not enough polygons, so I couldn't use a intersection algorithm involving a true/perfect ellipse, same goes for the Rectangle2D with round corners. So I decided to go for the most generic and accurate way. All primitive types are supported except the new WireFrame2D one. Through the PCM object you have a list of all primitives intersecting with the Canvas' border (if you activate the feature), it's useful. You also have a list of all the pair of two colliding primitives. From a given prim you have the intersectWithObservable and intersectWith properties to get notified of new/removed intersections and to access the full list of them. New Text Alignment (vertical and horizontal) and word wrapping features for Text2D (coded by @adam, I'm very thankful to him! It's good to feel less alone on this whole coding...) Basically now you can set a left/center/right text horizontal alignment and a top/center/bottom for the vertical one. If you specify a size for your Text2D primitive you can now have auto word-wrapping if the line exceed the horizontal limit. Maybe @adam could share a PG demonstrating the feature! New Primitive Type: WireFrame2D Well, I needed it to draw the debug World AABB and Cluster of the PCM, so I wrote it. The Primitive accept many WireFrameGroup2D, each one having a default color and contain a list of lines. Each stored vertex has its own color. Basically you create a WireFrameGroup2D instance then use its method to fill it with vertices. Note: it's Line List, not line strip: each line is defined by two own vertices. You can use an API to start, fill, end a LineStrip but internally it will double the vertices for everything between the first and last vertex. Right now this Primitive doesn't support any kind of intersection (point or prim-prim), I'll add an intersectionThreshold and implement the algo any time soon...It's not a priority right now... Misc things The BoundingInfo2D now support a WorldAABB with an efficient dirty/update, I obviously needed it for PCM Each Prim Instance has now a uid property which is a unique id (a GUID), I use it as a key to store the prim or prim related data into a StringDictionary, it's an efficient way to retrieve a given prim without going O(n). There's a Triangle versus Triangle intersection method in the Math2D.ts file, its implem is slow. If someone has the code for a Tri-Tri in 2D implemented using the Separating Axis Theorem (SAT) algo: I'm in ! Update #13 from January 24th, 2017 WorldSpaceCanvas TrackNode feature So I've developed the feature requested by @royibernthal to create WorldSpaceCanvas that track a 3D Scene Node with the optional feature for the WSC to always face the camera (billboard mode). You can find a demo in this playground. It was truly missing to the whole "WorlSpace Canvas interacting with 3D Scene" scenario. Other users requested more about this specific scenario and it perfectly makes sense: C2D was develop to provide 2D support for the 3D Scene, I've been focus on the "2D stuff" by itself a lot, because, well, it's already a big task, but yes there should be more things to come on this area, I'll try to dev feature requests on this matter with a higher priority. Update #12 from January 11th, 2017 Few announcements: We can now use BMFont to render text with Text2D PG here the documentation of the Text2D was update to explain the different techniques you can use to render text (normal, Super Sample, Signed Distance Field, BMFont) and which one you should use. (Thanks @MasterK for the idea and help) There's a new page about how the Rendering is working, it will help people to understand how to get transparent sprites, for instance. (this page is currently only accessible by the link I gave before, because I've messed up the link in the Canvas2D Homepage, yeah, that's my special ability, DK loves it) Some new Playgrounds are available at the bottom of the Home Page I was ill during the release of the 2.5, so I couldn't update the doc and the what's new, so I've updated the what's new of the documentation web site, go take a look if you want. As a separate module, Canvas2D has its own section in the What's New. Update #11 from January 5th, 2017 Long time that I didn't develop new features but here we go: AtlasPicture is now supported, see the documentation about it. Scale9Sprite is a new feature of Sprite2D class.The Sprite2D documentation was also updated. You can play with the following PG: Scale9Sprite AtlasPicture Of course you can use Scale9Sprite for a Sprite generated from an AtlasPicture. Update #10 from October 21th, 2016 allow3DEventsBelowCanvas Until now, pointerEvent occurring above a ScreenSpaceCanvas were also sent to the 3D Scene, many people (rightfully) complained about this so I decided to add the feature, which is called "allow3DEventsBelowCanvas" (which is false by default). The PR is here for more info https://github.com/BabylonJS/Babylon.js/pull/1448 (preview files updated and PG not updated so far). You have to realize that this is a change in behavior, now by default events won't be sent to the 3D Scene if they occurred above the Canvas, but I figured it made more sens this way. If you want them to be sent anyway, just set the setting to true! Update #9 from October 19th, 2016 Stabilization The latest weeks were spent on keeping stabilizing the Canvas2D feature, fixing bugs and adding feature only when necessary. Overall bug fixes were concerning Positioning Engine (alignment), StackPanel Layout Enigne, pointerEvent observable (leave/out now works better), some dispose issues solved, you're supposed to have no more opacity/transparency issues (well, let's say, "less"). One new feature One new feature was developed recently, during the creation of a ScreenSpaceCanvas you can now specify the renderingPhase setting, allowing you specify for which camera and which renderingGroup the Canvas is supposed to be rendered to. Simpler version: you can now interleaved 3D layers (which are renderingGroup) with 2D layers (which are ScreenSpaceCanvas). Many people requested it ( @MasterK, @HenryPeng, @stormwarestudios) to render 3D content above UI for FX (particles) or simply some 3D preview (like a 3D character preview in a UI). This playground is a very raw demonstration of the feature. Modularization Oh, by the way, I nearly forgot to tell something pretty important: we have recently extracted the Canvas2D feature (and the forthcoming GUI Lib first code lines) from the main babylon.js file. This is the first step of what is going to be a modularization of babylon.js, Canvas2D/GUI being obvious (and easy) candidates. What is changes for you? Well, not that much, if you use C2D/GUI you now have to use the "babylon.canvas2d.d.ts", "babylon.canvas2d.max.js", "babylon.canvas2d.js" that are sitting next to the "babylon.js/d.ts/max.js" files in the "dist" directory of your choice (right now only the "preview release" directory contains the Canvas2D related files, for obvious reason. The module's name is still "BABYLON", which will ensure you'll compile without changing anything. On a repository point of view, the source code was moved from /src/Canvas2D to /canvas2d/src/. Our lovely boss made the move and the Gulp config to compile everything the same way babylon.js does so you don't be lost. La surprise du chef! And the "chef" is not me, but another core member @Temechon spent some very valuable time (and I can't thank him enough for that!) to work on a feature I desperately need for so long but that I'm unable to code (well, in the time frame it will took me) which is called: c2dinspector.js. Basically the c2dInspector is a HTML Pane that is added on the right side of your HTML pane and that displays all the Canvas2D instances in your Scene (well, Engine to be more accurate) and their content as a tree of Primitives. You can select a given Primitive to see its details on the Detail Plane below, you can even change some values (still work in progress). In the tree, for each item there're two icons at the very left, an "eye" to show/hide the prim, and a "double frame" which is used to show/hide the debugDisplayArea (more on this below). This feature will help you (and me!) debug and understand better what's going on and why! It's not released yet, but a beta will be very soon (tonight or tomorrow), it's still Work in Progress, but hey, it's better than nothing and it won't harm you. The debugDisplayArea (the only thing I coded, bugs are to expect!): as you may know a primitive has four area: layout, margin, padding and content, this feature will display them with a given color code (layout being light red, margin is yellow, padding is magenta, content is cyan). This screenshot below is the same UI as above but with the debugDisplayArea on the "GUI Visual Placeholder of MainWindow", which has a margin of 50, 50, 50, 50 (the yellow area shows it) and padding of 100, 100, 100, 100 (the magenta area show it). The content in blue is the Windows' background, in light grey, which is here covered by the blue area. GUI Library I've started the GUI Library, it's going on very well, but I just can't work as much as I wanted on it the last couple of weeks, so there's delay: that's life. There's a separated thread about the GUI here so don't expect me to say more in this post, got watch the other thread if you care about it. That's all folk, enjoy, as usual: feedback are welcomed, you can do it in this thread of course! I just don't want this thread to be a "bug tracker" one, if you have issue, keep creating a new post and don't forget to mention me as I don't look at the forum everyday to see if someone needs help (but DK does, happy him...) Update #8 from August 31, 2016 I pushed a new commit today that address many things around using Scale on the Canvas object directly. I'm lazy so I copy/paste the PR description: You can now set a Scale (or ScaleX/Y) to a Canvas2D object, it will render as expected, for every caching strategies. At creation time of a ScreenSpaceCanvas you can set a designSize which will be used to compute the Canvas' scale automatically in order for you to specify absolute coordinate in the frame of the designSize (MasterK request) Any Cached Renderable Group can have a new GroupCache Behavior: GROUPCACHEBEHAVIOR_NORESIZEONSCALE. When set the cached bitmap for the Group won't be resized when the scale of the group will change, improving performances over rendering quality Ellipse, Rectangle are now drawn with a prescale computation to ensure the best result when using high/low scaling Prim2DBase has not the actualScale and actualScaleX/Y property that return the accumulated scale of the primitive. At their creation, primitives can specify if they should not inherit from the scale of their parent through the dontInheritParentScale setting. I don't know if many of you will get the GROUPCACHEBEHAVIOR_NORESIZEONSCALE and find a usage, but I thought it was the time or never to do it, so I did. And it works pretty well. I think for mobile gaming it may help to improve the perf by setting/keeping a fixed resolution of what's being rendered into a Cached Renderable Group2D. The designSize mode was made upon a request from @MasterK and it's really a good idea, I can see the use case from a game UI point of view and I hope it will work the way it should be, otherwise I'll do bug fixing! If there's no more urgent thing I'll go back on my working list and the next thing (that was already started but paused) is supporting the Device Pixel Ratio, which is another big thing for mobile gaming I think. I will be a breaking change for people who are right now "compensating the lack of this feature", but well, I'm sorry, there's nothing I can do about it except I wished I knew more about HTML few months ago! I know most of you are still trying to understand how things work with the Canvas2D and don't have time to try and use different Caching Strategies (and then rely on the DONTCACHE mode). Truth is the other modes were pretty bugged, they are less bugged now, but I'm not sure it's working the same. To solve this matter I'm revamping my whole "Unit Test" project, which was a local thing and not as powerful as it should be. There are so many different combination to test a given Use Case against: the different Caching Strategies, the support of the Instanced Array and with different Device Pixel Ratio values. I have to find time to put a good Unit Test framework and publish the whole stuff once it's done, because I think it will help all of you to discover the many things you can do and how. When this will be done then I think I'll start the true "why I did this": a GUI Library based on Canvas2D, with the UI Controls you all are waiting for. The foundation of Canvas2D is getting more and more stable so I think it will be soon the right time to start it and it will be the perfect chance to fix dozen of bugs, I'm sure of it! Update #7 from August 13th, 2016 @ Legoland, Billund, Denmark The latest fix is a long ongoing one noticed by @FlashyGoblin concerning transparency of Sprite2d. To make a long story short: I mixed up the implementation of AlphaTest and AlphaBlend (aka Transparency), the result were...well ugly...and you couldn't do things like the one FlashyGloblin ran against. So here are the new ground rules about this: I try to behave the same way the 3D Engine StandartMaterial does, so people familiar with it will catch things up pretty quickly. One noticeable difference is that useAlphaFromTexture is true by default. There are three render modes: Opaque, Alpha Test and Transparency (Alpha Blend). If you don't use Alpha in a Brush or a Texture and the Opacity is 1, the primitive is rendered in Opaque mode If you use Alpha in a Brush, if you set BaseTexture.hasAlpha to true in a Texture your primitive uses or if the Opacity is not 1, then it will be either Alpha Test if useAlphaFromTexture is false or Transparency if it's true. Beware: until now you didn't have to set hasAlpha for a Sprite2d to deal automatically with transparency, this is no longer the case! With the latest version your Sprite2d will be rendered as Opaque if BaseTexture.hasAlpha is set to false (which is the default value no matter what your bitmap stores). To sum up Text2d is set as a Transparent primitive to ensure a proper blending. Shape2d based primitives will be either opaque or transparent based on Opacity and Alpha in their Brushes. Sprite2d can use the three modes, the default behavior being Opaque if the texture has hasAlpha to false or Transparent if it's set to true and you can use useAlphaFromTexture to switch to Alpha Test. Update #6 from 15 June 2016: babylon.js 2.4 is out! I took the time to finish the overview/tutorial documentation. I also updated the playground and use the BABYLON. prefix everywhere it was needed (which mean I removed the alias like "var Scene = BABYLON.Scene") in order for you the user to copy/paste more easily. The documentation entry point is: http://doc.babylonjs.com/overviews/Canvas2D_Home (with all the playgrounds at the bottom of the page). The architecture/design doc is: http://doc.babylonjs.com/overviews/Canvas2D_Overview_Architecture Please, I've also created a PRO for the Canvas2D feature in Slant, for those who think it's a great addition to babylon.js, please follow this link and upvote, this work is on my spare time so fame is my only reward! thanks! http://www.slant.co/topics/3777/viewpoints/4/~open-source-javascript-3d-engines~babylon-js#15 Update #5 from 13 June 2016: new features added and also a lot of little bug fixes This version is supposed to be the "first official release", there were breaking changes with the previous ones, most notably: You don't use the public static CreateXXX method to create a primitive, you can now use the constructor, the parent is an optional parameter in the settings object (see sample below). At construction you can use a settings object that contains many many properties that you can set as you wish, some are somewhat overlapping (e.g. there's size, width and height, you set either the first or the two latest). This was designed to bring you some flexibility. You won't certainly notice, but the location of a primitive will always be relative to its bottom/left corner, regardless of the origin you set. This change was necessary to bring something coherent and understandable when alignment/layout comes into play. You have to use the actualPosition and actualSize properties to get the "real" values. position/size properties are the value before layout/positioning takes place. New features: This new creation mode allows you to cascade the creation of objects (see below). You'll see that Brushes can now be initialized with a string to make the code more simple. The same is true for margin/padding/alignment. You will find example in some playgrounds, doc will come asap. Lines2D now fully support intersection/picking, as well as roundedRectangle. The size of a primitive is now optional, if omitted it will be sized to its content bounding box. (the same behavior as Group2D) Margin, Padding, Alignment is introduced, you can play here. Margin/Padding support units in pixels or percentage, the value can be inherited from its parent or simply be automatic (0) A LayoutEngine feature now allows to position/size the primitive, by default it's the CanvasLayoutEngine that is assigned to all primitives, unchanging the behavior you already know. But I've made in few minutes a StackPanel Layout that you can test here (don't forget to CTRL-F5 your web browser to fetch the latest .js file) By the way, there's a new playground for Transparency testing. Update #4 from 03 June 2016: new features added and also a lot of little bug fixes intersection works better on Lines2D, I now support every Cap types, it's also accurate on rounded Rectangle (if you click on the empty zone create by the rounding corner it won't generated a hit). interaction mode can now be enable in WorldSpace Canvas, you can take a look at this PG for an example: http://babylonjs-playground.com/#1BKDEO#9 I've also added a alignToPixel property in Sprite2d to make sure the rendering of the sprite will be aligned to the render target device pixel, is ensure the best rendering quality, but in rare case of slow animation you would probably want to turn it off to ensure smooth animation. by default it's on. I won't detail it too much here because it need proper doc to be fully understood, but now you can give your own WorldSpaceNode to render a WorldSpace Canvas on something else that a simple Plane mesh. This mode is easy if you don't use Interaction, but if you do, you have to give a method that compute the world space intersection with your mesh and then compute the local position in the Canvas of the resulted intersection. This is not the simplest method to code but you have an example with the current implem for Plane World intersection to Canvas. Update #3 from 25 May 2016: new features added Breaking changes in the API: concerning the way to create Canvas and Primitives, now it's using the same signature than other object in babylons.js, with an options{} json object for optional parameters. There are default value each time it's possible. Including many bug fixes and little features improvements. We have two new primitives: Ellipse2D and Lines2D. I worked hard to dev a nice Lines2D primitive and I hope you will like it! A full Overview Documentation is now online, the main entry page is here: http://doc.babylonjs.com/overviews/Canvas2D_Home, from this page you'll be able to access to every others pages of the overview doc and also all the playgrounds I've made so far. The reference documentation is now online for the 2.4 you will find documentation for about 80% of the Classes/public methods. Update #2 from 19 May 2016: new features added Lots of little bug fixes, I hope everything will be ok with the origin property, nesting primitives, the text render is way much better now than before. Interaction is supported! There's an pointerEventObservable property in Prim2DBase for you to be notified about many things concerning interaction with a pointer (mouse, touch, pen). I've also added the support of the ActionManager, it's the same as Mesh and Sprite. I support all triggers exception Intersection and KeyUp/Down. Animation is supported too! You have the animations property in the base class of a Primitive for you to add animation the exact same way you would do for the scene objects. Update #1 from 16 May 2016: added link in the Documentation section to a new tutorial that explains how to write your own primitive types Original post I am very pleased to announce you a new feature I've been working on for weeks now! Well, to put things simply, Canvas2D is...a 100% WebGL 2D Engine! It may sound strange at first but I really thought it was missing to this lib, all started from the time I realized I couldn't efficiently display text in babylon.js. So I started to work on a new feature to do so and one thing led to another and I realized we could use of a real 2D Engine for many things! It's not related to the HTML Canvas Element at all, Canvas being a generic term (like Rectangle, for instance). I've called it Canvas2D because the main class controlling the feature is called Canvas2D and acts as its name suggest: you can draw 2D content inside. For performance reason the rendering is 100% WebGL your graphic card loves to do these kinds of things if you spend the right amount of time to create a good rendering engine. Developing such 2D Engine wasn't an easy task because I wanted to lay strong foundations to allow it grows decently through time. Future will tell if I did well or not! At last, for a better understanding this features serves the same purpose than Pixi.js, but the intent were slightly different: Pixi.js relies on two rendering engines (HTML Canvas or WebGL Canvas), but the Canvas2D relies only on WebGL, because it's made to be used along with a 3D Scene, which requires WebGL anyway. Primary focuses while designing the feature: fast, flexible and hopefully easy to contribute. Concerning the "fast" if your device support the WebGL Instanced Array extension, you should be really pleased with the result, the engine was designed to work with this extension (even though if it also works without). I think I overall did well although if there's still room for improvement. Basically, how does it work? You can create many Canvas2D instance on a given Scene, you have two kinds of Canvas: ScreenSpace: the canvas is displayed above the 3D Scene, in 2D space, like you would expect See this example. But there's another interesting mode: WorldSpace:the canvas is displayed in a 2D Rectangle as a part of the 3D Scene, you setup its position, rotation and scale, like a Mesh (well, it's in fact a Mesh of a Plane). See this example. When you want both Performance and Flexibility Things get a little technical! When you create a Canvas you have to choose a Caching Strategy. Why? Because depending on what you will do with it you may use different rendering strategies. CACHESTRATEGY_DONTCACHE: easy, nothing will be cached, all Group2D are called "logical" and the whole content is redrawn every render. If you have few things or if it always change, you may use this mode. It's also the most stable right now. CACHESTRATEGY_TOPLEVELGROUPS: my favorite! Only Group2D that are direct childs of the Canvas will be cached and considered as RenderableGroup, their children Group will be logical only. If you have some On Screen GUI to display at the different corners of your Viewport, this mode may be the best for you. CACHESTRATEGY_CANVAS: Well, the whole Canvas is put into a cache, you better avoid this if you create a Canvas with the size of the Viewport because a texture/depth buffer will be allocated with the size of the viewport. Note: this is actually the only mode that can be used with World Space Canvas. (the other at the exception of DONTCACHE will follow later). CACHESTRATEGY_ALLGROUPS: this is the most technical one, sound brute force at first, but its the opposite: the most complex one. Potentially every groups are Cached, but in reality for each Group you create you can set a CacheBehavior which states if: The Group follows the cache strategy (then be cached), It won't be cached (then rendered every time) or If it's cached in the nearest Cached group parent. This mode has been elaborate to allow the creation of GUI controls being part of a complex canvas with a lots of Depth and diversity. As for today, this is the least tested one, be indulgent. A canvas is made of Primitive: this is the base type, has many property like position, rotation (along the Z axis), scale (uniform), visibility, an origin, zBias (if you're not happy with the default behavior), and a list of children primitives. Group2D: to create a new reference of frame, but also if you wish to cache its content, to avoid redraw at every render. If you have primitives that are most of the time static (or changing sporadically, in response of an event for instance) it'll be well advised to cache them to speed up the canvas rendering. Renderable Primitive: as its name suggest, it's a base class for primitive that render to the canvas, so far: Text2D: to display text. Sprite2D: to display a sprite (a part of a texture if you will). Shape2D: another based class for a 2D Shape made of an optional Border and or Fill content. The Border and Fill Content are drawn using a specific type of Brush, for now SolidColorBrush2D and GradientBrush2D are supported. TileBrush2D (so based on a bitmap pattern) should make its way in the 2.5. So far only the Rectangle is implemented, but it does support roundRadius, which is nice. I think I can implement Ellipsis and Circle in no time, but well, I wanted to focus on the engine first. nPolygon, WireFrame should come later. Vectored based graphics (SVG support) should be a nice addition too. Documentation The tutorial can be found here. An overview of the feature architecture and capabilities can be found here. That's where you'll understand everything you can do and what you can expect in term of performance. A long tutorial to explain how to write your own primitive type can be found here. Few last things My mantra for this feature: by indulgent with the current state of the Canvas2D, but be fearless on the feedback side! I will try my best to fix things as much as possible, I've made already some testing, but nothing will replace the impartiality of the user! I also have some bugs already logged (like don't try to change the origin of a Text2D, the result will be rather funny...and unpleasant) and will fix them asap. Critical features are missing: Group2D and Text2d horiz/vert alignment, more shapes. As well as interaction support through an event system and a better support for animation. I will work on them right away. I don't make promise of what will be there for the 2.4 RTM but I expect everything except animation improvement, really hoping that interaction will make it (edit: also done). A big thanks to the core contributors of the lib for their help: @Deltakosh @RaananW @Temechon @jerome and @Sebavan! I'm waiting for your feedback!

After a LOT of hard work I finally pushed Phaser 2.0.0 out today! It literally only just snuck into the March 13th release date But I'm super happy with this build. The headlines: 1) Pixi 1.5 under the hood = much faster in nearly all cases 2) Multi-physics engine support: Arcade, p2.js full Body and Ninja. 3) Better Group handling - more sensible parenting, less code, better child support, faster. 4) Better Text handling - Bitmap Fonts with spaces in the name! Text shadows, text events, web fonts, etc. 5) More consistent input events across more game objects than before. 6) Literally hundreds of bug fixes. I cleared out github entirely 7) Much better tilemap collision than ever before - tile delta options, tile padding on bodies, faster getTiles, faster rendering 8) Tilemaps supported across Arcade, p2 and Ninja! 9) Lots of bizarre physics bugs nuked. 10) Retro Fonts 11) Tilemap ray casting 12) Load Lime/Corona polygon files direct into p2 bodies. and loads I forget because I've not slept for 26 hours In short ... It's all on the repo: https://github.com/photonstorm/phaser Site to be updated when I'm back in the land of the living. Thanks to everyone who helped test and reported bugs

So a few of you are rightly confused after my recent commits Let me explain what's going on with the physics systems inside Phaser ... As you may know, I've been really happy with p2.js for all of Phasers proper full-body physics requirements. It's excellent and I'm really pleased with how well it integrated. However on mobile it doesn't take long before the frame rate starts to dive. This is no fault of p2, it's having to do a lot of heavy lifting math and mobiles just struggle. Even with just 50 bodies in the scene you can see it start to suffer. So I wanted to offer an option to devs. In Phaser 2 no Sprites have physics bodies as standard, they all need to be physics enabled (much in the same way you enable them for input). This helps keep things fast. Where-as in 1.x Phaser is spending a LOAD of time processing a physics Body it may never even use. Arcade Physics, back from the dead So I decided to go back and resurrect Arcade Physics. Not the broken SAT one in 1.1.4, but the one previous to that. I merged lots of the fixes I had made in 1.1.4 (things like process callbacks actually working properly) with the previously working separation code from 1.1.3. This means that existing 'old' games won't have to be ported over to p2 to run, they can just use Arcade Physics like before - the only difference being they'll need to enable the Sprite bodies. All those annoying/broken things about 1.1.4, like the way gravity and velocity are messed-up, are all fixed. Because physics is 'off' by default I created a Physics Manager via which you do things like 'enable p2' or 'add a physics body to this sprite'. While I was doing this it occurred to me that you could actually have p2 and arcade physics running together in the same game. p2 could be controlling whatever bodies you give it, and arcade the same. After a few basic tests this was working just fine. Here is how you activate a physics system: game.physics.startSystem(Phaser.Physics.NINJA);The important thing to remember is that a single Sprite can only belong to ONE physics system. So you can enable a Sprite for p2 or arcade - but never more than one. It cannot exist in multiple simulations at once. Here is how you enable a Sprite for say Ninja physics. You can do it directly on the system like so (here creating a new Circle shape): game.physics.ninja.enableCircle(sprite, radius);Or you can use the physics manager interface (this will create an AABB shape for the sprite, the default): game.physics.enable(sprite, Phaser.Physics.NINJA);In 'enable' calls you can pass in either a single object or a whole array of them. p2 and Arcade running together Why on earth might you want to have both running? Well for a lot of games I would say there is what you could call 'simple' and 'advanced' requirements. For example you could have a nice complex polygon terrain all handled by p2, with a car body with motors/constraints/springs driving happily across it. But what if you wanted that car to be able to fire up to shoot some aliens overhead? Assuming you can fit those aliens into clean AABB shapes then it's now entirely possible to have the car itself controlled by p2, driving over a p2 managed landscape, but when you shoot it launches a stream of bullets managed entirely by Arcade Physics, and collision with the aliens who are all running under Arcade Physics too. In short you're leaving p2 to deal with just a handful of complex bodies and motion and not bogging it down with ultra simple requirements. I'm not suggesting that all games will need this, but at least you have the option now. Great, but what the hell is Ninja Physics? As I was working through all the above I realised that even with p2 and arcade available, that still doesn't cover all bases that a game may need. What if you wanted to use Box2D? Or Chipmunk? It dawned on me that I should stop referring to the physics systems inside Phaser as just 'arcade' and 'advanced', but actually call them by name. Then I could provide a (mostly) standardised physics Body object, a single Manager to handle them, and then you could use whatever physics system your game actually needs. The Physics World object needs to implement a standard set of methods, but otherwise can work quite independently. While renaming these classes I remembered that I had spent weeks about a year ago working through the physics system that Metanet Software used in their awesome N+ Flash ninja games and porting it to JavaScript. I had shelved it as it was only suitable for certain types of games and didn't play well with Arcade Physics settings (at the time I was trying to merge some of their collision responses with Arcade Physics). But I dug out the old source files and had a look, and sure enough it was pretty much complete. So to test out my theory of Phaser supporting a variety of physics systems I created Ninja Physics from it, and integrated it. It's a really nice little physics system, supporting AABB and Circle vs. Tile collision, with lots of defs for sloping, convex and concave tile types. But that's all it does, it's not trying to be anything more really. As you'll see from my Labs demo it works well, and is really quite fast on mobile too. Which one do I use?! I've no idea, it depends on your game The choice is yours. If you need full-body physics, then p2 obviously. Arcade Physics has proven successful in lots of games so far, so you could carry on using that too. Or maybe if you like what you see re: Ninja's tiles, you could test that out. The important thing is that it's up to you now, and although it requires more careful planning with your game, you can even combine them too. Phaser doesn't have all of these physics systems running together wasting CPU, they all start off as 'null' objects and do nothing until explicitly activated. I'm also tweaking the grunt scripts so that the build folder will provide versions of phaser with none, one or all physics systems embedded into the code, so they're not going to waste space either. The plan is to carry on adding support for popular physics systems in, most importantly Box2D and Chipmunk. Again these will be separate libs you can bundle in with phaser, with just a single variable stub in the physics manager. As long as the Body and World objects adhere to a few simple requirements, it will 'just work'. Anyway, hopefully this clears things up a bit!

Hello community! As you know, the playground is a very valuable tool if you want to try, experiment and share your Babylon scenes. You can even search for a specific word in the whole snippet database from the documentation website, that make it easy to find and discover a new snippet. And because we know it's a very powerful tool, we worked hard last month with @Deltakosh on a better user experience when searching for playground. From now on, when saving a new playground, you'll have to fill several information: a title, a description and some tags. It will be asked only once at the playground creation, and all next iterations of this PG will share these metadata. You won't be able to redefine it afterwards. For all PG that don't have any metadata, you will be asked to fill it only once. The search has also been improved. You can search for a word in the PG code like usual, but you can also search for a word into a PG title/description, or a specific tag. The overall quality of search had also been improved (ou can now search with several words, that will return all PG that contain these words, and several bugs have been fixed). All this work couldn't have been done without @Jaskar and @DeathSoul who wrote all the code (back and front-end), and @Deltakosh of course So go try it : http://doc.babylonjs.com/playground Please helps us by reporting all bugs you can have in this thread Thank you very much !!

Hello all, As some of you already knew it, I've been working on the a Babylon.js ebook for several months. Today, this book is finished, and I named it Learning Babylon.js. What is included in the book: - Getting started with Babylon.js (Hello world in 3D!) - Learn how to use primitives (box, spheres, torus,...), default cameras and lights - Detailed guide on materials and textures - Particles - Shadows - Collisions - Intersections - Physics engine (Oimo.js) - User inputs (keyboard/gamepad) - Animations - How to use exporters (3DSMax, Blender, Unity) - Shaders - Skeletons/bones - And more! The main goal of this book is to CREATE a whole game, chapter by chapter: start with the basics (cubes, spheres and torus), add materials, replace with custom 3D models exported from 3DSMax/Blender,... The game you will create is greatly inspired from the Super Monkey Ball serie. By the end of the book, you will have a complete game to play with, and (I hope!) enough knowledge to create your own. Sadly, I was not able to handle all Babylon.js features in this book alone (I would have spent a whole year on it, and DK is adding new features every day!), but I tried to cover as much as I can with one game. You can find some more information here : http://learningbabylonjs.com/, as well as some screenshots of the book. I hope it will help you in your next Babylon.js projects. If you have any questions, remarks, I'm not far from this forum (as you know it:) )

Hello, It has been a while I did not introduced a new feature in BJS so as the higlight layer was famous, let s introduce the glow layer: http://www.babylonjs.com/demos/glowlayer/ Documentation is available here: https://doc.babylonjs.com/how_to/glow_layer

Hey Devs and All, I'm just feeling a bit sentimental about how far this forum has come the past 4 years. @Deltakosh and @davrous ( + others) have given us a creative outlet that has turned into a new frontier. I just wanted to say how much I appreciate that I am able to come to a place that provides me not only technical advice, but I've made many new friends as well. Much love to you all. DB

http://shellshock.io My first BabylonJS project is a whacky multiplayer first person shooter featuring, well, eggs, of course! It's in very early development and still fairly rough around the edges, but it's super easy to jump in quickly and play. It's just been made public, so finding people to shoot may be a little hit and miss (pun intended). Enjoy! Facebook: http://www.facebook.com/ShellShockGame Twitter: https://twitter.com/eggcombat

Hi people, I'm glad to introduce you to my new project : OfficeGames. http://officegames.eu Well ... 3D games for office computers (not only, though). As said in the text, there's only one game for now and it's not even finished. I need your feedback and ideas to improve it and get it to the right direction. So please let your opinions, comments, criticisms, wishes, whatever in this thread. I won't answer everyone but will read them all for sure. Have fun [EDIT] FYI, my best score ever is 10200.

Hello, I'm happy to announce that the node based PBR Composer is on the road. What is PBR Composer ? In short, PBR Composer helps you design and visualize a PBR Material in an efficient way. Parameterizing takes place by dragging and connecting specific nodes from a palette (typically textures, colors and uv-coordinates) to the output node, which represents the PBR Material. A preview panel lets you see all changes in realtime and the corresponding js-sourcecode will be updated as well. The resulting graph can be downloaded in JSON format for later use. Images can be inserted via preview fileselect dialog and/or Drag&Drop, in latter case the images will be transformed to embedded data-urls so the javascript functions can be reused without dependencies. Different meshes and environment-maps are available to see the material under different geometry and reflective light conditions. Motivation for PBR Composer: Due to the complexity of the PBR material (soo many combinations with soo much amazing effects) there is a need of having realtime feedback reflecting the changing parameters. Other than some editor already out using a bunch of parameters in confusing properties panels, nodes lets you to concentrate only on the parameters you need giving a nice overview in form of a graph. Nodes can also be shared and avoids therfore redundancy in the sourcecode. The goal is/was to make the user interface as efficient as possible. The idea for realizing the PBR Composer was inspired from Shader Editor. Technical details: PBR Composer is a web application based on dat.gui, w2ui, litegraph.js and of course on BABYLON.js TODO: At the moment, PBR Composer is customized for PBR-Glossy materials. The current activity is realizing a function for switching between Glossy and Metallic paradigms. Any questions? Let me know... PS: PBR Composer is still in alpha stage but will be deployed in beta stage soon Here it is te demo ...

Hello, I am happy to announce the release of my last Dev: http://spector.babylonjs.com This will help any of you willing to troubleshoot or understand what are the webgl commands generated by the engine ! Have fun,

I had hoped to create a brand new Babylon Christmas Card - but real life gets in the way of virtual Reality So I decided to bring back my first Christmas effort with a few changes - I know @dbawel likes it. Basically some added geometry - a cottage, a sign and chimneys. The chimneys gave me the opportunity to experiment with particles - in addition to the particle effect I stole from @Wingnut; a long time ago. I had to create 5 textures, and I also tweaked the terrain. Anyway here it is: A Babylon Christmas Card You can also change the volume of the music Up or Down with the "u" and "d" keys, and if you, for what ever reason, would rather have no music, it can be toggled On/Off by hitting the "o" key. The camera speed can be made slower or faster with the "s" or "f" keys. Have fun. Ohh and the sign - do whatever you can do Nadolig Llawen, Merry Christmas, Joyeux Noel, Feliz Navidad, Frohe Weihnachten, to one and all. Next year, hopefully a new Village cheers, gryff

Thanks to the awesome Babylon framework, I'm creating a city building and simulation game; I thought I'd share the progress so I can ask some questions in case I get stuck. Here's a sample town (read-only at the moment because the UI is far from complete): http://misc.blicky.net/c2/?id=1 (desktop only) Some screenshots.. Current issues: Shadows are way too 1990's, even though the targetTexture is 4096 in size. It would be nice if the shadowGenerator's matrix would adopt to only include faces that are in the camera frustum. That way shadows would look good from afar and close-up. Solved Road intersections are a pita. The current solution, using CSGs on the road segments (extruded shapes) and some math to create a plane is barely acceptable and rather slow/error-prone. Performance. While 'idle' FPS is not bad, when adding more structures, the browser will lag because it is using MergeMeshes() to merge the new structures to the existing meshes. I'm currently transitioning to SPS meshes, because they build a lot faster, however are also more restrictive. So my question is: why is MergeMeshes() slower than SPS.buildMesh() and can it be made to match the latters' speed?

Hi, One of our intern in Microsoft France and now core member of the team, @Luaacro, has been working with us building an online editor for Babylon.js: http://editor.babylonjs.com. In order to showcase what you could do with it, he decided to build a complete impressive scene: http://www.babylonjs.com/demos/ruins Yes, it has been entirely built with our editor! It uses a lot of high end effects we have in the engine like a standard pipeline, dynamic shadow generators and particles. He has written a small article about it: https://medium.com/babylon-js/babylon-js-editor-demo-is-now-live-a8fc217a6324#.wp85aq2kx As the scene could be a bit hard to render on every machine (you need a GTX970+ to render it without issue), I’ve added some code to monitor performance based on the last 60 frames rendered. If the fps is too low, I’m: - First lowering the size of the render canvas to 66% and removing the standard pipeline (post processes cost a lot of perf) - Lowering the size of the render canvas to 50% if it’s not enough If fps goes up again, I’m doing the opposite but will never re-enable the standard pipeline. It means that if your machine is able to render the complete demo in full resolution from the first frame to the last one, it has a great GPU and/or a great browser. Enjoy! David

Hello, It often happens in a project that a grid is required but it is not that easy to get it right (anti-aliased, easily configurable...). So please, find below a new material available in the babylon extensions (2.4) that may help dealing with it. This material requires the webgl derivative extension in order to work correctly. The documentation is available in here : http://doc.babylonjs.com/extensions/Grid As well as the playground : http://babylonjs-playground.com/#1UFGZH#12

Today the now-closed browser based MMO Glitch released all of their art assets as public domain. There are hundreds of megs worth of stuff. From lovely looking snowy landscapes to bottles of Goat Whiskey (yes, really). You'll have to dig deep and dig hard to extract what you need, but some amazing stuff in here: http://www.glitchthegame.com/public-domain-game-art/ Also found this pretty sweet castle art set today on Graphic River too. Not bad for $5 http://graphicriver.net/item/castle-platform-game-tiles-sprites/5633823 Feel free to post more links here if you've got them.

Hello, I'm proud to talk about version 2 of my MMORPG editor (FR and ENG) that I renamed to "Web Game Editor" instead of "HeroonEngine" which was a name that looked too much like another existing editor. This version 2 comes with a new, more modern, community-based website. It will be possible to find a manual and video tutorials for getting started, as well as a shop and a forum (FR and ENG). The editor has undergone many improvements, new features and various fixes to make it more stable, more functional and more successful. Some things have been totally rewritten. It will come with a small Integer demo that contains two terrain and plenty of media on offer. I should hopefully release version 2 in the month and make an announcement of its release. For the moment I present it here. I have been working on this editor for years since BabylonJS was born. The editor has been renamed 4 times and rewritten 3 times totally and this name is the last change. Content and features: Here is some screenshot:

Take a look at where I'm going with this and let me what you think. It is basically a heavily modified Babylon Unity Exporter Demo Video Link U3D - BabylonJS Game Editor Toolkit Quick Intro Demo API Update Warning: I tried to make it shorter, i took a deep breath and spoke as fast I could but it still took about 1 hour and 20 minutes. But the technical folks who are up to it and want to see how to use and how i put together a Manage Scene Component API with a light weight 'Unity-Style' life cycle with native babylon scene hooks for 'start, update and destroy' stages... Then this is for you U3D - BabylonJS Scene Component API Intro Note: I found the problem at the end of the video with the getSceneMarkup function. I had to move the controller.ready() to AFTER the scene.manager has been set. But you should still where i was going with that

Hi all, I would like to introduce Stupax: A different sidescroller game, where you are not the guy, you are the level! In fact you control a movable platform using the arrow keys or your gamepad (Gamepad API) to help the guy (namely Stupax) to get through the levels. You can play the game here: http://mbarde.bplaced.de/stupax/ Controls: Arrow keys / Gamepad 'R' for level restart 'ESC' pause game and open menu Create and test your own levels here: http://mbarde.bplaced.de/stupax/editor.html You can find further information on my website and view the source code including contributions for the music, sounds and textures on GitHub.

Hi Everyone, I recently launched a preview version of my game made with BJS, and you can try it here. It's a 3d billiards game, but currently only Snooker available in this preview version. Hope you'll like it, and have fun. It currently supports these browsers on desktop: Firefox, Chrome, Safari and Edge. (To BJS team: I have added a "powered by babylon.js" in the 'about' page of the game, please let me know if it is allowed to use your logo, and if I have used the right logo, since I just grabbed it from your home page, and converted to png.)

The default pipeline has been updated to add Depth of field, Grain, Chromatic aberration and MSAA post processing. The existing bloom effect has also been updated to only bloom the bright highlights instead of blurring the entire image. See the updated demo and docs. Please let me know if you have any feedback. Thanks!

A simple demo displaying the power of the ParticleSystem by creating a low-hanging fog. https://www.babylonjs-playground.com/#BHNVUE#1 Thanks to @Wingnut for finding the PG used as base for this demo. Have a nice saturday

Hi boys and girls, I don't know if you noticed, but the repository has a new directory called "Viewer" : https://github.com/BabylonJS/Babylon.js/tree/master/Viewer The viewer is a simple way of displaying a model without the need of JavaScript at all. It (obviously) uses babylon, and can be customized to your needs using HTML tags and HTML attributes. The only two important lines in your page would be: <babylon model="https://playground.babylonjs.com/scenes/Rabbit.babylon"></babylon> <script src="https://viewer.babylonjs.com/viewer.min.js"></script> Which will result in this: https://viewer.babylonjs.com/basicexample You can read about how to use it and how to customize it here - http://doc.babylonjs.com/extensions/the_babylon_viewer It is currently in a very early stage. The (public) project can be found here - https://github.com/BabylonJS/Babylon.js/projects/6 , including future plans. I am in the process of simplifying the development, build, and deploy process and it will soon be available on NPM as well, if anyone wishes to embed it using webpack/imports/require/whatever

Last update of this information was 13 August 2014. Note: As of this writing, CocoonJS (2.0.*) comes in a total of three modes. [system] WebView creates an instance of the default browser for a platform, loads its own API, and then hands off the code execution. In most cases, it is the same as running the code in a mobile platform's default browser. WebView+ is often the same as WebView, but adds in Chromium-based libraries. For Canvas+ mode (previously accelerated, "Canvas 2D/WEBGL") it strips out things like XML and most DOM and CSS support to make running the canvas as fast as possible. Because of this, most common things like getElementById and createElement in JavaScript have reduced functionality. It is designed purely for Canvas-based projects. (For the 2.0 branch, see the changelog from 1.4.7.) Since there is limited DOM support, make sure to use an empty string for the parent element during the creation of a game object when using the accelerated/Canvas+ mode. (This is to make sure the created canvas element is appended to the document.body object, and not some other element the getElementById function cannot find.) var game = new Phaser.Game(window.innerWidth, window.innerHeight, Phaser.CANVAS, '', {preload: preload, create: create, update: update});Issues with Phaser <= 2.0.7 and CocoonJS <= 2.0.2 (Canvas+) Images Use of multiple images may introduce disappearing or flickering results. Text Single-line text printing works. However, using the newline character will not produce the correct results. Setting anchor.y values do not work correctly.Shadows do not work. XML CocoonJS does not have native support for XML. Its XHR does not return responseXML and it does not have a window.DOMParser object. Scaling Generally, you can use window.innerWidth and window.innerHeight to compute the size of the screen in CocoonJS. However, if you know there might be a device pixel ratio issue, the following code works for that. var width = window.innerWidth * window.devicePixelRatio;var height = window.innerHeight * window.devicePixelRatio;Depending on your needs, Phaser's built-in scaling manager will often be enough. However, the following code suggested by Starnut should be helpful for accounting for odd screen sizes as well. var w = window.innerWidth * window.devicePixelRatio,h = window.innerHeight * window.devicePixelRatio,width = (h > w) ? h : w,height = (h > w) ? w : h;// Hack to avoid iPad Retina and large Android devices. Tell it to scale up.if (window.innerWidth >= 1024 && window.devicePixelRatio >= 2){width = Math.round(width / 2);height = Math.round(height / 2);}// reduce screen size by one 3rd on devices like Nexus 5if (window.devicePixelRatio === 3){width = Math.round(width / 3) * 2;height = Math.round(height / 3) * 2;}var game = new Phaser.Game(width, height, Phaser.CANVAS, '');BitmapFonts Because of the lack of XML support, one solution for BitmapFonts is to convert the XML into JSON and use an alternative loader. This post covers the code needed and what to use to convert the XML into JSON. Audio Most often, audio problems are related to the device itself, not CocoonJS or Phaser. If you are running on an Android device, make sure you have OGG or WAV (16-bit ONLY) files. Apple devices support MP4, OGG, MP3, WAV (16-bit ONLY), or MPEG. (Remember too that MP3 decoding, depending on the device, can often be slow.) On some platforms, a user-activated event (like touch) is needed to enable sound. This specifically affects iOS devices, but is not uncommon on other platforms too. Using something like a "Tap to Continue" button or an initial menu works well to signal to the player to tap to enable both the game and sounds. Filters Filters don't work currently. (As reported here.) Buttons There is currently a problem where image-based buttons can sometimes disappear. It is under investigation. It is HIGHLY recommended to update to newer versions of Phaser ( >=2.0.7) and CocoonJS ( >=2.0.2). Issues between older versions of both libraries are no longer being actively tracked.

Hi, The babylon.js team is proud to share the last project we’ve been working on during the last weeks during our free evening & week-ends. We’ve done a lot of things into this new demo, I’ll blog about it later on. You can check it there: http://babylonjs.com/demos/sponza It uses almost all cool HTML5 available features: WebGL, Web Audio (with some 3D sounds), CSS3 transitions (during the demo mode), Fullscreen, Pointer Events (across platforms via jQuery PEP), Gamepad & IndexedDB/HTML5 Offline API. We’re using our new Universal camera that provide a FPS like experience using either keyboard/mouse, touch or gamepad. So if you’re using a PC, you’ll be able to move using keyboard/mouse, on a mobile device using touch and on Xbox One using gamepad. It’s the same code completely transparent for the user. This new Universal camera is now used by default by Babylon.js (for instance on BabylonJS.com, all demos can now be used using mouse, touch or gamepad) Michel has done an awesome job optimizing the original scene from Crytek to create a beautiful experience but still very performant. For instance, it runs at 60 fps on an iPhone 6s! Some cool demo scripts to test. On Windows 10, use MS Edge: 1 – Launch the demo on a touch enabled laptop 2 – Click on the “camera icon” and then move using keyboard/mouse 3 – Move using a finger touching the screen 4 – Plug a Xbox controller in one of the USB port and move using the controller 5 – Click on “Pin this page to Start” and you’ll be able to show the various tiles defined. 6 – Switch to airplane mode or disconnect from Internet. Click on the pinned Sponza site. 7 – The web app still loads and provide the very same experience! (thanks to our IDB engine and the HTML5 offline API/manifest) You can follow the same procedure on iPhone/Android devices. I've created a big set of icons/tiles for all platforms. On Xbox One: 1 – Navigate to http://babylonjs.com/demos/sponza 2 – Use the Xbox pad with the A button to switch between interactive/demo mode 3 – Use the Y button to display our debug layer 4 – Use the gamepad normally to navigate inside the 3D scene J Enjoy! David

Most people here know that I have an 82 DSLR cammera scanning rig. I use this specifically for scanning in people at the shortest time possible (which is currently 1/300th of a second). However, such a complex rig is not required for scanning objects. You don't even need a DSLR camera or a handheld scanner. In this demo I used a simple iPhone 6+ and walked around a statue. We took 89 photos from different angles. My web designer had to stand on my shoulders for the top row of photos. The bust needed to have smooth shading but the base has sharp edges which I needed to preserve so I wanted flat shading for that. With babylon.js you can't pick and choose which edges to smooth. In order to pull this off I made the base and bust 2 separate meshes and turned off smooth shading on the base. It still doesn't look perfect, but it was much better than everything smoothed or everything flat. This is my first test scanning with an iPhone and I usually scan people so this is a rough demo. www.punkoffice.com/statue

'Twas the frame beforeRender, and all through the scene, Not a vertex was indexed, the canvas was clean. Observers were hung on event loops with care, In hopes that St. Deltakosh... soon would grow hair. The cameras were nestled on Y-offset peds, The lights well-positioned in greens blues and reds. A box and a sphere and a tube with a cap, A torus, a plane, and a fresh-baked light map. When out of the engine arose such a clatter, It woke-up young Davrous to check on the matter. Away to the Windows... he flew in a flash, To resize the viewport and refresh the cache. The specular shined on a heightMap of snow, The includedMeshes were starting to show. When what to his wondering eyes did appear, A Wingy-made bobsled and 12-pack of beer. The BJS framework so lively and quick, Was rendering elves each with onPointer pick. They all went to work wearing new Christmas formals, Connecting the verts and adjusting the normals. A beautiful pano on isBackground Layer, And cool twinkle lights... it just couldn't be gayer. This holiday playground was now well-awake, So Davrous relaxed with a nice Christmas cake. More rapid than beagles the elves made their fame, They yelled at observers, and called them by name: "OnPointer, onReady, onActivate true." "onAfterUnbind, onBeforeRender, too!" The scene came to life at a fine framerate speed, The particle snows had a great random seed. The post-process pipe added gorgeous effects, The boys at Three JS were all nervous wrecks. Ol' Davrous and DK and all of the puppies, Were dancing and singing like freshly-fed Guppies. And Davrous, he smiled and he started to sing... “Merry Christmas to all, and to all a good ping!” Happy holidays!

Hi everybody, Pretty new to Phaser.js but kind of old to AS3 I just started to port a as3 game into html5 with phaser, but my client wanted transitions between states - just like my game had in flash. Therefore I created a plugin just for this. You can find it here: https://github.com/cristianbote/phaser-state-transition Let me know, what you guys think, or what can be improved. Cheers!

After hundreds of hours of hard work, 13 Release Candidates and changes pretty much across the whole board - Phaser 2.2 is out! 2.2.1 Update There were a couple of small but really important bugs that slipped in at the last minute, one involving alpha not working in Pixi.js in WebGL mode, and the other a Tween Manager update. These have been rolled into a 2.2.1 release which is now live. Everything else remains the same as with 2.2.0, no API changes took place, so it's a safe direct update. What's new in 2.2.0? One of the nicest and most surprising things about a truly open-source project like Phaser is that you never know who might jump on for the ride. I've been extremely lucky with the support I've received over the years - fellow developers both fixing bugs and reporting issues, all helping to make Phaser stronger as a result. But sometimes a single individual can come along and make a substantial difference all on their own. A quick glance at the Change Log for this release will show many different contributors, but one stood out more than any other: Paul Stickney. Thanks to his contributions alone Phaser is now sporting a powerful new Scale Manager, nicely updated API docs and many other fixes and features across the board. The Scale Manager, a core part of any HTML5 game has had its own book published about it: A Guide to the Phaser Scale Manager which is available now. One of his other major contributions was in updating Signals, the event system used inside Phaser. Before Phaser was creating thousands of Signals in a busy game, most of which sat idle. Now they've gone on a diet in terms of memory consumption and hide behind a proxy causing them to not even be created unless needed. This has cut down on the amount of objects being generated every frame dramatically. As you may have noticed we've bumped the release version to 2.2 from 2.1. This is because there are some API breaking changes and some core fundamentals have been updated as well. The biggest change here is the move to a proper fixed-step internal game loop. The logic and rendering are now fully decoupled, with both Arcade Physics and Tweens having been updated to use this new system. This is by no means a panacea for overloading low-powered mobile devices. However it will help prevent issues arising from devices running Phaser games at different speeds just because it has a slower processor. Also given a large update is the Tween Manager. This is now hooked in to the new timestep code, smoothing out tweens when the frame rate drops. New features have been added, including the ability to pause and resume a whole timeline of tweens and tween chaining has vastly improved. The Change Log is indeed extensive. I would say that if you are *already* working on a Phaser game, and a good way through development, then you should carry on with whatever version you used before. But for all new projects definitely take the leap into 2.2 and I hope you enjoy splashing around in its new features Thank you to everyone who beta tested 2.2 with us in one of its many Release Candidate incarnations. Your feedback helped fix issues that would have been otherwise troublesome to find and it's a process we'll carry on with for future builds. 2014 has been an amazing year for Phaser and I'd like to take this opportunity to thank everyone who has been involved, one way or another. Your support has been fantastic and we've built great things. Here's to 2015. Cheers, Rich

Hello, I just released a new game called BLOCK here : http://pixelcodr.com/games/block/index.html Move the block with the arrow keys and try to complete all levels !

I'm really pleased to announce that the long-awaited 1.1.4 is finally out. There is a full write-up about it on my blog here: http://www.photonstorm.com/phaser/phaser-1-1-4-kandor-released-check-out-the-new-features-and-roadmap Thank you to everyone who contributed feedback and testing during development. This is a significant upgrade, so be careful before blindly upgrading from 1.1.3 if your game is well established under that codebase. If you find issues (and I'm sure you will!) please check the Examples first to see if there is a new way of handling things, then post about it on the forum (don't clog up this thread, it will be impossible for us to keep track, create a new one). Or use github issues too. Thanks everyone

Here's a list of the tools I use daily for game creation, coding, animation, etc. I hope you'll find some useful info, let's begin. Art and Animation ########################################################################## Photoshop: The daddy and mommy of raster editing. I've tried lots of alternatives over the years but I always came back to it. Even though it's not a specialized tool (creating pixel art for example) I've found that it's quite flexible and it allows you to work on a variety of project types. I USE IT FOR: Text manipulation, logos, etc. GUI creation - shape tools and the alignment tools come quite in handy. Add effects (strokes, shadows, etc) and you're golden. Overall finishing touches. Playing with curves,intensity, blending modes to give my graphics that extra visual boom. ALTERNATIVES: GIMP: Also called the poor's man Photoshop. It's a pretty decent and powerful program and it has many of the features offer by it's more expensive brother Photoshop. I gave it multiple spins over the time and I was disappointed in the GUI arrangement and the overall workflow. Asesprite, Pyxel Edit, Graphics Gale: These are 3 different pixel art creation software packages. I don't do pixel art and I only tried them for a short amount of time but I hear good things about them. ########################################################################## Illustrator: One of the most famous vector editing programs out there and rightly so. First of all it's an Adobe product so you have good integration with other Adobe products (such as Photoshop) and a certain level of quality. Although it's a bit tricky to get into it at first it's really worth it - there's nothing more powerful out there in terms of vector editing (as far as I know) and you can really create some awesome art for your games. ALTERNATIVES: Corel Draw: Altough I am a big fan of PainterX (digital painting at it's best from Corel) I'm not so taken aback with Corel Draw. Obviously you can create artwork in it but I had the sensation that it is more geared towards desktop publishing. It's a good product all in all but you should rather take the time to learn Illustrator - it will be worth your time. Inkscape: This is a free vector editing software and you would probably expect it to be bad in some way. It's really not. Very easy to learn and with an intuitive workflow it allows you to create art simple and fast. True, it lacks the sophistication of Illustrator but it's the perfect choice for a beginner artist - the guy behind game art for programmers uses it extensively so he must know something. ########################################################################## Moho: IMHO the best 2d skeletal animation software out there. The only decent competitor out there is Toon Boom but it lacks in the bone setup area and it's mainly focused on frame by frame animation. Spine it's simple and intuitive but it lacks the power required for more complex setups ( it also lacks vector drawing). It's only drawback is that it can't import properly .psd's and .ai's but it compensates by having it's own (very powerful and sometimes more intuitive than Illustrator) vector drawing tools. Oh, and I mentioned that it also has particles? Motion Blur? Z Depth layer ordering and animation? IK animation? Animation Morphs (like the ones you can find in Maya)?Smart Bones? Animated strokes? 3d capabilites? You get it, I'm hooked. I USE IT FOR: Character and prop creation 2d Animation ALTERNATIVES: Spine: A lightweight 2d skeletal animation program. Intuitive and friendly especially for artists that are new to animation. ToonBoom: This is Moho's main competitor as it has similar complex animation tools. It has a steep learning curve and it offers lots of features in terms of animation. I think it is more geared toward animation movies rather than games but you can definitely create great art and animation in it if you invest in learning it. Adobe Animate:Adobe's 2d animation flagship product. Since it's Adobe you know you'll get tight integration with other products from the Adobe Suit (Photoshop, Illustrator) and a certain standard of quality. One thing I liked about it was the particle creation capability and the large variety of brushes. Although it's a bit weak in the area of rigging and bones (specially compared to Toon Boom or Moho) it is a powerful and complete piece of software so it might be worth your time. ########################################################################## Cinema4D: Altough I've been infatuated with Maya I've come to love this friendly 3d editing software. Why? Because it just works. It works fast, it works good and it's easy to learn even for 3d noobs. I USE IT FOR: 3d Text creation Various object renders ########################################################################## Lightroom:The best photography catalogue out there. I had 50 thousand photos once (paintings pics mostly) and other similar programs died just trying to read them. Not Lightroom. How can a dev might use it? For me it's useful when I gather lots of art inspiration from various websites, games, etc and I can browse and rate them with ease and pleasure. I USE IT FOR: Inspiration Management ########################################################################## SqCheck:A nifty little utility that allows you to preview rendered frames (sequenced) of animation at various speeds. It might not seem as much but it's much easier to focus on the animation final result without all the clutter of a big animation program. I can spot common mistakes quite easily - like having too much static extra frames at the end of an animation (like having a walk cycle and the foot stays just a bit too much at the end of animation). Or I can load it each third or second frame sequence to see how it looks without all that interpolation in between (because smaller spritesheets and snappier animation - Richard Williams said in it's incredibly inspiring animation book - The Animator's survival kit. I USE IT FOR: Animation final touches ########################################################################## Timeline Fx: A particle editor for all your particly needs. Explosions, flames, bubbles, etc. It has the best blend of usability and ease of use. Another particle editor beast that I like it's Particle Illusion - altough you can create the same particle effects with the standard particle properties (particle life, velocity, lifeOverSpeed, etc) it really shines at particle assembly - you can combine multiple particle effects, animate them, create deflectors/blockers/wind, clip them to alpha masks, etc. I USE IT FOR: 2d Particle creation and FUN ########################################################################## Irfan View: An image viewer that can cook, clean and take out your garbage. Well, maybe not but it does have a motherload of options and it supports a large variety of image formats (.psd, .tiff). It even reads .txt for god's sake. My favourite shortcut in Irfan View is Shift + 1. It opens your image in a predefined application - you guessed it, Photoshop. And it's very fast. I USE IT FOR: Image viewing and fast access to Photoshop. ########################################################################## Programming ########################################################################## Sublime Text: "The text editor you'll fall in love with" - says in the website title. Well I did...over the heels. Coming from a C# background I was used to Visual Studio - awesome IDE, ideal for large projects and with lots of little helpful features. Sadly using JS in Visual Studio it's a drag. Intellisense it's basically useless, go to code definition doesn't work well most of the time, starting it takes quite some time. Sublime Text to the rescue. Lightweight, uber customizable, lightning fast, works like a charm with JS. I recommend installing JS Hint for linting and Js prettify to make your code readable. Also learn some general shortcuts for a better workflow. And if you really wanna fly in it learn either Emacs or Vim shortcuts (it has plugins for both). I used Emacs first - a bit too heavy and a carpal tunnel risk. Switched to Vim and after the rather abrupt learning curve I feel much more comfortable. And if you really wanna protect your hands and increase your touch typing speed I'd reccomend switching from Qwerty keyboard layout to Dvorak. ########################################################################## Phaser: Html5 game framework. Why? You probably know why since you're on this forum so you're probably a dev yourself. Easy to learn, quite powerful, good performance. ########################################################################## Other ########################################################################## Sprite Sheet Exporter Photoshop Script: Altough you can create spritesheets directly from many 2d Animation programs I find it it allows for much flexibility to import sequenced frames in Photoshop (using File > Scripts > Load Files into Stack) and doing various refinements -I usually get rid of all transparent pixels with Image > Trim and apply various color corrections - this will be my master animation document. After that I can resize it to fit my needs (can happen multiple times during the life of a project) and export it to a sprite sheet with the Exporter script. ########################################################################## Audacity: Simple yet powerful sound editing software. While I can't create music/sfx by myself I can greatly improve it by mixing it, fading in/out, applying various effects. ########################################################################## AutoHotkey: A nifty little utility for Windows that allows you to remap various shortcuts, exe paths and other commands to custom keyboard bindings. It increases the workflow speed enormously and it makes a working day more pleasant. Imagine double clicking on Photoshop.exe 30 times a day. It might not seem much but if you're in another application you'll have to minimize it and hunt the icon on desktop - it interrupts the creative process and takes a bit of time. It's much easier just to press a combo keyboard shortcut (mine it's Ctrl + R) and there pops Photoshop. Or my current working folder. Or sublime Text. Try it - you'll love it. ########################################################################## Wamp: Web Development Environment. You'll need it to develop Html5 games and it's very easy to install and use. ########################################################################## Sumatra Pdf: For all your pdf reading needs - programming, animation and design books. First it was Acrobat reader and it was good but then it got bloated and sluggish. Then it was Foxit and it was so much faster than Acrobat Reader but then it got bloated and sluggish. Now it's Sumatra and altough it's simple it's very fast and it supports .mobi and .pdf. Let's hope it stays clean. ########################################################################## Various Online Tools ########################################################################## Tiny Png: Incredible png compression with very little quality loss (if any). I even saw 90-95 percent file reduction on my png's - that's going from 1 MegaByte to 50 KiloBytes - pretty impressive) ########################################################################## Trello: Task management and collaboration. I heard good things about it but I think it's better suited for larger projects and I still prefer to keep track using pen and paper. ############################## @Goblet Ed################################## draw.io: "draw.io is completely free online diagram editor built around Google Drive that enables you to create flowcharts, entity relation, mockups and more. Your data is stored only in Google Drive, so no additional third-party to trust with your data (or extra accounts)." It has good object snapping which makes placing and aligning things very pleasant. ########################################################################## I USE IT FOR: Creating screen flowcharts One page designs Level designs (can import your sprites) ############################## @Goblet Ed################################## Coggle.it: Pretty mind-mapping tool. I USE IT FOR: Creating pretty mind maps to organize new information ########################################################################## *************************************************************************************************************************************** Feel free to contribute in comments (link and your personal experience) and I'll try to keep this updated - just tools and utilities please, there are lots of resources lists already. ***************************************************************************************************************************************

Dear community, A few changes were recently made to the forum. We have a new and improved layout to work with, and some new sections for organization. The forum is now divided to four sub-sections: Demos and Projects is used to showcase your work. If it is either a nice playground or a whole website you have created with Babylon.js, we want to see it! Please share a link, a screenshot, or anything project related. Questions & Answers is used to ask questions about the framework's features, and about subjects you don't quite understand. Don't know how to use CSG? Don't understand what a physics body impostor is? this is the place for you. It is built in a "stack overflow" style - questions have their answers, which can be upvoted or downvoted. Please don't forget: Show us what you did so far. We are all very happy to help (always), but we won't do your homework for you. Start a playground, share a link! A functional demo (with a question at the end) will give everyone the chance to understand what you mean. If you share an external link, have the bablylon.max.js version available on the server. Otherwise it is impossible to debug. If this is not possible - share some code. Unless it is a philosophical question about the life, Babylon.js and everything, code is the right way to go. Try searching the forum before submitting a question. Chances are, this question was already asked by a different user and was already answers. Pro tip - the forum's search (thou revamped) misses topics from time to time. Try searching using google/bing/duckduckgo/altavista, adding "babylon.js" before your question. If you have your question answered, mark it as answered. This will surely help other people in the future! Bugs is used to report bugs in the framework. If you tried doing something and it doesn't work correctly, it is a bug. Please don't forget: Unlike questions and answers - a demo is a must! I can't think of a way you found a bug without actually writing code. Same as in Q&A - If you share an external link, have the bablylon.max.js version available on the server to help us debug the error.. This is an open source project. We never say no to contributions. Found a bug? Have some time? Look at the source and see where we might be wrong. Try the current stable and the preview version before submitting - maybe it was already fixed! Announcements will be used by the framework's moderators to notify about news regarding Babylon.js. New versions, a new CDN server, a Babylon.js conference, those kind of things. Apart from that, there is still the main page which will be used for general discussions. The main page also hosts old topics from the old forum's layout. This is the place to ask about the members' programming experience, talk about tutorials, share a nice link you found about the framework. Whatever doesn't fit into the other sub categories. This is also the place to ask about integration with other frameworks or other technologies. Some general Guidelines: Be nice! Don't expect anyone to help you just because you have a problem. Don't forget - this is an open source framework. We are all working on it on our spare time. Please try being clear! We are all international users, English is not always out mother tongue. We do understand that! Liked a post? Press the like button! It will only make the other side feel proud. It is also a way for you to bookmark answers you liked. If you have any personal questions, contact one of the forum moderators. Anything else belong in the forum for everyone to learn from! Don't be afraid to make mistakes or to post questions you feel are silly. They are sometimes the most important ones! That's about it! Happy writing

Documentation: https://ssatguru.github.io/BabylonJS-EditControl/ Demo: https://ssatguru.github.io/BabylonJS-EditControl/demo Source and Download: https://github.com/ssatguru/BabylonJS-EditControl/releases Release 3.1.0 (01/22/2018) * planar guides always rotate to face camera. makes it easier to pick them * mesh with parents or childs are properly supported. see https://ssatguru.github.io/BabylonJS-EditControl/demo-parenting.html * constructor now has an additional optional parameter called "pickWidth". This determines how close the pointers need to get to an axis before the axis can be picked up. The default is 0.02 * constructor "scale" parameter has been made optional. Default is 1. * code refactored. private properties are prefixed with underscore "_". This warns JavaScript coders from using those as JavaScript does not honor TypeScript's "private" keyword. Underscore also helps with property name mangling and thus reducing the minified size. * added additional demo file (demo-parenting.html). The long term intention being to use these for tests. Release 3.0.0 (12/31/2017) major change to rotation UI now uses the more common "spherical" guides new methods getPosition() getRotationQuaternion() hide() show() isHidden() setVisibility() few properties and methods which were private were exposed by mistake. They are now hidden code refactoring. Release 2.5.0 (12/03/2017) added translation and scaling bounds. client can limit translation and scaling between a minimum and maximum value contributed by @focomoso Release 2.4.5 (09/04/2017) see https://github.com/ssatguru/BabylonJS-EditControl/releases for details with this release the edit control is now also available from the NPM repository Release 2.3.0 (06/05/2017) Changes migrated from Java to TypeScript rewrote picking process to make the control snappier added transforms in planes added scale snap changed UI - hopefully more intuitive now Release 1.0.0 (03/22/2016) Of late I had been working on a small in-world kind of 3D editor similar to what you find in open sim or second life kind of virtual worlds. As I worked on it I realized that the part used for controlling translation, rotation or scaling of objects can be re-written as a reusable component. So that' what I did I created, what I call a "BabylonJS EditControl". You can use this in your editor, if you like, to handle translation, rotation or scaling of meshes. For a simple demo see https://ssatguru.github.io/BabylonJS-EditControl/demo For source code and explanation on how to use it from your code see https://github.com/ssatguru/BabylonJS-EditControl The initial version was written using Java and JSweet. ( don't think I could have done this without JSweet ) Newer versions from 2.3.0 have been written using TypeScript. Please try and provide some feedback. Regards

Hello everyone! I thought I'd share something I've been working on for the past few weeks. A plugin for Phaser that provides collision handling for sloped tiles and half tiles, similar to Ninja Physics but somewhat more concisely. Check it out on GitHub, give it a whirl, let me know what you think! Github: https://github.com/hexus/phaser-arcade-slopes Demo: http://hexus.github.io/phaser-arcade-slopes/ It's still early days for this project, as I've only just released v0.1.0-alpha today, but I look forward to continuing fleshing it out. Why did I make this? I've been intending to make a 2D platformer with Phaser for ages, and I knew I wanted it to have sloped tiles to allow for a liberating way to traverse the Y axis, but I couldn't find anything that worked the way I want it to. I experimented with Ninja Physics, but it's deprecated and its limitations left me wanting. I tried P2, but it was too much in terms of physics for me, and I didn't want to tame a beast like that. I started searching these forums to see if anyone had managed to get sloped tiles working in Phaser, with some success, but not completely. The solutions wouldn't allow for completely free tile placement, and they just stuck physics bodies to the slopes and left it at that. So, with a somewhat limited understanding of the maths I'd need to learn to achieve what I wanted, I started reading tutorials about the Separating Axis Theorem (SAT), particularly the ones from Metanet and one I found magically through a Google search. After experimenting with SAT.js in Phaser, I decided that I could totally pull off my own plugin to solve this the way I wanted it to be. With lots of learning, but with a clear vision of how I wanted the plugin to work, this is what I've managed! I have lots more features planned, as you can see in the roadmap, but for now I'm just glad I've built something that can be plugged straight into any Arcade Physics project that just works. Screenshots

I'm going to answer that as I'm the one who forced @Deltakosh to switch to TypeScript. First, TypeScript is "just" a superset of JavaScript, adding types and supporting future features of ECMAScript by transpiling down to ES5 or ES6. This means that we don't break anything with regular users that will just use the compiled JS version in ES5 or ES6 and will never see it comes from TypeScript. Thanks to the switch we've made 3 years ago, we've managed to find bugs that were just under our eyes and difficult to find in plain JavaScript and we've also managed to boost our productivity on the engine, which is good for us and our community/customers. @Deltakosh has done a great article on that: https://www.eternalcoding.com/?p=103 On my side, 3 years ago, I was also concerned on the fact we were spending a lot of time answering basic questions of our users, trying to understand if there was a bug in their code or in our code. All this time was our spare time and wasn't used to improve the engine. I've then started to discuss with @Deltakosh on ways to solve that and again TypeScript was a good candidate. Why? Again, thanks to the types exposed, I’ve discovered great possibilities such as the TypeScript playground: http://www.typescriptlang.org/play/index.html I’ve then told to @Deltakosh we could do something similar, having autocompletion in the browser, building some basic sample codes to help our users, learning by live discovering the API. Deltakosh ended up building a much better playground with great features such as saving your code to share it with your colleagues or on the forum for review, downloading the ZIP, etc. Something which would have been much more difficult without TypeScript. TypeScript also offers us to use future features of ES now to add clarity to our code: module, class, arrow functions, generators, async/await, etc. Those are not TypeScript specifics. You will have to learn them to be able to write ES2016/ES2017 code anyway. Regarding the fact it comes from Microsoft, this is really not what influenced us (everybody knows deltakosh and I are MSFTees). Deltakosh was even against at the beginning but quickly changed his mind when he discovered the potential behind without affecting our users. Even if it comes from Microsoft, the web community enjoys TypeScript and other big companies such as Google is using it for Angular 2. TypeScript also offers another great benefit for us: we managed to attract talented developers such as @Nockawa writing the awesome Canvas2D extension who was mainly a C# developer. C#, C++ and Java developers tends to have difficulties understanding some paradigms of JS at the beginning such as the prototype oriented programming, the classical issue with capturing this for closure, writing module/class like with self-executed anonymous functions, etc. TypeScript is hiding that by still generating perfectly written JavaScript under the hood. I tend to find TypeScript also better to work as a team. At last, as said before, we managed to attract some customers using Babylon.js because it is written in TypeScript and you can them fully develop with the .ts version of our engine instead of the .js to have a full typed experience during your development process. Another great benefit: I can compile an ES6 (ES2015) or ES7 (ES2016) version today without changing a single line of code of Babylon. If we would be in plain JavaScript, we would have been forced to rewrite everything to switch from ES3/ES5 to ES6 for instance. The only caveat is that it’s a bit more complex for contributors to the code to do PR to fix bugs or add features. But to be honest, as said, it’s just the JavaScript we will all use in 1 to 2 years. Except this small part, TS doesn’t affect our users because it’s transparent for them, we’re improving the quality of the code, we’re going faster, we’re attracting more diverse talented developers, we’re ready for the future. I really don’t see where the problem is then.

Hi guys, This weekend I joined ludum dare again and I managed to build a game using babylonJS. The theme that was chosen was "one room". This is the game I created: http://jppresents.net/static/ld37/ You play with the mouse, holding down the mouse button fires the laser. Not much more to say.. obviously you don't want them to reach the bed. Pressing "s" toggles sound on and off. And here is a short timelapse of the creation within about 13 hours. (This includes creating everything from code to assets, except for the custom loading screen.) Thank you guys for the cool engine and the awesome playground examples. Special thanks to everyone from http://www.html5gamedevs.com/topic/21992-creating-a-scanning-laser-effect/

A small kind of Christmas themed flappy bird style game. Click or press space bar repeatedly to fly and gather as many stars as you can in one minute. Don't touch the ground, that resets the multiplier. http://www.yavsadventskalender.de/fly Features I played around with for this: - fixed aspect ratio - shadow generator for bird & stars - wrapping around an area - 2dCanvas for score & time display - custom loading screen - also more tinkering with blender animations

Hi! I’ve spent of lot of my free time recently to work on an upgraded version of babylonjs.com to be responsive across devices: http://www.babylonjs.com The new site uses Media Queries of course, Flexbox, SVG and much more fun: CSS Filters! Hovering the mouse on our elements will zoom it a little using CSS transforms & transitions and will apply a blur & sepia filter on the other elements of the flexbox. Using the scrolling links will also use a slight gray filter during the scrolling. The website has been tested on IE11/Edge/Chrome/Firefox & iPhone/iPad/Android & Windows Phone devices but if you find anything wrong on your device, please tell me. The website is now also much more faster to load (from 6s to 600ms!). This is because we've splitted the demos into specific page. In the past, we're using a SPA like approach. It was complex for our users to find the right file to review. Now, by simply view the source of a specific demo like this one: http://babylonjs.com/Demos/PointLightShadowMap/, you should be able to understand how it works. I've put also all images on our CDN. That's why the new page now loads very fast. In conclusion, this website is using almost all modern features supported by modern browsers: WebGL, Web Audio, Gamepad, Pointer Events, IndexedDB, Media Queries, SVG, Flexbox, Filters, Transform & transitions. Don’t know a lot of sites using that much features. ;-) Cheers, David

Hey guys, I’m sure you already know it, but the new documentation is now officially deployed on doc.babylonjs.com! This version is a total rework of the version you used to know, so let me present it a little bit. Our main concern was (and still is) to create a documentation the community (YOU!) can update and modify at will. This documentation makes no exceptions, with a big new change: it is now based entirely on Github (https://github.com/BabylonJS/Documentation) (and automatically deployed on Azure). This means you can : fork the repo and create your own documentation create pull request to fix bugs create pull request to contribute Clone the repo and have a local version of this documentation Everything you can think of Features: All tutorials, exporters and extensions are now sorted. We tried to keep the same hierarchy the old documentation had, but FEEL FREE to update it, or create a new one. (Don’t forget it’s your documentation!) All classes can now be tagged (example : http://doc.babylonjs.com/classes/2.1/AbstractMesh has two tags: Node and Mesh). All classes are sorted by tags, and alphabetically (http://doc.babylonjs.com/classes/2.1).o This allows news users to easily find common classes (Camera, Mesh, …) URL are now user-friendly. You can write http://doc.babylonjs.com/classes/<className>, and it will redirect to the last version of this class (if it exists of course). Example: http://doc.babylonjs.com/classes/Axis Links forwarding to the old documentation (example: http://doc.babylonjs.com/page.php?p=22551) are now forwarded to the same page on the new doc. This website is responsive, and the mobile version is awesome J MIT license, do what you want!How to contribute ? This website is an big empty shell created to DISPLAY markdown files. Each page is represented by a markdown file. To contribute, just clone the repo, update a markdown file (or create a new one if you want to add things), and do a pull request. It’s that easy ! What’s next ? My team and I and still working on this baby, so you can expect some QoL improvements soon. Stay tuned!

A native isometric tile support and some native ui tools like menus, combo boxes, (selecatable) lists, check boxes, radios, inputs etc would be complete all my wishes on this beautiful frame work.

Update: Friday 11th July We found a couple more issues in Pixi 1.6 - one that stopped RenderTextures working at all (which in turn broke some Phaser features) and the IE9 Float32 issue. These were fixed today and rolled into Phaser. I also reverted to the previous implementation of the Image object, which fixed a strange bug with Buttons not changing frames properly. You'll find the latest build files in the dev branch on github, it will be a 2.0.7 release next week after a few more issues have been looked at. https://github.com/photonstorm/phaser We're very pleased to bring you the latest version of Phaser. We were hanging back waiting for the 1.6 release of Pixi (hit the link for lots of nice demos!) and sure enough it landed today, so we're pleased to incorporate that into this release. Pixi 1.6 itself brings in a number of powerful new features, not least of which are the awesome updates to the Graphics class - now allowing for significantly more complex shapes and masks and a host of new methods such as drawPath, arcTo and quadratic curves. There are also masses of updates across Phaser as well. The Change Log will give you the full details, but there are substantial new updates, features and bug fixes across most of the library. Also a big shout out to the guys at Ludei for helping get to the bottom of some strange CocoonJS issues and submit their code into Phaser. Just as we were preparing for release the 0.6 version of p2.js landed as well. As much as we'd have loved to include it this time we just didn't want to hold back any longer. So we've updated our roadmap and will push out 2.1 very soon, which will focus specifically on integration of the new version of p2.js. We're moving to 2.1 as it has a number of API breaking changes inside. You may have noticed that we also now have a Gittip account set-up. Everything we raise from this will go towards helping Phaser development, one way or another. To those of who you have already contributed, thank you! We're also working extremely hard on the new web site. We're really happy with the new features we've been adding recently and are pushing to get it done as soon as possible. There's also a brand new documentation generator nearly done - see our Roadmap for more details. Edit: There's also now a blog post to go with this release with more details + a couple of new games.

Hi guys, We just released today our new version of Wanaplan : www.wanaplan.com This is a 3D home planner that was originally built with Three.js, but we decided a while ago to use Babylon instead, and it works fine now, even better We tweaked the engine a little bit to be case-specific, so the renderings are way faster when the number of objects grows (still CPU limited though). Check it out ! (also available on the french website www.kozikaza.com) If you see some features you're interested in, and you'd like to implement them in your own project or in babylon.js itself, just give me a heads up. Cheers, Feldspar