remap BRep to XY-Plane inaccuracy / tolerance problem?

Replies to This Discussion

Permalink Reply by phillip on February 20, 2013 at 7:21am

Could nail down the problem to the reorient component and posted it here.

Permalink Reply by Hannes Löschke on February 20, 2013 at 7:25am

Floating point numbers and thus numeric operations have limited precision. There will always be an error margin. This problem comes up a lot under various topics. If you want some more detailed input serach for "double", "float", "precision", "accuracy".

Permalink Reply by phillip on February 20, 2013 at 8:14am

Well, well, somehow I figured it must be something about accuracy or rounding.

As you suggested, I got a little closer on the topic and got a little more of understanding about the problem in general. I see on most discussions I find, you are involved, so this must be your expertise, so maybe you can help.

The thing here is: If I want to transform A to B and they both deal with the same precision, I´d would think the transformation itself also would.

So does my transformation have to be more acurate than A and B itself and If so, how to do it?

Permalink Reply by Hannes Löschke on February 20, 2013 at 8:52am

I'm no expert, just a long time coder so this issue is an "old friend".

All math is ultimatively handled by the CPU. Numbers are limited to about 15 digits. Some numbers will have a mantissa exceeding this limit. So with two integer digits and maybe one or two operations, an error in the realm of e-11 is totally within reason.

There really is no sensible way to get more precise. Rhino tolerance paradigm states that you should never expect results to be more precise than six digits after the decimal point. Any difference smaller than that should be ignored/treated as no difference at all.

2.9e-11 is way beyond e-6 so just ignore it.

Permalink Reply by Steve Lewis on February 20, 2013 at 9:23am

Do u have a link to the rhino tolerance paradigm? Thanks?

Permalink Reply by Hannes Löschke on February 20, 2013 at 9:52am

http://wiki.mcneel.com/rhino/faqtolerances

See 4) last sentence. I stand corrected: You should not even use a tolerance below 1.0e-5.

Permalink Reply by phillip on February 20, 2013 at 10:53am

I´d love to ignore it. The thing is, some other components won´t.

Anyhow, I got around it by projecting to XY-Plane afterwards, but it just bothers me to do this.  

Another funny thing is, if you take the output plane and do the same orient again and again, it will come to the point a panel tells you they are all World XY now. If you take the compound transformation of these repeated steps and transform the initial plane with it, its still not the same though.

So as mentioned the two outputs still behave different. That was confusing me.

Permalink Reply by Hannes Löschke on February 20, 2013 at 2:43pm

The right way to deal with little inaccruacies depends on what you want to do and what error you can deal with. (would be interested in how the non "WorldXY" planes affect generator)

Your case looks a little confusing in the first place. Reorient is meant for geometry not planes. If you reorient a plane to another plane, all you get is the plane you orient to (ignoring the numerical inaccuracies). Your example might be meant for demonstration purposes, though...

If you reorient a plane with very little deviation from WorldXY to WorldXY, the deviation will gradually get smaller until it is shifted out of existence, because input and output data is off by more than those roughly 15 digits. Imagine you only have 4 digits. You try to add up a lot of 0.001. Once you reach, 10.00 another 0.001 doesn't matter. The result can only be 10.00. Even with 15 digits not all numbers can be added or multiplied with a valid result. This is when off planes "degenerate" to WorldXY.

The combined transform will first combine all transforms, which doesn't introduce any errors for your simple action. This results in a single "Orient to WorldXY". This essentially cancels out two of the three orientations and gets you the result of just one.in Theory it doesn't matter if you add A to B and C or the other way around. In limited computer math, the order does matter.

Now all this is technically a "bug" in the display logic. "WorldXY" will only be displayed when all axes do exactly match WorldXY, ignoring all that tolerance stuff.

Other components will pay attention to tolerance. Like Planarity will return true, even if the cruve isn't exactly planar. Here's a little example for you to play with.

Attachments:

• curve_planarity.gh, 4 KB

Permalink Reply by phillip on February 21, 2013 at 3:44am

Yes, of course the example I gave doesn´t make much sense in terms of reorienting a plane.

So it was only to show, that if you process a plane it will transform from O (0,0,0) Z (0,0,1) to World XY, which in terms of tolerances more or less the same, but not in terms of definition, as you mentioned above.

This means I was actually looking for a way, how to "degenerate" on purpose.

E.g. the Generation Nest Component will only accept curves, which are layed out on World XY. This is the reason, why I came across this in the first place. So as you mentioned this is not only a "bug" in the display logic, the definiton also draws a border sometimes.

After this discussion though, I now believe this is something that should rather be handeled by the component itself, since we are apparently speaking of a generic - maybe unsolvable -  issue.

Which then brings me back to the conclusion the mentioned problem should be also solved by degeneration inside the reeorient component itself, if a World-Plane is an provided input.

Even though we are -technically- not talking about a bug here.

Thanks.

Permalink Reply by Hannes Löschke on February 22, 2013 at 11:36am

Well, since Rhino itself with it's tolerance can possibly create "planar" and "WorldXY" that has a non-zero Z coordinates, Generator should accept those too. I'd call this sloppy programming since you might want to pack 3D Panels for efficient 3D CNC milling not only flat curves for laser cutting...

For any flat geometry you can expolde the result of the orientation to WorldXY into control points and set each Z-coordinate to 0. With curves, a projection to WorldXY is a quick way to make sure of that.

Permalink Reply by Steve Lewis on February 20, 2013 at 9:24am

What is the component that looks like the list item component but is highlighted with blue instead of red?

Permalink Reply by Hannes Löschke on February 20, 2013 at 9:49am

It's just a clustered ListItem. You can inspect that downloading the definition.