Rendered Mode development

After some time without rendering anything in Rhino (maybe about 8 months?), I took a look at it again.
First of all, the Rendered mode looks so much better for me than what I was used to. I don’t know if it is because I was using V-Ray in the past and the materials were not previewing correctly (v-ray doesn’t care about some useful Rhino features, so that would be no surprise) or there was some development done?

Anyway, previewing scene in Rendered mode is much more eye-pleasing now, thank you for all the work!

To not make it all sweet, I need to mention about huge viewport performance drop if there is an Ambient Occlusion texture turned on in the material.

1 Like


Are you talking about the Physically Based material in Rhino WIP?

  • Andy

Yes, this one.

Hi @Czaja,

Thanks for the report - we’re actually aware of this but we didn’t have a YouTrack item for it yet, so I created one:


1 Like

I have an issue with selecting geometry in Rendered mode - there is a huge lag between click and selection.

Scene has around 400k polygons and uses 4k textures.

UI also acts very slow.

Hi @Czaja,

Can you give a link to the model so that we can take a look?


Can I send it somewhere? For some reason file is quite heavy. - 415 MB :grimacing: Also, it contains paid textures so I shouldn’t upload it publicly

You can use to upload confidential files and @DavidEranen will get an automatic notification when the upload has been completed. For completeness do add a copy of the link to this discussion in the comments section.

Hi, you don’t have to look into it now but please confirm if you received it. :slight_smile:

Another thing is how shadows sometimes look right now.

They are very far from the geometry edges.
Any slider-playing inside properties of Rendered mode isn’t helping.

I would be happy if user could quickly set up sun & shadows to the point where a good approximation of real-world shading scenario is shown on the screen.

As you probably know there are regulations in building law about minimal sun hours exposition of building windows. Many times this is one of the most important things in the project.
Of course we can use Ladybug or other, simpler GH approaches to receive precise results but it is overkill to use it just for a quick check.

So, the possibility to set shadows the way that we receive not pretty, maybe even performance heavy but quite sharp and precise shadows would be extremely helpful to all people working with architecture inside Rhino. There are quite a few users like that :wink:

Performance given from shadows from default Rhino hdri map is very, very low.

1 Like

I am curious if this issue (mis-aligned shadows) will be addressed in the Rhino WIP? I am developing work-arounds using duplicate display modes, one for modeling, the 2nd for image output (where cycles are switched ‘on’). Super annoying that the shadows do not land at the corners of the geometry.

Try selecting the ground plane and deactivate *cast shadows * on the properties panel, depending on your scene this might solve the problem.

Kevon -

Is there a simple file we can use to test this? We can run it on a few machiens and see how it compares to your results.

Shadows calculated in a Rendered mode are always going to be somewhat different from a raytrace mode. The difference is how they are calculated from a ray point of view or a made up OpenGL shadow,

Thanks @jespizua. Deactivating “cast shadows” improves the result by 50%.
I will post a reply to Scott and see if they can review the settings.

Hi @scottd, Thanks for your reply. I would love to have your perspective on this because we have been looking at it for months. We first thought is was an origin thing but the corner in this image is at (40.346,-32.373,0).

My test model and Display modes are attached. Hamburg Style(1) is using cycles on the Realtime display engine. Note the result in the screenshot:

ShadingTestModel.3dm (2.4 MB) Hamburg Style(1).ini (11.4 KB) Hamburg Style.ini (11.4 KB)

Yeah, I see it has to do with the size of the shadow map resolution.

The Video Memory Usage has a maximum resolution setting that produces sharper shadows. This small offset at the corner is due to the next point of the map is actually in light. Essentially it is making the transition from light to dark there.

I guess the question becomes is there a hard limit on the shadow map resolution? Is using OpenGL shadow maps the best way to represent shadows? Hmm. I will do some research on this.

Obviously the Raytrace Cycles shadow calculation avoids this by ray tracing the shadows:

Hi @kevin3,
I recommend you to read this topic to know more about this limitation and why it is happening.

1 Like

@scottd, thanks for looking into this further. @jespizua , your link was super informative and the limited cast-shadow selection strategy is very helpful for small areas.

It might be worth noting that this result is super prominent when rendering an architectural facade elevation and nearly impossible to work around with a tall building (for example, thousands of objects in 20 stories, and more articulation in the facade = more shadows to map).

When detailed drawings are made for graphical images (cross between technical and rendered imagery), the team draws the shadow edges manually in another software; not fun.

We did some looking into this still not sure it is fixable. But, we did notice if you click on the ground plane surface, then under Object Properties and Un-check Cast Shadows. This removes the ground plane object from the shadow casting and reduces the size of the shadow offset in the corner. Perhaps this will work?

Thanks again for checking out the subject in more depth. I also noticed that ground plane selection affects the result. Jespizua’s tips are also helpful, by limiting the geometry to calculate. It comes down to acceptable resolution for the final size (of architectural drawing).

I often encounter resistance to Rhino’s imprecise shadows for presentation architectural drawings, especially when neighboring geometry is involved. For example, _Silhouette will give an accurate shadow projection to the ground plane but ignores adjacent geometry; and Ladybug tools output low-res bit maps (that is, without extended time to calculate the map); rendering a Raytrace Cycles often gives a good result, but the graphic style of the geometry is often very different.

I wonder if the _Silhouette command could be adapted to engage neighboring geometry, including 3D ground surfaces? In this way, the shadow lines can be ‘flattened’ with Make2D from Top view, hatched, and used as a graphic overlay on a 2D plan.

The idea of using a projection to create vector shadow outlines is an interesting one. And on flat ground it makes a lot of sense. But what happens if the building is sitting on a mesh topology? Or if a shadow hits and adjacent building. Sometimes it is not even planar results?

I don’t now if it makes sense as a general purpose tool?

1 Like