Author Topic: yet another materials system topic  (Read 4194 times)

0 Members and 1 Guest are viewing this topic.

Offline Bobboau

  • Just a MODern kinda guy
    Just MODerately cool
    And MODest too
  • 213
yet another materials system topic
I have been thinking of FS again for the first time in a long time, and I have given thought to my once great nemesis, the materials system. I think I may have come up with a way to implement it that will require no (significant) POF format changes, and could yet allow for the level of flexibility that we need. what I have come up with is on a fundamental level very similar to a suggestion made by The E about a year ago. I had some significant opposition to some of his choices, namely the use of hard coded texture types, lack of fallback mechanisms, and lack of multi-pass material support to name a few, but the basic architecture he suggests has merit. I think I have thought up a way to define the components I think are fundamentally important yet maintain much of the ease of implementation that The E's submission had. the critical impasse between a singular materials table and requiring a material chunk in the POF and the texture replacing one The E described comes down to how do you pass material parameters to the material. the answer is in the fact that texture names are saved as simply a string, a string can have any value, and as such we could have specaly formatted texture names, that rather than loading a set of textures and getting assigned a default material, it could list a material (<-The E's idea) and all of it's parameters (<- my idea).

how this would work in practice, would be in the POF where currently you would have something like
fighter01a
instead you could have something like
metal(fighter01a, fighter01a-glowystuff, 4.0, ship.engine_output)
which would load the metal material, passing the parameters to the material which would load textures and set uniforms based on those parameters

a sample of what a material would look like is as such:
Code: [Select]
#parameters
$string: diffuse_texture
$string: glow_texture
$number: rate
$variable: attached_to
#end_parameters
;; this defines what inputs this material is expecting,
;; in this case 4 variables named diffuse_texture, glow_texture, rate, and attached_too
;; the first two variables are texture names, the third is a constant,
;; and the final one is the name of a game variable

#textures
$texture:
+name: diffuse
+file: {diffuse_texture}
$texture:
+name: shine
+file: {diffuse_texture}_shine
$texture:
+name: detail
+file: noise
$texture:
+name: glow
+file: {diffuse_texture}_shine
#end_textures
;; this section here defines what textures are used and what handle they are to be referred to by further in the material and within the shaders
;; note that even though only 2 parameters pertain to texture file names
;; this material actually uses 4 one of which is not based on a parameter at all
;; parameters are purpose agnostic and treated as constants throughout the material specification
;; theoretically this could be a place to define dynamic textures (RTT), predefined game textures, or perhaps another material could be referenced

#uniforms
$uniform:
+name: pulse_rate
+value: rate
$uniform:
+name: subsystem
+value: attached_to
#end_uniforms
;; this defines the material specific uniforms name is what they would be referred to in the vertex shader
;; value is what they would be set to
;; this is the part I am least happy with,
;; I think scripting could be brought to great effect here

#render_set
;; this starts a render set, a renderset is simply a set of rendering passes that make up the material
;; there is more than one of them so if the first one fails it has fallback effects that are
;; less resource intensive or at least can run on lower level hardware

$detail: 3 5
;; this marks this material as only being supported when the game's texture detail is 3, 4 or 5 (out of 5)
;; this is optional will default to all levels

$lod: 0 2
;; marks this material as only being applicable when on LOD 0, 1, and 2
;; this is optional will default to all levels

$pass:
;; here we finally have a pass definition
+textures: ( "diffuse" "shine" "detail" )
;;the textures used in this pass
+vertex_shader: really_cool_vertex_shader
+fragment_shader: really_cool_fragment_shader
;; these should be obvious
+alpha_mode: none
;; here we set alpha mode to none, there are a plethora of other possible settings that could be added here but I won't go into them right now
$pass:
;; second pass,
+textures: ( "glow" )
+vertex_shader: another_really_cool_vertex_shader
+fragment_shader: another_really_cool_fragment_shader
+alpha_mode: (add_lighting&fog:subtract) (add_lighting:add) (fog:interp) none
;; this pass will do different things depending on the situation
;; if this is an additional lighting pass and fog is enabled it will use subtractive alpha
;; if it is just an additive lighting pass, it will use additive alpha
;; if it is just fogging, then this pass will draw with the interpalation alpha
;; finaly if none of the other cases catch it will not use any sort of allpha effect
#end_render_set
;;that is the end of the first render set

