Weird sorting of Planar Surface output

I'm sending rectangles into a Planar Srf component and the sort order is wierd now. See images. You can see in the shader preview how the coloration is a nice gradient, then after adding the planar srf the sort order is mixed up. Is this a bug or something else? Any idea how to avoid it? I'll go try other surface tools for now.

Replies to This Discussion

Permalink Reply by Vicente Soler on November 15, 2009 at 2:13pm

You can try grafting the list of curves before the planar surface component. Then flatten out the output surfaces.

Permalink Reply by Chris Wilkins on November 15, 2009 at 2:43pm

I tried that. It didn't change anything. I ended up extruding the rectangles very thin, and then capping to get same effect. So I got past the problem, but I'm still thinking this is a bug. I can't think of why the sort order would come out wonky.

Permalink Reply by Vicente Soler on November 15, 2009 at 2:57pm

It works for me:

From top to bottom:
- First surface contains rectangles colored by their index number
- Second surface contains planar surfaces created from the previous rectangles, colored by the rectangle's index number. You can see the list order got screwed up.
- Third surface contains planar surfaces created by grafting the list of rectangles and then flattening them after the planar surface component. The list order stays intact.

Permalink Reply by Chris Wilkins on November 15, 2009 at 4:40pm

I tried again and it worked. I think that I never saw the results last time, because I had plugged in the unflattened list into the shader and instead of giving me 1456 results, it tried to give me 1456*1456 due to cross referencing, and it just sat there forever.

I know why the grafting will work - because the paths are processed individually. But I'm still curious why the output of the planar surface comes out weird. Do you know why it sorts that way?
Thanks

Permalink Reply by Vicente Soler on November 15, 2009 at 4:47pm

Well, you could have a single planar surface made out of many different curves, so i guess all the lines get plugged into the sdk's planar surface method and then it tries to sort out how many planar surfaces should be created (two closed curves, one inside the other, on the same plane, create a single surface with a trim in the middle), somewhere along the way the initial order of curves is forgotten.

Permalink Reply by Chris Wilkins on November 15, 2009 at 5:02pm

Ahh. That makes complete sense. I've always been sending in closed curves to that component. I didn't realize you could send open curves in and it would find the curves that can close and make surfaces. Interesting. It seems like that would be a memory intensive component (although I have no idea how it would do what it does - look for matching end points? - I wonder how that works).

RSS