I’m wondering what the best way is to run a view analysis over multiple buildings. By default the input to ‘geometry’ is flattened. I want to have a single legends, but separate average view values per building.
If I keep the geometry input flattened I somehow need to reverse engineer the meshes back into its constituent parts plus recalculate the average view etc. This is proving very difficult because as soon as I disjoint mesh, I’ve lost the corresponding view results.
If I don’t flatten the geometry input, the mesh and the average view is correct (I think) but then I get multiple legends and when I go to recolor the mesh the lists don’t match.
This is the output with grafted geometry. The analysis results are different to the flatten geometry one. Not sure if they are wrong or if the colours just need to be remapped (recoloured) across all the buildings rather than on a per building basis.
OK.
Case 3 is completely wrong. Flattening the results and joining mesh just mess up all.
Cases 1 and 2 are ok. The difference in results is that when you flatten the geometry it also serves as contex (case 1). When you graft the geometry the analysis is done per object and the others are not considered as context (case 2).
In your case the context input is empty (no geometry). So what you need to do in order to get the average per building is to connect your geometry also to the context and you will be set.
Using Case 2 I can get the correct results (including average view per building) from the original component. But the recolouring mesh is still a problem. The results and the analysis mesh are different data structures. How can I use the recolour mesh component here? Do I need to re-calculate the result using the point is visible output - @mostapha ?
I know that I can feed the LegendPar into the view analysis component itself but doing this means that it will re-run each time someone changes a colour scheme. Better to run the analysis first, then recolour to minimise compute time.
Looking at this again, I don’t think grafted geometry as an input works. It looks correct but the ‘pts is visible’ output is not. It should have only 3 results per testPt (one for each view point).
But them I am back to the beginning. How to re-color mesh and get average view per building. If I flatten the input I can get the correct results. But then there is no way for me to maintain a parallel data structure when I join and disjoin meshes.
The issue you encountered is because the results are returned on a face-by-face basis for input breps. This was done to give a finer level of control on the output results but it creates some difficulties for alignment with the mesh faces. In any case, if all that you plug into the component is breps with single faces, you will always be able to get out results that align with the output meshes.
@chris Thanks for the reply. I knew their was an easier way to do it! The mesh recolouring works well and is displaying as intended, but I don’t think the average view is correct.
In your example, you are getting the average of the average. Unless all the surfaces have the same number of analysis points - this is going to give false results. For example, if you run it on just one building brep, the average is 46.2%. (My model might be slightly different to the one previously uploaded). This sounds like the correct value.
If you re-run the analysis using the faces from the brep grafted, the average is 29.9%. This doesn’t look right as I believe it is the average of the average (as per your example).
So to run over multiple breps, I think we need to do something like this. ‘Debrep’ to get the number of faces per brep. Flatten the input. Run analysis but then use ‘pointIsVisible’ output to reconstruct the results for the average view . The Ladybug output will be the average view per development (all breps). By partitioning the results first (based on the number of faces per brep), then working out the average, will give you results per building. Using this method we get 46.2% for the first building and the development average matches the ladybug output.
Also, is it fair to say that the sunlight hours analysis and radiation analysis components behave in the same way in terms of geometry input and results?
Ah, good point! Man, this took a lot more list management than I ever imagined but I am sure that the attached script does what you want (I apologize that I just gave up at one point and added a small python component)
I’ve run into another problem. Is it possible the ‘mesh’ and the ‘mesh colors’ outputs from ‘remesh’ are not in the same order? I’m trying to get a separate mesh, one for each color but I’m getting weird results.
Sorry for the late response. I am not sure why all of the extra components were necessary. I was able to get one mesh for each color by processing the input data like so:
I’m trying to sort out something similar but for radiation analysis. I tried flattening the meshes but it didn’t give the desired result. The goal would be to have 3 design options passed through a single solar radiation analysis component and then recolor each option using the high and low bound of the combined runs. The advantage of this being that one could easily modify the input options and get reparameterized comparable results. Is there a way to accomplish this? It seems as though in the attached example I would have expected the ‘analysisMesh’ and ‘radationResult’ components to have similar data structures but they don’t. Not sure what I’m missing. Thanks for any feedback!!
(tried to upload a example file but the forum blocked me)
