Shadows and Display Speed test/need for tune-up

This has been mentioned in a few other threads but I think it deserves its own topic and a bit more scientific approach to show the issue and need for improvement.
( @andy, @DavidEranen, @jeff - this is for you guys)

Problem: Sun+Skylight with high quality shadow setting display is very slow due to skylight and cast shadow quality linked.
Mainly in architectural and set design models there is a need for clean and crisp edge shadows in large size models (not complex/heavy, just vast). At the same time the best look is a combination of Skylight (AO) and Cast Shadows. Currently the price to pay for very crisp cast shadows and AO is a major display slowdown to the point of making Rhino unusably slow.

I have prepared a bunch of scenarios tests that should illustrate the problem. Using recent Rhino WIP, starting with default Render mode, the only alteration is no soft edge shadows)

Here is the test file if anyone is interested: WIP_ShadowsDisplayTest.3dm (3.4 MB)

Note: FPS has been determined using _TestMaxSpeed command. Looks like this command is not triggering the DynamicDisplay SkylightDegradation so it has been changed manually via Advanced Options to mimic the screen navigation interaction

Please see below some testing results with comments:

Default shadows quality: almost perfect AO, good FPS, unacceptable cast shadows:

One has to go really low with Shadow Quality (4 MB) to notice grainy AO shadows (which are still not bad). Cast Shadows almost non-existent

Skylight quality from now on (any higher setting or even default 16MB) looks great so no need to increase it, but Cast Shadow still bad; note drop by half in FPS

2 x previous shadow quality setting : Skylight looks same (as good) as before (no improvement), Cast Shadows still jagged, more FPS slowdown

Max quality allowed by Rhino UI Slider: Same Skylight look, still not crisp Cast Shadows, big FPS slowdown.

Same setting as above with Skylight Degradation set to 1/4 instead of 1/2. Most users will not find this in Advanced Settings, but helps with FPS and Skylight quality change is not noticeable

Quality doubled from Rhino UI slider maximum (via scripting or editing Display Mode ini file and reimport). Cast Shadows finally crisp!! But look at FPS - unusable, since Skylight kills the performance…Skylight looks the same as before but bogs down the display

Even reducing the Skylight Degradation to 1/4 at this Shadow Map size doesn’t help that much with FPS

At the same time, same 520 MB large ShadowMap is blazing fast with no Skylight (but who likes that look A.D.2020?)

