iges file compare

Zander,

I agree with you! In fact, I agree so much that I have disabled Utilities to compare faces. It only checks volumes.

There are 2 different volumes that can be discussed here, volume values and occupied volumes. You can have 2 parts that each have the same volume value (i.e. 1 cubic inch), but the parts occupy different volumes. These parts are not identical (technical exceptions can exist, see below). But if the occupied volumes are identical (which is what Utilities checks), then the parts ARE ALWAYS identical.

The exception to the above rule is when there are 2 identical bodies, occupying the same geometric space, but modeled in a different relationship to the origin with one another. Imagine two 1x1x1 cubes. One of them is modeled with the origin dead center of the volume. The other one is modeled with the origin at one vertex. Both parts are technically the same exact part, just modeled a bit skewed to each other. But SW Utilities will not be able to tell this due to the volumes relationship to the origin. It will think they are different.

Checking volumes, surface area, and CG should be enough. Theoretically, parts can be equal in all these respects but still different, but that's a stretch. You could also compare inertia moments (provided density is same on both parts). Adding that to your comparison matrix would make your comparison nearly error-proof.

Is half a cc out of a half gallon enough to matter? It might. Judge for yourself; and usenet WAG polling doesn't count toward due diligence.

What is "usenet WAG polling"???

Zander

WAG=WildAssGuess; sometimes used as SWAG=SillyWildAssGuess

Mike wrote: /* Is half a cc out of a half gallon enough to matter? It might. Judge for yourself; and usenet WAG polling doesn't count toward due diligence. */

Zander wrote: /* What is "usenet WAG polling"??? */

I'll take a W(ild) A(ss) G(uess) at Mike's meaning: If you haven't identified critical features and explicitly verified conformity you are not doing your job as you should be. Most of an average "part" is just filler between function critical features and most of the checks mentioned are influenced by the trivial, only imply conformity of the critical.

I was wondering how others used sw's geometry compare tool for verifying 'exported' date ie. an iges file in this case. I'm still surprised by the amount of deviation present in a sw exported file for parts of this size. Sw is able to identify a changes face at a finer resolution than it can identify a change in volume. It can show the change in volume numerically but not indicate it's location. When you work to the resolution of your tools you are at the limit of proof. I wansn't doing any WAG polling that I know of....!

I don't recall the numbers you posted earlier, but remember thinking it equated to about half or less a cc in two liters of volume. About equal a few minutes of atmospheric evaporation in Kissimmee in July? A plaster cast likely varies much more than that... Anyway, converting NURBS to polys should have measurable error. (IGES is polygon-based, right?) The tesselation would be too fine if it didn't.

IGES has representations for most surface types, preserving control vertice structures (number, position, weight) and knot vectors. There is no loss of accuracy, change in topology inherent in the translation.

I believe the polygon facet surface rep is one of the few objects without an IGES representation matching most source system's data structure. Think the source system must convert them to analytic, parametric or rational b-spline entities before export. There should be no inherent loss of accuracy here either as these are the simplest of surface reps requiring only control vertice locations for definition.

Going further into subject matter I 'know' nothing about; topology changes occur in translations where either the source or target system change surface reps (type of rep, degree, etc.) before or after writing / reading the translation (Catia v4 is an example? Pretty rare otherwise?). Screwing up trim boundaries is another matter which is, to venture a guess, due to either the source or target system not conforming to IGES standards or making bad assumptions regarding data processing (conflicting or misinterpreted option switch settings).

"Healing" algorithms can (very often do to an objectionable magnitude) alter topology.

I don't know if or how this might be applicable to the original question / problem. I do think what I'd do (I'm assuming contours are in question) is create some section cuts thru both data sets and compare deviations and curvature graphs, but I don't know SW and there may be some other function that will tell the user more with less effort. Generic body checks are WAGs that don't tell me exactly what I want to know. [My thoughts on the subject, anyway.]

Wasn't (or, at least, had no intention of) talking about converting to polygons. I don't believe there is an IGES entity that, for instance, an acad polyface mesh, 3dFace, etc. can be written to without translating the polygons to something that can be written out as an analytic or parametric surface (types

114, 128? Don't get me to lyin'. I'm up to my ears trying to understand this stuff.) Acad's IGES translator will do that. There should be no inherent loss of accuracy.

" ... topology changes occur in translations where either the source or target system change surface reps (type of rep, degree, etc.) before or after writing / reading the translation ... " wasn't intended to encompass conversion to facet reps, though that might not have been clear. Within that context the definition of "topology" was simply contour, shape, ...

My reference to Catia v4: It's been my impression (hearsay, no first hand experience) that conversion from Bezier to rational B-Spline or NURBS (or whatever, but not facet) reps is among the primary reasons for many other systems having trouble (do have first hand experience) reading their exports. If you can comment on that it would be appreciated.

Understood, but conversions from "real surface" (if you'll allow that) reps to facet reps was never, in my mind, relevant to the subject matter (aside from Mike's "IGES is polygons" assumption).

Ah! Many thanks for that. To be honest, I've never had a clue what "copious data" is. At a glance it looks like they are writing out a lists of bounding vertices? Never mind, I can dig into it. `;^)

Hi Jeff,

Yes an iges file can hold a polygon mesh, but all it will do is convert each tri into a planar nurbs surface that duplicates the original polygon. (garbage in garbage out!) I've never used iges files for that purpose. In the old days it was all we had for data translation and there are still a few vendors around who accept nothing else. I've only used iges files to export solid or surface models to other systems, always nurb or b-rep based etc. The whole reason I started this thread was because a recent project required iges output. I don't think I've used iges from solidworks for a long time so to be on the safe side, I re-imported my own iges files and compared them to the original solidworks parts for verification and found discrepencies, I was surprised, but chalked it up to minute rounding errors out in the

6-8 decimal place range.

Zander

It's not. I am. (Well, not really new; just a bit slow.)

My experience is limited to building polyface mesh models in acad and exporting to Femap. That's my only use for the pesky critters.

Very good idea. If for no other reason than to "sanity check" the translation. If the source system can't read it back in there's little hope...

Sorry to munge up your thread bantering with Cliff. `;*)

Thanks, Cliff. I don't pretend to comprehend the math (not the language, structures, abstractions, calculations; dropped on my head or maybe it Was the pot) but think

"We have chosen rational Bézier curves to be the base, because they can exactly represent both conic sections and nonrational Bézier curves. They are also an equivalent to NURBS (non-uniform rational Bézier splines) used in professional CAD systems."

answers my question in it's present form. (... Are Catia v4's native reps Beziers? Maybe my bad.) (Also thought "basis splines" was the BS in NURBS? Basis splines [the basic segments], Bezier equations? or is their acronym expansion incorrect?)

It's an idle time pursuit; understanding the mysteries of less than perfect Catia v4 translations. Rooted in more mundane procedural or not-platform-specific causes contradictory to "prevailing wisdom" perhaps?

Thanks, I'll get back with you on that.

[ Nah, seriously, thanks for all. `;^) ]