Three.js or Babylon.js for room design

[Art Vandelay 1]

Hi everyone,

I would like to create a simple interior design tool. Basically a drag and drop tool, where you can drag and drop furniture, lighting, wallpapers, pictures, windows, floors, anything really. For this type of project, should I use Babylon.js or Three.JS?

Thanks!

[adam 754]

BabylonJS

(I'm clearly biased, though)

[Temechon 675]

Babylon.js too, everything you need is already there (drag and drop, file import...). I'm also clearly biased

[MarianG 151]

Hi. I have been using ThreeJs for a very long time, but I discovered the BabylonJs and I fall in love with it. And yes, I'm too for BabylonJS :))

[Capitaine Herlock 2]

Hi, i am new to babylonjs i find that it's better then threejs in term of the discussions here in the forum

[Fyrestar 1]

I would recommend THREE, i'm using it for years now and also tried Babylon.

[jerome 1,732]

BJS ... I don't even know what this "Three" is

[Fyrestar 1]

1 minute ago, jerome said:

BJS ... I don't even know what this "Three" is

https://threejs.org

[Dad72 915]

Same thing for me, BabylonJS. It is much more modern and easier to use for trying both.

Eyes close: BabylonJS

[adam 754]

This seems to be appropriate for this thread:

 

[jerome 1,732]

@Fyrestar it was just a joke 

that's just... well ... you come the BJS dedicated forum, the unofficial-official one (say, the main one, if not the lone one) and you ask to BJS users or fans if they prefer BJS rather than 3JS.

A bit like if you were entering a München pub and you ask the local drinkers if they prefer the München beer to the Berlin one 

[Fyrestar 1]

1 minute ago, jerome said:

@Fyrestar it was just a joke 

that's just... well ... you come the BJS dedicated forum, the unofficial-official one (say, the main one, if not the lone one) and you ask to BJS users or fans if they prefer BJS rather than 3JS.

A bit like if you were entering a München pub and you ask the local drinkers if they prefer the München beer to the Berlin one 

Of course, it's pointless to ask such a question here, it should have been asked at least in "Cording and Game Design", but anyway @Art Vandelay you should probably try and play with the examples of both to see what you prefer. THREE has a clearly separated render engine core, from all the libs and modules you can plug in for things like drag & drop. Basically everything you find in the feature list of Bablyon is also offered by THREE, but you should try and play around yourself, every fanboy will only suggest you their preference. I tested both, but i also only use THREE as render engine for a custom game engine.

I would prefer the beer from München anyway, since i'm from Ulm 

[Art Vandelay 1]

Thanks everyone for the replies! Yes I realize it might be a bit naive to post that question here. I guess I just felt babylon users were more trustworthy

 

Anyways thanks again, will play a bit with both.

[Dad72 915]

I tried TrreJS and when I discovered Babylon, I realized more than I would have done with TreeJS. So I suggest you in all honesty and objectivity BabylonJS. Many people here come from TrreJS and we prefer to use BabylonJS because of its simplicity and a very reactive super community.

[jerome 1,732]

That's also my own history. I started with ThreeJS, then for some reasons (one being the fast and great support on this forum, another being the docs, tutos and videos made by the BJS author himself), I ported my project to BJS.

And I'm still here with no regret at all since early 2014. 

I even became a core contributor as much as I felt the framework smart, productive and the people around here interesting, passionate and lovely (this was not my initial intention but things slowly happened this way and I went stuck to this project  )

[jerome 1,732]

Moreover there are serious and objective reasons to prefer BabylonJS over ThreeJS :

- the name "BabylonJS" is longer than the name "ThreeJS"

- Deltakosh's hairdressing is more fashionable than Mr Dood's one

- BabylonJS has an animated logo

 

[RaananW 982]

Three.JS for sure. 

[max123 53]

As many here, I moved from Three to Babylon.

My reasons:

- Three feels neglected at the moment. It was hard to get things fixed. I had an issue with Blender exporter, it took Three community 6-7 months to resolve the bug. When it comes to Babylon, things get fixed PRONTO. I mean often within hours!
- This neglect translates to maintainers of various Three importers/exporters, e.g. Collada seemed to have been broken for ages.
- It's easier to get help for Babylon. This community is fantastic!
- A lot of building blocks are already present in Babylon: drag/drop, scene optimisers, render loop with delta time, etc..

Pros/Cons of both:

- Three feels more coherent at times. When you get past the learning curve, everything (well, almost) seems to follow a set logic. I can't say the same thing about Babylon (the whole Cameras approach feels clunky).
- Babylon is too "object orientated" for its own good   It's a good thing, generally, but I feel that sometimes levels of abstraction can get too high and long-winded. For example, I got lost at custom shaders bit. Besides, OO is NOT always the best approach where performance is important and the engine is creating/destroying thousands of objects at every tick. 
- I don't like Babylon's presumption that it knows best what to do with CSS. It's quite a big one for me and with every release I have to go to source code and remove all CSS-related stuff: z-index, tab order, etc. as it messes up with styles already present.
 

Overall, I think Babylon is more modern, has more features and is FAR easier to get going than Three. If I had to compare these frameworks to programming languages, I'd say Babylon is C# and Three is an early version of C++  

[Art Vandelay 1]

Thanks for the detailed response Max. And thanks everyone else as well.

[RaananW 982]

Hey @max123,

would be great to get your input inspected and sorted, if needed!

1) Cameras - Would be great to know where you see the problem and see if we can solve this. The cameras' architecture was implemented by different developers with different approaches, and we will be happy to see where it can be improved, as long as we dont break backwards compatibility.

2) OOP is nice, but doesn't always, fit I agree. Where I disagree is that we create and destroy a lot of objects every frame. We are doing our best to never recreate new objects, and I believe so far it is very much a successful approach. We reuse as much as we can, and only use new objects when we really have to. If it is not the case, would be great to know where!

3) CSS? I guess you mean the debug layer and the GUI. Which are somewhat external modules of Babylon. You don't need CSS to paint 3D on a canvas, it is a single HTML element. Having said that - if you see that something wrong is being done, css-wise, we would really appreciate the input.

@Art Vandelay,

We get this question quite a lot here (I think, just like some have pointed here, it is the wrong place to ask this question ) . It all depends on your needs eventually. I believe Babylon provides everything you need to get started and more. and that it is easy to use. But I doubt I will be able to convince a seasoned three-js developer to switch, as they probably already got everything they needed working. 

[adam 754]

2 hours ago, max123 said:

the engine is creating/destroying thousands of objects at every tick. 

Where is this happening?

[max123 53]

Hi @RaananW,

CSS:

Inside freeCamera and arcRotateCamera classes: element.tabIndex = 1;

Inside babylon.scene: canvas.tabIndex = 1;

Inside VirtualJoystick: VirtualJoystick.vjCanvas.style.zIndex = "5";

And yeah, you're right about the debug layer: when the new one came out, I just gave up on it: no matter what, it wouldn't play nice with my app  

Cameras:

I think I covered the subject some time ago, but for me the whole idea of having loads of different camera classes with their own controls feels clunky: I think that having a camera and separate controls would be easier to reason with, e.g. a Camera class would only have properties you normally associate with a camera: fov, min/maxZ, mode (perspective/ortho). Then you would have SEPARATE camera rig classes: Free/FPS, Orbit, Joystic, etc. Again, it's just my opinion

Objects creation/destruction:

While playing with Rays (I know, it's dangerous!), I noticed that when you pickWithRay, it would then return Ray.Transform, which calls

var result = new Ray(new Vector3(0,0,0), new Vector3(0,0,0));

Ray.TransformToRef(ray, matrix, result);

return result;

There were other places where I noticed "new" keyword (I'll have to dig through my older code).

 

[max123 53]

19 minutes ago, adam said:

Where is this happening?

Bad phrasing on my part. I didn't mean that by default the engine itself creates/destroys thousands of objects; it's the use cases where a user has to do loads of ray picking for example.

[adam 754]

In the case, the user should be reusing Rays.

[adam 754]

There should probably be a scene.pickWithRayToRef so that we can use Ray.TransformToRef.