Vue integration like A-Frame

[BrainBacon]

If you haven't yet seen A-Frame yet, you should check it out. The gist is that you use HTML tags to define your scene. I was working on porting A-Frame to Vue because the devtools are amazing and the components are expressive and makes your app really reactive. I prefer Vue over React since it's simpler and I don't have to work in JSX. While working on integration with A-Frame I started to notice that the overlap between A-Frame's entities and Vue's components became rather cumbersome and Three.js's API and documentation made the situation worse. I noticed the Babylon.js project shortly after and discovered how awesome it is. I then decided it would be better to make my own ECS using Babylon.js with Vue components.

As of right now I have Scene, Entity, Mesh, Light, and Animation components created. Here's a sneak peek:

And the code for the scene written in Pug:

I'll keep this thread updated as I continue progressing on the project. Let me know if you have any ideas or feedback.

You can watch me code it on my Twitch stream this Monday from 2-10pm CST.

I just started this project a couple days ago, so it doesn't have documentation yet, but you can see the code on Github or grab it off of NPM as vue-babylonjs

[GameMonetize]

Really cool

[BrainBacon]

Here's a little update:

I've been working on materials and I started with supporting custom shaders. You will be able to define your Shader code in a multitude of ways. Here is one of the most interesting ones, inline code in a Vertex or Fragment component!

 

You can see more examples including loading from a file or inside your component scripts in the example on the Github repository

[BrainBacon]

I've been hard at work on integrating features for the plugin, and I launched the start of the example website.

You can see the site here: https://beg-in.github.io/vue-babylonjs/

Additionally I'm planning on bringing this project to HackIllinois this year which has a strong commitment to contributing to open source projects, so the documentation and testing should get a quick boost!

Anyway, on to the update!

While developing the Camera components I noticed that the plugin was going to become too tightly coupled to the current BabylonJS API, so I came up with a way to accomidate future changes and feature additions. I present the property system:

Rather than specifying every possible property in this plugin's components, this system will allow you to modify your BabylonJS objects indirectly. Several helpers are available to make defining properties easy in your template, and there are multiple ways to set them. Any changes you make in Vue will be reactive and will update the object in real-time! Unfortunately the "properties" prop for Entity components uses a deep watcher, so I will be keeping an eye on how this affects performance.

My  plan is to implement a method in the near future where you can access the underlying BabylonJS object directly as a v-model.

Right now that is already possible from a child component extending Entity as a mixin with one of the following:

• A custom lifecycle hook defined specifically by this plugin: 

  onParent({ parent }) { ... }

• An injected promise: 

  let parent = await this.EntityReady;

•  A private property: 

  this._$_parent

  note: I am currently unsure If I should maintain this as a public-facing API.

As always, you can see the example code in the Gitub repository.

P.S.

@Deltakosh

I'm pretty much done with the Camera component, and I was wondering if it makes sense to have a default camera for the scene? While I was messing around in the BabylonJS Playground I noticed the scene will not function without a camera. Do you think it would confuse new developers more or less without them explicitly specifying a Camera? Right now I am not setting up a default camera if you do not specify one, but It could be do-able. A-Frame does set one up for you automatically. I see pros and cons either way, especially if someone wants to set up some sort of rig or modify camera settings. Let me know your thoughts.

[Guest]

You can still call scene.createDefaultCamera() if before rendering you see that there is no camera

[BrainBacon]

Hey all, sorry for the delay in an update. I've recently moved to a new city and haven't had much of a chance to get my news up here. I have, however, been working a lot on the library in the meantime.

I've finished up the implementation for the initial version of the library. The final pieces Material, Texture, and Physics are now available for use. Model binding syntax is now available for most components of the library for ease of access to the underlying objects from BabylonJS! Use the "v-model" property on components and bind it to a data property and use a watcher to listen for when the object is available in your scripts.

I was initially using PBRMaterial by default for the Material component, but I found that trying to stabilize the PBRMaterial API to be easy for new developers with sensible defaults was more challenging than I initially thought. I eventually decided to revert that back to StandardMaterial. I did, however, combine many of the properties of PBRMaterial and StandardMaterial in the Material component, so the switch between the two (using the type property) should be easy enough for developers with experience with PBRMaterial. If the community pushes for PBRMaterial to be default in the future then I will heavily consider the change.

Physics implementation is in place and leverages the new model binding mechanism to allow for access to the underlying impostor object inside your component scripts. The Physics Engine on the Scene is automatically initialized when any Physics component is activated! The Physics component uses the same parenting system as Entity, so adding physics to your scene is as easy as any other part of this library. Joints, however, were more difficult to reason about inside of a DOM-like tree structure since they require a reference to multiple Entities. In the end I decided to skip Joint implementation until the community has a chance to try the library and provide feedback on plans on how to structure that sort of interaction. For now joints can be created using the impostor objects.

This marks the point at which the library graduates from alpha to beta status which means the API structure is pretty much finalized and will only change if there are considerable issues. This week I will be adding much needed documentation and sprucing up the examples and documentation website.

Future updates will happen on the Github mailing list issue. Subscribe to be notified as soon as the library comes out of Beta!

[Guest]

Hey

I wanted to offer you the opportunity to be hosted on our extension repo and to have a page in our doc.babylonjs.com

 

Would you be interested?

[BrainBacon]

@Deltakosh Absolutely. What do you need me to do?

[Guest]

First create your folder here (I'll make you admin as soon as you will create your PR):

https://github.com/BabylonJS/Extensions

 

For documentation, we have a specific section for extensions:http://doc.babylonjs.com/extensions/

 

Thanks a lot!

[Nodragem]

Yay! An Entity/Component/System extension for BabylonJS is very great news!

I mean, for now, there is no organisational paradigm in BabylonJS, except maybe the Unity Toolkit and its Scene Manager. Hence it can be hard to organise our projects.

 

I have some questions about your extension, which may help people to know if it is relevant to their project:

- What is the performance cost on mobile? (I am working on mobile web)

- What are the babylonjs' functionalities that aren't supported?

 

Can't wait to see your extension in the official website