Incorrect top view shadows

Take a look at the screenshot, the top view looks like if it would be a flying plane instead of a cube resting on the ground. I’m using the sun as light source.

Doing a quick render shows it correctly

incorrect shadow.3dm (2.8 MB)

Something is weird here.
If I run Zoom Extents, the shadow is recalculated.

Thanks John, you are right that for this particular case running ZoomExtents fix the problem, but I’m still seeing problems with shadows. If I move the sun to get a more long shadow, look what happens. Running ZoomExtents does not fix the problem here.
Screenshot 2020-06-30 at 06.46.20

Of course using the renderer gives correct results

incorrect long shadow.3dm (2.8 MB)

Is it just me? Here is my system info.
SystemInfo.txt (5.4 KB)


Thanks for reporting, I created a YouTrack item that you can follow:


Thanks David for taking a look.


From what I’m seeing here, this is just the adjustment you get due to the self-shadowing issues involved with “Shadow mapping”. In order to make sure that an object does not cast a shadow onto itself, the shadow map (depth buffer) is biased a little towards the camera…the end result is that certain shadows in certain conditions will appear to be a bit too far in front of the object that’s casting the shadow.

Again, Rhino uses “Shadow mapping” to produce its real-time shadows…not projected shadows, or any of the other techniques out there (which all suffer from some kind of side-effect of some sort). Because of that, there are certain limitations and restrictions that exist. I think it’s a pretty unfair comparison to attempt to compare a raytraced result with a capture of Rhino’s rendered viewport…Do you really expect real-time results to match raytraced results?

That being said… I would try tweaking the Shadow settings in your display mode…specifically the “Self-shadowing artifacts” setting… Try sliding that all the way to the left (maybe one tick shy of the left)… Then turn off Soft Shadows, and try compensating for the loss of soft shadows by increasing the Edge Blurring. … All of these settings attempt to mitigate the shortcomings of Shadow Mapping…but you will never get perfect results…nor should you expect perfect results… That’s what raytracers are for.

I will look to see if perhaps there are better default settings that can be defined so that something like your simple example works out of the box.


Looking at this further, it appears this is a special case that is causing the light frustum calculations to be too tight… If you simply add one more box to the scene, everything looks a lot better. The problem is still related to the self-shadowing adjustments I mentioned, but those adjustments are based on what’s in the scene, and what can be “seen” by a given light source. Apparently a single box causes a bit too tight of a viewing frustum…which I’ll see if I can tweak.

But again, self-shadowing adjustments will eventually creep into the results, and produce “offset” shadows to appear…that’s just how things are and how Rhino’s current shadow mapping works.


Here’s an example where self-shadowing adjustments still have unwanted results… There’s another box off to the left in the distance… and this image shows the result using Rendered mode default settings…

If I delete the box (that you can’t see), then the shadows all line up… However, if I don’t delete it, and instead, make some tweaks to the Shadows settings (as I mentioned above), this is the result…

…still not perfect, but certainly a lot better. I will look into changing some of the defaults… The current defaults were/are based on what the “average” hardware was doing at the time (which was the V5 time frame)…obviously hardware is vastly different today, and can allow for higher settings.

So to clarify…

This is the scene with the box in the distance (it’s what causes the light’s frustum and depth calculations to change)… and this is using the current default settings…

Tweaking the Shadows settings… I’m probably going to change the defaults so that it now looks like this…

Note: The differences around the corners of each of the boxes.


I just realized that Mac Rhino is what is being used here…and the results are somewhat different… The soft shadow adjustments are causing their own set of problems and just adding to the self-shadowing problem…But I can still get better results by changing/tweaking the Shadows settings…

Note: This is now using Mac Rhino…

Before (defaults):

After tweaks (potentially new defaults):

1 Like

Hi Jeff,

Thanks a lot for taking the time to give me such an in-depth explanation of the issues, I really appreciate it.

No, I was just trying to make sure that there wasn’t any thing else causing this. In the beginning I thought that this could be related to casting shadows on the ground plane so I tried with a custom plane as the ground and deactivated cast shadows on it but nothing improved. I also wanted to make sure that this wasn’t due to my graphic card.

The most important thing related to shadows for my needs is clean and precise shadow silhouettes. I understand that if I need more real world-photorealistic shadows I should be using Raytrace. The thing is that display modes are so great and versatile that I try to use them most of the time but when it comes to shadows I experience many issues, and I know from having read lots of your posts, that this is expected due to the shadow mapping limitations. I just wanted to make sure that we have the best we can.

I think this is looking really good. One difference I see between Mac and Windows result here, is that the Mac one has a white halo around the corners, why is that? but I’m most that happy to have that as the default.


RH-59336 is fixed in the latest WIP

Hi @Jeff

I just checked the latest WIP and I see great improvement over the previous one when having multiple objects in scene, with one object I still see the same problem though. I run a few test similar to yours on my system and this is what I get.

Just one object

Multiple objects, all of them within camera field of view.

Multiple objects, some of them outside camera field of view.

Now that I know how it works, I will try to make sure to hide all objects out of the camera view, in architecture this might not be possible sometimes though, like when you have a main building surrounded by existing ones and you just need to show part of them to contextualise the location.


@jespizua Apologies, this item was marked as fixed by mistake. The bug is still there…


No worries, thanks for confirming.