Tech Discussion: The Material Definition ("TXMT", a.k.a. "MATD")

[Numenor]

This thread's scope is to collect all the data currently available about the structure, the content and the functions of the MATDs (Material Definition).

I've studied them a little, and I found them very interesting, because they hold information over objects' transparency, reflectivity, texture, lighting and many other (still unknown) things.

*Everybody is welcome* to add his knowledge, his experiences, the results of his experiments and everything related to the subject. Don't be afraid to give your contribution: despite the thread title, this discussion involves every level of knowledge, from the lowest to the highest.

If we'll be able to create an organized data repository, maybe we can then transfer it into the Wiki.
And if I find there are many people interested in contributing to the collective knowledge, I can start new Tech Discussion threads for other subjects.

Share the knowledge! :) :grouphug:

[Delphy]

Theres a bunch of stuff on the wiki about MATD already :)

http://www.modthesims2.com/wiki/49596978

[Numenor]

General function and Texture reference.

My first contribution (I'll add more later) is about the general function of the MATD in relation of the flow of data that has to be collected in order to represent an object in the game.

Once the game has collected the 3D mesh of the object that has to be rendered, it needs to know what should be the exterior look of the object itself.
So, it looks into the SHPE file(s) and the GMND file(s) in order to know:
1) what parts (subsets) the object is made of;
2) how those subsets should be represented in the game.

For each subset there is at least 1 MATD, but often we can find multiple MATDs for each subsets, because the subsets may be multistate (clean/dirty, lit/unlit...) and/or they may have more than 1 color.

For example, the "Bella Squared" painting has 2 subsets: the painting and the frame (there is a 3rd subset related to the shadows that the object casts over the wall, but from now on, let's forget the shadows, that are not interesting for our study.
As this painting has no multiple colors option, and it's not a multistate object, we have only 2 MATDs for it (not counting the shadows).
Another example is the "Bon Apetit" dining chair: it's made by 2 subsets, as well (fabric and wood), but the fabric comes in 7 colors, and the wood in 2 colors, so we have a total of 9 MATDs for this chair.

The main scope of the MATD is to hold information about the texture that has to be applied to the subset in order to render it in the game.
The texture reference can be found in the stdMatBaseTextureName string field of the MATD.
In order to let the game display the texture, the stdMatBaseTextureEnabled boolean value must be set to True
Then the graphic engine must know how to apply the texture over the 3D mesh: the texture might be tiled over the surface, or stretched across it, or maybe something else... Anyway, the stdMatBaseTextureAddressingU and stdMatBaseTextureAddressingV fields are suitable for the purpose.
I'm sure that these two fields may assume different values, but so far the only value I've found in these fields is: Tile. If anyone has more information, pleas let us know.

[Delphy]

I wonder how the stdMatBaseTextureAddressing values correspond to the UV coordinates held within the GMDC files themselves.

It might act like a base offset from the original coordinates given.

[Numenor]

Theres a bunch of stuff on the wiki about MATD already :)

http://www.modthesims2.com/wiki/49596978

Thank you Delphy, I knew it, but I think that the wiki, while it's an important tool for the experienced modders, is quite difficult to use and understand for the not-so-high experienced users.
I'm trying to push those people to share every little bit of knowledge they may have collected: maybe they think that those "little bits" aren't enough to post them and share them with the Community, so I started this thread as a "collector" for them. Maybe it will be only an unsuccessful experiment, but at least I shared what I know in a more understandable way then the Wiki can do.

Anyway, your "watching over us" is really appreciated! :) Where do you find the time to read all the threads we start and to post your advice, too?! :D

[Numenor]

I wonder how the stdMatBaseTextureAddressing values correspond to the UV coordinates held within the GMDC files themselves.

It might act like a base offset from the original coordinates given.

But then, why I always find the value "Tile"? Aren't there other ways of applying the texture over the mesh?
And, to tell the truth, I only open the GMDC in order to extract some meshes with your plugin...! :) I know nothing about the GMDC, but the "Tile" value doesn't seem to refer to a coordinates set. I'm quite confused on this subject, because is really out of my study field... :err:

[Delphy]

Textures can be tiled across a mesh by increasing the UV coords greater than 1. So, a UV of 2 would indicate a tiling pattern.

Perhaps the MATD version of tiling alters the mesh UV coordinates in some way as to tile the texture by X, depending on what is specified.

I agree that the Wiki is very much for technical file formats, and and actual discussion about *what* particular values mean is called for, so it's good that you've made this thread :)

As for having time to read everything, I just scan the new posts and comment on stuff thats interesting ;)

[Numenor]

The Blend Mode: part 1

Another very important function of the MATD is to hold information about the blend mode.
Among the other things, the blending lets the user alter the look of the object, adding to the texture transparency, color, brightness, light/shadow patterns and so on.
The blending can be used in conjunction or alternatively to the texture.
In other words, sometimes the texture is referenced into the MATD and the special effects can be added to it; on the contrary, sometimes the rendering of the object isn't based on a texture, but relies only on those special effect.
The typical example is the glass: to render a glass object, there is no need to use a texture: the only things we need to specify are its transparency, and its colour (if any).

The blending mode is activated/deactivated by using the stdMatAlphaBlendMode key; the values accepted by this field (correct me if I'm wrong) should be: none, additive, blend, blendreflective, mask, maskbump.
Every one of the mentioned values instructs the game to look for additional keys into the MATD, in order to collect the needed rendering information.
Obviously, the none means that no blending is to be applied to the object, so there's nothing to talk about. :)

Let's begin our analysis with one of most frequently used blending mode: blend.
As seen, we can activate it by means of the key: stdMatAlphaBlendMode: blend.
Then, we have to specify some more parameters in order to give our object the look we want it to have.
The most useful parameters are stdMatDiffCoef, stdMatUntexturedDiffAlpha and stdMatDiffCoef.
These three parameters are used to have the so-called "color blend".
Here is the syntax & acceptable values.

stdMatAlphaBlendMode = blend
stdMatDiffCoef = [0-1],[0-1],[0-1] -> RGB values for glass colour
Values of 0,0,0 give as a result a dark (but still transparent) glass; 0.5,0,0 give a reddish glass, and so on.

-------------------------
stdMatAlphaBlendMode = blend
stdMatUntexturedDiffAlpha = [0-1] -> glass transparency
A value of 0 means "completely transparent" (beware: it means invisible!), while 1 means "solid".
Typical value for clear window glass is ~0.3


-------------------------
stdMatAlphaBlendMode = blend
stdMatEmissiveCoef = [0-1],[0-1],[0-1] -> RGB values for glass brilliance
The brilliance is the "inner" light that the glass may have. It's not a "light", because it doesn't add light to the room; it's just a bright look.


-------------------------
Experiment by yourself different values for the three parameters and look at the differences. I find very useful, for testing these values, the "window" part of the cheap microwave (obviously, you have to install the CEP in order to recolour it :)).

End of part 1

[RGiles]

To get the value you want in stdMatDiffCoef, pick a color you like in a paint program and find out the Red Green and Blue values for it. Divide each of them by 256. These are then the numbers you'll list as the values for stdMatDiffCoef.

For instance the middle-grey color is R 128, G 128, and B 128. 128/256 = 0.5 so stdMatDiffCoef would be set to 0.5, 0.5, 0.5

stdMatDiffCoef sometimes has a fourth parameter. I assume it relates to the alpha (transparency) channel, but I haven't been able to see what effect it has. Does anyone know?

Edit: This value can be applied to objects that are not glass as well. For instance if you wanted to give a textured object a "warm" look you might set this to a very faint yellow, and if you wanted it to have a "cool" look you might set it to a very faint blue. It can blend with the texture that will be laid over it, so that the same texture can be applied to a different overall effect.

RG

[Numenor]

Sorry, I made a mistake while copying & pasting: the third "code" is stdMatEmissiveCoef and not stdMatDiffCoef. Now I've fixed my post.

The stdMatEmissiveCoef sets the "brilliance" values, while the stdMatDiffCoef sets the "color" values.
Thanks for having pointed this out and for having exlained the method to get the Coef values starting from the RGB values.

As for the fourth parameter of the DiffCoef, I've seen it sometimes but I don't know what it is for. I hope that someone will tell us.

[RGiles]

Ah, I see. I changed my post above so as not to cause confusion.

What else can I add? Hmm... I'll see what else you have to post in Part 2 and beyond so we're not duplicating. I probably have more questions than answers anyway. :D

RG

[Inge Jones]

I don't know if this is relevant but did you know you can set some things in a BHAV, like "My 48 assign to 0" (followed by a Refresh instruction) sets the object transparent? That's the alpha, and there are other values for red, blue and green.

[Numenor]

Very interesting!
The 0x48 (Render Alpha) operand probably changes "on the fly" the stdMatUntexturedDiffAlpha value, and the 0x49/4A/4B (Render Red/Green/Blue) should change the stdMatDiffCoef values.
Do you think so?

[Inge Jones]

Well I found only 255 and 0 actually appeared to do anything in the game, and I am afraid I didn't try the RGB ones at all. It affects the whole object, whereas I would have thought editing the materials would apply differently to the various parts of the object.

For example, in a shower, the frame and the back are separate materials, aren't they? Yet the BHAV instruction makes the whole lot visible or invisible.

Could it be a toggle (0/255) meaning apply the channel or don't apply the channel, applied to the values defined in the material?

[Numenor]

Well I found only 255 and 0 actually appeared to do anything in the game, and I am afraid I didn't try the RGB ones at all. It affects the whole object, whereas I would have thought editing the materials would apply differently to the various parts of the object.

For example, in a shower, the frame and the back are separate materials, aren't they? Yet the BHAV instruction makes the whole lot visible or invisible.

Could it be a toggle (0/255) meaning apply the channel or don't apply the channel, applied to the values defined in the material?

The stdMatUntexturedDiffAlpha value into the MATD applies to the single part of the object (but it doesn't consider the alpha channel of the texture, so the transparency is applied to the whole texture of the object part).
The problem is that there is 1 MATD for each part of the object, and (afaik) the "My Render Alpha" operand doesn't accept a parameter to indicate which part you want the alpha to be applied to, nor it's possible to set the stack to point to anything less then a whole object. So, I think that the operand modifies the Alpha for the whole object, regardless of the parts it is made of.

BTW, haven't you tried any other values between 0 and 255? If it's just a toggle switch, why the values are 0-255 and not 0-1...?

[Inge Jones]

Yes I tried various other values for My 0x48. All non-zero values resulted in a 100% solid object, no hint of tranlucency at all. You ask why 0-255 if it's only a toggle? Well in my time with The Sims I have come across zillions of quirks where I thought "Why on earth did they do it like that?!?!" :D

[RGiles]

LOL. Yeah, that's a good question a lot of the time, Inge. In a lot of cases it looks like they started to implement something and then gave up on it.

I know Rain was interested in irridescent effects. I came up with these 2 textures in playing around. I used a glass material and added my own reflection map is all. By the way, do you want this globe for the CEP? It's not a standard catalog object. It's one that Carrigon added to the catalog from debug stuff.

RG

[Inge Jones]

Ooh that's weird! Yeah, sure, the more the merrier :D

[Quaxi]

If it is ok with Carrigon, the please yes. Add this to the CEP :D

[RGiles]

I'll check about that. It's a nifty object. It would be niftier still to have a clone of it that does something. This one just sits there. It's purpose was to test materials and lighting... curved objects are good for that, so I picked it too. :)

RG

[Carrigon]

It looks great. Add it :D I hope we can eventually hack it to do something interesting :D

[Numenor]

I knew that object since long time ago, it was originally used as a test for lighting and reflection. I've never showed it in my "Maxis lost & Found" because it's useless, without some modding; for the same reason I've skipped it in the CEP. There were other test objects (or abandoned objects) nested into the Objects.package, most of which were brought to the "public attention" by the ingenious "collection" by Carrigon.
If you like it, I can add the ball to the CEP, and other object, as well. I just have to test if the CEP will work with such "hidden" objects without actually bring them to the normal catalog (cloning the ObjectData, like I did for the Umbrella Light).

[RGiles]

It requires Carrigon's package of debug objects. I do like this one because it's useful for testing materials (the original purpose as you said) and because it's a fully built decorative item where a lot of the objects are not very detailed.

I've already got the files for CEP if you want me to upload.

Edit: Did you make any progress on recoloring fences? I think they have to be cloned to be recolored because they are 2 pieces bound together by an XML file. But I figure I should check with you before I give up on it.

[Numenor]

RGiles, would you please post the MATD for that iridescent sphere, so I can study it? Or maybe you can describe what MATD values have to be changed to have such an effect.

(As for the fences, I haven't even looked at them, but let's talk about the CEP in the older thread)

[Miche]

Maybe this is a tiny bit off topic, but I don`t think the MATD files link to the GMDC files. I think the SHPE file links the GMDC and MATD files together, in the SHPE , there is a list of the the named "objects" in part 3 of a GMDC file and next to each (seemly divided by a single character, though this character varies) is the name of a MATD file.
In the tests I have done so far in creating new GMDC files, this list needs to fit in with what is in the GMDC file, else the graphics for the object will not show up in the game.

[Numenor]

You're right, the MATD doesn't link to the GMDC, did I say so?
The SHPE file undoubtedly points to a GMND and holds information about the parts the object is composed of.
These parts are used, in different ways, by the GMND (that associates a MATD to each part), and by the GMDC (that contains the 3D mesh of the various parts). That's why, I think, the parts listed in the GMND must be the same that are in the GMDC.

[Miche]

No, I didn`t say you said they do.

That reply was more to Delphy to tell him that when a new GMDC file is created it must have all the parts which are listed in the SHPE file. Missing out one part from the GMDC has the effect I said. (or it seems so from my tests anyway)

As for the GMND, with some objects it doesn`t seem to list all the parts which are in the GMDC (the cornucopia for example only lists the groundshadow in the GMND, while others list all parts.)

[RGiles]

RGiles, would you please post the MATD for that iridescent sphere, so I can study it? Or maybe you can describe what MATD values have to be changed to have such an effect.
This was very simple. I extracted the MATD for glass car windows. Then I used OW to create a new color package for the sphere. I replaced the MATD in the color package with the glass MATD (of course changing it's name and TGI to match the old one). That made a nice crystal ball.

Then I imported a texture image to replace the reflection map that was used on the glass. I think it was called "outdoordaytime-envcube". I put my own small texture imag in that reflection slot, so my swirling texture is reflected onto the image. Changing that reflection map can produce a lot of different effects, especially different metals.

Here's the package. Sorry for the pathetic file name. I hadn't meant to share it. :)

RG

[RGiles]

As for the GMND, with some objects it doesn`t seem to list all the parts which are in the GMDC (the cornucopia for example only lists the groundshadow in the GMND, while others list all parts.)
The GMND lists all subdivisions for which retexturing is possible. If the object has only one color option be default, the subdivisions don't need to be listed in the GMND, since that list is just an instruction to the game to display options. We added that list to the GMNDs of objects that didn't have it to create the CEP. (Sorry if you knew this already, of course. I have no idea who had the patience to follow our previous thread.)

RG

[HoneyB]

I am trying to make the glass on the Matte and Glass Door dark. Just so u know what I've done so far I created a package for the door itself. Then I created a second package for the glass & changed the stdMatDiffCoef to 0,0,0 to make the glass dark. I then used both sets of files to make a combined package (door & glass). The thing is that I see the door image just fine but the glass is still the same as the original door.

What am I missing? :)

Edit: Nevermind...I wasn't missing anything. It worked! I was trying to use the design tool to look for the different color glass but it didn't show the dark glass option. But when I went to place a door from scratch, the option was there for the dark glass:

http://img.photobucket.com/albums/v14/HoneyB/Posting%20Pix/DarkGlassDoors.jpg

The dark glass is now an option for all my doors even though it is packaged with the black one. If I want to offer just the dark glass option without the door, I can package it seperately & it should work right?

Thank u again for all the help! :)

-B

[Numenor]

The dark glass is now an option for all my doors even though it is packaged with the black one. If I want to offer just the dark glass option without the door, I can package it seperately & it should work right?

Thank u again for all the help! :)

-B

I'm glad that it worked! I always suggest to create 1 package for 1 recolourable part, so you can share only the glass. If you *really* want to make a package that contains bot the wooden part ant the glass, you can select *both* parts when creating the recolour package (by CTRL-clicking on the subset names in the listbox until all of them are highlighted).
Try some more combination of the stdMatDiffCoef and/or the stdMatEmissiveCoef: even if the stdMatEmissiveCoef values are intended to "lit up" an object, low values can add a warm/cold feeling to your glass.

[WesHowe]

Another very important function of the MATD is to hold information about the blend mode.
Among the other things, the blending lets the user alter the look of the object, adding to the texture transparency, color, brightness, light/shadow patterns and so on.


I have found this thread quite 'illuminating'.
I found that if you specify blend, but don't supply the right type of texture for that, you get a black/blue object, the same as if you had no texture image at all.
That took me a while to track down, as I spent some time trying to figure out a naming issue that wasn't there. When I changed it from blend to none, everything worked well.
<* Wes *>

[Numenor]

I have found this thread quite 'illuminating'.
I found that if you specify blend, but don't supply the right type of texture for that, you get a black/blue object, the same as if you had no texture image at all.
That took me a while to track down, as I spent some time trying to figure out a naming issue that wasn't there. When I changed it from blend to none, everything worked well.
<* Wes *>

That's very interesting. So, the "stdMatAlphaBlendMode=blend" *requires* an actual texture to work correctly. Thanks!

[Hairfish]

Thank you all for this conversation. You gave me enough courage to go into the Material Description and start playing around, and in the process, I discovered how to fix several hanging lamps that I'd almost tossed ~ they glowed green when they were lit. That wouldn't be so bad if they weren't red lamps. :blink:

Changing the stdMatEmissiveCoef to a warm-red RGB (0.8,0.09,0) solved the problem, and I now have lamps that glow red when lit. :)

Setting those RGB values to a matching color will let you light a lamp in any appropriate hue. This affects only the color of the lampshade, not the color of light cast on walls, floors, or other objects.

[Numenor]

...they glowed green when they were lit. That wouldn't be so bad if they weren't red lamps.
LOL! :)

Changing the stdMatEmissiveCoef to a warm-red RGB (0.8,0.09,0) solved the problem, and I now have lamps that glow red when lit. Setting those RGB values to a matching color will let you light a lamp in any appropriate hue.
I'm so glad that even an academic discussion like this could lead to positive practical results... :)

