Does Babylon.js or Three.js perform better with more meshes?

As I never played with 3JS, this topic made me want to try a bit, and I create a FIGHT page :crazy_face: 'was fun to do (but in a very non-neutral point-of-view, I thought BJS is more easy to get into).

Here a temporary online link: 3JS vs BJS
but sources are available on my Github: graphic-assets/BabylonJS/3js-vs-bjs at master · Vinc3r/graphic-assets · GitHub

  • dragon.glb - 20 Mo
  • tchouri.glb - 128 Mo

In your browser console you will see timing using performance.now(). Please note that I’m not sure if my process is rigorous enough, PR is accepted :wink:
By testing this page, you’ll may thinking that 3JS is faster than BJS on the 128Mo file… Actually, and I don’t know how to fix that, it’s probably just because your browser have to redownload the same file for both engines, even by using a local webserver… (cache looks like disabled for huge files)

So… I can’t do any conclusion :smile:

2 Likes

@Vinc3r you’d have to profile the parsing to avoid taking download times into consideration.

I’m starting to release my app (I’ll do a proper post to the demo forum later once it’s working). But just for comparison if anyone cares, the same thing in threejs and in Babylon. The Babylon code is way ahead, I dropped the 3JS version a while ago.

2 Likes

Hey @GabrielMarcondes, does your model have a lot of children meshes just like the one I posted at Animation performance drop by translation/rotation?

1 Like

It is not necessary, it’s only it was easier to hide them for the demo and only deal with the instances to properly clone and align them.

To quote @aFalcon :

Look deeper into your model, the export, debug the import, and provide the LOG if you can.

You probably have zero-size faces or high number of faces that can be reduced with retrotopology.

Yes, retopology is one way to get the vertex count down, but if you are using textures and texture mapping, the nature of the UVmap is also important. See the images below:

1st Image - a cube with no texture map - just a simple color. 8 verts for 12 faces
2nd Image - a Blender simple (and in my opinion, sloppy) UV map. 31 verts for 12 faces
3rd Image - an improved Blender UV Map. 22 verts for 12 faces
4th Image - best UV Map in my quick effort to unwrap. 17 verts for 12 faces

And if you look at the playground demo that has a simple crate texture mapped onto a box - you get 24 verts for the 12 faces.

The vertices can pile up more quickly than you think if you don’t think about good UV mapping.

As for BJS and 3JS - I tried both out in 2014. For a crap scripter, BJS was the only choice - but I do build my stuff with BJS in mind. I tend not to get 3d geometry from other places or stuff originally built for something else.

cheers, gryff :slight_smile:

no_uv01

sloppy_uv01

better_uv01

best_uv01

2 Likes

@gryff GOLD!!!

123456789

24 vertex count, with texture UV, on a box - that makes SENSE!

Can it go lower, with BAD UV MAPPING?

Found a way. :grin:

But didn’t know about INSPECTOR, OR how to use it to count VERTICES like that.

Cool

Thanx G!


Ah…

I just want to say LIKE this THREAD so MUCH!

LIKE - what @jerome says about

  • every scene needs to be optimized in different ways. AND,

@Deltakosh - the perf ops of runtime animations - in RELATED thread - is especially helpful.

For review, and OTHER PERF OPS TIPS, more comment on that thread.

:eagle:

3000 meshes, is that what you are asking?


I don’t see the same botleneck, what do you think?

Which version are you on? I’m on the latest beta (4.1-beta15)

Wait! I see edgeRenderer all over the place! You never mentioned that earlier. EdgesRendering was not in the equation. with 3000 meshes, the edges renderer will be REALLY expensive. This is a bad idea.

3 Likes

I don’t really know how to read your profiler logs.
If the BJS scene is slower than 3JS on evaluateActiveMeshes(), this is the standard behavior depending on both framework assumptions :

  • by default, BJS computes an accurate frustum intersection check (bounding sphere, then bounding box)
  • by default, 3JS computes a simpler one (bounding sphere only)
    The accurate test requires, in my memory, 24 more steps than the simple one.
    The accurate test avoids false positives, it is to say, to pass invisible meshes to the GPU. That can be really efficient with high poly meshes.
    That’s simply different default choices.

You can set BJS so it behaves like 3JS by setting the mesh cullingStrategy property value : AbstractMesh - Babylon.js Documentation
by choosing
AbstractMesh.CULLINGSTRATEGY_BOUNDINGSPHERE_ONLY
or even faster if you know that your meshes are very probably in the frustum
AbstractMesh.CULLINGSTRATEGY_OPTIMISTIC_INCLUSION_THEN_BSPHERE_ONLY

doc here : AbstractMesh - Babylon.js Documentation

3 Likes

I’m using v4.0.3.

I’ve added edges render after, it is really expensive, I’m thinking in other solution to show the edges better, testing some lights.

3000 meshes is a very small model
One of my models has about 100.000 meshes.

I’ve added bounding sphere only, for each mesh:

mesh.cullingStrategy = BABYLON.AbstractMesh.CULLINGSTRATEGY_BOUNDINGSPHERE_ONLY;
mesh.freezeWorldMatrix();
mesh.doNotSyncBoundingInfo = true;

1 Like

Yeah but what is the point of your profile then?

Also if you can, please switch to 4.1 as we improve perf on it

2 Likes

In realtime 3D, furthermore using webGL, I’m not sure about that :smiley:

1 Like

I will turn on boundingsphere only by default in 4.1 btw :slight_smile:

3 Likes

By the way I just notice that this frustum tips is also on this page: Optimize your scene - Babylon.js Documentation (which was not mentionned yet in this topic if I’m not wrong).

2 Likes

The think is that we started by the classical 3 vs bjs battle and we end up with 100000 meshes with edgesRenderer

2 Likes

It could have been worse if each mesh was using its own non-power-of-two 8k texture :crazy_face:

1 Like

I’ve updated my packages to the lattest beta. Thanks for the tip!

In the time it was the solution I found to better show the edges in the model, right now I’ve discarded the solution… Perhaps doing it with the active meshes not all meshes would improve the performance.

That’s relative.

:rofl:

By the way, here is the link for the treejs based viewer, that’s what I’m aiming in performance:

Are you sure they are using the same models? They must use thousands of tricks to get perf (like us of course)

They do not render everything while moving:


and then when you stop:

This is highly custom code that would not work outside a viewer and not 3js specific here.

Could we see your scene with 100000 meshes in default 3js working fast and then in Babylon with our known differences enabled (freeze, culling…) without edges renderer to compare objectively ?

1 Like