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 
1 Like
I will turn on boundingsphere only by default in 4.1 btw 
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 
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.
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
What do you mean with same models?
In fact there is a specific format used by the viewer (proprietary), and I don’t doubt there are thousand tricks. The only thing that the Forge Viewer is better than Babylon is on this specific performance stuff.
In all other stuff, babylon is lightyears ahead. (That’s why I choose to implement the viewer using babylonjs and throw the 3js based viewer away).
As you said the base is the same, so with some effort I could achieve comparable performance.
Yes, exactly.
That’s not default 3js, as I said before.
But it runs under 3js, and from what I’ve found here, babylon could do the same, or even better. Am I right?
Yes, in the end with the same kind of optim enabled, they would perform the same cause the bottleneck will probably be the number of calls to the underlying GL which might be in the same ballpark.
And to replicate that in Babylon you will need to implement the same trickery with enabling disabling meshes while moving around.
Sure, I thought about freezing the active meshes in the render loop, and unfreeze then each second or 500 miliseconds.
why unfreezing ? Could you not rely on setEnabled to force rendering or not ?
I don`t known, I am a humble padawan, Mr Concilor.
What property are you talking about
mesh.alwaysSelectAsActiveMesh = true ?
Freezing the meshes in the loop would cause them to reevaluate only by the time interval I choose (not every frame). That would cause some popups (ugly, but if that is the price I must pay for a responsive interface, then Ill pay it). At least thats what I think it will happen. Correct me if I`m wrong.
Interesting, maybe you could use setEnabled on all the small meshes, unfreeze the rest and it shoud be all good while rotating and when movement stops enable them back and freeze ? (just a random idea)
2 Likes
I liked this idea. I will do that, just to see how it behaves.
3 Likes
I’d be interested in seeing both versions.