This affects only the color of the lampshade, not the color of light cast on walls, floors, or other objects.
Take a look at THIS THREAD (http://forums.modthesims2.com/showthread.php?t=4727): it's quite old, but I think it's very interesting and useful!

[HoneyB]

I had a question about using the alpha of an object to create transparency.

I made some glass panels on a door (no RG it's not THAT door thank goodness! LOL) so I turned the blend on but I noticed that the frame now blends as well & I can see it slightly coming through the edge of the door...not overly bad but enough for me to notice. So I opened the file for the Moroccan Screen because I know that parts of it are transparent & I studied it. :) I saw that while the alpha had black sections to make it see-through, the blend mode was set to "None".

How can parts of an object be transparent with the blend mode set to none?

-B

[trombones03]

This topic has since changed directions, but I'll say it anyway. It is just a thought and I have no idea if is even remotely true, but in another thread, someone (was it wes_h?) that was trying to figure out the process of how the slice of cake was removed from the whole. I haven't read that thread in a while, so i don't know if he figured it out, but maybe that BHAV that Inge Jones mentioned is how it is done. The BHAV turns part of the cake nvisible, giving the appearance a slice was taken. I dunno, just an idea that crossed my mind.

[RGiles]

Trombones,
That conversation was me talking to myself about how the cake slices disappear. :D I found where it's done in the BHAVs. But I still think I'm missing part of it.

HoneyB,
I just cloned the screen so I could look at all the MATDs and textures. Some of them are "blend" and some of them are "none" and I don't know why. We just don't know enough about these yet. My guess (and I really do mean guess) is that if there is a texture image with transparency, "none" will give you binary alpha (you'd have visible and invisible, but nothing in between) and "blend" will give you a full range of semi-transparent states. The sceeens with then more complex patterns in terms of the transparency use the "blend" mode. So it's a guess, but not really an answer.

RG

[trombones03]

Ok, I couldn't remember who it was. I thought it might have been you, but I couldn't remember. I'm glad you figured most of it out.

[Inge Jones]

Could explain why the cheap shower only responded to render alpha 0 for full transparency and anything else was opaque.

[Numenor]

Inge, this question has still no response, for me. I can only suppose that the Render Alpha operator serves to another purpose: make an object "vanish", applying a transparent texture to it.

Anyway, make some tests with the semi-transparent shower I've made (see attached file).
I've used a DXT3 texture, with a proper alpha channel.
In the alpha image, the white parts makes the texture look solid, while the grey parts create a semi-transparent effect (there are no black parts, that would look completely transparent).
In the MATD, the stdMatAlphaBlendMode is set to "blend".

If you compare it with the original shower, you'll see that the alpha channel is completely white (texture completely solid) and the stdMatAlphaBlendMode is set to "none".

Maybe the Render Alpha will have different results with a semi-transparent object...

[Inge Jones]

I've downloaded that and will look at it. It puzzles me that they gave us the render settings in a long integer field if they only needed to be a flag though.

Later... Hmm now when I tried making a shower transparent by importing an alpha channel - I tried doing a completely black one - all that happened is the shower was black in the game. It was some time ago, maybe it was a SimPe problem. I might have tried it just as Quaxi was fixing a bug or something.

[HoneyB]

Ok RG...well that makes sense. But I tried to reproduce the effect that the none blending screen uses on the door but I can't get the transparent parts to be clear without using blend. I'll keep trying different things to see what they do. Thx. :)

-B

[Numenor]

HoneyB, what door are you working on? A plain wooden door ar a multi-part door? Just to know...

[Numenor]

You ask why 0-255 if it's only a toggle? Well in my time with The Sims I have come across zillions of quirks where I thought "Why on earth did they do it like that?!?!" :D

You told that... :D

[Inge Jones]

I'm not immune to being bewildered or puzzled though <giggle>

[HoneyB]

Plain wooden Numenor. The Justadoor cheap door. :)

-B

[RGiles]

B,
Don't forget when you're working on the doors that they all need 2 Material Overrides, one for placement on a straight wall and one for placement on a diagonal wall.

RG

[Numenor]

OK, I think I have another bit to add to this MATD "encyclopedia".

The stdMatAlphaTestEnabled should be set to 1 in order to declare that the texture uses an Alpha channel. In this case, the stdMatAlphaBlendMode can be set to none

On the other hand, if we set the stdMatAlphaBlendMode to blend, the game seems not to apply the Alpha channel to the texture, but applies the general blending factors (set in the MATD itself) to the whole texture.

Let's say that stdMatAlphaTestEnabled stands for stdMatAlphaTextureEnabled :D

Anyway, here is what I could do (look at the picture).
Mind that, unlike other more complex doors, in this case the "glass" is just a part of the main texture: it can be made more or less transparent by modifying the "grey" level of the Alpha channel in the texture, but can't be coloured usinf the stdMatDiffCoeff (unless you want to add some colour to the whole door... :))

[Inge Jones]

Ooh those do look good! <slobber>

[RGiles]

Numenor,

"On the other hand, if we set the stdMatAlphaBlendMode to blend, the game seems not to apply the Alpha channel to the texture, but applies the general blending factors (set in the MATD itself) to the whole texture."

What???? :D

stdMatAlphaTestEnabled=1 has confused me a lot. How different objects will and won't take transparency or different types of transparency has confused me a lot.

Eeek.
RG

[RGiles]

stdMatAlphaTestEnabled=1 doesn't seem to work if the blend mode is "none". It has to be 0 in that case. If you want to use binary alpha (no shades of grey), then blend mode would be "blend" and stdMatAlphaTestEnabled would be 0.

That is what I *think* I know. Does it sound true?

RG

[Numenor]

The first thing I have tried with the door was to load an alpha mask into the texture ("grey" alpha, not simple binary) and set the Alpha mode to blend and something strange happened: Looking from inside the house, I could only see the inner face of the outer side of the door (can't explain better, I fear); the inner side of the door was completely transparent.

I guess that either we haven't understood enough all the parameters of the MATD (and of course we haven't...), or those parameters are applied in a different way for different objects.
I only know that *for this door* the blend mode must be set to "none".
I'm attaching the package.

But I'm sure you are right for other objects; so we have "just" to discover why it happens :)

[HoneyB]

That is exactly what I meant Numenor about being able to see the frame blending from the other side! :)

I tried doing the doors your way...leaving the blend mode at "none" & changing the "stdMatAlphaTestEnabled" to 1. I found out that only shades of grey #808080 or darker on the alpha gave me the transparency effect. Anything lighter was opaque. See here:

http://img.photobucket.com/albums/v14/HoneyB/Posting%20Pix/GlassPaneDoors.jpg

The one on the left is set to #959595 while the one on the right is #808080. What was your grey shade for your door?

RG...I forgot about having 2 overrides! :( The funny thing is I placed this new door & saved the game. When I went back in, it was still there & I tried it on a diagonal wall as well. Do I need to do the second override for something else? And if I do, where do I get it from? :)

-B

[RGiles]

The normals are bing inverted... it's the same thing that happens on the cheap shower. I can't understand it at all. :( It's just something I've seen on other 3D models. It's like you're looking at the object inside out, sort of. Hard to describe.

When you set the blend mode to "none" though, you only have the binary transparency, correct? I have never been able to get full transparency with that setting (which is where I came to a dead end with the floor tiles as well).

RG

[RGiles]

I'm not sure. Maybe not all the doors need 2 overrides? They do have different GUIDs. I was just basing it on the clone I made of the other door that you sent me, which had 2 overrides for each color of each part.

RG

[RGiles]

Numenor,

Have we informed Quaxi yet of the error in the way the MATDs are being built? For the links to the TXTR, it's leaving the hash off. We've determined before that this makes retextures unstable, and I'm concerned that a lot of people are making a lot of recolors this way.

RG

[Inge Jones]

I think Quaxi is still on holiday?

[Numenor]

HoneyB, my alpha had a gray at 0x65/65/65.
So, there's a threshold at 0x80.... So, RG and I were both right, after all: the transparency is set by the texture's alpha channel, but *it's* a binary alpha, not a shaded one...
This means that the glass part of the door actually... it's a hole! :) We can't add color, brightness or (that's bad) reflectivity to it.
This explains why in the original doors the glass part always have a separate mesh and subset: in this way a "real" transparency can be applied over the whole mesh, in blend mode.

[RGiles]

numenor, how did you find the threashhold? and is there a chance we can change it?

It's strange because this affects only some parts of some objects.

RG

[Numenor]

HoneyB has found that threshold... Haven't I understood well her post?
Any value more "white" then 0x80/80/80 makes the texture look solid, while any lower level makes it look fully transparent.

[RGiles]

Nope you unserstood it right. :D I missed it.

Now that's using blend mode = "none" and we can change that threashhold. That's the one I was talking about before. We normally see stdMatAlphaRefValue=127 ... when we change that, we change the threshhold. But I misunderstood it before, I think. Now I believe it has no effect if blend mode = "blend".

Did you try "additiveblend"? it makes the object look like the ghosts. :D

RG

[Numenor]

We normally see stdMatAlphaRefValue=127 ... when we change that, we change the threshhold. But I misunderstood it before, I think. Now I believe it has no effect if blend mode = "blend".

Did you try "additiveblend"? it makes the object look like the ghosts. :D

RG

Yes, my tests lead to the same conclusion about the stdMatAlphaRefValue being the threshold value for the Alpha channel.

I haven't tried the additiveblend mode, yet. Seems interesting but... what use can we do with it? Maybe it *was* created to render the ghosts, after all...! :)

[RGiles]

It may very well have no use but the ghosts... well, lightbulbs would work. Funky disco decoratives, maybe. But it's not terribly useful.

RG

[trombones03]

Additive looks like an object does when it is not placeable - like if you try to place a painting anywhere besides a wall. I compared an addititve object with one that was unplaceable and they looked the same. Just an observation.

[Numenor]

And the additiveblend mode seems like when you hover the pointer over an object while in Design mode (the objects "lits up" and become transparent).
Maybe these alpha modes were actually created as "service" modes to be used only in the UI...
But I trust the great inventive of our modders/recolourers :)

EDIT:
I was almost forgetting again: RG, what a little cute Avatar! Finally... I coudn't stand any more your lacking of an avatar: now I can spot your posts much easier! :D

[Numenor]

Well, it's time to say something more about the MATD...

Relations between Alpha Channel and Blend Mode

As you know, the Alpha Channel embedded into the texture tweaks the transparency of the texture itself: the more "black" the Alpha is, the more transparent the texture will look.

But the texture itself is affected by the stdMatDiffCoeff and the stdMatEmissiveCoef MATD values.
Actually, the texture act like an "Alpha" image, regarding those values: the more "white" the texture is, the more visible will be the effect of the "Diff" and "Emissive" coefficients.

To make it clear, let's take a look at the attached images: the first depict a test texture, and the second is the associated alpha channel; when combined, the texture will look like in picture 3.
Let's apply this texture to a window.
If we set the DiffCoeff to 1,0,1 (purple) and the EmissiveCoeff to 1,1,1 (white), we'll have the result depicted in picture 4.
As you can see, on the right of the window the glass is fully transparent (because the Alpha channel is plain black); on the left site there is no transparency at all, and the effects of the MATD coefficients are visible.
In particular, going from the upper to the lower part, the MATD coefficients show more and more their effect, as the colour of the texture goes from black to white.
In picture 5 there is the same glass, but with the Alpha channel stripped off; it shows clearly how the MATD coefficients modify the appearance of the glass: no effect at all in the upper part (texture black) and full effect in the lower part (texture white).

[kellymichele]

Ok, since all input is welcome...here is a little from someone with the lowest level of knowledge. However, my problem was with the shiny things dishwasher...not with glass or transparency. I made counters and decided to add matching appliances using the same texture and adjustments. As you can see in the first pic...the trash compactor blends perfectly. I then recolor the shiny dishwasher in the same manner and get the dishwasher shown in the second pic. I did everything...darken, etc, but always got the same results. After reading this thread, I changed several values in the matd editor for the dishwasher using the compactor matd properties as a guide. (Here are the values changed: reflectivity, stdMatAlphaBlendMode, stdMatEnvCubeCoef,stdMatEnvCubeMode, stdMatSpecCoef,stdMatSpecPower) After doing this, as you can see in the third pic, the dishwasher to the far right now matches the compactor. Of course, as a beginner, I'm really not sure if changing all files was necessary, or if maybe just 1 or 2 would have done the trick. Anyway, I thought this might be of some help to someone. Thank you, numenor, for starting these types of threads, and to all of those who contribute as well. It is very helpful for beginners like me.

[RGiles]

Very nice work. Changing them all was probably good, because some small difference still might have been noticable.

RG

[kellymichele]

Thank you...now on to the elegant chef gas range...I'm having similar problems with it. Thanks again for your help.

[Leman0]

I'm trying to make a genetic skin translucent. I've had some success so far but I can't get it to look quite right. Can anyone recommend settings which will make a skin texture translucent while keeping its current colour?

[Numenor]

Try lowering the "stdMatUntexturedDiffAlpha" parameter (usually, it's the last line) to a value less that 1.
If you notice no effect, set the "stdMatAlphaBlendMode" to "blend".

[Leman0]

Try lowering the "stdMatUntexturedDiffAlpha" parameter (usually, it's the last line) to a value less that 1.
If you notice no effect, set the "stdMatAlphaBlendMode" to "blend".

Unfortunately that was one of the first things I tried. It seems that 'blend' mode doesn't behave the same for skins as it does for other materials (unless there's some setting I'm missing). Using blend has the weird effect of making the parts of the body which should be hidden show through e.g. if I turn the sim sideways the foot which is furthest away - and should therefore be hidden by the closer foot - shows through, overlaid onto the closest foot. The additive mode does have better results, in that it is properly translucent, but it looks too bright for my purposes.

First pic is of 'blend' mode, the second is 'additive' mode.

[Numenor]

I'm sorry, seems that complex textures like this behave in a different way compared to objects ones...

[xanathon]

There's something I am misssing completely regarding transparent materials or so it seems. I was able to manage when building my objects, I even was able to include new MATD files in those and link correctly to them.
But now I try to do something with transparency and though I have read a lot of posts regarding that topic (and others, as about the RCOL chain) I wasn't able to get a submesh transparent, they all appeared flashing blue, as if I was not pointing to a valid MATD in the SHPE data.

I tried making an existing texture transparent by setting the stdMatAlphaBlendMode to blend. (Question: Do or don't I need an alphachannel for this to work? I got that never really clear) In all my tries you could always only see the texture as defined in the TXTR file or the dreaded blue flashing object.

(EDIT: I figured this one out. My problem was, that the needed alphachannel is named layer mask (ebenenmaske) in the germen version of photoshop and an alphachannel is something different. I should have thought of that, since I had a similar problem in a videoeditor. Textureeffects tweaking the MATD are now in the works... :o)

I also tried to import an existing glass, for example that from the microwave oven, and to tweak the settings and names and then to point the submesh in the SHPE file to that, but always to the same effect: flashing blue object.

Maybe Someone would be so kind as to take a look at the attached object, were I tried the latter.

After two days of pointless experimenting I am a little frustrated (okay, I caught a bad cold and so my thinking is a little impaired atm, maybe this is the cause for my dumbness :o). Maybe I am missing just a tiny bit and need to be nudged in the right direction or maybe I'm doing something basic completely wrong, I just don't know.

Any help would be highly appreciated!

[Numenor]

Xanathon, it's not only a MATD problem.
The first thing I noticed is that the "xanathon_glass" MATD had a bad TGI: the group was 0xFFFFFFFF, the Instance 0x00000001 (like a MMAT).
I changed the Group to 0x1c050000 and then I clicked Fix TGI.
Now the object, instead ob being fixed, crashed my game.

After a little more investigation, I discovered that you deleted some entries in the GMND (all the shadows), but you forgot to update the Indexes (or "Indices", as it should be sayd :)).
Look at the picture: every time you remove or add a block in the GMND, you have to modify the "Datalist Extension Reference".

[xanathon]

Thank you very much for these explanations and sharing your insights! :howdy:

I will do further experiments.

[xanathon]

Okay, I looked into that and I understand it, but how do I tell what cDataListExtensions that I delete in the "Edit Blocks" tab correspond to which Datalist Extension Reference entries in Content/cObjectGraphNode?

You showed the ones in your picture but I have no idea how I can tell which are the ones to delete.

[Numenor]

No, there's not a relationship between the cDataListExtensions and the entries in the Index list: simply, if you delete 4 extensions, you have to delete 4 Indexes (the last ones in the list). :)

[xanathon]

Some findings about animated textures.

After I saw Oberkorns krystals and Maxis' lost sphere, I thought about doing a palantir (it was also requested in some thread). My main idea was to try and find out something or the other about the animated textures. As a byproduct my Magic Sphere was created and I decided to share my knowledge thus far here in the MATD encyclopedia.

Here goes:

stdMatTextureCoordAnimMode none, tile, transform, scale, (rotate?)
With this property set to "tile" you tell Sims 2 if you are using the bitmap registered at stdMatBaseTextureName as the source for animation frames.
I saw the transform entry and I tested scale, both did something, but I could not really find out what, yet. "rotate" is pure speculation atm. So let's stick to the tile-animation for the moment.

stdMatTextureCoordAnimNumTiles c,r (columns, rows)
Here you set the number of tiles in the beforementioned bitmap. If you choose 4,4 for example, your bitmap will be divided into 4 rows of 4 columns of smaller images, which are used as (16) animation frames.
The original texture-coordinates have to be applied to the whole bitmap however, Sims 2 scales the smaller frames accordingly (first I thought I had to map my object to one of the smaller frames, but I was wrong).
The first animation frame is that in the upper left, then they are used left to right, row by row.

EDIT: I changed the order of r,c, after I looked into one of the pinball machines.

stdMatTextureCoordTfAnimOrigin x,y
I'm not really sure about this property, since nothing seems to happen if I change it. I had the idea, with this I could probably assign an area of the animation-bitmap to be left out of the declaration of animations frames (example: upper half of your bitmap is static, while the lower half conatins animation frames), but further research is in order, I fear. Maybe someone has something to contribute here.

stdMatTextureCoordTileAnimSpeed frames(/sec)
Sets the framerate and thus the speed of the animation. It seems to be roughly frames per second.

Nothing more about ...Rot..., ...Scale... and ...Trans... atm, but one can make an educated guess, that with the first two properties you are able to rotate and scale an animation. With Trans(form) you are possibly able to move an animated bitmap around on your object, that's my guess, because it is used to scroll the screentext of the teleprompter. Those are subject to further testing, however. If I find out more, you will hear (or better: read) about it. :o)

[Numenor]

Thank you Xanathon for your contribution.
The "Anim" section of the MATD is still a mystery to me, and I'm glad that Oberkorns first opened this Pandora vase... :)

I have made no tests at all, but I can point out some other Anim parameters that can be found in the MATD, along with some values that they can assume:

stdMatTextureCoordTfAnimRotSpeed
0.000000 - 0.750000 - 16.000000 - 0.200000 - 1.500000 - 1.000000
stdMatTextureCoordTfAnimRotStartEnd
0.000000,1.000000 - 0.000000,0.040000
stdMatTextureCoordTfAnimRotWaveform
triangular - sawtooth
stdMatTextureCoordTfAnimScaleSpeed
0.000000 - 0.200000 - 1.500000 - 0.800000
stdMatTextureCoordTfAnimScaleStartEnd
0.000000,1.000000 - 1.000000,2.000000 - 1.000000,7.000000 - 1.000000,20.000000
stdMatTextureCoordTfAnimScaleWaveform
triangular - sawtooth - sine
stdMatTextureCoordTfAnimTransEnd
0.000000,0.000000 - 1.000000,0.000000 - 0.000000,1.000000 - 128.000000,32.000000
stdMatTextureCoordTfAnimTransSpeed
0.000000 - 1.000000 - 0.100000 - 3.000000 - 0.750000
stdMatTextureCoordTfAnimTransStart
0.000000,0.000000
stdMatTextureCoordTfAnimTransStartY
0.000000
stdMatTextureCoordTfAnimTransWaveform
triangular - sawtooth


Seems that lots of things can be done with this parameters: rotation, transformation, scaling (even with a pattern: triangular, sawtooth and sine...).
I hope that someone would run some tests: what interesting objects can be created with animated textures!

[Saiz08]

Ahhh to many to remeber it would be really easy if some one just made a list of some of the things you can do with the matd files

[Numenor]

You're right, but it wouldn't be easy to write such list, because the MATD has a million different parameters and purposes :)

Basically, everything related to the external appearance (not shape) of the object is commanded via the MATD: texture, transparency, diffuse colour, specularity, reflection, animated texture (e.g. the flashing red light of the TV).... Too many to mention.
That's why I've created this thread: to let everyone give his contribution on this huge subject.

[harpy0]

Okay, here is my contribution. I'm not 100% certain of what I'm about to say being absolutely correct, but I'm 100% certain of my experience attempting to create stainless steel, and large matching sets. I've kept records; here they are:

Please correct me if I am wrong.
These settings were constant through my experiment:
stdMatEmissiveCoef: 0,0,0
stdMatEnvCubeBlurFactor: 0,0,0
stdMatSpecPower: 12

stdMatEnvCubeCoef: 0.9,0.9,0.9 (the most reflective) or 1,1,1 (the least reflective).
My Scarborough cabinets were set to 0.25,0.25,0.25. Typing 0.9 for each gave me undesirable results. (see picture labeled #1 where the settings are 0.65,0.65,0.65). It's not set to 0.9, but it gives a basic idea of how big of an effect the number change is. Multiple colors tend to be seen when you rotate the screen, like a mirror effect. The higher the number is, the less visible the actual color tends to be. You basically have to be at a certain angle to even see the actual color.

stdMatSpecCoef: 0.99, 0.99, 0.99 (for brighter edges, handles, and corners) or 1,1,1 for less bright edges. (see pic # 4)

If stdMatEnvCubeMode: is set to "none" then it disables the reflectivity caused by the stdMatEnvCubeCoef. I don't know if the stdMatEnvCubeMode
has other uses, but I know that stdMatEnvCubeCoef seems pretty useless without it.
One more thing:
While recoloring Frances's Zen Dining Room, I noticed that the material definitions of the china cabinet (buffethaut - sorry, I only speak English) were quite different from the table and sideboard. no matter how I recolored it, it never looked right. I edited the Matd's so that they were identical to the sideboard and table, and now the cabinet looks the same as the rest of the set.
The more the Matd's are alike, the more the textures are alike. Without fail.

A question: Does anyone know why I am seeing equations (x+y) in recolors with a high setting on the stdMatEnvCubeCoef. It appears that the lower my settings are, the higher elevated (less visible) the equations are.

This may be common knowledge by now; this may help no one, but then again . . . it might.

[Numenor]

Thank you Harpy for your much appreciated contribution!

The thing that most puzzles me is the way the stdMatEnvCubeCoef modifies the transparency of the object... It shouldn't, as far as I know.
I'm curious, and I'll run some more tests with different values of stdMatEnvCubeCoef, while keeping all the other parameters to an average level.

In your tests, you wonder how come a stdMatDiffCoeff of 0,0,0 prevents your solid red colour to appear. It's normal: the DiffCoeff determines the "diffusion", i.e. how much the base colour is visible. If the object has not a texture, the DiffCoeff determines the colour of the surfaces. If a valid texture exists, the appearance of the texture is "bended" toward the RGB value contained in the DiffCoeff. Therefore, a DiffCoeff of 0,0,0 brings the texture colour toward the black.

On the other hand, I thought that the EnvCubeCoef determined the colour of the EnvCube texture: 0,0,0 = the EnvCube reflection is shown with very dark shades; 1,1,1 = the EnvCube is shown with very bright shades; other RGB values = the EnvCube reflection is "tinted" with the RGB value.
But seem that I was wrong, or at least it's not that simple: that transparency effect was not expected...

In your tests, the stdMatAlphaBlendMode is set to "none" (= no transparency)?

[harpy0]

I had to check to be sure. Yes, it was set to none through all of the testing. I have only recently started learning to recolor glass, and I didn't use it because I didn't know what it was for.

I did have to set EnvCubeMode to reflection to get these results though. If it was set to none, I saw no reflective properties, of course.

Do you think that is what is causing me to see these equations. (See pic below). I suppose it was not intended to be used that way, but it can obviously be manipulated. The numbers can be tampered with to where the equations are not visible, or at least higher elevated. The in-game camera cannot come low enough to the surface to view the equations.

All I can say is that the closer EnvCubeCoef is set to 0.999+, the more visible the equations are. This really drives my curiosity.

[harpy0]

Well, it's been four days, and I've answered my own question about the equations. It turns out, I had to add a new material definition to get rid of them.

This stuff is starting to make a lot more sense now.

[Numenor]

Sorry, Harpy, I missed your last post...
I only wanted to point out that when you set the EnvCubeReflectionMode to "reflection", you have to specify a valid TXTR in the stdMatEnvCubeTextureName field, otherwise, the game can't render the reflection.

Infact, there is a difference between "reflection" (correctly, EnvCube reflection) and "reflectivity": the former uses a texture (the EnvCubeMap) to create a fake "environment" reflection (like the trees that can be seen reflected on the taxi windows); the latter is only a "shineness" parameter, that determines how much the surface reflects the light.

If in the MATD there isn't a stdMatEnvCubeTextureName field, you can add it; but you'd better use a MATD that already has the stdMatEnvCubeTextureName field (and presumably has the stdMatEnvCubeReflectionMode already set to "reflection"

[Inge Jones]

I got writing on one of mine using the description in this thread, then I noticed a texture name for the reflection mapping had been spelt wrong in the message (sliver instead of silver) when I corrected that in my MATD I stopped getting the writing on the object.

[harpy0]

To Igne Jones: I did not change any spelling, and fixed the visible equations. Numenor was right.

To Numenor: Why did you say "you'd better use an MATD that already has the stdmatEnvCubeTextureName field"?
I added TextureName and didn't seem to have any problems, but if this causes problems, please let me know as I have sent the MATD settings to a mesh creator.

[Inge Jones]

Harpy, that doesn't mean there wasn't a misspelling in the MATD you replaced. I can tell from your spelling of my name that you are prone to the occasional typo :)

[harpy0]

Gee thanks, and I did not not replace a MATD. I added one that was not there to begin with.
And I was not saying that your method did not work for you. I checked the MATDs that I was using before I posted, the before and after MATDs, and there was no typo in mine. I don't know how many objects you found typos in, but it is unlikely that I had typos in dozens of unrelated object MATDs.
P.S. Can I just call you "Bob" as I am less prone to mispelling "Bob"? :)

[Inge Jones]

Sure, Bob will do fine :D

[chrissy6930]

I am playing around with the MATD lately. thats what I figured or at least think I figured:

I checked out a mesh that has a recolorable part and an additional MATD. the second MATD has blend mode set to blend, blendstrength set to 0.200000, speccoeff set to a dirty yellow, diffcoeff set to a medium grey and diffalpha to 0.97. the default texture is medium grey and its MATD has medium grey coeffs everywhere. I figured that the chrome appearance of the item results from the additional mesh MATD. once the diffalpha is set to less than 1 and blendmode is set to blend u can make your texture blend to the color entered in the speccoeff.

now I intended to get some other colors. thus I went and created recolors that appear gold, orange/copper, red, purple, light green and light turquoise ingame - all this with a darkened silver texture. once a 'prop group' with a coeff is enabled u can add a color and make them overlay the texture.

having figured that out I intended to tweak reflectivity. the MATD of the texture has cubemode set to reflection and reflectivity set to 0.5. while the envcube props do not look like I could do anything about the 'degree' of the effect reflectivity certainly looks like a percentage in decimals. thus I tried tweaking it by using diff parameters for reflectivity. only: no change at all ingame! how annoying! then I thought I might add reflectstrength. maybe that prop needs s.th. additional to be tweaked the way I wanted. I again tried diff parameters (format: 0.000000) in combination with reflectivity. while the game didn't mind me adding that prop it sure didn't change anything about the ingame appearance either.
what exactly does it take to change the degree of reflectivity? I aimed at making the surface appear matte or at least less reflective...

s.th. else I couldn't figure while recoloring windows is the emissivecoef. its supposed to tweak the brilliance/ inner light of glass provided blendmode is set to blend. now with a window blend mode is certainly set to blend only why do I not see the slightest diff when compared to the 'default' black? what exactly am I supposed to see when entering a color to the emissivecoef??

[Numenor]

Emissive coeff are intended to be used with opaque textures (blend=none), not transparent ones (though the Emissive should be visible on transparent textures, as well). Note: the emissive RGB parameters can be higher than 1.0.

As for the various reflectivity parameters, I've never understood completely what each of them is supposed to do. I usually enhance reflectivity by lowering the "Reflectivity" parameter, and it works to me (especially with glass, but it works on metal surfaces, too).

Last note: I'm not sure to have read well your experiments, but if you add one or more entries to the MATD, the game won't read them, unless they are in alphabetical order (the next release of SimPE will have a "Sort" function for the MATD).

[Mage]

I just discovered and read this thread. Now my head is spinning and I'm wondering how, understanding as little as I do, I have managed to make anything. Well the answer is that people like those who have contributed here have also made step-by-step instructions for people like me. Thanks to you all. I'll have to read everything here over several times and then see if I can use it. The answers to several of my previously unanswered questions are here if I can make sense of them in my fuzzy little brain.
Thanks to everyone who has given me all this new information.

[Mage]

Theres a bunch of stuff on the wiki about MATD already :)

http://www.modthesims2.com/wiki/49596978

Btw, this link is dead. What is wiki? Is there anywhere else I can find this information?

[Numenor]

The link you've posted works for me (at least, it's working now...).

The Wiki is a sort of Encyclopedia that contains all the things we know about the game; everyone can add his own findings.
If you have read the message you have quoted, you have probably read my reply, too: I don't like the Wiki very much, seems so unfriendly... Though it's a great idea, and it might have had more success among the users.

The home page of the Wiki is: http://www.modthesims2.com/wiki/
You need to register (the login to MTS2 isn't valid, there).

[Mage]

Thanks. It's working for me now, too. Not that I know what to do with all that information. But I like to think I am graduallylearning a little.

[Mage]

Yay! kitchen appliances that actually match each other perfectly. Thank you so much to everyone who posted here and gave me this valuable information.

[IgnorantBliss]

Since the abbreviation for Material Definitions is TXMT nowadays, and not MATD, it might help to avoid confusion to update the title of this thread :) (No, I'm not anal or anything :lol: )

[Inge Jones]

Why did it change, I wonder?

[IgnorantBliss]

Why did it change, I wonder?

I don't know, I liked MATD better :lol:.

[Inge Jones]

So did I, it was less easy to keep getting mixed up with TXTR

[Numenor]

Yes, I don't like TXMT, either; btw I never remember if it's TXMT or TMXT...
It was changed because, at first, SimPE coded the files using the definition readable with the hex editor, and these files contained "Material Definition" (hence the abbreviation MATD); then, we realized that all the scenegraphic files have an extension, which in this case is "_txmt".

Anyway, IgnorantBliss, you are right, the thread title should be changed; after all, even in the Wiki the file code has been changed: now it's "TXMT (formerly MATD)". I'm going to change the title.

[Mage]

I just have to thank you all again. I can't believe what I can do after reading this thread. Ijust made a buffet table with a glass top. Thanks for all the great info, everyone.

[Mage]

This question comes from almost total ignorance, I'm afraid. I was wondering if there is a way to have color choices for parts that are glass and have no texture. I'm thinking maybe you could have more than one material definition for the material...

[IgnorantBliss]

This question comes from almost total ignorance, I'm afraid. I was wondering if there is a way to have color choices for parts that are glass and have no texture. I'm thinking maybe you could have more than one material definition for the material...

Yes, you can recolor glass that has no texture, but if you mean that the same subset would have more than one color at the same time, that's not possible without texture. With separate subsets you can have more than one color at a time.

[Mage]

Yes, you can recolor glass that has no texture, but if you mean that the same subset would have more than one color at the same time, that's not possible without texture. With separate subsets you can have more than one color at a time.

But for color options you would need to make new recolor files, right?

I know this thread is to gather knowledge together but is it ok for me to ask my rookie questions here?
If so here's the next one. I'm making a bedroom set. First I made a bed. Thanks to IgnorantBliss' tutorial the bed is made of wood and glass.
Then I made an armoire and an end table.
I replaced the material definition for the glass and the wood parts, for each with the ones from the bed, each time copying the filename first and then pasting it in after.
In the wood txmt files I changed the stdMatBaseTextureName to the name of the texture for each object minus the txtr at the end and plus the ##0x1C050000! at the beginning.
And everything turned out great except the wood part of the armoire and the end table ended up with numbers and letters instead of my texture.
So I started again with those two objects and each time with the txmt for the wood I just copied each line from the one for the wood on the bed.
And that worked fine, and I'm happy with the result.
But why didn't it work when I replace the whole files?
If anyone reads all that, thanks. And if you can make sense out of it and tell me what I should do next tim
e thanks again.

[IgnorantBliss]

But for color options you would need to make new recolor files, right?

I know this thread is to gather knowledge together but is it ok for me to ask my rookie questions here?
If so here's the next one. I'm making a bedroom set. First I made a bed. Thanks to IgnorantBliss' tutorial the bed is made of wood and glass.
Then I made an armoire and an end table.
I replaced the material definition for the glass and the wood parts, for each with the ones from the bed, each time copying the filename first and then pasting it in after.
In the wood txmt files I changed the stdMatBaseTextureName to the name of the texture for each object minus the txtr at the end and plus the ##0x1C050000! at the beginning.
And everything turned out great except the wood part of the armoire and the end table ended up with numbers and letters instead of my texture.
So I started again with those two objects and each time with the txmt for the wood I just copied each line from the one for the wood on the bed.
And that worked fine, and I'm happy with the result.
But why didn't it work when I replace the whole files?
If anyone reads all that, thanks. And if you can make sense out of it and tell me what I should do next tim
e thanks again.

You could post your problem packages in the subset adding tutorial thread and I could take a look :).

[Mage]

You could post your problem packages in the subset adding tutorial thread and I could take a look :).
Thanks, next time I will. I don't have those ones any more as I used a work around toget them right.

