I’m trying to create an array of surfaces across a diverse variety of plane geometry. I’ve built a script that that reliably creates an array of panels on any sort of quadrilateral. However, when I try to apply this to multiple surfaces, the script produces strange results, beginning at an orient command about halfway through the script. This seems to be something with the data from multiple trees misaligning, because I can gain some sort of improvement by flattening some of the incoming data; however, it still doesn’t quite work.
I’ve included the entire script as I think it’s helpful in understanding the final intent, however the problem begins halfway through, at an orient module:
Yeah, it’s data trees for sure. I would start by grafting the two surfaces, then eliminate most of the Orient components because collectively, they are redundant.
Thanks for the help @martinsiegrist! I think I understand what the Shift Paths module is doing, and the output is making a lot more sense. Apologies for the Pufferfish, I imagine there’s a way I could avoid the plugin, but it’s working for the moment.
Thanks @Joseph_Oster for the tip on the overuse of Orients–I’m going to try to make the script more efficient once I have a reliable output.
Thanks @Joseph_Oster, this is great, I will use this to optimize at the end!
One thing I’m also trying is to orient each of this sets of small planes such that they remain planar to their host planes, but their y-orientation aligns with the world’s y-orientation. It’s also important that these smaller planes stay in rows, as shown in the picture; this is why I rotated and cull by surface boundary right at the end, rather than earlier as shown in your solution @martinsiegrist
I’m not so sure it makes sense to align any planes with Y, given their arbitrary orientation. The planes I am using are the “natural” result of EvalSrf on the untrimmed surfaces. Looks good to me?
@Joseph_Oster I would agree in general, though in this case these are photovoltaics, and I want them all to be facing ‘south’. I’m now struggling with a secondary issue that depending on how you build the surface the y normal can be 180 opposite
Oh. That’s a whole different issue, eh… Maybe eliminate the rotation and just align planes before creating the rectangles? And use sliders for spacing values to get the panels as close together as possible? I added the expression “floor(x)” to the ‘U’ and ‘V’ inputs of SDivide, though the difference is probably insignificant.
Awesome, I will definitely be able to incorporate some of this efficiencies. However, part of the reasoning for making the the rectangles, rotating as a group, and then culling is so that the panels remain in neat rows. I’ve been trying this on a number of geometries to ensure it’s a robust and broadly-applicable script.
I’m still having a bit of trouble with the orientation of the panels, which I think only becomes evident when they are tilted using the Pufferfish ‘Rotate Plane XYZ’ module. But I am hoping to sort it out.
I see nothing when I open your file. I can dig around but it’s too much work, especially with two models in the same file. Slowly revealing more requirements is also called “moving the goal posts”.
Parallel to one edge of the roof? Bottom edge? Top edge? How does this work on roof surfaces that face north? Have fun.
That’s a whole different issue, eh… Maybe eliminate the rotation and just align planes before creating the rectangles? And use sliders for spacing values to get the panels as close together as possible? I added the expression “floor(x)” to the ‘U’ and ‘V’ inputs of SDivide, though the difference is probably insignificant.
