Eporting per material material file?

Hi Lioric,

I'd like to be able to export the individual oFusion materials from within my 3ds Max material editor to individual .material files. If there's no way to do this, perhaps you could consider this a feature suggestion.

I'm building a fairly complicated scene - a barnyard with a few buildings and terrain - and I'm getting to the point where I have to make frequent revisions and updates to the materials.

Originally I exported the whole scene all at once, and this produced, among other things, a barnyard.material file containing all the material definitions for the whole scene. These definitions correspond to the materials in the Max material editor.

Now I'm fixing up bits and pieces, and I want to re-export only these pieces. Doing so, however, creates material conflicts.

Say for instance I re-export a building within the barnyard: the chicken coop. That export produces, among other things, chicken_coop.material. Now my game directory has a barnyard.material file and a chicken_coop.material file. A problem arises because these .material files contain identical material definitions, and that'll cause the game to crash. In this case, the original barnyard.material contained definitions named wood_material, chicken_wire_material, dirt_material, windmill_material, etc, etc. The chicken_coop.material file *also* contains wood_material, chicken_wire_material, and like I said, that causes a crash.

I see the oFusion exporter provides an option to export a per-mesh material file, but that wouldn't work for me because my scene contains so many meshes (because the buildings can break up into pieces). Even if I didn't have so many tiny pieces, I would prefer that different meshes be able to share .material filess.

Why not have an option to export per-material material files? That is, for every material within the Max material editor, export an Ogre .material file. That would eliminate the problem of conflicting material definitions: any potentially conflicting .material files would just be overwritten. This would, for me, really smooth out the art update pipeline. Not to mention the fact it would be more comfortably analogous to the way Max handles materials.

If there's a way to do this already, please let me know . Otherwise, I hope you'll consider this as a possible feature.

it would definately be nice to get around conflicting duplicate materials. It's one of the biggest problems we have too.

I think its quite hard to pull off at the moment but should be easier in the next version of Ogre which supposedly lets you intercept loading and should in theory allow you to ignore duplicates with the same name.

Actually is quite easy to handle duplicated materials in current Ogre versions, it as simple as adding a few lines to the resource group system to be notified in your applciation of the material load process via the resouce listener, and to update any material currently in your scene with the new material definition from the file being loaded

About exporting materials directly from the Material Editor, how would you select what materials are to be exported exactly? it is common to have several materials that are tests only and others that are acutally used

Do you mean a "export to file" button in the material panel?

Hi Lioric,

I'm not suggesting an export directly from the material editor. I'm thinking instead something more like a check box in the oFusion export dialog box. Right below the check box that says, "Per Object Material File" I'm envisioning a checkbox that says, "Per-Material Material File."

Here's an example of how that might work:

Currently, with my chicken coop scene, I have, in Max, a multi/sub-object oFusion material called coop_multisub (applied to a number of objects in the scene), and a standard oFusion material called chicken_wire (applied to the wire fence object). Within coop_multisub, there are three sub-materials: coop_planks, coop_plywood2, and coop_treering.

When I export, I do so to a scene file called chicken_coop.osm, and this produces a material file called chicken_coop.material.

Within chicken_coop.material, I see the following:

material chicken_wire
{
technique
{
pass
{
ambient 0 0 0 1
specular 0 0 0 1 10
scene_blend alpha_blend
alpha_rejection greater 46

texture_unit
{
texture_alias textureUnit_0
texture sd_chicken_wire.tga
}

texture_unit
{
texture_alias textureUnit_1
texture sd_chicken_wire_lm.jpg
tex_coord_set 1
}
}

}

}

material coop_multisub/coop_planks
{
technique
{
pass
{
ambient 0 0 0 1
specular 0 0 0 1 10

vertex_program_ref NM_2UV_vs
{
}

fragment_program_ref NM_2UV_ps
{
param_named ShineValue float4 0.05 0 0 0
param_named_auto lightColor surface_diffuse_colour
}

texture_unit
{
texture_alias lmap
texture sd_chicken_coop_lm.jpg
}

texture_unit
{
texture_alias dmap
texture sd_wood_planks.jpg
}

texture_unit
{
texture_alias nmap
texture sd_wood_planks_nm.jpg
}
}

}

}

material coop_multisub/coop_plywood2
{
technique
{
pass
{
ambient 0 0 0 1
specular 0 0 0 1 10

vertex_program_ref NM_2UV_vs
{
}

fragment_program_ref NM_2UV_ps
{
param_named ShineValue float4 0.05 0 0 0
param_named_auto lightColor surface_diffuse_colour
}

texture_unit
{
texture_alias lmap
texture sd_chicken_coop_lm.jpg
}

texture_unit
{
texture_alias dmap
texture sd_plywood2.jpg
}

texture_unit
{
texture_alias nmap
texture sd_plywood2_nm.jpg
}
}

}

}

material coop_multisub/coop_treering
{
technique
{
pass
{
ambient 0 0 0 1
specular 0 0 0 1 10

vertex_program_ref NM_2UV_vs
{
}

fragment_program_ref NM_2UV_ps
{
param_named ShineValue float4 0.05 0 0 0
param_named_auto lightColor surface_diffuse_colour
}

texture_unit
{
texture_alias lmap
texture sd_chicken_coop_lm.jpg
}

texture_unit
{
texture_alias dmap
texture sd_tree_ring_grey.jpg
}

texture_unit
{
texture_alias nmap
texture sd_tree_ring_nm.jpg
}
}

}

}


What I'm suggesting is, if I was to check this "Per-Material Material File" box, the exporter would produce two .material files: one called chicken_wire.material, and the other called coop_multisub.material - names that come straight out of Max's material editor. Within coop_multisub.material would reside the material defs for that multi/sub-object material: coop_planks, coop_plywood2, and coop_treering.

Basically, I'm suggesting just chopping up the .material export according to the material definitions. Then naming these .material files according to the material definitions.

It's all about making the material export consistent with the way materials work within Max itself. This then makes it so that re-exporting creates fewer material definition conflicts.

As to your point about selecting which materials get exported, it seems to me that wouldn't be a problem because the exporter already selects the contents of the .material file based on which geometry is visible.

It's just a matter of breaking the resulting .material export up into a few more .material files, according to the materials defined in Max's editor.

Actually is quite easy to handle duplicated materials in current Ogre versions, it as simple as adding a few lines to the resource group system to be notified in your applciation of the material load process via the resouce listener, and to update any material currently in your scene with the new material definition from the file being loaded


Hi Lioric, Our coder asked "Do you think you could ask llioric to elaborate on his fix for the duplicate problem? He is probably more versed with the ogre material system than I am, and I can't find much info on listeners. If it's just a few lines then it'd be nice to just have him say where to look."

Would be really helpfull if you could point out where in the code they should look to fix duplicate materials.

An article will be posted in the next hours with more details on the modification needed to handle duplicate materials in Dagon

Thanks Lioric thats more than we were asking for . It might be worth adding it to the Ogre Wiki since its a common problem that crops up endlessly in the forums and doesn't seem to be addressed anywhere.

Hmm, just some info regarding where abouts in the source code the material listener is, and the aproximately where modification would go would be sufficient. I expect Lina can work our how to implement it from there.