CGAL users discussion list

["Max" <>]

>> 
>> I already know the content of .nef files written with different kernels
>> are different. and I also guess there's difference in contents between 2 
>> .nef files written with different items types. But I cannot detect any 
>> significant diff's.
>> 
>> >I spent lots of time to write input and output functions that convert
>> >and normalize coordinates. 
>> Yes, writting the i/o module of nef_3 is a hard work.
>> 
>> >Actually I have code that even sorts the
>> >output such that it is always the same, but I only use that for testing
>> >purpose.
>> 
>> That's a good news. And I think it's a good idea to make it open.
>> It's a good idea to keep a uniform format of .nef files for different
>> kernel types and items types, as long as it's possible practically 
>> and theoritically.
>
>I think you got me a bit wrong. The output can deviate only in two
>points (at least if you use a supported kernel):
>- the coordinates are not normalized and can therefore deviate in their
>representation
>- the items may be listed in different orders.
>
>If you compile with flag DCGAL_NEF3_SORT_OUTPUT the output will also be
>normalized and sorted. I took that out as a standard behavior because it
>slows down the output.
>

Thank you for your further information.

>
>At the moment that's your only option, but it will try to find the time
>to give you the following idiom:
>
>    Plane_3 p;
>    Nef_3 N;
>    Nef_3 result = N.intersection(p, PLANE_ONLY);

Thank you. I think it'll see an improvement, no matter how faster it will be.
I'll give it a try.

>
>Peter
>
>
B/Rgds
Max