OpenSauce Post Processing

**Siliconmaster** · August 13th, 2009 10:01 PM

Well shit. That would be insane.

**Roostervier** · August 13th, 2009 10:09 PM

wow, great work FireScythe

**Con** · August 14th, 2009 08:00 PM

What exactly are we looking at in the second picture, and how can that aid in motion blur? Also, you should be able to do the cell-shaded look with edge finding on that depth map. Is there any way to fix the planes showing up for sprites?

**FireScythe** · August 15th, 2009 05:00 AM

The second picture shows the vertex/face position in screenspace (Although the full range can't be shown in the 32bit format we see), so if a copy of the previous frames position data is kept, we can get how much an object has moved, and blur it accordingly....in theory :P.

I'm working on the transparent textures. Trees and such should be fine, but I still need to figure out whether I can do particles.

**Con** · August 15th, 2009 11:01 AM

If an object is moving across the screen, such as a warthog driving by, then wouldn't the position data between the front of the hog in one frame and the back of the hog in the next be almost the same? The only major change would come from the front and back of the hog where it's compared with the background. I'm not sure how you would pull objects out of the scene. On the plus side, that new SSDO method works using depth and position data doesn't it?

**Masterz1337** · August 15th, 2009 11:26 AM

Amazing as always, can't wait to use this on OS2

**FireScythe** · August 18th, 2009 03:37 PM

Originally Posted by Con

If an object is moving across the screen, such as a warthog driving by, then wouldn't the position data between the front of the hog in one frame and the back of the hog in the next be almost the same? The only major change would come from the front and back of the hog where it's compared with the background. I'm not sure how you would pull objects out of the scene. On the plus side, that new SSDO method works using depth and position data doesn't it?

Yep, this seems to be the problem iv'e been coming up against. Seems the way I thought it was implemented isn't quite right. I initially thought I could compare the positions of two frames at each pixel, but as you say, doing this means the difference between frames would be greatest at the boundry of a moving object and wouldn't give a per object velocity.

What I actually need to do is get the velocity of each vertex when the objects are initially drawn. However I can't think of a feasible way to do this without some major editing of vertex shaders and the like. So an accumulation buffer motion blur will have to do. Position information will still be available for other post process usage though

.

**Donut** · August 18th, 2009 06:24 PM

Originally Posted by FireScythe

Plus as a bonus I might be able to seperate the hud so that post processes don't affect it.

i have open sauce d3d9.dlls for limited's 3rd person/fov app and your post processing app. some weapon's zoom turns the whole screen black. is that your app or limited's app?

also i dont know if anyone posted this or anything but the whole screen dims when you open the chat box. separating hud elements would be great

**FireScythe** · August 18th, 2009 06:39 PM

I would say its the 3rd person extension doing that as it has code that changes its behaviour when zoomed.

**W1zard** · August 19th, 2009 01:31 AM

Originally Posted by FireScythe

Indeed, Depth of Field should be possible, but also with the screen space position data (second pic) I 'might' be able to do per pixel motion blur. Plus as a bonus I might be able to seperate the hud so that post processes don't affect it.

Big cooky if you can actually get the HUD unaffected =O

Keep it up, you're legend for making an old engine like this look great