Camera Frustum Control / Dynamic 3D Realtime Navigation

Rhino
,
1

image
image1514×833 77.8 KB

I’ve had this on my mind since I bought my first 3D mouse in 2004ish, and used it with programs like CATIA, Inventor, Solidworks, Rhino, etc.

I always found Rhino to have it’s own odd navigation behavior, but I’ve always done my best to adapt.

Eventually I learned the reasons behind the causes of said odd behavior.

Hence, the source of the behavior is entangled in the following entity:

image
image1792×522 129 KB

As a user, I need more control over this camera frustum entity, in order to correct Rhino’s odd navigation behavior. I mostly need control over the distance between 1 and 4 in the frustum.

I’ve had enough with 3dconnexion’s driver flaws as well.

I’m interested in fixing the problem, but I’d need to know if the geometry of the camera frustum is parametrically constrainable – per say.

Also, if a peripheral device doesn’t exist that can do the job, and drivers don’t exist that can do the job, then I guess this might get difficult.

Primarily, I need Rhino to give me control over the camera frustum. I need control over the distance between 1 (the camera viewpoint) and 4 (the target point). I need to be able to lock the distance.

2

I doubt this will help but it’s worth a try.
If you change the view projection in the Perspective view to Parallel, then I think your view navigation goal of leaving your points 1 and 4 the same distance apart will be met. However this comes at a cost of display distortion.
It might be worth a try.

1 Like
3

I agree in that the parallel projection definitely helps reduce the ‘quicksand effect’. And appears to constrain the distance between those points 1 and 4, but then the parallel projection is allowing the distances between points 4 and 3 and 3 and 5 to move freely.

I very rarely use parallel projection, but when I do, I don’t necessarily need to constrain the distances between those entities per say, because I might get my self in trouble by criticizing the very essence of how Rhino achieves the zoom behavior under the parallel projection scenario – although I don’t mind challenging that particular permutation of ‘zoom’.

My focus then would likely be the ‘perspective’ projection scenario – mostly for now.

At some point the ‘dolly zoom’ behavior will likely be addressed, and I’m not sure how that might relate to different projection types atm.

After glancing at it for a moment it appears dolly zoom is oriented for ‘perspective’ type…

3dconnexion doesn’t seem to utilize ‘dolly zoom’ as well as it should imo, which kinda leads me to this brain storm.

4

Right. Dolly Zoom is how we push the target point along with the camera point.
I have no idea how to do that with a 3dconnexion mouse.
They make me motion sick so I will not use one.

5

Dolly zoom actually isn’t the behavior I remember it to be, so maybe I always thought it was something else.

I did a little analysis on it and noticed it’s only maintaining the distances between 4,3, and 5.

Also, I think those frustum entities are labeled poorly.

5, for example is pointing at one particular point entity, and describing it as an ‘angle’.

While 3, is depicted as a roll control entity.

I guess 2, 3, and 5 are more like ‘handles’ or something.

At any rate, I think the ‘dolly zoom’ is more like a camera distortion than it is an actual ‘zoom’ behavior.

Dolly zoom seems to mostly just alter the length between 1 and 4 while maintaining the frontal frustum frame size.

And that’s not really what I want the 3dconnexion device to control anyway, so maybe that’s a good thing.

6

Ok, so to revise the zoom behavior I’m interested in, and make it something that others can recreate on their own, it’s very similar if not exactly the same as if the user clicks on the (2) camera location entity and uses the gumball to drag the whole frustum parallel to that line between 1 and 4.

When the user does this they will witness a zoom behavior that moves the whole camera frustum.

image
image1490×652 66.6 KB

Unfortunately, this only seems to work on non-parallel projection. Which is fine really.

After more analysis, I’m seeing that the 3dconnexion device is doing it this way atm :thinking:

Weird, imma try turning off the target reset feature they have, and see if I get anywhere.

7

You might want to have a look at the Rhino “WalkAbout” command.
https://docs.mcneel.com/rhino/7/help/en-us/index.htm#commands/walkabout.htm

1 Like
8

I’ll definitely check that out.

I’m currently realizing that the behaviors of zoom are much different for ‘parallel’ projection vs ‘perspective’ projection.

The one for perspective, seems to be the one I want which moves the whole frustum, whereas the one for parallel is just changing the size of the frontal frame…

Some reason I never really differentiated the two :thinking: Or I had them backwards…

Or 3dconnexion changed something and I just forgot lol.

9

You’ll get a DollyZoom with Walkabout turned on in a Perspective display too.

1 Like
10

I’ll have to check those out sometime, but I think I had a breakthrough in my realization in 3dconnexion’s modern drivers.

I think there’s probably some confusion in nomenclature. I decided to turn off their “auto” option for their “rotation center” and this helped me see that frustum in a manner where it actually stayed the same size and shape during navigation.

So, now I’m thinking what is needed would be a different rotation center auto behavior that will move the target per say without changing the size of the frustum.

For now, I’ll use my new understandings and continue learning about these camera behaviors and see if I can create some more clear concepts in the future.

With the modern drivers, there still seems to be deficiencies with ‘rotation center point control’ in a smooth manner without frustum size manipulation. This might also mean to include smoother camera frustum control would be needed or I need to learn more about how to control it.

11

Ok, so dolly zoom is changing “lens length” if I’m not mistaken. And walk about is just giving the user a visual of the center of rotation in the viewport and altering the button combos or something.

I wont necessarily be using those two commands, but they’re good to know.

Now, I’m seeing that 3dconnexion seems to have already solved the old problem of the quicksand effect and the issue I was trying to bring up.

So, I guess this thread was kind of a false alarm now that I have thought more about it and analyzed things more.

The only thing I’d say however or reiterate is the lack of rotation point control for the user.

But, this would fundamentally be incompatible with Rhino’s current way of doing things I presume.

If Rhino is always forcing the ‘rotation point’ to be at point location (4) the target point of the camera frustum, and this is basically always the center of the viewport, then there’s probably no other way to provide the user the ability to lock certain rotation points – cause it’s fundamentally always the center of the viewport… :thinking:

I wish there were other options for that…

3dconnexion’s drivers seems to maintain the center of rotation from ‘vewport center’ upon motion and allow it to lock temporarily until motion stops, then the target will update if their ‘auto’ option is active – this is where my confusion was still residing.

I’ve known about this in the past, and now have a much clearer understanding.

Trying to put this into words can make even me motion sick hahah.

In the future I’ll have to make a new thread that focuses on ‘center point rotation’, now that the frustum seems to be behaving better…

12

Try fiddling with this:

image
image936×881 43.1 KB

1 Like
13

ahah I keep forgetting about that, thank you :beers: I’ll check it out! :sunglasses:

Ok so I checked that out and noticed something very interesting.

I think there’s a conflict between that feature and also 3dconnexion’s feature:

image
image1751×829 131 KB

After turning them both off, I was able to witness some “consistency” in behavior of the camera frustum size.

Unfortunately however the frustum size is dynamically increasing/decreasing as per zoom action.

If (both) aren’t turned off, you wont notice any real discernable effect.

So, with this being said, I wish there were a way to control camera frustum size under the regime of (both) of those two options in images above turned off.

14

You might need to get in touch with Markus Bonk from 3dconexxion. I haven’t heard from him for some time but he was always the SpaceMouse driver guy.

1 Like
15

Cool, yeah I remember his name. I think we shared some emails in the past.

I’ll have to reach out to him.