Rhino 7.1 bug - DollyZoom distorts perspective view

There are two bugs related to the DollyZoom command. One of them is illustrated in the following screenshot. (I always set the Options>Rotate to “Rotate relative to view” - as shown in the screenshot.)

The first bug:
Before I used the DollyZoom command, the perspective view looked like the one shown in the upper left corner of the screenshot. (I saved this view with the NamedView command.) When I used the DollyZoom command, the camera moved a little when the cursor was near the center of the perspective viewport. When the cursor was far above or far below the center of the viewport, the camera was tilting rather than moving.

The second bug:
I changed the Options>Rotate to “Rotate around CPlane Z-axis” and used the DollyZoom command again. The second bug appeared. It is a display bug which grotesquely stretches all objects in the perspective view. The bug is shown in the bottom images of the screenshot. Once the bug appeared, changing the Options>Rotate had no influence on the display. I could not restore correct perspective view by zooming, tilting, and panning, but I could restore it with the NamedView command. This bug appears in the perspective view only.

So far, I am unable to repeat this.
Does this happen in a new file too?

What does your SystemInfo look like?

sysinfo.txt (3.4 KB)

I made new file from template, and both problems appeared instantly - as shown in the following screenshot. After the DollyZoom command I get the extreme distortion and I cannot pan. When I try to pan, by any means, the perspective view rotates instead of panning.

Hello - please turn on the camera (f6) for the view and then run DollyZoom to see what it does to the camera.


The camera widget has 5 control points: viewpoint, location, roll control, target, and field of view (a.k.a. lens angle). During the DollyZoom command the only moving control point the viewpoint. All other control points are stationary. (Viewpoint, location, and target are almost in the same spot and the field of view becomes very wide.) After the DollyZoom command the mouse rotates the camera widget, but it does not change distances between its control points.

The white lines in the screenshots are part of the construction plane grid. As you can see, the grid is also severely distorted.

By the way, it would be nice to toggle the DollyZoom mode (scroll wheel moves camera back and forth) by pressing the CapsLock key. :yum: The DollyZoom is useful for architects who want to fly inside house model. Some architects purchase 3D Connexion SpaceMouse because it is more convenient than the existing DollyZoom command.

The SystemInfo looks okay but it’s clear this is an old laptop and you’re short on VRAM.
If you’re driving a single standard resolution monitor, it should work. High resolution and multiple monitors are out of the question.

The display symptoms you’re showing I associate with display driver issues.
I don’t have a lot of hope here, but if it were my laptop, I’d update the drivers for the Intel GPU.
The K2000M is no longer being updated and you have the final drivers for it.

Here’s a link for the Intel 4000.

Driver from October:

Any luck?

Hello - so far, you are describing what DollyZoom does, not a bug, that I can see.


Rhino documentation says: “DollyZoom command moves the camera location and changes the lens length at the same time…”

I do not see any movement of the camera widget. I only see the movement of its viewpoint control point, which changes the field of view (a.k.a. “lens length”). By the way, there is no such thing as the “lens length”, but there is focal length.

I am skeptical. My laptop has 2GB of dedicated video RAM and 15.8GB of shared video RAM. I have connected 4K monitor to my laptop and I display 4K videos at 60Hz frame rate without glitches.

You can do what you like obviously.
I told you what I would try and why.

We see this problem with old Nvidia cards mostly on old Apple MBPs that can’t get Nvidia driver updates anymore.


I think you are confusing what DollyZoom is for.
Seems like you are expecting different result from this command and may be confusing its normal behavior with a bug.
DollyZoom is not to be used for walkthrough/flythrough as your target is stuck in place by default.

Check this out:
Dolly zoom - Wikipedia
DollyZoom is a cinematic “trick” move that makes it look like the camera stays in place while “sharpening” the perspective, this is achieved by moving the camera and compensating with the lens length at the same time…

So Pascal may be right here, hard to tell just from the screenshots, maybe post a video of what you describe as a problematic behavior.


That looks like a correct behavior. Your target is past the scene objects, and the camera getting very close to it makes the objects look super distorted since you are probably getting to lens ~1 or so…
There is no problem here, just make sure you understand how this camera tool works.

You are completely wrong. Your quotation from the Wikipedia and my quotation from the Rhino documentation say that the camera moves. There is another bug: the grid is distorted. I have to use the NamedView command to restore its correct appearance.

Yes, the camera moves, but the target does not - thus creating the effect also known as the vertigo zoom, which - when taken too far - creates a massive perspective distortion, which is what you are seeing. Notice how close your camera is to the target in the end of the video. It’s explained in a movie setting in this clip:

HTH, Jakob

Edit: Notice how the examples all have their camera target on an object/person. The reason your video goes haywire is because your camera target is behind the objects you are zooming in on (or past, really).


As Jakob said, and you wrote yourself- the camera moves, that is correct. Target does not. So by “DollyZooming” you are just getting closer to or further from the target, with changing lens to maintain the same “view frame”. In your sample case the target is slightly past the scene objects, so as you get close, they become super distorted. So again, no bug here, just the way Rhino handles DollyZoom and its normal behavior in your scene and camera/target setup.

I was looking into DollyZoom calculations a while ago because I am not a big fan of how Rhino does it (target-based) and I actually need to DollyZoom a lot since selecting the best possible views of models is important part of my work. I am using a custom DollyZoom navigation where the “target” is always picked based on the object under cursor location This gives much greater control of the view and perspective depth changes. Maybe Rhino’s behavior could be adjusted similar way? In Rhino viewport navigation the camera target is…well… a moving target, so it is hard to always predict it’s location without checking and manually adjusting it to do a desired DollyZoom.

Here is a sample of Rhino and my custom object/cursor based DollyZoom:



1 Like

Camera movement means that the entire camera widget moves!!!
Camera movement means that the entire camera widget moves!!!
Camera movement means that the entire camera widget moves!!!
There is no good reason to grossly distort the objects. When the camera moves past the objects, the objects should disappear from the view. In other words, the distortion is a bug, not a feature. The Rhino camera should behave like real camera used in Hollywood. When they move the real camera past the actors, we do not see gross distortion of the actors.

The camera widget moves. Saying three times is two times too many. The widget moves, and the target stays put.

You want it to work like that, there’s the difference.

What you get is the visualization of the camera location (the tip of the pyramid) and the target (whatever is in that viewplane).

To help yourself, think of the camera as the point in the pyramid.

There has never been a visualization of the camera as you say it should.

And such a camera widget makes no sense. If it makes you happy you can always model a camera and put it at the tip of the view volume.

Now @andrew.nowicki do yourself and all others a favour and stop dismissing the great input from @Normand and @Jarek. Tantrum fits won’t change that they are correct.

1 Like

Really cool as always, @Jarek!

It should move according to the Rhino documentation and the Wikipedia article, but it does not move. The only thing that moves is its viewpoint (control point which controls its focal length).

I said it twice before my last post, but Jarek and Normand still do not understand it.

This is big news for 3Dconnexion company - this is exactly how their SpaceMouse works. Architects use the SpaceMouse to fly through a model of a house. The existing DollyZoom really does not make sense - I would describe it as a buggy zoom. How can you justify the semi-permanent distortion of the grid?