[Bobboau]

today at work I was thinking about the upcomeing shader system and the table were all this is going to be handled I think something like this will be good.
each material will have a name and a vertex useage, the bulk of the material will be a colection of one or more instances, each instance will contain all the information needed to have a functional material, but each instance will be a progresively simpler implementation, the parseing code will read through and build a material and if your graphics card cannot handle some opperation that a material wants then it starts over on the next instance.
each instance will be composed of one or more passes, each pass will be composed of a number of render states includeing zbuffer, alpha blending, and up to eight render steps. optionaly you will be allowed to add vertex and pixel shader code.

the table structure will be something like this
these are examples of the current material types available, they should be useable on all hardware so there is only oe instance of each, I'm in the middle of class so my ability to post examples is limited.

Code: [Select]


$Material: defuse
$Vertex_Useage; XYZ|NORMAL|UV1
$Instance{
$Pass{
$Zbuffer:FULL
$Alpha:NONE
$lighting=true

$Render_step{
arg(1)=texture[0]
arg(2)=defuse
opp=mult
}
}
}Instance

$Material: glowmapeddefuse
$Vertex_Useage; XYZ|NORMAL|UV1
$Instance{
$Pass{
$Zbuffer:FULL
$Alpha:NONE
$lighting=true

$Render_step{
arg(1)=texture[0]
arg(2)=defuse
opp=mult
}
$Render_step{
arg(1)=current
arg(2)=texture[1]
opp=add
}
}
}Instance

$Material: shinemapped_glowmaped_defuse
$Vertex_Useage; XYZ|NORMAL|UV1
$Instance{
$Pass{
$Zbuffer:FULL
$Alpha:NONE
$lighting=true

$Render_step{
arg(1)=texture[0]
arg(2)=defuse
opp=mult
}
$Render_step{
arg(1)=current
arg(2)=texture[1]
opp=add
}
}
$Pass{
$Zbuffer:read
$Alpha:add
$lighting=true

$Render_step{
arg(1)=texture[3]
arg(2)=specular
opp=mult
}
}
}Instance


[WMCoolmon]

We should standardize our table formats...

[DaBrain]

Wow great!!!

How will it be used? By model or by map?

Or even per map section?



I think I saw a water pixel shader somwhere. This might reduce the memory useage of SoL's 'isle-mission' a lot and will look even better.

I can't wait to see this stuff implemented.

[WMCoolmon]

After reading over it (and thinking over it) a few times I'm still confused - does this mean that we'll be able to specify pixel shaders or primitives and generate a texture on-the-fly, or will these be applied to and modify image files?

[Bobboau]

ok, I had to rush last time, sorry. to clarify, or explain at all, how/ware this will be used. currently all POFs have a texture chunck, after this gets implemented, there will also be an optional material chunck, each material in the pof will consist of a material name (a reference to the material table) and a list of up to eight textures (either file names or index into a seperate TXTR chunck still present) to be used by the material. within the material table there will be an identifier, texture[0-7], that can be used within a rendering step, (additionaly, I intend there to be a section within the material table that would allow you to load sevral sort of global textures)

now... each material in the table, will consist of sevral instances, an instance is one posable implementation of the material, many materials will have only one or two instances, the purpose of this is to allow a coder/artist to define fall back behavior. if a user's hardware cannot suport some critical opperation needed by a material the coder/artist will have an alternate method already programed.

each instance will consist of one or more passes. not all effects are posable within one pass, some times you need to work it out over the course of two or three additive passes.

finaly each pass may have up to eight rendering steps (d3d notation texture stages, OGL notation TMU (I beleive)). each of these will allow a coder/artist to determine what textures go were and how colors or textures (ect) are going to be applyed together.
additionaly, a render pass will have properties that are more to do with how the material is drawen, like alpha blending or z buffer opptions.

[StratComm]

So does this mean that the graphics system is getting another complete overhaul in the near future?  If so, this is big.

[Bobboau]

ok, now that I've had a few minutes to work on it, the proper material definition for shine mapping would be this
look how it goes from the most complex to the least demanding way of doing it. first you have a full vertex/pixel shader implementation, then a vertex shader one, then a single pass method, then finaly the multipass solution we have currently.

Code: [Select]


/*
texture:
0 == defuse
1 == glow
2 == shine
*/
$Material: shinemapping
$Vertex_Useage; XYZ|NORMAL|UV1
//specular mapping useing a vertex shader and a pixel shader in a single pass
$Instance{
$Pass{
$Zbuffer:FULL
$Alpha:NONE
$lighting=false //vertex shaders take over

//no render steps becasue the pixel shader takes over

$Vertex_Shader{
/*Cg code goes here*/
}

$Pixel_Shader{
/*more Cg code*/
}

}Pass
}Instance

//specular mapping useing a vertex shader in a single pass
$Instance{
$Pass{
$Zbuffer:FULL
$Alpha:NONE
$lighting=false //vertex shaders take over

//the specular step
$Render_step{
arg(1)=texture[2] //set the shine map
arg(2)=specular //set the specular light
opp=multX4 //multiply the two, useing 4x multiplication, draw it to...
result=temp //the temporary register, this feature is not available on all hardware
//if this is not specifyed it is assumed that it should draw to the screen
}
//the defuse step
$Render_step{
arg(1)=defuse //set defuse light
arg(2)=texture[0] //the defuse texture
opp=mult //multiply them normaly
//the result will be drawen to the screen, rather than the temp this time
}
//the glow map step
$Render_step{
//arg[n] will default to current if one is not specified
//if neither is specified the operation will be set to disable
arg(2)=texture[1] //the glow texture
opp=add //multiply them normaly
//sence arg[1] was not specified, it is current, so current
//(wich has the defuse light*defuse color) will have the glow map added
}
//adding specular and defuse+glow
$Render_step{
arg(2)=temp //the temp register, that has the specular color*light
opp=add //add current to temp...
//drawen to the screen
}

$Vertex_Shader{
/*Cg code goes here*/
}

}Pass
}Instance

//specular mapping with one pass
$Instance{
$Pass{
$Zbuffer:FULL
$Alpha:NONE
$lighting=true

//the specular step
$Render_step{
arg(1)=texture[2] //set the shine map
arg(2)=specular //set the specular light
opp=multX4 //multiply the two, useing 4x multiplication, draw it to...
result=temp //the temporary register, this feature is not available on all hardware
//if this is not specifyed it is assumed that it should draw to the screen
}
//the defuse step
$Render_step{
arg(1)=defuse //set defuse light
arg(2)=texture[0] //the defuse texture
opp=mult //multiply them normaly
//the result will be drawen to the screen, rather than the temp this time
}
//the glow map step
$Render_step{
//arg[n] will default to current if one is not specified
//if neither is specified the operation will be set to disable
arg(2)=texture[1] //the glow texture
opp=add //multiply them normaly
//sence arg[1] was not specified, it is current, so current
//(wich has the defuse light*defuse color) will have the glow map added
}
//adding specular and defuse+glow
$Render_step{
arg(2)=temp //the temp register, that has the specular color*light
opp=add //add current to temp...
//drawen to the screen
}

}Pass
}Instance
//not all hardware will suport this unfortunately
//so we have to improvise with a multi-pass solution if the above one fails
$Instance{
//first pass draws the defuse light*color+glow
$Pass{
$Zbuffer:FULL
$Alpha:NONE
$lighting=true

$Render_step{
arg(1)=texture[0]
arg(2)=defuse
opp=mult
}
$Render_step{
arg(1)=current
arg(2)=texture[1]
opp=add
}
}Pass
//second pass draws specular additively
$Pass{
$Zbuffer:read
$Alpha:add
$lighting=true

$Render_step{
arg(1)=texture[3]
arg(2)=specular
opp=mult
}
}Pass
}Instance


[Taristin]

Feck. I don't want to have to learn how to program pixel shaders just for my ships to have shinemapping...


Is this going to be the only way it'll work?

[Grug]

Would a tag system similar to Halo's be any easier to implement / use?

[Bobboau]

what? you think I'm not going to make the base material table

[Grug]

No, just making a suggestion, throwing an idea into the air.

The centralized table would probably be easier to keep track of things.
I just hope its well documented.
I spend most of my time in the FS2 tables anyway, what could one more hurt?

[Taristin]

Suddenly modding becomes that much more difficult... for me atleast.

[Bobboau]

Originally posted by Raa
Suddenly modding becomes that much more difficult... for me atleast.

how's that?

[Taristin]

Originally posted by Bobboau

how's that?

Every time we want to use a new texture that isn't configured for the shaders, we'll have to make a new entry?

I'm not sure I understand how this new table works...

[StratComm]

No not at all.  Textures and materials are independent of one another.  You assign a material to a texture (or vice-versa) as you apply it to the ship, and for the most part all you'll ever need to do is assign shinemapped textures to the shimemap material that will already be available.  You'd only need to write a shader if you wanted to use some new effect.

[Taristin]

So... there will be a section in the pof file that tells the game what maps to use where, this I understand, but it'll have a defineable shinemap area, too? I mean, you'll have to specify which maps use which shinemaps?

[Bobboau]

"very time we want to use a new texture that isn't configured for the shaders, we'll have to make a new entry?"

no...

the exsisting texture chunk in the pof file will have to have some sort of hack to make it work like everything does now. I'm going to have to make a new POF chunk that has a little more data, to use the new material system you will only have to (useing a new version of PCS) name wich material you want to use and the textures to use with it.

instead of

fighter01-01a

you'd have

shinemap
fighter01-01a
fighter01-01a-glow
fighter01-01a-shine

to have everything work exactly like it does now

...gasp! such dificulty!

[Taristin]

Originally posted by Bobboau

instead of

fighter01-01a

you'd have

shinemap
fighter01-01a
fighter01-01a-glow
fighter01-01a-shine

to have everything work exactly like it does now

 

So every mesh needs to be changed to add 4x the data.

And what's with the 'shinemap'? if fighter01-01a-shine is the shinemap, why does it have to have shinemap written above it?



Sorry if I don't understand what you're trying to say here.
There's a reason I don't code.

[Bobboau]

ok...

you specify the material, and up to 8 textures to use with it.
specular mapping requiers three textures.
with a new POF data chunk I will be able to change the way textures are loaded,
no longer will it look for a file with '-shine' (ect), that has always been an ugly hack, now you will tell it specificly wich file you want to load, you could have fighter01-01a for defuse Imapretylady for shine map and oh_my_god_what_the_hell_is_that for the glow map (well actualy that has too many charicters... but that's besides the point)

all exsisting POFs have a chunk called TXTR, if this is found and the new ...MTRL sounds good, if the new MTRL chunk isn't it will have a hack to select specmapping if the files for it are avaiable.

keep in mind that there will be more materials than variants of specmapping, such as bump mapping.

[Taristin]

Ok. That makes more sense, then. So long as the model editting program isn't hostile towards the user, and makes it clear what is being defiend, I should be able to grasp this.