Wetness

#41 Found it.

#42 I finaly have a fullscreen wetness shader working (see video)

I'm now converting it to object space, might need some help with it, but, what it does/has, you can set the amount of warp (normal map),
it runs down screen, you can set speed, you can fade it out (time based).
if I can get it onto objects, we may have a wetness shader.
the original shader was written for xna, and was easy enough to port to T3D.

#43 @Deepscratch

That is a very nice looking effect. I "think" it's a little bit different than what we need to do for the wetness effect. I'd still like to see the implementation.

#44 I'm going to go out on a limb (and man I hope somebody proves me wrong) but I think that this feature is going to be best implemented with some data added to the pre-pass.

That "Blood Pooling" paper is awesome, I don't think I have seen a better description of harvesting the gravity vector. The author of the paper suggests storing the XY gravity vector in a render target, what I would try is storing an angle. That's half the storage space, for the same value. It will cost you a trig function to decode, but on the "space vs time" balance, we really want to conserve space.

What I'd try doing is editing the GBufferConditioner to only store 16 bits of depth for a 64-bit G-buffer, instead of 32-bits of depth. Use the channel you save to store that angle. Extending the pre-pass is easier than it sounds, but there aren't really any examples of it.

My gut tells me this should be able to be computed in screen space, but the problem with screen-space effects is that you often find yourself with 95% of the data you need for an effect (see: SSAO and SSGI) but never quite all of it.

#45 Since this is a generalized flow direction and not a moonshot. I can't see that anything is lost by using angles. The goal after all is to spread the heightmap out to a uniform depth in the appropriate direction by identifying donors and the appropriate adjacent recipients.

Edit - WOW, Thats a lot of trig functions! (5/pixel)?

#46 @Pat

Wouldn't we have to store two angles? One in the X and one in the Y? If we limited it to the Y axis (which I "think" is what you are saying) wouldn't everything flow from top to bottom on the screen, just varying in speed by angle? It would seem we would need to account for variation both down and across the screen.

The biggest question I have about doing this at screen space is how we transform the gravity vector from world space to tangent space. Do you have any thoughts on that?

I'm currently working on this at the Custom Material level, which is a bit less complex than screen space. Once I get something there I'll try a post effect.

Edit*** nevermind the edit... that wouldn't work.

#47 Joshua,
you on messenger?

#48 Deepscratch,

Which messenger? MSN? I have an account but I'm at work so I sort of sneek time during the day to think about this stuff. If you want to add me on MSN messenger I'm (actually I'd rather not broadcast email addresses). Is there a good way to do this?

#49 send me your msn to "snotporridge@yahoo.com", its my garbage account for, well, everything, I'll add you and message you.

#50 We don't have the info to get into tangent space (or object space) during the post process because we are drawing a full screen quad. We can get world space, but each object has its own object->world transform, and each vertex has its own tangent->object transform.

We only need 1 angle (provided this vector is direction only, not magnitude) which is the rotation from "12 o'clock". All water doesn't flow top->bottom for all rotations of the camera.

I would not work on custom material, but instead alter the pre-pass to store this vector. This is a value which is needed on a per-pixel basis, and the information you need to calculate it (tangent space matrix) is stored in the vertex stream. This means that you must be drawing the world geometry in order to compute it. This is why I suggest computing in the pre-pass and storing.

#51 That's interesting. I didn't think of one angle on a 2d surface.

Quote:We can get world space, but each object has its own object->world transform, and each vertex has its own tangent->object transform.

Does this mean we have access to the object->world and tangent->object transforms in the post effect?

If so that removes some obstacles I thought would be there.

The thing that has me a little stumped at the moment is dealing with screen space. When dealing with objects you need to find the contributions of gravity and the normal in tangent space. As the paper says, transposing the world matrix gives you an easy way to find the gravity vector in relation to the object and then transforming that to tangent space gives you the ability to take the normal to the surface into account.

Perhaps we would need to transform worldspace normal and gravity into view space? Could we then sum them, and project the result to get screen space vector?

I could be way off though.

Grah I wish I didn't have to work so I could try this.

#52 Or, what if we ignore all of that and do what you originally suggested to calculate the downhill vector and then transformed that vector into view space?

I think not having that transformation might have been what was causing our earlier problems.

#53 Yeah, I think this is the case of we have almost the data we need to compute this in screen space, but not exactly all of it.

#54 If the world->view transform matrix isn't available in the engine, we can reconstruct it using the eye and up vectors (the same way downhill is computed).

If we multiply the "downhill" vector by that matrix we will get the vector in view space. I "think" if we take the x,y coordinates of that, we will have a correct screen space direction for downhill at that point.

#55 I dont think you need a matrix operation - given the camera angle and the gravity map angle then all you need is the sum of the angles to get the flow direction relative to screen space.

#56 I don't think you can construct a gravity map in screen space the way it was described in the NVIDIA paper.

What I'm describing above is the creation of the gravity map.

#57 Here's the result of my gravity mapping. The blue is every point that has a negative z component of the gravity vector. That, to me, means the precip texture should scroll "down" it.

I tried mapping this vector to a UV adjustment and for some reason it still doesn't work every time. like 5% of the ones that should be down are going up.

#58 I think I give up on this as a post effect.

#59 @Deepscratch

That is a really cool exit-water effect, better than the gui idea. Also sweet kitten video!

#60 Well I just spent about three more hours on it. There's something I fundamentally don't understand about post effect texture scrolling. Good luck with this one.

When I modified the UV coords with a simple (0,-1) * accumTime the entire texture scrolled down, as expected.

When I use calculated uv coords the texture scrolls away from me, regardless of whether or not the v modification is negative. That really blows my mind.

Another thing that freaks me out is when I clamp my U modification to 0 and use the calculated V. I get a weird banding effect. Vertical bands appear on the screen. Some of these bands scroll the texture, some don't.