PDA

View Full Version : Keep bounding box of item in camera / frame bounding box rather than target a point



AbstractTech3D
10-24-2012, 04:01 PM
Hello

I have an issue whereby I'm trying to keep centralised (well framed) in camera a rectangular object while moving the camera to some quite extreme angles relative to the object.

The usual process of simply targeting the item breaks down as the camera approaches extreme angles, and the rectangular item as a whole appears in the camera to be somewhat no-longer evenly framed. Although the pivot point of the target item is central to the target item, and is successfully targeted by the camera - the difference is that a real cameraman would seek to keep the entire object framed such that the boundary corners of the item are somewhat evenly distanced from the edges of the frame - rather than simply keeping the dead centre of the item in the dead centre of the frame.

Hopefully that makes sense!

I've been trying for a while to build a versatile nodal rig that displaces a target null (parented to the rectangular item) based on the angle of the camera to the item, and also exhibits a fall-off of this effect as distance to the object increases. However, its become messy and difficult to tweak the multiple interacting nodal gradients to perfection this way, I've found.

It would be ideal if there were an option to target the item based on keeping the boundary box evenly distanced from the edges of the frame.

Has anybody solved this problem before?

Any advice?

Thanks!

AbstractTech3D
10-24-2012, 05:02 PM
Ok, after so far using a dummy guide bounding box I've attempted to average the DP Kit 'align to' angle values from the camera to the 4 vertices… see attached. It partially works. Unfortunately it flips the camera when the camera is directly in front of the bounding box. However, the framing of the box is improved (over simply targeting the bonding box) for much of the camera's range - but not all, and not yet to the extent that I'm looking for.

The setup's failures is almost certainly down to my poor vector math capabilities.

Still looking for help. :hey:

AbstractTech3D
10-24-2012, 06:43 PM
After further working on this, I have the camera keeping nice framing of the dummy bounding box when the camera moves horizontally. Framing with vertical movement is not happening so well, however.

Still looking for help. :)108753

AbstractTech3D
10-24-2012, 06:44 PM
After further working on this, I have the camera keeping nice framing of the dummy bounding box when the camera moves horizontally. Framing with vertical movement is not happening so well, however.

Still looking for help. :)108753

Sorry for the double post…. forums still not working nicely...

UnCommonGrafx
10-24-2012, 07:05 PM
That's a scary node tree...

AbstractTech3D
10-24-2012, 07:11 PM
That's a scary node tree...


you should see some of my others. Literally 10x this. Grinds LW to a halt.

UnCommonGrafx
10-24-2012, 07:21 PM
I'd like to.

AbstractTech3D
10-24-2012, 10:42 PM
I think at the heart of the matter I need the horizontal and vertical rotations (H and P) of the camera to happen in series: H first, then using the new position values for each vertex - calculate the P rotation.

Unfortunately have been unable to figure out a way to do this yet. I can't get DP Kit / Tools / Rotate to calculate the post-H rotation position shifts of each vertex - I think perhaps it doesn't work in the Item Nodal Motion context?

AbstractTech3D
10-24-2012, 10:45 PM
I think at the heart of the matter I need the horizontal and vertical rotations (H and P) of the camera to happen in series (rather than calculating in parallel): H first, then using new theoretical averaged position values for each vertex - calculate the P rotation.

Unfortunately have been unable to figure out a way to do this yet. I can't get DP Kit / Tools / Rotate to calculate theoretical post-H rotation position shifts of each vertex - I think perhaps this node doesn't work in the Item Nodal Motion context?

Double post…aagh!!!

RebelHill
10-25-2012, 01:23 AM
Well... first off, your node tree is overly, and unnecessarily complicated... Well. Not complicated, but unnecessarily "expanded". You got pos vec for each vertex, through split vectors into make vectors... Why? Take vector... split to XYZ... recombine to vector. Youve done NOTHING. So lose all that, its getting you nowhere and hiding the problem from you. Next is the method. You're targeting a single point still, which ofc is all you CAN do with any kind of align/target/etc type setup. The way you're getting this single point is by taking a average of the 4 corner verts... great... but that's basically the exact centre (so assuming the object is centred in modeler... you're just targeting the objects pivot).

The main problem you've got here... isn't the target behaviour... its the fact that as the object moves closer/further to/from the camera, its SIZE in view changes... Get too close and there's no way it can be all fitted in frame. The only option for those moves is to either move the camera back away from the object... or zoom out. So Id suggest that this is more what you need to aim toward.

Perhaps start out using plain ol regular targeting (or a single align to node if u like)... but put some other set up that measures the camera to object distance, and pushes the camera to make it always maintain this minimum distance from the object.

AbstractTech3D
10-25-2012, 06:56 AM
Cheers RH.

Yes, you are quite right that I left some unneeded nodal expansion in there - I realised after posting. My apologies.

