Hi,
I think i found a bug on the method ArcRotateCamera.zoomOn() show by this PG who truncate the box instead of being at the min distance where we could see it fully in the current viewport.
So, zoomOn method should sideeffect to camera.minZ? Is such behaviour in the scope of this method?
Interesting, I see source code and this method changes the camera.maxZ, then it should change minZ either 
1 Like
Definitely a bug here (or at least, a design issue) if you ask me.
It looks like the function updates the zMax; Donāt know what this is supposed to do in case of a zoom?!
It also looks like the zoomOn method works only considering the camera is actually facing the mesh.
To make sure nothing was conflicting, I tried to remove āsetTargetā and move the camera āradiusā further from the object and call the function only āon readyā. As expected, it didnāt change anything to it.
So unless Iām missing something, this is, in my opinion, requiring a fix/improvement, yes?
@PolygonalSun @sebavan
Edit: Might have posted a bit too fast here. It actually seems to works with just a slighty bigger size of mesh. So, it might be just a problem with the zoom on tiny mini meshes.
@mawa, both PG-Scenes seems not to work, the box is still cut-off
1 Like
Yes, you are right. I didnāt express it correctly. The part with the zoomOn where the entire object is supposed to be displayed in the canvas is indeed NOT FIXED with a bigger mesh.
However, the minZ seems to work in this case (where with the smaller mesh both requirements are not met). Thanks for rectifying this for me and my apologies for the confusion. Have a great day, 
My recommendation would be to rely on the framing behavior for those tasks:
@PolygonalSun could you check the other functions ?
2 Likes
Yeah, I can take a look at things
hello,
I made some changes as @sebavan recommended resulting in this PG which works pretty well.
Now iām questioning about āwhy does it not zoom a little more to be really at the edge the mesh ?ā.
I conducted my little investigation by digging in API as well as in the source code and I finally found that framingBehavior.zoomOnMesh() takes into account the bounding sphere and not the bounding box of the mesh (as I would have need).
Would it be possible to create a _calculateLowerRadiusFromModelBoundingBox method that would take the bounding box into account?
and thereby create a new static FitFrustumSidesByBoundingBoxMode?
and therefore modify the one already present by FitFrustumSidesByBoundingSphereMode.
sounds like a cool idea, do you wanna make a PR ?
ehmā¦ Iām not sure that Iām able to do this, Iām a bit newbie in developpement ^^ā (Iām student in sandwich course)
Maybe i can try but i will need help.
if Iām right I will need to fork the project, do changes (in wich branch ?), and then do a pull request (I donāt know how to do that) ?
1 Like
Hey,
You should find all the needed information here
Let me know if you need some more help with this 
1 Like
thanks @neu5, i will take look
If I need to ask some questions for help, were can I put them (cause I think this thread is not the best place)
btw should i close this BUGS? I didnāt really understand if it was really one or not. If so, which post should I mark as a solution?
I really donāt know how the BabylonJS team handle this.
I think that the discussion about the technical details may lay in the comments of the PR itself.
I think we need someone from the BabylonJS team. Maybe @sebavan or @RaananW can help you here.
1 Like
in this case a link to the PR would be a great solution. Having said that, this is not really a bug - the framework works one way, you want it to work a different way So there is no real resolution here (still, myabe the link to the PR).
You can keep it as is. If you have questions regarding contribution let us know! we are very happy to help with this topic
1 Like