I was just wondering if it would be possible to expose the grid direction when setting up a simulation through the Rhino Environmental Analysis interface?
Vertical planar grids is something I test a lot and it would be amazing to have the option to have grids facing up (0.0.1)
Thanks, @byron .
Can you be more specific about what you mean here and why you want it? For something like a direct sun study, setting like the direction of a sensor normal to (0, 0, 1) is kinda meaningless given that all sun vectors are already pointing above the horizon.
Is this only for radiation studies or something like that?
Hi @chriswmackey ,
There are many cases where it is very useful for me to run a vertical grid to demonstrate distribution of solar access, solar radiation, or daylight (this is a different topic as not included in the Environmental Analysis tab) throughout a space, ie an atrium.
In GH I can manipulate all vectors to “look up” in my Honeybee runs.
For solar access or solar radiation, you have to simulate the surface twice, vectors facing either way, and then add up to get the total.
I guess, in the pollination method - through the Environmental Analysis - for solar studies, the Grid surface is also casting shadows? (same as in GH LB). If so, then what I am asking does not make sense.
If the creation of the grid though is only a point system, and does not include the surface as a “context”, then “facing up” could be very beneficial.
very simplistic example below.
Thanks for providing more information, @byron .
So, if I’m putting this request into my own words, you would like to have an option (just on the PO_DirectSun command for now) that allows you to toggle off whether the input geometry blocks the sun or not. So, when you toggle off the geometry-blocking behavior, you’re looking at the number of hours seen by each point in the geometry mesh rather than the number of hours seen by the Surface of the geometry (accounting for the direction that the surface geometry is pointing).
If so, then yea I think that’s useful and do-able.
Honestly, I have already been considering whether the LB Direct Sun component should get a new optional input for geo_block_, which works the exact same way as the input on the LB View Percent component works.
An input like this would make some things people have requested a lot easier. For example, the results could help Ladybug users make visualizations of only new shadows cast by a given geometry:
If you’re telling me you have more cases like this that would benefit from being able to turn off the geometry-blocking behavior, then let me implement something on the LB Direct Sun Hours component now. If you get the chance to test the Ladybug component and confirm that it gives you what you want, I’ll add it as an option on the PO_DirectSun command.
Hi @chriswmackey,
thank you for the answer. I think adding that option might be a very interesting idea even on the LB components.
As a side note, I find it very common to have to explain to students that geometry assigned as a grid is self shading and acts as context.
The issue will be with people forgetting then to add the surface as an actual context if needed, but if the setting (to remove the surface) remains optional, then I see no harm to longtime users.
Thanks, @byron ,
I added a new geo_block_ option to the LB Direct Sun Hours component:
… and you should be able to get it on your end with the LB Versioner now. If you confirm that it works the way you want it to, I’ll add a similar option into the PO_DirectSun command when I get the chance.
And I hear you with this:
Sometimes I get confused too and I have to remind myself that’s how the component works. But I at least know that this confusion is less common than if we had made the geometry transparent/non-blocking by default. Then, people go to run their study without any context and they see everywhere gets 100% sun. I think a new toggle option like this is the “right” way to expose this type of functionality.
@chriswmackey , it’s insane how fast you implement solutions these days…
I did a very quick test and overall it seems that it works as intended. On closer inspection though, I realise than there is a tiny difference when I flip the surface. In theory, the 2 results should be identical, irrespective of the surface’s normals.
edit: I just wanted to mention that the scale is fixed (0-12hrs), it does not show on my screenshots
Thanks @byron ,
I know why that is happening. It’s because of the _offset_dist_. The sensor points are in slightly different locations depending on the direction of the input geometry. It makes sense that this is not what you’re expecting so I just changed the component to use a default _offset_dist_ of zero whenever geo_block_ is set to False. When it’s True or unspecified, it will use the default 10 cm as it usually does.
I also realized that my interpretation of the input wasn’t great since it follows intuitively that setting geo_block_ to True should mean that the geometry blocks the sun while setting it to False means that the geometry is transparent. I originally had it reversed. I fixed all of this here:
Now, you get the same result when you flip the geometry:
Good catch @chriswmackey , and silly of me for not thinking about it… It’s good that I did not manually set the offset to 0 as I would have not picked up the difference.
thanks again for being so quick to add the feature and fixing it.
And thanks for this 
I just have to give a disclaimer that updating the Environmental Analysis commands is going to be slower. For the LBT components, I have a whole nice automated set of workflows that run to push the changes out to you. I’m still in the process of setting this up for the Environmental Analysis commands but I’ll get there.
haha not a problem.
I am sure we can all excuse a few days’ wait to get new functionalities.
