Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Bobboau on April 16, 2005, 05:52:53 pm
-
well I've prety much finalised the syntax o the materials table, and I have a working parser for it (and the structs needed to store the data)
you will have to/be able too (depending on how you look at it) define materials that will have diferent properties based on the environment and define multi-pass lighting behavior (usualy this is little more than telling it to use additiive alpha on the aditive lighting passes)
this is the current state of my materials table, keep in mind that if you don't want to take advantage of this you won't have to mess with it at all. and once I get materials working it won't be much longer till I get shaders working, and with the way this is set up it will be almost the most versitile shader/material system posable.
$Material: fullbright
#Instance_set{
#Instance{
$Format: ("pos" "uv_1")
#Pass{
$Z_Buffer:
+read: yes
+Write: yes
+opp: lessequal
$Alpha: +preset:none
$Cull: 1
$Lighting: no
$Render_Step:
+Opp: arg1
+Arg1:
+type: texture
+value: 0
}Pass
}Instance
}Instance_set
$Material: diffuse
#Instance_set{
#Instance{
$Format: ("pos" "norm" "uv_1")
#Pass{
$Z_Buffer:
+read: yes
+Write: #FLP{yes}FLP #ALP{no}ALP
+opp: lessequal
$Alpha: +preset: #FLP{none}FLP #ALP{add}ALP
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult
+Arg1:
+type: diffuse
+Arg2:
+type: texture
+value: 0
}Pass
}Instance
}Instance_set
$Material: glowmapped_diffuse
#Instance_set{
#Instance{
$Format: ("pos" "norm" "uv_1")
#Pass{
$Z_Buffer:
+read: yes
+Write: #FLP{yes}FLP #ALP{no}ALP
+opp: lessequal
$Alpha: +preset: #FLP{none}FLP #ALP{add}ALP
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult
+Arg1:
+type: diffuse
+Arg2:
+type: texture
+value: 0
#FLP{
$Render_Step:
+Opp: add
+Arg2:
+type: texture
+value: 1
}FLP
}Pass
}Instance
}Instance_set
$Material: glowmapped_shinemapped
#Instance_set{
#Instance{
$Format: ("pos" "norm" "uv_1")
#Pass{
$Z_Buffer:
+read: yes
+Write: #FLP{yes}FLP #ALP{no}ALP
+opp: lessequal
$Alpha: +preset: #FLP{none}FLP #ALP{add}ALP
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult*4
+Arg1:
+type: specular
+Arg2:
+type: texture
+value: 2
$Render_Step:
+Opp: mult_add
+Arg1:
+type: diffuse
+Arg2:
+type: texture
+value: 0
#FLP{
$Render_Step:
+Opp: add
+Arg2:
+type: texture
+value: 1
}FLP
}Pass
}Instance
#Instance{
$Format: ("pos" "norm" "uv_1")
#Pass{
$Z_Buffer:
+read: yes
+Write: #FLP{yes}FLP #ALP{no}ALP
+opp: lessequal
$Alpha: +preset: #FLP{none}FLP #ALP{add}ALP
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult
+Arg1:
+type: diffuse
+Arg2:
+type: texture
+value: 0
#FLP{
$Render_Step:
+Opp: add
+Arg2:
+type: texture
+value: 1
}FLP
}Pass
#Pass{
$Z_Buffer:
+read: yes
+Write: no
+opp: lessequal
$Alpha: +preset:add
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult*4
+Arg1:
+type: specular
+Arg2:
+type: texture
+value: 2
}Pass
}Instance
}Instance_set
$Material: shinemapped
#Instance_set{
#Instance{
$Format: ("pos" "norm" "uv_1")
#Pass{
$Z_Buffer:
+read: yes
+Write: #FLP{yes}FLP #ALP{no}ALP
+opp: lessequal
$Alpha: +preset: #FLP{none}FLP #ALP{add}ALP
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult
+Arg1:
+type: diffuse
+Arg2:
+type: texture
+value: 0
}Pass
#Pass{
$Z_Buffer:
+read: yes
+Write: no
+opp: lessequal
$Alpha: +preset:add
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult*4
+Arg1:
+type: specular
+Arg2:
+type: texture
+value: 2
$Render_Step:
+Opp: mult_add
+Arg1:
+type: diffuse
+Arg2:
+type: texture
+value: 0
}Pass
}Instance
#Instance{
$Format: ("pos" "norm" "uv_1")
#Pass{
$Z_Buffer:
+read: yes
+Write: #FLP{yes}FLP #ALP{no}ALP
+opp: lessequal
$Alpha: +preset: #FLP{none}FLP #ALP{add}ALP
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult
+Arg1:
+type: diffuse
+Arg2:
+type: texture
+value: 0
}Pass
#Pass{
$Z_Buffer:
+read: yes
+Write: no
+opp: lessequal
$Alpha: +preset:add
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult*4
+Arg1:
+type: specular
+Arg2:
+type: texture
+value: 2
}Pass
}Instance
}Instance_set
$Material: multi_pass_shinemapped ;;sometimes you want to force this, like glass
#Instance_set{
#Instance{
$Format: ("pos" "norm" "uv_1")
#Pass{
$Z_Buffer:
+read: yes
+Write: #FLP{yes}FLP #ALP{no}ALP
+opp: lessequal
$Alpha: +preset: #FLP{none}FLP #ALP{add}ALP
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult
+Arg1:
+type: diffuse
+Arg2:
+type: texture
+value: 0
}Pass
#Pass{
$Z_Buffer:
+read: yes
+Write: no
+opp: lessequal
$Alpha: +preset:add
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult*4
+Arg1:
+type: specular
+Arg2:
+type: texture
+value: 2
}Pass
}Instance
}Instance_set
$Material: same_texture_shinemapped ;;uses the defuse texture as the shine texture as well
#Instance_set{
#Instance{
$Format: ("pos" "norm" "uv_1")
#Pass{
$Z_Buffer:
+read: yes
+Write: #FLP{yes}FLP #ALP{no}ALP
+opp: lessequal
$Alpha: +preset: #FLP{none}FLP #ALP{add}ALP
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult
+Arg1:
+type: diffuse
+Arg2:
+type: texture
+value: 0
}Pass
#Pass{
$Z_Buffer:
+read: yes
+Write: no
+opp: lessequal
$Alpha: +preset:add
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult*4
+Arg1:
+type: specular
+Arg2:
+type: texture
+value: 0
}Pass
}Instance
}Instance_set
$Material: 1_texture_glow/shinemapped ;;uses the defuse texture as the shine texture as well
#Instance_set{
#Instance{
$Format: ("pos" "norm" "uv_1")
#Pass{
$Z_Buffer:
+read: yes
+Write: #FLP{yes}FLP #ALP{no}ALP
+opp: lessequal
$Alpha: +preset: #FLP{none}FLP #ALP{add}ALP
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult
+Arg1:
+type: diffuse
+Arg2:
+type: texture
+value: 0
$Render_Step:
+Opp: add
+Arg2:
+type: texture
+value: 1
}Pass
#Pass{
$Z_Buffer:
+read: yes
+Write: no
+opp: lessequal
$Alpha: +preset:add
$Cull: 1
$Lighting: yes
$Render_Step:
+Opp: mult*4
+Arg1:
+type: specular
+Arg2:
+type: texture
+value: 0
}Pass
}Instance
}Instance_set
each material consists of a name and a number of instinces held within an instince set, each instance is one posable implementation of the material. the instances should be ordered from best implementation to simplest. the first instance that the user's hardware is capable of suporting is the one that is used, all others are ignored.
within the instance, you must declaire what vertex data this instance of the material will use, generaly this will involve position, normal, and one uv coordanant (I have an idea for upgradeing the model format (so that, for example, more than one UV coord can be used) that won't requier rebuilding all exsisting models) ["pos" "norm" "uv_1"], (if you don't need lighting don't includ norm, if you don't need textures don't include uv_1).
after vertex format has been specified, you must define one or more rendering passes, the fewer passes you use the better.
each pass consists of a number of render states (zbuffer, alpha blending, ect...) and up to eight render steps (you must define at least one) were you can define all sorts of behavior such as render arguments, how they will be combind, were they will be output to (current or temp, this is not render target, though I intend to add that functionality eventualy),wich UV coord set to use, and texture wrapping behavior (for example, you could have the texture mirror rather than repete)
one of the unfortunate complexities, is that you will need to define diferent behaviors for diferent environments and lighting modes. this is done via blocks, a block is a section of table that is started by #a_label{ and ended with }a_label. the only two blocks that I currently have in the table are FLP and ALP. FLP is the first lighting pass, generaly this will be the only thing you see, but when more than the maximum lights are needed an additive lighting pass is used to draw the additional data, because you have controle over how the first lighting pass is blended, there is no way to determine how the additional passes are to be drawen, so you will have to define them. generaly anything constant should be only used in the first lighting pass, for example glow mapps should only be drawen once (and my tables reflect this), in most cases you are going to want to use no blending on the first lighting pass, and additive blending one the additive ones (as my tables reflect) if you however should use a subtractive alpha blend you won't want to use addtive blending here, further, you have full access to all alpha blending options (not showen in the table but it's there) so you will need to figure out how your alpha mode should be added.
in addition to lighting modes you will also be able to specify diferent behavior for nebula, normal space, and subspace (and anything else I eventualy think of) useing a similar method.
anything between the brackets of the labels will only be parsed when that option is active, text between the bracets is erased when the option is not present so for anyone with any programming experience it's sort of like an #ifdef #endif block.
now any questions?
this might seem confuseing, but once you get the hang of it it's unbeleiveably easy and super powerful, you will no longer have to rely upon us programmers to develop new rendering modes, (multi-textureing, for example, would be a peice of cake to implement).
-
I really really hope, for the sake of your coding sanity that Instince is not meant to be Instance... :nervous:
That said, abso-bloody-lutely awesome looking stuff. I get the gist of the tables, but it'll probably take a little bit of study to get full idea, but it looks good!
-
Originally posted by Flipside
I really really hope, for the sake of your coding sanity that Instince is not meant to be Instance... :nervous:
better now? :rolleyes:
-
:blah:
*Hopes someone understands all that*
-
@WMC's following post.
at what point do you get confused?
-
:D Ignore me :)
-
arg timewarp, @flipside:
tis ok, I fixed it :)
-
Well, how to take a shine map and turn that into an effect, for example. If it means you have to add the specular tag, doesn't that restrict types of maps?
I guess I'm sort of confused by what this does, and how it provides a feature beyond merging everything into one big shinemap, glowmap, normal-map set if coders still have to add 'specular' or 'bump map' or whatever.
-
diffuse and specular are the names of the two lighting colors, when a primitive is being drawen to screen it has two colors available, they are refered to as d0 and d1 or diffuse and specular, because that is typacly what they are used for, but if you have a vertex shader you can put anything you want to in there.
the available options for argument type are:
CURRENT (the result of the last opperation), TEMP(an off screen drawing area), DIFFUSE(a lighting color), SPECULAR(a lighting color), TEXTURE(the color of a texture at the point on the screen you are drawing), and VARIABLE (a variable on the ship). these are basicly all colors. you could for example turn lighting off and specify any two colors you wanted you would have to refer to them as diffuse and specular though.
the reason why this gives such advantage to the modders is becase it basicly gives total controle of the fixed function over to a material designer.
-
So what you're saying is that you could use VARIABLE() to make the glowmaps darken/brighten when a Sathanas charges a beam cannon?
-
more or less (variable is going to requier a coder sets up a variable for it. you have to pick from a bunch of predefined variables)
-
Ugh. Can't we just have something simple in a pof editer to do this for us? I'm starting to dread this system.
If it was like the pic below, I'd be more inclined to use it.
-
the end result will be something like that, this is how those effects will be implemented, not accessed.
-
I didn't understand anything you guys said, but since it's SCP, it must be ****ing fantastic. Way to go Bobb.
-
I've got it drawing now, I still have a lot of work to do, but when I get done everything involved with drawing a ship is going to be so much cleaner it isn't even funny. I just replaced about ten pages worth of realy ugly code with about half a page. I am haveing to completely rerwite all vertex buffer drawing and light management code. I will atempt to et the OGL functions myself, for once, once I have everything in d3d done, there will be two realy long boreing functions and a whole bunch of small boring ones.
-
Awesome. :)
Will you be able to work in some way of using Display Lists?
-
This is sounding really really promising, anything that optimises texture drawing code to that degree may well have a very good impact on rendering times :D
-
this is actualy what I wanted the display list code for, I'm already useing it (well the d3d side of it at least). the only major thing I need realy to get OGL working is a function that can take an enum and a value and set things like z_buffer mode, and alpha blending states, and a seperate one for manageing TMUs in a similar way. I also need to get a bunch of smaller functions made that will do things like set and activate lights, a vertex buffer renderer that doesn't do anything other than rendering buffers (ie no state changeing), but I'm going to wait untill I have d3d done because I seem to keep changeing little things.
-
When this is ready, do you expect it to overcome the ATI-Cat4.4+ D3D Shinemap bug?
-
not imediately, but this is the last thing I have to get working before I get started on shaders, and that will not only fix the cat bug, but it will actualy allow far superior quality. man I can't wait untill I get a per pixel lighting model working in FSO.
-
i hope it will allow script based animations. if it does you could in theory use them for cockpit gauges. you would just need a good imagination and the ability to access variables that the hud gauges use.
-
It'd be better to just make a flexible variable system that could be used for both gauges and the texture system, it'd be less convoluted to do things and probably more efficient as well. It would probably have to be hooked into the materials system (so you could choose whether the gauge would use a glowmap/shinemap)
Actually it'd be nice if we could work it into the animation system so we could do truly 3d knobs and dials and such.
It's not like we don't have render-to-texture for D3D...
-
we have render to texture now? :D
-
well... we do...
you, as of now, don't. there is no access to it to any modder yet, exept environment mapping wich was modified to use the new system.
-
Originally posted by Bobboau
the end result will be something like that, this is how those effects will be implemented, not accessed.
So lazy people can just use pre-defined materials? :)
Looks like this is going to become one of best features ever.
-
exactly, in fact I am guessing that most people will simply use the predefined materials, on top of everything else this makes all rendering effects much more organised and even a little faster than they currently are.
tangent:
I am realiseing that I will need to add suport for texture transformations, be they static (scaleing texture coordanants, for easy multi-textureing) or dynamic (panning textures, and environment mapping needs a changeing texture transformation)
-
You know this is some awesome work, don't you? ;)
-
yes, I am aware of this. :)
-
so will we be able to include math functions and have access to game variables in our material scripts?
my idea is that you would have one control panel matieal with the scripted subsections for each gauge. then you can configure your panel simply through creative uv mapping, using the same material for all ships. you could aslo hav vasudan panels and shivan panels or a different panel material for each ship. and you can do stuff beyond panels, like making the glowie spots on the ship change collor as the engine output changes, or have your weapons light up when their armed. i would have fun with that, at least once i learn your scripting system.
-
you'll have access to game variables (at least untill we move to DX9 you'll only be permitted one variable per pass), but I'm not sure how much mathematical action I'm going to code. surely when we get the shader suport you'll have all sorts of math you can through at stuff (if hardware suports shaders) but with the states I don't know if I can get that effecent enough to make it worth while.
-
I would love to get some sort of simple-to-use variable system in - my draft is somewhere in the SCP internal - but I've gone through three revisions, at least, and still haven't got a 100% working version. (The last major revision didn't take arrays into account very well)
-
Originally posted by Bobboau
you'll have access to game variables (at least untill we move to DX9 you'll only be permitted one variable per pass), but I'm not sure how much mathematical action I'm going to code. surely when we get the shader suport you'll have all sorts of math you can through at stuff (if hardware suports shaders) but with the states I don't know if I can get that effecent enough to make it worth while.
we dont need much maths, just basic operations and maybe a couple trig functions, maybey some logic functions. i dont see the one var per pass to be a big limit unless theres a big slowdown as you use more passes. just give us the tools and im sure you will see some awesome effects by us modders.
-
theres a big slowdown as you use more passes.
-
so how many passes do you think it could hande?
-
As few as possible please.
Right now we're talking <5 with shinemaps/glowmaps/envmapping, in general, I think - unless there's more than 16 lights affecting the object.
AFAIK you can have as many passes as you like, though.
-
8> lights = 3
8> lights <16 = 5
on hardware that can handel 8 lights
most materials should have one or maybe two passes.
-
When taking animated textures into account, would it be possible to set the FPS and rotation type (Once, repeat, bounce) and whether to fade between frames?
What I'm thinking of are things like runway lights, where you really just need to fade between light set A being on to light set B being on. With the current system you'd have to make a massive animated glowmap. This would allow the same thing with just two frames and gradual alpha adjustment.
It might also work for Lightspeed's animated Shivan ship textures, and fading between frames would work well for when time compression is used to slow things down.
-
Not to mention some cool cloacking effects - I'm talking about Ordos esque masquarade of pirate/black ops ships.
-
you can do liniar interpolation between two textures easily.
-
Well....... less posting, more coding!
-
I have only one response: Cool :yes:
-
Hurry up with it! I want my shinemaps back! :D
-
well if I had my homework done I'd be right on it, but I am haveing quite a time finding the material I need.
-
The PETA vids?
-
yip :)
-
im taking a couple days off to recover from work (i remember the days back when i went to work to recover from my days off :D) so if ya got anything cool to test now would be a good time. ever implement those gatling turrets?
another idea would be a matfile system. you would have a matfile that would contain the various textures used and the blending script for the material. then you could use the name of the matfile in your texture list. i dont know how your set up right now but it might streamline things.
-
ok, got my speach done, got an A. next I have a big'ole programming assignment, I have to implement 6 diferent sorting ruteens, though I get a few hours to work on it tomarow.
as for this, the next big thing I need to figure out is a variable system, so I'm thinking each material should be given a expression class, this would manage a bunch of element classes, each element would be derived as either a variable or an opperator, I'll do some parseing majic so that externaly everything runs like one would expect, but internaly, there will be an array of elements, opporators will take the value of the next two elements as parameters and evaluate them acordingly, variables will be passed a current_ship pointer and execute a function pointer they are given on instansiation (wich would consist of something like "return ship->engine output;")
I'll have to limit return types to floats
-
do you realize how awesome it is that you (and all the other coders too) do this for free?
-
the reason i make mods for free
1. i hate capitalisim
2. it builds my experience
3. its fun
4. capitalisim sucks
5. i would never sell out my talents
im sure the coders dont have far too different reasons. were all sub-perfessionals, the only difference between a professional and a sub-professional is that sub-pros dont get paid for their work (see 1 and 4). there are plenty of professionals who dont know a **** how to do their job but are damn good at selling out. so i think were better :D
honestly my most recent work is much better than crap like tachyon or perhaps even freelancer
-
capitalism made possible the computer your using, the clothes your wearing, and the food your eating. dont be hatin.
-
all of witch we can do without...
capitalisim is like a booster rocket on the space shuttle, it gets you up to a certain altitude and then must be ejected or else its weight would just impede the ships progress to orbit. capitalisim has established a society and it is fast becoming time to get rid of it. a point will be reached eventually when the current system will no longer function. when this happens society will either crumble, or we may choose a new system. its the same cycle thats been running for an eternity. sence i dont believe in free will, i think were pretty much ****ed.
none the less this isnt the place to discuss my nihilistic point of view. back on topic...
-
*Starts to derail the thread with a discussion of politics/economics - hestitates*
No...that's what they'd be expecting me to do...
A lot of things have made a lot of other things possible in the past which are now considered bad. Simply because something has worked in the past doesn't mean it's the best thing for the future.
There. Something broad enough that it's on-topic. :p
-
"Yay Capitalism!"
-
2 and 3,
I love capitolism, it's the perfict way to continue evolution in a powerful socal animal.
-
and this is sort of what I'm thinking for the whole user variable system
#include "ship/ship.h"
class variable{
public:
virtual float value(ship*shipp=NULL) = 0;
};
class constant:public variable{
float val;
public:
constant(float in):val(in){};
float value(ship*shipp=NULL){return val;};
};
class operate:public variable{
protected:
variable *operand1, *operand2;
public:
virtual float value(ship*shipp=NULL) = 0;
operate(variable*op1, variable*op2){operand1 = op1; operand2 = op2;}
};
class add:public operate{
public:
add(variable*op1, variable*op2):operate(op1,op2){}
float value(ship*shipp=NULL){return operand1->value(shipp) + operand2->value(shipp);}
};
class sub:public operate{
public:
sub(variable*op1, variable*op2):operate(op1,op2){}
float value(ship*shipp=NULL){return operand1->value(shipp) - operand2->value(shipp);};
};
class mult:public operate{
public:
mult(variable*op1, variable*op2):operate(op1,op2){}
float value(ship*shipp=NULL){return operand1->value(shipp) * operand2->value(shipp);};
};
class div:public operate{
public:
div(variable*op1, variable*op2):operate(op1,op2){}
float value(ship*shipp=NULL){return operand1->value(shipp) / operand2->value(shipp);};
};
class expression:public variable{
int n_var; //number of variables in the expression
variable** var; //an array of pointers, each points to a diferent subclass
variable *head; //the head of the expression
variable* parse_next(char**);
public:
expression(char*);
~expression(){for(int i = 0;i float value(ship*shipp=NULL);
}
/*
variable* con = new constant(1.0f);
variable* op = new add(con,con);
*/
#include "graphics/materials/variables.h"
expression::expression(char* in_str):n_var(0),var(NULL),head(NULL){
while(*in_str){
}
}
variable* expression::parse_next(char**in_str){
//do some parseing
//get the string into pre-fix notation
char ship_idnt[] = "ship:";
char op_char[] = "+-*/"
if(!strcmp(in_str,ship_idnt)){
//it's a ship variable
}else{
//it's a constant, or an opporateor
if(strchr(op_char, **in_str)){
//it must be an operator
}else{
//it must be a constant
}
}
}
float expression::value(ship*shipp=NULL){
}
I need to make a class that takes a string, allocates enough variable pointers, allocates each pointer to the corect type, and while doing that passes the corect pointers to all operate type variables.
to set up the variable cascade corectly it will need to convert to prefix notation.
each new ship variable type would requier a new class be defined for example ship:thrust would be
class thrust:public variable{
public:
float value(ship*shipp=NULL){if(shipp)return ship->what_ever_the_member_was; else return 0.0f;};
};
global variables like fov would just ignore the ship parameter
-
yay! variable thing pretymuch done, now back to this.
first thing I'm gona add with this is a texture matrix
each step of each pass can have a diferent texture matrix assosiated with it, this is all totaly optional, if you don't add the texture matrix section it will fill it in with a default identity (change nothing) matrix. for those of you who don't know a matrix is basicly a 2d list of numbers, it is used in transformations with a texture matrix you can scale rotate move a texture on a surface (I will provide scale(x,y) rotate(a) move(x,y) pan(x,y) auto-matrix features once I get the low level version working so people who have no idea what they are doing can use these features).
now the syntax of the low level texture matrix code I'm thinking right now should be something sort f like this
$Material: fullbright
#Instance_set{
#Instance{
$Format: ("pos" "uv_1")
#Pass{
$Z_Buffer:
+read: yes
+Write: yes
+opp: lessequal
$Alpha: +preset:none
$Cull: 1
$Lighting: no
$Render_Step:
+Opp: arg1
+Arg1:
+type: texture
+value: 0
[b]+texture_matrix(
("1.0" "0.0" "0.0")
("0.0" "1.0" "0.0")
("0.0" "0.0" "1.0")
)texture_matrix[/b]
}Pass
}Instance
}Instance_set
each one of those numbers can be an expression so rather than 1.0 for the first one you could use fpart(:global{time}) and it would evaluate that expression every time it rendered that.
I have the underlying code set up to minimize expression evaluations so if an element is from the identity there won't even be a constant variable used.
-
I did a search for matrices (since I'd like to know something beyond 'magical things that let you rotate stuff.' :p)
So far I've found "Matrices: A Lesbian and Lesbian Feminist Research and Network" and this site (http://www.geocities.com/SiliconValley/2151/matrices.html), which is a bit more relevant.
-
haveing knowledge about matricese in general is good, but there are some specific things about how they function in this instance that you need to know, I'll try to give everyone a run down on it when I get everything working.
-
oih my god it ****ing works! this is ****ing SWEET!!!:D:D:D
it'll be somewhat limited untill we get model files that suport it, but my material system now has the capability to run any texture translation effect you can think of.!!!!!
-
ok things that need expressions and/or need to be implemented.
frame selector- wich frame out of a multi-frame animation.
pass variable, I need to rework some stuff, each pass gets one variable,
I need to figure a way to allow activation of a single color chanel within the variable system that is transparent.
can't think of anything else off the top of my head, put up some more ideas for were thid could be usefull
-
Hmm, I thought I posted this, guess not.
Will it be possible to use a single alpha channel to control glowmaps? ie, you have your base diffuse texture, with alpha, and then you have a single additional channel that handles the glowmap 'intensity'.
Ditto for shinemaps.
Since most textures only really make use of the base 'this thing glows' and 'this thing shines', it could reduce memory usage a lot.
-
cant really think of anythi g off the top of my head, but im planning on taking the next 3 days off of work again, so if you need anything for testing let me know.
-
yeah, I'm prety sure that can be done, if it's posable to do at all then it will be posable with this system.
-
Originally posted by WMCoolmon
Since most textures only really make use of the base 'this thing glows' and 'this thing shines', it could reduce memory usage a lot.
That's not true. Almost all of the new maps have the glowing points removed from the base map, so that when the lights are off they go black instead of diffuse-color-of-the-light. I actually can't think of any major examples left where this is not the case.
-
Speaking of wich, we needs the lights to turn off for debris.
-
It seems absurd to me, though, that we need four full channels just to add red glow gradiants on Shivan fighters, for example. When we start loading bumpmaps or normal maps, it'll just get even worse.
Take this for example:
Fighter with one 1024x1024 map for the entire ship:
4.1 MB Diffuse
4.1 MB Glowmap
4.1 MB Specular
4.1 MB Normalmap
----------------------
17.4 MB per ship.
For every channel removed, the size goes down by one megabyte.
-
^dont you mean 4?
And couldnt you have a pixel shader that creates an animated red gradient from a greyscale map (once we get those implemented ofcourse)
-
well the great thing is very soon it will be easy to change things like that.
I can't off the top of my head think of exactly how you would add the multiplication of texture A with the alpha chanle of texrue A to the multiplication of texture A and the defuse color. but there's probly a way to do it :).
oh, yeah, and I just pluged a little memory leak (stupid virtual destructor crap) and added an optomiseation that will reduce any constant subexpression to a single constant. so ((3*4-1)/sin(ln(34^5)))+107^5 will be replaced by14025517295.277
-
I get 14025517343.315744886 with the Ubuntu calculator :p.
-
I got that from my TI89, given that the TI89 costs more your calculatore must be wrong
-
Mine has more decimal points than yours. :p
-
no it doesn't ,
no it doesn't !
/*la!la!LA!*/
I'm not listening I'm not listening.your wrong .your wrong .your wrong
-
I wish i had a TI89 silver.
-
well this is freaking cool to the point that I need to show off, this is a build and the requiered table.
this is a build that has gives glowmapped ships a pulseing glow, it' doesn't quite work in game (though it shouldn't crash, however I can't garentee it. it WILL use the wrong textures for diferent effects)
feel free to play with the table.
things are extreemly limited untill I get the model files upgraded so you can choose wich material to use.
http://freespace.volitionwatch.com/blackwater/materials_test_5-1-05.zip
you may now bask :)
-
:jaw: :jaw: :jaw:
w0000000000000000000000000000t!!!!!!!!!!!!!!!!!!!!!!!1
When's it going in CVS? :nervous:
-
Well, the build crashes whenever I try to look at a ship (any ship, even if its my own using the '.' key, and backgrounds dont work at all. However, it doe-
*sees all the ships in the techroom
Holy....sh...****!!
*goes to get FRAPS
-
if you want to play, the material glowmapped_shinemapped is the one used by most ships.
it also has a commented out texture matix example (that shows translation in one direction)
"When's it going in CVS? "
heh... gona be a while :)
-
.....i didn't understand the half of that...
-
wich half?
-
......
*looks down in shame...
Both....
btw...I do have a video showing the effect...captured it with FRAPs...anyone got place for a 15+ MB file? GW seems to be down right now :/
-
Originally posted by Bobboau
well this is freaking cool to the point that I need to show off, this is a build and the requiered table.
this is a build that has gives glowmapped ships a pulseing glow, it' doesn't quite work in game (though it shouldn't crash, however I can't garentee it. it WILL use the wrong textures for diferent effects)
feel free to play with the table.
things are extreemly limited untill I get the model files upgraded so you can choose wich material to use.
http://freespace.volitionwatch.com/blackwater/materials_test_5-1-05.zip
you may now bask :)
:eek2: :yes:
Wow, now we can use high res glow maps instead of animated ones. Is it possible to randomize the pulse start for tiles?
So some parts of a capship won't glow at the same time?
-
can i make panel gauges with it yet?
ieverything apears without glowmaps on my rig. and it broke transparency too.i might be doing something wrong though.
my command line:
Z:\FreeSpace2\fs2_open_r.exe -spec -glow -pcx32 -jpgtga -d3dmipmap -nomotiondebris -2d_poof -pcx2dds -nobeampierce -dualscanlines -ship_choice_3d -targetinfo -orbradar -3dwarp -ballistic_gauge -smart_shields -snd_preload -env -alpha_env -decals -fps
-
Bob, is this a preview build, or are you already interested in bugs?
-
Hehe: messing with colour channels is fun. ;)
http://www.geocities.com/vasudanad/DiscoOnEnifStation.zip
Brilliant feature tho - i've already lost count of the number of situations this could be used in. :D
-
This is great! ;) :lol:
Hmm I should try a few things too.
-
Err. I tried it. Put the materials table in the tables forlder, ran the program... and nothing.
EDIT: Ok put it in the root dir and it worked.
-
Need screenshots people!
:yes: Bloody marvelous Bob. :D
-
Hmm screenshots won't show anything. It's like the glowmap fades on and out....
-
okhay thats pretty cool although raw to say the least
is it possible to make it randomized on different parts of the maps and will we be able to make it NOT fade out completely?
(everyone dosent turn off the lights at same time ;))
-
You could fake that with a noise-textured luminosity map that translates across the map itself. It wouldn't be as cool-looking as, say, Lightspeed's Lucy maps, but it would be cool enough.
-
i dont even know of how this could be used, but man, it's cool to see....if it can be perfected, so that things use it realistically, it'd be awesome, makes things seem more alive and stuff, rather than just being static objects
even how it is right now, it makes it seem more vibrant...more movement on the screen, like there's actually things going on in those ships
great job bob!
-
heh, there's a hell of a lot more that you can do than just play with the color chanels of the pass variable.
what you guys are all looking at was about four seconds of tinkering, there are all sorts of crap you can do
here is a complete list of suported argumaents for all of the optional strings (listed in order that the optional strings apear)
first off I should explain the block system used
there are a number of
#name_of_block{
}name_of_block
things available, the most important of wich are the
#FLP{
}FLP
and
#ALP{
}ALP
blocks they define what happens in the first lighting pass and additive lighting passes respectively. you see the most lights any hardware can suport is 8, so in order to draw an object with more than 8 lights on it we must add the lighting of the remaining lights. so anything related to lighting should be fine most of the time, but you need to change some things almost all of the time, the alpha blending modes need to be changed, on the first lighting pass you need to usualy use either no alpha blending or alpha chanel alpha blending, on the additive lighting passes you almost always want to use additive alpha blending, also the z_buffer usualy needs to be write disabled, in addition to that any non-lit lelements of a material need to be disabled on the additive lighting passes so glowmaps (and things like them) should be held in a #FLP{}FLP block.there are other blocks not demonstrated in the current material table, they relate to diferent environments, such as nebula, subspace and normal space ("normal","nebula","subspace") in order to use these just put the name in the name_of_block section anything between the start and end block denoters with only be present in the corisponding situation, anything outside the block will be present in all situations
"$Material:" name_of_material
the name of the material, the material used by most objects is glowmapped_diffuse, so if you want to play with this, that is the one you should be experimenting on for the most part.
#instance{
don't screw around with "$Format:" yet, it doesn't realy do anything yet, but it will be used eventualy. but for documentation purposes the available flags are:
pos, norm, uv_1, uv_2, uv_3, uv_4, diffuse, specular.
the diferent uv flags are incompatable with each other, and untill major work is done on the model format only uv_1 will do anything, these coordanants tell how many sets of 2d UV coords each vertex has. but as I said this isn't going to be functional for quite a while, it's unfortunate that the instances get started off with such an intimidateing and confuseing item, just ignore this for now.
#Pass{
"$Z_Buffer:" and "$Alpha:" both have a manual mode, and a preset mode. first, I'll describe the preset modes
"$Z_Buffer:+preset:" suports "full" "none" "read" or "write"
full - is normal zbuffering
none - has no z buffering
read - uses the z buffer for drawing but doesn't change it
write - draws without care of the z buffer but outputs it's depth.
if you set it up manualy there are three opptional strings
+Read: (yes/no)
+Write: (yes/no)
+opp: (none,less,equal,lessequal,greater,notequal,greaterequal,all)
for most situations useing the preset of full is all you will need, if you ar useing additive alpha blending you will probly want to turn it to 'read'. the only advantage to manual setup is you have access to wich comparison opperation is used, read and write as well as the whole "$Z_Buffer:" section are totaly optional, if you don't put something down it will defualt to full z buffering, wich is what you want in most cases.
"$Alpha:"
now this one you can have some real fun with, especaly if you make some multi-pass materials.
the alpha presets are
none (default)
'additive' or 'add' (additive alpha, like thrusters)
alpha_blend (uses the alpha chanel for transparencies)
now the manual mode for this has a lot more opptions, you can do all sorts of crazy ****, like subtract what you'r drawing, though at the moment this'll only realy be visable if you use it for multi-passing effects (because the exe doesn't work very well in game yet)
"+src:" and "+dest:" use the one of the following values (capitalizeation not nesicary anyware): ZERO, ONE, SCR_COL, INV_SRC_COL, SRC_ALPHA, INV_SRC_ALPHA, DEST_ALPHA, INV_DEST_ALPHA, DEST_COL, INT_DEST_COL
"+blend:" hmm, I just noticed I forgot to get this one activated, unfortunately this is one of the more fun parameters to fool around with, well I better tell you what the corect values should be (even though they won't work in the build you all have): ALPHA_ADD, ALPHA_SUB, ALPHA_REV_SUB, ALPHA_MIN, ALPHA_MAX
"+test:" it takes a number, I beleve it needs to be a value between 0 and 255. you can use this to make alpha transparent bits that stuff will be able to render through
"+test_opp:" determines how the test works (if the alpha of a pixel on the texture is greater/less/equa/ect..l than the pixel on the screen do/don't draw it) it takes the same arguments as the z test opp and works the exact same way
(none,less,equal,lessequal,greater,notequal,greaterequal,all)
in order to make use of manual pllha blending you need to know the alpha blending formula,
at any given pixel
final color = dest*dest_factor + src*src_factor
'dest' is the color on the screen.
'dest_factor' is what you specify when you use the '+dest:' tag.
'src' is the color of the texture (well actualy the color of the output polygon) at the point on screen it's getting drawn.
'src_factor' is what you specify when you use the '+src:' tag
the addition between the two terms can be changed to a subtraction (or a subtraction with the terms reversed) by changein the "+blend:" tag.
"$Cull:" a much simpler option, this determines wich, if any, cull mode is used, 1 draws polygons faceing the screen,0 draws all polygons, -1 draws only the polygons faceing away from the screen. this would be especaly fun with multi-pass textures were you draw the back face of something one way and the front face a totaly diferent way (with some sort of alpha blending).
if you use 1 or 0 the model will draw prety much exactly like you expect, if you use -1 they will draw inside out. use 0 only if you are doing something like additive alpha.
"$Lighting:" a yes/no, does this material use the fixed function lighting, almost all the time you will want to use 'yes' but if you have something that glows (or later has precalculated lighting values, or you use vertex/pixel shaders) then you would want 'no'
"$Pass_Variable:" this takes an expression for each of the "+R:","+G:","+B:","+A:" components, this is what is used later when you specify a variable for a render step argument.
ok, that's all the current pas specific stuff, now on to the render steps:
"$Render_Step:"
you must always have at least one render step, you may not have more than eight.
"+opp:" this is one of the things you have an absurd number of choices with, it is the opperation that will be performed on the two arguments. the options you will most commonly use would be
add - add arg1 to arg2
and
mult - multiply arg1 with arg2
but you have a few more opptions available,:
DISABLE, ARG_1, ARG_2, MULT, MULTX2, MULTX4, ADD, ADD_SIGNED, ADD_SIGNEDX2, SUB, ADDSMOOTH, BENLD_VERTEX_ALPHA, BLEND_TEXTURE_ALPHA, BLEND_VARIABLE, BLEND_LAST_ALPHA, PREMODULATE, MULT_ALPHA_ADD_COL, MULT_COL_ADD_ALPH, MULT_INV_ALPHA_ADD_COL, MULT_INV_COL_ADD_ALPH, DP3, MULT_ADD, LERP
so... I guess I should explain a few of those...
disable will kill the current render step and any following render steps.
arg_1 and arg_2 mean you just select one of them and discard the other
mult multiply, multX2 = a1 * a2*2, multX4 = a1 * a2*4
ehh.. I'll link to the MS DX documntation that describes all of these in detail.
"+Arg1:" and "+Arg2:" exept on the first pass arg1 defaults to 'current' arg2 defaults to 'texture', now to explain what this means.
the values available for these tags are: CURRENT, TEMP, DIFFUSE, SPECULAR, TEXTURE, VARIABLE
because there are only five, I'll explain all of them
'CURRENT' the result of the last texture step
'TEMP' a temporary off screen drawing area (I'll explain how to draw to this in a second)
'DIFFUSE' and 'SPECULAR' the first and second color chanles respectively, they are named for what lighting values the fixed function lighting system gives them
'VARIABLE' use the pass variable that you defined earlier (if you didn't define this and you use it here it will give you black)
'TEXTURE' one of the material textures, use "+value:" after this to specify wich of the 8 textures to use, with the current hack system only three textures are available 0 = defuse base texture, 1 = glow map, and 2 = shine map. you may use a texture only once per pass, and only one texture at a time.
"+Output" draw the result of the opperation opp(arg_1,arg_2) to the screen (current) or the temp drawing surface.
"+UV Index:" wich set of UV coordanants to use, useless at this time always set to 0 or better yet, don't use at all.
"+Addressing:" one of the more fun things to play with, that I'm use people will get a kick out of, this determine how out of range uvcoords get handled, the default is to wrap (repete, tile), but you also have "mirror" "clamp" and "border", further, you get to determine this on a per direction basis so you can hae it wrap in the U direction and miror in the V. the corect syntax for this item is
+Addressing:
+U:mode
+V:mode
were mode is one of the available options (wrap,mirror,clamp,border)
"+frame_selector:" this is a mathmatical expression that determines wich frame of an animation (if there is an animation used) is selected
the default frame selector is:
"(:global.time:*:texture.fps:)%:texture.n_frames:"
the last line is especaly important to remember, because at this time I don't have any error corection code in place and if you forget to make sure you are within the range of available frames you'll try useing frames that probly don't exsist, or are some random texture, I will fix this eventualy, but at the moment you need to be aware of this.
+texture_matrix(
(ii,ij,ik,il)
(ji,jj,jk,jl)
(ki,kj,kk,kl)
(li,lj,lk,ll)
)
ah... the texture matrix.. what can I say about this...it can do lots of neat stuff. rotations scaleing panning of textures, kind of dificult to explain how to do that tough
you only need to define it as big as the values you need, so generaly the fourth row and collum can be ignored. the matrix is row major (or what ever is the opposite of OGL's default)
*each element is an expression* you can put simple numbers down, or full expressions, useing any game variable or function you could use elseware. currently you can only define a single matrix, so you will have to work matrix multiplications out by hand, but I intend to alow defineing of multable matricies that get multiplied together.
##texture panning: the element ki and kj relate to a UV offset in the U and V directions respectively, this needs to be made a function of time (or some other changeing variable) in order for you to realy see anything happening.
+++++++nothing bad will happen if you just screw around with this, don't be afraid of it+++++++
useing sin and cos of an angle would be usefull in the first 2*2 elements
this matrix is 4*4 because d3d suports up to 4 texture coordanants, and I need all four dimentions to properly set up environment mapping. you will probly never need the 4th row or collum.
}Pass
}instance
-
You know, when I saw the Thread title I tough of different materials as in different textures.
I actually tought you implemented texture recognition (so if it's a metal panel texture it will render like metal and act as armour by decreasing damage done..or if it's windows it will be more vulnerable to attack..etc...)
Silly me:D
-
Now how ON EARTH would you do that?
Bob, out of curiosity, is this pixel shaders proper or just a material system back end?
-
this is only the foundation upon wich a pixel shader system will be built
-
honestly, it probly wouldn't be too hard to get WCM's armor system integrated with this., rather than doing ther stuff on a per ship basis it would do them on a per material basis.
-
Won't that cause the number of materials required to skyrocket?
-
don't think so, though I realy have no idea how his armor system works
-
Well, I basicly tought that if a texture is marked as metal panel any shot hitting an area covered with that texture will be decreased. and vice-versa for windows or softer materials.
Basicly you have a txt files which classifies all textures per material type...
that's how I imagined it....but it sounds too much work...think of it - you have to write down all the texture fileames and theri type and damage reduction, AND write a recognition code.
-
or you add one line to the material table telling wich armor types from the armor table to use...
-
What if you want the same texture to map to different armor types on different ships? There's really no way to designate a material "hard" or "soft" simply by its looks or file name, but you could either a) assign it a special material (which I worry about because then you have (number of material types) * (types of armor), i.e. tons of duplication) or b) give each map a special additional map where each region that was supposed to behave differently could be mapped to a different color. I don't particularly like either of these solutions because they move damage application from the colission check into the materials handler, which sounds like a can of worms that's better left unopened.
-
most textures only get used on one ship, and there is not a one to one coralation between textures and materials, the same materials gets used dozens of times with diferent textures all over the place, right now each ship has an index to wich armor to use (if I understand the system corectly) what I'm saying is move that index to the material system, then in the colision check system (wich already has the ability to determine wich material was on the poly that got hit) and instead of shipp->armor_type you type material->armor_type I'd rather have WCM talk about this though because I'm realy talking out my ass when it comes to his system. but as far as I'm aware it wouldn't be had to have tougher materials than others.
-
pics now.
-
Pics don't show it very well.
-
so basically all that stuff in the table tells it to _just_ blink the glowmaps on and off? snap
-
arggg, no, !
that was a blink of effort, play with the damned thing and see what you can do.
-
Right now, it's basically a table that's indexed.
All I'd need to do to change armor type on a per-material basis would be to have an int stored with the material, and some way to tell which material was hit.
I'm going to be revamping the system if I work on it anymore, to be easier to use in the ships and weapons tables, so all you really need for the materials table would be to add something like this:
char buf[NAME_LENGTH];
if(optional_string("$Armor Type:"))
{
stuff_string(buf, F_NAME, NULL);
mat_pointer->armor_type = get_armor_by_name(buf);
}
And - of course - some way for me to retrieve what material type to grab the armor_type value from in ship_do_damage.
I'll have to revise some of the member functions but it should be possible
-
I would, but this is all waaaay over my head. Despite your explanations. :(
-
Originally posted by Raa
I would, but this is all waaaay over my head. Despite your explanations. :(
no, no it is not, it is not so far over your head that you can't just randomly change things.
-
Hmm, material editting capability in the lab would be very handy.
-
Originally posted by Bobboau
no, no it is not, it is not so far over your head that you can't just randomly change things.
Err. I wouldn't know what can be changed and what can't. 's why I model and not code.
-
Originally posted by WMCoolmon
Hmm, material editting capability in the lab would be very handy.
that might be dificult, as it relys on state blocks.
-
It's a learning curve Raa. If you looked at what is needed to mod the SCP these days, and you hadn't been along for the entire ride, it would seem pretty daunting.
Same with this, I don't understand it, but I'll tweak and learn from my mistakes, just as I did with every other aspect of modding FS2, and eventually get the hang of it. Don't underestimate yourself ;)
-
Well, I rejoined this community when glowmapping was implemented. Then HTL. And Spec. And Env. But those were all easy to grasp. As soon as I have to learn new code for something, it instantly becomes 17x harder. :(
I think I'll wait for someone else to learn it, and keep asking them questions...
-
start with the render steps, specificly args and opps, that is probly the most important, and easiest to grasp, especaly if you have photoshop experience.
this (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/graphics/reference/d3d/enums/d3dtextureop.asp) is a complete documentation on the stage opperations
and this (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/graphics/reference/d3d/constants/D3DTA.asp) is complete documentation on the arguments
just remember it's two arguments put together by one opperation, you select all three of these.
-
Bookmarked, thanks :)
I'll work through them alongside the tables and play a bit, see what happens :)
-
its not to dissimilar to material scripts ive used in other games, but i still dont know enough about how rendering works to make anything spectacular at the moment. also i need to figure out why your glow test doesnt work. but i got 2 more days to figure it out.
one thing id like to do is make a glow map and overlay that with a diufuse map with transparency. you can do stuf like have the gas iin the gas compartment of a gas miner look as iff its moving within the vessel.
-
Like the Anuket?
-
yea, also you could make vasudan bioplating alittle bit more lifelike, make it look like skin with flowing veins and such beneath. also you can do tbp vorlon and shadow plating. that would be cool :D i just wish i could get it to work. it may just be my video card is too old to support it.
can you use two diffuse maps in a single material?
-
yeah, but at the moment you don't have any way of loading textures other than: defuse_name, defuse_name-glow, defuse_name-shine. so you'r stuck with them as texture 0,1, and 2 respectively, and you can't realy make materials and apply them like you should just yet, everything gets assigned a material based on what textures can be loaded, when I get the basic material system done, I'll make a new data chunk in the model file giveing you total controle over the situation.
-
Bobb, can/are the > < and == operators (or just =, if == is too many characters) be implemented into the code to give a 0 if false, 1 if true? This would be andy for armor stuff:
:weapon.damage: * (:weapon.damage: > 20)
Which would only apply damage if the weapon originally dealt 20 points of damage. I suppose you could do it with
:weapon.damage: * abs(sign(:weapon.damage: - 20))
but that's a little less clear.
Edit: Another question, would there be a way to use this to use 1/4th of a shockwave laid out to make a full shockwave? (Someone, DaBrain I think, asked about this)
And, someone asked about switching parts of the glowmaps on/off...could you use a sine function, for example, to make the glowmaps on a ship ripple - with only one glowmap frame? (I haven't heard anybody ask for this specifically, but I can think of some really cool effects you could do with something like this)
Finally, will there be a way to use SEXPs to add/remove materials and some way to fade them in? For example, to go from a "Hiigaran" material to a "Beast" material in TAP.
Edit: This is the last thing, really. :nervous: Can you at least commit the non-material-specific parts of the equation system so I can try it out with the armor table or at figure out how I'll have to implement it?
-
makeing comparison opperators that return float 0 or 1 would be like three minutes work, consiter it done:)
the shockwave thing, so you mean like, you have the upper quadrant of a circular thing, and you mirror it? yeah, that's actualy one of the optomiseations I was going to sudgest when I allowed the setting of materials for weapon effects.
I'm not sure exactly what you mean with turning parts of glow maps on/off, but if you wanted a rippling effect you could have one texture with a gradient and another glow texture. assign a texture pan for the gradient texture and multiply it with the glow texture.
(beast effect)we could probly make some sExp definable variables and, for that particular effect (psudo-script):
pass_variable :sExp.variable_assigned_for_this_task:
//or if we have some code for it :ship.beast_level_or_something:
renderstep
opp mult
arg1 beast texture
arg2 variable
renderstep
opp add
arg2 normal texture
renderstep
opp mult
arg2 defuse
//remember arg 1 always defaults to 'current' wich is the default output of each renderstep
that implementation doesn't have shine mapping, and that would probly only be doable via multi-pass
I was also thinking about this sort of thing to enable cloaking, cloaking would be enabled on a per material bassis, so you could in theory (if you wanted to) have a diferent cloaking effect for each part of your ship. it would work the same way as the beast effect basicly, you interpolate a texture that looks like the background, you'd just need to have a pass that said something like
pass_variable :ship.cloak_level:
if you set up the alpha blending to blend via alpha chanel.
opp mult
arg1 background texture
arg2 variable
this does bring up another thing, it might be a good idea to have a conditional in the render pass, modifying the synax to be
#pass(expression here){}
if the expression evaluates to be anything other than 0 then the pass is performed. otherwise it isn't
I'll try to commit the variable system tonight, I'm prety sure it's solid. though there may be smallish memory leaks (8 bytes at worst for each node). I'll try to get comparison opperators in there first though.
-
any way to create that fancy startrek style distortion effect while cloaked? perhaps have a material that has a starfield scrolling texture. effect and fade transarency debending on how much the ship moves around (predator active camo style) or before decloaking. some cool effects can be done.
-
if you saw the cloak effect I had going a while ago, that effect is almost posable with the material system right now. all I'm missing is access to the background texture in the table. I need to setup global textures at some point.
-
youre cool, bob....i like you (more specifically, i like the work you do)
anyhow...could someone help sum up all what this is capable of?
not sure if this is related, but i saw some shots from a build of yours, bob, that had shadows projected from ships and such...not sure what happened to that, but could this materials system thing be used for that too somehow? i like shadows :)
so far as realism goes, having all the "room" lights blink on and off, whether all at the same time or not, doesnt make sense...are you able to set aside only certain parts of the texture that would use the feature? like, on one of the vasudan transports, the cool little purple llights on the underside blinked on and off, which made enough sense to me...ships have blinking lights sometimes
but then, all the lights on the terran ships do the same....and that doesnt make sense...but, if only certain lights did, like, the lights on a rotating radar turret thing, etc, that'd be cool
basically, i'm not quite able to distinguish whether this is some kind of animated-graphic thing, or some kind of texture-attrubute thing (armour stuff)....or is it both? that's pretty versatile if it is
-
ok, I'm going to move some stuff around and commit the variable system. I just finished nearly full documentation on how to use it and how it works.
I'm going to commit the files, but not my workspace, because I have all sorts of crap, that no one else will, and I'd rather save that joy for the day my materials system is decent enough to commit.
-
ehh... :doubt:
cvs add variables.h variables.cpp (in directory I:\FSO\fs2_open\code\variables\)
cvs add: missing hostname in CVSROOT: :pserver:[email protected]/home/fs2source/cvsroot
cvs [add aborted]: Bad CVSROOT.
*****CVS exited normally with code 1*****
-
ummm... was something done with CVS, I added a colin to the end of the root like some faq said to and now I get
cvs login
(Logging in to [email protected])
Fatal error, aborting.
Bobboau: no such user
cvs login: authorization failed: server warpcore.org rejected access to /home/fs2source/cvsroot for user Bobboau
*****CVS exited normally with code 1*****
restoreing it to what it was before gives me
cvs login
cvs login: missing hostname in CVSROOT: :pserver:[email protected]/home/fs2source/cvsroot
cvs [login aborted]: Bad CVSROOT.
*****CVS exited normally with code 1*****
:wtf:
-
krisvek: didn't see you'r post till, just now. what this system does is it gives full controle of how objects are rendered over to a person editing a table file, if there is any way to acheve an effect this material system should allow you to do it. what has been demonstraited at this point is mearly a small test of what it's capable of, you've only seen the "hello world" implementations of what's posable. hope that answeres your question.
-
and sence, someone want's these files, and CVS is being *****y for some reason.
-
Just a dumb question, the awnsers probably no, but does using two materials with the same texture take any extra texture memory?
-
Bobb, I'm going to commit the variables system under the object folder, that seems a bit better than the location it seems to have in your local codebase. (Not to mention that the materials folder doesn't exist anyway. ;) )
-
@FireCrack:no.. I don't think you're even thinking of how this works right. no material has any specific texture assosiated with it. a model has a list of textures,when you draw a model with a material you give the material this list, and you tell it were and how to use wich textures from that list
so there realy isn't any coorelation between material and texture at all.
though I will later on allow global textures wich would not change from ship to ship.
@WMCoolmon:don't put it in object/, put it in variables/ make a new folder for it. that path wasn't were I had intended to place it (and leaveing like it was was a mistake)
-
:doh:
I *just* commited it to objects.
Edit: I'll fix it if you like, I just don't want to play musical folders. ;)
-
it's it's own thing, not a subset of object management, it doesn't make sence for it to be in with the object stuff, the only reason it was origonaly in with the material stuff is because it was origonaly just going to be a subset of the materials system.
to the new folder and the music stops for ever, no musical folders.
-
Done
-
For someone who doesn't understand what the hell this is all about, can we get it in either layman's terms, orrr....possibly screenshots of what it can do?
-
I second what UT said, as I am confused and mortified by what everyone has to say.
-
It lets you change how textures are applied, instead of just what textures are applied.
Edit: Cloakmaps are a good example, actually. In order to do them, you need to tell the rendering engine that as the ship turns, the texture doesn't. Or rather, the texture must have the same rotation in world space, rather than in relation to the model as is the usual method.
It must also use the texture from the background, which is in memory. To give a cloaking effect, you may want the background texture to be offset slightly or add a special glowmap when it's active. This would let you do that, as well.
If someone else wanted to do a cloaking effect with two glowmaps - one under the background texture, one over the background texture - they could do that instead, with the material system.
-
Would be neat to make everything but the glowmap invisible on the pegasus.
-
you could do that easily.
-
just out of curiousity what are the video card requirements on getting this to actually work. it doesnt work at all on my geforce4mx420. my caps file is at www.game-warden.com/nukemod-cos/nukesd3dcaps.txt
-
about the only thing you need for this that you wouldn't on anything else is state blocks, but that should be abstracted by d3d for cards that don't have hardware suport
-
Damn, Starshatter just jumped to a DirectX 9 engine with full bump-mapping support. I have faith that Bob's material achievements will pave the way for FSO to re-establish its past and rightfull place in "graphics" superiority.
-
I'm quite confedent, that when I am done, our graphics engine will make there colective e-penises shrivelup and fall off. :)
-
AFAIS it will do a lot more.
That disco-station already showed the freaky things the material system will let you do. Finally you'll have full control over the skin of any craft - though most will only use the pre-created materials, eventually material modders will emerge as well.
Beside graphics is one thing - full mod support and tools to port anything into is another! An so far I'm yet to see another game as modable as FS Open.
-
so will we have DX9 support?
-
Originally posted by Bobboau
I'm quite confedent, that when I am done, our graphics engine will make there colective e-penises shrivelup and fall off. :)
Hell, yeah!
I'm going to learn writing custom shaders.
@Turambar
Positive. ;)
-
well actualy the DX9 switch will probly come after I get shaders wich will come after I get the materials system done, wich will be at least two more months. and after we switch to DX9 I'll have to alter some of the materials stuff (add options).
-
Originally posted by Bobboau
well actualy the DX9 switch will probly come after I get shaders wich will come after I get the materials system done, wich will be at least two more months. and after we switch to DX9 I'll have to alter some of the materials stuff (add options).
We aren't switching to DX9, remember. Not without conditional compilation anyway.
-
Can we move this part of the thread into the internal please.
-
It already is in the internal. But I had to clarify the issue so that the forum regulars will know that we haven't switched gears on them.
Further discussion can and should go in the internal, though.
-
Blasted isolationism :(
-
To code or cope that's the question.
-
Okay, would someone please tell me what this is all about, in plain english?
I tried to follow the course of this thread, but all these technical terms and CPU speak have me confused:confused::dizzy:
-
purdy colors
-
Basically, bump maps, normal maps, and all kinds of other cool graphical goodies are on the way.
-
that's a bit down the line still, I need to get this done so you have enough controle over what's going on to be able to make effective use of shaders.
when this is done, and then has shaders (im going to get both pixel and vertex at the same time) you still won't have bump mapping, but you will have the ability to make bump mapping, so were on the first (and biggest) of the final three steps.
when this is done though, it'll be a ground breaking new era in modability by it's self.
-
^And, best yet, shinemaps on ATI :D!
-
I wonder if there's any other game out there offering the same modability as FS_Open will.
The only stuff that even compares is stuff from Blizzard (WC3 ie.), and the Unreal Engine(! - direcly made for development so...).
-
Bobboau, can we bribe you or something to elevate FSO to Halflife 2 or Doom 3 standards? I can hear the REGRESSORS now. I'm willing to make the first donation. :)
-
No need for bribes, the man is a saint already set an aim:
Outdo HL2 and Doom 3.
Status: 17% - Matsystem.
15% - Multimapping (glow, shine, evn)
7% - Superdetailing
-
i updated my drivers and it kinda sorta works now. still i havent got to messing around with it yet.
-
Wait a sec. If this involves stuff needing to be added to the tables, then wait about old campaigns that use their own tables? Is this not backwards compatible? Or did I just not interpret everything correctly........
-
i figure old stuff would use the default materials set, else the campaign deigners could make a materials patch to take advantage of the new eye candy abilities of the engine.
-
Beyond that it should be possible to just stuff a materials.tbl in the mediaVPs, rather than hack it in. Pretty much everybody should have mv_core, and the only reason the materials.tbl would be overridden is if a campaign were to take advantage of it.
-
Still not really following this...
So we could do the following?
1) Assign 'Armour Types' to different ships
2)Have said Armour types be really good against some weapons, but poor against others
That's about all I can follow...
-
that's the armor thing WMC made, the material system is more about makeing things look good.
-
'nother question: :)
In terms of variables, we have ":global.time:" atm. Are there/ will there be others we can use to base calculations off?
Ie, velocity in certain directions, fred variables, ship damage, global location, light hitting object (ouch), distance to an object, ship orientation and many others i just can't think of right now. :D
All of those could quite nicely be used in various circumstances, such as basing light flickkering levels (or frequency of the flickkering) off the ammount of damage the ship has sustained etc.
And while i'm here: triggers. How will they work, and will it be possible to link an animation sequence to them?
Some things i can think of that would be awesome are: weapon links (ie, triggered by firing the associated weapon), object/weapon impacts, fred variables or sexps, docking process, object destruction (ie, only triggers when the object blows up - fancy non-standard explosion effects or special debris etc), warpout sequence and again many others that i can't think of. :)
Once people (myself included) learn how to use this to it's full potential, i think the results will be incredible. :D
-
there will be many many many game variables, I already have localy access to an object's position and orientation, as well as the eye/view pos/orient. adding in any of the variable you have mentioned would besimple and will probly be done anyway. the idea is to give access to as many game variables as posable.
the triggered animation system has a totaly diferent way of working. it has basicly a newtonion simulation running and when an event happens it's told to move an object in one direction or another. I realy had thought that by now a lot more would have been done with this, adding animation triggers is (in it's self) a very simple process, the only tricky part is figureing out were to place the few lines of code to add a trigger. as far as the variables here are concerned, it would probly be relitively easy to grant access to some of the variables involved. and a seperate animation system that uses variables to define object orientation is something I've had in mind for quite a while now.
I have implemented looping and conditional passes recently, I also added in an optional additional translation matrix (mostly for scaleing of thrusters but can be used for other things), this offers some very interesting posabilities. with these tools you could (if I hadn't already hard coded it) make weapon models that draw at each of the weapon points through the materials system.
-
there will be many many many game variables, I already have localy access to an object's position and orientation, as well as the eye/view pos/orient. adding in any of the variable you have mentioned would besimple and will probly be done anyway. the idea is to give access to as many game variables as posable.
That's awesome. :D Just give out a list of implimented variables when they're done, and i can't wait to use them. :)
In regards to the triggered animation systems, sorry, i think i mislead you there :\
I was still refering to the materials system rather than the sub-model one - ie, material effects that are only brought about once triggered. Pretty much like the current sub-model animation system triggers, except instead of moving something, it would initiate some sort of material change.
A really basic example would be to have a sexp fire after 20 seconds, which triggers a 'scripted' (mathamatically) material animation, such as gradually lowering the alpha values on difusse map of a ship, starting at the time it was triggered rather than as soon as the mission loads. :)
And don't worry about the sub-model animation code not being used. I was performing a rather interesting experiment the day it came out, as i'm sure many others were/are. :)
Within that same day i managed to get this:
http://www.geocities.com/vasudanad/New_OrestesDockingClaw.zip
I didn't release it then and am reluctant to release it now due to the terribly incomplete-ness of the whole thing, but since the docking ship there is going to be delayed in texturing, i figure i may as well post this now.
I was hoping to post a better one with both ships completely HTLed and with no glitches, such as some better docking clamps that were actually timed properly and looked decent, but the effect is still there in that one. So ignore everything but the animation. ;)
(I also have a pair of far far far more extravagant sequences completely planned out, but they're for TI. ;) )
And submodel scaling matricies you say? Ooooooooh...... :D
*scurries off to replan a few things*
-
Argh. Your geocities account is out of bandwidth by the looks, and I don;t have space to mirror that ani anywhere :( Which sucks, because it's rather cool.
-
arrgh, i was afraid of that. :\
*wants Sectorfiles back* :(
-
"save as" works fine for me. :)
Looks like the file is still there.
Edit: Wow, that's cool. :eek2:
-
If Raa recieves the file in an email, he may upload it to game-warden.
-
keep in mind that the geometry matricies will only effect what they look like, not what happens with colisions.
and you can make any/all passes conditional, so if there is some mathematical expression that will give a zero for everything that you don't want to draw, that's already implemented.
(you can also make looping passes and go through a serese of elements)
-
How are looping/indexed passes done (Just a line or pointer to another post is fine, I just want to see how it's done as it may be useful for things like the escort gauge...I'm not sure when I'll get back to coding work, next few weeks are gonna be busy...but maybe I'll come up with some good way in the next couple of weeks or something.)
-
there is a for loop and rather than useing 'i' it uses a mamber of variable_call_data that I added for that purpose, and I made another expression determine how many times to go through the loop, if that expression is NULL, it does it once, otherwise it does it as many times as that expression says.
although, I supose I could even go further and make an expression for every part of the for loop, the initaliser the comparison and the intrement step, just in case, but what I have now is more than enough to get done with most of the cases that will ever show up and the statement is rather ugly as it is.
for(call.iteration = 0; (mat->pass[p][get_environment()][0].loop)?call.iterationpass[p][get_environment()][0].loop->value(&call):call.iteration<1; call.iteration++)
//use quote, HTML parseing screws this up a little
-
ok, tonight's party time funfunfun was rewriteing the stupid assed way I was handleing model loaded textures and adding inline conditionals to the expression system.
it works similar to the c style inline conditional
()?():()
exept sence we already are useing ':' for stuff I had to use '|'
so it's like (:condition:)?(:true_action:)|(:false_action:)
example:
(:object.engine_output:>0)?(:object.engine_output:)|(1)
will return 1 when object.engine_output is <= 0 and it's value otherwise.
so... good for me.
now off to use this to put the warp effect's scaleing behavior into an expression wich is what initaly ent me off on this tabgent.
[wow smileies fuk'n ate this post alive]
[edit]
now that I think about it I wanted '|' for logical OR
the only common charicter left that I can see is '@' :/, I guess I could use '_'. anyone got any ideas here? it can only be one charicter
-
Perhaps "&"?
-
being used for logical and
-
£?
-
Not on the US keyboard.
-
could you yous some off keyboard asci character or is that too much a hassel?
-
I could do that, but would you realy want to have to remember some obscure acii code every time you wanted a conditional.
-
#
~
Would either of those work?
-
both are already used
# == root (of variable base)
~ == log (of variable base)
-
if anyone wanted to know the FSX (yay! I came up with a cool sounding name for my expression code!) code for the size of a warp model is
(:object.warp_life:<2.5)?(((:object.warp_life:/2.5)^0.4)*(:object.rad:/20))_((:object.warp_life:<:object.warp_life_max:-2.5)?(:object.rad:/20)_((((:object.warp_life_max:-:object.warp_life:)/2.5)^0.4)*(:object.rad:/20)))
-
I know I'm late posting this, but here it is. (I didn't get this email right away. MSN is a pile of scheiss!)
http://game-warden.com/raa/New_OrestesDockingClaw.zip
-
mind you nukemod still has the first and second use of submodel animation, unfortunately i commented them out of the tables because it wasnt in cvs at the time of my release of the nukemod beta.
-
Actually, i made the first version with only the doors on the 11th of Jan and that 'final' version the same day. Your ship got it's animated missile doors on the 14th. :p
Besides, Bob wins with the little Isis demo model he packed with the initial test exe. :p
-
well you didnt count the rumrunner, which i gave to bob for testing before the code was even working. :D
anyway bob can you please fix the $show weapon models: tag in cvs? the only exe i can mod with is a few months old.
-
That's jumping the gun then! :p
*runs*