Replies: 11 (Who?), Viewed: 13051 times.
Instructor
Original Poster
#1 Old 21st Aug 2009 at 7:33 PM
Default A short guide to good clonable CAS objects (in progress).
Each object seems to have individual parameters which drastically change what you see on your uv map and your cloned object in game. There is stretching going on both with the shading maps and the patterns. If you clone the wrong object it will mess up all your hard work and unless you have the stamina of an elephant you may never want to try again. In order to simplify things and maybe help find the solutions here is a list of objects which seem to retain uv maps quite well:

This guide is very much in progress but I thought it would be best to post results as they come up. Anyone wanting to help add to this list with examples is more than welcome because it will benefit us all. Please do not ask questions yet since for the time being there are no answers, none that I could answer anyway. (I am working on dining tables now.. so if you do want to help...pick a category and spare many of us heartache:D.)


Post 1: Dining Chairs
Advertisement
Instructor
Original Poster
#2 Old 21st Aug 2009 at 7:34 PM
DINING CHAIRS

In this category there are two chairs which work quite well and you would be best avoiding the others for the time being especially if you want to shade your items: (Note that I cloned most of the dining chairs but not all. For this test I used the shading map as a reference, and the same new object and uv map each time.

The dining chairs that do not have a notable uvmap displacement once in game are:

1) ChairDiningCountryCushion 3 recolourable CAS parts
2) ChairDiningColonial1 2recolourable CAS parts

Of note,

1)ChairDiningCountryCushion has accurate pattern mapping but displaces the shading map more than 2).
2) ChairDiningColonial1 retains a better shading map but as you can see stretches the patterns once in game. Here is a very rough picture of what happens, with
3) the bad example:

Look at the black lines and the pattern to see where the differences lie.
Alchemist
#3 Old 21st Aug 2009 at 7:56 PM Last edited by WesHowe : 21st Aug 2009 at 8:57 PM.
Thanks for the detailed analysis. I can see you did a lot of work coming up with these facts.

I'm going to make my own clones of these three chairs. Somewhere in the material of OBJ parameters are some variables that we need to be able to learn to control. Perhaps by comparing different things between these we can find these differences... especially the texture stretching and displacement issue.

[Wes tips his cowboy hat to the lady]

OK, Here is one answer. If you look in the XML file that has the same instance as the VPXY, you will see that the middle chair uses:

Quote:
<value key="Pattern A Tiling" value="1.0000,2.0000" />


While the other two chairs use:

Quote:
<value key="Pattern A Tiling" value="2.0000,2.0000" />


That is undoubtedly the reason that the texture is stretched unequally on the center chair, because the vertical tiling is set to half the rate used for the horizontal.

If you like to say what you think, be sure you know which to do first.
Instructor
Original Poster
#4 Old 21st Aug 2009 at 9:10 PM
If it helps any here are some more uv maps of the bad ones: Is there a pattern?





Considering the shading maps were already off I did not put them into game to see if the actual patterns are stretched or not. Hopefully its a start, to work out what's happening and why.

[lady flutters eyelashes Tex Avery style to clever cowboy]


Images named after their game counterparts. Some parts are stretched, some seem to correspond to outside of game mapping.
Alchemist
#5 Old 24th Aug 2009 at 3:02 AM
I have some news on this.

In the last few days a lot of bit-bashing has been going on involving the MATD (Material Definition) data by the likes of Tiger and Delphy. These files are part of what is in the MLOD files, and control all sorts of things like Shininess and Transparency.

As well as, interestingly, U and V scaling. While I talked about texture stretching, and said there had to be something in the MATD, I was only half-right. It is a specific U and V scale factor that is in the MATD.

I have a fix half-way done (far enough along to prove to myself it is feasible). While it adds to the complexity of the tools themselves, it will just work at the basic level. But, I am adding control files that can be edited to change material parameters for those building new objects. I am a little excited about this, because it will allow the more self-confident modders a path to take care of issues like transparency or metallic looks that were not configured that way in the original object that was cloned.

I plan to release this in a few days (whenever it is finished). Projects that are partly done can be rescued, but in order to capture the right UV Scaling factors a new decompile will need to be done, and the mesh transferred over. Sorry, a little extra work it is the price of progress sometimes.

<* Wes *>

If you like to say what you think, be sure you know which to do first.
Test Subject
#6 Old 24th Aug 2009 at 4:02 AM
Dear WES,where is the XML file?
I couldn't find :<value key="Pattern A Tiling" value="1.0000,2.0000" />


And...If you have time come to see my problem....
http://www.modthesims.info/showthread.php?t=366044
Alchemist
#7 Old 24th Aug 2009 at 4:24 AM
You need to clone the object with the defaults duplicated, there is a checkbox and you have to change it. Then there will be more files in your clone, one will be an XML file that has the same instance value as the VPXY. That is the one I was referring to.

Otherwise, if you just leave the defaults, it is using one shared with other game objects, and if you edit it, it will change game items, too.

<* Wes *>

