[Q] Trim Inclusion Behavior

As an idea from several recent discussions, I'm developing a routine to automatically place a label in the same relative location of many planar trimmed surfaces.

I have a procedure that works, but I'm seeing unexpected behavior from the trim inclusion component which I'm hoping someone can shed some light on...

The routine selects a column of subdivisions from the untrimmed surface and then identifies the subdivisions that are within the trimmed (and shrunk) surface by testing the 4 corner points for inclusion. One corner of the lowest subdivision is then selected as the text tag location.

However, when the subdivisions are close to the trim boundary, the trim inclusion test doesn't always seem to get it right. In the image, subdivisions 2 thru 8 are shown (7 total) with 8 being the bottommost subdivision.

I would expect that the branch for subdivision 8 should contain one "False" output (Just as subdivision 9 should contain only one "True" output) from the trim inclusion component.

Thoughts, theory, or suggestions?

-taz

Replies to This Discussion

Permalink Reply by taz on October 8, 2009 at 2:25pm

Bump.

I can e-mail the file, but I don't want to post it yet... It's kind of a mess...

Permalink Reply by Vicente Soler on October 8, 2009 at 2:32pm

Can you post a screenshot of the previous part of the definition?
A while ago i posted this image:

in this thread: http://www.grasshopper3d.com/forum/topics/surfacetrim-workflow
I didn't ran into this problem. Maybe it can help.

Permalink Reply by Vicente Soler on October 8, 2009 at 2:36pm

Why is data with multiple paths being connected to the surface input of the trim inclusion component? Don't you have only one surface?

Permalink Reply by taz on October 8, 2009 at 2:46pm

I'll post a screen in a second, but multiple planar surfaces... lots of tree work (which maybe I can clean up).

Permalink Reply by taz on October 8, 2009 at 2:49pm

The VB comp is to shrink the surfaces (just in case...).

Permalink Reply by Vicente Soler on October 8, 2009 at 3:03pm

Maybe the paths don't match in the trim inclusion component. How are you making them match?

You have: a list of surfaces -> each creates a list of subsurfaces -> each creates a list of points
You have to duplicate each original surface as many times as subsurfaces were created for each surface and graft those so that it matches the paths of the list of points.

Permalink Reply by taz on October 8, 2009 at 3:00pm

I hadn't made it all the way through that thread before, but I think my setup is very similar to what you arrived at.

Using mass addition to cull the list after trim inclusion is a nice touch though. I hadn't thought of that one.

Permalink Reply by taz on October 8, 2009 at 3:11pm

Paths match.

Specifically, going into TI I have (86 paths, N = 1) for each surface and (86 paths, N = 4) for the UV points.

The output to notepad corresponds to (86 paths, N = 4) for the booleans.

I feel the issue is isocurve proximity to the trim curve, but that's just a hunch....

Permalink Reply by Vicente Soler on October 8, 2009 at 3:19pm

Strange. Have you tried lowering the document's tolerance values? Setting the surface's input to reparametrize? (i don't think this will do anything, but you never know)
Just out of curiosity, how are you making the list of surfaces match the number of paths of the point list? Why are you shrinking the surfaces after rearranging them into paths?

Permalink Reply by taz on October 8, 2009 at 3:30pm

Well, thanks for checking for obvious mistakes...

Doc tolerances didn't seem to have an effect. Reparameterizing would mess with my UV point generation scheme as I'm trying to (roughly) size the subdivisions.

I'll attach the file, but I wouldn't expect anyone to slog through it.

-taz

Attachments:

autoLabel_wip.ghx, 520 KB

Permalink Reply by Vicente Soler on October 8, 2009 at 4:04pm

Maybe I'm not using the definition correctly. I referenced a couple of open curves but the paths didn't match in the trim inclusion component as i feared above.
I made a couple of changes and now it seems to be respecting the trim. I marked the changes in orange. (The one from the right is probably not necessary, just to simplify things).

Attachments:

autoLabel_wip.ghx, 569 KB

Permalink Reply by taz on October 8, 2009 at 4:17pm

I can't open your file. Could you try to attach again with a different name? I get an IO error message.

Wait, now I see what you mean about the paths. I was checking the paths for the wrong surfaces... Duplication would be necessary to make things match up.

I should have been more descriptive, but these are my input curves...