|
Thanks for the list Raffaele, it is a treasure.
Like to add one thing regarding previous, unsafe. I glad XSI is not
accepting such as non connected vertices. Once you have enveloped one and
it starts act weird, the envelope is trash, shapes are trash, in worst
case more. I've done this, and yes it won't import same mesh to 5.1.
Right, it could prompt the fault but it just still is better this way.
Those illegal components are not something you want to find after spending
endless hours making scene and animation and last thing when render.
Regards
Mikko
On Mon, 03 Apr 2006 08:45:27 +0300, Raffaele Fragapane <jaco(at)thejaco.com>
wrote:
just ANOTHER note...
That's nothing new to me, obj is often implemented as a super fault
tolerant format.
Some applications, like Maya, will allow topological and connectivity
schemes that are, simply put, unsafe.
It allows Nsided Polys with a hole in the middle and no edges connecting
the inner and outer bonduaries (keeping those edges hidden under the
hood but not considering them at export time, only internally at shading
time), it often accepts non manifold connectivity without raising a
warning (XSI at least raises the double edge warning and highlights such
edges for you), it will allow one and two point polys that sometime will
just not show up at all in the viewports (partially addressed in maya 7
I'm told, was still there the last time I used 6.5 though); and last but
not least, in conjunction with MJPT or other similar plugins (that come
as a part of the bonus tools set now), it will very easily generate
meshes that might be corrupt at the very foundation of the connectivity
scheme (issues like two points owning more then one edge).
It makes a remarkable effort to deal with as much, and it will export
OBJs containing these issues because there's simply nothing defined as
illegal in the filespec paper, but then no other app will be able to
import them correctly half the times.
This also holds true for other applications I had to work with, and it
sure as hell applies to some of the ATROCIOUS outputs I've had to endure
from Max, which also happens to be what 60% of turbosquid models are
modelled with.
I've had many situations where I received files from other vendors
working on the same show I was on, where these things had to be
routinely and carefully cleaned before they would stop making every
other app barfing on them.
While I agree with Rainer that a hard crash is simply NOT the way XSI
should react to such import attempts, I can see how optimizing the
importer to reduce memory footprint might lead to segfaults and illegal
memory access when the going gets too tough.
As for the meshes themselves, they'd better be cleaned up in whatever
app they come from, it's simply unreasonable to request more fault
tolerance, or a validation process, from an importer unless you're ready
to sacrifice scalability and performance, and corrupt data simply
shouldn't have been generated in first place.
All shops large and structured enough I've worked in have mesh
validation and healing tools, I've had to write them myself in one
place, and if you really want things in a format whose definition is so
volatile to go across all applications, then you should make sure
yourself that all such meshes are healed to an MCD before they cross
bonduaries.
If anything, the only reasonable request you might direct toward soft is
to have fault tolerance and optimization options in the importer, but
even then, it would be soft addressing somebody else's shortcomings, not
their own (which they did from 5.0 to 5.1).
as for the list of things that might create problems and you should
check against if you want to implement such trapping and cleaning
yourself, here's the most prominent:
-non connected points, or points with an ID that's not contained in the
polygons definition
-1point polys, or points whose ID is the only one in a polygon's
definition
-non manifold connectivity in all its forms
-two points owning more then one edge
-a point being included in a number of polygons higher then its
neighborhood count
-points defining a bonduary edge being contained in more then two
polygons including a bonduary edge
and these are just "illegal" issues, there's more rules that end up
under the borderline cases or that are simply bad practice, like point
multiplicity, which is often a valid method to pinch a catmull clark
interpolation, but will not necessarily go down well with all I/O
operations because of one or more 0Length edges being generated.
there's a lot that can go wrong with intermediate file formats, and it
often does go wrong when the product comes out of a bad or hasty
modelling process.
If the output is the issue, correcting it at input time might not always
be possible.
******************************
| Raffaele Fragapane |
| Rising Sun Pictures |
| "Remember, TD is for TopDog" |
******************************
Luc-Eric Rousseau wrote:
Just a note.. according to the investigation the .obj files that you
reported earlier this year all contained corrupted meshes, meaning for
example triangles with only one or two vertices, or duplicated
vertices, which eventually results in UV and polynode trouble after bad
triangles are rejected. The application that's generating these is
wrong. Obviously you've found that the importer in XSI 4.2 was dealing
better with these corrupted meshes, although not necessarily by
design... The goal of the new importer in XSI 5.x was to address
severe performance and memory management issues loading large meshes.
Additional hardening of the importer against corrupted meshes has been
done in 5.1. I think this whole made-up story about good programmer
making the old one and a bad one making the new one is totally
inappropriate.. the new importer in 5.x is helping a lot of clients
who couldn't load their .obj meshes at all with 4.2.
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
body:
unsubscribe xsi
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
|
