Lighting
Re: Lighting
Thank you guys for the fast response
@Per: Excellent, now I have everything I need. Am I correct in assuming that the direction vector corresponds to the tank's local y-axis?
@SafetyOff: So, do you like it? The main thing I wanted to change was ensuring that pure black is still black despite adding a teamcolor.
@Per: Excellent, now I have everything I need. Am I correct in assuming that the direction vector corresponds to the tank's local y-axis?
@SafetyOff: So, do you like it? The main thing I wanted to change was ensuring that pure black is still black despite adding a teamcolor.
-insert deep philosophical statement here-
Re: Lighting
I don't like that the multiplication by 2.1 causes distortion in the whites, so I approve of changing from grain merge to multiplication with mask interpolation, but not the multiplication by an arbitrary factor.Jorzi wrote:@SafetyOff: So, do you like it? The main thing I wanted to change was ensuring that pure black is still black despite adding a teamcolor.
I tried to find a good, simple function that would boost the amount of team colour present in the darker colours (I assumed that's what the 2.1 was for), but I didn't find anything that I was happy with.
So if you guys are content with the multiplication/interpolation then we can commit it, otherwise I think we should look at other solutions.
Note: Here's what I've been using, you should try it to make sure its not just my hardware/software.
OBJ file i've been using:
Code: Select all
g cube
v -32 -32 -32
v -32 -32 32
v -32 32 -32
v -32 32 32
v 32 -32 -32
v 32 -32 32
v 32 32 -32
v 32 32 32
vn 0 0 1.0
vn 0 0 -1.0
vn 0 1.0 0
vn 0 -1.0 0
vn 1.0 0 0
vn -1.0 0 0
vt 0 0
vt 0 1.0
vt 1.0 0
vt 1.0 1.0
f 1/4/2 7/1/2 5/2/2
f 1/4/2 3/3/2 7/1/2
f 1/2/6 4/3/6 3/1/6
f 1/2/6 2/4/6 4/3/6
f 3/1/3 8/4/3 7/3/3
f 3/1/3 4/2/3 8/4/3
f 5/4/5 7/3/5 8/1/5
f 5/4/5 8/1/5 6/2/5
f 1/2/4 5/4/4 6/3/4
f 1/2/4 6/3/4 2/1/4
f 2/2/1 6/4/1 8/3/1
f 2/2/1 8/3/1 4/1/1
Re: Lighting
I think so, but Safety0ff is the resident expert on those now...Jorzi wrote:Thank you guys for the fast response
@Per: Excellent, now I have everything I need. Am I correct in assuming that the direction vector corresponds to the tank's local y-axis?
Re: Lighting
No, currently that shader gives the rotations for the individual axes (currently that patch give it in 16 bit fixed point format), with ZXY rotation order.Jorzi wrote:Am I correct in assuming that the direction vector corresponds to the tank's local y-axis?
Heh, I'm no so sure about that... stinking wz math...Per wrote:I think so, but Safety0ff is the resident expert on those now...
Re: Lighting
So I will have to use matrix transformations? These use radians, right?
-insert deep philosophical statement here-
Re: Lighting
For degrees, orientation.diff should be changed to:Jorzi wrote:So I will have to use matrix transformations? These use radians, right?
Code: Select all
@@ -348,6 +359,7 @@ void pie_ActivateShader(SHADER_MODE shaderMode, PIELIGHT teamcolour, int maskpag
glUniform1f(locStretch, shaderStretch);
glUniform1i(locTCMask, maskpage != iV_TEX_INVALID);
glUniform1i(locFog, rendStates.fog);
+ glUniform3f(locOrientation, UNDEG(shaderRotation.direction), UNDEG(shaderRotation.pitch), UNDEG(shaderRotation.roll));
if (maskpage != iV_TEX_INVALID)
{
#define FP2RAD(fp) (fp)*0.00009587379924285258
then change the patch to:
Code: Select all
@@ -348,6 +359,7 @@ void pie_ActivateShader(SHADER_MODE shaderMode, PIELIGHT teamcolour, int maskpag
glUniform1f(locStretch, shaderStretch);
glUniform1i(locTCMask, maskpage != iV_TEX_INVALID);
glUniform1i(locFog, rendStates.fog);
+ glUniform3f(locOrientation, FP2RAD(shaderRotation.direction), FP2RAD(shaderRotation.pitch), FP2RAD(shaderRotation.roll));
if (maskpage != iV_TEX_INVALID)
{
Re: Lighting
Thanks for the info
About the tcmask blending mode, I agree that the multiplication by arbitrary factor is somewhat inelegant.
However, if we skip the 2.1 factor the current textures will be very dark, and it's also not possible to add highlights brighter than the defined teamcolor, so I'd consider it an artistic choice...
I agree that a formula where white areas are also (almost) white would be optimal, but I still think my formula works pretty ok...
About the tcmask blending mode, I agree that the multiplication by arbitrary factor is somewhat inelegant.
However, if we skip the 2.1 factor the current textures will be very dark, and it's also not possible to add highlights brighter than the defined teamcolor, so I'd consider it an artistic choice...
I agree that a formula where white areas are also (almost) white would be optimal, but I still think my formula works pretty ok...
-insert deep philosophical statement here-
Re: Lighting
Here is something I had came up with but wasn't 110% happy with:Jorzi wrote:I agree that a formula where white areas are also (almost) white would be optimal, but I still think my formula works pretty ok...
Code: Select all
void main(void)
{
vec4 colour, mask;
// Get color and tcmask information from TIUs 0-1
colour = texture2D(Texture0, gl_TexCoord[0].st);
mask = texture2D(Texture1, gl_TexCoord[0].st);
vec3 invColour = 1.0-colour.rbg;
float tcBoost = dot(invColour,invColour)+1.0;
gl_FragColor = mix(colour, tcBoost*teamcolour*colour, mask.a) * gl_Color;
}
Re: Lighting
interesting approach.. calculating a unique factor per pixel...
Looks quite nice, although it doesn't allow for highlights...
Looks quite nice, although it doesn't allow for highlights...
-insert deep philosophical statement here-
Re: Lighting
After adjusting the contrast of the camo in the texture for your transport (from another thread) I've ended up with this (using my latest shader): I think it is a good compromise, though the factor formula could be tweaked.Jorzi wrote:interesting approach.. calculating a unique factor per pixel...
Looks quite nice, although it doesn't allow for highlights...
Re: Lighting
yeah, it works pretty well with my current models
-insert deep philosophical statement here-
Re: Lighting
A question about the glsl shaders. Isn't it possible to directly use gl_ModelViewMatrix to transform normals from object space to screen space, instead of using the orientation euler angles you provided?
EDIT: Also, what programs are recommended to compile warzone? qtcreator should come bundled with the gcc compiler and I read about bison and flex being needed, but the wiki compile guide seemed somewhat outdated, talking about using svn, and not mentioning qt at all...
EDIT: Also, what programs are recommended to compile warzone? qtcreator should come bundled with the gcc compiler and I read about bison and flex being needed, but the wiki compile guide seemed somewhat outdated, talking about using svn, and not mentioning qt at all...
-insert deep philosophical statement here-
Re: Lighting
Absolutely, though that isn't what you asked for.Jorzi wrote:Isn't it possible to directly use gl_ModelViewMatrix to transform normals from object space to screen space, instead of using the orientation euler angles you provided?
Btw, you'd need more than just gl_ModelViewMatrix to get to normalized device coordinates.
I suggest you either ask for what you really want or try to explain what you're doing.
Re: Lighting
I recommend using gcc. If you are using Linux, you should be just use whatever gcc and Qt Creator that are available in your package repository, and those should work fine. What is your build environment/platform?Jorzi wrote:EDIT: Also, what programs are recommended to compile warzone? qtcreator should come bundled with the gcc compiler and I read about bison and flex being needed, but the wiki compile guide seemed somewhat outdated, talking about using svn, and not mentioning qt at all...
Re: Lighting
I'm on windows 7 and I'm trying to learn glsl:P I'm planning on modifying warzone's fragment shader to use object-space normal maps. The maths are not very complicated at all but I'm trying to learn basic syntax and stuff, as well as learning what functions are built-in and what needs to be done manually.
-insert deep philosophical statement here-