;; now it's on to the second
#render_set
$pass:
+vertex_shader: less_cool_vertex_shader
+fragment_shader: less_cool_fragment_shader
+alpha_mode: none
$lighting:
+alpha_mode: add
#end_render_set
;; this set would be used if the above render set could not be used for some reason,
;; be it insuffichent hardware support, or detail settings mis matched, or any other such criteria

#render_set
$import: fallback_diffuse({$diffuse_texture})
#end_render_set
;; final render set imports another material
;; an import can happen in any renderset
;; it just so happens that it would be particularly useful for handeling fallbacks

;; if all else fails the default material will be attempted useing the defined textures
;; for diffuse, glow, shine, normal in the order that they are defined in the texture section
;; actualy it might be better if it just errors out so the problem actualy gets fixed

the two parts that still need work are how to handle render conditions (like what lighting pass you are on or if fog is enabled or something else that is slipping my mind) and how to handle the passing of game variables to the shader. Right now the first problem is handled awkwardly and the second really I don't think would work well.
« Last Edit: August 23, 2011, 08:55:13 pm by Bobboau »
Bobboau, bringing you products that work... in theory
learn to use PCS
creator of the ProXimus Procedural Texture and Effect Generator
My latest build of PCS2, get it while it's hot!
PCS 2.0.3


DEUTERONOMY 22:11
Thou shalt not wear a garment of diverse sorts, [as] of woollen and linen together

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: yet another materials system topic
i think if you're gonna stick all the info into a string things could get messy, you might also run into string length limits (as far as i know there are none in the pof format itself, as there is a length field, but in the engine you might have a 32 char limit, because that was the anticipated file name length). i do like using the name string as an identifier to tell the engine where to get material information. but i wouldn't want to do is pass static variables right in the name string to another set of information which could just as easily contain the variables (this actually reminds me of hacks i did in the early days of scripting), i think it would be better organized and less confusing for modders to just but the variable defs in the material file. if there is no material file that matches the texture name string then a "default material" is used that maintains the current naming conventions (the texture name is passed as a variable and affixes would be applied to generate the maps list).

i would also make material files linkable so that you could call other materials within a mat file as a basis for new materials, essentially use one as a template for another. you would stack object specific modifications on top of the base material, very similar to the way modular tables work.

i would also use scripting to data mine vars to be passed to the materials system, such as if you want the glow maps to pulse based on engine output or whatever. this need not be done every frame, for performance reasons, script could be run at a set interval, and output values from the script can be interpolated in c frame to frame to maintain fluidity.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline Dragon

  • Citation needed
  • 212
  • The sky is the limit.
Re: yet another materials system topic
Sounds reasonable, your example seems quite intuitive and flexible.
The_E had been (IIRC) working on material system for some times, so you may want to contact him.
It'd be really great to see that working.

 

Offline Zacam

  • Magnificent Bastard
  • Administrator
  • 211
  • I go Sledge-O-Matic on Spammers
    • Minecraft
    • Steam
    • Twitter
    • ModDB Feature
Re: yet another materials system topic

Dragon, I'm sorry but, did you even read anything that was posted? Did you fail to notice the link in Bobboau's message that linked directly to the thread by The E?

I'm pretty sure they both know how to get in contact with each other.

I'd have more to say about the rest of the on topic discussion, but it's been hashed through so many times before that all I can say right now is that you seem to have made some inaccurate assumptions Bobboau, but that aside, a fine system you are suggesting other than the embedding stuff in POFs to work with. Any idea should be externally capable of applying materials to an unaltered model, otherwise you force a lot of update/makework for models already released.
Report MediaVP issues, now on the MediaVP Mantis! Read all about it Here!
Talk with the community on Discord
"If you can keep a level head in all this confusion, you just don't understand the situation"