[chrissy6930]

Mage: I've had the same 'paper print' a couple times myself. for me replacing the MATD only works if I do the following:

copy the name of the MATD there without the '_txmt'
replace the existing MATD with that of your choice
now mark the name of the MATD excluding the '_txmt' and paste
PLUS go to MATD - cMaterialDefinition - description and paste as well
perform FixIntegrity

without pasting the name into the description FixIntegrity will make the MATD filename revert back to the one of the imported file.

the above appears to be only necessary if the MATD filename is different from the TXTR filename. otherwise a simple pasting over the MATD filename seems to be sufficient

donno if there is a more straightforward way 4 this though...

[Numenor]

When you replace a MATD with a different one, the texture reference must always be checked and fixed (if the MATD has a texture reference...). That's why the new MATD obviously keeps the reference to the texture contained in the object it was extracted from.

On the other hand, you are right when you say that the old name should be copied befor the replacement, and pasted again after the replacement: this way the internal links of the package won't be broken (in particular, the reference to the MATD contained in MMAT and SHPE).

[chrissy6930]

Numenor: well yes ! only I am not referring to the addition/ editing of basetextureprops I am afraid...

instead I really mean the MATD filename itself:
a while ago I recolored a bunch of doors and windows both Maxis and meshes. and a couple Maxis items had the above mentioned prob. let me show u what I mean with an example.
my recolor package of the Octothorp window looks like this:
MATD filename: windowfourtilewideatrium_windowtrim_wood_txmt
basetexturename: ##0x1C050000!windowfourtilewideatrium-wood

the highlighted parts of the two filenames obviously are different. in that case I had to use the first mentioned procedure to replace the existing MATD.

recolors of other windows/ doors came with MATD filename and basetexturename being identical and thus I could get away with just pasting the original MATD filename over the one of the imported one...

[Mage]

Mage:
PLUS go to MATD - cMaterialDefinition - description and paste as well


Ok, this is the part I missed. Thanks.

[Numenor]

recolors of other windows/ doors came with MATD filename and basetexturename being identical and thus I could get away with just pasting the original MATD filename over the one of the imported one...

Oh, now I understand...
It's not so frequent that different objects uses the same MATD or textures. Anyway, your suggestion were correct; I only pointed out that the texture reference, inside the MATD, should always be checked (at least, to be sure that it's the same :)).

[Reyn]

Wow, this was an unexpected find while trying to find one of my own posts. I've found a few oddities myself, while trying to make metallic and glass walls and floors, but since I don't remember what did what, I can't post them, yet.

Also, I noticed noone mentioned an oddity with this and clothing, so I will, and if I missed it, I'm sorry, its late for me. When doing clothing, you can either do transparent or shiny not both, at least (as I read) without doing a whole lot of work. There are two types of 'skin' types, SimSkin does transparent, and SimStandardMaterial does reflective.

Does anyone know if there are similar properties on Walls and Floors? I not only still want glass walls for making greenhouses and such, but also truely metallic floors and walls for making futuristic homes. Also, its become something of an academic interest, so as I figure out things, I'll try and update here. So far, most normal tricks don't work.

[Numenor]

Thank you Reyn, your contribution is very interesting; so far no one has posted anything about the Material Definitions related to Skins: it's a brand new subject to explore! :)

Since I'm not experienced in Skins (I usually only deal with objects), I'd like to understand better...

As far as I know, "Simskin" and "SimStandardMaterial" are types of Material Definitions, not parameters contained in a Material Definition.
In other words, if I open a TXMT into SimPE, I will find the "Type" in the cMaterialDefinition tab (there are numerour TXMT types: StandardMaterial, SimSkin, PhongTexture...), while the parameters can be found in the "Properties" tab (each type uses some common parameters, plus some typical ones).

Quickly browsing my SavedSims and my Downloads folders, I've found (but correct me if I'm wrong) that:
- StandardMaterial type is used for Objects
- SimSkin type is used for Clothing
- SimStandardMaterial is used in Sims and Genetics
- Floor, FloorPool and FloorReflective types are used for Floor tiles
- Wallpaper, WallpaperBump and WallpaperPool are used for walls.

As said, each of these TXMT types contain various parameters (some common to all types, some other specific for the single type), but each TXMT can have only one type.

With specific regards to reflectivity and transparency, examining the Maxis packages I've found that all the TXMT types named above contain the "reflectivity" and the "stdMatBlendMode" parameters, but some of them are never used:

SimSkin type may have different values for reflectivity (known values are: 0 = deactivated; 0.5 = average reflectivity; 0.2 = high reflectivity); the stdMatBlendMode is always set to "none" (= transparency deactivated).
SimStandardMaterial type uses the reflectivity much more intensely (I've found a lot of different values, ranging from 0 to 0.55); and the stdMatBlendMode can be set to "blend" (= transparency activated)

[Reyn]

Hmmm, I wonder if one of those other floor or wall types might have the answer to making a metallic. And I do want to play more with reflectivity. A friend told me my new metallic bodysuits are a bit to blinding when light hits them, and he's right, so I need to see if I can get that level of metallic without the bright.

[Numenor]

I can't check now, but if I remember well, all the walls and floor types have a "reflectivity" parameter. Try fiddling with it (remember that the lower the "reflectivity" value, the higher the reflectivity effect; but a value o zero deactivates the reflectivity).

What I still haven't understood is the purpose of the "type": I don't know if it's just a name or if it actually affects the object appearance.
For instance, two Material Definition that have exactly the same parameters, but different "type": will they act differently? I'd like to know.

[chrissy6930]

What I still haven't understood is the purpose of the "type": I don't know if it's just a name or if it actually affects the object appearance.
For instance, two Material Definition that have exactly the same parameters, but different "type": will they act differently? I'd like to know.

I donno about the appearance but a reflective MATD with cubemode set to reflexion when used on a floor will have the following effect:
StandardMaterial: a floor with whatever texture will show up black ingame and will have a black thumb.
in order to figure what s causing that bug I created 2 floor packages both with the reflective MATD imported - nothing else. now I went and deleted all but the first 2 or 3 props, submitted saved and checked it out ingame . reflectivity is one of the first props on my MATD and this was the first time I saw my tile in its real color ingame. then I went and either added a prop block or a couple single props. after each I checked it out ingame. after adding the cube props it was the first time I saw the black tiles again ingame. I tried to fix the tile again by deleting the cube props but to no avail: the package was irreversably corrupted.
soooo as I didn't like the idea of the props itself causing the bug I thought of what - in combination with the props - could cause it. and the only thing I could come up with - from within the MATD - was the type.
thus I dumped the corrupted package , went to the other one and changed the type to 'Floor', added all the other floor exclusive entries of a default floor package, and checked it out ingame. and voila it showed up fine...

[Numenor]

That's interesting. BTW, the MATD won't work if all the properties aren't in alphabetical order; SimPE has a "Sort" button for this.

[chrissy6930]

BTW, the MATD won't work if all the properties aren't in alphabetical order; SimPE has a "Sort" button for this.

yup ! I've seen that comment of your's a couple months ago and ever since I make sure to use that function... :)

[niol]

Wow, I wish I'd read this thread and the another ones earlier... it's really taking a lot time to find out how to set things right...
But, it's still good to fool around without any guideline... :bandit:

I lately made a newer recolour for the Matte Sphere... I used a photo of metallic object as the texture for it.
Then, I "set" (actually mess around many settings at a time.) the definitions as such... I've yet to understand more of what I did, but I really like the result.

http://thumbs.modthesims2.com/images5/MTS2_238468_niol_Numenor(MTS2)_SphereMatte_Moi_stand_Ag001.jpg


Added:
In my limited experience so far, it seems that


[for shadow txmt, ????..._????...shadow_alpha_txmt]
stdMatAlphaBlendMode=blend
0<stdMatAlphaMultiplier<1

[the normal frame or what]
stdMatAlphaBlendMode=none
stdMatAlphaMultiplier=1

[glass definitions] (These have amzing results...!!! :smash: )
stdMatEnvCubeMode=reflection
stdMatEnvCubeTextureName
=reflectionkitchenhighcontrast-envcube (mirror)
=outdoordaytime-envcube (car)

[chrome] (This one will give out a realistic metallic appearance...!)
stdMatEnvCubeMode=reflection
stdMatEnvCubeTextureName=reflectionkitchenhighcontrast-envcube (mirror)


Update:
OK, my bad, overlooked my own settings, it also takes
stdMatEnvCubeLockedToCamera=1
for the better metallic and glassy look



txmt types:
StandardMaterial (for object recolours, sims no-body-objects)
Floor (for floor tiles)
WallpaperBump (for wallpapers)
SimSkin, SimStandardMaterial (for hair, etc)
AdditiveTextureAlphaBlend (for shrine, lit spaces as in the case of the woodenlamp)
ImposterRoofMaterial (lot, roof,...)
SimpleMirrorReflection (mirror reflection)
ImposterDualPackedSliceMaterial (lot, ...) [page=0]
ImposterTerrainMaterial (lo, terrain) [includeCanvas=0; includeLightMap=1; lightMapTint=(1.0, 1.0, 1.0); textureCoordSet=1]
ImposterWallMaterial (lot, wall,...) [page=0]-->[page=9]