Indeed the size changes as the camera moves to and from the item, as expected.
To clarify: I mean to keep the left and right edges at equal (or close to equal) distance from the frame left and right edges throughout the camera range of horizontal motion. And similarly the upper and lower edges of the box equal distance to the upper and lower frame edges throughout the range of vertical camera motion. (Obviously at extreme angles this equal distance is lesser than at more oblique angles, which is fine for my purposes). This doesn't happen with simple centred targeting through extreme angle positions. Consider the process of taking and framing a photo from an extreme horizontal angle of a picture on a wall. If you centred the centre of the camera frame on the true centre of the picture on the wall, you'll be left with a whole lot of white space on one side of the picture, and the other side very much filled up with the picture. Instead, what you would do (without thinking about it) would be to aim the camera more towards the side closer to you, and thus in effect push the picture (including its true centre point) off to one side enough such that the framing is much better balanced.

Actually, I think that by averaging the 'align to' angles that I'm in fact getting a different effect to averaging the positions of the vertexes. If I just averaged the position of the vertexes, yes I'd expect to get the same result as when simply setting 'motion properties / target' to the box item. But you can see (by switching motion properties / target between none and the box) that in-fact I am getting a much better framing - horizontally at least - when moving the camera even through extreme horizontal angles than when simply targeting.

I have furthered the idea (in my head), which I'll try tomorrow: To separate the horizontal and vertical adjustments by applying only the horizontal onto a parent camera, and only the vertical to a child camera. Thus the horizontal adjustment (which I appear to have correctly working) then becomes the new starting point for the vertical adjustment.

RebelHill
10-25-2012, 07:47 AM
Yeah I see what you're on about.

First off... averaging align vs averagin points... nope. If positional vectors px are positions, and rotational vectors rx are rotations that point to each of the positional points... then (p1+p2) / 2 = p3... and (r1+r2) / 2 = r3... Then r3 is pointing at p3... So no difference.

I cant remember the exact form offhand, Id have to dig in one of my books to find it... or mess around and figure it out... but the answer you wat is gonna be a trignonometric modification... Basically... alig to the pivot (regular target) +/-/*/whatever some trig function or other... Id give u a more definitive answer, but no time to be checking it all out now... but theres the track for u to explore I believe.

RebelHill
10-25-2012, 07:52 AM
No... wtf am I saying... Ok, strictly that first part IS true... but ofc, we're dealing with euler... which are ORDERED rotations... so the answer there is right... but doesnt apply to the standard ADD nodes... You need the HPB add node for that to make sense... and since we dont have an HPB divide node, then there's no way to properly split the value after.... Anywhich way... assuming we did, it'd be correct... as it stands, you wont get the same result via either method... but trying to add (or whatever) ordered HPB rotations will give you erroneous values, not a "different" but otherwise correct value.

AbstractTech3D
10-25-2012, 03:11 PM
Thanks RH.

Unfortunately however, I'm stuck at this point...

AbstractTech3D
10-25-2012, 04:40 PM
Just to clarify my theory (which I appreciate that you disagree with, and indeed you know more about vector math than myself), see attached image.

108774

Indeed the shift in the H channel in my posted setup seems to at least approximate this.

I've come to realise also that it cannot work in the P channel as is since the H channel is calculated first for each 'align to' calculation - effecting the P calc. Instead I need to derive the single appropriate new x target position to replace the x pos values of each of the vertices. i.e. the box x pos + delta (delta referred to in my image).
From this I should, I think, have derived the correct P offset.

XswampyX
10-25-2012, 05:02 PM
Have you allowed for the perspective of the camera? In your hand draw example the centre mark would be more appropriate if you drew it with perspective.

AbstractTech3D
10-25-2012, 05:44 PM
Have you allowed for the perspective of the camera? In your hand draw example the centre mark would be more appropriate if you drew it with perspective.

Hi XswampyX
Not quite sure what you mean by the 'perspective of the camera', sorry.

Basically trying to use the vertices of the bounding box object to define a floating or roaming target point such that the bounding box vertices are continuously framed as well as they possibly can be.

RebelHill
10-25-2012, 06:33 PM
see attached image.

Well math skillz aside... when dealing with geometrics technical drawing is a much useful thing. Now you've seen my node vids, right... cos if so you doubtless have seen my terrible freehand childish scrawl in the drawing of vectors... my sine graphs that "rise" and my "radian circle" that has 3 marked on the number curve AFTER pi...??

So trust me... when it comes to figuring out your problem in a clean, precise, and well defined manner, you're well on your way. Take another look at your image... whattaya see?? 1 big triangle, cut into 2 smaller, with bisection line cutting from the camera point to the "intended" centre.

Triangles... NOT right angle ones (so no regular pythagoras)... but trig. Find the lengths (vector mags+directions)... solve the angle.

AbstractTech3D
10-25-2012, 07:23 PM
Yes, have got your great nodes videos. (Haven't yet watched all of them).

I believe I see a geometric trig solution. Will put it to the test later today.

Cheers RH!

AbstractTech3D
10-29-2012, 09:39 PM
4 days of trying to solve this… and still very much stuck!