¤[D+¬>

[08/01 16:53:11] <sigtau> EveningTea: I have decided that I am a 32-bit registerkin.  Pronouns are eax, ebx, ecx, edx.
[08/01 16:53:31] <EveningTea> dhauidahh
[08/01 16:53:32] <EveningTea> sak
[08/01 16:53:40] * EveningTea froths at the mouth
[08/01 16:53:40] <sigtau> i broke him, boys

 

Offline Dragon

  • Citation needed
  • 212
  • The sky is the limit.
Re: yet another materials system topic
Oops, I indeed missed the link.  :)
Anyway, I'm looking forward to this. It'd be a great feature for atmospheric mods, where you don't only deal with metal targets.

 

Offline Bobboau

  • Just a MODern kinda guy
    Just MODerately cool
    And MODest too
  • 213
Re: yet another materials system topic
the engine you might have a 32 char limit
if only we had the means by which to change that :p

i wouldn't want to do is pass static variables right in the name string to another set of information which could just as easily contain the variables, i think it would be better organized and less confusing for modders to just but the variable defs in the material file.
well, then they aren't material files anymore, they are material instances. think of it this way, lets say you have a solid color material, it draws geometry with just a single color, under your system a model with a solid red and a solid yellow are completely different materials, if something needs to change in the material, you have to hunt down each and every instance of that set of related materials, if you decide to change a color on a ship you have to make a completely new material, with what I have proposed you would simply call the same material with different parameters. what is easier, making a couple dozen materials and all the overhead of maintaining that, or making a handful of materials and referencing each as solid_color(#ff0000), solid_color(#ffff00), etc? keep in mind this is only dealing with a single material parameter, in practice materials are probably going to end up getting half a dozen parameters, and every combination will need a separate 'material'.


if there is no material file that matches the texture name string then a "default material" is used that maintains the current naming conventions (the texture name is passed as a variable and affixes would be applied to generate the maps list).

using the method I describe would produce texture names that have invalid file name characters, at least they would be invalid on the windows platform, this fallback behavior is impossible, and IMHO undesirable.

i would also make material files linkable so that you could call other materials within a mat file as a basis for new materials, essentially use one as a template for another. you would stack object specific modifications on top of the base material, very similar to the way modular tables work.

I like this.

i would also use scripting to data mine vars to be passed to the materials system, such as if you want the glow maps to pulse based on engine output or whatever. this need not be done every frame, for performance reasons, script could be run at a set interval, and output values from the script can be interpolated in c frame to frame to maintain fluidity.
in order to interpolate you would need to know the starting value and the ending value, especially for non-deterministic things like engine output this is not possible, you would need to know what the user was going to do at some point in the future.

The_E
I only mentioned him like half a dozen times :|
Bobboau, bringing you products that work... in theory
learn to use PCS
creator of the ProXimus Procedural Texture and Effect Generator
My latest build of PCS2, get it while it's hot!
PCS 2.0.3


DEUTERONOMY 22:11
Thou shalt not wear a garment of diverse sorts, [as] of woollen and linen together

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: yet another materials system topic
the engine you might have a 32 char limit
if only we had the means by which to change that :p

of course im sure you can up the length of the name string in the engine by changing a couple of #defines, but then any mod tools that expect a 32 char name might have issue with it, and those would need to be updated too. granted this problem is somewhat trivial.

Quote
i wouldn't want to do is pass static variables right in the name string to another set of information which could just as easily contain the variables, i think it would be better organized and less confusing for modders to just but the variable defs in the material file.
well, then they aren't material files anymore, they are material instances. think of it this way, lets say you have a solid color material, it draws geometry with just a single color, under your system a model with a solid red and a solid yellow are completely different materials, if something needs to change in the material, you have to hunt down each and every instance of that set of related materials, if you decide to change a color on a ship you have to make a completely new material, with what I have proposed you would simply call the same material with different parameters. what is easier, making a couple dozen materials and all the overhead of maintaining that, or making a handful of materials and referencing each as solid_color(#ff0000), solid_color(#ffff00), etc? keep in mind this is only dealing with a single material parameter, in practice materials are probably going to end up getting half a dozen parameters, and every combination will need a separate 'material'.

i really just dont like the single string function call format used in place of a texture name. there are ease of use issues. this makes the material settings difficult to tweak (youd have to use a pof editor as opposed to notepad). its also confusing for modders who might not know what a number in the string means. i would at the very least use named variables so the modder knows what the numbers mean to the material. i think it would be better to use the name to reference a file containing the parameters for the material (variables, textures, data mining scripts, ect), if not the material itself.