null (for "invisible" or undrawn objects)
etc... There're several more, but I can't recall at the moment...

[amycapdet]

Same as previous posts, this is *the source of knowledge* and a real tutorial, valuable for so many different mods. Thank you all.

[Khaibit]

Dear WindBlower
Thank you for this link!

@ Numenor: maybe I'm just blind and something like that already exists but may I suggest that an overview over the Material Definition (TXMT) can be added to the Modding Info Center? (= a list of the entries, a quick 'translation' of the name of this entry and the range of allowed entries, would be great when even their min/max value behaviour/effect in game can be included to this info)
I know it's quite a lot of work and yepp, I already found the wiki entries but they could be re-written in a clearer list or table for an easy quick access while editing the TXMTs (I think).
As neither JWoods nor you did this so far I suppose that you two thought this wouldn't be necessary - if you do so, well I could write as much as I can (= found so far) as it would be useful at least for me myself to prepare this list/table and you would only have to check for mistakes and add missing so far known entries and, last not least, upload it to a tutorial thread or even the Modding Info Center if you want. If I'm the only one who could need this overview I write it only for me and post it just in The Material Definition ("TXMT", a.k.a. "MATD") just for the case someone might want to take a look at my quoting skills...
Of course I would never say that anything of this text is found out by me but even quoting needs some research and that's why I immediately offer to help while posting this suggestion.
What do you say? Would this be useful enough to be posted in the TXMT-thread or even added to the Info Center?

@blake_boy: nice I could help :D

[Numenor]

The reason why I didn't create an InfoCenter article about the TXMT is not because we think its useless; on the contrary, the main problem is that the Material Definition is a *huge* subject, and collecting all the data in a single article is a hard job.
But of course, if we never start it, we'll never finish it :)

If you are willing to gather the info you have collected by yourself, and the ones taken from this thread, and create a draft of an article, I'll be glad to check and integrate it, and then post it in the InfoCenter (since JWoods is no longer available, I'm the only one that can post in the InfoCenter forum).

[niol]

Khaibit & Numenor,

May I join if it's good, or probably we can start a thread for collection of open inputs or reuse this thread and openly ask for more inputs?
I've had this thought for a long long time now. :rolleyes:
As Numenor has said, txmt is really a HUGE subject...and I can assure you that is no kidding. There're many not well discussed txmt properties and types, even just the ones based on the base game. Be prepared, it's gonna be a "lot" of works... :!: We may ask for more people to join in.

Or, we can have a general standard txmt properties discussion first, then the rest one by one gradually. I kinda doubt everything can be kicked out without compartmentalisation/ segmentation/ chopping/ sub-categorisation unless we're crazy enough... and the resultant post or thread is gonna be really long like a research journal paper if I'm allowed to say so. (At least, that's how I vision it.)

I just checked the wiki http://old_wiki.modthesims2.com/49596978
If those're the only listed ones in wiki, then they're just the aerial part of an iceberg.

txmt is unnecessary to have to deal with material properties all the times despite most of the cases I've found so thus far. In other words, txmt is like a collection file for graphical parameters including materials and others.

When txmt is touched, I tend to think that material shaders have to be discussed as well. This is also a "big" "highly related" subject coz many txmt types and properties are predefined in material shaders...

To tell you all the truth about my understanding so far, there're many of them I still don't know how to properly use yet.
Guess, we may need some Maxoids or people from different fields to gather infos and/or explain some of the most puzzling ones... :rolleyes:

So, the most pragmatic approach for the whole overall things I see of is to have a collection thread like this to gather different data and experiences from various people first.
But if a list of general standard txmt properties is so wanted more, it's quite easy to do actually. :)

May check out this post (http://www.modthesims2.com/showpost.php?p=1120305&postcount=13)

[Numenor]

Niol (and Khaibit ), I don't think that we need a thread like this to collect info, because this thread has benn online enough to collect valuable data; and we ourselves, in the meantime, have experimented and increased our comprehension of the MATD.

The info in the Wiki are very old and somehow inaccurate (for instance, there is confusion between reflectivity and actual reflections).

My personal guideline, in the last year, was a file created by an unknown user: when the base game came out, he was so crazy (and kind) to create a small program to scan all the existing MATD in the base game, and extracting the values that the various parameter had.
Then, he compiled a list, grouping them by material type ("StandardMaterial", "BaseTextureMaterial", ecc...).

I don't know if I ever posted this file on the forum, but anyway you wil find it attached to this post. Inside the RAR there is also an Excel sheet, where I started categorizing and organizing the data, but I never finished my job :P

I think that the subdivision by material type is a good approach, also because will let us to keep separated types related to objects, types related to skin, to floors, to wallpapers etc.

I think that we can't exceed in the info, and we shouldn't, at the moment, include info about the shaders: the subject is already too complex and we risk to abandon it once more, if the work to do is too much.

Also, we should keep in mind that people will come to read our notes in search of info on a specific subject (for instance, how to add reflectivity or transparency to a piece of furniture), and therefore we shouldn't ovewhelm the readers with tons of info.

That said, welcome aboard to everyone want to give his contribute! As Khaibit has wisely said, this is no subjet to claim credits for ourselves: we'll collect and organize data in a pure "community" spirit :) (that was the original meaning of this thread btw :D ).


PS: you will excuse me if I still call the Material Definition "MATD": I never got really accustomed to call it TXMT, and still sometimes confuse the TXMT with the TXTR :P - Posting on this old thread doesn't help, either! :lol:

[Inge Jones]

Thanks for the attachment, Numenor. That will be useful.

[niol]

So, this thread will be re-used to collect further infos.

As for the wiki info page, you're right, some infos are no longer valid.


...
My personal guideline, in the last year, was a file created by an unknown user: when the base game came out, he was so crazy (and kind) to create a small program to scan all the existing MATD in the base game, and extracting the values that the various parameter had.
Then, he compiled a list, grouping them by material type ("StandardMaterial", "BaseTextureMaterial", ecc...).

I don't know if I ever posted this file on the forum, but anyway you wil find it attached to this post. Inside the RAR there is also an Excel sheet, where I started categorizing and organizing the data, but I never finished my job :P
...

From what I've seen, in the attached excel file, they're most of the common txmt/MATD property parameters and a few less common ones.
By the way, where to get that pogramme, I'm curious. you know, back to the days, I knew nothing, and I guess I really missed it.
In the txt file, are those all the occured instances in a particular type from the base game?
After checking out many txmt/MATD files and glimpsing some material shaders, I realised even just the amount of types are already amazing, but they do serve their functions mostly. Yet, some were dropped and/or broken.

Using data sheet for a big huge table seems the simplest.

Should they be categorised in a 2-sided xy-table
1. property parameters on the y-axis in the middle of the table
2. txmt/MATD types on the left x-axis.
3. digital type, known possible value ranges, default values, functions (how can be used), notes, object instances, etc will be on the right x-axis

So, the most significant infos will be alphabetically ordered and can be fused into one table for easy searching.
If people are finding infos through the object categorisation, there should be a categorisation list for objects, so people can get the terminology used for the object instance in the table to do a search.
If people are looking for infos through the txmt/MATD types, they can skim through the left horizontal x-axis alphabetically.
If people are seeking for the property parameters, they can check out the vertical y-axis.
If people are hitting at some in-game effects, there should an effect list to state out the possible txmt/MATD types and/or property parameters. Or, segmentise the categories.

While some highly specific materials or graphical settings can be made as some scattered tables of its owns. Yet, integrating them into the big one table is still just fine.

Let's start it with the common standard property paramters and the most common txmt/MATD types first... coz they're the most widely understood and used. As for the more specific ones can be done later gradually.

I assume these're the most common types, yet surely removal and addition are welcome.
Sims: SimSkin, SimStandardMaterial
HPC products: (CelShadedMaterial)[although there're some guidelines but not not well experimented, Floor, FloorPool, Wallpaper, WallpaperBump, WallpaperPool
objects and others: StandardMaterial, TextureAlpha, WallMask

The more specific, custom, and/or uncommonly-used (***updated to clear the confusing phrase***) types and properties parameters and especially the material shaders may be done and added later.

I kinda think additions of transparency, reflection map, bump/normal map can already be handled in simple tutorials rather than a more comprehensive info data sheet for various references.
Or, maybe there'll be links to those simpler tutorials for these common usages. Then, more types of users can be fulfilled.

Lol, some of the credits belong to all the info-sharers and all the Maxis staffs who left out some hints. I wish I could list them all out if I could know all of their names and efforts. And I regard this is a community-based project for info collection, organisation and presentation. Thanks in advance for the work. :bunny:

...(that was the original meaning of this thread btw :D )...

No doubt... :anime: as you saw the need for more infos...

...
PS: you will excuse me if I still call the Material Definition "MATD": I never got really accustomed to call it TXMT, and still sometimes confuse the TXMT with the TXTR :P - Posting on this old thread doesn't help, either! :lol:
As I use both terms more, they become stuck together in my memory! :D


All,
just a quik note:
stdMatDiffCoef (1,1,1)
The RGB can be > 1, so it can be something like that (1.2, 0.5, 2.3).
The resultant in-game coloration (colorScalar) is gonna be like a multiplication of the textural values and the stdMatDiffCoef values, so regard stdMatDiffCoef as a monochromic filter where the colourational value is set by the users. So, one can make repository recolours by such means. Just do some simple maths and you'll get your desired recolours.

The 4th value is for the Alpha channel transparency, where 1 means opacque for the input texture while 0 means complete transparency for the input texture.

As for "stdMatUntexturedDiffAlpha", it's to decide the whole transparency of the resultant in-game coloration.

[Khaibit]

Numenor & Niol:
Yepp, we don't need another thread like this again but a result ;)
As I was moved by you, Numenor, (I suppose you noticed) there was a reason why I didn't immediately post my request here though it would have made sense, too (and yepp, I already knew the original meaning of this thread - I was already referring to this with my more or less "wise words" :faceslap: :D )
To remind/ tell you: I'm a math sucker who don't know any programming languages and I just started to work with Simpe again about 2 weeks ago (as I found out that the things I imagined are possible now so it's time to get started) so believe me: I'll write my part of this info as easy and understandable/comprehensible as possible - and already useful for other "beginners" (definition: someone who creates his first package with more changes than only the mesh) who just realised (like I did) that the TXMT (MATD for Numenor ;) ) is not only very confusing but even important as you can do lots of fine tuning there.
I started with cloning Maxis packages that seemed to be helpful to compare their TXMTs with mine and just copy some values (e.g. the fridge, car and glasstable only for metal- surfaces to get a nice reflectivity) which takes not only lots of time, is impractical and frustrating - and it takes a while until you find out on your own that the lower the value the more the reflectivity. So this was the idea I've had to write this info- collection and how I would start it as this would fulfill the needs of those who want quickly specific info and those who want to have a more detailled helpful overview as they not only want to change a certain thing but even want to know what they are doing.:
1. Starting with a simple quick overview table, listing the possible parameters with their known value/range - like you started your Excel table :gjob: as a short introducion to everyone like "and with the TXMT (MATD) you can do these changes but not those".
2. Easy access to specific changes, listed by subjects like "for instance, how to add reflectivity or transparency to a piece of furniture" as I think it's easier to take a look at one table instead of searching for the right tutorial and there for the important step where you find out which parameter are required and which values you should take to get the best result for your effect.
3. Detailled infos: I think as it is thought to become an overview it can't harm to list even the one or another custom-uncommonly type as long as it contains something that's worth to mention - or just listing other useful topics that are related to the TXMT to let the others know what can be important for them, too (called 'skim- reading'?! (Ger: quer lesen)) as a reference for related topics.

Niol, seems like we all agree starting with a table and listing the most common types :D Maybe you can start a little introducion about material shaders (I myself don't know even what they are), not detailled or complex but a short description in a few sentences: what they are and what they are good for as a hint for the ones who still want to know more.

As I already have had an idea about the layout when I suggested to collect the infos this is my part so far (hopefully I can be helpful at all) and if I understood you right, Numenor and Niol, you were thinking about the layout of this info in a quite similar way. And the differences, I don't think it'll be difficult to find one way it's done best in our opinions.

Here at MTS2 are a lot of modders who already have a great knowledge (because of their jobs, talents, interests, whatever) and lots of people who just start to learn the necessary skills just because they have an idea for a package they want to create - like me *ehm*. Of course it's complicated to fulfill the needs of the beginners group without boring the others to death and you can easily want to write too much detailled stuff that is hard to understand for beginners. Finding the right mixture may be helpful to finish this info collection and help as many as possible people in the community out. So I think it can't be wrong when enough of "Hey, when you want to go further into the matter research about this next - information" is included as it may help saving lots of frustrating "what am I actually looking for to go on fixing this problem" so I think it can't be wrong to integrate a short definition about the shaders - when they are really so complex (as I said: shaders, what's that?) they might be worth a new topic anyway...

[Numenor]

My primary concern, just like the two of you, is to create a table that would be easily searchable. But I'm not sure if Niol's suggestion is suitable, or perhaps I sisn't understood it fully.

Obviously, we are bound to 2D tables; since there are some parameters used by several material types, we know that we *must* have something repeated: if we choose as primary search key the parameters (as suggested by Niol), then we'll have in the first column many occurrences of the same material type. If we choose to order the list by material type, we'll have several occurrences of the same parameter.

So, the first question is: which should be the primary search key?

Niol suggests to use the parameters, and to start from the most common ones (leaving the list incomplete, until we finish this job, if ever we finish it :lol: )
But I still think that ordering the data by material type is better: this would allow us to organize the data, and publish it, "on installments": we can start with the most common materials types (the ones listed by Niol sound good), and then we can go on, explaining, if we can, the more unusual and less used ones.
We should also consider that many parameters are active only for some file types; and therefore, if a user wants to edit a MATD, he's bound to refer to the list of parameters allowed for that material type.

Of course, nothing prevents us to post two different lists, one searchable by material type, and one searchable by parameter name.
In this case, we can publish several 2D tables, one for each material type, each containing all the parameters for that type, the allowed values and info; and then one long list of parameters, with the references to all the types it is allowed into.

An example:
-----------------------------------------------------------------------------
Table A - StandardMaterial
Parameter1 - integer - range 0 to 10 - typical values 0,2,8 - Notes for Parameter1
Parameter2 - floating - range 0.0 to 9.99 - typical value 0 - Notes for Parameter2
-----------------------------------------------------------------------------
Table B - SimSkin
Parameter1 - integer - range 0 to 10 - typical values 0,2,8 - Notes for Parameter1
Parameter3 - real - range -5 to +5 - typical value -1,+1 - Notes for Parameter3
-----------------------------------------------------------------------------
INDEX by Parameter name
Parameter1 - exists in: StandardMaterial, SimSkin
Parameter2 - exists in: StandardMaterial
Parameter3 - exists in: SimSkin
-----------------------------------------------------------------------------

This layout is more readable and understandable for less experienced users (we don't want to put our knowledge into an ivory tower, right ;) ).

Anyway, just to be clear, I don't disagree with Niol's layout: I just think that it would be more (too?) technical...

Kahibit's opinion on this subject will be valuable, having an "average user" point of view...

[niol]

I realised I didn't present the 2-sided table clearly...
I see confusions with the table I suggested. Sorry, I'm bad at expressing things sometimes...

1.
The relationship between the material type and the parameters can be dealed with on the left-hand-sided x-axis of the table. So, the material type listing can be on the left. We may use some simple words or symbols to tell the readers if certain material parameters are "known to occur" in certain material types. Symbols or words are to tell what are "known to occur" (+) and "known not to occur" (-) while leaving blank for those unknowns.
The parameters can be in the middle along the y-axis linking both tables together coz the parameters are the common subjects of the 2 tables.
The descriptions of the parameters can be on the right-hand-sided x-axis.

(Material types) - (Property parameters) - (Parameter descriptions)
(Left-hand-side) - (Middle) - (Right-hand-side)

For example, check out the attachment.

So, in this idea, we can even reuse Numenor's excel file and add the material type on the left hand side of the parameters while we may leave a column for both their left and their right to make them visually distinctive from the material types and their descriptions.

For those who want to see the overall pattern and/or relationship, they can see these in one whole table.

Addition of specific property paramters can be done below the common standard ones and others. Basically, segmentise the y-axis where the property parameters are located and group them according to their known specific usages.

Surely, This same idea for the table can be altered like the following as well.
(Material types) - (Property parameters) - (Parameter descriptions)
(Top/y-axis) - (Middle/x-axis) - (Bottom/y-axis)

2.
Yet on the second hand, if the above type of table is not easily understandable, I think a few more simpler tables can be made instead. Besides, if they're done in what Numenor did in the excel file, it's not hard for people who want one big table to integrate them together while people who are more comfortable with tables in that format can readily understand them... Then, I tend to believe that may be a nice balancing point.

Addition of specific property paramters can be done below the common standard ones and others. Basically, segmentise the y-axis where the property parameters are located and group them according to their known specific usages.

3.
On an another hand (Yes, niol has >2 hands!), the format Numenor showed in post 133 is clear and neat, too. I can see its modularity and flexibility which are really suitable to this project. Yet, it takes many repetitions of data but copy-and-paste can ease the typing job.

So, there're 3 type of presentations here unless I've missed something.
1. the format of a left and right (or top and bottom) bi-table.
2. the table format used in the excel file.
3. the format in post 133

[Khaibit]

Ok, I've chosen my weapons for the duel me vs table descriptions: a) a dictionary (to make sure I can follow these table descriptions), b) pencil and several sheets of paper (to try and realise if I can follow these table descriptions), c) a rubber (to try and correct myself while trying to follow these table descriptions) and d) some brain (unfortunately out of order because of these table descriptions)... let's see who lost...

More or less seriously serious: I really tried to follow your table construction suggestions so if I understood you two right the tables should either look like:
- post 133, which refers to Numenor's Excel table (uses this order) but lists everything sorted by material type and again by parameters and has an useful index for quick access where to look for the values/parameter
- or a right/left bi-table which is niol's suggestion... though it refers to Numenor's Excel table, too (technical challenged says: it is easy to understand). The technical challenged thinks that the top/middle/bottom listing on x and y- axis at least sound complicated (my drawing even looks like that)
I never felt like being one of the technical challenged but obviously I am: what is the difference? I mean both of you want to use the same 'input' (parameters, values etc.) and you are still discussing the layout, right? And you still try to decide which layout/ way the table is sorted (and what to start with/ primary search key: parameter vs material type) is best/ easiest to use, right?
Maybe this may be helpful for the discussion as the technical challenged tries to explain to you two, which seems to be important for me/ how I would get along best with the table - and maybe this makes it easier for you to decide which way is best or maybe even how to combine the different ideas to the best result - but before I get started I do have a last technical challenged- stupid Q: can the user read them like an ordinary table you have to scroll or do you want to create tables with hot linking included, I mean is the index just an overview or an easy acces portal to get started (at least I suppose to know that it still could be offered as a PDF as it should support the hot links *start feeling really uncertain*)? If so (I know it's easy with html *proud as punch* ;) ) a table with hot links makes a lot of work while linking everything correctly but the user should have an easy to use table and in this case it doesn't matter if it's one big one or if the table is splitted in parts/ smaller seperate tables.

OK, the technical challenged would be able to manage a table that starts with:
- the parameter when the table isn't more detailled so that I have to know the material type on my own or have to know at least the value I want to change
---> advantage: the parameters are listed alphabetically in the TXMT so the right one should be easy to find in/within (great, even my grammar troubles increase...) the table.
---> disadvantage: if I don't know which paramers have to be changed because a) I couldn't find or even didn't look for a tutorial for this kind of changes I want to do or b) if I don't look carefully enough at my TXMT and compare every parameter with the table I might not find every value I would have to change

So the technical challenged would prefer a table that starts with:
- the material type and for each of them the parameter are listed alphabetically or you can choose (index!) to start with the parameters and ignore the material type
---> advantage: I immediately know which parametrs have to be changed how - when I know in which material type I actually do the changes in my TXMT. If I don't want to take this offer (material type) I don't have to.
---> disadvantage: when I'm unsure if I'm looking for the right material type I might be concerned - but in this case I can just look for the parameter

For the technical challenged a table that supports easy access to the wanted ingame effect would be the ultimate, of course it is still listed by material type or even just parameters, too - you can make your decicion via the index:
- either if you know which material type or parameters you have to search for you can take a look at the wanted effect (listed in the index) which can be found in the one or other material type so you know where to go next
---> advantage: either if you know the material type or the parameter you can find the right and best fitting entry in the table easily (e.g. bump mapping for 1. floor, 2. object or 3. clothing?) as you should at least know what sort of file you are working on/ cloned in SimPe.
---> disadvantage: hmm, maybe someone could eben be confused by this decision, unable to answer but in this case the one should redo some tutorials...

Maybe that's what you suggested with the y top and bottom stuff, niol (as I said "eh?") but if you find a way how to prepare a table like the 3rd one it might be lots of work but the most effect for the users, either if they are really technical challenged, average or even advanced.
Reminds me of a commercial slogan... It says "Make the most of now" (don't ask me what product it is made for) but "make the most of a table"... maybe my post could help you to decide... the table... at least... at last...
It was about how the table should look like, wasn't it???

Sorry, the reason why I'm not 100% serious is just the point that a decission like this is surely important but somehow funny to me, too (strange humor) - like discussing if you want to pick the honey from the bees either with your naked hands, with the help of smoke, naked hands + smoke, what about a protective coat, or even a protective coat + hands in gloves + smoke, or just killing the bees (if so, which method would be best to kill the bees without affecting the honey?)? You want the most honey (= best effect) with less pain (= as clear, understandable and easy to use) which is necessary but my strange humour just freaks out when reading this so could you please come to one way you want to create the table?

[niol]

As much as I see and as well as what I've read,
1. There'll be a part to tell what Maxis object types use what effects to familiarise users with what known/confirmed effects they can try. Why to choose Maxis object categorisation? coz most people should be familiar with it. So, when they're looking for a particular effect, they think of what object(s) or content(s) may have the effect. After all, there should an alphabetical listing for the effects, so users can skim through it first, and probably copy and search for the word or phrase among the whole part, article, or even thread.
2. Then, a part for what effects use what material types and/or property parameters.: Say, additions of transparency, reflection map, bump/normal map can be handled in simple tutorial table/listing/else in this part.
3. Table(s) or listing(s) or whatever presentation(s): This's the part to show what known property parameters a given material type is known to have. Also, this part will show the property parameters' description (inlcuding the value type, the value range, etc...)

I don't care which format will be chosen eventually as long as a set of database can be established in the end.
It's not hard to do other presentational formats once a set is already done.
The hardest parts of the project should be the data collection, organisation and confirmation.
What really matters about the presentational format are whether it will be widely understandable and easily used.

I thought one big bi-table for part3 may be able to fulfill plural usages, dependent on where people start to search. One can seek
1. from the material types to the property parameters;
2. from the property parameters to the material types;
3. for the corresponding property parameters settings
(left)<-->(middle)-->(right) [for bidirectional browsing]
or
(top)<-->(middle)-->(bottom) [for vertical browsing predominantly]
Yet, it can be challenging to those who are not comfortable with it.

[Khaibit]

Yet, it can be challenging to those who are not comfortable with it. Oh well, I noticed *gg* This time your post was easier to understand, thx!
It's fun for me to learn all the necessary skills I need to create objects in the way I imagined them and I suppose that many other creators started for the same or at least similar reasons: an idea that became a 'goal' and fun! But you can do those things without having to learn programming languages (if necessary it's enough to understand SimAntics well enough that you're able to do some changes and you know what you're doing), you don't have to be able to write working databases or programs and you don't need your bachelor or even master in math, computing science or something like that (if so the TXMT might just be properly discussed in this thread and that's it) so please forgive me that I don't want to learn the required background for the writing progress of the TXMT info for Everyone. I try to help you two as far and as well as I can and I hope that we reach a point I can really do something - as long as you two want my help. At least I can translate it into German :lol:

to 1st 1.: Using Maxis object categorisation and listing the effects which belong to the category seems to be a good start/ introducion (good idea!) but wouldn't this mean that all the Maxis objects have to be listed as e.g.
Surfaces -> Tables -> Milano Royale Dining Table/ Talking Table (and so on)
the Milano Royale Dining Table has a glass surface so it referrs to the 'reflectionkitchenhighcontrast-envcube' while the Talking Table doesn't - so grouping the effects only by categories wouldn't be detailled enough I think as this could be confusing to list effects in generally for categories. In this case all the addon- objects would have to be updated again and again? A more detailled grouping by categories would be easier - or was this what you meant?
An alphabetical listing for the effects is helpful for a quick search, good idea!

to 1st 2.: As a sub- or stand alone part? Good idea again though tables or lists should be enough as it's only about the necessary changes within certain parameters of the TXMT - one short "how to change the values, add or delete lines and correct the File List if required" should be enough as the progress stays the same. (We should add this though it is already explained in some other tutorials - reminds me of Numenor's "Lights and LGHT files" 'somehow-tutorial' - stupid me was thinking of what text list you were talking about until I got it *ggg* so it can't be wrong to repeat this quickly as it's easier to skip this when you already know it)

to 1st 3: So when the effects are described well enough that the user knows what he has to look for in the 'main table/ listing presentation' the bi-table will be easy to use. The technical challenged one is now fine with this kind of table ;)

to 2nd 3.: Can you give me an example what you mean with vertical browsing, please? I guess I did it already but eh?

As we're already making some progress it seems to become widely understandable - and quite a long presentation. We should keep in mind to collect as much as possible infos (for various porposes/ needs) without getting lost in details which seems to become tricky, too.

[Numenor]

Sorry, I left you two discussing alone... :P -
I've been busy (and I still am) in these days: things to post, things to fix, the Pets are coming...

I was thinking to the "Object categorization"... Yes, my intention is to give to modders an instrument to better edit their object, but perhaps that is *too* "tutorial-ish"?
This should be a reference table, not a tutorial, so we shouldn't explain "how to make a surface like the glass of the Milano table"; if one wants such a surface, grabs its TXMT, like all of us do :)
And once he has grabbed the right TXMT, he can understand its meaning reading the table (in this case, the table for the "StandardMaterial").
And while reading the table for the StandardMaterial, he can notice that it contains some parameters for the texture animation, or the reflectivity, and he may suddenly have new ideas for editing his object.

That's the way I imagine this "TXMT Encyclopedia".

A more complex table, with cross-references, would be more compact, but would scare the people, I think. BTW, if Delphy reads this, he will yell at us that the Wiki was *purposely created* to show cross-referenced data; but unfortunately I hate the Wiki, and I think it's reciprocal :lol:

So, my suggestion is: let's start collecting data for the various parameters, and then we'll decide *how* to connect the parameters with the various Material Types :)
Once the data is collected, we can think to a descriptive text that would explain how to manage specific [/I]groups[/I] of parameters (for instance, a small article that explains as a whole the group of parameters related to the animated textures, or to explain the relationships between the various "blend" parameters: this additional info won't be included in the table of course).

[Pixelhate]

I like to help in a way or another. I always wanted to play with the MATD but I felt too unconfident to start.
So if you think you could use someone to type, compile, read, layout, transfer text in xls, etc I'd be happy to do so.
If you need a total noob to tell you if your guides are understandable, I can be that one!
I can already tell you that the TXMT_values.xls helps a bit to understand what this is all about as the txmt properties guide.txt let me feel that I have to understand a few things before diving into it.
Just by the way it's presented...

[Numenor]

Lol! Don't think that I myself understand *all* the TXMT properties listed in that text file! :lol:
Thanks for your offer, you are appointed Beta Tester for this project :)
And your contribution is always welcome: if you - for instance - realize that you have always misunderstood the usage of a TXMT parameter, tell us; this will help us understanding what can be the most common mistakes people do about the TXMT.

[Inge Jones]

/me smashes a bottle of champagne against the side of this project

[niol]

txmt/MATD-project members,

To me, these sound like the format will be like the table used in the excel file...? Please correct me if I got it wrong. N, surely, I'm fine with all 3.

Maybe, there can be a separate section in a follow-up post listing some simple effect tutorial links or else... So, certain users can know where to look for some available tutorials related to this txmt/MATD.

As for the arrangement of the property parameters, they may be grouped according to their specific functionality. This may lose the alphabetical order, but one can use "find"/"search" to seek out the propery parameters from the table.

So, how do other txmt/MATD-project members think about adding pixelhate into the team?
I'm definitely happy with that.


pixelhate,

Thanks for your offer...I'm definitely delighted... To tell you the truth, I'm confused with the part about the standard material in the txt file, it seems it can have almost all the property parameters! But, in the standard material shader sheet, there aren't that "many". It has propery parameters from the cell shader, pool shader, etc... Maybe, they work in the type "standard material" while some may appear non-functional but stable. Gotta check them out... :D I don't know how to use them all either, and that's why more people are welcome to join and input into this community project... :jest:


Khaibit,
Sorry, for my terrible terminologies... "vertical browsing" = "scrolling vertically"... I'm from Wonderland, so words I may use can be so different that confuse people. :p


Added: now, niol's drunk and falling asleep...!

[Khaibit]

Cheers, niol! :Pint:
First of all: Vertical browsing... is just scrolling vertically?!? That's all? :faceslap: niol, can you actually imagine what I started to suppose what this could be and how it could work? :rofl: You're a nutty fruitcake from Wonderland though you more felt like a mushroom to me... just for the case you confuse me again (so far I could do it myself perfectly) may I call you "Alice" in a case of actual confusion? (I'm not so confused, it's the wrong sex) :P

Ok, from bottom to top to bottom again:

Numenor,

too tutorialish? As this project should end up in something that is an instrument for modders to better edit their objects/files/packages (this was my intention to ask you :D ) it might become either somehow tutorialish or most people start to feel like a complete idiot - so they would ask Pa Smurf for help with the help... ;)
Maybe, no, obviously I didn't express myself clearly enough as I'm from Endlesslongandhorriblynestedsentenceland.
A bit more detailled grouping that makes it easier for the one who works with this reference should be tutorialish enough (as it should be required up to a point) to use this 'encyclopedia' while explaining every single object (that's why I listed the diningtables) would definately be too much = transfer job is required while reading/working with it to make the most of a table because this is the only way to make the most of your skills (I guess I shouldn't try to write explaining parts in English... anyone around who speaks German well enough to translate me?) The reference tables I've had to work with so far were all written in a way that you get the required infos you need though they aren't listed - as it's not necessary when you have enough information about "x" and "y" so you know how "z" behaves, it's just simple transfer. I guess quite a lot people already noticed that you, Numenor, can write explanations that are somehow tutorialish though it isn't a tutorial at all just because the 'understanding-factor' is what makes the infocenter threads, and the other stuff you wrote so far explaining things, so useful so why do you worry about creating the reference too tutorialish? Either this baby will become a tutorialish table or a cross- reference chaos it will contain some traces of Numenor so even if we would prefer to write unnecessary simple tutorials to avoid doing really complicated things we struggle with - I think you would tell us, wouldn't you? ;) :D
"Do or do not... there is no try."

Cross references would scare people? I myself think they make it a lot easier... when the references are crossed well (nope, the Wiki is a horrible crossing so if Delphy reads this: it could need a tutorial how to use a cross reference data base that doesn't like crossing, in this case without crossing references please to avoid frustation because of constant noncrossing :blink: )
@Pixelhate (and niol), your opinion about cross- references: scary or helpful?

Numenor: what about a quick organization of the data collectors (who which parameters/material types/effects) or should everybody try and find what he/she/it gets? Could become some cross collecting of references... which isn't always wrong.
:!: EDIT:
Just have had an idea how I might really be useful for the data collecting progress: I can search several English and German speaking foren for 2 points: 1. search for some new things someone found out about the TXMT he posted somewhere in the www and 2. keep an eye on the questions, problems that are reported/ ask for help as this might be useful to decide about the style/ detail- depth of the final result... yes/no?

:up: pixelhate: Hello and welcome! Great that you want to help us - but you don't think that I know more than an itsy-bitsy bit about the TXMT yet, do you? So don't worry about this. We'll see, when the mixture is correct, we 2 will become TXMT editors who feel quite save when editing around :D

So, how do other txmt/MATD-project members think about adding pixelhate into the team?
Ehm, Alice, how many members habe been in this this project before pixelhate entered? I can be wrong but I thought it was a threesome *confused again - did Inge join?* and as Numeon already agreed... especially because I'm definately the "other txmt/MATD-project member" who knows less... my nick isn't too complicated to you, is it? ;)

[Inge Jones]

No I just gave it my blessing by launching it like a ship with champagne. Since I am not helping, I can't really offer an opinion but I'd like it best if it was developed openly so people could use the information in one unfinished form or another while it was being accumulated, rather than a closed development process that suddenly appears for the first time as a finished product in several weeks.

As some people are good at listing technical things in a technical way, and others are good at extracting some of the more popular settings and writing beginners tutorials, it's good to have the basic facts available to many people all the way through, so they can use them in their own presentations.

[Khaibit]

I noticed so hopefully this launching won't end up in a sunken project.

Sounds like extreme cross linking to me :D As I don't expext that I can do much technical stuff during this developing progress I don't know if several other members of this txmt/MATD-project ( :p ) would agree with me but if they are fine with your suggestion - I would be fine with it if these people offer their opinion to the progress (understandable/ too detaild/ clearer please/ I have a hint/ whatever) though they aren't helping as niol is right, it can't be wrong to have more input and another point of view can offer possibilities... passive helping in an extreme cross linking multifunktional support preparing/ offering community project (as you know this"TXMT Encyclopedia" is just one point) makes sense, doesn't it? ANd this already happens ;)

[niol]

Lol... Just one more thing to suggest... after reading and re-evaluating the previous posts...

As for the object type thing, we can just talk about how the glass, metal, furniture surface is dealed with probably in some simple tutorials linked in the additional info section or post...


Khaibit,

We've got 4 members now... (Or am I mistaking, too? :rofl: )
anyway, I'm getting openoffice 2.04 to work with the excel file...


Aded:
jokes apart...
I've started to complie a few of the previously linked standard material infos into Numenor's excel file using openoffice... coz I want to have something started... I've finished the texture animation inputs, but surely, more may be added as more inputs are gathered. Besides, more infos may be gathered from JWoods' cell animation tutorial... I'll leave the rest of the standard material definition for other members to do first..., Here's my editted version of that excel file...

I plan to do the pool definitions using the same format right now, and if the format is to be in another one, I believe the conversion will be easy.

I suggest we can use that format and make own pieces of spreedsheet and, then do the integration after we've finished our discusion on how to arrange the property parameters and/or the material types. The tables for the property parameters and their descriptions are kinda unidirectional, and that's why I think they can be started without much discussion except the parameter types, note and helps.

As for the parameter types, I'm unsure what [sort] is what type, so I just add them all together.

Regarding to the notes and helps, I'm just confused what should be for what... so, I just added some other titles there just for my convinience, and it's definitely alterable after we get a mutual understanding on how to deal with them.

[Pixelhate]

Thank you all for letting me be part of the adventure. :bunny: Just hoping I can really help and not being a dead load :rolleyes:
For sure you 3-4 knows a bit or some bits about TXMT. I don't, I've never dare to change only 1 parameter! It looks so vast, where to start ?, what method to follow ? what result to expect ? :wtf:

This is how I understand it:
SimPe is like a gigantic mixing table in a sound studio.
The parameters are the adjusting/tuning/add effects knobs. (like bass/trebble/fx, etc.)
Some knobs are independent.
Some knobs are "masters" other depends from masters (the sub one). If you cut a master knob all his dependents/sub ones are also cut.
Some knobs are interelated and any change made to one, affect also the related knob(s)/parameter.
The file/package is the input instrument. Each instrument/package has his own typical feature (a bass is not treated as a piano) a wall is not treated as clothe.
Some adjustement are valid for all kind of instrument, some are specific to the genre or the tone of the instrument.
So, depending of all the tweaking made to the parameters/knobs the output file can be quite different of the input.

The mixing table (SimPe) is avaible but there's no complete "owner's manual". There are bit and pieces of "how to use that feature", "what happens if you do this" comming from people who have a technical understandment of its functionnalities (it looks like something else they know), or others who have a practical/empirical aproach (they are are not afraid to try and see). There are also mystery zones.
What is tried here is to collect all these bit and pieces and put them together, in hope to have an, as much as possible, complete owner's manual, accessible to everyone.

Does this analogy make any sense ?

[Khaibit]

We've got 4 members now... (Or am I mistaking, too? :rofl: ) Hmm, the math sucker tries to calculate: Numenor + Alice + me = *counting fingers* 3 + pixelhate makes 4... right?! 3 men and 1 'quota woman' ;) (When we made it to agree at least in this point we might become experienced in agreeing in TXMT- project related points... :beer: )

Ok, I took a first look at your file... looks alredy very well. I'm already thinking of some things (like the Notes and Help list) and I could do a bit in the standart material- part (will try around tomorrow, too much wine tonight) but 2 questions: 1. The spreedsheet is the table, right? 2. Pool definitions are definitions of the data (material types etc.)?
As I'm completely unsure about technical terms in English it would be easier to understand them correctly if you either rephrase them extra for me immediately or you just go on writing like this and bargain for a 'technical term correctly understood- check- PM (and answer in this case of course :D ) as this is not required to be discussed in this thread, I think.

pixelhate (Four of Four ;) ) your analogy makes absolutely sense! See, you already know what the TXMT is good for - and why an 'Encyclopedia' is complicated to write but required.
It will take a while until the owner's manual will be finished but we (al least 2 of 4 are able to do so) want to write a chapter that is written by someone who is really able to speak the language it is offered (instead of one of those bad translations which only make you laugh but don't make any sense so you have to fiddle on your own).

