Performance of BJS and VueJS

I am working on a gcode viewer using BJS 4.0 to display a model of what will be printed on my 3D printer. On a non-vuejs version of the page I am able to render about 400k cubes with no performance problems or lockups. However, when attempting to use the same code on a vuejs version of the webpage it throws out of memory exceptions and when it does work for smaller models I find that the performance is very slow.

I was wondering if anyone had any idea what could be going on. The only idea I have is vue is trying to mandhandle and observe babylon. Performance nosedives or outright fails on the sps.addShape or sps.buildMesh calls. From debug it seems when it is building arrays is where the problems may be happening.

1 Like

I guess @timetocode has been working with vue and babylon for one of its game. What I have seen causing this in all the ui framework is some wrong rebuild of the component wrapping babylon. Babylon and its canvas would be better in a component that would not get recreated at all or which should dispose the different scenes and engine when a new instantiation happen.

I tried to eliminate vue from the picture by manually adding a canvas element and zindexing it above the printer control page. My hope was that vue would not interfere with the canvas and babylon. I feel that I am missing something but not sure what. Is there any way to guarantee that vue will not interact with babylon?

Unfortunately i am not so much using Vue but I bet some other ppl from the community will be able to help soon like @BrainBacon who did an amazing vue-babylon framework

I’ve had a canvas tag both within a vue component and outside (outside meaning in the section of the html not touched by vue). Both have worked. My interactions between vuex+vuejs+babylon are pretty minimal in the end – I basically observe incoming network data and pass pieces of data that my UI needs to the vuex store. For example when hitpoints or something changes, I commit that to the store and the ui re-renders the hitpoint bar. I’m not sure what would happen if more complicated objects (or a self-referencing set of data…?) were added to the store and possibly mutated at 60+ fps.

In my case they both work just fine but even when it’s outside of the VueJS app it loses significant performance. I don’t feel like fighting with Vue at this point so I am going to just have it open a new browser window that will load/render the gcode I want to visualize. I appreciate the replies.

I encountered the same issue. I noticed considerable performance degradation when using VueJs with BJS. I dug in and pinpointed the cause. Vue automatically injects reactive getters and setters for all Vue variables. Injecting reactive getters and setters on large and fluid objects, e.g. Babylon objects, create significant bloat and causes performance hit on FPS.

If you make any BJS mesh into a Vue variable and check the chrome dev tools with vue extension, you’ll see Vue injects dozens/hundreds of getters/setters. This means in every update cycle, Vue has ALOT more to check for dirty flags than necessarily needed.

In practice, you shouldn’t really need BJS variables to be reactive. Vue should just be used for rendering content on the DOM.

For the above reasons, I created a fork out of vue called vue-for-babylonians. Check it out here.

With it, you can tell Vue to not make any objects which are stored in vue or vuex from being reactive. You can also tell Vue to make certain subset of object properties reactive. You’ll find performance improves substantially and you enjoy the convenience of storing and passing BJS objects as you would normally in vue.

2 Likes

Posted this solution in another thread as well. Hopefully this helps anyone searching that happens upon this thread when trying to debug perf issues when using Babylon & Vue.


You can avoid Vue injecting reactive properties by setting _isVue = true on your scene class/object (ie. Whatever you are using to wrap babylon).

This was a pretty easy solution for me.

2 Likes