New material-naming standard
by Russell Fincher · in Collada Test · 01/06/2009 (11:56 am) · 36 replies
Note: this post has been updated to fix some errors.
I tried rather poorly to explain this in the email discussion, but I'll just document it here.
Previously, the MapTo value in the materials.cs file referred to the name of the base/diffuse texture:
But with the Collada importing, the MapTo value refers to the name of the overall material, not a specific texture. So it would go something like this:
Where vine_diffuse.png is the diffuse texture, and vinematerial is the name of a collection of textures that make up a material in your modeling program.
I've usually (though not in this example) just been naming the material in Max the same name as the diffuse texture, so that file can easily be exported as both a dts and a Collada, and use the same materials.cs file.
I tried rather poorly to explain this in the email discussion, but I'll just document it here.
Previously, the MapTo value in the materials.cs file referred to the name of the base/diffuse texture:
new Material(Vine)
{
baseTex[0] = "vine_diffuse.png";
translucent = true;
mapTo = "vine_diffuse";
};But with the Collada importing, the MapTo value refers to the name of the overall material, not a specific texture. So it would go something like this:
new Material(Vine)
{
baseTex[0] = "vine_diffuse.png";
translucent = true;
mapTo = "vinematerial";
};Where vine_diffuse.png is the diffuse texture, and vinematerial is the name of a collection of textures that make up a material in your modeling program.
I've usually (though not in this example) just been naming the material in Max the same name as the diffuse texture, so that file can easily be exported as both a dts and a Collada, and use the same materials.cs file.
About the author
Art Lead at Sickhead Games, focused on dev tools and prototyping, instructor/advisor at several Dallas colleges and universities, Associate Developer with GarageGames, champion of avant-garde game art at uncommonassembly.com.
#22
I wanted the loader to be able to load any collada model at all - not just those that have been specifically set up for DTS export. Non DTS-marked-up shapes often contain meshes named "Box01", "Box02" etc, which if interpreted in the 'DTS' way would indicate a "Box" object with details of size 1 and 2 => not what was actually wanted!
So the loader looks for the baseXX->startXX node hierarchy, and if it does not exist, it loads all geometry in the model to a single detail level (size 2). If the hierarchy does exist, the loader parses the LOD markup nodes as normal.
This is just one of the assumptions made by the loader that I'm not really happy with. It works most of the time, but when it doesn't there needs to be an easy way to override the default behaviour.
An idea I floated to MattF was to have an optional script in the model directory (just like we do with models that use TSShapeConstructor datablocks, it could even be the same script) that would allow the collada loading process to be controlled a bit better. The script might allow you to do things like:
- force DTS markup mode
- for non-DTS markup mode, load all geometry to a single detail level of size X (not always 2)
- autogenerate materials.cs using the collada file settings
- override the scale value in the collada model for exporters that get it wrong
- override the up_axis value in the collada model for exporters that get it wrong
It all gets a bit tricky though with the new detect-file-changes-and-auto-reload feature. ie. You have Torque running, then re-export the collada model and it will update automatically ingame. The auto-reload needs to take into account this new script, and also any TSShapeConstructor settings that must be applied after the shape has been reloaded.
01/12/2009 (8:12 pm)
@Russell: The base01->start01 requirement has been relaxed to baseXX->startXX where XX can be just about anything. The loader only looks for this hierarchy so it can make a 'guess' about whether the shape has the DTS markup nodes (LOD and sequence markers).I wanted the loader to be able to load any collada model at all - not just those that have been specifically set up for DTS export. Non DTS-marked-up shapes often contain meshes named "Box01", "Box02" etc, which if interpreted in the 'DTS' way would indicate a "Box" object with details of size 1 and 2 => not what was actually wanted!
So the loader looks for the baseXX->startXX node hierarchy, and if it does not exist, it loads all geometry in the model to a single detail level (size 2). If the hierarchy does exist, the loader parses the LOD markup nodes as normal.
This is just one of the assumptions made by the loader that I'm not really happy with. It works most of the time, but when it doesn't there needs to be an easy way to override the default behaviour.
An idea I floated to MattF was to have an optional script in the model directory (just like we do with models that use TSShapeConstructor datablocks, it could even be the same script) that would allow the collada loading process to be controlled a bit better. The script might allow you to do things like:
- force DTS markup mode
- for non-DTS markup mode, load all geometry to a single detail level of size X (not always 2)
- autogenerate materials.cs using the collada file settings
- override the scale value in the collada model for exporters that get it wrong
- override the up_axis value in the collada model for exporters that get it wrong
It all gets a bit tricky though with the new detect-file-changes-and-auto-reload feature. ie. You have Torque running, then re-export the collada model and it will update automatically ingame. The auto-reload needs to take into account this new script, and also any TSShapeConstructor settings that must be applied after the shape has been reloaded.
#23
Anything between those tags can be overwritten at any time by the engine. Anything outside the tags must be left alone. So the collada loader (or another tool like the Material editor?) could happily write into materials.cs without fear of overwriting an artists manual settings. The trouble of course is how to neatly have the manual settings override the automatic ones, but that shouldn't be too difficult.
01/12/2009 (8:15 pm)
@Matt: Another alternative is to write into a clearly indicated region of materials.cs, just as we do with .gui script files. eg.//--- OBJECT WRITE BEGIN --- //--- OBJECT WRITE END ---
Anything between those tags can be overwritten at any time by the engine. Anything outside the tags must be left alone. So the collada loader (or another tool like the Material editor?) could happily write into materials.cs without fear of overwriting an artists manual settings. The trouble of course is how to neatly have the manual settings override the automatic ones, but that shouldn't be too difficult.
#24
If anything above is wrong please do correct me. I heard many people confusing this mapTo thing in the past so let's clear it out a bit.
Also, I am not for changing the loader (from the right way of doing it) just for the sake of 'people are used to doing it that way' or because there are models to port over. As long as you are exporting the model as collada anyway, naming materials in the 3d app is common sense and just match those names with the materials.cs entries.
01/12/2009 (8:58 pm)
The mapto thing looks like it's telling the engine what texture is applied to one material (or other shader features like transparency); that means I can use a texture in 2 or more places (redundancy in assets gone). So whatever material I am applying to a model, I actually use the material name. I then can change the diffuse texture (or settings) however I want. If that's the case, it's irrelevant what the diffuse texture name is as long as it's hooked to the model via materials.cs in the (exported as collada) model. If the collada loader looks after the material only, the materials.cs script will tell the engine what settings that particular material has (texture, flags, whatever);If anything above is wrong please do correct me. I heard many people confusing this mapTo thing in the past so let's clear it out a bit.
Also, I am not for changing the loader (from the right way of doing it) just for the sake of 'people are used to doing it that way' or because there are models to port over. As long as you are exporting the model as collada anyway, naming materials in the 3d app is common sense and just match those names with the materials.cs entries.
#25
01/12/2009 (11:13 pm)
@Chris: That could work. I would personally prefer it to be a completely separate file, but keeping everything in one place is good too. At first I was thinking it would need to have a date and time (which could still be stored in a comment).. but I suppose all you really need to check against is the *.cached.dts files. Sounds great.. really excited to try it out.
#26
@Apparatus: Yes.. but if we _only_ did that then we won't be able to use auto-generated materials (except on the first session before the cached.dts file is created) because DTS can only store one name for the material. Normal map, specular and all that will be thrown out. That is unless we read the DAE even if an up to date cached.dts file existed and regenerated the material for that session. I think that is bad though because then you can't just delete DAE file when you want to publish.. you would have to write the materials.cs manually and then ship it.
No doubt in my mind though that we should be using the material name instead of diffuse tex name.. but in order to take full advantage of collada generated materials, I think it needs to be written out to materials.cs.
01/12/2009 (11:47 pm)
EDIT: Modified for clarity.@Apparatus: Yes.. but if we _only_ did that then we won't be able to use auto-generated materials (except on the first session before the cached.dts file is created) because DTS can only store one name for the material. Normal map, specular and all that will be thrown out. That is unless we read the DAE even if an up to date cached.dts file existed and regenerated the material for that session. I think that is bad though because then you can't just delete DAE file when you want to publish.. you would have to write the materials.cs manually and then ship it.
No doubt in my mind though that we should be using the material name instead of diffuse tex name.. but in order to take full advantage of collada generated materials, I think it needs to be written out to materials.cs.
#27
Leaving for the last day of a corporate gig soon, I'll be free tomorrow on; I'll head back in to the engine for some looking and tinkering.
01/13/2009 (4:47 am)
Now...what happens with setSkinName? and the special namingConvention of the bitmap texture. I believe I started this shape out as that....what would you name the 3d app Material? Same as the bitmap? 'base.player'?? And will any of this new schema affect the legacy setSkinName feature?Leaving for the last day of a corporate gig soon, I'll be free tomorrow on; I'll head back in to the engine for some looking and tinkering.
#29
01/30/2009 (5:43 am)
We're back!? Last I heard, we were using the old email discussion... good to see our forum up again.
#30
I need confirmation on this or clarification on how it currently works; I am looking at this issue through the eyes of someone with zero information (new to the engine) and I am aiming at something straightforward; Thus:
How is mapto actually working with the current exporters (max, maya, milkshape and others); also, for each app, what collada exporter is used.
Naming conventions explained;
materials.cs editing (i.e. for maya you need to add the file extension or not anymore?)
Being a forum and such things get easy off topic so let us keep the topic, at whatever costs; Just make another topic somewhere else and simply point the link if really necessary;
01/30/2009 (7:51 am)
I am quoting meself, but I really want to stress this out a bit:Quote:The mapto thing looks like it's telling the engine what texture is applied to one material (or other shader features like transparency); that means I can use a texture in 2 or more places (redundancy in assets gone). So whatever material I am applying to a model, I actually use the material name. I then can change the diffuse texture (or settings) however I want. If that's the case, it's irrelevant what the diffuse texture name is as long as it's hooked to the model via materials.cs in the (exported as collada) model. If the collada loader looks after the material only, the materials.cs script will tell the engine what settings that particular material has (texture, flags, whatever);
I need confirmation on this or clarification on how it currently works; I am looking at this issue through the eyes of someone with zero information (new to the engine) and I am aiming at something straightforward; Thus:
How is mapto actually working with the current exporters (max, maya, milkshape and others); also, for each app, what collada exporter is used.
Naming conventions explained;
materials.cs editing (i.e. for maya you need to add the file extension or not anymore?)
Being a forum and such things get easy off topic so let us keep the topic, at whatever costs; Just make another topic somewhere else and simply point the link if really necessary;
#31
For me, the MapTo variable in the materials.cs is asking for the name of the material built in Max... the one that would normally contain diffuse, specular, normal maps, and other internal material settings. I'm assuming all Collada exporters are capable of exporting the material name. So, unlike before when using DTS, the MapTo is NOT asking for the diffuse texture name. There's really no other configuring that needs to be done inside the modeling programs besides naming the material the same thing as the MapTo value in the materials file, or vice versa.
I've been using the Feeling Software exporter for Max 2008, and the native Collada exporter for Max 2009.
App, can you be more specific about your questions with naming conventions and materials.cs editing?
01/30/2009 (8:13 am)
I know I've said this before, but just to see if I can make it clearer:For me, the MapTo variable in the materials.cs is asking for the name of the material built in Max... the one that would normally contain diffuse, specular, normal maps, and other internal material settings. I'm assuming all Collada exporters are capable of exporting the material name. So, unlike before when using DTS, the MapTo is NOT asking for the diffuse texture name. There's really no other configuring that needs to be done inside the modeling programs besides naming the material the same thing as the MapTo value in the materials file, or vice versa.
I've been using the Feeling Software exporter for Max 2008, and the native Collada exporter for Max 2009.
App, can you be more specific about your questions with naming conventions and materials.cs editing?
#32
The 'mapTo' field tells Torque to map the Material object defined in materials.cs to the DTS material named xxxx.
01/31/2009 (6:13 pm)
You've got it exactly right, Russell. Even a low-end app like Milkshape separates the name of the material from the name of the textures (diffuse, bumpmap etc) used by that material.The 'mapTo' field tells Torque to map the Material object defined in materials.cs to the DTS material named xxxx.
#33
I remember I had this all mixed up in the start.
02/19/2009 (1:10 am)
Maybe a bit late on this thread but I have to agree that the mapTo value should be pointing to the Application Material Name and not the Texture name.I remember I had this all mixed up in the start.
#34
How do you have 2 models using the same base texture, 1 with a normal map, the other without? When I attempted this in 1.7.1, both objects were using the normal map. (looked really odd) Which of the ways mentioned above would make this easier. (remember, I am NOT an artist. I just pretend to be one for testing)
02/19/2009 (4:22 am)
My question about all this is:How do you have 2 models using the same base texture, 1 with a normal map, the other without? When I attempted this in 1.7.1, both objects were using the normal map. (looked really odd) Which of the ways mentioned above would make this easier. (remember, I am NOT an artist. I just pretend to be one for testing)
#35
The ability to create a new (multi) material.
Change the ambient/diffuse power /color
Change specular power /color
Diffuse, specular, normal as separate entities; tie the specular to color or normal map and you will limit a lot the options.
Flags like glow, scroll, detailmap
and so on. The way I would really love to see it, as a personal wish not as a 'why is not like I want it' thing. Of course, if this route is picked up, nobody will ever need to even have a materials.cs in the first place, and let the engine handle the materials internally.
02/19/2009 (4:47 am)
This mapTo thing should be dropped altogether once the engine will handle materials inside the editor and act like any regular material library. The only unique objects are the maps (color, normal, specular. The materials can share unique maps and do whatever you please, use the same grate texture here with normal map and there, on a second material, without, or even something like a different ambient and specular power. Many top engines have some kind of default on their materials library, with basic and (depending on engine) advanced shader options. The basic stuff should give you:The ability to create a new (multi) material.
Change the ambient/diffuse power /color
Change specular power /color
Diffuse, specular, normal as separate entities; tie the specular to color or normal map and you will limit a lot the options.
Flags like glow, scroll, detailmap
and so on. The way I would really love to see it, as a personal wish not as a 'why is not like I want it' thing. Of course, if this route is picked up, nobody will ever need to even have a materials.cs in the first place, and let the engine handle the materials internally.
#36
02/19/2009 (9:19 am)
Quote:How do you have 2 models using the same base texture, 1 with a normal map, the other without? When I attempted this in 1.7.1, both objects were using the normal map.Mike, you just need to set up two sets of materials in your modeling program, and two corresponding sets of materials in your materials.cs file (one configured to include normal maps, and one configured to omit normal maps). The materials can share maps if they need to.
Associate Chris Robertson
The only trouble you might hit is a name collision if there are other shapes also using the 'player' material.