Been working a bit on trying to understand more about the vertex and fragmentprograms in Doom3. Without a real tutor or any normal and useable info to find out there it's hard to say the least.

Can anybody explain to me why the shader below is upside down in Doom3 and not in Prey? It's a ported shader from Prey into Doom3 for testing. Why is it upside down? How can I flip it back?

Code:

see #radialblur.vfp in your Prey directory.

**shameless 48 hour waiting time bump**

One more bump and then I'll assume noone has an answer for me.

I've been struggling with this glprog for 3 days already and I've got not clue as to how to flip the image.

I saw this topic and have it on my "look into it" list but didn't have time yet to experiment myself.

You can turn the image upside down by negating the y component of all texture reads from Texture 0 (y = 1.0 - y). Maybe there is an elegant way to do this without introducing alot of new instructions.

My guess right now is to add a "ADD pos.y, 1.0, -pos.y;" right after the "MUL pos, R0, program.env[0];" but I'm not sure if this throws off the computations that happen afterwards.
EDIT: changed the "MOV pos.y, -pos.y;" to "ADD pos.y, 1.0, -pos.y;" because the texture doesn't wrap, you have to stay in the 0.0-1.0 range I think. Not sure about the syntax btw.

I think maha_x might know something. He is the one who has toyed a lot with doom3's, quake 4's and prey's shaders. Try PMing him.

der_ton wrote:

You can turn the image upside down by negating the y component of all texture reads from Texture 0 (y = 1.0 - y). Maybe there is an elegant way to do this without introducing alot of new instructions.

My guess right now is to add a "ADD pos.y, 1.0, -pos.y;" right after the "MUL pos, R0, program.env[0];" but I'm not sure if this throws off the computations that happen afterwards.

EDIT: changed the "MOV pos.y, -pos.y;" to "ADD pos.y, 1.0, -pos.y;" because the texture doesn't wrap, you have to stay in the 0.0-1.0 range I think. Not sure about the syntax btw.

Thanks for responding.

I've been tinkering with that a lot to no real avail. When I make a .vfp program from scratch and just parse the data it's totally normal. I have no clue what makes it 'upside down', or where in the prog it does that. I also wonder how they solved this in Prey, all of their glprogs turn out upside down, except the heathaze prog which is the same as the original. Which makes things even weirder, because if they solved this in the rendercode how do they know in code when to flip the image?

jcdenton22 wrote:

I think maha_x might know something. He is the one who has toyed a lot with doom3's, quake 4's and prey's shaders. Try PMing him.

Thanks, I will try that!

[edit]
Eureka!

der_ton, you totally put me on the right direction. I finally found out how to make it happen, I only had to add one simple calculation to the prog to switch it back to normal.

Code:

#(see radialblur.vfp in your Prey directory and find the line:
# scale by the screen non-power-of-two-adjust
MUL      pos, R0, program.env[0];

#then add, right after that:
ADD      pos.y, program.env[0], -pos.y;

What does this "ported" shader?

It shows (in conjuction with a target_setinfluence) a radialblur that covers the screen. Below's an old inverted screen which shows the effect nicely (never mind the upsidedown hud, that's been fixed now. But it's just a test, mind-you.

The similar kind of radial blur has already been implemented in Doom 3 ROE. I am talking about the same effect that gets triggered when the marine guy touches the artifact.

E.g.
http://media.pc.ign.com/media/710/710432/img_2697182.html
http://image.com.com/gamespot/images/2005/092/reviews/925095_20050403_screen010.jpg
http://www.lovefilm.com//images/products/screenshots/8/61358-3-large.jpg

Here are two random screenshots I took with radial blur on:

But I'll have to agree that it doesn't look as good as the effect you have achieved using Prey's shader. Moreover ROE's blur is achieved by iteratively applying the shader to a single frame (the default iterations are 30 per frame) making it too expensive to use. Due to the performance issue, I am not integrating this effect with my mod's dll.

All I want to know is, does your blur effect use iterations? if yes, how many? I guess it uses very less iterations or none may be.

This one in the end used 5 iterations to achieve the desired effect. The beauty about it is that because time is slowed down during this effect it's not noticeable (at all) that there is a slight performance impact. My machine drops about 2 fps or so when it's turned on, very acceptable; and because it's combined with an extra color filter (via the .mtr) I was able to tone it down considerably.

Code:

!!ARBvp1.0 OPTION ARB_position_invariant ;
MOV      result.texcoord[0], vertex.texcoord[0];
MOV      result.color, vertex.color;

END

#======================================================================

!!ARBfp1.0 
OPTION ARB_precision_hint_fastest;

TEMP      color, R0, R1, pos, displace, half;

PARAM      size=0.017;
PARAM      strength=.24;


MOV      R0, fragment.texcoord[0];
MUL      pos, R0, program.env[0];
ADD      pos.y, program.env[0], -pos.y;

MOV      color, 0;

MUL      half, program.env[0], 0.5;

SUB      R1, pos, half;

MOV      displace.x, 1;
MAD      R0, R1, displace.x, half;
TEX      R0, R0, texture[0], 2D;
MAD      color, R0, strength.y, color;

SUB      displace.x, displace.x, size.x;
MAD      R0, R1, displace.x, half;
TEX      R0, R0, texture[0], 2D;
MAD      color, R0, strength.y, color;

SUB      displace.x, displace.x, size.x;
MAD      R0, R1, displace.x, half;
TEX      R0, R0, texture[0], 2D;
MAD      color, R0, strength.y, color;

SUB      displace.x, displace.x, size.x;
MAD      R0, R1, displace.x, half;
TEX      R0, R0, texture[0], 2D;
MAD      color, R0, strength.y, color;

SUB      displace.x, displace.x, size.x;
MAD      R0, R1, displace.x, half;
TEX      R0, R0, texture[0], 2D;
MAD      color, R0, strength.y, color;

TEX      R0, pos, texture[0], 2D;
ADD      color, color, R0;

DP3      R1, color, { 0.5,0.4,0.3};
LRP      color, R1, color, R1;

# load the screen render
MOV      result.color, color;
END