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.
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).
Yes, I think this is the likely explanation.
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.
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
# 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.
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.
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