[Pixelhate]

Looking at the XLS file make me suggest to add a column with links to related threads or articles.
If it's ok for all of you, I like to give a though and then propose improved layout for that file (like a printable version and computer readable one), see what uses of macro can be done etc.

[niol]

Lol, just my re-stating the post with the stand material properties, here (http://www.modthesims2.com/showpost.php?p=1120305&postcount=13)
If anyone wanna do all or parts of the rest of it, you can try to figure the patterns of the above updated excel file and compare that of the infos in that post... (the bottom "texure-animation" property parameters I did can be viewed as some examples...) Surely, questions and suggestions are welcome... May pm me (certainly) or others (I believe) about them... Thanks... :) Let's get the party started...! :jest:


pixelhate,
Yay, I like your analogy... and it makes sense to me...
Inexperienced? From now on, you're NOT...!
I also don't know how to use all of the features simpe offers..., there're just many... :lol:
As for the linkage thing, I also have this in mind to add a column for references, how do other members think?
With regards to the layout idea, I don't see why not try a pilot of it out to see how others think? :D


Khaibit,
Yeah, the spreadsheet is the table.... I think we can talk about how to divide the work through pms by pm-ing one another in the team...
I'll start to do the pool part which is a specific part first coz I've had fooled around with it before.
When it comes to terminologies, I've to admit I'm not good at them either, but hey it's all about communications here..., so to pm me (surely) or others ( I think yet I can be wrong :giggler: ) is fine ... :)
Wow, it sounds cool to have language translations... :!:

[Inge Jones]

Actually I think maybe I (well Peter and I) could get involved in this. I was telling him a little while ago it would be good to have a more helpful TXMT plugin, perhaps a wizard with all the different settings and their maxima/minima that writes out the TXMT for you. We maintain Help for PJSE and that could have a link to whatever tutorials or references were provided here.

But first we're trapped updating the TTAB plugin for format 54. If anyone knows what the new data in that format is, I'd be very happy to be contacted with the info :D

[niol]

Wow, a new plugin for txmt/MATD, cool...

It'll be good to have a txmt/MATD plugin that can edit multiple txmt files at once whether by check boxes or whatever other means... That'll save a lot of repeitive works effectively. I've tried scripting, but they don't work well in many cases. It's great in some cases where I've saved a lot of work...

A little dictionary with check boxes or else to choose what property parameters to be added or overwrite the original ones in the txmt file(s)

I know that'll be kinda luxurious and show how lazy niol is!
But, that can really speed up the txmt editing process tremendously due to the huge amount of data in some cases, especially for CAS and (now CAP also?) products.

Just a question: if that plugin may be made, may it contain all the txmt properties or just some common ones and the standard ones?
Now, niol is dreaming while doing more on the table for the pool stuffs...

[Inge Jones]

I was thinking the wizard should contain ALL possible settings and then make itself responsible for writing back the used ones in order while suppressing the unused settings to keep the result as small as possible. Better still give the choice to write all or suppress ununused so if during development you want to temporarily turn off animations you don't lose all the animation settings :D It can have different display options so some people might just want the usual ones for transparency and reflection etc.

[niol]

Inge,

Ohhhhhhhh...! Now, I feel like a whiny little kid...
Still, the video setting is still a question in my head... Think your Maxoid friend or someone may tell how to use it?

