numeric values from colors (very unique problem)

Started by
3 comments, last by TheKrust 16 years, 7 months ago
I'm having a seriously hard time tryig to figure this one out... is there a way to convert color values to plain numbers in pixel shaders (2.0)? Here's my situation. I have a blurring algorithem that needs one number to tell it how heavy to blur the scene. I want different parts of the screen to blur to different strengths. (depth of feild effect). what I have done is lined up 2 textures side-by-side, one being the regular scene, and the other being a pure black and white version that makes basic geometry lighter or darker based of how far away they are on the screen (this is measured by a vertex fog). In the end, the two are compared by a pixel shader, and the regular texture is blurred based on how dark the areas of the other texture is. this method works except for one thing. When I pass the pixel color into the loop, for (int i =0; i < pixel.r * 8; i++) {blur texture} the color information from the black and white texture is INCLUDED in the final output. It looks absolutley awful. Is there a way to just take the numeric value of a pixel color without it assuming I want to actually USE the color for something? [Edited by - TheKrust on October 1, 2007 7:13:53 PM]
---------------------------------------- There's a steering wheel in my pants and it's drivin me nuts
Advertisement
Have you looked at the PostProcess sample in the SDK? That has an implementation of a blurring effect and might give you some ideas about how to implement yours.

There should be no problem with using a value from another texture without it directly contributing to the actual output. Posting a little more of your HLSL code might help us to explain things...

hth
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

I'll post the HLSL, as soon as I get a chance. I have a feeling the problem is related to my actual algorythem. I'm comparing "i" to the color value, and then passing i directly into the x-y coordinates. Then applying the x-y coordinates to the output color... it doesn't seem like the color would carry over after all that but evidently it does.

btw, I've never seen the "post process" sample, but almost every DoF method I've seen just blurs the textures, but leaves the hard geometry behind. That can't work for what I'm doing (plus I hate how it looks)
---------------------------------------- There's a steering wheel in my pants and it's drivin me nuts
I agree. Need to see more of your code where you retrieve the texture colors and modify them.

On another note... isn't pixel.r a float value between 0 and 1, thereby making your integer loop only execute once?

~ C
thanks for pointing that out, but that's not the real code. I times it by 8 so. the higher the number, the more passes it makes. (0.3 * 8) (0.7 * 8) ect...
---------------------------------------- There's a steering wheel in my pants and it's drivin me nuts

This topic is closed to new replies.

Advertisement