Polyexpand failing in a for loop

[AntoineSfx]

I have this simple setup: a few 2 points segments, which I want to polyexpand individually. I'm not trying to polyexpand all of the segments as a whole.

It's failing when I iterate over the segments in a for each primitive loop with

1 flip event ignored because of infinite loop detection during skeleton computation.

Also the cooking time is insanely high, even tough in the end the geometry looks correct..

Can you tell me what's happening here ? It looks like there is some feedback loop which leads to an exponential time increase with the count of primitives, but I can't find an explanation. This is the default Block Begin setup with For-Each Primitive.

 

odforce.polyexpand.hipnc

[BlackPariah]

I'm getting the same error copying an expanded line to a bunch of points. The only difference is my polyexpand node is outside the loop... I think the node might have a problem with data coming out of a for each loop in general.

Edited August 21, 2018 by BlackPariah
screenshot upload

[pxptpw]

when i pipe the lines into the for loop, yes it complains as you guys have mentioned , 

with iso offset scatter /  connectivity / for loop and it seems to work fine and it took 19 sec for the cook for 50 lines ,

i might be wrong but this way the node cooks without any warning or error

tried to speed this up with the compile block , as it is muti threaded , but looks like the polyexpand node is one of those nodes which cannot be used in the compile block,

polyexpand.hiplc

[AntoineSfx]

5 minutes ago, pxptpw said:

when i pipe the lines into the for loop, yes it complains as you guys have mentioned , 

with iso offset scatter /  connectivity / for loop and it seems to work fine and it took 19 sec for the cook for 50 lines ,

i might be wrong but this way the node cooks without any warning or error

tried to speed this up with the compile block , as it is muti threaded , but looks like the polyexpand node is one of those nodes which cannot be used in the compile block,

polyexpand.hiplc

Without even putting a compile block (just a Block begin loop), it doesn't explain why it takes so long, and it fails randomly, especially when the segments are distinct .. The cooking time should be roughly the cooking time for 1 piece times the number of piece plus some extra time for the wrapper, but it's not, it's like it growing exponentially. I still haven't found an explanation nor a solution

[anim]

to me it seems to scale linearly with the number of curves

the error/warning is not because of your loop but because of arbitrary geometry for straight skeleton computation, which is straight line so even single line takes forever until it falls back from its internal infinite loop

if you for example split each line and jitter points a bit in XZ just so that it actually knows the curve's plane, it will get fast again, see example

so you either find an alternative to polyexpand for perfectly straight lines or submit a bug to maybe have an option to have such edge case handled, whether it'd need some helper primitive normal attribute or something

odforce.polyexpand_mod.hipnc

[AntoineSfx]

19 minutes ago, anim said:

to me it seems to scale linearly with the number of curves

the error/warning is not because of your loop but because of arbitrary geometry for straight skeleton computation, which is straight line so even single line takes forever until it falls back from its internal infinite loop

if you for example split each line and jitter points a bit in XZ just so that it actually knows the curve's plane, it will get fast again, see example

so you either find an alternative to polyexpand for perfectly straight lines or submit a bug to maybe have an option to have such edge case handled, whether it'd need some helper primitive normal attribute or something

odforce.polyexpand_mod.hipnc

so it's definitely related to points being colinear under some error e, causing polyexpand to be confused whether a point is on a side or another of a segment.

I remember reading a paper, I believe it was about CGAL  numerical robustness, see page 4

https://members.loria.fr/MTeillaud/CGAL/robustness.pdf

And for some value, you have wrong predicate values, because of rounding in IEEE754, causing the algorithms to fail because a point is found to be outside of a polygon, when it's really, inside, hence ... problems..

Even with jitter, it hiccups on some values when I change the grid size,

Also, specifying the projection plane in polyexpand doesn't solve the problem.

Maybe snapping the points on a nice grid with exact binary values, like 1/16 of a unit, to force the values to play nice..

[anim]

55 minutes ago, AntoineSfx said:

...

Even with jitter, it hiccups on some values when I change the grid size,

Also, specifying the projection plane in polyexpand doesn't solve the problem.

Maybe snapping the points on a nice grid with exact binary values, like 1/16 of a unit, to force the values to play nice..

as I mentioned, you better report a bug or a rfe for handling such cases, maybe specific projection or custom polygon N would be a good hint for the algorithm to handle this, but clearly this is not the case currently