New material-naming standard

#1 Ahh ok then that sorts it out a little clearer

#2 Ah yeah that's definitely wrong.. it should be setting mapTo to the material name.. not diffuse color.

#3

Quote:
Ah yeah that's definitely wrong.. it should be setting mapTo to the material name.. not diffuse color.

So you think Collada should do this differently from DTS (which maps to the diffuse texture name and never references the 3d modeling apps material name)?

#4 I think that the material name should be used with mapTo in the material definition.. same reason as what I said in the email thread (even though I was misunderstanding what Russel was saying). I'll post it here since this is where the topic is now.

Quote:
I think that a torque material should be applied via material instead of texture name because it's current implementation has caused some irritating workflow problems in the past. Let's say I have 1 diffuse texture shared by 2 objects, but on one object I want the material to animate scroll and the other I want to animate rotate (or even something simple like a different specular power on both). That means I have to create a duplicate dummy texture for the application to reference and then have my material.cs mapTo the dummy texture but actually use the same texture the other object is using.

A solution for people forgetting that they have to name a material could be a simple script that would have a check box for "Material Name = Diffuse" which would rename all used materials and export.

#5 Uh oh. I think I may have mis-spoke. I confused the MapTo with the BaseTex when I wrote all that up. Let me figure this out and post back here in a few minutes.

#6 OK, I've updated the original post. Ostgard is correct, it should be (and is) using the material name as the MapTo value.

#7 Should we also change that for DTS's? Seems odd to have that be inconsistent between DTS and Collada.

How badly would that impact the current DTS's/materials.cs files? Could we perhaps base that on the DTS version number?

#8

new Material(Vine)
{
   baseTex[0] = "vine_diffuse.png";
   translucent = true;
   mapTo = "vinematerial";
};

where: new Material(Vine) = create a torque material (i say torque to be clear is not max or softimage or maya material);

where: baseTex[0] = "vine_diffuse.png" = specify the base texture

and finally :mapTo = "vinematerial" = mapTo the (3dsmax, etc, material name) material

It does the job, it makes sense and it should probably be used for both collada and dts to avoid further confusion;

#9 To use the same diffuse texture for more jobs (animated flags, specular information and so on) just duplicate the material in the 3d app and add a new material entry in materials.cs;

fy, exported from xsi 7.0.1 doesn't work;

#10

Quote:fy, exported from xsi 7.0.1 doesn't work;

Could you provide the model that is not working in the xsi samples thread? Is it just the materials that are not showing up, or something else?

#11 I made a material named vine_diffuse.png (to be consistent with the example), renamed the xsi material to vinematerial and exported; in torque this example shows up gray (no warnmaterial), so the material/texture is there, only messed up somehow.

download example

#12 I am having somewhat similar issue, from U3D...I get a black texture, or bright orange...

new Material(basePlayer)
{
   baseTex[0] = "player.png";
   translucent = false;
	mapTo = "basePlayer";
};

is my material.cs with my bitmap and shapFiles.

my bitmap is named "player.png", and my U3D[collada] material is "basePlayer".

#13 Here is the DAE 'Kork' character that does not render it's material no matter what I do in materials.cs. I tried to follow the suggestion above and no go, I followed any other material.cs file I found and no go....I'm sure it's some 'simple' line of script. This is the most frustrating part of 'TGEA' rendering...imho, for me at least.


Another 'render' oddity I get in this build and almost any other 'advanced' engine of torque, when I open the Mission Editor, the ground slides around under me as if I've selected it?? and my player often falls thru terrain?? IE< I find opening the Mission Editor very glitchy.

Ya, that's it...I keep selecting the terrain object and moving it...how do I 'lock' the 'megaTerrains'...?? to keep from selecting them once I've popped into the Cam mode?

Thanks.

#14 I'm still a bit torn about the material-naming standard.

I feel like the "right" thing to do is to make Torque Material names the same as the material names in the 3d app (rather than the diffuse texture name), as is currently done by the Collada loader.

But since the cached DTS file only stores the material name, the diffuse texture cannot be found unless you

a) name the 3d app material the same as the diffuse texture OR
b) create a materials.cs script for every model.

(b) seems totally overkill for shapes that need only a diffuse texture (or diffuse + transparency). (a) is a little more palatable, but will undoubtedly cause initial confusion/frustration among the Torque community, as people are used to the diffuse texture = material name concept.

#15 If those are the two options, my vote is to go with (b) as well. Making a material.cs for each mesh in Torque is just standard practice, as far as I'm concerned. The redundancy of (a) seems a little sloppy, anyway.

#16 The third option is of course to keep the material name = diffuse texture approach. That has always just felt "wrong" to me, but this may be one of those times when the right approach is not the best! ;-)

#17 I like (b) better as well.

#18 Another thing to consider is how important it is to make it easy to re-export old meshes previously created for dts export. The current Collada exporting requires two changes that I've noticed... 1) the MapTo issue discussed here, and 2) the naming convention of the Base and Start nodes (that they must now be named Base01 and Start01). (Edit: subsequent posts indicate this has changed... any numerical configurations in the form of BaseXX and StartXX are now acceptable)

Personally, I think having things work in a way that feels "right" is a better approach than sticking to old routines, even if that means a couple of changes need to be made to old meshes to have them export correctly to Collada.

#19 Eh? I can live with whatever works, prefer 'most intuitive'...as long as it's documented with examples....I can live with any schema, lol. I don't mind writing scripts for each model[...eh..], that can be a lot of shapes, in a large project; some automated mechanism would be nice...possible? To do the 'heavy lifting' with some applied existing leverage. Say...look thru all shapes in such/such folder, write proper script based upon shapes data...?? Sound sexy, does to me, LOL!


So, what would be the current 'working solution' for my example with a 3Dapp material name of 'player' and a texture of "player.png"?

Thanks, Chris. Been busy gigging, and haven't edited the P4 Skeleton file to make it build correctly, then I could look at that material as well. Did it work for you?

#20 Maybe if it wrote to an alternate name (materials.cached.cs) so that the materials can always be written on load and won't mess with anything the user defined in materials.cs.. and materials in materials.cs take precedence for what is actually being applied to the model.