Camera zoomOn()

Bugs
1

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.

2

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 :thinking:

1 Like
3

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?! :thinking:

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.

4

@mawa, both PG-Scenes seems not to work, the box is still cut-off

ZoomBug

5

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, :sunglasses:

6

My recommendation would be to rely on the framing behavior for those tasks:

@PolygonalSun could you check the other functions ?

1 Like
7

Yeah, I can take a look at things

8

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.

9

sounds like a cool idea, do you wanna make a PR ?

10

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
11

Hey,
You should find all the needed information here

Let me know if you need some more help with this :slight_smile:

1 Like
12

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?

13

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.

14

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 :slight_smile: 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