3D Modeling

[sawarsi]

we have continued to use the old faceting methods however, we have noticed that it no longer honors the normal tolerance. here was the code that used to work:

    ref->set_surf_mode(AF_SURF_ALL);
    ref->set_triang_mode(AF_TRIANG_ALL);
    ref->set_grid_mode(AF_GRID_INTERIOR);
    ref->set_normal_tol(angle);

now, regardless of the angle set it always comes back with the same faceting. do we need to change something else to get it work?

[asdf]

Yes.  If you want to control the tolerances using refinements, you need to pass a particular facet options in.  With code as below, when you call the faceter you will  need something like

facet_options_expert foe;

foe.set_tolerance_specification_mode(af_surface_tolerance_from_refinement);

api_facet_entity(entity, &foe);

You will find that when used correctly, the R21 and later versions of the faceter do a lot better with meeting the normal tolerances you ask for.  This means you should consider loosening the tolerances relative to what they where in R20 and earlier to get similar quality and facet count.  Prior to R21, surface tolerance and normal tolerance were not rigorously enforced.  In R21 and later, the tolerances you request should be honored unless there is something wrong with the input geometry.

Please let me know if you have further questions

Eric Zenk

[asdf]

Also, please consider reading the technical articles that accompanied the revised faceter algorithm:

http://doc.spatial.com/index.php/Facet_Options

http://doc.spatial.com/index.php/Quad_Tree_Gridding

thanks

Eric

[sawarsi]

thanks Eric,

that is exactly what i tried and it worked however, i was wondering why the old code no longer functions as before. i assume it would be going through the old code path and return the same results as before.

[asdf]

People want a lot of things from the faceter.  It is good if the faceter obeys the tolerances you request of it.  All other things being equal, it is also good if the faceter produces few facets and does so quickly.  

If we chose to make the default behavior of the API to obey refinements strictly, when earlier than R21 did not, there would be a bunch of fake regressions, i.e., cases where we took more time and produced more facets because the previous algorithm was "cheating" by not obeying tolerances accurately.  Having the default behavior you suggest would also be a silent behavior change.  We decided that (1) the improvements we made caused a silent behavior change no matter which way we did it (ignoring refinements or paying attention to them), and (2) the better silent behavior change is to quickly make a coarse mesh ignoring refinements.  When people notice the issue, they are pointed to the documentation and are given guidance to select tolerances.

I should also point out that the faceter changes are often versioned.  If you want "exactly the same behavior" out of the faceter without changing code, you can pass an ACIS options object into the API saying you want R20 algorithmic version.

Backward compatibility is critical.  Unfortunately, engineering often involves situations where there are a lot of critically important constraints that contradict each other.  Our customers expressed dissatisfaction with the behavior of the preR21 faceter (that it wasn't accurate enough, and when they tightened tolerances to make it accurate enough it produced too many facets).  As discussed above, fixing the inaccuracy in the preR21 faceter could cause mistaken impressions based on how the behavior changed.

Does this make sense?  best regards.

Eric

[sawarsi]

yes, that make sense thanks for the input.