Window Mullion Help

Replies to This Discussion

Permalink Reply by Joseph Oster on November 8, 2017 at 5:14pm

I see several problems here.

1. 'Deconstruct Brep' is returning 11 or 12 edges from surfaces that appear to have only four edges, which may indicate something odd about how the surfaces were constructed.
2. For 'Sweep1' to work, the "section curve" (which is the 'Mullion Square') must be oriented to the start of each rail curve, on a plane perpendicular to the tangent at that point (obtained using 'Eval Curve'), and with the appropriate source reference point and direction vector for the 'Mullion Square' curve.  Use 'Orient Direction' for that.  It would be a little easier if you created your 'Mullion Square' from a 'Rectangle' component instead of using an arbitrary curve because you would then have the reference point and plane (or direction) needed by 'Orient Direction' instead of having to figure that out from the static curve.
3. Finally (for now), the 'Rail Curves' parameter contains the six lines from the top surface but it also contains a copy of the 'Mullion Square' curve - seven curves total instead of the expected six.

Permalink Reply by Joseph Oster on November 8, 2017 at 5:36pm

Here is an attempt to demonstrate 'Sweep1' using your data.  I re-created the 'Mullion Square' using the dimensions of the existing rectangle curve (two edge lengths), removed the stray rectangle from the 'Rail Curves' ('Shift' list with 'Wrap (W)'=false), and then used 'Orient Direction' followed by 'Sweep1'.

But as you can see, there is another problem here.  The surface is curved (twisted), not flat, and the orientation of the station curves ignores the surface completely, resulting in unsatisfactory mullions.

Not simple!

Attachments:

• Mullion_2017Nov8a.gh, 76 KB

Permalink Reply by Joseph Oster on November 8, 2017 at 7:28pm

This is a much better result.  It wasn't easy!  Instead of 'Orient', I ended up creating 'Mullion Square' curves (rectangles) at both ends of each curve, centered on the rail curves and oriented by 'PFrames (Perpendicular Frames)' aligned to surface normal vectors at each rail start/end point.

While I was at it, I noticed that every other rail curve was flipped, with start points for half of them at the top and half at the bottom.  It didn't cause a problem but I looked deeper into it and found and fixed the reason; see the yellow groups in your code that divides the top and bottom edges of the surface:

I used these results (8 instead of 6) for rails instead of the internalized 'Rail Curves':

It looks so simple, doesn't it?  Especially if you use sliders for the 'Rectangle' dimensions instead of extracting those dimensions from the internalized 'Mullion Square'.

Attachments:

• Mullion_2017Nov8b.gh, 83 KB

Permalink Reply by Joseph Oster on November 8, 2017 at 8:44pm

I decided to look into applying this to all twelve "Internalized Window Surfaces"...  The first thing I did was to fix the issue of getting four edges from each surface instead of all the fragments; the bright orange group accomplishes that:

Then I realized my mistake in Mullion_2017Nov8b.gh - creating straight lines for the rails on a curved surface - oops!

So I abandon all of that and decided to use isocurves instead, which returns only six rail curves; the edges get ignored. :(

But when I try using all surfaces instead of one, I get this mess, which is a little worse than it looks.  U/V direction isn't consistent for all twelve surfaces (again, likely due to differences in how they were created).  Unfortunately, the mullions don't lie flat on all the surfaces as expected.  Too late tonight to figure out why...

Attachments:

• Mullion_2017Nov8c.gh, 85 KB

Permalink Reply by Joseph Oster on November 9, 2017 at 10:29am

I took another look this morning, thinking I might be able to resolve some of these issues.  The best thing would be to reconstruct the entire multi-surface model; so I started to do that by baking the surfaces and duplicating horizontal edges, with the intent of joining and lofting them.  That's when I discovered another problematic detail - the corners of the surfaces don't share the same point:

So how about starting over on that set of twelve surfaces?  Or at least create them consistently so they all have the same UV orientation?  That's my best advice at this point.  Oh, and isocurves aren't the only option; the straight lines could be pulled to the surfaces or 'Curve On Surface (CrvSrf)' could be used instead.

Permalink Reply by Joseph Oster on November 9, 2017 at 1:20pm

So how about starting over on that set of twelve surfaces? Or at least create them consistently so they all have the same UV orientation? That's my best advice at this point.

Having said all that... good news!  I finally managed to get code working with all twelve panels, just as they are:

The most difficult part was the white group, grafting and partitioning as necessary to match and align the pFrames at each end of each rail.

It got a little painful.  Couldn't possibly do it without examining the data coming from every component in the chain, using text panels and my 'Tree/List Viewer' tool (included).

Attachments:

• Mullion_2017Nov9a.gh, 94 KB

Permalink Reply by Joseph Oster on November 9, 2017 at 1:42pm

Reading your description again, you mentioned "5' spacing between the mullions".  You can replace the two 'Divide' components in the lower left group with 'DivLength' components but I doubt you'll like the results because the top and bottom edges of each surface are different lengths.

Or you can divide the length of the shorter (top) edge by 5 and round off the result to the 'Count (N)' value for the 'Divide' components used before.  Again though, maybe not what you expect?

Attachments:

• Mullion_2017Nov9b.gh, 87 KB