[Inge Jones]

Unfortunately we no longer have a maxoid friend. I think they shipped him off to Spore or something... And Sam ain't talking business with the modders yet.

[Numenor]

OK, here I am :)
As Inge knows very well, every EP that comes out is a nightmare for the modders, and I have to do my assignments... :P -

Anyway, I was thinking to the best way to share the data between us while the compilation of the TXMT list was in progress; I thought of a private forum with a thread for each Material Type, but it would be too difficult to set up.

We need a place where to post our data, letting to the other member to edit and add their own findings, without overlapping and without duplications; a normal forum isn't suitable for this, because users can't edit other users' posts to add their own findings.

Then, much to my dismay, I realized that the only place where we could do this "free exchange" of data already exists, and it's... the Wiki!.
I've run a quick tour in the wiki, and I've realized that probably it is really the best place where to move this project: there, every project member can create pages at will, and also edit at will all the existing pages.

For instance, Niol could start with a page covering the Floor material, writing a list of all the possible parameters allowed for that type; this list, for instance, includes the "stdMatDiffCoeff" parameter, and therefore Niol creates a page for this parameter.

Separately from Niol, I work on the StandardMaterial type, and I complile my own list of available parameters; in my list, too, there is the "stdMatDiffCoeff" parameter, but I don't have to duplicate the work made by Niol: I just link to his page! And, if necessary, I edit Niol's page about the stdMatDiffCoeff, to include my findings on that parameter.

It's really an efficient way of working: as an added bonus, when we are done, we don't have to reorganize the data in any way: the final result of the project is already ready to be used :)
Inge and Peter could use the stored data while we are still working on it, without haveing to wait the end of the project.
And the resulting data could be easily browsed by Parameter name, by Material type or by any other key: we just need to create a specific index page.

I'm inclined, after a lot of doubts and afterthoughts, to start my journey into the Wiki. What you think?

[Inge Jones]

I hated the Wiki too, but at 54 I am always anxious to prove to myself I can still learn things, so I even created a little page in it. I think it was the Who Is section about Quaxi, if I remember rightly.

[Khaibit]

Ehm, where, Inge? Just found Numenor's (oh, nice picture of you, useful wiki, full of required information :D ) First Page (http://www.sims2wiki.info/TXMT).

The idea of adding a wizard to SimPe sounds sooo great! Will save lots of time... :up:

Numenor, just found out that your great idea using the Wiki has one disadvantage (at least for me): People have to know how to edit something there - and I think I don't. When entering 'edit mode' at this site it looks strange (Java :faceslap: ok, bold, italian, internal link, headline and *writing text* is easy) so no idea about heater layout, necessary content, something like that before I can write... eh, and spreadsheets?
Something to copy/paste or hints without having to learn Java?

[Inge Jones]

http://www.sims2wiki.info/Quaxi

[Khaibit]

:lol: I think I need a break *blinddumbusedup*
THX!

[Inge Jones]

Feel free to add to it, it's not exactly detailed :D

[Numenor]

No Java is involved in editing the Wiki; actually, it seems to me a very old textual system.

The basics of the formatting, createing links et al is HERE (http://en.wikipedia.org/wiki/Wikipedia:Quick_guide); some good examples and hints are HERE (http://meta.wikimedia.org/wiki/Help:Wikitext_examples).

I've seen that there are optional templates or java-like scripts that add a superimposed thumbnail, or other special effects; but they are not necessary at all.

The odd thing will be to learn simple things, like to get the bold using three apostrophes :lol:

[niol]

Oh... the holy Wiki... (Here comes my white flag!)

I guess I'm too stupid that I feel and find myself getting lost and trapped whenever I visit(ed, ***now it seems to be a past...***) the Wiki.
I never know how others can get to the places they link in the posts in the forum.
I've absolutely no idea of how to view something more technical there coz I just get a message claiming I was not allowed to edit the page while I intended to view and read it only.

So, you see why I don't bother to visit it without necessity.
I don't hate it but am just frustrated with it.
So, my conclusion is "The Wiki hates me...!"

Whines apart, any dummy idiot-proof tutorial introducing how to use the Wiki?


If these infos will be done in Wiki.
I kinda think the descriptions and "how-to-use" of the property parameters should be on the property parameter pages.
A property parameter page should have reference link(s) to the txmt/MATD types the property parameter is involved.
A txmt/MATD type page just has the reference links to the property parameter pages.

But, if in this way, it's really frustrating (probably only to me?) to browse around instead moving the window bars to see more paramters and types with ease. This's just not like having a big table showing the data plainly. And it's hard to analyse the patterns among similar material types. I'm not saying Wiki is no good at all. But in this case and this way, it seems too exhausting / overwhelming to browse around in order to gather or edit the infos coz we may be doing hundreads of pages if we do it in such a way.

There're problems I see of such approach:
1. there're some property paramters are not in any material type and so they may be left out as orphans parameters easily.
2. There're at least 1 or 2 material types have no explicit property parameters, so they may be left out as orphan material types.
3. we can only do the ones that we know possible and impossible. The unknowns are easily left out in this approach coz it demands the readers to at least memorise what hasn't been tried or they've to search everywhere for what's not been tried. This will in turn enervate the process to knowing them all and it's hard to have a full figure of where and what to head on for trials...
So, as you see, there's a fluidity I think that approach is making it hard to deal with.


How about we just dump the cell table files in the Wiki for info exchanges?


Added:
Actually, this post was written after post 158, but was postponed 2 hours to post due to my being away.

lol, just realised there was an updated thread for getting started... That tells how long I've not been there since the last before my getting the previous link from Wiki.

[Khaibit]

As I don't know Java it looks for me very Javalish :D Arrgh, Wiki tuts...

The more I'm thinking about this idea (which means give the Wiki a fair chance but I get lost there) the more I think the Wiki hates almost everyone, probably even Delphy but he didn't notice yet??? :p
I want an encyclopedia seperated from the wiki that it's useable without tutorials how to read this tutorial *gripingaroundlikeatoddler* :cry:

Isn't it strange to you that even experienced modders like you struggle with the wiki? Did you actually ask yourself how many people would read our wiki-texts as nobody would find it??? Even with a direct link people might still be scared shitless to enter the Wikispace! :wtf:

OK, serious: The attachment is my changed version of niol's XLS file - I just added the Maxis stuff from your single post- link, niol (hopefully my changes are completely red) and after I made it to read properly (I just had to while comparing the values) I even noticed where it's from :D
Eh, yes, the additional pages (?), my workspace in progress in your file - I splitted your titles in parts, don't know yet if it makes sense... PPC (protein PC) is still working on that, added English translation there extra for you :D Comments, ideas?

Wiki:
If I would knew how to get this xls-file in there I wouldn't add it as an attachment. Working with real spreadsheets makes it easier than writing immediately in the wiki- pages though the information transfare is easier there.

What about asking Delphi gently if it's ok to get a seperated temporary workspace forum as we don't like the wiki :lol:

Serious again (I really try):
Offering language support might become a big problem, too because a) the wiki is so far as I know English only and b) translating and crosslinking correctly and completely (English <--> other language <--> next topic, again English and other language) would be a lot more complicated than just translating a HTML- site/PDF/whatever document so who would like to do so as those who translate are able to understand... Do I have to explain why language support is important?

Hmm, the probs niol sees appear on the horizon while I'm looking around though I can still see Numenor's silver lining...
It can't be wrong to update the wiki-txmt entries (for the few who use it) and it's an easy access to other member's progress, I could even get "my" cross linking - but this kind of cross linking (between pages and pages...) is too uncomfortable so most people don't do it if they don't really want it/ have to. Of course we could just say "it doesn't matter if someone wants to read what we wrote or not as Inge and Peter will develop a wizard, hehehe" but I think noone of us would really like to spend his/her time when it's only for Inge, Peter and... maybe the one who comes there by accident (don't get me wrong, this offer of trying to develop a TXMT wizard IS great - but the benefit of this encyclopedia can be increased a lot when offering it to AMAP people instead of just preparing a programmers guide for another SimPe wizard, it would just be a pity).

So my suggestion: what about mixing the advantages of spreadsheets (and their layout possibilities) and the wiki filesharing area?
(Ok, how to upload files there???)
We can write/ work on spreadsheets and write additional/ explaining texts in the wikispace, which is linked correctly (wiki tables can be added at the end of this project, so far xls-.sharing). So even the unknown parameter can be handled in the xls- version and are listed in the final wiki- table (for further texts if experienced) like we can decide how much linking will be required for us to work with without too much cross linking - the final wiki version can even only have some main parameter or effect links while the spreadsheet handle them in a different way (via macros or whatever you guys can do with 'tables' :D ). Either if you decide to create new links for the definition of some doubled parameter like the "stdMatDiffCoeff" or you decide to use one page for all the double listings you both edit together and when the texts are finished you copy, paste the required parts from there into the spreadsheet(s) the info/data sharing should be quite easy in the wikispace (as long as you don't try linking each other to madness).
Understandable?

EDIT: Looked at Numenor's help- links and found the file- upload (I'm so blind *doh!*), so I think I can manage wiki-writing...
Seems like I have an idea about a beginners- introducion, pixelhate and me can try to write it - and the others can decide to delete it again if it's too tutorialish... :D So far... (http://www.sims2wiki.info/TXMT/Khaibit-Workspace)

[pljones]

Quaxi's TXMT editor in SimPE loads in the Properties definitions from an xml file, if anyone wants to update it with the information from the spreadsheet.

...\SimPE\Data\txmtdefinition.xml looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<properties xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="propertydefinition.xsd">
<enum name="BlendMode" writeas="name">
<field value="0">none</field>
<field value="1">blend</field>
<field value="2">additive</field>
<field value="3">addNoSrcAlphaScale</field>
</enum>
...
<category name="SimBody">
<property type="guid">
<name>cafHairTone</name>
<help>GUID of the Hairtone you want to assign</help>
<default>00000000-0000-0000-0000-000000000000</default>
</property>
<property type="int">
<name>cafNumOverlays</name>
<help>Number of assignable Texture Overlays</help>
<default>0</default>
</property>
<property type="guid">
<name>cafSkinTone</name>
<help>GUID of the Skintone you want to assign</help>
<default>00000000-0000-0000-0000-000000000000</default>
</property>
<property type="string">
<name>compositeBaseTextureName</name>
<help>Composition of all cafOverlay Texturenames</help>
<default/>
</property>
<property type="bool">
<name>eyeGizmoEnable</name>
<help>Is an eye Gizmo assigned?</help>
<default>0</default>
</property>
</category>
...
<property type="string">
<name>alphaRefValue</name>
<help/>
<default>128</default>
</property>
</properties>
So you define the <enums> for fields with a range of set text values ("none", "auto", etc), then categorise properties, using type="..." to specify the validation rules.

[Numenor]

Thanks, I didn't think to transfer the TXMT data to the SimPE's xlm, it's a good idea :)
Of course, we have to finish the collection and arrangement of the data, before doing that :P

[Khaibit]

Ehm, I took a look, compared with the spreadsheet... and, guess what: I am confused! :lol:
Whenever I thought I understood the structure of this xml-file I found something which didn't fit my 'understanding-trial' so is there a site with explanations how to read in this file somewhere around? Or can you give me one? Thanks in advance :)

How are *we* making progress with data-collecting, Numenor? ;) :D

[Inge Jones]

I didn't even know about the xml file, and Peter didn't think to look at that at first, so he spent a few days looking at other ways to make a material editor until suddenly he discovered that!

[niol]

Is that the presets for txmt editor categorised interface or something else? :blink:

I've a full faith Khaibit will understand it fast soon if not yet... :D So, the property type definitions are in txmtdefinition.xsd?

[Khaibit]

:lol: *erm* Yes, of course, 'Tim' ;) :wtf:
It seems to me that there is also some other stuff listed (like GUID etc.) so this is another reason why I'm still confused - I cannot expect that everything is about the txmt. Didn't have the time to search/google yet...

Do you understand it?

[niol]

really didn't think about mod-the-simpe (MTS)!
Yes, it's really the preset list for txmt editor categorised interface... just test it out for my convinience...
Now, I haven't to wait for an update to have some of the values I've already known to appear in the simpe... I can do that myself a little bit. :D

Lol, I only understand a little bit of it... not fully understand all the terms or parameters.
I'm no programmer anyway.


added:
I suddenly wonder if there can be a graphical preview for the environmentmap with a set of known in-game values while keeping the blank customisable... That'll further save a lot of work of typing or copy&paste... :bunny:

for some reasons,
the parameter preset list is kinda random...

I've been wondering where this paramter is from:
stdMatTextureCoordTfAnimTransStartY
I've just found it appear in that txmt list. If it does exist, then it's probably not a standard one.

[Khaibit]

But you're a Tüftler (sorry, couldn't find a fitting translation... what you do all the time when you're not lost :D) and this stuff is intresting.

It's more MTPe, isn't it? ;) Suggestion: you 2 go on collecting and arranging data, like the Italian guy said, and I'll try to manage this strange listing - in this case I can do something useful, too.

Edit - to Niol's edit:
It's made by Quaxi, right? So maybe asking him where he extracted the data for the file from? Might be helpful...

[niol]

No doubt... :D

If many presets are already in the xml file, how to add them instead of copy&paste them into the lines@ the categorised interface?

added: sorry... i presumed one knows where it is.

The pic also shows my addition to the preset for the "addressing" by adding them into that xml file. It works. :bunny:

pljones, I thank your pointing it out... :)

[Khaibit]

Ehm, what? can you re-phrase, please? :D

BTW, I added each 1 line in the materials and parameters-talk - might be helpful to be understandable for beginner I thought...

[niol]

Argh, still I failed to add some texture names there as some enum presets...
I'm too lazy to analyse the xsd file to add in new modified definitions. :P

The string type is predefined too board for my purpose. Yet, a clone of it with a different name should work it out, I bet...:D

[Pixelhate]

Gggggh?

[Inge Jones]

Well this would be the ideal thing for the wiki because we can each edit the page with further findings, and surely the result each time can be copied and pasted into our live xml file to use with SimPE?

Note: There is a similar file with the OBJD properties... I believe someone was saying there were some that could be added?

[Numenor]

That was me :) Yes, I've found the objddefinition.xml as well, and I'll try some experiments on that :P -

HINT - If someone doesn't know this (like me, until 10 minutes ago...), you can open .xml files with Excel, edit it at will, and re-save as .xml.

The various items are arranged in rows and columns, and it's easier to edit/add data.


EDIT: correction! Saving from Excel heavily changes the xml structure, that becomes unusable by simPE.

EDIT AGAIN:

@Niol: I've searched *all* the TXMTs from the base game, and the "stdMatTextureCoordTfAnimTransStartY" only appears in the "staircasestraightvalue_wall_orange_txmt" (but all the texture animation values are set to zero, and the animation is off; so we can say that this parameter is actually *not used*, at least in the base game).

@Khaibit: The GUIDs mentioned in the xml are *not* the same ones used in the OBJD; they are 32-digit hex numbers often used to identify in a unique way some bodyshop elements (skins, hairs, etc).
So, the inclusion of these 32-bit GUIDs in the txmtdefinitions.xml is ok.

[Khaibit]

Hey, imagine: I noticed on my own that these GUIDs are "something else" than the one from the OBJD and that they "must have a reason to be listed in there" (which I couldn't explain myself/ find out of course :D) - I try and think logical at least sometimes :D - but this caused my confusion: what if I try and edit the .xml in a wrong way because I misunderstood the way the stuff is listed, are other names also for something else than I think? :blink:
Open the .xml with Excel makes it easier to try and understand the file structure but it stays so far confusing to me... and intresting *doh!*

Thank you for explaining! :)

Anyway, seems like you guys want to edit it on your own (so I can't harm anything :D), right?

[niol]

Sorry... I'm one of the leads who started to make this thread kinda off-topics.. :P
(from txmt to mod-the-simpe!) Maybe, we can start a new thread for the latter. :)

Numenor,
Grazie mille (correct me if I got tis worng :P) for your finding it out, gonna check it out... Could the maxis team be thinking of an esculator? just wonder... (no need to answer/respond unless wanna.)

[Inge Jones]

Can I just check that Peter's not needed to do anything on this project now? There are people here who are ok with editing xml files?

[Khaibit]

:rofl: Inge, if someone is not ok with editing xml files... what will Peter do in this case? :D A confusing question again ;)

Don't know if others who try and find out if they are ok or not already (Niol, can you edit/write php???) found these 2 progs, 1 free, one trial: http://www.snapfiles.com/get/xmlnotepad.html (free) and http://www.ovidius.com/xmetal.html (trial).

The free one offers even an easy to follow structure :D (Didn't test the trial yet)

[Inge Jones]

Peter understands xml, but it makes more sense to leave his time free for doing the C# coding if someone else can do the other stuff. In the end, if there is some change that needs to be done in the TXMT properties tab to add some functionality, Peter or Quaxi can add that.

Atavera, doesn't the final file exclude any unused settings? If not, then perhaps there is a code change that could be usefully done there. Though we're not talking about huge excess size, are we?

[Khaibit]

Inge, maybe you can tell me easily where's my mistake in English to be understood as I mean it http://www.sims2wiki.info/Talk:TXMT/Introduction-Analogy :D (serious: I really don't know where exactly the problem is located there so someone, please?)

[niol]

Added with atavera's idea,
I think a table of txmt property parameters to add/alter/remove can be categorised into groups as well with one check for the whole group.
Lol... niol is dream-talking again...

I can only add some simple values there so far... Guess, I need learn more on it.

[Numenor]

About Atavera's question: we know that some parameters are bound together and form a "group", but there are other parameters that are stand-alone (but hey, a 1-item group can exist, nevertheless :) ). Let's not forget that all the parameters in the TXMT must be in alphabetical order, therefore, after adding a chunk, the TXMT must be re-sorted.

About editing the XML: I think that it's a great idea, because this way SimPe will contain a TXMT editor more and more refined, while we progress with our job. But manually editing the XML is so boring... If we had a program with an input mask to use, it would be much easier. But in any case, we won't start editing the XML until some data are collected lol! :)


To anyone: I'm reorganizing and reformatting the "txmt_properties.txt" that I've posted earlier into an Excel sheet; the purpose it to see which values are possible and which are actually used in the various parameters. And I'm also taking the chance to specify the type of the values (Integer, real, Boolean...) and the accepted range.
I'm not delving into the meaning and usage of each parameter of course; but it will be a good starting point to sort out the mass of parameters (and this will also help with the XML, later on).

@Niol - "Grazie Mille" = perfect! "Esculator" = uh? :lol:

[Inge Jones]

Khaibit, I, er, don't know what you were trying to say, so I can't correct it :)

[Khaibit]

Inge:
In here: it was a stupid question which didn't need a serious answer (thanks anyway, but of course Peter asked for someone else to do it that he can do other things :) ) so don't take me serious all the time, only sometimes, please (yepp, even German can try and have something similar to humour ;) )
And the link: it's about offering an analogy about the TXMT only so it's not required to talk about other things, which wasn't my intention. Though it seems like I did talk about other things, too - unfortunately I can't see where/what/how this happened (suppose I couldn't make it to express what I mean, result was what Numenor remarked). So can you read the comments and the "Future House" analogy to check and help me out what I have to correct/rephrase? Would be a big help by a native speaker because I really don't get it. :)

Niol:
Hey, I suppose, I'll have to wait for Numenor's improved TXMT.txt to go on, also I can only try and write more analogies (if required) after you two added values etc. on the site first (to avoid 'off topic' stuff :D ) so I feel even more feckless/unhelpful.

Numenor:
About Atavera's question: Can't I follow? You mean, it is possible to do so with the right 'know how' (get it working & SimPe-user)?! If so: would be great! (Remember, I'm a dummy when it's about programming so maybe I didn't get it :D)
XML: It can't harm to try and find out how to edit it already now that we can do so when it's time ;) And even if a prog. isn't available, well, maybe the dummy can do some boring tasks if/when I make it to be able to edit correctly... (yeah, risky to let it a dummy do :lol: - I only would try when I know what to do to avoid troubles caused by me)

TXTM-txt improvment: Great! Will definately be helpful to try and find something out about meaning and usage.

(Off topic: did you see, the drums are posted - forgot to ask you: are you actually fine with my thanking? You too, Atavera?)

[niol]

Somehow, I thought the alphabetic order is mostly for modders to read easily or sort easily...

I've seen some txmt packages are working well with the order messy... And even those in shaders barely follow alphabetical order.

But it's true it's easier to sort things out if they follow such order.


