# Sun Hours Analysis rendering glitch

**URL:** <https://discourse.ladybug.tools/t/sun-hours-analysis-rendering-glitch/19256>\
**Category:** ladybug\
**Created:** [August 12, 2022, 6:06pm UTC](https://discourse.ladybug.tools/t/sun-hours-analysis-rendering-glitch/19256 "2022-08-12T18:06:14Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![nazmeevaa](https://discourse.ladybug.tools/letter_avatar_proxy/v4/letter/n/3be4f8/32.png) [@nazmeevaa](https://discourse.ladybug.tools/u/nazmeevaa)\
**Post date:** [August 12, 2022, 6:06pm UTC](https://discourse.ladybug.tools/t/sun-hours-analysis-rendering-glitch/19256/1 "2022-08-12T18:06:14Z")

</div>

Hi All,

I am working on sun hours analysis to see how many hours of direct sun is available in public spaces. Working with a simple flat surface works just fine, but when I use actual terrain it has many “artifact”-like looking parts.

I tried to simplify geometry, quadro-remeshed the mesh and tried to use Mesh2Surface plugin, but even with these adjustments the final result looks “patchy”. I am not sure what causes it and what are the ways to fix it.

 ![image](https://discourse.ladybug.tools/uploads/default/original/3X/2/1/2187c55755facdfcdff154b2140bb616e54d905d.jpeg)

---

<div class="post-metadata">

**Author:** ![charlie.brooker](https://discourse.ladybug.tools/user_avatar/discourse.ladybug.tools/charlie.brooker/32/27164_2.png) [@charlie.brooker](https://discourse.ladybug.tools/u/charlie.brooker)\
**Post date:** [August 12, 2022, 10:02pm UTC](https://discourse.ladybug.tools/t/sun-hours-analysis-rendering-glitch/19256/2 "2022-08-12T22:02:51Z")

</div>

Hi @nazmeevaa,

I think this is the same issue I’ve experienced in the past where the LBT remeshing that goes on to produce the analysis mesh and points results in points that fall beneath the input geometry.

Something that’s worked for me in the past is to use the LB Generate Point Grid component to create my analysis mesh first, then input that into the Sun Hours or Incident Irradiation components instead. Then the original geometry and remeshed analysis mesh won’t have that same interaction issue.

Alternatively you can probably just increase the offset distance to avoid this interaction that way.

@chris I’d be interested to get your take on this - I have wondered if it would be worth tweaking the code to avoid this (although I haven’t actually looked at the code to see if that’s already being captured in some way).

---

<div class="post-metadata">

**Author:** ![chris](https://discourse.ladybug.tools/user_avatar/discourse.ladybug.tools/chris/32/10179_2.png) [@chris](https://discourse.ladybug.tools/u/chris)\
**Post date:** [August 30, 2022, 12:43pm UTC](https://discourse.ladybug.tools/t/sun-hours-analysis-rendering-glitch/19256/3 "2022-08-30T12:43:01Z")

</div>

> [@charlie.brooker](#):
>
> the LBT remeshing that goes on to produce the analysis mesh and points results in points that fall beneath the input geometry.

Yes, I think this is the likely explanation.

> [@charlie.brooker](#):
>
> you can probably just increase the offset distance to avoid this interaction that way.

This is the way that I would recommend addressing this. There isn’t really a good default for this since you usually want to be a close as possible to the surface without going beneath it. This is invariably going to be different for different geometries.

---

<div class="post-metadata">

**Author:** ![charlie.brooker](https://discourse.ladybug.tools/user_avatar/discourse.ladybug.tools/charlie.brooker/32/27164_2.png) [@charlie.brooker](https://discourse.ladybug.tools/u/charlie.brooker)\
**Post date:** [August 30, 2022, 3:50pm UTC](https://discourse.ladybug.tools/t/sun-hours-analysis-rendering-glitch/19256/4 "2022-08-30T15:50:27Z")

</div>

Thanks Chris, I just had a look at the code for this

```auto
    # create the gridded mesh from the geometry
    study_mesh = to_joined_gridded_mesh3d(_geometry, _grid_size)
    points = [from_point3d(pt.move(vec * _offset_dist_)) for pt, vec in
              zip(study_mesh.face_centroids, study_mesh.face_normals)]
    hide_output(ghenv.Component, 1)

    # mesh the geometry and context
    shade_mesh = join_geometry_to_mesh(_geometry + context_)

```

My thinking is that if you change the above to

```auto
shade_mesh = join_geometry_to_mesh(from_mesh3d(study_mesh) + context)

```

That might help avoid some conflict between the shade\_mesh and the study\_mesh.

I’ve had a few people message me about this as an issue in my company recently which makes me keen to help come up with a way to minimise it happening.

---

<div class="post-metadata">

**Author:** ![chris](https://discourse.ladybug.tools/user_avatar/discourse.ladybug.tools/chris/32/10179_2.png) [@chris](https://discourse.ladybug.tools/u/chris)\
**Post date:** [August 31, 2022, 3:26pm UTC](https://discourse.ladybug.tools/t/sun-hours-analysis-rendering-glitch/19256/5 "2022-08-31T15:26:19Z")

</div>

Thanks @charlie.brooker ,

I can definitely see why reusing the study mesh in the shade calculation would result in fewer cases of curved geometry blocking the sensors. I think I’d just want to be sure that this doesn’t affect the performance of the calculation significantly and, if so, we can implement this change.

---

<div class="post-metadata">

**Author:** ![charlie.brooker](https://discourse.ladybug.tools/user_avatar/discourse.ladybug.tools/charlie.brooker/32/27164_2.png) [@charlie.brooker](https://discourse.ladybug.tools/u/charlie.brooker)\
**Post date:** [August 31, 2022, 9:36pm UTC](https://discourse.ladybug.tools/t/sun-hours-analysis-rendering-glitch/19256/6 "2022-08-31T21:36:01Z")

</div>

Sounds good @chris

Appreciate this would be low priority - I’ll try to remember to come up with a few tests next week when I’m back at work from leave to see if that change would be an improvement or not, and any impact on performance

---

<div class="post-metadata">

**Author:** ![chris](https://discourse.ladybug.tools/user_avatar/discourse.ladybug.tools/chris/32/10179_2.png) [@chris](https://discourse.ladybug.tools/u/chris)\
**Post date:** [October 5, 2024, 12:40am UTC](https://discourse.ladybug.tools/t/sun-hours-analysis-rendering-glitch/19256/7 "2024-10-05T00:40:32Z")

</div>

FYI, @charlie.brooker . I realize that it’s 2 years later but I finally implemented your suggestion:

> [@Problem with concave surfaces using the DirectSunHours component](https://discourse.ladybug.tools/t/problem-with-concave-surfaces-using-the-directsunhours-component/34735/3):
>
> Thanks for trying to answer this, @mostapha, but a smaller \_grid\_size will only make this situation worse. I think what you were trying to say is “increase the \_offset\_dist\_,” which is how we have traditionally handled the fact that some of the sensor points end up behind the study geometry and get blocked. Increasing the \_offset\_dist\_ is a proven way to get a more sensical result no matter the version of Ladybug that you are using. With all of this said, @charlie.brooker actually came up with …

Sorry for not doing it sooner!