CGAL users discussion list

[Peter Hachenberger <>]

> >> One thing to note: I'm reading a nef_3 from a .nef file. 
> >> And I've refreshed the .nef file from an identical .off model (very 
> >> simple)
> >> using the nef_3 type with the indexed items type. (I've not found any 
> >> significant 
> >> difference in format from the two .nef files written from two identical 
> >> nef_3
> >> with different items types)
> >
> >What is the question of this paragraph? Are you wondering that the nef
> >files are the same although you use different kernels? That's intended.
> 
> 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.

> >> Sorry, it's a typo, it should be:
> >>     Plane_3 p;
> >>    Nef_3 N;
> >>     Nef_3 result = N.intersection(p).intersection(p.opposite());
> >
> >I got that fault in the first place. My comments where on the corrected
> >version. Do you already have an impression of how much the indexed items
> >help you? Is Nef still a bad bottleneck? How much of a speed up do you
> >need?
> 
> You mean this idiom is ok for my need?

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);

Peter