I am using exploded breps as inputs. I get one radiation mesh still but the radiation results are branched. So at first I tried to map the values with colors and represent the value with lines/ circles - just to start out. I tried to branch the values by what face they are on, using the data structure of the radiation results or by finding similar values between the radiation results and the color values on mesh vertices. However, handling 100k points with find similar poses challenge. I dont think it runs fast enough.
But now that I think about it, since the test points are branched and so are the radiation results , so I thought I am set there if I just use exploded breps as inputs to test an idea of interpreting radiation results for outlining embedded functional aspects to detail semi unitized facade components.
I am particularly interested in designing facade components using solar radiation to create a spectrum of thermal distribution between South/West and Northern facades, and between vertical facades and overhangs in order to draw natural ventilation across the floor plates during the summer and in the winter have the facade components work as efficient thermal break/ micro winter gardens / heat collectors.
At any rate, I would need face normals for most cases so I thought I could get the normals from mesh vertices.
But as it turns out the testing points are not the same as the mesh vertices. The testing points are center points of the mesh faces. but no problem, I could just evaluate mesh and get normals in branches that way. easy.
Now the issue however, is that the points are in branches, but they are not necessarily in an order that is useful. It is because there are triangle and square faces mixed. for this one brep face, the algorithm created two triangular wedges that when in as a list of points, it is either listed in the beginning or the end of the points. so - if you read the polyline of the points, you see first the polyline skips the mid row, and anyways, you can see there is a problem with the way I’m using exploded breps as inputs although it would be the easiest way to organize and branch the testing points, the radiation result values, and the face normals.
So alternatively I could mesh the breps first, then use the meshing pattern to unflatten the… radiation mesh? I dont know what you I mean, I have to try it myself. If I can control the way the brep is meshed, and then It might be possible for me to also have a consistent logic of how test points are organized… which I think is really crucial to work with the radiation results. For example, If I want to some how get this information over to revit (I think Mr. Sobon recently release Mantis Shrimp), I would need to have the points organized neatly.
I will post if I get some progress on the meshing approach you suggested. I think the way triangle and quad faces are mixed are a bit random now… or it might be that I can find a clever way to list points… I think Mr Stasiuk had some interesting approahes with mesh indices.
As for the RAM issue, I don’t understand how grasshopper handles ram enough to comment on what you said. But if there were a “purge” function where the user can decide to empty undo history after saving the definition, and if that lowers RAM use, that would make a lot of sense.
// as for SAM, I’m glad to know it exists and I have to look in it!