I must admit your tone could be badly interpreted.
On perf standpoint:
- Maybe we have a bug in the OBJ loader hence a repro could help
- Try calling scene.freezeActiveMeshes()
- Using instances can DRAMATICALLY help in your case
2 Likes
Sorry for my tone, I will do better.
I will work on that, thanks for the advice! I hope soon I can show you guys some results.
It’s probably not a bug, since I use OBJ files and glFT.
If I find something usefull I will share with you.
2 Likes
Ok thanks! but keep in mind we are here to help and again there should not be any major difference between 3js and bjs when setup correctly
1 Like
Hi @GabrielMarcondes welcome to the community.
From experience, imports require your expertise and optimization.
After looking at hundreds of edge cases, it is (probably) not a BABYLONJS issue.
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.
BUT that is just the beginning. To get great exports you really need to understand what you are telling the exporter to do.
With gr8 humility. So many times I thought the same. Then dug deeper to find I had instructed the export to do something incorrect. All in all a great way to learn. But the problem space is massive.
So you need to dig in and optimize your model.
Post the LOG or anything you can, like a PG.
BABYLONJS is vGood. 60fps for many things (if you do it correctly).
And this forum is best in class.
Welcome.
2 Likes
Challenge accepted 
See the other thread: Animation performance drop by translation/rotation - #2 by Gijs
I hope I didn’t sound too critical before. BJS is awesome.
But this issue (“I translated meshes and the fps fell to 30fps”) is exactly the kind of thing that I’d have expected to work out of the box with no performance loss. This is a simple demo “load some objects and make them run circles”; I’m certain BJS can handle it and you’ll tell me “do this and it will get back to 60fps”.
This example hopefully makes a practical case of what could be easier for a simple demo:
- you need to
addAllToScene()because it’s a container. But at the same time I need to do things like scaling with a container.meshes.forEach loop.container.scalingwould be pure syntactic sugar but helpful. - with instances I have to disable to original mesh. At least I read that somewhere, perhaps it was related only the RTT thread with overriden materials? I don’t know why I have to do that.
- freezing materials seems to be what you want 99% of the time, but it also required a foreach and an if.
instantiateModelsToSceneis great – it just works and I read that instancing objects was not a trivial thing to implement. But now I have to do a foreach to the rootNodes of a subkey just for a simple translation. A façade for translation/scaling/rotation, just like with the container, would be very practical.
This is a bit closer to what I’d like to write
BABYLON.SceneLoader.LoadAssetContainer(path, scene, (container) => {
container.scaling = new BABYLON.Vector3(0.1, 0.1, 0.1);
container.instanceToScene(
5,
(instance, i) => {
instance.position.x = i*2.0;
instance.entries.animationGroups.forEach((group) => { group.speedRatio = 1.0-i/10; } );
}
});
I can just work with the instance. I don’t have to understand if the main object is part of the scene or not, instanceToScene takes care of that. If I want to do something that is less standard, such as setting the animation speed, then I fall to the current API, which is very reasonable. The animation loop could also have a façade for translation/etc, abstracting the for loop of rootNodes.
This is of course my two cents, and my personal experience as a developer using BJS and not a developer of BJS (yet 
).
My point was more about: Is that simpler with 3js?
Not sure why you need that? This should not be the case
Sorry, I started to diverge and just suggest improvements to BJS instead of comparing it. But googling returned this, which though a 3rd party extension is exactly what I’d like to have as an user: GitHub - pailhead/three-instanced-mesh: wrapper around THREE.InstancedBufferGeometry
I don’t know. It ended up being part of the demo that became part of the RTT/multipass howto after that long thread. I understood it was necessary and I vaguely recall that there was some trouble with the rendering in the RTT if the original object was used. If this is not necessary let me know and I’ll fix the demo and docs.
I don’t think it is necessary 
As I never played with 3JS, this topic made me want to try a bit, and I create a FIGHT page 
'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 
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 
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
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. 
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.
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