Sun Hours Analysis rendering glitch

[nazmeevaa]

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.

[charlie.brooker]

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).

[chris]

@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.

[charlie.brooker]

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

    # 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

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.

[chris]

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.

[charlie.brooker]

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

[chris]

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

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!