Hi, I have a very specific and interesting problem here… 230405_PV_pattern.gh (277.6 KB)
I have a collection of parallel lines that are divided according to a fixed length.
Now I want to create surfaces in between those lines. The first challenge here is that the surfaces need to be planar while the beam’s start-/endpoints differ in height.
A rule is that the surfaces shall never go below the line, because later on those lines are beams and the surfaces are PV-modules, which should not intersect. I think this part I managed, by evaluating the z-coordinate.
The problem is that some lines are longer (bigger angle), so it produces more points.
This leads me to the second big challenge: The lines/beams will later on have varying extents on both sides (see second input in the script).
I extended all curves to a fixed length, starting from a reference point, in order to work with a grid.
Built each panel and computed the best plane from 3 corners (minimizing strictly positive deviation), then projected the real contour along Z on the corresponding plane.
Amazing! Thank you so much! I haven’t thought of this strategy.
If a full one can’t be fitted, it should be removed yes.
I was also wondering, if one can control on which side the hovering corner is?.. so it is always hovering on the same side. Is this possible?
Yes it’s possible to add such control.
Instead of testing all 4 planes, I only test 2 consecutive ones. You have a parameter “side” to choose which side is allowed to “not be flat”. Here with side 0, you can see than the panels only lift up by their bottom left or bottom right corner.
Removed everything that concerned partial panels, this makes things easier.
The Z coordinate is the local Z coordinate of the 4th point in the local plane created by the first 3 vertices.
These get sorted in increasing order (Sort List).
And only the positive Z values are kept (Greater Than 0 and Cull Pattern).
Since the first 3 vertices are on the beams, as long as the 4th vertex has positive Z value locally, we know the entire panel must be above the beams.
This number controls how many panels will be “tested”, but as you asked before, if a panel can’t fully be applied on the base surface it will get removed. So it’s not really a parameter you can act on, especially because your panel length is fixed.
You could increase it more to be sure but this will make the calculation more heavy only for more panels to be removed. When doing the tests, 12 was the best value.
What you could try to act on is the base point (input of Move). Slightly moving it could maybe allow you to get one extra row of panels ?
but isn’t the input of the move dependent of this “number that controls how many panels will be tested”?
…because the motion of the move component is connected to the amplitude which again is connected to the multiply…
ah okay so it doesn’t affect the overall “positioning” of the grid then.
So my current reference points for the grid are the midpoints of the straight curves right?.. so shall I move them with a number slider and then plug them into the geometry?
You could use Evaluate Length (or Point on Curve) instead of Curve Middle.
Your method should work if you plug the output of Sort List inside the Vector and a slider in Amplitude. Right now you may have a list/tree data mismatch.
alright! I’ll go with points on curve! maybe I can calculate the overall area of all the modules in the end and see with which point I get the highest values
Hi again, I’m in the process of implementing this PV-grid on the actual geometry (which has several entities) and there’s one problem I can’t get rid of.
In some areas (or rather, always in the same area), rectangles are created although they aren’t within the scope of the loft. PV_pattern_implemented.gh (64.2 KB)
Any ideas why this happens?
A few… For starters, there seems to be two adjacent surfaces, not one as in the original problem.
I’ll have a look but there is a plugin right at the beginning of the definition that I have to bypass somehow.
THANK YOU!
Hehe, sorry to have flatten the loft at the time it seemed to be the only thing that works.
So, the problem was the data structure of the loft then? …therefore, the violet part is all about setting the right data structure for this loft right?
Yes in a way this was a data matching problem.
The Project Point component takes the Geometry as list, meaning he will try to project each point on all geometries. Some lofts overlap are close to each other, so some rectangles were succesfully projected on an adjacent loft that they weren’t supposed to belong to, and therefore were kept in the tree.
The only solution to this is to give the component a single loft for each group of points to project, and when doing so, the tree structures must match. Hence the purple group.
I would have been stuck for ever with my method!
at the time it seemed to be the only thing that works.