Quote
if there is no material file that matches the texture name string then a "default material" is used that maintains the current naming conventions (the texture name is passed as a variable and affixes would be applied to generate the maps list).

using the method I describe would produce texture names that have invalid file name characters, at least they would be invalid on the windows platform, this fallback behavior is impossible, and IMHO undesirable.

seems like a simple concatenation of strings to me. no material referenced, so use the default. the default would take the name string from the pof texture chunck and concat -glow, -shine, -normal, etc, to it and look for those textures, and if found use them. default material would just be hardcoded (though overwritable if desired) as the first instance, just to maintain compatibility with existing texture naming conventions, so it dont break old mods.

Quote
i would also use scripting to data mine vars to be passed to the materials system, such as if you want the glow maps to pulse based on engine output or whatever. this need not be done every frame, for performance reasons, script could be run at a set interval, and output values from the script can be interpolated in c frame to frame to maintain fluidity.
in order to interpolate you would need to know the starting value and the ending value, especially for non-deterministic things like engine output this is not possible, you would need to know what the user was going to do at some point in the future.
you could still make predictions based on the last 2 samples (or number of samples), if the data mining script runs every 10 frames, youd at most be off by a fraction of a second and that wouldnt look too bad, but i still kinda think id rather have the var change between frames than just sit idle for several frames. perhaps make it possible to choose between various sample based prediction algorithms, hard delta, soft delta, smoothed, noise, static, whatever. i just dont see it optimal to run data mining scripts all the time or perhaps at all (maybe use sexp-like expressions or flags indicating vars to mine to conditionals in c). just an idea.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline Bobboau

  • Just a MODern kinda guy
    Just MODerately cool
    And MODest too
  • 213
Re: yet another materials system topic
i really just dont like the single string function call format used in place of a texture name. there are ease of use issues. this makes the material settings difficult to tweak (youd have to use a pof editor as opposed to notepad). its also confusing for modders who might not know what a number in the string means. i would at the very least use named variables so the modder knows what the numbers mean to the material. i think it would be better to use the name to reference a file containing the parameters for the material (variables, textures, data mining scripts, ect), if not the material itself.

you would have to use a pof editor at some point anyway, having it in the pof also makes it easier for future pof editors to be able to edit and manipulate it.

the problem with this is that what you describe would be like if the textures were listed in the ship table or something, the it seems like adding indirection for indirection's sake to have the pof link to a file that links to a material, when the contents of that intermediary file could just as easily be set in the pof. I mean you are going to need a dozen of these mapping files for every model, dozens of itty bitty text files that if you forget to pack them they the model wont work, seems error prone, you have to open each one up independently, unless you are careful to maintain a strict naming convention you will have no idea which mapping file goes to which model, this just seems like a management nightmare.