If you like to say what you think, be sure you know which to do first.
Test Subject
#8 Old 24th Aug 2009 at 6:37 AM
I used the new S3OC to clone the loveseat but without an XML....>.<
there is a VPXY...but in S3PE it is :
RCOL Blocks:[0] --- 0x736884F1-0x00000001-0xC4622CAF411E2B95 - VPXY ---
Tag: 0x59585056
Version: 0x00000004
--
Entry List:
[0]: [EntryType: 0x01] [TGIIndex: 0x00000000]
[1]: [EntryType: 0x01] [TGIIndex: 0x00000001]
[2]: [EntryType: 0x01] [TGIIndex: 0x00000002]
[3]: [EntryType: 0x01] [TGIIndex: 0x00000003]
[4]: [EntryType: 0x00] [EntryID: 0x01]
TGIIndexes: [0] 0x00000004
[5]: [EntryType: 0x01] [TGIIndex: 0x00000005]
[6]: [EntryType: 0x01] [TGIIndex: 0x00000006]
[7]: [EntryType: 0x01] [TGIIndex: 0x00000007]
TC02: 0x02
BoundingBox: [0:'-0.9110385'] [1:'0'] [2:'-0.4070864'] [3:'0.9110385'] [4:'0.777337'] [5:'0.3471175']
Unused: [0:'0x00'] [1:'0x00'] [2:'0x00'] [3:'0x00']
Modular: 1
FTPTIndex: 0x00000008
--TGI Blocks:
00000000: 0x03B4C61D-0x00000000-0xC2435BE9297C1B3E
00000001: 0x01D0E75D-0x00000000-0x599AD245E6FC4DA5
00000002: 0x01D0E75D-0x00000000-0xA1B8359F6ADEDD0E
00000003: 0x01661233-0x00000001-0xC4622CAF411E2B95
00000004: 0x01D10F34-0x00000001-0xC4622CAF411E2B95
00000005: 0x8EAF13DE-0x00000000-0xA33A8DB9A8C9E3BF
00000006: 0xD3044521-0x00000000-0xA33A8DB9A8C9E3BF
00000007: 0xD382BF57-0x00000000-0x289FC02ECFEB25E8
00000008: 0xD382BF57-0x00000000-0xA33A8DB9A8C9E3BF
--
Instructor
Original Poster
#9 Old 24th Aug 2009 at 8:37 PM
Quote:
Originally Posted by WesHowe
I have some news on this.

In the last few days a lot of bit-bashing has been going on involving the MATD (Material Definition) data by the likes of Tiger and Delphy. These files are part of what is in the MLOD files, and control all sorts of things like Shininess and Transparency.

As well as, interestingly, U and V scaling. While I talked about texture stretching, and said there had to be something in the MATD, I was only half-right. It is a specific U and V scale factor that is in the MATD.

I have a fix half-way done (far enough along to prove to myself it is feasible). While it adds to the complexity of the tools themselves, it will just work at the basic level. But, I am adding control files that can be edited to change material parameters for those building new objects. I am a little excited about this, because it will allow the more self-confident modders a path to take care of issues like transparency or metallic looks that were not configured that way in the original object that was cloned.

I plan to release this in a few days (whenever it is finished). Projects that are partly done can be rescued, but in order to capture the right UV Scaling factors a new decompile will need to be done, and the mesh transferred over. Sorry, a little extra work it is the price of progress sometimes.

<* Wes *>


Well, that is really good news. Whilst the shinyness factor could still have been overcome elsewhere the distinctly odd uv mapping is a major hurdle and the fact that you are making progress on it is a huge breakthrough.

Is this just for the pattern scaling or for both that and the shading?

Anywhich way, thankyou:D
Test Subject
#10 Old 24th Aug 2009 at 9:02 PM
Buggybooz: The shinyness comes from the specular texture. There is a white image in the cloned object, it controls the shinyness of the object. It comes with a black alpha image, but for some reason the Photoshop plugins import it without one. So, when you made your new specular map, you have to make a completely black alpha channel and import it that way.

Wes, these are good news. Thanks a lot for your work.
Moderator of Extreme Limericks
DELETED POST
24th Aug 2009 at 11:27 PM
This message has been deleted by jhd1189. Reason: Oops... never mind
Alchemist
#11 Old 27th Aug 2009 at 9:33 PM
So I think I have this fixed. Credit to Tiger and Delphy for their contributions to the MATD format on the Wiki.

There is a tag item in the MATD for meshes which sets a scale value to the UV map. It appears to have been designed to decrease possible rounding errors from compressing the floating point values on UV maps that used less that teh full range possible, however the default rounding on a 1024x1024 texture map would amount to 1/32 of a pixel. However, it is the way it is, and the decompiler and recompiler in the ObjTool now know how to use the value to regenerate the scaling spot-on.

This makes another issue, overscaling, possible when a new mesh is substituted for the original. The compiler checks for this, and warns. The fix, however, is manual, and requires editing the .mtlsrc values in the project. It isn't guaranteed to happen, but overscaling will occur if the UV map in a new mesh has items below or right of what was used in the original mesh.

So if someone would test this out on some of their problem meshes, it would be helpful.

<* Wes *>

If you like to say what you think, be sure you know which to do first.
Instructor
Original Poster
#12 Old 29th Aug 2009 at 4:45 PM
There are many "howevers" but test we will
Back to top