Best fitness result NaN

[petrasvestartas]

Hi,

I would like to ask if this actually an error.

The software produces correct result. But when I have lots of elements to nest the sum of area becomes so large that instead of large number it displays NaN.

Does such result produces an error internally? Or yield incorrect genetic algorithm result?

Would it be possible to scale down internally?

[fel88]

Hello, i think this is error somewhere. If you give me your input data, i'll try to reproduce this bug and try to fix it.

[petrasvestartas]

I cannot replicate NaN error anymore. It seems that it happens only when an element cannot be placed withing a sheet i.e. a polygon bounding box diagonal is bigger than the sheet bounding box diagonal.

I noticed that scaling is highly important too. Here comes the tolerance issue. Below I do not display simplified polygons, as I do not know which property could give me the simplified polygon (Please advice which property I should search for).

Below I compare different tolerances. By tolerance. I mean that I scale polygons before outputting to nesting application and when nesting is finished I scale back to original scale. Random seed number stays the same in all examples.

Original scale:

Scaling 10 times more:

Scaling 10 times less

Scaling 100 times results in some shapes not nested as they are probably average to integers and becomes bigger shapes than sheets. And then nested shapes overlap:

It is quite obvious why it happens because polygons gets simplified or rounded to integers (correct me if i am wrong) But ordinary user do not have clue about the scale and which tolerance to choose.

[fel88]

Thank you, for this report. I'll check it out.

[9swampy]

The code uses float in parts of the nest which can result in overflows so in my branch I flipped to double, just kicks the can down the road though. If you keep scaling up then of course the issue could reappear, as you've found. You could get some mileage by reducing ClipperScale but if you go too far you'll very quickly lose precision in the nest.

[petrasvestartas]

Thank for the reply.

Other question: do you know how to nest long linear elements, they usually nest very poorly?

[9swampy]

Only noticed after I replied that the question was 3 years old! Sorry for that, glad it helped. You're still using regularly?

I had a similar problem; some long thin parts that nest fairly well with each other leaving gaps that could be filled by small parts if they were fit later, after the long thin ones have placed already. I've attempted two routes;

• restricting rotation on a part by part basis to only vertical or horizontal (for the long thin parts) - which works well and on the original branch you can replicate by either - reducing the number of Rotations from default 4 to 2 but then that applies to all parts. - changing the code in the procreant GeneticAlgorithm constructor for the long thin parts
• the notion of IsPriority - essentially forcing the long thin parts to get placed first which, especially in combination with the rotation restriction, works very well IF you can fit all parts on a single sheet. More than one sheet and the parts overlay and the nest is invalidated. Still debugging this one and isn't really easy to replicate in the code as it stands. If I fix the problem I'll publish the code :)