So I need to get the shadow of the context buildings on each other as one output and then as you can see there’s a lighter color area which is the shadow created by the proposed geometry in the center.
I have tried using sunlight hours however putting a low grid size takes way too long and I can’t get just the shadow of the proposed building either. What I have been trying to do so far, I input the base surface, the context buildings and the proposed building into geometry input of ‘Direct Sunlight Hours’ and leave context input empty and that gives something similar but I can’t isolate just the proposed building shadow. I understand there used to be a legacy shadow plugin which used to do something similar but it doesn’t really work and is unstable. Is there a better workflow maybe using something like ‘Mesh Shadow’ component?
Both Legacy Ladybug and LBT Ladybug have components that run relatively quick shadow studies using Rhino’s built in renderer and your GPU. In LBT, this is done with the LB Set Rhino Sun component. It’s much faster than than the LB Direct Sun Hours component as long as you don’t max out your GPU’s capabilities (you’ll see your screen start to freeze if you do). Also, here are a lot of improvements to the workflow in the LBT version compared to Legacy, including the ability to see multiple shadows at once. So that’s what you should use if you need something fast to just show you the shadows and you aren’t trying to do a custom analysis that is highly specific.
In your case, pulling out the shadow effect of a single building is highly-specific and it’s really challenging to do this with any type of GPU-based workflow, even if you have a CS degree. So you’ll need to go with the LB Direct Sun Hours component for this case.
By tweaking a couple of lines of code in the component, I can get to run a shadow study where only the context_ blocks the sun and not the _geometry:
In theory, yes. But let me think about what it should be called since it’s not the same as what geo_block means for the “Direct Sun Hours” and the “View Percent” components.
Unlike hours or percent, Radiation has the units of kWh/m2 so it has to be in the plane of a Surface. And, if it’s not the Surface of the input geometry, then it’s something else. So it’s not really as simple as saying “the _geometry blocks the view or not.”
I guess you’re telling me that this is a case where you want to use normal vectors that are always facing up? Is that right @Byron .
In that case, maybe the “Incident Radiation” component should just have an input for direction_. When you specify it, the _geometry becomes transparent and all radiation is evaluated in the plane of that direction_. When it’s unspecified, we use the direction of the geometry_ and treat the geometry_ as opaque. What do you think?
Yes I understand what you mean. In my head it was more simple, as I had the “always facing up” vectors in mind, but you are right, the geo_block might be confusing as an input and can lead to very wrong results.
Equally though, I think that the direction_ will not be very intuitive as an input, especially if you have to override the _offset_dist_ to be 0 as in the new LB Direct Sun Hours you created.
Of the two, yours is a better choice for sure and it is a clever idea. I just don’t want to create confusion just to satisfy my selfish request.
