Kiril Mitov blog

Tagged: babylonjs Toggle Comment Threads | Keyboard Shortcuts

• 

  kmitov 5:25 pm on January 18, 2021 Permalink | Log in to leave a Comment
  Tags: babylonjs, ci ( 2 ), devops ( 2 ), jenkins ( 2 ), rails ( 40 ), Software Development ( 18 ), specs ( 11 ), teaspoon ( 4 )   

  The benefits of running specs against nightly releases of dependencies. 

  Spend some time and resources to set up your Continuous Integration infrastructure to run your spec suites against nightly releases of your dependencies. The benefits are larger than the costs.

  Context

  To further explain the point I will use an example from today.

  We run our specs daily against the latest nightly release of BABYLON.js. On Friday one spec failed. I reported in the forum (not even a github issue). A few hours later there was a fix and PR merged with the main branch of BABYLON.js. We would have the new nightly in a day or two.

  Our specs pass with version 4.2.0 of BABYLON.js, but they fail with BABYLON 5.0.0-alpha.6. A few of the hundred of extensions running in the Instructions Steps (IS) Framework are using BABYLON.js. The IS framework is powering the 3D building instructions at FLLCasts and BuildIn3D.

  BABYLON.js provides two releases of their library.

  1. Stable – available on https://cdn.babylonjs.com/babylon.js
  2. Preview – available on https://preview.babylonjs.com/babylon.js

  How do we run the specs against the preview (nightly) release of BABYLON.js?

  We’ve configured Jenkins to do two builds. One is against the official release of BABYLON.js that we are using on production. The second run is against the preview release.

  When there is a problem in our code both builds will fail. When there is an issue with the new version of BABYLON.js only the second build fails.

  What is the benefit?

  I think of the benefit as “being in the context’. Babylon team is working on a new feature or they are changing something. If we find an issue with this change six months later it would be much more difficult for them to switch context and resolve it. Probably there are already other changes. But when we as developers are in the “context”, when we are working on something and have made a change today and there is an issue with this change it is much easier to see where the problem is. You are in the same context.

  The other large benefit is that when 5.0.0 is released we will know from day one that we support it and we can switch production to the new version. There are exactly 0 days for us to “migrate” to the new version.

  How much does it cost us?

  Basically – zero. The specs are run in under 60 seconds and the build is configured with a param.

  

  What if there are API changes?

  Yes, we can’t just run the same code if there are API changes in BABYLON.js. That’s why we have the branch. If there are API changes we can change our code in the babylon-5.0 branch and keep it up to date with changes in dev, which is most of the time resolved with a simple merge.

  But BABYLON.js is a stable library. There are not many API changes that are happening. At least not in the API that we are using.

  For fun

  As you are here, here is one instruction

  Large Spaceball from Geosmart Spaceball set in 3D
   

  Reply Cancel reply

  You must be logged in to post a comment.

• 

  kmitov 9:56 pm on November 28, 2020 Permalink | Log in to leave a Comment
  Tags: 3d ( 3 ), babylonjs, javascript ( 18 )   

  How to do headless specs with the BABYLON JS NullEngine 

  [Everyday code]

  In buildin3d.com we are using BABYLON JS. To develop a headless specs for BABYLON JS that could run in a Node.js environment or without the need of an actual canvas we can use BABYLON.NullEngine. A spec could then look like

   const engine = new BABYLON.NullEngine();
   this.scene = new BABYLON.Scene(engine);

  Here is what I found out.

  Headless specs

  We run a lot of specs for our BABYLON JS logic. All of this specs are against preview.babylonjs.com. The preview version of babylon give us access to the latest most recent changes of babylon that are mode available to the public. These are still not release changes, but are the work of progress of the framework. They are quite stable so I guess at least the internal suite of BABYLON has passed. Preview is much like a nightly build. In BABYLON JS case it is also quite stable.

  2 days ago much of our specs failed. I reported at https://forum.babylonjs.com/t/failure-error-typeerror-cannot-read-property-trackubosinframe-of-undefined/16087. There were a lot of errors for :

  Cannot read property 'trackUbosInFrame' of undefined.

  Turns out that many of our specs were using BABYLON.Engine to construct the scene like

  const engine = new BABYLON.Engine();
  this.scene = new BABYLON.Scene(engine);

  The BABYLON.Engine class is only intended for the cases where we have a canvas. What we should have been doing for headless specs without a canvas is to use BABYLON.NullEngine. Hope you find it helpful.

  Write more specs.

   
• 

  kmitov 11:05 am on November 16, 2020 Permalink | Log in to leave a Comment
  Tags: 3d ( 3 ), animations, babylonjs, javascript ( 18 )   

  We got featured in the BABYLON JS 4.2 release video 

  About two year ago when we started working on delivering 3D instructions and playing 3D animations and visualizing 3D models in the browser. Little did we know than that with version 4.2 babylon js will feature us in their release video. Thank you BABYLON theme.

  I wrote an article on BuildIn3D.com – https://buildin3d.com/blog/buildin3d-featured-in-the-babylon-js-4-2-release-video/

  Here is the release video for all to enjoy.