warning: long historical note follows
several weeks ago someone asked about why the DX libs
don't seem to work well with both invalid positions and
invalid connections in the same field. (actually i think the
question was why Include went out of its way to remove
one if both existed.)
the problems come when the two exist but aren't consistent.
it leads to all sorts of confusing and error-prone situations
and we finally said the benefits didn't outweigh the dangers
of presenting bad data to someone, and having both kinds
of invalids in one field made that way too easy to do.
originally we didn't see a problem and i know we talked about
writing a library routine which brought both components into
a consistent state. but this is more difficult than it first seems.
say you've changed the invalid positions - now you have to
go back and also invalidate any connections which reference
those positions. so far, so good. but do you OR them in?
replace what's there? if the invalid connections just shadow
the invalid positions, then it doesn't seem very useful - why
would you want both? it's more likely you want both in the
same field because you are using different criteria for the
positions than the connections. so trying to reconcile
them seems like an impossible task to "do right".
in addition, going the other way, if you invalidate a connection,
then what does that say about the positions? it's easy to say
that if any position in a connection is invalid, the whole connection
is invalid. but the reverse doesn't follow - because positions are
normally shared amongst multiple connections. if you started
invalidating positions, then that would invalidate neighboring
connections - just like pulling a string in a sweater, the whole
field would unravel before your eyes.
then there's the possibility that you are actually revalidating
positions - does that automatically revalidate the connections?
perhaps they were invalid for other reasons other than just
the vertex validity, but there's no way to know.
it also gets complicated when you can Mark, Compute, and
then Unmark components. should Unmark always check to see
what component you are unmarking into and do some automatic
tests on consistency? but if you're trying to hand manipulate
both invalid positions & invalid connections, you can't create
the intermediate field because unmark will change the other
component on you. yea, you could rename it, but this is
already convoluted and getting worse by the minute.
(oh, yea, and you can have "invalid faces" for face/loop/edge
polygons, so you'd have to include checks for that as well.)
if you think of their original purpose, it is to flag the data.
there's only one data component per field, and that data has to
be either per position, per connection, or per face. if the invalid
component follows the data dependency, then things seem to
be the most rational most of the time.
Include checks for and removes "other" invalid components
if they exist, because later processing modules typically do
the following:
1. look up the dependency of the data component
2. check to see if there is an "invalid XX" component
3. process only the valid data items, updating the invalid
component if needed to reflect any newly created data.
it's at steps 2 & 3 that things get bizarre if both components
exist, because most modules don't look for, nor can know
what to do with, another invalid component.
it can be a bit strange to have an existing component get
nuked by Include, i'll grant - but if you use the structuring
routines to rename the components and update them "by hand",
at least you're in complete control and can know what you're
seeing in your final image is what you intended.
hope this helps in trying to understand one of the many
strange habits of the dx libs.
nancy
