dolly
dolly copied to clipboard
h3r2tic
Support for bbox/bsphere framing?
I saw in the readme that field of view is (intentionally) not part of this. But could it be?
Framing an object (smoothly) based on its bbox/bsphere is a common task for such rigs in the wild.
That is a very good question, and got me thinking for a while! It does seem like a useful feature to have, but at the same time, I think it would be entirely orthogonal to the current camera rigs.
Please correct me if I'm wrong, but I believe the framing would sit on top of the rig, using a final interpolated position and rotation. It probably wouldn't then interact much with the camera rig, and be a separate system instead.
Now would it make sense for it to be part of dolly? I imagine it could quickly gather up additional features and interactions: e.g. the camera needs to also care about the aspect ratio, different kinds of bounding volumes (or precise meshes); then depth of field would naturally extend here, and the camera now needs to also worry about focal length and aperture, etc. I don't feel nearly qualified enough to tackle those, and my projects usually don't have those sorts of requirements.
My current thinking is that those bits would fit better in a sibling crate, but if it's something you're passionate about, and would like to contribute to dolly, then let's figure it out :)
In the context of this crate I would assume you feed this fov and frame aspect (the latter is optional, needed only if non-square). fov is usually vertical if the frame aspect is non-square but this could be parameterized too. This is for a simple perspective camera. Fisheye or cylindrical projection cameras require possibly different math but could be tackled later, if users really ask for them.
In any case, all you want then is that the camera's position is shifted to frame the geometry under that constraint. There is really not much to it. Basically look_at_bounds_perspective() doing just that. A look_at() with shift away from the bounds along the look at axis until bounds fit into fov under a simple, linear perspective projection.
Does that make sense?
Ah, I think I misunderstood what you meant then -- I thought you were suggesting that the framing would happen by adjusting the camera's fov. In that case the crate would start concerning itself about optics, and that potentially opens the flood gates to a whole lot of other features, changing the scope quite a bit.
Framing by shifting the camera position sounds less problematic for sure -- in such a setup, only the framing driver needs to know anything about projection parameters, not the entire rig. That would probably make sense.
Yes, sorry for not being more precise about this. The name of the crate very much suggests this too and so I both get and second the idea that anything beyond belongs either in another crate or at least behind a feature gate that prevents the compiler from seeing it at all, if the user doesn't request it.
I.e. what I meant was just what is minimally needed to change position.