Feature request: Direct .material file support

I'd like to be able to just specify the .material file on disk to use, rather than using oFusion's material system. There are many reasons for this:

The problem

1. It's far easier to give a set of .material files to artists than to give them a material library.
2. Artists very rarely want to change settings in the .material file, so exposing the entire material system for ogre is overkill and confusing
3. Mass changes (such as adding a pass to all instances of a material) can be done very easily with material inheritance, or mass find/replace. The equivalent change takes an order of magnitude longer in the GUI and is error-prone.
4. I can put a set of .material libraries in source control, which can then be merged, etc. I can't do this with materials in MAX material libraries.
5. I can hide settings artists would never change in a base .material file, and expose those they would change (such as the texture name), making things easier for them to learn and use. Right now the system is extremely complex upfront and would overwhelms an artist, who would simply not make any changes rather than try to learn it.
6. The majority of what one does in the oFusion material editor is programming, not art, and doesn't fit well in the MAX environment.
7. Adding new materials is very time consuming - Every time I have to think about all the properties I want to change, rename the pass, technique, etc, reset the shader parameters, etc. The equivalent in a text file (copy / paste) takes about 5 seconds.
8. The majority of the bugs I've found are related to .materials. Saving, exporting, copying, rendering all have problems. The art pipeline is halted at the export stage until these are all fixed. Having a fallback would make things significantly easier.

I could do this by using Ogre's exporter directly, but then I lose the main reason I licensed oFusion, which is the real-time viewport so artists can actually see the game while they work.

The solution

Add a new material "oFusion Material Script" which has only two buttons - the name of the .material file and a "reload" button.

When I click the name of the material file, it brings up a prompt and lets me select from disk any file with a .material extension.

These files are never exported as materials themselves. The mesh will be exported referencing the .material file I select.

If this were put in I could have my artists do in-game exports immediately and all my other bug reports would be bypassed.

What do you think?

After you had brought up the previous issue I was thinking the exact same thing. The simplest work around would be to keep the materials external and only referanced by the oFusion material editor. This would allow for a cleaner material library (for cvs/svn, etc.), and still retain all of oFusions existing material capabilities. Its still isnt a real solution, however.

The main reason I am interested in oFusion is due to its use of a popular commercial package, 3dmax, as the interface. I am working with a team, and my artists are struggling with proprietary formats and being required to edit material scripts to test things out without programmer assistance (coming from another engine, not ogre). The thought of using max as a level editor, which all the features that come with it, seems like the best solution. But there must be a way to share/inherit materials easily for non-programmers.

I am currently evaluating oFusions usefulness as a world editor in the game I'm working on with a team. We are prepared to purchase a commercial license if need be. I've only tested it for like a week now, so I cannot verify these bugs Rak'kar is speaking of. But if they hold true, I would consider this a major issue and indication that the product is not production ready. So far oFusion is looking like a true next-gen development tool, and I would really like to use it if these bugs can be ironed out.

All of the issues mentioned are being or has been fixed

About the script material support, if instead of adding a new material type, what if we add support for the "Load material from script" (and the reload button) in the "oFusion Material"

In this way you can use scripted materials if you need, and the "oFusion Material" will be auto configured with the script loaded

That would be good. It would save tons of time in setting up the basic properties for materials.

Another feature that would be cool is that on the materials that are loaded from files, you could have an "edit" button that would launch notepad or the maxscript equivalant that would allow you to change whatever you wanted.

Although this could lead to people making improper .material scripts, it would allow the artist much more advanced control over materials if they needed something that isn't possible in the oFusion GUI

It would be really nice if this feature could get in the next version. I just spent 2 hours updating a scene in MAX, which only has 4 normal mapped planets (one with clouds) and a background. My shaders require a z prepass, careful setting of depth read and depth write, and other things. It takes a deep understanding of graphics programming and Ogre to know what to set, far beyond what can be expected of an artist.

For my art pipeline, my only options are spending days setting up the materials myself every time I get a .max file, telling the artists what to do and hoping they set up the dozen parameters correctly every time (they won't), or waiting for the ability to read .material files directly. Only the last of these is a realistic option.

Either way, I'd really appreciate an ETA on this. That way I can plan my art pipeline accordingly, or find other ways to resolve the problem if needed.

Thanks

I was thinking about this and want to add that while the solution you proposed, loading templates from disk, will save time, in the end it would be an order of magnitude better to directly specify a material and not edit materials in MAX at all.

The problem with .material templates is that is the template changes, all the settings the artists changed are lost. If I change one of my basic materials, this will involve redoing every material in the game. This will get old in a hurry, mistakes will be made, etc. And while I can source control the template, it's not as helpful, because if I need to change a material I still have to go through MAX.

I could be totally off, but here's a solution which I THINK will be trivial to implement and do what we want:

1. Right now in oFusion / Object properties we can already specify a mesh filename. Add a line under there "Material name" If that is blank, do what you do now. If it is non-blank, load the specified material. If the material doesn't exist, just render blank white or something and the artists will figure it out.

2. Under oFusion / Scene, add a file path entry line for the ogre.cfg file, needed so the materials can use relative paths. Just load all the resource groups in one go, since you don't know what groups the user will have loaded at any one time.

3. Add a reload button (either in the object properties, or the scene) so changes in the .material files will be reloaded.

This is mission critical enough to me I am willing to donate my own time to help you program it if you want. What do you think?

The solution you proposed, Rakkar, sounds pretty good to me. For the project I am working on I need the ability to give the artists material templates they can edit easily. For example, if I could give them a generic normal mapping material that all they would have to do it edit the texture names in the script, which is easy enough for them to do. That way we can keep our material library ogre specific and not ofusion/max specific. Editing material within the ofusion gui is too complex for non-programmers. This seems like the easiest solution for all parties.

We are currently reviewing the addition of this feature, there are some considerations that need to be done about its implementation (specially about the custom material serializer system that is used)

The implementation will be available asap

Thanks for looking into this.

Yeah, this would be a useful feature to have

So after this long time was it developed or not?, I have downloaded some .material files and this feature will help me a lot, but if anyone can PLEASE tell me how to use them right now I will be very glad and thankful,

Yes, its being implemented, but it will be in the Pro version and then in the CE version (in the next CE update)

Will this be in by the end of March? I've been holding off on developing in-game art assets until but but am shipping soon and can't wait much longer.

As an artist I completely agree...anything that effects the programming side of things I personally don't like to touch as I have no clue with what I am doing there. But anything that can alter the material itself visually is easy enough to learn and to handle...as long as the Ofusion viewport can show the changes in the material in realtime.

Could you please allow for a simpler way to implement alpha mapped texture images. I'm like a monkey with a rubix cube at the moment, trying to figure out where the options are to tweak the map...lol

Yes, this support will be completed in the next days

The Externally defined material support was implemented

This feature is part of the new featureset of the new version 2, but we have ported to your version and provided it in the hotfix #180oECM (you need to apply all of your assigned hotfixes, in numerical order, we have provided this way as you needed this asap, if you prefer we can provide it in a single hotfix)

Details on its usage are in the knowledge base:

Using Externally Defined materials (".material" script files)

Bear in mind that some minor features are not enabled (as the user defined location folder) because of the time constrains needed by your project, but they will be provided in the next days

Thanks! It works, except that the model is black, so my artists still can't use it This is because of light attenuation. In code I fix this by overriding OnLightCreate with:

float range = pLight->getAttenuationRange();
if (range > 500.0f)
pLight->setAttenuation(500.0f, 0.0f, 0.0f, 1.0);
else
pLight->setAttenuation(pLight->getAttenuationRange(), 0.0, 0.0f, 1.0);

Would it be hard to allow us to specify defaults for constant, linear, and quadratic in the scene settings? Set these to all newly created lights automatically in the loader. This is good enough for my game to ship. But as a long term solution I think these settings should also be tweakable per-light.

Also, as an improvement, it would help a lot if the material list was sorted by material name. With 100 some materials it takes a long time to find what I'm looking for.

I need to get a build to my 3D artists by Friday. If this is done before then this would really help.

The light attenuation values will be reviewed immediately

The material list will be sorted by name, and the editbox above the list is used to mask the list entries by name (similar to the max object select dialog), these are part of the "minor ui features" that were not enabled, but they will be tested in the next days

The material list sorting has been implemented and its available in the Hotfix #175oECM in your account page

Feedback:

My artists and I tried using this and I know although I asked for it it really didn't work out at all. My artist was up to 5 AM doing it wrong, and I was up to 4 AM fixing it, and that is just for a small test level.

The advantages are important: The material is source controlled, and if I change a base material it is now reflected in the level, without redoing every material in the game. This is very good.

The disadvantages are so great I told my artists not to use this technique anymore:
1. set_texture_alias doesn't work
2. Inheritance of properties in the pass or technique doesn't work
3. Multi-sub materials are not supported
3. What you see is not what you get. It is ridiculously easy for artists to select the wrong material, or a material that doesn't exist
4. If you type in a string for user defined material, you can no longer select from the drop down list
5. If a material is selected in the drop down list, you can no longer export the material.
6. If you try to multiple select objects and set materials in the drop down list to "None" it crashes.
7. It's too hard for artists to create materials by hand
8. Artists do not follow naming conventions, especially in regards to matching objects in the .material file to the actual texture, and preventing duplicate material names. I went with oFusion to avoid this in the first place, and this technique brings up all the original problems I was hoping to avoid.
9. It's hard to train artists how to use this in general.
10. It's a tremendous hassle and source of problems to copy resources ot the oFusion directory.

My feedback to Lioric:

Thanks for doing this, my solution was OK for programmers, but is too hard for artists. The only thing I can see working is to have the regular oFusion material setup needs to support material inheritance that programmers previously setup. The artists need to be able to select what material to inherit from, if any, and these settings need be used unless they were specifically overridden.

For now I told the artists to not use oFusion at all and to just make the level how they look in Max. I will then go through the final submitted levels by hand and setup the materials myself, using oFusion.

Actually, material inheritance doesn't work at all. I kept thinking this was my fault but I proved it conclusively by having the shader output a solid color, and having a material inherit from that base material that has the shader. It just outputs the regular texture with no shaders at all.

As this was the whole point of using this setup to begin with I'm sort of disappointed.

1. Do you mean the set_texture_alias keyword, as defined in the material script, dont produces the aliases sections in the mesh file?

2. It might be related to the Ogre engine version, we will review this

3. There is no relation between material ID (the material index used by submeshes) and materials defined in .material scripts, as in script matrials, there is no concept of parent materials or submaterials

The other 3. That is why i suggested an "import material from script" button for the oFusion material

4. Just select the "From User Library" radio button and select the material form the dropdown list

6. We will fix it immediately

7, 8 and 9. That is part of the resons why the oFusion material was created

10. The external materials folder can be defined in the latest version

About the material inheritance,

how do you suggest it to be handled, a button in the main material?
do you need to support for the "base materials" from scripts or from other materials?
How do you prefer the update process is handled, what do you need when a base material is updated, the overriden settings has to be updated too?

1. What I mean is:
Create a sphere and a light
Set the user defined material with one that inherits


material Asteroid : GM_NormL3
{
set_texture_alias DiffuseMap asteroidd.dds
set_texture_alias NormalMap asteroidn.dds
}


You won't see anything. It will just be black.

Now remove the inheritance by copy/pasting in your base material.

It now works.

I just did this and verified that it is the case. Inheriting DOES work in my game, using the exact same material, so I know it's not my material settings.

3. What I'm saying is an object with submeshes cannot be viewed as it is in the game using oFusion. I can either select the first material, or none at all.

4. In the scene the artists gave me, they typed in the name rather than selecting it from the listbox. I could then never uncheck or delete the typed in name. Doing so, closing ofusion, and reopening would result in the typed in name showing up again. Trying to select from the drop-down list had no effect and would immediately switch back to none.

10. Can you provide me with a fix for selecting external materials, inherited materials, and shader corruption please? I know you have your own schedule but these bugs are killing me and I just registered another license so hopefully that will pay for your time. And I don't mean this in a bad way, but please double-check your fixes because some of these things are really apparent and when it doesn't work we have to go through the forums and that prolongs the schedule by days at a critical time.

I suggest having a button in the material editor "Load from .material file" Doing so will fill out all the properties, textures, etc. The artist can then change the materials and other settings as they wish. If we do this then I don't need the object properties drop-down anymore.

Thanks for getting back to me on this

We have indetified a bug in Ogre engine in named parameters of shader programs

We will do some more tests and provide a solution for your issue asap