![]() But when I really looked at what I was doing in Unity, it was a lot of file organization and custom scripts attached to assets imported into the engine. And with the option of creating a Progressive Web App, I can see where I could get a lot of flexibility out of any prototype that I made.īut I had been very comfortable working in Unity so I was a little uneasy moving from that environment and C# to writing the entire prototype in Javascript or Typescript to be viewed in a browser. No need to get a specific device into the hands of someone wanting to review the prototype. No creation of individual packages based on the device. Just from the standpoint of a WebGL prototype being up-to-date and usable on any device with a web browser I could see that this would be a faster method of iteration while keeping all testing devices up to date. We would, from time to time find a device that had not been updated and was being tested on an old build which was a waste of time for everyone. There also needed to be the ability to hide some debug UI in the prototype so that we could determine if the device had the latest version of the prototype on it. ![]() It also resulted in a lot of passing around of unique devices since a device needed to have the prototype side-loaded onto it before it could be used for testing. This was a tax that had to be paid with every iteration, and could be very annoying if there were a small bug or typo that needed to be corrected. Better yet, if the prototype can be deployed on the target hardware, we could get a feel for the form factor while testing the prototype.įor Unity, that meant creating and side loading a unique package for a specific device. This was a good way to reduce code churn on the engineers when integrating features since everything had been user-tested already. ![]() It was much faster for us to let the engineers focus on the hard work of making production-ready code where I could work fast and loose just to get an experience for design to test. The best way for me to do that was to create a Unity project of that specific interaction or even mock up the whole experience so we could test the end-to-end user flow. In my work across several teams at Microsoft my main focus was to produce prototypes of user interactions, UI layouts, visual effects, and more. One of my prototypes for describing a point cloud with particles using depth of field ![]() But when you are trying to reach as many users as possible regardless of the device they are using, it can be much more powerful to lean into a WebGL solution. If you are making an experience that is targeted to a specific piece of hardware, being able to leverage a native engine is going to give you a lot of flexibility. There are limitations on WebGL that are not an issue for a native engine, but on the flip side the accessibility of a WebGL experience is much broader than a native app. So what is it like to move from a native engine like Unity to a WebGL engine like Babylon.js? It was not as jarring as I would have initially thought.įirst of all, we need to acknowledge that comparing a native 3D engine to a WebGL engine is not an apples to apples comparison. In the past, however, I have worked full time in the Unity engine on projects for HoloLens, 3D for Everyone, and Real-Time 3D Scanning. From Unity to Babylon.js - How is the journey?įull disclosure: I am a technical artist working for Microsoft on the Babylon.js engine.
0 Comments
Leave a Reply. |