Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Bobboau on March 24, 2005, 07:27:24 pm
-
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.
$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
-
We should standardize our table formats...
-
Wow great!!! :eek2:
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.
:yes: :yes: :yes:
-
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?
-
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.
-
So does this mean that the graphics system is getting another complete overhaul in the near future? If so, this is big.
-
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.
/*
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
-
Feck. I don't want to have to learn how to program pixel shaders just for my ships to have shinemapping... :blah:
Is this going to be the only way it'll work?
-
Would a tag system similar to Halo's be any easier to implement / use?
-
what? you think I'm not going to make the base material table
-
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. :D
I spend most of my time in the FS2 tables anyway, what could one more hurt? :p
-
Suddenly modding becomes that much more difficult... for me atleast.
-
Originally posted by Raa
Suddenly modding becomes that much more difficult... for me atleast.
how's that?
-
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...
-
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.
-
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?
-
"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!
-
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. :doubt:
There's a reason I don't code.
-
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.
-
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.
-
I code and I still don't get how it's supposed to work.
MHO is that it should be set up so that the last - in a name is checked for a material name, then that material is applied to the texture. This way the ease of -glow -shine could be preserved.
Wait. Unless what you do is specify the material in POFCS, then list the textures you'd like to use with that material So for a "shinemap" material you'd specify your normal, glowmap, and shinemap. For a " colored envmap" material, you specify the same, plus an envmap.
In that case...ugh. Modding just got much more complex. What if you want to use a shinemap but not a glowmap? You have to create a new material (or code in to handle missing textures without losing the entire material).
It's adding great flexibility but at the cost of great unwieldy in texturing. If using -glow -shine is really possible, I don't have any objections - but I do have an idea how it could be made more user-friendly.
In the table, you specify a name for each texture associated with a material. "shine" or "glow" or whatever. Then in POFCS, you specify which material to use, for a base texture. The material data is stored in a special chunk.
Then to use multiple textures you just add the proper texture-name-suffix (which was specified in the tbl) to the end of the base texture name specified in POFCS. The default material would supply "-glow" and "-shine" tags, and "-bump" later on.
-
shinemap is the name of the material
fighter01-01a is the first texture wich in shinemappinf as I have it defined is the defuse map
fighter01-01a-glow is the second texture wich acts as the glow map in the material
fighter01-01a-shine is the third texture, in the material definition the third texture is the shine map
-
Yes, but you still end up specifying those in POFCS, just another step to forget once you've made a new texture and saved it. You also shouldn't be using different name patterns for textures anyway, it just makes things more messy.
Plus, there's no need for nasty hacks; if the MTRL chunk doesn't exist, then the default material is used; it doesn't have to spit out the old names, the material would define them along with any new ones that are added.
-
ok I am going to
A) make a material table that has all of the available material capablities
B) make a hack that handles the current pof data like it is currently handled
modding will get more complex only after I have gotten PCS and 3ds2pof updated with the new, it will only get more complex to the order of haveing to manualy specify wich material you want to use (ie you'll have to write specmap or somehithing to that effect) and the specific textures to use with it.
-
right now we have a rube goldberg machine loading textures and drawing ships.
-
Hell, if it was as easy as having the max exporter keep all of the material settings from the Max material editor, it'd be easy as all hell.
-
yeah, that'd be about what you'd have, at worst you'd have to type wich material you wanted.
-
so then, everybody's all clear and convenced on how good an idea this is?
-
I still like my idea better. :p
But if it brings bump mapping, I suppose I can't complain. And the table seems flexible enough to add more material types, although what that exactly would bring (beyond bumpmapping) I'm not quite clear on yet.
-
anything, this gives almost infinite flexability to the artist.
-
Actually there are other advantages to specifing additional maps explicitly; right now a lot of shinemapping uses the same shinemap for multiple files; if we could specify the same shinemap across multiple materials, it would help reduce the redundancy of maps and thus cut down on download sizes.
-
exactly.
-
I don't think our aritsts have grasped the potential in this sysytem yet.
What Bobbau makes will a tons of things possible and open a myriad of tricks.
Examples:
-Homeworld-esque ships where you can set colors for specific parts of the texture (this may call for some further tweaks, but the material system would make it a lot more straightforward)
-Separate textures for parts of the ship (lining, edges, machinery) that's paintjob independent, enabling ships have a custom paintjob of their own
-Creating faction/squad/personal painjobs would be a breeze
-The decal system could be revived
-Custom damage textures
I hope Bobb had an object oriented approach in mind (his definition of multilevel rendering (complex-->simple) is pretty close) that would allow a flexible texture development.
(For example glass, metal, matt or scrathed surfaces could be a couple of base templates that any texturer may find handy to originate his materials from)
As I see it - BTW please clarify any orbital idiotism on my part Bobb :p - the material system would make it possible to have layers for texturing just like PSP or Photoshop has and any 2D artist knows with that the possibilities are endless.
-
http://pcgamemods.com/11163/
we can use this, or the one that comes with Far Cry now!
w00t, normal maps
DaB was talking about animated Shinemaps sometime before, will this make that possible?
-
Animated shinemaps are already possible AFIAK.
It's just like about one mod that needs it. So I guess it's not really a top priority.
Still I hope we can use shader 'animations' instead of animated textures whenever it's possible.
Might save some memory. (Like the water shader.)
-
Originally posted by StratComm
Actually there are other advantages to specifing additional maps explicitly; right now a lot of shinemapping uses the same shinemap for multiple files; if we could specify the same shinemap across multiple materials, it would help reduce the redundancy of maps and thus cut down on download sizes.
Ahh, I didn't think of that. :nervous: Kudos. :yes: