I have been looking at this interesting problem, and I think I have a possible answer. I believe the artefact is due to the 'winding order' of the vt entries within the face definitions.
I am aware that the winding order for vertices within the face definitions is used to calculate the face normals, and that is documented, but I have never come across definition for the winding order of VT's. Nevertheless Poser seems to be very sensitive to them.

An example:-

v -1.00000000 -1.00000000  1.00000000
v -1.00000000  1.00000000  1.00000000
v  1.00000000  1.00000000  1.00000000
v  1.00000000 -1.00000000  1.00000000
v -1.00000000 -1.00000000 -1.00000000
v -1.00000000  1.00000000 -1.00000000
v  1.00000000  1.00000000 -1.00000000
v  1.00000000 -1.00000000 -1.00000000
v -1.00000000 -1.00000000  0.00000000
v -1.00000000  1.00000000  0.00000000
v  1.00000000  1.00000000  0.00000000
v  1.00000000 -1.00000000  0.00000000

vt  0.11894488  0.04803747
vt  0.29814872  0.04803747
vt  0.29814872  0.18821995
vt  0.02934299  0.46858484
vt  0.02934299  0.18821995
vt  0.11894488  0.18821995
vt  0.29814872  0.46858484
vt  0.29814872  0.60876727
vt  0.11894488  0.60876727
vt  0.11894488  0.46858484
vt  0.38775063  0.18821995
vt  0.38775063  0.46858484
vt  0.40683913  0.57345837
vt  0.49905956  0.57345837
vt  0.40683913  0.84908801
vt  0.49905956  0.98690283
vt  0.49905956  0.84908801
vt  0.68350047  0.98690283
vt  0.77572089  0.84908801
vt  0.68350047  0.84908801
vt  0.68350047  0.57345837
vt  0.77572089  0.57345837
vt  0.68350047  0.43564355
vt  0.49905956  0.43564355

vn  0.57735026 -0.57735026  0.57735026
vn -0.57735026 -0.57735026  0.57735026
vn  0.57735026  0.57735026  0.57735026
vn -0.57735026  0.57735026  0.57735026
vn -0.57735026 -0.57735026 -0.57735026
vn -0.57735026  0.57735026 -0.57735026
vn -0.70710677  0.70710677  0.00000000
vn  0.70710677  0.70710677  0.00000000
vn  0.57735026  0.57735026 -0.57735026
vn  0.70710677 -0.70710677  0.00000000
vn  0.57735026 -0.57735026 -0.57735026
vn -0.70710677 -0.70710677  0.00000000

g cube1_default
usemtl default

f 1/6/2 9/1/12 12/2/10 4/3/1
f 2/10/4 10/4/7 9/5/12 1/6/2
f 3/7/3 11/8/8 10/9/7 2/10/4
f 4/3/1 12/11/10 11/12/8 3/7/3

f 5/13/5 9/14/12 10/17/7 6/15/6
f 6/16/6 10/17/7 11/20/8 7/18/9
f 7/19/9 11/20/8 12/21/10 8/22/11
f 8/23/11 12/21/10 9/14/12 5/24/5

The above will display as a hollow cube, each side of which consists of two faces. These will display artefacts as they were created from a box mapped cube. I deleted the ends to simplify.

If you replace the f lines with the following:-

f  1/1/2  9/2/12  12/3/10  4/4/1
f  2/5/4  10/6/7  9/7/12  1/8/2
f  3/9/3  11/10/8  10/11/7  2/12/4
f  4/13/1  12/14/10  11/15/8  3/16/3

f  5/17/5  9/7/12  10/6/7  6/18/6
f  6/19/6  10/11/7  11/10/8  7/20/9
f  7/21/9  11/15/8  12/14/10  8/22/11
f  8/23/11  12/3/10  9/2/12  5/24/5

Then the artefacts disappear. If you study the two sets of face definitions, the ony difference is the order in which the vt references appear. Please not that the 'corrected' cube has distorted texture map. this is because I didn't change the actual VT entries themselves, just the order of references to them.

I welcome any thoughts on this. If this is the answer I hope somebody could write a little code to 'repair' .obj files.

Cheers

Ian

I sketched out the vt definitions for each face of the 'fixed' cube and I think that I see  a  'clockwise' winding order for each face, including where faces have shared vt entries. I could be confused though as its difficult to visualise a 2d map into 3d, then back onto a sheet of paper .

The 'bad' cube has no recognisable winding order that I can see for the vt's. In case anyone is supicious the 'bad' cube is a exported from a UV program and I did not deliberately break it, other than box mapping to generate artefacts.

Cheers

Ian
 

Very interesting!  I'll have to look into this some more (although WHY Poser is even looking at the UVs for 'shading' purposes is still a mystery to me).

Spanki,

I agree that it's a mystery why Poser is , I think,  using this infomation for shading. I don't see what purpose it serves that the face normals don't already provide.

I looked at the example file that TheOwl posted   plCylobj.txt on the first page of this thread. Following the trail of vt references through the face definitions I see a pattern for the triangles of the end caps and for the quads of the cylinder sides. In a couple of places this pattern is broken, particularly clear on the cylinder sides. I suspect that this is where the artefacts appear.

Well, it's not 'just' about the winding order... I suspect that your 'fix' above is just a case where that particular order happened to work.  If you simply reverse the winding order of the existing vt references, they'll flip the texture around in various ways (but still use the same texture space for that polygon), but the artifact still appears.

I'd also comment that, IF you were using Bump Maps (or displacement, etc), then the shading would indeed depend on and need to reference the UV values, but even then, I would think that it was just to look up a value (bump or displacement amount) for that pixel - the UVs (in and of themselves) don't contain any 'normal' information (aside from the case of using a 'Normal Map' - but even with that, the 'shading information' is the normal map pixel value found at that UV location, not the UV location itself).

Thanks Spanki,

I'm open minded on this.

I don't quite follow your statement that  "If you simply reverse the winding order of the existing vt references, they'll flip the texture around in various ways <>, but the artifact still appears." I am suggesting that any breaking of the vt winding order will cause artefacts, including reversing them, so yes I would expect reversing the winding order to create artefacts . I agree totally that reordering the vt references will flip the texture about.

I would be suprised if my fix randomly hit on a combination that worked. I do think that it would be better if I could demonstrate on a more complex geometry. I hope to try that tonight but I can't try any more experiments for about 13 hours or so whilst I am at work. I simplified the test example down to a hollow cube to make it easier for me to understand.

Currently I am suggesting that for Poser:-

a)  That the order of vt entries for each face should follow a winding order

b) And it follows that where  faces share vt entries, and smoothing is being applied across the boundary between the faces, that the winding order rule is applied for all faces including the shared vt entries .

Cheers

Ian

im currently working on a clothing model that suffers with this ripping problem, (all the normals are correct and facing in the right direct etc) Will re-mapping the model effect the winding order???
im off to do tests....will post later

guys... I think it's time to pack this up as a bug report (I suggested to RC he gets the programmers to take a look in here, but he thought it better to pack it up and submit it as a bug report directly)

Quote - Thanks Spanki,

I'm open minded on this.

I don't quite follow your statement that  "If you simply reverse the winding order of the existing vt references, they'll flip the texture around in various ways <>, but the artifact still appears." I am suggesting that any breaking of the vt winding order will cause artefacts, including reversing them, so yes I would expect reversing the winding order to create artefacts . I agree totally that reordering the vt references will flip the texture about.

Sorry, I chalk this up to applying different meanings to the term "winding order".  As typically used (in regards and related to vertex ordering), this refers to the order that the indices are listed in the facet record, but has less to do with the "index numbers" themselves and more to do with the 3D positional values of the vertices that those indices reference.

In other words, if the resulting vertex locations describe a polygon in a 'clockwise' direction (winding order, around the perimeter of the polygon), then the polygon is interpreted by apps as facing one direction, whereas if they describe a polygon in a "counter-clockwise' direction, then the polygon is facing the oppposite direction.

So, when a user chooses an option to "reverse the winding order" (in UVMapper or "Reverse Faces" in something like my plugin for Cinema 4D), the order of the vertex indices (whatever they happen to be) gets written out reversed, to flip the faces around - I assumed this is what you meant by the term.

I now see that you were more referring to the actual "index values" (regardless of the value of the UV it refers to) - which is even more interesting (wierd) as it relates to implications of causing the artifacts :).

I agree with Khai though... someone from SM needs to be looking into this and could probably provide a quick answer to all of our speculation about the potential causes and maybe a working solution (ie. work-around, for all the currently broken versions of Poser and a fix for any future patches or updates).

it's a start. I can replicate the above results on complex meshes - you can eliminate the artifacting... but on cylinders (where this all started), nope.. soon as you put a UVmap on, the artifact is back.

did anyone report this to the programmers as a bug yet?

Hey Khai,

Without knowing/seeing the before and after UV-mapping layout used in your image, I can't say whether this adds anything new (see my previous posts about easily reproducable "causes" of artifacts being where the uv-seams are).

What I do find interesting though is that IF all 3 of the above renders use the SAME material, then something is indeed odd about how uv-mapping (or the lack thereof) actually affects the "shading" (noting that the center image, with NO uvs is rendered darker than the others).  There is no reason I can think of for Poser to render these differently, when there's no texture involved at all.

I still think this is somehow entangled in the way that Reyes renderer sub-patching engine works.

well the middle one was straight from your STOMP program with all UVmapping removed on saving.

then I just put on a quick Uvmap on the last one in UVmapper pro..

so all I did was effectively prove your right it's the UVmaps ;)

Thanks... I'm (a little) releaved that they at least all render the same (overall) shade with or without uv-mapping values :).

wasn't a point to showing the UVmap for the raw Stomped, since there wasn't one ;)

interestingly, I can't get consistant results on this.
the mesh above worked fine after having it's UVmap removed then a new one applied. but on taking a cylinder and stomping it then applying a new UVmap, the artifacting was back.

so it's only a parital fix in the end.

Cool - thanks.  Could you post a link to your simple (uv-mapped) .obj file?  It's interesting that the 'fixed' version seems to have a uv-seam at the spot where the artifact was (opposite of what I've been claiming/thinking).   I'd like to play around with it.

Also... aside from any potential odd (ie. floating point precision) differences between the output of STOMP and UVMapper, you shouldn't really need to run it through STOMP to remove the UVs before (re)mapping it in UVMapper.

I don't recall if UVMapper will let you save .obj file without uv-mapping or not, so you might need to use STOMP if you want those types of files, but if you just want to try out different mappings, you can just do all that in UVMapper.

no, UVm won't strip UVmaps. looked into that.
bascially I was trying to find a fix for that artifacting when I remembered you saying that UVmapping may be the root of this.. so I used Stomp as a 'control' to remove any mapping as part of the experiment process.

Gotcha.  And the file - thanks.

Do you still have the Sketchup version available?  I don't have a good way to reproduce that particular mapping for testing.

just tried an experiment. I converted the OBJ to LWO and imported that.

it was worse...! it looks like OBJ's the best format to import even with the artifacting.