I have a complex swept part, about 35' x 15' profile with a swept
section about 2' tall and 1' wide. It's analogous to a giant crown
molding in looks.
I have split the part into about 20 pieces for mold making/casting.
The parts are being exported as IGES files for the fabricator.
I want to compare the iges files to ensure they are identical.
I open the original part and then open it's iges counterpart and do a
'geometry compare'. It almost every case the volume is 'identical' but
there are almost always 'unique faces' listed.
In my mind if the volume is identical that should be good enough? I
take it to mean that the unique faces are so close to one another that
boolean operations are impossible and I should be happy that it's all
Good Enough (tm)!!
Do you all agree?
Here is a snippet from the report of a sample part:
Reference Part Modified Part
Unique Face(s) 8 8
Modified Face(s) 1 1
The solid volumes of both the bodies are identical.
Parameter Reference Part Modified Part
Surface Area 1860414.3878mm^2 1860416.4688mm^2
Volume 17098479.8507mm^3 17098545.7532mm^3
Center of Gravity (0.074mm, 473.1173mm, 1216.3107mm) (0.0736mm,
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"??? */
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
"Healing" algorithms can (very often do to an objectionable magnitude) alter
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,
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
" ... 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. `;^)
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.
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
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
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?