You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@ryanxwelch has developed a geometric view factor calculation that we've been using internally at @KieranTimberlake. Although we think it may be more geometrically limited, this method should be quite a bit faster than the existing view factor calculation method in the Honeybee_Indoor View Factor Calculator component because it doesn't rely on ray-tracing. So as discussed with Mostapha and Chris we're going to try and integrate it as an alternative calculation option in the existing component.
@ryanxwelch can provide more detail as needed, but to give a general overview of what's proposed - the calculation and visualization method he developed skips ray tracing by reducing the number of surfaces to be analyzed (as a function of inverse square of distance from viewpoint), and then calculates the view factor as the dot product of the mesh face normal and vector from the viewpoint sphere. @chriswmackey has noted that the procedure may not be able to handle, or become computationally prohibitive to process non-planar surfaces, concave zone geometry, or where the view to one surface blocks another. This entails catching and warning users of the geometry inputs that would trigger these conditions.
Next Steps:
Translate Ryan's view factor code/grasshopper script to python.
Resolve non-planar edge case, by either checking for non-planar surfaces or meshing surfaces.
Test and resolve concave edge case (possibly use @devngc's Honeybee_Find Non-Convex).
Test and resolve edge case where surface blocks another surface.
Integrate into existing component (if possible)
Possible option: include way to extend viewfactor outside to sky mesh.
Possible option: include way to extract material data from HB_Surfaces or HB_Zones to weigh view factor by emissivities for more precise mean radiant temperature calculation.
The text was updated successfully, but these errors were encountered:
I just wanted to reiterate what I mentioned in the email a while back, which is that I can see this as very helpful for certain situations. I recommend getting this stable as it's own component and then we can start merging it into existing workflows.
Thanks Chris, we have made progress on this calculation: master...ryanxwelch:master; and are working on scheduling some time in our busy work schedules to finish off the first implementation. We'll hopefully have some form of a PR soon.
@ryanxwelch has developed a geometric view factor calculation that we've been using internally at @KieranTimberlake. Although we think it may be more geometrically limited, this method should be quite a bit faster than the existing view factor calculation method in the
Honeybee_Indoor View Factor Calculator
component because it doesn't rely on ray-tracing. So as discussed with Mostapha and Chris we're going to try and integrate it as an alternative calculation option in the existing component.@ryanxwelch can provide more detail as needed, but to give a general overview of what's proposed - the calculation and visualization method he developed skips ray tracing by reducing the number of surfaces to be analyzed (as a function of inverse square of distance from viewpoint), and then calculates the view factor as the dot product of the mesh face normal and vector from the viewpoint sphere. @chriswmackey has noted that the procedure may not be able to handle, or become computationally prohibitive to process non-planar surfaces, concave zone geometry, or where the view to one surface blocks another. This entails catching and warning users of the geometry inputs that would trigger these conditions.
Next Steps:
Honeybee_Find Non-Convex
).HB_Surfaces
orHB_Zones
to weigh view factor by emissivities for more precise mean radiant temperature calculation.The text was updated successfully, but these errors were encountered: