[The E]

Okay. As we all know, materials are something that we kinda want in FSO.

So I've been thinking about this a bit, and here's what I came up with.

I think that any system like this should plug into the existing texturing pipeline as easily as possible. Based on this, what I propose would be to create a new quasi-tbl that can be plugged in as a supported texture type into the texture loading mechanism, similar to the way effs are integrated.

This text file would look like this:

Code: [Select]

$Diffuse Map: <filename>
$Glow Map: <filename>
$Spec Map: <filename>
$Normal Map: <filename>

$Vertex Shader: <filename>
$Fragment Shader: <filename>

$Uniform: <String> ;; The name of the uniform variable that is passed to the shaders
+Type: <One of: Int, float, texture>
$Value: <As appropriate>

$Preprocessor define: <String> ;; Name of a preprocessor define

$Flags: (
"Lighting" ;; Shader handles lighting. Number of lights will be passed to the shader as a uniform.
"Environment" ;; Shader handles env mapping
"Fog" ;; Shader handles fog calculations.
"Timer" ;; Shader gets current missiontime and frametime as floats.
)
Now, in terms of shader compilation etc, this should be handled during mission load, the first time such a material is encountered. In case of failure to compile the shaders, the engine would fall back to the "standard" texture loading process, trying the various supported formats until it can find something it can load.

Comments?

[Kolgena]

I did a quick google search, but I'm still not too clear on what exactly a material is. Is it some sort of procedurally generated texture?


_{Don't flame me}

[Galemp]

I would strongly discourage the use of parameters like 'Diffuse Map' or 'Glow Map' as fields. I propose something like this instead:

Code: [Select]

$Map: filename ; Without file extension
+Diffuse: 255 ; 0 to 255, 0 is transparent and 255 is opaque
+Blending: 0 ; Type 0 is no alpha, 1 uses 1-bit green alpha, 2 uses 32 bit alpha channel, 3 uses additive blending
+Lighting: 0 ; 0 to 255, affects self-illumination value
+Specular: 0 ; 0 to 255, affects specularity
+Env: 0 ; 0 to 255, affects environment mapping
$Normal:     NO ; Whether map is a normal map
$Translation: NO ; Whether this texture moves at all

Basically something close to the materials systems of rendering engines with plenty of room for expansion. This way groovy effects like animated texture translation or pulsing glowmaps could be generated with a single texture instead of with inefficient and inflexible EFFs, and maps can be layered for additional effects, such as a huge Ambient Occlusion texture and a tiled hull plating texture on the same material.

[The E]

Well, the way it is designed right now would allow just that. The "$Diffuse Map" option, for example is just a shortcut to the following combination of information that is passed to the shader:

Code: [Select]

$Uniform:      sBasemap
    $Type:      Texture
    $Value:    <filename>

$Preprocessor define: FLAG_DIFFUSE_MAP

This system is designed for ease-of-use, and to make it easier to fit existing assets into the material pipeline.

Make no mistake, the heavy lifting has to be done in the shader here; and with the various options for data to pass into the shader, we can do anything we want.

[Iss Mneur]

I did a quick google search, but I'm still not too clear on what exactly a material is. Is it some sort of procedurally generated texture?

No, not really.  A material, as I understand it, is a file that specifies all of the properties (texture, shaders) of a surface or object.  The name itself comes from Valve and their Half-life engine, where a material also specifies the sound of something hitting the surface, and IIRC, the friction of the surface.

Though, I suppose a materials system could be used to specify procedurally generated textures as well if you really wanted it to.

[Nuke]

i kinda like it. would it be possible to add additional maps which may be needed by a particular shader?

[The E]

i kinda like it. would it be possible to add additional maps which may be needed by a particular shader?

Yes, via the "$Uniform:" option.

[Fury]

Could you explain how would your average modder use this proposed material system?

If I have understood right, this material system would make separate -shine, -normal and -glow maps obsolete? So how exactly you do those maps with only shaders? I'm guessing shaders would be capable of doing same work as image editing software would? Only in real-time. But since you don't usually get wanted results with one method when doing normal maps in particular, wouldn't you need a lot of different shaders to get the results you want?

And since the material system is supposed to do away with inefficient use of animated textures and effects, how exactly do you do animated effects and maps with material system? How would you do, say current mediavps exp06 in material system?

[The E]

If I have understood right, this material system would make separate -shine, -normal and -glow maps obsolete? So how exactly you do those maps with only shaders? I'm guessing shaders would be capable of doing same work as image editing software would? Only in real-time. But since you don't usually get wanted results with one method when doing normal maps in particular, wouldn't you need a lot of different shaders to get the results you want?

Nope, that's not how it works. You will still need separate diffuse/glow/shine/normal/whatever maps. And recreating something like a full explosion effect using shaders alone will not look as good as an eff could (explosions are very intensive computationally, generating them on the fly will never look quite right). Now, the main purpose of this is to allow a modder to specify exactly what shader is used on a texture; As opposed to the current implementation where we have one shader set that is used for everything.

And since the material system is supposed to do away with inefficient use of animated textures and effects, how exactly do you do animated effects and maps with material system? How would you do, say current mediavps exp06 in material system?

As said above, you can't recreate an explosion effect like that. However, what you CAN do, for example, is doing something like the pulsating effect seen on Shivan glowmaps, using only one or two textures that are blended in the shader.
What this system will also allow (eventually, anyway) is to allow the sexp and scripting systems to pass information to the shaders. This can be used (for example) to implement optical stealthing.

[Fury]

So eh, then what is it that is supposed to do away with inefficient use of animation frames? How do other games do such effects?

[DaBrain]

Sounds like a good plan. I'm wondering abour a few things though.

How will this work with meshes that use multiple textures/multi-materials? Wouldn't we need some kind of "material" we can save in our models?

It it depends completly on the texturename, we loose some room for content optimizations.
I.e. the subspace jump in/out effects could use the same frames (maybe reverse), but different materials to recolor them.



And about the $Uniform, I was wondering what exactly will be allowed? Will be able to have a dynamic value that we can animate somehow?



Later I'd like to be able to assign materials to my meshes directly in my 3d application, by adding the name to the custom mesh properties. In most 3d apps this would make editing multiple meshes at once a very simple task.

The materials should have names and be stored in a table and could be used as material "templates".
I.e. there would a 'Vasudan_Fighter" material which you'd add to the mesh properties in Blender, Max, Maya, etc, or directly in PCS2.
If you just add the material name the default values of the material will be loaded from the table (ps, vs, textures, uniforms), but you can also add values in the mesh properties to overwrite the default values.


For the fighter mesh:

Code: [Select]

MatId = 1
UseMat = 'Vasudan_Fighter'
And if you want to change something:

Code: [Select]

MatId = 1
UseMat = 'Vasudan_Fighter'
DiffText = 'vas_fighter_02_diffuse'
SpecText = 'vas_fighter_02_spec'
DetailNormText = 'gen_vas_detail_normal'
SpecGloss = 35





@Galemp
Looks fine first, but that wouldn't be flexible enough. Not all shaders will need a diffuse texture. If we ever want to have (heat) distortion effects, the objects with this shader will not even be visible. They'll just provide informations for the post processing.

[Nuke]

so take it shaders themselves would be kept in another file, and you would select the one most appropriate for the material. i also take it there would be a default material that would be used for reverse compatibility which would be about equivalent to the kind of rendering we have now.

i would also want some kind of script output to the variables in the material system. like make the shivan ships glow brighter when they have full shields. stuff like that.

[The E]

So eh, then what is it that is supposed to do away with inefficient use of animation frames? How do other games do such effects?

First, you need to define what "inefficient" is in this context.
For an explosion effect, 100 frames aren't that inefficient; and unless you have a super efficient way that can generate explosions procedurally, those things are going to stay.

Now, something like an animated glowmap on a ship, that's inefficient.
Imagine you want to pull off an effect like the one seen on TBPs Shadow ships. This means an animated diffuse map, and if you're interested in real awesomeness, an animated normal map on top. Depending on map size and effect quality, this can get pretty ugly pretty fast.

However, using a custom shader, with the current mission- and frametime passed as an argument, the same effect can be pulled off using only 2 maps.

A material system is not a magic bullet to kill effs, nor is it intended to be. There are scenarios where an eff is the best choice. There are others in which a well-designed material is the best one.

Sounds like a good plan. I'm wondering abour a few things though.

How will this work with meshes that use multiple textures/multi-materials? Wouldn't we need some kind of "material" we can save in our models?

This is designed to plug into the existing texturing system. There is nothing stopping you from using multiple materials on a model, just as there is nothing stopping you from using multiple textures right now.

It it depends completly on the texturename, we loose some room for content optimizations.
I.e. the subspace jump in/out effects could use the same frames (maybe reverse), but different materials to recolor them.

Why? You can just pass different arguments to the shader via uniforms.

And about the $Uniform, I was wondering what exactly will be allowed? Will be able to have a dynamic value that we can animate somehow?

Stated in the first post. In terms of uniforms, we are limited by what GLSL data types are available.

Later I'd like to be able to assign materials to my meshes directly in my 3d application, by adding the name to the custom mesh properties. In most 3d apps this would make editing multiple meshes at once a very simple task.

As I am not a modeller, I cannot help you there. As I said, this system is designed to plug into the existing pipeline (Especially PCS2) as seamlessly as possible.

The materials should have names and be stored in a table and could be used as material "templates".
I.e. there would a 'Vasudan_Fighter" material which you'd add to the mesh properties in Blender, Max, Maya, etc, or directly in PCS2.
If you just add the material name the default values of the material will be loaded from the table (ps, vs, textures, uniforms), but you can also add values in the mesh properties to overwrite the default values.

A tbl might be a good idea. Will have to think about this some more.

so take it shaders themselves would be kept in another file, and you would select the one most appropriate for the material. i also take it there would be a default material that would be used for reverse compatibility which would be about equivalent to the kind of rendering we have now.

i would also want some kind of script output to the variables in the material system. like make the shivan ships glow brighter when they have full shields. stuff like that.

Doing something like this, and leaving out scripting/sexp integration, would be stupid.

[DaBrain]

Ok., I think I didn't get something right then.


I have texture/EFF called "warp_animation" now I want to recolor it using by using two materials with two different uniforms for the color.
How do I do that?

As I am not a modeller, I cannot help you there. As I said, this system is designed to plug into the existing pipeline (Especially PCS2) as seamlessly as possible.

Well, you wouldn't have to care about that part. The values will be stored in the POFs like i.e. the detail box values. How they get there is entirely a problem of the artist and doesn't require any modification in the POF format.






And on a sidenote about the explosions. Many modern games if not most of them use particles for their explosions now. some in combination with short frame animations others with just one texture per particle system.

I'm not saying that's possible in FSO though. I'd even say with the current options for particles, it's probably impossible to create a decent effect with just particles. (as in, more than one particle with a frame animation)




Edit: Will we be able to use materials and shaders for effects and particles? That would be incredibly awesome!

[The E]

I have texture/EFF called "warp_animation" now I want to recolor it using by using two materials with two different uniforms for the color.
How do I do that?

By passing a colour value as a uniform parameter? I should have said this before, the system would allow an arbitrary number of uniform variables to be created and passed as an argument to the shaders.

Well, you wouldn't have to care about that part. The values will be stored in the POFs like i.e. the detail box values. How they get there is entirely a problem of the artist and doesn't require any modification in the POF format.

Ah, I see. Hadn't thought of that, but it's a good idea. One that I do not really like, since I like to keep data in as few places as possible. What I would want to do instead is to have new fields in ships.tbl and weapons.tbl to pass material information.

[DaBrain]

By passing a colour value as a uniform parameter? I should have said this before, the system would allow an arbitrary number of uniform variables to be created and passed as an argument to the shaders.

Well.. the two effect are supposed to use the same textures and I thought the system would tap in here and pick the material depending on the texture name. I think that's the part I got wrong. I'm just not sure how it's supposed to work then.

Ah, I see. Hadn't thought of that, but it's a good idea. One that I do not really like, since I like to keep data in as few places as possible. What I would want to do instead is to have new fields in ships.tbl and weapons.tbl to pass material information.

I'm not a fan of redundant data myself, but I'd still suggest it for usability reasons.
There are tons of options and tools to rename/alter multiple meshes at once in modern 3d software packages.
On top of that you can use Python  (Blender), MAXScript (3DS), MEL (Maya) and other scripting languages to create your own little tools for the material/mesh setup.




Btw this is how it works in the UDK:
You set up a "shader" (not quite correct, but lets say it's a shader) in the editor and decide which values will later be exposed to the material. Then you create a material which uses this shader. Now you can assign the material to meshes, or better to material  IDs of a mesh. This will create a copy of your material instance. You can go with the default values you set, or change them.

[The E]

Okay, here's what I had in mind. Hopefully it'll clear something up.

We start off with a model. Sad model refers to a texture, let's call it "awesome".

In our maps folder, we have a file called awesome.mat, which is a text file as outlined in the first post. This defines our base material for that texture.

In ships.tbl, we add a "$Material:" section, where we can redefine the used material for that ship class only, using the same syntax as found in the .mat file. Does that make sense?

[DaBrain]

Ah alright, I get it now.

So you refer to a texture on a specific model. That will indeed cause way less problems.
The only limitation I see is that if I want to use the same texture on the model twice or more often, I can set different shaders paramters...

Hmm, but wait. I can assign a texture called "1" and a texture called "2" and simply use the textures like material ids and overwrite the diffuse, spec, whatever textures via the material.


That would work perfectly.


Edit: I could even use the actual textures in Max and write a script that will replace the texture names by the actual material IDs and use it before I export a DAE.
On the other hand the texture fallback wouldn't work this way, but I guess an option to set a fallback texture in the material would fix that.


Edit2: How would we handle things that don't have a mesh. Like beam effects or the lens flares and of course all particles?

[The E]

Well, weapon effects are rather easy. After all, they do have a mesh, even if it is autogenerated.

However, That will take some more time, as I have to figure out how the batch renderer (which is responsible for these things) interacts with stuff. Let's try to get this running on normal models first, then move on to that.

[DaBrain]

Sure, I didn't want to make it even more complicated.

I just see a lot of room for effect optimizations with materials/special shaders. I hope to get rid of many frame animations. The memory can be used better elsewhere.

There is more than enough content to optimize without the POF-less meshes though. Animated glow maps and the shockwave effects are my first target.




One last question. Can we add position/scale animations via the vertex shaders as well?