Hope the above tests show the need for improvements in V7.
Here are some ideas and suggestions:

  1. Allow for higher Shadow Quality setting via Rhino UI (260 MB these days may not be enough). I understand this is a safety measure not to run out of video memory but maybe at least the max value can be defined in Advanced Options

  2. Allow for separate control of Skylight Shadow quality and Cast Shadow Quality. 2 Separate sliders, or some reduction factor for Skylight based on Cast Shadow map size.

  3. Optionally, allow for more Dynamic Display degradation of Skylight in Advanced Options (currently the lowest value 3 - 1/4 degradation, maybe up to 1/32?


Thanks @Jarek for the writeup. I agree with all your points.

I’ve made the following YouTrack items:



Hi David, great to hear and thanks for logging these items. I was trying hard to bring this up before you guys go into UI lock for V7 mode and tweaks like that would not be possible.



While preparing this test I realized TestMaxSpeed command doesn’t switch to degraded Skylight, which unless using a trick I did doesn’t produce valid measurement. Maybe that could be tweaked as well?

On the contrary…it produces very accurate results… Switching to some degraded mode is what produces inaccurate results. We need TestMaxSpeed to produce, constant, reproducible results… having a degraded mode kick in at random times doesn’t give us that.

That being said, there is an option to TestMaxSpeed that uses the “Dynamic” aspects of the view (i.e. what you get when you manipulate the view with the mouse)… But again, any results you get with that option are useless/pointless as far as collecting any kind of “benchmark”.


I think that your #1 should really be a percentage of the overall GPU memory…otherwise we’re just going to run into this again… However, even that is probably a bad idea since users will just max everything out because they just paid a lot of money for a new video card…right? :slight_smile:

Actually I think the best solution is this:

  • Shadow maps are just texture objects on the GPU
  • Texture objects have their limitations (undefinable by the program, and only determined by the drivers)
  • The slider will simply “max out” when the maximum texture size has been reached… Because Rhino can not physically go any larger than that, regardless of what the slider says or does.

I’m still a little reluctant to do that…because even low-end cards today support a maximum texture size of 32K x 32K… And with a 32bit depth buffer (which is what a shadow map really is), that equates to a 4GB shadow map.

Note: The 260MB current limit is really because Rhino is maxing out at 8K x 8K shadow map…which was exactly half of what the maximum supported texture size for most cards was at the time. If I change that to 16K x 16K, maybe that’ll suffice for now and even in the distant future… Not really sure atm.

I’m open to any suggestions here… We don’t want someone with a 4GB video card maxing out the shadow map size simply because they think they’ve paid enough money for their card, and it “should be able to handle it”… and they’re not really understanding what’s actually going on.



@Jarek Just curious… What is the maximum texture size reported in Rhino’s OpenGL page on your system?


Hi @jeff - the max texture size in listed in OpenGL info in Rhino options here is: 16384

So this was the maximum setting that when changed via scripting or editing DisplayMode ini file had any effect on shadow quality. Beyond that, system was working fine but just no quality improvement in shadows. So I think the upper limit for the shadows slider could be not measured by max memory but by maximum texture size, if it makes sense…
If Skylight quality was not getting in the way slowing it down, we would probably work on this highest setting, for now only use it to make screenshots.

Oh thanks - I did not realize the TestMaxSpeed has dash-version with more options. For my purpose testing it with DynamicDisplay on made more sense since the SkylightShadows - main bottleneck - degrade when rotating views… But in any way we test it results were clear that the Skylight looks great in much lower quality slider and bogs down display in values high enough for sharp cast shadows.

Just curious: in TestMaxSpeed, when DynamicDraw is enabled, there is another option: DynamicDowngrade? What does that do?
I can tell that Skylight gets degraded when rotating views but would love to know what else is being done in display to speed things up while rotating views… I am working on plugins that could take advantage of these speedups and while now I don’t think DynamicDisplay can be activated/deactivated via RhinoCommon, maybe at some point we will get there… Sorry I digress but your posts are always full of useful and detailed info…

RH-57802 and RH-57804 are fixed in the latest WIP

Great job @Jarek. I don’t have time nor knowledge to go deep into it but I would like to add my voice to the request of making shadows and display performance better.

Some performance tests

  • Latests WIP
  • CPU: i7-6820HK
  • GPU: GTX 1070 8GB (mobile)

Very simple scene. I would really like to write something else, but performance is bad.

testing file: test max speed.3dm (592.0 KB)

  1. Ground Plane On makes huge FPS drop

  2. Bigger memory usage - awful performance

hi @Czaja, I think once the above steps are implemented we should see a big performance boost with Skylight+Cast Shadows; you may try turning off Skylight and the performance should be super fast, even if you max out the shadow quality slider (note it has been increased in WIP recently). So as soon as the Skylight quality gets its own control, display should fly. My understanding is this is possible to implement, so now fingers crossed…


Hi All,

Looks like in the next WIP a big display speed improvement is coming up!

Following up on this topic where the idea was defined along with some tests, here are the results after implementing it. Please note that the V6 metric also applies to WIP prior to making this recent change.

This affects any display mode where Cast Shadows and Skylight Shadows were enabled together, which is pretty much the best look IMHO (except for Cycles). It directly impacts the performance of the default Rendered display mode too, even though to see full potential of this change you’d need to crank up the Cast Shadows quality.

  • V6 scene with Cast Shadows and Skylight in this test has double of the max shadow quality allowed by UI (512 MB) to achieve cast shadows as sharp as possible on vast models when looking at details (typical need for architectural work) - but by doing that skylight quality being tied to cast shadow quality makes it super slow.
    Speed =3 FPS (unusable)

  • WIP scene with Cast Shadow and Skylight has increased UI Max Cast Shadow setting of 1GB (2 x V6 above) for even sharper and more detailed Cast Shadows on closeups in vast models. The Skylight here is set to its own new default quality of 4 with is close to as good as it can get…
    And now the best part: Speed=60 FPS !

This is 2 x quality and 20(!) x speed improvement :slight_smile:

@DavidEranen, @jeff - thank you for having this implemented - this shows a huge speed and quality gain and makes a big difference for overall Rhino display experience.
@stevebaer - along with your V7 display speed improvements that were already visible in WIP prior to this change I think you guys have earned a major bragging rights for WIP display speed gains :grinning:


Hey @Jarek,

Something to look at… Any time I see or hear “60fps” I immediately think Vertical Retrace/Sync. If/when VSync is enabled, you will never get anything higher than 60fps…

So I’d be curious if things are even faster if VSync is disabled? Or is it already, and this is just a coincidence?


hi @jeff,

The FPS is real: meaning: the above test was done with VSync ENABLED in -TestMaxSpeed; (also it does use DynamicDisplay. The actual FPS reported was 59.8 FPS

If I disable VSync , with the same settings it reports 69 FPS.

If I go to SSAO quality 2 and 512 MB cast shadow (still 2 x Rhino 6 max), the DisabledVsync reports 101 FPS…

quite impressive gain : )

RH-57803 is fixed in the latest WIP