Numenor,
Glad to hear the paramter type will be revised... I like the new ones coz they'll be matching the codes. But you know what, I can never understand how 4 variables are still considered v3. Maybe, that's the result of an addition of formats?


Khaibit,
lol, you help me clear up my thought a lot. :!: :lol:

[Khaibit]

I did WHAT??? Gosh, how did I do it, which kind of thoughs, in which context? Will you tell me - and will it work for mine, too??? :rofl:

About the alphabetical order: now that you say it, yes, I noticed this, too - sometimes it works even when mixed up :wtf: So why when the order is so important? *suppresses a nasty to herself and other German comment* :D

[Numenor]

@Kahibit (OT): lol! :lol: Another "tempestuous" hug! :) Thanks ;)

About the alphabetic order: this is one thing that Quaxi and I discovered when he first implemented the TXMT editor in SimPE (you know, the "Categorized Properties" tab in the TXMT wrapper). That's why Quaxi added the "Sort List" link at the bottom of the main TXMT tab. Let's say that at least some parameters don't work if not properly sorted. If I remember correctly, for example, we were trying to add a stdMatBaseTexture property to a TXMT that didn't have one (e.g. the glass) and it didn'd work until we sorted the lines. But perhaps we just overlooked something? I don't know. Further testing is needed, because if the properties can be unsorted, separating them in chuncks can be easier.


@Niol: what are you talking about, specifically, when you say "how 4 variables are still considered v3"? The only case of 3-to-4 variables that I can think of is for the RGB parameters, that can sometimes have a fourth value for the Intensity (if I only could understand what this Intensity is... :P )


New TXMT Property FullList attached: it's an .xls sheet that you can sort by MaterialType (to see what parameters are used in that MaterialType) or by Parameter name (to compare the different "known values" that the same parameter has, when used in different MaterialTypes).
The second sheet included in the Excel file is a simple list of all the existing MaterialTypes (39 in total).
Please note that the content of this XLS is based on the old text file posted earlier, and therefore takes in account only the TXMTs released with the base game.

[Khaibit]

(OT: :D I told you I can - and so far noone died of hugging... except when hugging niol this might happen, he uses this perfume... :lol: :P
Fine that you feel thanked well, you really earnd it :) Nevertheless you could try and copy & paste my nick to avoid typos :p)

OMG, when things go on like that we might still be investigating for data collection (to start writing when Sims 3 comes out :lol:
Of course even me understands the need of this investigation and I will try around a bit with the order, esp. with adding stdMatBaseTexture and other.

You are quick, thanks! Quite a lot entries in the Properties sheet and - as you said - the notes still are scary empty.
Just took a look at Pets\...\Materials.package and am I wrong or is it full of additional Parameters and even Materials?? So the list will become even longer and - at least for the XML - grouping per EP would make sense, too? Or isn't it required because this could be managed different in SimPe so even not required for listing data in Wiki? Anyway lots of managing lists stuff to do ;)

(Another OT: why does MTS2 actually not support .7z files for upload? Wouldn't a decreased file size help to save at least a bit bandwith? Unpacking with WinRar works so this shouldn't be a reason.)

[Numenor]

Khaibit (copied and pasted :D ) - I'm not sure you have looked into the right package...
In each EP there are, among the other packages, the following:
....\Res\Materials\Materials.package -> This contains the "Material Shaders", i.e. the effects of the water surface, the reflection of the mirrors etc. The Material Shaders are *not* to be included in the TXMT Encyclopedia. BTW, Teko's thread (http://www.modthesims2.com/showthread.php?t=194918) is about Material Shaders, and therefore those info can't be included in our work.
....\Res\Catalog\Materials\Materials.package -> These are the Material Overrides (MMAT), that are used to apply a specific TXMT on recolourable objects; again, this are out of our interest.
....\Res\(Sims)3D\Objects02.package -> These are the actual TXMTs used in objects
....\Res\(Sims)3D\Sims02.package -> These are the TXMTs usend in skins, clothings, accessories etc.

I've given a brief glance at some ramdom TXMTs from Pets (from the Objects02.package) and I've seen no new parameter; but of course I haven't examined them all.
I'd like to add that there is a reason why my Excel sheet only contains TXMTs from the base game: I don't know how to extract the parameters and their values from the TXMTs and put them into a text file: I've used a file that was created back at the times of the base game by an unknown user (that has all my gratitude): he probably created a small program to extract the data, but I don't know how to do that (and of course I can open manually the TXMTs one by one...). So, I'm not going to update my Excel file with the TXMT values extracted from the various EPs.

[Khaibit]

:lol: :up: Numor (not c&p) :D

*doh!* I learned about 50% from my mistake with the 1st try of my misterious line- question: I added 50% of the necessary to understand the context- infos (that's much improvement for me!) If you didn't understand this see older mails ;)
I looked at Pets\Res\Materials\Materials.package because of this (http://www.modthesims2.com/showpost.php?p=1120305&postcount=13) post by Niol (he links to it earlier in here) - after taking a look at the XLS I just reminded this and took a look in there, too - without knowing what's about :lol: (clever tactic, isn't it? :faceslap: )
And yepp, know already that it's about material shaders, was told (this does not mean that I know what these are, if so I'd have known immediately that I was wrong in there, sry. Now I know what they're about... thx)

Phew! So when I looked at Sims/Objects02 I was right at least in there :D

Re-thinking about my 'fear' of thousands of new TXMT materials and parameters (which was only material shader stuff, fortunately :D)... stupid question by a non-programmer: would it actually make sense to add new material definitions (materials|parameters|both) to EPs instead of including all needed stuff directly into the base game and use these for new textures, except thes new ones are too special that new values are required? I mean: new anims make sense for sure but new material definitions - for what kind of package would these make sense, couldn't 'texturing' not solved with already available stuff? Do you know what I mean? So can it be that only using the base game TXMT is absolotely fine for us? [I'd just like to understand *programming principles*, I think :blink: ]

Incidentally: you can just laugh at me next time I said something stupid - feel free to tell me that I was stupid if you want. (Some guys already start to laugh when they just see me for that reason...) :D

[teko]

I don't know if this is clear but the TXMT is an extension of a shader. The data of the TXMT is read by the shader. That means the shader collects the values and behaves like that (true/false "system").

If user data in the shader is needed it's written like this:

(Example)

$stdMatSpecPower
$stdMatAlphaTestEnabled

So even the StandardMaterial is a shader.


I don't know if this is useful or dumb stuff - if so, just ignore it. ;)

[Khaibit]

At least it calms me a lot because this explains why I fell into the trap and saw new parameters in there - it is connected/relating/interacting somehow... *phew*

So Numenor, (Teko),

(I dunno if it's useful or dumb but) if the shader is relating to the TXMT, what if Teko updates (it's copied from old Wiki, so maybe you can rephrase/update the 'quick info') http://www.sims2wiki.info/CD7FE87A and we add cross links (this site <--> TXMT Intro) to make it clear and avoid confusions of clueless ones. Maybe my mistake was good for noticing that this quick explanation/definition does makes sense to help the "average" (ehm, expect the unexpected silly Khaibit-factor :D) user not to fall into this trap. (Do I have to remind you to try'n'think like the "average user", Numenor? ;))

[Numenor]

Khaibit, first off I want to thank you fro having reminded me about that post by Niol, regarding the Material Shaders. After having re-read it, I've better understood the relationship between the shaders and the TXMTs.

I know almost nothing about Material Shaders, but I think that Teko's definition is very precise and understandable: TXMTs are extensions of the Shaders. shaders have a life of their own, if we can say so; but sometimes (often?) they use the parameters that are passed to them by the TXMTs.

So, my idea is: let's keep the topic strictly on the TXMT; but let's keep an eye on the Material Shaders, because they contain *a lot* of information (and sometimes explanatory notes) about the meaning of the various TXMT parameters.

I think that most of the info included in the shader posted by Niol in his thread, and included in other shaders from the Materials.package can be included in my XLS, and also used when writing the posts on the wiki.

[Khaibit]

:lol: So my look into the pets\materials\materials was not completely wrong :D Erm, you're welcome :D

Teko and me were already PMing about it and I hope he'll make it to update the shader-wiki page on his own (well, I think he can). Hey, do (can :P) you remember our discussion about whole stuff vs. concentrating on one point? I think this is a good point to start both at the same time - shader|TXMT though both needs the other topic as a reference/ for going on in making progress on the topic you're concentating on, you know?

[Numenor]

I don't have the knowledge to develop a wiki project about shaders. If Teko can, he's welcome :)
In any case, if I'm right and the Shaders are at a lower level than the TXMTs, then we can go on with the TXMT part and then start with the Shaders part.
I mean: while talking about the TXMT, we don't need to explain how the parameters are treated by the shaders: we can just point out the visible differences that occur in game when altering a parameter.

On the contrary, if someone wants to explain the Shaders, he needs to refer to the various TXMT parameters, so it would be better to finish the TXMT part, before starting with the Shaders. In my opinion :)

[Khaibit]

Did I get it right - we just found out that there are still tons of data to check, sort, add - and you already make plans about continuing with a shaders-project? :lol: Ok, if we also investigate the unlogical behaviour of the Link Section of the GMDC I'm fine with (doesn't belong at all to texturing but I'm curious about this behaviour - and I have no clue how to investigate it on my own except noticing what happens and wondering about...) :D

Erhm, 2 guys, 2 opinions about shader/TXMT hierarchy- theory... :lol:

I didn't mean that *we all* (to avoid confusionsl: niol, Numenor, pixelhate, Teko, me) start right now together with the shaders but I meant that Teko could try to write what he already can write (maybe some thoughts by Niol may help) while we try to do whatever we can do so far with the TXMT to find out when/ if/ how a kind of cooperation would make sense - I was talking about a kind of info-collection/preparation for 2 things at the same time. When we know enough about the common denominator we can again think about the best/ most effective tactic, clearer now?

If you're right with your tactic I just have to agree - it seems just to me that you misunderstand me - or did I?
Someone else?

[Numenor]

Lol! I'm not making plans of organizing a "shader project", au contraire! It was an elegant way to call me out from a possible inclusion of the shaders in the TXMT project :P
And as for the shaders/TXMT hierarchy, I think Teko and I are saying the same thing: TXMTs are somehow "less important" than shaders. A shader could even be coded to work without any TXMT passing parameters to it.
Teko has already proved that it is possible to talk about the shaders almost without mentioning the TXMTs, but of course, writing an analysis of the shaders isn't possible without referring to the various TXMT parameters. I would be more than glad if Teko would write about the shaders; I only think that it would be much easier for him if he could access (and refer to) the TXMT data collected by us, without having to duplicate the efforts.

[niol]

Sorry for my a few days of absence...

Actually, from what I've seen and expreimented.
Sometimes, for certain settings such as those for pool-surface-tiles, the shaders can have the ultimate effect on the colouration of the these tiles while the locally modded floor tiles can't control the final coloration.
Yet, in the same example, the wavy x and y parameters in the local pool-surface-tiles can override the shader default settings locally but not globally, so those tiles are basically local mods themselves.

So, I don't think a 1-way hierarchy can help others understand the shader's role in my view. A bistable type of circuit may do it! :D
I'd say the material shaders and the txmt files can have variable roles of dominance, co-dominance and/or recessiveness.

A material shader is a global setting for a particular sort of material while txmt file is for local "fine-tuning" settings generally but unnecessarily to be so. [*added* From my limited experiences so far, all the property parameters of txmt are predefined by the material shaders. *added*]

A modded txmt file can build up a mod as a recolour when it can contain upstream parameters or predefined upstream material type that will affect how the game renders.

[Khaibit]

:lol: Your elegant way wasn't clear enough to me, Numenor ;)

Without understanding shaders (just first 'aha-effects') but what I just saw so far it seems to me that shaders and TXMT behave more like Niol says - that's why I was talking about going on with both at the same time, "a bistable type of circuit may do it!" :D

Welcome back, Niol! At least you undestood me again :D Hopefully Numenor understands you, you and me Numenor, Teko at least one of us - in best case rather you or Numenor than me, maybe even all three of us, Pixelhate could maybe understand one of this bunch, maybe even Numenor and in this case we can just hope that Numenor understands at least Teko and you... and I just can go on talking because you understand me and can translate Khaibit to all the others, clear? :D ;)

[Inge Jones]

I don't understand you, usually, so I hope Niol can translate for me too :)

[teko]

OT: Khaibit, your last part is even harder to understand than the shaders. :rofl:

I have never written a wiki article but I can try that. ;) I just need to collect more of the data I know (saved in my head, not written down yet) and make sure it's right what I tell. And it would be good if Niol can have a look at it and if he's got the same results about shaders.

Numenor, I think you can go on with the xls-sheet you have posted. :up: It looks very complete to me.
By the way, I guess there can be added own links for parameters between the shader and the TXMT. Like this:

$MyVeryStupidLinkForAValue (Shader)

MyVeryStupidLinkForAValue : 0.6,0.6,0.6 (TXMT)

At least it's just an assumption and isn't very useful though.

[Khaibit]

Inge, of course I didn't forget you - but I already realized that you usually don't understand me so including you in this complex understanding huddle would maybe even have been too much for Niol :D
Teko: this was still an easy-to-follow version because I tried to be understood :D

Topic:
Teko, as you talk about linking single shaders seems like you want to make it "big" - if I understand the stuff I can try and write an analogy for understanding (= without 'lots of background is required for understanding the shaders') the differences and similarities of Material Shaders and Material Definition if you don't want to write it on your own/ would like to be helped even by me.
Maybe the refering topics should be explained similar (mean: well enough, understandable) to point out the differences and similarities and the relation. Clear what I mean? (Frustrating that I really started to ask all the time if I'm understood but obviosly I ain't... :wtf: )

Cross links will be great (one of the big advantages of the Wiki) so when the stuff is prepared - so far - adding the related cross links will be easy :) Maybe finding out how to cross link can be the tricky part - just one cross link/ other additional shaders/TXMTs referring to this, is the cross link- structure finished or is something missing? (Niol, could you, please...?)

@all, I guess not only Niol can help Teko out like Teko could have additional infos for us, also for the TXMT plugin I guess, so a cooperation does makes sense :)

[niol]

Trying to catch up...


My hero Numenor,

For the Q on post 191, Bingo! :D
"a fourth value for the Intensity" = the transparency alpha value (surely when the alpha blend mode is enabled.)

On one hand, I do agree with you that the material shaders should be a separate topic from this project coz I doubt we all (those in the txmt project) can deal with the material shaders with full confidence unless someones with such full knowledge will join in to help out (Then, that's an another story). Just to try not to chew more than we can bite before we choke is often a wise decision made.
Yet, we may find Teko to help out to talk about the shaders somewhat for better undestanding. :D

Sorry, just dl-ed and haven't read the new xls yet, so no comment yet...:P

Actually, there're many infos from the shaders, which we do need for our txmt projects "unfortunately"... :P ***added : Oops... :faceslap: Having read the previous posts but forgetten the contents of the recent post... So, you also think so..., so I should get slapped for that...! :faceslap: ***


the txmt project members,

Lol just in case, what Khaibit meant was that we may learn more about both the txmt and the shaders through an interactive learning back and forth on these 2 subjects. Yet, I guess we (the txmt project members) may not "publish" anything about the shaders in the txmt sections until the shader wiki is ready to start, but we can still "discuss" the shaders for the txmt project.

As for the scope for the txmt project, let's finish up the field of the base game first before the EPs, or we'll have started too many things at a time that the pressure may enervate our motivation. Surely, Khaibit may be an exception coz the cell cycle of her spirit is ALWAYS on! (For those who's learnt a bit of general biology should understand what I meant.. :D Shall I get stomped later? :P)


Khaibit,
for post 192, you're not alone wanting 7z to be used in MTS2... :) I want uha, too, esp. for Bodyshop products.. :P
There're no "thousands of new TXMT materials"... but just less than a hundred ones so far for the listed. lol, just open your eyes to count it again... :) But, I can't tell how many paramters are there! :P
"for what kind of package would these make sense, couldn't 'texturing' not solved with already available stuff?"
No, niol can never be satisfied by the already in-game materails... :D If so, I wou;dn't be digging for more! (:ranting: I want a bloody wavy watery surface for my horror themes... I want new roof materials... I want new glass materials... I want ghostly materials.. blah blah blah... oops... niol is just leaking his greed as der "vint"!)
After all, aren't mutual understanding and comunication parts of our goals? :D
When we get to the parts, we'll know what might have been missing... :D So, no worry...!


My heroine Inge,
It's time for you to interact with a German in order to understand them... :sarcastically and honestly... The first time I talked with a German at the college I was in, I was shocked and amazed by how that person expressed things in English... But, getting along a while, I started to understand what they really mean... That's a big good thing about multi-culturalism! I see more things than I do in one "colour-blind" culture. Surely, I think I've benefitted a lot from that... :D


Teko,
For material shaders, I think and believe you know much better than I do... :anime:
Thanks for the useful links. :) :thumb up: Now, I can learn more about the shader thingy.
it was just that I was fooling around about the applicability of them rather than the coding structures..
:ha ha ha: for your humourous descriptions and probable help on the shader wiki (so, I can learn more by the way...)... Danke.


All,

can someone post the material shader scripts of Pets... for analyses if that's OK?
I'm curious how they do the layering thing...

[@ all, this's what I think.

txmt files do need materails shaders to work out, or they become meaningless when alone. Many material shaders can work alone well without txmt files, such the roof shader, the neighbourhood shader, the wall shader, the mirror shader etc... Yet, it sucks when they have no txmt files for local customisations, just think about the roof recolouring! And if they do like the wall shader, full customisation is unavailable, argh...(Why didn't they just make up one major material for most materials for much more possibilities in the future? When the coders couldn't think of some possibilities, they unconsciously shut the door to them.) Without local customisability by modded txmt files , we're gonna lose easier local game modding. txmt files can be a local graphical partial hybrid or linker between a local object and a "global" material shader.

Just in case, just think of the TS2 material engine (in a general overall sense) like a paint programme and a 3d programme for those who happen not to be aware of that. To set the txmt parameter values is just the same as to set the filter values to see preview(s) of the editted graphic in your paint programme. Shaders in TS2 are kinda like graphical plugins for such rendering.]

Shaders are responsible to connect the traslations between the MS D3D (according to Teko's post) and graphical presentations of TS2. MS D3D is a 3D graphical means for the hardwares (video card, the monitor...) to read for 3D graphical presentation? (lol, please correct me if I'm wrong... I'm only telling what I've "understood" from what I've read so far.)

I meant "a bistable type of circuit" in the context of applicability rather than that of the original structural intention when I thought back... I know some ways to use them might not be intended, but you know how naughty niol is.

[teko]

Shaders are responsible to connect the traslations between the MS D3D (according to Teko's post) and graphical presentations of TS2.
To the exported Maya materials were Assembler code and HLSL code added. That's what the Maxis Material Shaders are. :)

(Based on notes by Maxis in the shader code)

[Khaibit]

quick notice:
I put all the 68 MATSHAD together in one txt I'll upload with the 'real' reply, ok?!

[niol]

teko,

Thanks... :) Still, I'm in confusion... :twinkle little stars:
Was that from the shader with HLSL codes? Now, I guess I was reminded of that statement I read somewhere among the shaders.
I'm still thinking what that statement can mean...
They're Maya materials (probably back in 2002!)... Can new Maya materials be integrated into TS2... by the way? :D

There're some shaders designed for running in / identifying a range of hardware types and grades in order to choose the appropriate settings for rendering... Some dummy tests...

(I"m gonna take a nap again... before anything else.)


Khaibit,
:D "68" MATerialSHADer... Danke...


(Oops: that German was one of the those I had conversations with.)

[Khaibit]

Here's the real reply...
and HA! Someone who agrees at last! :D Actually, there're many infos from the shaders, which we do need for our txmt projects "unfortunately"... :P That's what I meant, the interactive understanding/ learning - nothing more, nothing less so far :D Niol, you're not only my "understanding-hero" ;)

No reason to stomp, trample down or kick you - but it seems like you have quite a good understanding of happenings while I'm busy with boring stuff, like e.g. having a shower vs. bored mind... :faceslap: :D Hopefully I can lead my spirit in one direction :anime:

Do you know this German expression "tierische Übertreibung"? ;) :D Actually it seemed to be round about 3 mio. new TXMTs, roger? :D
Seems like they find better solutions for already working/ available stuff, more solutions for new stuff and more ideas which require even better solutions, don't they? ;) Ok, it was a stupid question... your wants sound bloody familiar to me and I like so far our goals :D

Now I am curious: how do German express things different in English? And don't just reply: 'German' please, that's not helpful... :lol:
@Moderator Numenor: get Delphy ready to enable 7z-file support in here, please. (already wanted by two members! :D )

To the txt (RAR because of the size):
Hopefully quite self-explaining...
In #46 there's something about a "version 4", shader for mirror reflections... changes in comparison to older EPs??? Anyway, some useful hints and lots of confusing stuff inside... Teko?! :D

[teko]

HLSL is more common today than Assembler. Sims 2 is kept on a very low level of possibilities with graphics.

Can new Maya materials be integrated into TS2... by the way? :D
Don't know. :giggler: But if it's similiar to the MATSHAD we have in Sims 2 I guess so.
It would be actually interesting to see such an exportet Maya material. :)

Edit:
Thanks Khaibit. :) This is very useful! ... Gosh! Very very very useful!! I've just found a simple Pixelshader and Vertexshader which explains the structure of much better to me. Maxis thought at us. :)

