I was wondering if the min-max shadow map size setting for DisplayModes is the same on all systems, or depends on the video card somehow as well? In all systems I have access to it looks the same but they are quite similar, so curious if everyone has the same range available for shadow quality ( 16 Kb - 260 Mb )
It’s hard coded. I guess I could make it a percentage of the overall GPU memory… I just don’t want people blowing out their GPU memory because their shadows are a little better…but then everything else is toast.
Are you finding that 260MB for your shadow maps is still not enough?
Jeff - thanks for confirming that. I think the range is good as-is, considering the security measure not to let users accidentally blow up the video memory.
I needed this info for a plugin where as a part of functionality I can toggle between low quality and high-quality shadows quickly to control the display speed.
In general with Rhino 6 I am struggling to find a good balance of quality and speed in Render mode, when using both Skylight and Sun cast shadows. At the high/highest quality, when using both, the view speed reduction is quite significant and moving around the vport is not smooth anymore.
At the same time, whether it is Skylight-only, or Sun-Shadows only (high-quality), the speed is still blazing fast.
Of course the best look is when both are ON. But in general visually lower Skylight quality is much more passable than low cast shadow quality. In ideal world we should be able to have grainy Skylight effect for speed (that still adds a lot of “meat” to the view) but sharp-edged shadows from high-quality cast-shadow setting. I wonder if such combination is possible and if it would result with a lot of speed gain.
We would only care about super-smooth Skylight for screencaptures; a bit grainy for navigation is fine.
I was suggesting making two separate controls for Skylight and Cast Shadow quality earlier in Beta, not even knowing the speed slowdown effect now tested and described above. Now it comes up again with more thorough testing on real-life projects in V6.
@Andy, @DavidEranen - in case you see this, any ideas how to marry good quality cast shadows with Skylight that doesn’t slow down the display too much?
Sorry for reviving a dead thread. @jeff It would be incredibly useful to override the 260MB limit on shadow maps on more powerful systems with modern GPU’s. The real-time shadows in Rendered display mode are just such a handy piece of instantaneous feedback, but they can easily look grainy on larger scenes, and I frequently have to adjust the clipping bubble to improve them.
Are there any numbers I can change in the Advanced section of the Rhino settings menu?
(My usage case is modelling Architectural shade devices. I’ve just been deep diving through the Rhino6 display settings trying to wring more performance out of my display modes with my GTX1060)
I agree it would be handy to have higher values exposed in the UI (maybe only in advanced options) to take advantage of the high end video cards.
In the meantime, you can try this small script - it should let you set custom size of the shadow map beyond the UI setting:
if you look at the script code, it is using 16512 as the shadow value, which translates to double the size allowed by Rhino UI. I use this one as highest setting since it is close to the max texture size my video card allows (listed under Rhino Options > View ? OpenGL settings ) here :
if you have better card/larger texture size allowed, you can experiment with changing the number in the script. To get back to lower quality, just use Rhino UI.
Thank you so much. That’s such an amazing help. With your script, I’ve boosted the shadow map up to 21,696 with good results, but the value you set is a little faster. The shadows are so sharp, this is brilliant, thanks.
It would be great if Rhino could scale the shadow clipping radius dynamically depending on the distance from the camera target for large scenes (like having different levels of detail in depending on scale in Google maps). It could be set to generate a detailed shadow map when up the camera is at the zoom level defined as ‘close’, and then a less detailed one when further away. Maybe this could be based on starting template/accuracy. That would probably get the best balance of performance and detail from real-time shadows.
good to see it works on your end. Here is a tip regarding the performance - I bet if you don’t use the Skylight shadows (AO), the display performance is very fast with just cast shadows, even with your highest map setting (at least that’s the case here). It is the Skylight shadows that slow things down with higher shadow map value settings. Obviously things look best when both types of shadows are enabled. The problem is, the Skylight shadows and Cast Shadows use the same setting for quality, even though much lower values of Skylight work quite well, but when you try to achieve sharp edges cast shadows and ramp up the map size, it bogs down the display because Skylight map is also ramped up, which is not noticeable in display quality, but only in slower performance. Currently there is not that much that can be done about this except for one small setting:
You can try Options > Advanced and find Rhino.Options.OpenGL.SkylightShadowResolutionScaleDynamic, and set it to 3 (instead of default 2):
What it does is it tells Rhino to use 1/4 of the Shadow Map size to generate the Skylight shadows. It can help a bit to alleviate the effect of ramping up the map size for sharp cast shadows.
You can see the explanation for these values (1,2 or 3) here:
Maybe that helps a bit on your end.
@andy, @DavidEranen, @jeff - this is another example of what I was bringing up several times regarding the display performance and shadows. Hope you agree there is some room for improvement:
with the newer video cards, the shadow map quality cap may be too low now. If not in main slider, maybe the upper value can be exposed in Advanced Options for users to type any number they want? Or Rhino to cap it there at the maximum supported texture size per-system?
Ramping up the shadow quality is used to achieve sharp edge shadows on larger scale models (always the case in architecture). The shadow bubble often doesn’t cut it and is also cumbersome to use. High quality cast shadows on their own look great and display is fast, but as stated above, having them and Skylight shadows together causes the display to slow down a lot, due to Skylight being slow with very high shadow map sizes, with no noticeable Skylight quality improvement. Basically Skylight looks good with much lower values. At the same time both shadow types enabled give us the best look, so we need to find a way to have them both work well.
Ideal solution would be having separate Shadow Quality slider for Skylight and Cast Shadows. That would give users full control of the look vs. display performance. My understanding from past talk with David E is that under the hood these two are separated and it’s only current UI that connects them. Would you consider separate controls for there before it’s too late in V7 (UI lock?)
The workaround I suggested to Patt (using lower dynamic display Skylight map degradation value) somehow helps, but with ramping up the map sizes a lot, 1/4 degradation is still not enough. @DavidEranen - would it be possible to enable steps 4 or 5 (1/8 and 1/16) or even 1/32 for Dynamic Display degradation in Advanced Options? If we have separate shadows sliders, there would be no need for this, but if not, this could be a life-saver. The problem with this method is that it is global, not per-display mode, so other display modes that use skylight shadows and lower values can suffer and we would need to switch this setting back-and forth; so separate sliders per-display mode would be better IMHO.
Hope this is reasonable and you can consider these suggestions.
Thanks for that tweak, display performance is faster with no noticeable loss of quality when adjusting SkylightShadowScaleDynamic. And turning off the skylight all-together was a fantastic speed boost - vector like shadows go a long way in convincing some in the Architecture community that Rhino may be more viable and useful than SketchUp, as insane as that sounds (now if only we could get a few tweaks to the walkthrough tools).
Yes, the current clipping bubble seems a bit clunky and unintuitive. It would be great to have an option to set it to ‘Auto’ mode to set it based on a distance from Camera target (with a few brackets eg factor of 10 or factor of 3).
I’d second a call for a separate slider for Skylight shadows and Sun Shadows, it seems like that would really boost the capabilities of the Rendered viewport mode without adding much to the complexity from the user’s side. (And while we’re at it, a variable slider for ambient occlusion diameter, to add on to the wishlist ). Thanks for the tips, I love the community around Rhino.
What version of Rhino are you on? If 7, that script is not useful anymore since Rhino 7 allows for much higher map size via UI, which was limited in older versions and only available through that trick.
Otherwise it is probably possible to convert the script to python (or write similar that just changes the display mode shadow map size) but unfortunately I will not be able to help with that in the near future.
Ah! Found another one of your posts where you can override the value in the display.ini export, (could bump it up to 3300mb) which made it look a little better, buuuut isn’t practical and I assume will create stability issues. Guess I’ll just have to do proper renders for decent hard shadow shots.
Assuming you maxed out the shadow map size/quality slider in the display mode, there are a couple of other things to look at to possibly improve.
Rhino shadows will never be as sharp as Sketchup since they use shadow map and not vectror, so the more you zoom in, the more pixelated they are.
However, they are calculated based on the overall visible scene bouding box, so if you have some objects very far from where you are looking at, this affects the quality. So I would look for that in the first place, try to make the model as “small” (not vast) as possible.
Another thing to try is objects that don’t “casts” shadow don’t contribute to the size of the shadow map, so for example if you have a scene with a large ground plane that only needs to receive shadows but not cast, try in its properties unchecking “Cast Shadows” and only use “Receive”, this may help.
Last resort could be using the display mode’s “Camera-Based Clipping Bubble” slider, but it is not very convernient - view based, depends on the camera target distance that is not obvious for most users where it actually is and keep changing on its own while navigating the view in most cases, and overall pretty bad workaround, I would not say it is not very useful in real-life production workflow.
Hope that helps, V7 shadow map size improved a lot, but also may be limited by your video card memory, not sure if all cards can handle the max map size the slider allows.
of course you can experiment with that but I find that V7 max UI shadow map value (1GB) works very well for sharp shadows in quite large scenes. Of course if you have model of a few blocks of a city and try to zoom in to the base of a chair, this will not work well for shadows quality if you keep all objects on, only way is the dreaded camera clipping bubble…
awesome! thanks for the tips, I’ll give them a whirl. I think you’re right about it being contingent on the specific GPU I have got an M1 mac (16GB) which doesn’t have dedicated GPU ram so it might be a little more conservative.
True, when I had it turned on for the first time I thought I had some kind of display bugs. If one understands how it works it may be possible to control its behavior but as you said it’s rather inconvenient.
Last video of this post - rather unexpected behavior of camera clipping bubble
Maybe Rhino should have Cascaded Shadow Maps? Or some other, modern solution.