I am not opposed to syntax like:
solidcolor(color:#ff0000, shine:#ffff00)
that actually has a number of advantages, such as you could assign default material values

seems like a simple concatenation of strings to me. no material referenced, so use the default. the default would take the name string from the pof texture chunck and concat -glow, -shine, -normal, etc, to it and look for those textures, and if found use them. default material would just be hardcoded (though overwritable if desired) as the first instance, just to maintain compatibility with existing texture naming conventions, so it dont break old mods.

maybe we are misunderstanding each other, a material name would have parenthesis in it, solidcolor(), I could be wrong but I am fairly sure that solidcolor().dds is not a valid file name on the windows platform, and I think using the presence of (*) in the file name as the flag that this is referencing a material not a texture would be the way to go. obviously if you don't have parenthesis in the file name it will load like it does now.

you could still make predictions based on the last 2 samples (or number of samples), if the data mining script runs every 10 frames, youd at most be off by a fraction of a second and that wouldnt look too bad, but i still kinda think id rather have the var change between frames than just sit idle for several frames. perhaps make it possible to choose between various sample based prediction algorithms, hard delta, soft delta, smoothed, noise, static, whatever. i just dont see it optimal to run data mining scripts all the time or perhaps at all (maybe use sexp-like expressions or flags indicating vars to mine to conditionals in c). just an idea.

that's not interpolating, that's extrapolating, and it's inherently error prone, and difficult. I doubt it would have performance enhancing affects. and even if it did I doubt they would be significant enough to warent the complication of such an indirection. and if it was I wouldn't want to implement it in the first iteration.
Bobboau, bringing you products that work... in theory
learn to use PCS
creator of the ProXimus Procedural Texture and Effect Generator
My latest build of PCS2, get it while it's hot!
PCS 2.0.3


DEUTERONOMY 22:11
Thou shalt not wear a garment of diverse sorts, [as] of woollen and linen together

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: yet another materials system topic
i really just dont like the single string function call format used in place of a texture name. there are ease of use issues. this makes the material settings difficult to tweak (youd have to use a pof editor as opposed to notepad). its also confusing for modders who might not know what a number in the string means. i would at the very least use named variables so the modder knows what the numbers mean to the material. i think it would be better to use the name to reference a file containing the parameters for the material (variables, textures, data mining scripts, ect), if not the material itself.

you would have to use a pof editor at some point anyway, having it in the pof also makes it easier for future pof editors to be able to edit and manipulate it.

the problem with this is that what you describe would be like if the textures were listed in the ship table or something, the it seems like adding indirection for indirection's sake to have the pof link to a file that links to a material, when the contents of that intermediary file could just as easily be set in the pof. I mean you are going to need a dozen of these mapping files for every model, dozens of itty bitty text files that if you forget to pack them they the model wont work, seems error prone, you have to open each one up independently, unless you are careful to maintain a strict naming convention you will have no idea which mapping file goes to which model, this just seems like a management nightmare.

I am not opposed to syntax like:
solidcolor(color:#ff0000, shine:#ffff00)
that actually has a number of advantages, such as you could assign default material values
i dont think i would have anything against a text block being added to the texture chunk on a per texture basis, or perhaps a materials chunk which supersedes the texture chunk (thus providing a mechanism for reverse compatibility, no materials chunk indicates default texture behavior), instead of a file. i certainly dont want to use the ships table though since some materials would be reused across multiple ships, causing redundancy. i was thinking more along the lines of in an eff file (or a .mat file), but it does cause an organizational nightmare. youre gonna get one anyway just because of the extra textures that you will want to use in multiple materials. i guess using the new syntax might be acceptable, passing variables by names as opposed to order would be more intuitive for modders. but if we could do a new materials chunk with a text body instead of a 1 line string a more familiar table syntax could be used:

Code: [Select]
$name: solid color
 +color: 255 0 0
 +shine: 255 0 0

this would be far more readable, especially with a large number of parameters. but i would suggest using a .mat file for testing purposes pending a new chunk format and support in pcs2. if a material has a dozen parameters then you might end up with a very very long string which is hard to edit.

Quote
seems like a simple concatenation of strings to me. no material referenced, so use the default. the default would take the name string from the pof texture chunck and concat -glow, -shine, -normal, etc, to it and look for those textures, and if found use them. default material would just be hardcoded (though overwritable if desired) as the first instance, just to maintain compatibility with existing texture naming conventions, so it dont break old mods.

maybe we are misunderstanding each other, a material name would have parenthesis in it, solidcolor(), I could be wrong but I am fairly sure that solidcolor().dds is not a valid file name on the windows platform, and I think using the presence of (*) in the file name as the flag that this is referencing a material not a texture would be the way to go. obviously if you don't have parenthesis in the file name it will load like it does now.

what i said was under the assumption that the function call format was replaced with a named reference to a parameters file. if you do decide to stick with the function call format or a new chunk then this would not be an issue. im actually leaning away from a parameters file now, and would only suggest using one for testing purposes. 
Quote
you could still make predictions based on the last 2 samples (or number of samples), if the data mining script runs every 10 frames, youd at most be off by a fraction of a second and that wouldnt look too bad, but i still kinda think id rather have the var change between frames than just sit idle for several frames. perhaps make it possible to choose between various sample based prediction algorithms, hard delta, soft delta, smoothed, noise, static, whatever. i just dont see it optimal to run data mining scripts all the time or perhaps at all (maybe use sexp-like expressions or flags indicating vars to mine to conditionals in c). just an idea.

that's not interpolating, that's extrapolating, and it's inherently error prone, and difficult. I doubt it would have performance enhancing affects. and even if it did I doubt they would be significant enough to warent the complication of such an indirection. and if it was I wouldn't want to implement it in the first iteration.

i use the wrong term, my bad. but running an extrapolation algorithm in c as opposed to data mining in the much slower scripting environment or expressions system every frame could turn out to be very slow. then again i really dont mind a few frames of lag between when your afterburners burners fire and your glowponts go super-bright. if you allow a samples worth of lag, and interpolate that against the most recent sample and step forward each frame across the interpolated range that would look ok. for example you have a sample at frame 0 and a sample at frame 10 and frames 1..9 use interpolated samples.  so at frame 10 you use the sample from frame 0, and at frame 11 you use the sample interpolated for frame 1, and so on. considering your sampling every 10 frames you would only be 1/6th of a second slow at 60fps. of course youd likely work by timestamp to maintain uniformity at all frame-rates. you might get some error, but its only changing the appearance of a texture. worst case scenario you get a little graphics glitch for a single material over a single frame. also not everything is speed critical. if you want your hull to look damaged based on remaining hitpoints, it could take a few seconds for fireballs and explosions to clear to reveal damage and this can be second or two slow.
« Last Edit: August 24, 2011, 10:19:28 pm by Nuke »
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline Bobboau

  • Just a MODern kinda guy
    Just MODerately cool
    And MODest too
  • 213
Re: yet another materials system topic
i dont think i would have anything against a text block being added to the texture chunk on a per texture basis, or perhaps a materials chunk which supersedes the texture chunk (thus providing a mechanism for reverse compatibility, no materials chunk indicates default texture behavior)

that's entirely a POF editor thing, a text block and a single line string are identical at the data level, it's simply a matter of changing the editor control in the POF editor.
a supposed material chunk would look exactly like a texture chunk aside from the identifier. you can't use both at the same time however, because the geometry index into the texture list.

what i said was under the assumption that the function call format was replaced with a named reference to a parameters file. if you do decide to stick with the function call format or a new chunk then this would not be an issue. im actually leaning away from a parameters file now, and would only suggest using one for testing purposes. 

using an external file would be harder to implement, it would be silly to do it 'just for testing' when the easier method is to just use the texture string, which already exists and already has all the code in place to read it.


i use the wrong term, my bad. but running an extrapolation algorithm in c as opposed to data mining in the much slower scripting environment or expressions system every frame could turn out to be very slow. then again i really dont mind a few frames of lag between when your afterburners burners fire and your glowponts go super-bright. if you allow a samples worth of lag, and interpolate that against the most recent sample and step forward each frame across the interpolated range that would look ok. for example you have a sample at frame 0 and a sample at frame 10 and frames 1..9 use interpolated samples.  so at frame 10 you use the sample from frame 0, and at frame 11 you use the sample interpolated for frame 1, and so on. considering your sampling every 10 frames you would only be 1/6th of a second slow at 60fps. of course youd likely work by timestamp to maintain uniformity at all frame-rates. you might get some error, but its only changing the appearance of a texture. worst case scenario you get a little graphics glitch for a single material over a single frame. also not everything is speed critical. if you want your hull to look damaged based on remaining hitpoints, it could take a few seconds for fireballs and explosions to clear to reveal damage and this can be second or two slow.

what exactly do you mean by "data mining", I think a script that sets a few ship specific variables would not have much of a performance hit at all. it's not like it's going to be doing complex pattern recognition analysis in lua on a large body of text. in order to do extrapolation you need to have a decent model of how you expect the variable to change, I mean you could do a cubic extrapolation, which could yield not horrible results most of the time, but I think you'd end up with situations where you had oddly flickering lights, or something similar and I don't think it would be for any benefit.

what you are doing here is a classical example of premature optimization, you are trying to solve a performance problem when you have no idea weather or not it exists with some elaborate side step.
Bobboau, bringing you products that work... in theory
learn to use PCS
creator of the ProXimus Procedural Texture and Effect Generator
My latest build of PCS2, get it while it's hot!
PCS 2.0.3


DEUTERONOMY 22:11
Thou shalt not wear a garment of diverse sorts, [as] of woollen and linen together

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: yet another materials system topic
i dont think i would have anything against a text block being added to the texture chunk on a per texture basis, or perhaps a materials chunk which supersedes the texture chunk (thus providing a mechanism for reverse compatibility, no materials chunk indicates default texture behavior)

that's entirely a POF editor thing, a text block and a single line string are identical at the data level, it's simply a matter of changing the editor control in the POF editor.
a supposed material chunk would look exactly like a texture chunk aside from the identifier. you can't use both at the same time however, because the geometry index into the texture list.

still id use a block format as opposed to a one line format. if a material is used id put the material name between $ and : characters and put the parameters in +name: value format on following lines. absence of the $ and : characters would indicate it is a texture and nor a material, and the reverse compatibility mode would be invoked. this format is familiar to modders, and thats why i think it should be used.

i use the wrong term, my bad. but running an extrapolation algorithm in c as opposed to data mining in the much slower scripting environment or expressions system every frame could turn out to be very slow. then again i really dont mind a few frames of lag between when your afterburners burners fire and your glowponts go super-bright. if you allow a samples worth of lag, and interpolate that against the most recent sample and step forward each frame across the interpolated range that would look ok. for example you have a sample at frame 0 and a sample at frame 10 and frames 1..9 use interpolated samples.  so at frame 10 you use the sample from frame 0, and at frame 11 you use the sample interpolated for frame 1, and so on. considering your sampling every 10 frames you would only be 1/6th of a second slow at 60fps. of course youd likely work by timestamp to maintain uniformity at all frame-rates. you might get some error, but its only changing the appearance of a texture. worst case scenario you get a little graphics glitch for a single material over a single frame. also not everything is speed critical. if you want your hull to look damaged based on remaining hitpoints, it could take a few seconds for fireballs and explosions to clear to reveal damage and this can be second or two slow.

what exactly do you mean by "data mining", I think a script that sets a few ship specific variables would not have much of a performance hit at all. it's not like it's going to be doing complex pattern recognition analysis in lua on a large body of text. in order to do extrapolation you need to have a decent model of how you expect the variable to change, I mean you could do a cubic extrapolation, which could yield not horrible results most of the time, but I think you'd end up with situations where you had oddly flickering lights, or something similar and I don't think it would be for any benefit.

what you are doing here is a classical example of premature optimization, you are trying to solve a performance problem when you have no idea weather or not it exists with some elaborate side step.

by data mining i simply mean to go into the game, get a variable, maybe refine it (do some operations on the data) and return the results to the materials system so the var can be used to modulate some effect. pretty much all that needs to be done. id use script or events systems because they already touch upon a wide variety of variables. i merely assume doing this every frame for every instance of every material, could potentially be slow, but that is something to find out in testing. but still ive merely suggested a few ways in which these things can be made faster should they proove problematic.
« Last Edit: August 25, 2011, 05:06:55 pm by Nuke »
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline Bobboau

  • Just a MODern kinda guy
    Just MODerately cool
    And MODest too
  • 213
Re: yet another materials system topic
still id use a block format as opposed to a one line format. if a material is used id put the material name between $ and : characters and put the parameters in +name: value format on following lines. absence of the $ and : characters would indicate it is a texture and nor a material, and the reverse compatibility mode would be invoked. this format is familiar to modders, and thats why i think it should be used.

I'm not opposed to that, though it would initially be on one line until someone modified PCS2 to use a multi-line text editor, that should be a relatively trivial change though.

by data mining i simply mean to go into the game, get a variable, maybe refine it (do some operations on the data) and return the results to the materials system so the var can be used to modulate some effect. pretty much all that needs to be done. id use script or events systems because they already touch upon a wide variety of variables. i merely assume doing this every frame for every instance of every material, could potentially be slow, but that is something to find out in testing. but still ive merely suggested a few ways in which these things can be made faster should they proove problematic.

nah, this would be done once per frame in one scripting call that figured out all the parameters in one go, with the amount of scripting used presently I don't think this would slow things down hardly at all.
Bobboau, bringing you products that work... in theory
learn to use PCS
creator of the ProXimus Procedural Texture and Effect Generator
My latest build of PCS2, get it while it's hot!
PCS 2.0.3


DEUTERONOMY 22:11
Thou shalt not wear a garment of diverse sorts, [as] of woollen and linen together