I've run into an issue that has had me puzzling for a few days, and I thought I'd share here, in case it's something involving the s3 cc pipeline of tools and therefore of interest to those bravely developing it all.

When I assign materials to my object in milkshape, and check it out to ensure that my uv mapping seems sound and covers all, things look one way. When I view the object in Sims 3, however, the coverage is not the same. It's my understanding that these should pretty much match.

If not, feel free to ignore the post altogether.


Potentially relevant info:
- Object is a desk, made entirely out of the milkshape box primitive. It replaces the DeskContemporary S3 object. (My desk is meant to cover only one square and the original model takes up three, that's why the shapes are so different.)

- I UV-mapped by screenshotting all the parts of my desk in Milkshape and then assembling a .dds out of those to map to. My gray texture map and my part mask are built off of that, as well.

- I grouped all of the top/bottom, the left/right, and the front/back faces together for each of the boxes, and mapped those groups, then finally grouped all together. (I tried different groupings, too. All worked when previewing textures/materials in Milkshape, but this box mapping worked best in-game -- though still not right.)

- The desk was built as half a desk, and duplicated then mirrored and welded to make the full desk.

- A weird thing is that the top two boxes (the desktop and the base of the desktop) have mapped perfectly in-game every time, but the legs, crossbar, and feet are the ones that have not.

- The faces that seem off are the front leg front & back faces (was same group), and the bottom bar side faces (left and right again were in one group together).

Other notes:
- The object isn't perfect -- I do realize I have the desktop and the base z fighting and the legs aren't all perfectly positioned. That's stuff I intend to fix only after I figure out what's going on with the uv mapping.

- The back leg mapping works and is the same, basically, as the front leg. I'm sure if I keep fiddling with redrawing boxes for the uv map for the front leg and cross bar (as I've already attempted a number of times, to some improvement), I might get it to look right in the game. However, the point here is that I thought it was odd that I wasn't seeing the mapping issues inside of milkshape, using the same texture files as I imported into my package.

The game does some sort of scaling on some textures. This appears related to the material definitions, which we do not have fully defined. In your example you will notice the trouble areas are at the bottom and right side of the texture map, which are the two directions in which the values of U and V increase.

The difference is about 1%, or perhaps 2 pixels on a 256x256 texture. I have no concrete solutions, and not every object or texture does this. I have worked on this several times, the UV mapping is replicated exactly on export and import, the texture appears to be being scaled, for what reason I do not know.

Objects without this scaling do not have this problem... besides trying a different base object, the only other solution I know would be scaling the texture map about 1% larger, as I do not know what fields in the MATD are specifying the scale.

<* Wes *>

One interesting point (which I fear will help no-one) is that this happens when cloning an EA object and making no alterations to it. I'd been having problems with a shifting-down-and-right mapping on a window. So, I cloned the EA original and DID NOTHING to it - just fixed it with a unique identity and ported it back into the game.

The texture still shifted.

Several objects I've made so far have given me this little headache, but it's not the plugins. I can use the plugins to extract the mesh back out of the faulting package and it, the multiplier etc and the mapping are spot on perfect in UV Mapper Pro and in Milkshape too. It's not alterations to the mesh, mapping or texture either.

_____________

Other things I tried:

Offsetting my UV map: I shifted my meshes on the texture in the opposite directions by the same difference. Oddly, not only did this fail, the texturing had STILL slipped by the same degree and distance down and to the right (as if I'd made no offset at all)

Mapping to the full extent of the texture: I figured that there might be a mapping origin fault so I deliberately added a tiny (hidden) plane that was mapped from point 0,0 to all extents of the texture. That achieved nothing too.

As said, I fear this might be of NO help whatsoever, but I thought I'd post in case there is that small chance that one of you ultra-intelligent folk bringing these fabulous tools coulld say: "Ah! Got it!"

I am at the moment stumped myself. If has to be something in the material definition, but I don't get why it would be there, and what is changing it.

I played with different values in the plugins that alter the UV mapping, and while I can make the UV and texture match perfectly on one mesh by stretching the UVs by about 1%, it ruins another object that had no texture matching problems. On a lot of objects, it is there but is not obvious because texture maps often are colored "past the lines".

It does not make sense that this sort of stretching would be used, because it is just one more step that has to be done to a texture or a mesh when it is loaded, and for no apparent benefit.

The good news is, because it happens on some (actually, many) objects but not all means it must be something that is a variable.

As a note, it is not a "shift" of, say two pixels. If you look at the differences, stuff in the upper-left part of teh map are not shifted, or at least not an appreciable amount (less than a pixel shift would not be noticeable). The shift becomes noticeably larger as you move down and right. This is indicative of a multiplicative shift, such as 99% or 101% scaling would do, rather than a flat shift across the whole image. It looks like if you took the texture image (say 512x512) and resized it to 507x507 (about 1% smaller) and then pasted that in the upper left corner of a 512x512 image and colored in the little edge strips it would fix it.

But who would hire artists and have them do that sort of work for no visible gain in quality or functionality of the game? EA may do some things for reasons that are not readily apparent out here, but they are not stupid enough to design something that takes longer and costs more to produce just for the sake of it taking longer and costing more.

Anyway, there is something in the game that does this, for reasons that are not readily apparent. I know that many of the materials use a texture compositor (TXTC) and there are portions of that chunk that we don't know what all of the data items do.

I wouldn't be surprised to find that the ones that shift and the ones that don't have something different in the material definitions, and it could well be related to texture compositing.

<* Wes *>

I noticed that the scaling is different on all objects. I tried some in-game objects, both with 512x512 texture map and for the first one the scale was around 100,5%, for the other one it was around 102%.

I tried to create a new object, with using the same scale value that previously worked on the original EA object, but the result was really bad.

In some respects, I have cheated quite a bit to get this to work. Entire chunks of configuration data is copied from the import to the export, with just the adjustments needed to allow more or fewer faces and vertices (as well as the UVs of course) plugged in.

In one MATD I was just looking at, there are 23 different variables defining something or another in it. Logic tells me that some of these are shininess or transparency and similar material definition data, because there is really no other place such things could be defined, and anyone can see that some materials are glass and some are metal and some are flat surfaces.

In the latest release of the object meshing tool, there is room to add buttons... one of the things I pictured adding was a material properties editor. The properties are among the little .bnry files that are made when a MODL is decompiled, if you edited them now with a hex editor the changes would be picked up and included in the recompiled MODL, but what is lacking is some basic analysis of what is in the files. Tiger did some analysis of this, but the trouble is, there is Tiger, and Wes, and Delphy, and far too few other names to add to the list of people trying to analyze these files. A few of our past champions are busy doing other things, such as earning a living, and can't contribute.

But analyzing the MATD and related chunks is a fertile area for any new explorers out there. Because the mesh tools split the chunks out and remerges them later, poking at them some with a hex editor is certainly easy enough for anyone adventuresome and inquisitive.

<* Wes *>