Can Scroll Whell work with viewport degradation?

Currently the Scroll Wheel viewport zoom / camera closeup move does not work with Rhino standard view manipulation degradation (Dynamic Display bounding box mode, skylight shadows degradation, maybe more view manipulation optimizations that I am not aware of). That results in much slower navigation while using scroll wheel, vs. for example zooming in with Ctrl+RMB-drag.

I understand that each scroll wheel step is basically a single view change, and there is no in-between smooth mode while scrolling, like when holding RMB and rotating the view, so Rhino does not know that we are in the middle of zooming action.

I was wondering if this could be implemented. Scroll Wheel action is hardly ever a single step. Most of the times user would keep scrolling to get the view where it needs to be, sometimes back-and-forth.
What if, the first detected scroll wheel step would trigger the view degradation mode as the other view changes do, and then keep it on for another 150-200ms. If no more scrolling happens, switch back to regular display, otherwise if user keeps scrolling the view stays degraded, until 150-200ms passes from the last scroll wheel movement.

@DavidEranen - is that something you think would be possible?

thank you-


Hi @Jarek,

You hit the nail on the head in regards to why this is a bit tricky. I’ve definitely thought about it, but redrawing on a timer is risky, and can be just as unexpected and unwanted as the problem it’s trying to solve.

Either way, I’ve created a YT item so that I don’t forget about this. It might be worth trying out:


hi David - thanks for the explanation and looking into it.
Hope you can come up with something creative :slight_smile:


This is really hard to implement. We’ve tried several times in the past and failed.

The only other thing in Rhino i can think of that does that is Cycles… option to manipulate the view in non-raytraced mode, and after user-defined time of view change inactivity, raytracing kicks in. Maybe @nathanletwory had some secret solution? I would be curious to know what technical problems you forsee with auto-redraw in 200ms after scrollwheel inactivity.

It’s called drawing on a different thread. Really hard to do when any customization to the display exists though plug-ins (think grasshopper)

Ok, as expected beyond my comprehension. Thx for the note!

I’m just pointing out that this is very hard (not impossible). I wouldn’t re-engineer the entire display architecture just to solve this one issue. The better option is to just continue to make the display faster without degradation :wink:

1 Like

I guess you’re talking about the fastdraw option that fades the Raytraced result in gradually. The OpenGL view you see is close to the Rendered view actually.

But @stevebaer knows what he’s talking about (:

1 Like

I wish I didn’t. All I’m saying here is “don’t get your hopes up”…

That is what I meant :slight_smile: