Output Image from Pixel Shader

Chris · 05-13-2010 02:57 PM

Hi,

1. Is it possible to output (or update) an image (say IMAGE_F32_4) from the pixel shader?

At the moment, i'm projecting my models texture to the screen, but because of the camera:

Code:

Cam.at = Vec(0, 0, 0);

Cam.dist = 1;

Cam.yaw = PI;

Cam.pitch=0;

I need to make it larger with:

Code:

Vec4 project = Project(outPos);

project.x *= 1.555; // spent ages getting this value, which seemed the most accurate

project.y *= 1.555;

outVtx = project;

Then doing:

Code:

Renderer.capture(Image,resX,resY,IMAGE_F32_4,IMAGE_2D,1,true);

- to get the texture. But this isn't accurate enough (some pixels near the seams are incorrectly alligned).

2. Is there a better way to do this?

Thank you,
Chris

**Esenthel** · 05-16-2010 10:47 AM

Hello,

Do you want to draw 3D or 2D graphics?
if 3d then you should adjust D.view* methods rather then modifying the projected vtx values.
like fov, square pixel, ...

Chris · 05-17-2010 12:12 PM

Hi,

Thanks for your reply. I want a 2D floating point image output.

I tried:

.viewForceSquarePixel(true).viewFov(DegToRad(51.5));

- this seems to be good code for replacing project.x *= 1.555; - but it's still not accurate enough. What I want to do is:

1. Load a model.
2. PIXEL SHADER: Project its UV texture to an IMAGE_F32_4 (+ make changes to the colours in shader code, using parameters from the vertex shader).
3. Perform some CPU operations on texture.

I'm encountering problems with getting the UV texture image from the pixel shader. Basically, the image isn't quite scaled correctly (from the camera), or in the right place. + I'm having to flip it manually on the CPU.

Can you help me to solve this? I can show you more of the code if its useful.

I'm a week over my deadline for this implementation now, + getting married this July which doesn't help!

Also, offtopic, I keep getting the following redirect alot of the time on this forum, both at home and in the lab: Here's the page source:


[an error occurred while processing this directive]

it occurs frequently when I try to reply etc.

**Esenthel** · 05-17-2010 04:12 PM

Hello,

I don't understand this:

Quote:2. PIXEL SHADER: Project its UV texture to an IMAGE_F32_4 (+ make changes to the colours in shader code, using parameters from the vertex shader).

What exactly do you want to achieve?
Can you post some screens?
For example the source data, and output data you wish to achieve?

Do you want to transform 3D coordinates, or 2D coordinates?
For 2D you don't need to use Project, you can set custom values you want for example:
outVtxPos=Vec4(x,y,0,1); // where x,y=-1..1 2D screen coordinates (speaking from my memory)

about the 500 server error, yes, unfortunately I receive it too, I've contacted the hosting provider, but they didn't fix it yet

Chris · 05-18-2010 09:47 AM

Hi & thank you again for your help.

Okay so on the pixel shader, i'm doing this:

Code:

outPos = Vec(outTex-0.5,1); // -0.5 centers the projected 2d UV mesh, else its in the top right.

Vec4 project = Project(outPos);

outVtx = project;

After clicking "Capture", i'm then doing a: Renderer.capture(Image,resX,resY,IMAGE_F32_4,IMAGE_2D,1,true); and then flipping this image vertically (as the mesh has flipped y texture coordinates).

Part of what i'm working on requires reconstructing the mesh from the image (where r/g/b represents x/y/z - hence me altering the colours earlier) - so in another shader program, I simply read the image input on the vertex shader for the mesh - this code works, as I had this near-enough working when I generated the projected 2d uv mesh on the CPU.

Here's the result, from the GPU:

As you can see, the vertex's aren't quite hitting the correct UV space (they nearly are, as you can make out the man). It's very close to being good, but you can see the edge vertex's (by the seams) are just hitting BLACK on the image.

So i'm wondering if I can generate this, somehow ignoring the cameras - e.g. something like outputting an image from the pixel shader, rather than doing a capture. Or whether you can help me get the right camera settings so I don't get these "near-miss" vertex/uv-space. I'll keep playing with the code you suggested in the last post.

**Esenthel** · 05-18-2010 10:28 AM

Hello,

I'm not sure if that's the problem but I think that you should have also the correct color at the "boundary/edges"

like attachment

you could try writing algorithm which duplicates nearest pixels to the "white areas" or do it manually in the photoshop.

Chris · 05-18-2010 10:43 AM

Thanks for the diagram smile

On the CPU, I just iterated each vertex, got its UV position, then coloured a 3x3 area around the uv vertex pos. This worked, but it was incredibly slow, and also did not fill the space between the vertex's (which the GPU does very well). Any ideas how to do this on the GPU?

(Or how to "grow the edges", like you described)

I just have, as with your skinning tutorial:

out DeferredSolidOutput output

~Chris

**Esenthel** · 05-18-2010 11:52 AM

I would get the GPU generated image, and then perform custom operation on it in CPU.
Iterate all white pixels and replace them with nearest non-white pixel.

Chris · 05-18-2010 12:15 PM

Hmmm. I tried this sort of thing on the CPU when trying to fill the space between the vertex's. Consider a 1024x1024 image, and an algorithm like this:

For each pixel:
Find-Non-White-Neighbour( pixel ) // returns ture if it finds a colour
Find-Non-White-Neighbour( pixel.LEFT ) else
Find-Non-White-Neighbour( pixel.RIGHT ) else
Find-Non-White-Neighbour( pixel.UP ) else
Find-Non-White-Neighbour( pixel.DOWN ) else
// perhaps LEFT-UP, RIGHT-UP ... etc cases too
terminate if found colour C, or if we have travelled further than threshold T:
colour pixel C;

- not exactly correct, but perhaps you get what I mean. You're going to have at least 1024 * 1024 * T^2 operations. To get perfect quality, using T=Image.x, this takes an extremely long time, for 2048x2048 it was taking >5 mins on an i7 920. I think my 8192x8192 test took something between 30-40mins.

I don't suppose you can you think of anything faster?
EDIT: If you zoomed the image about the center, say of a factor like 1.2, then merged the two images (if a pixel is alpha, get the value from the zoomed image). EDIT AGAIN: Oh, this won't work.
EDIT ANOTHER AGAIN: I just thought of another algorithm:

for each coloured pixel:
examine 3x3 neighbours
if neighbour is alpha, colour neighbour colour of pixel

repeat as many times as you wanna grow.

*tries*

In zBrush they have a seam overpaint function which doesn't take anywhere near this time. But I can't find any information on their algorithm yet.

Chris · 05-18-2010 05:31 PM

Okay, the kernel-method seam growing method "works", but the edges appear very slightly darker, even though i'm just copying colours from the image.

Here's the result:

So I use Magnifier.exe, and after examining the original shader output to the screen (not the captured image), I realised that the edges are actually slightly darker. Is this caused by some filter being applied to the output image from the renderer (I have a black background)?

(You have to look very closely to see this, also it appears that their are not enough colours (it should be floating point colour output), or that there is some kind of compression. Is it possible to get rid of this/improve the quality? (Perhaps that will solve it)

I'm currently just using:

D.mode(1050, 1050, false).sync(true).hpRt(true).viewForceSquarePixel(true);

with:

Renderer.capture(OCM,propertiesOCM.resX,propertiesOCM.resY,IMAGE_F32_4,IMAGE_2D,1,true); // e.g. you specify a resolution, does this perform anti-aliasing?

I'm so stuck with this. It's kinda back to the original question: can I get more quality out of the screen output, or just have it so pixel shaders make changes to an image? Why are edges darker?

Thanks,
Chris

Chris · 05-21-2010 02:39 PM

I found out why the edges were darker. It was the bloom shader, I needed:

D.mode(1050, 1050,false).sync(true).hpRt(true).ambPower(0.5).bloomScale(0);

This fixes the major artifacts. I now get this result:

Much better. I reckon the remaining seam artifacts are now caused by a loss of floating point quality between the shader output to the screen and the Renderer.capture function.

1. Can you confirm this.
2. Can I somehow get floating point accuracy image output from the GPU.

Sorry for the repeated posts, questions, and updates. I'm over my implementation deadline for this and am receiving quite a lot of stress for paper submission.

Chris

**Esenthel** · 05-21-2010 04:51 PM

Hello,

You may want to disable screen dithering (D.dither)
however the capturing is taken always from B8G8R8A8 screen format

Chris · 05-21-2010 05:22 PM

Hi,

Thanks. Is there any way that you improve the capture function, such that it can support floats, or provide more flexibility on the output of the pixel shader? Or is this beyond essential, e.g. something to do with the graphics pipeline?

Thanks.
Chris

**Esenthel** · 05-26-2010 06:24 PM

I can add this to my worklist, but it won't be available in the nearest future.

Chris · 05-26-2010 06:35 PM

Thanks; I really hope you can do it by the time I need to publish so I can show a good result esp in the video. Although I'm fine and happy for now, can just hide the seams in the pictures. Oh, and please don't forget the fur grass! (Although to me that's far less important; just for the game.. side project... wish I could get back to it though.)

Good luck with your feature list. I don't know anyone else who can simultaneously port a decent game engine to mac while coding destructible objects on their own.

Output Image from Pixel Shader
Author	Message