🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Tight fit point cloud into view frustum

Started by
12 comments, last by ramirofages 4 years ago

Hello guys, I've been reading about how to position the camera in a way so that the view frustum contains as much of an object as possible, and a lot of people out of simplicity recommend using a sphere or bounding box approximation for the volume of the object, but I need an accurate fit for a set of points that I have, which can't fit nicely into a sphere or a box. Unfortunately I coulnd't find anything aside from the sphere/box methods and decided to come ask here, since this must be a common feature of most programs.
Any idea or article you could give me is welcomed ?

Advertisement

The solution could be anything - the problem is not well defined. What more do you have?

Is your camera position / orientation somehow restricted? I guess you have at least an up vector so the camera can not tilt?
is it perspective or ortho projection, is fov constant, do you aim for top down view or angled, are your points on a plane…?

ah yes sorry for that! I can provide a fixed rotation and fov, so it's just moving the camera. The fov is vertical fov although I also need the horizontal fov for mobile devices. The points are randomly scattered (I think they do come from some sort of mesh object but I cannot assume that)

Here is a poorly drawn image of what I'm looking for. Although I'm not looking for code of course, just need some guidance

image

But this does not answer my (so your) question.

Taking your image, if camera can only move horizontally it's easy (red arrows) - just find the min / max distance points to the planes, for each plane calculate camera movement to intersect the point (some trig), finally make the largest possible move.

But if orientation and position of camera is totally free, there are infinite solutions (blue and cyan examples). So you need more constraints on the camera to define the problem at all.

Edit: Missed your second reply. So it's the easy case. But need to go, will reply later.

Ah yes, calculating the distance from point to plane would work but I would need to first position the camera in the center and in front of the points right? and if so, how would you do it? moving the camera in the backwards direction from the center an amount large enough? (like the volume of some bounding box or sphere?)

ramirofages said:
Ah yes, calculating the distance from point to plane would work but I would need to first position the camera in the center and in front of the points right?

I don't think so. I assumed you want to leave the camera where it is, and then move it only forth or back so all points are in view. there should be only one exact solution easy to find (because distance to planes is signed). It should work even if all points are behind the camera for example.

But if you can position the camera at any position initially, your idea would work to ensure the points are distributed well in view. The above alone would not guarantee this. I see no need to move the camera backwards for the start, having it at the center should do and then calculate the forth / back translation.

If camera rotation is free too, you could first find the average plane of the points (e.g. using least squares), than align camera to that plane and calc forth / back translation.

If camera tilt is also free, you could project the points to their average plane and then find their average line. Align this line to the wider side of the camera and proceed as above.

Example if points would form a nice grid so the illustration is clear.

I draw the average plane as a red rectangle, although you would only get the normal.

The average line is in green, and cross product with plane normal then gives us all information we need to construct this red rectangle, which defines the view of the camera.

Awesome! Thanks for your complete explanation for different cases. I have one more question regarding this:

JoeJ said:
I see no need to move the camera backwards for the start, having it at the center should do and then calculate the forth / back translation.

Wouldn't the distance calculation be off if I calculate it having the camera at the center of the points? Unless I'm not understanding how to compute those distances:

ramirofages said:
Wouldn't the distance calculation be off if I calculate it having the camera at the center of the points?

No problem, because you get signed distance to the plane, which changes linearly if the plane moves linearly. (99.9 % sure)

This topic is closed to new replies.

Advertisement