Background In WebGL projects, we often require UI elements such as confirmation dialogs, prompts, loading bars, etc. These can be implemented in two ways:
Overlaying DOM elements on canvas and Pure canvas implementation
Points to Address
With the advent of VR, clients may want to use webXR technology for interactive projects. However, it’s impossible to use DOM elements in immersive webXR mode.
In the first mode, it’s feasible for mobile (M端), but not for VR immersion, resulting in double development effort (cost reduction and efficiency improvement needed).
WebGLGUI code development is outdated, resembling the era of JQuery. Using component-based development significantly enhances efficiency and reusability. Below is a code comparison:
// Native GUI development
var advancedTexture = BABYLON.GUI.AdvancedDynamicTexture.CreateFullscreenUI("UI");
var panel = new BABYLON.GUI.StackPanel();
advancedTexture.addControl(panel);
var rect1 = new BABYLON.GUI.Rectangle();
rect1.width = 0.2;
rect1.height = "40px";
rect1.cornerRadius = 20;
rect1.color = "Orange";
rect1.thickness = 4;
rect1.background = "green";
panel.addControl(rect1);
var rect2 = new BABYLON.GUI.Rectangle();
rect2.width = 0.1;
rect2.height = "40px";
rect2.cornerRadius = 20;
rect2.color = "Orange";
rect2.thickness = 4;
rect2.background = "green";
panel.addControl(rect2);
Looks like a great start! I have been programming in vue for around 4 years now. I did make an attempt similar to what you are doing - I agree with your point:
“Limited number of components currently available”
I addressed that on one project using code-gen with ts-morph. There is basically 1 file that generates pretty decent support for Babylon.js GUI and core. There is a bunch of glue and the benefit of a reconciler to do a lot of the heavy lifting: …/generate-code.ts
There still a lot of wrapper code and extra things going on, but you may find that useful.
Thank you for sharing your experience and insights! Since I have less experience with ts-morph, I will definitely take a look at the generate-code.ts file you mentioned. It seems like it could offer valuable insights into streamlining the component creation process. Additionally, that abandoned project for creating declarative Babylon.js in Vue looks intriguing; I will explore it further to see if there are any nuggets of wisdom to glean from it. Thanks again for sharing your projects with me. Currently, my idea is to gradually establish a component library for convenient and quick use in projects.
Just stumbled over this topic. Found it interesting/intriguing. Since I have been advocating for the BJS GUI since the beginning, all efforts to improve/enhance it already has my full support . To be honest, I’m not too much into VR so I cannot tell (or help) here.
In fact, I was just wondering why someone like @RaananW from the Team hasn’t kicked in yet, to either discard or encourage your research and efforts…
Yes, I guess so. But I have seen a number of posts in this forum from people considering using the BJS GUI in a vue project and at some point, quit (likely because it was too ‘cumbersome’ for them). If we could get these people back, I suppose that would be a good thing, wouldn’t it?
I think many people do look for a different way of designing their UI. We try not to hook our users to a specific framework (in this case vue, if I understand correctly), but having this as an extension for users is an amazing addition. Especially in XR scenarios! Are you planning on documenting different scenarios? This could be a great addition to our documentation page in the community extensions section!
I apologize for my comment about “WebGLGUI code development being outdated, resembling the era of jQuery.” I regret any misunderstanding this might have caused.
I completely agree that many people are indeed looking for different ways to design their UIs. We certainly do not intend to lock our users into a specific framework (in this case, Vue, if I understand correctly). However, offering this as an extension is a fantastic addition, especially in XR scenarios!
Regarding documenting different scenarios, we would be very happy to work on that. It would be a great addition to the community extensions section of our documentation page!