Maths: Camera Position From AABB?

I'm trying to do the kind of "fit everything into the camera" stuff that 3d modelling software does. Essentially, I have an axis-aligned bounding box (defined by two vectors) which contains everything I want to look at, and I have a camera direction (defined by a single vector) which describes where the camera should point. Now I want to position the camera such that orienting it in the given direction will include everything in the bounding box, no more and no less.

EDIT: Forgot to mention that it's an isometric perspective that I'm wanting. It's just not axis aligned.

I have no idea how to go about it though.

This seems quite easy to me - I must be mis-reading it.



A quick, easy, fix would be to put thingies on the corners of the bounding box, then doing an EntityInView/EntityVisible thingybob thing - zooming/moving/scaling the contents of the box and/or the camera (whatever you want) until all thingybobs report back as EntityInView/EntityVisible.

'"Bob's" your sausage'.

What language is this in?

Blitz3D.

How do you know he's using blitz3d?

Its probably C++ and Bmax with TV3D

Oh, I thought the question was related to my answer.

I just want the maths for it, so I can do it in any language. At the moment, it's in BlitzMax and TV3D, but I want to know the math behind it. I don't want anything API specific because I'm not using Blitz3D, but I can probably cope with a code example in most language as long as it does all the maths itself (within reason, I don't need classes for vector math functions or whatever) and no helper functions.

Also, it's time-critical so moving it back bit by bit, trial and error, until I come across a close enough answer won't work. I'm sure it must be possible as this would be required for lots of things. Dynamic shadowmapping springs to mind, for one.

http://www.blitzmax.com/Community/posts.php?topic=76359

Thanks, but as I said, I'm looking for the maths, as I'm not using Blitz3D. Also, scaling the geometry to match the camera is not possible, it has to be the way around that I specified.

I imagine you will need some FOV maths for this.

Surely a triangle would be the port of call here?

If you think about it, a line running from the widest points. Then a line from the widest points, at the angle of the camera FOV. This would form a triangle.

Now, all you need to do is get the intersection point of these two lines. That should give you the position the camera needs to be. You would need to do first work out whether your fitting it height wise or width wise of course.

Scrap that actually. Drawing that out reveals closer objects may lie outside the the cameras view, even though they aren't the widest points.

BUT, if you take the side of the bounding box, closest to the camera, you can use this edge to perform what i mentioned above.

The scene is the circles and boxes. The large box is the bounding box. And the 40 Deg text is where your camera should be when it's position is worked out



You have your camera angle already, or should be able to work that out. You know the other two angles will be identical, so that should be easy to work out. You know the distance across the bounding box, between angle a and angle b.

So, given that information, you should be able to work out the distance from either point, to perfect point of the camera.

You need not even use line intersection, as given the 3 angles and a distance of one side of the triangle, it should be easy to get the length of the other side. This will give you your position.

Looking over that again, it should be easier to do, as you can create a 90 degree angle by chopping the traingle in halve, and halving the camera view angle. Gives you a nice 90 degree edge and easier maths to work with.

I'm not sure I follow you Ross. For one thing, the camera isn't necessarily going to be at right angles to the bounding box, so it won't necessarily be the same distance from any two points on the bounding box. Also, it's an orthographic/isometric perspective so there's no FOV as such, just the width and height (both the same) of the camera frustum, which are also unknowns.

I've been having yet another go on pen and paper again myself today and I have a couple of ideas but I need to think them through a bit more. Even if the theory is right, I still might have a couple of questions on the practice.

Could you place 8 objects on each corner of the bounding box, project the world coordinates to 2D, and then check wether each of these objects has a valid 2D projection coordinate, e.g. within the graphics screen.

If one is < 0 or > ScreenWidth, you could then move the camera back until they are all valid.

Much like how you use ProjectedX, ProjectedY etc in Blitz3D.

Just an idea! :)

Nope, I can't just move it back until it fits, because it's speed-critical.

I think I'm about half way now though. What I'm doing is creating a vector which describes the scale of the bounding box, then transforming that vector from world space into camera space ( orientation only, since the camera has no scale or indeed position at this point. )

Now I've got a bounding box oriented to the camera, but it has no position. The x and y dimensions of this box tell me the isometric FOV, and the z dimension gives me the distance between the nearplane and farplane. So if I knew where to work back from, I could derive the position of the camera by inverting the camera direction vector and multiplying by the distance between the farplane and the nearplane. I'm just not sure how to determine the point to work back from.

I'll have another think about it and make some more scribblings, see if I can't figure it out.

EDIT: Oh, and in case anyone is wondering why it matters where the camera is positioned, it's because I don't want crappy depth buffer precision. It's true that the position doesn't matter so long as the direction and FOV is right because an orthographic camera renders the same image at any distance, but I don't want flickering vertices and whatnot because the camera is further away than it needs to be.