Edit2:
I forgot to mention that the reflection shader hasn't changed since the base game. It was always version 4.
Between, through reading the txt-file the code is now much clearer to me than an hour ago. :D I have an assumption how to combine the mirror reflection with a normal map. :D

[Khaibit]

I just would like to know what exactly a "Maya Material" is... googled and found a Making a Glass Shader (http://www.tutorialized.com/tutorial/Making-Glass-Shader/16688) tutorial (a PDF which can be downloaded in there...).
I took a look but uhh? Without the prog (and understanding all words in there) this didn't help me out so is a Maya user around who can please explain to a stupid one what exactly these Materials are? What's the difference to ordinary texture materieal applied to the mesh? OK, shader are "thingies" for effects in Maya, right? But in which point is the difference, what makes them special - and referring to topic, how can they be used by Maxis (yes, they were "improved" but they're used as a base...)?
(tried to express myself clear - did it work? :D)

Next qustion would be: what are these "MS D3D" :D

[Inge Jones]

Is MS3D3 the Milkshape file format?

[Khaibit]

Hey, Inge, you understood at least the "next question"! :D *patpat* :p
Would make sense - but why Milkshape when Maya was topic- Niol??? :wtf:

[Inge Jones]

*patpat* :p


/me Kung-fu kicks Khaibit :duck:

[Khaibit]

:cry:
/me strikes back with Kibotu :!:

[Inge Jones]

Watch out or I shall invert your normals! (Actually I am very good at that...)

[Khaibit]

Try that and I weld you together :P

(absolutely senseless fooling around - we're kiddies :lol:)

[Pixelhate]

I think the Milkshape file format is : .ms3d

[Khaibit]

*throws a Christmas tree ball at Pix* :p
Maybe it's version 3 :D
I just lost all my updated downloads, my updated neighborhood, collections... ARRRRRRRRRRRRRRRRRRRRRRGH!
For sure when you one time, just one **** time not back your files up because 1 million times didn't happen anything this time it happens, Murphy's law - at the moment I hate the base game starter - and the data recovery freeware tool Numenor suggested only says "Error 6" when trying to read my HDD - ARRRRRRRRRRRRRRRRRRRRRRRRGH!
I don't know anyway why Milkshape should be involved in Maya's shaders so why not version 3?
*takes a deeeep breath*...
I'm fine... *throws some Christmas tree balls around*

[Pixelhate]

Actual version of Milkshape is 1.7.10, so I don't get the link with a V3 ??

Despite all that blinky christmas crap all over me, I feel sorry and compassionate for you, Khai ! :lol:

[Khaibit]

*still throwing Christmas tree balls around*
The stuff at TSR isn't free anymore! :cry: Such a great male hair mesh!

There's nothing to 'get' except a valid explanation - mine was just the 1st idea I've had... MS could also be Microschrott without any reason - I don't know that's why I ask... and what's the result? Inge clobbers me, my PC looses data, and I still don't know more about the stuff... feels like Friday, 13th so far... :banghead:... and you even laugh at me... :faceslap: :blink: :D
*goes on throwing, targeting Numenor*

[teko]

Khaibit, you have mixed something up. :lol:

Niol said

MS D3D = Microsoft Direct 3D :D

[Khaibit]

:rofl: at least I wasn't wrong with Microschrott then!
What about forching Niol to type words instead of abbrs which confuse even Inge? :D

*throwing Chtrba at N.* :D

Thanks Teko :lol:

Edit: Teko, do you actually know what "KiBoTu" is? ;) Inge didn't understand me again I guess :D

[niol]

Khaibit,
...deleted...
Lol, may google and try various hard-disk recovery utilities if one doesn't work well in your case. But, I think system mechanic (spelling?) may help? I've used a few ones for different relatively desired results. So, I can't say what it must be good in your case. The best suggestion is to try out various ones out there.
the f it's just the failure of the operating system (OS), just use another HD with a relevant OS to recover the data. :lol:
If the files were deleted by an accident or a partition-failure, use those suggested type of softwares. :|
If it's hard disk (HD) failure, I'm afraid even a hardware technician may not be helpful except for the diagnosis. :(
...deleted...


Numenor,
That's really a long list of txmt infos... :gjob: :bunny: Thanks a big bunch. ...deleted...


pixelhate,
good reasoning, and that's why "D3D" can't be referred to the version of Milkshape. :D


teko,
Thanks for explaining that... :anime: ...my kiddy things deleted...except you did some really nice mirrory floor objects... :D Will you make custom-object-based ceiling reflective as well? Can you make the mirror floor compatible to the base game, too...? :anime:


added for the following post.

Khaibit,

:jokes & teases gone:
So, the KIds TUrn their BOdies over and around on the floor for the exercises? :D
Lol, Nu should have enjoyed your hugs a lot despite his pretending to try to survive! :lol: N, should that be fatal, that should still be what he dies for! :D
The dragon must have found that clueless coz the lost scorpio-pieces have formed new scorpios with more and stronger poisons that whoever touches them again will die immediately except their kind. So, the others only stay away or die. What a sharp blade! :rolleyes: :lol:

It says these new fatal scorpios can transform into dragon-feu-mann, too... weird? :lol:

[Khaibit]

Niol ...deleted...

Inge and Numenor fooled me perfectly, indeed :D
The "lost data" was a fake, caused by Numenor's phantastic and without any errors working ( :P ) BaseGameStarter (in fact it's really cool, unfortunately I struggle with one or two bugs...) - and the genious could help me to get my stuff back *phew!*

Your suggestions about KiBoTu aren't bad :lol: ...deleted...

Actually it's a stupid German abbr for Kinder Boden Turnen - children's floor exercises :faceslap: Maybe a bit more dangerous than kisses but my tempestuous hugs are even more risky - you can ask Numenor how he survived the last one I owed him :D


BTW, can you maybe help me out, try and explaining/ answering my question before we started to fool around? Would be cool, my little scorpio *says the dragon - and looks for lost scorpio-pieces lying around...* ;)



Added to the added stuff above:
Hey, on the one hand it's nice to stop spamming but on the other hand expecting the other to check for "edits" in already read posts is... clever :lol:

Yes, the children have to avoid exercises which can't be done lying. Who stands up is dismissed and has to sit on the bench - that's why KiBoTu is such a dangerous fight sport ;)

Hmm, thinking about it makes sense - this also explains why Nu wanted me to hug him to pay my debts of bets :lol: ... and now I even know what's the quota woman is good for :D :blink: Never mind! *jumps and huggs Nu even more tempestuously tempestuous* *goes on and huggs Ni also tempestuously tempestuous, too tempestuous to notice the perfume* :D Dragon-women aren't affected by scorpio- poison, the opposite: I can use your poison for defense, thank you.
*erhm* isn't it a bit frustrating when scorpios only can touch themselves or dragons? :D :P

Edit without deleting:
The dragon is amused about these tiny scorpios that can transform after hugging... lots of little Grizus around :lol:

[Inge Jones]

Am I the last person to realise this fact? If you set materials for your meshes in your 3D editor, such as wings or milkshape, the game respects many of those settings. I wondered why one moment my new object was to dark for the game and the next momoent it was too bright without me changng the material or the texture. It was because I had played with a material in Milkshape.

[Numenor]

Are you sure you haven't just played with the smoothing/welding/unwelding?
As far as I know, the GMDC (where you store whatever is output from MS) just ignore anything related to the materials. The smoothing routines built-in in MS are so illogical and misleading that sometimes the user just can't understand what's happening...

In any case, I can say for sure that neither the OBJ format nor the MS-ASCII format can hold information about materials. I don't know how the Unimesh plugin works, but I'd be rather surprised if it can store these info (the Unimesh, on the other hand, is strongly suspected to alter the smoothing).

EDIT: the OBJ format *can* hold info about the materials in a separate .mtl file, which is ignored by SimPE, anyway.

[Inge Jones]

Well, it certainly seemed to look that way. I can experiment some more with a flat plane - make a few copies and apply different materials in Wings without touching anything else about the mesh.

[WesHowe]

The only material parameter I know of in the GMDC is the opacity value. Whay this is stuck in with the mesh versus being included in the TXMT file is just a mystery to me.

Besides this, changing the normals could have a particular effect on the display brightness. While editing the normals is not doable in MilkShape, it is apparent that this can be done and used for effects by maya. In particular, the edge of the hem of a skirt mesh has each vertex in pairs, one with a normal pointing roughly horizontally outward from the mesh center, and one pointing downwards at the floor. This makes the edge sharp and prevents a darkened shadow at the hemline.

<* Wes *>

[teko]

Inge, the normals can affect the looking of an object a lot. Have a look at this example:

http://img85.imageshack.us/img85/2696/shadingnormalenpluginhh7.jpg
(Sorry for the german legend ;))

It's twice the same mesh. On the right side the normals are generated with Wings 3D and on the left side they are generated with a special plugin for Cinema 4D.

[Khaibit]

Teko,
the legend is clear to me (:D "Plugin" and "Shading" are a German words anyway ;)) instead of the 'message' - what do you want to show? It looks like the plugin turns the direction normals face to
(to light -> away from light) which shows the result in game... just wonder if you show this comparison because you prefer this plugin or what... I mean, what should this tell me, the context is missing if there is more than the topic discussed in here now *curious* Not relevant but well, I'm curious about it, that's all :)
Relevant seems to be the flipped direction normals are facing to ;)

All,
as I have to learn lots of things and it's somehow quite ineffective to try learning everything right now at once it's possible that the following is absolutely nonsense - if so feel free to laugh at me :D I'll do the same when I understood the reason ;)
So far I just downloadd the 3ds texture baking tutorial but did not read in it or work with it yet so isn't the princile to apply texture withing editing the UV map but applying the texture immediately onto the mesh and import this into SimPe again (suppose via .smd format or Unimesh, maybe both) at least possible somehow? (Even without owning Maya, I mean.)

In this case I dunno if it's possible to affect textures in MS, too or how exactly SimPe processes the texture data that 'came with the mesh' but this also reminds me of a problem reported by WindBlower who couldn't fix the brightness of a pumpkin mesh (Nu, do you maybe remember? Still unsolved as far as I know) so either it is possible or Inge, a similar mistake happened to you???


Edit:
for the original topic, TXMT...
As this thread (http://www.modthesims2.com/showthread.php?t=57265) contains a new post by KevinsHope I noticed it and I found a list of several reflection*whatever*-envcube listed by Dewshine (in post #5, unfortunately some typos included, see correction by Frillen in post #23 below...). I guess you all know already about these several "envcubes" and in the Pets aquarium (well, I noticed it there) I also found a "reflectionsparking-envcube". I didn't know them yet but they are great to know, something like that increases the possibilities. It would be very useful to include all the different possibilities of 'envcubes' (are they complete? Isn't there even more for outside-reflection of cars etc.?) and maybe even a short explanation of the effect they come with/ are good for/ how they look like.

I don't know where in the TXMT-xls by Nu they could be listed, suppose they don't fit the sceme as they're additional input which needs a kind of definition on it's own (at least for the average user!) but they belong to topic and a list can't be wrong; I think.
Thanks to all those guys in this "old" thread for collectiong and sharing infos :)

[KevinsHope]

Thanks so much for starting this discussion. I am learning a lot from reading it. It's a long one though!

[Inge Jones]

Yes Khaibit, envcube info is definitely very useful.

[Khaibit]

:lol: Thinking about, it definately makes sense for the Plugin for easy TXMT-editing :D (maybe even for the txmtdefinition.xml- update)

So what about listing the envcubes and their known usage in here to collect them, in best case even all ;)

So I re-post Dewshine's listing, hopefully free of typos and what else I know/ suppose so far, additions appreciated :)

Used for colorized reflections of textures:
reflectionbronze-envcube (orange)
reflectiongold-envcube (gold)
reflectionbronzenonlit-envcube (darker orange)
reflectiondarkgold-envcube (darker gold)
reflectiongoldnonlit-envcube (med tone gold)
reflectionsilver-envcube (sliver)
reflectionsilvernonlit-envcube (darker silver)
reflectionkitchenhighcontrast-envcube (rusty orange to black)
reflectionsparking-envcube (black to red)

Used for the glass-subset in the aquarium, seems to be required for effects??? Not used in bathtubes and else, also not used in the base-game aquarium...
reflectionsparking-envcube

Standart reflection surface, seems to be neutral, not colored... so as it's used for almost everything what are it's limits, why are other envcubes needed/ when have others to be used?
reflectionkitchenhighcontrast-envcube

Creates the outdoor reflection of cars, metal, glass, whatever
outdoordaytime-envcube

That's all I know/ suppose for now... additions?

[teko]

Sorry Khaibit for loosing the context. :p It should show how an object can look with different normals generated and that the GMDC cannot save any material definitions (except the opacity). :)

Here are a few more of the envcube:

The Sims 2

reflection-generic (something like reflectionkitchenhighcontrast-envcube)
nightreflection2-envcube (dark violet)
reflectionoutdoorwater-envcube (landscape)
fencemoroccangate-envcube (black-brown-yellow-white)
swimming_pool-envcube (blue-white-blue gradient)
gothlivingroom_01-envcube (brown)
neighborhooddesert-envcube (desert sims landscape)
neighborhood-sky2-envcube (blue-turquoise gradient)
outdoordaytime-envcube (landscape with a forest)
outdoornighttime-envcube (violet with white spots)
sidebluelights-envcube (black with a violet spot)
skymap-generic-day-envcube (blue-turquoise-darkblue gradient)
skymap-generic-day-highres-envcube (blue)
skymap-generic-night-envcube (dark violet)


Nightlife

reflectionkitchenhighcontrastonyx-envcube (blue)
reflectioncubecityscape-envcube (city with skyscrapers)


There are some more but just templates by Maxis.

[Inge Jones]

That reflectionoutdoorwater doesn't work as originally designed. Maxoid Tom told me some time ago that they disabled it internally other than in hood view as it was messing up the mirrors. :(

[Khaibit]

:D Nice that I'm not the only context-looser ;) :P
Forgot to say, added: thank you for explaining the context to me :)
Eh, but this means that texture baking works not as I thought it would (it does work, doesn't it?)... before I start trying this I have to get along with anim/BHAV editing and slots (the stuff I have to texture is easy to do with UVmapper)

Cool, thanks a lot for the additional envcubes! :up:
Curious again, how did you find them? By chance or are they listed somewhere?

Then reflectionsparking-envcube seems to belong to Pets...?

Inge, seems like some envcubes have to be checked not only for purpose but even for 'being in use'...

[teko]

Khaibit, the "Finder" in SimPE is very useful for such things. :D

@Inge
How is it disabled? So we cannot link this texture like the others?

[Khaibit]

:lol: Great - I always struggle with SimPe's features *trying* and I don't know if it just takes ages or if I'm not able to adjust the "Finder" to find things... at the moment I'm even unsure if my Finder can search al least...
Guess I'm too stupid for SimPe :cry: :faceslap:

[Inge Jones]

Now, as the conversation took place very early on in the game, it is probable I didn't understand it fully. However, I was asking Maxoid Tom if it was possible to make the water in garden ponds and the water in the neighbourhood you can see from the lot as nice as the reflecting water you can see when in neighbourhood view.

He replied:

'We had the water at the lot level reflective at one point, but had to take it out at the very last minute because on certain cards (or perhaps all, I don't recall) it would conflict with mirrors.

It may not be as simple as changing the material from "lotSkirtSeaNoReflection" to "lotSkirtSea," since we have some code-level things disabled.'

Ok so this isn't the same envcube after all. It just reminded me of that, and the same principles may be involved.

[teko]

I'm going to have a look at these materials because they contain some interesting stuff anyway. :)

[niol]

Khaibit, find it with "keystring" like "envcube". :)
Besides...reflectionsparking-envcube does exist in the base game.. find it out...

Inge, odd... I thought I saw some default settings using this texture. Maybe, I mixed things up tho. Probably, those settings are disabled, too. But, the texture isn't what I thought it were. I guess it's more useful for the matte sphere... :D

The neighbourhood water reflection has its own definitions and "commands" in the neighbourhood shader apart from the mirror shader. The mirrory reflection or the neighbourhood water reflection is completely different from the env-mapping...
The former is basically defining a certain area of the screen to show the mirrory patterns of the pixels in order to simulate the corresponding mirror effect. (say, in a photoshop, you're doing a mirroring of an image; in TS2, the mirror shader is dynamically mirrorring or flipping of an image relative to the mirror area. n, the sides of a mirror in the monitor screen will be the boundaries of the "reflection".)
The latter is a presumed/predefined pattern/image/texture of a reflection, in which the pattern of a reflection is predefined/preset/presumed/fixated to apply on the base texture map. The content of the reflection has nothing to do with the surrounding indeed, but just a generalised reflective look.

[Khaibit]

Niol, how can I enter a keystring, anything in the finder??? Can choose a bit in "Find" and "Match" (some preselected stuff, where to try finding) but that's it so can it read my mind or how can I start searching to hopefully find? (And why is the interface of SimPe not explained, only tutos for procedures but I can't even find (already looking for month...) an explanation of the interface (what to do how, what is possible and if so how- seems like you have to be a developer (or a finder) to get along with SimPe... *frustrated* :wtf:

If I make it to find (at least I made it to find out that the updated QA completely shuts down after a "tilt" SimPe because of finding-trial... and yep, Inge psje is updated, too... doesn't help finding anyway - what am I actually doing wrong???) I'll do a happy dance when knowing where the reflectionsparking-envcube is used in the base game... *doing an agressive war dance surrounding the Kriegsklappstuhl to fight SimPe and my PC*

Thank you that you try to help me out - so you're invited to have some Dampfnudeln (???) with me when finished :D *preparing*

[niol]

Khaibit,

Did you read this here or that in the simpe site just in case...
SimPE - From The Ground Up (User Manual)
http://www.modthesims2.com/showthread.php?t=80960

That texture has already existed in the base game texture.package file, so may open it with your simpe... :)

[Khaibit]

Yes, Tazzman's explanation explains what I can manage on my own but things like "how to get SimPe displaying the objects in English to be able to compare the names with English filenames" and else isn't explained (know how, already :D) and Tazzman's explanation of the finder... yes. Found out on my own at last :faceslap: Just enter the keystring in "ResourceName" and that's it :lol: I need the explanation for the technical challenged! *embarassed*

[niol]

Indeed, I also want a prism-like effect...! Like highly cut diamond. Some people do have this type of caustic material shader...

[Pixelhate]

An ultra basic sketch for the tree analogy/illustration...

*edit* not needed anymore I guess..

[Khaibit]

Hi Pix,

here is your test cube. Just cloned and changed the mesh, only one change in the TXMT to get default values (and changed the texture itself :D) Didn't try in game.

And others: do not try to download this object, it is password protected because it uses a temporary GUID I'll recycle for "real" objects again. To avoid GUID conflicts you cannot open the RAR. It's just a requested "play around with the TXMT - object" so if someone needs one he/she can create one on his/her own I think.
Niol, if you could use it too and you don't want to try creating a cube mesh I can tell you the password, too. It will take some time until the cube can start to conflict - but it will somewhen - in this case you should be able to create your own cubes, too :)

Ah yes, created with SimPe 0.61.3QA (thanks Quaxi and crew), Milkshape 1.7.10 and UV Mapper pro - Credits can't harm :D Texture by me :D
Because of the (not changed) shadows 20 faces, 40 vertex.

Only Base Game required.

Edit: removed the download with it's temporaty GUID (3 user downloaded... :D). I don't want to risk conflicting your stuff with using the test cube.

Offering this cube for everyone will be ok to me, in this case I will keep this GUID and you wouldn't have to worry about it. So ask me if you want it, ok?

Keep the credits of course, they're still valid :)