Rendered Mode development

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

Grasshopper has the component ‘MShadow’ (MeshShadow). With it you can create a vector drop shadow on a given plane.


So, this thing exists. However, it would be nicer to have it somehow integrated in the display pipeline, without having to fumble with Grasshopper.

Yes, that may work well.

Perhaps, in the short run, this might be a good test for the Grasshopper Player.

What do you think a command would prompt?
Would the results be baked on a layer as vector fills?

Or does color of the fill just follow the layer it is baked on?

I guess the limit with MShadow is that it is only on a single plane. It would not shade on adjacent buildings or any topography.

Would the results be baked on a layer as vector fills?

Yes… I assume vector fills are _hatches. Hatches are very versatile for exporting and in WIP now have gradient options.

I guess the limit with MShadow is that it is only on a single plane. It would not shade on adjacent buildings or any topography.

Agreed. This is a huge consideration… Adjacent objects and topography are critical for design evaluation (in architecture at least).