Hello all,
I know that it's theoretically not possible for a fragment shader to affect pixel location. But does anyone know any hacks or work-arounds for this?
Can fragment shaders write to arbitrary locations in texture memory?
Basically what I'm asking is, if we think of the output of the rendering pass as a 2D array, is it possible for a fragment shader to write to any arbitrary location in that array?
Absolutely no way.
Imagine a super-duper chip which hardwires one pipe per pixel on your screen.
As soon as you are in that pipe, you're locked down to its final position.
The workaround would be to render a grid of GL_POINTS carefully adjusted to pixel centers (no FSAA!) and program the vertex pipeline to do the offset math.
If you have a texture dependent displacement in mind, you'd need a GeForce 6 using vertex textures.
Or, if your algorithm is able to store a unique inverse offsets per pixel ("From where should I read?") inside a floating point texture, this could be done with a dependent texture lookup in the second path of a fragment program.
Well, some limited fake-displacement seems to be possible.
On NVidia developer site http://developer.nvidia.com they're giving away some free chapters from the lastest GPU gems book. There's a chapter which explains per-fragment displacement mapping.
Well, it's not really much flexible as you may need but maybe you should take a look.
That is a displaced texture dependent read not moving the pixel. You can attempt to move texture fetches but ultimately the fragments you get are those from the primitive being rasterized. The net result may be a pretty good approximation of what you would have done with displaced pixels.
Thanks all, that's pretty much what I've been trying, but, as you all point out, those methods are messy and not very robust.
What about vertex programs, can they write to arbitrary locations, in texture memory or otherwise? I suspect that they can, but I'm really just getting started with shaders.
Carmack talks about screen space displacement mapping at the last QuakeCon.
You could project the offset vector from (steep) parallax or relief mapping into screen space. Then you've got the vector the current pixel should be moved. But how can you get the inverse offset ("From where should I read?")?
there is a boiling desert heat type effect that the playstation 2 seems to do very easily. ie. the scene is swimming globally.
i figure for non-ps2 hardware it would be achieved by rendering to a texture slightly larger than the screen and then after you are through writing the texture to the frame buffer while modulating the fragment reads.
for the ps2 though it seems to be a built in effect.
would it be worth while to have programmable frame buffer swapping units?
sincerely,
michael
God have mercy on the soul that wanted hard decimal points and pure ctor conversion in GLSL.
are you sure??? wouldn't this leave all sorts of holes? i couldn't imagine what kind of technique you could use to ensure that no holes would be created. and how do you assign proper depth values? or they talking about doing this before the fragment shader entirely in hardware?Originally posted by LarsMiddendorf:
Carmack talks about screen space displacement mapping at the last QuakeCon.
You could project the offset vector from (steep) parallax or relief mapping into screen space. Then you've got the vector the current pixel should be moved. But how can you get the inverse offset ("From where should I read?")?
God have mercy on the soul that wanted hard decimal points and pure ctor conversion in GLSL.
http://www.gamedev.net/community/for...opic_id=266373I have some interesting thoughts for being able to do
sort of a screen space displacement mapping, where we render different offsets into the screen and then
go back and render the scene warping your things as necessary for that, which would solve the T-junction
cracking problem that you get when using real displacement mapping across surfaces where the edges
don't necessarily line up.
This is an interesting idea. But how to get the correct offset if you only know how far the current pixel should be moved? Perhaps some kind of filtering or flow simulation?
It initially seems possible with image based approach but the question of where you read the image from is an embodiment of a complex problem, but perhaps not for the reasons assumed, you have an offset vector that could approximate the destination depending on how the assets are represented (you can chose to have the polygon hull enclose an entirely negatively offset displacement to the true surface for example). The real issue is resolution of offset fragment occlusion. Each sample gets a single read on the subsequent pass and a single offset value. Cracks are a non issue due to texture filtering, every fragment gets hit. The silhouette is described by alpha, the rgb image is actually an RGBA with the alpha term determining the final displaced silhouette.
So making this work is actually a question of rendering your offset vector map in a way that resolves the occluded offset issue. That may be possibly when rendering the offset vectors to screen space.
Without resolving occlusion in the offset vector map I think you could fix this with a depth map and multiple itterative image fetches almost like a search, it's no worse that the itteration through the map now for accurate tracing. It just does it in screen space.
Definitely doable I'd say, worth it? I dunno.. One problem would be discovered fragments on the same model. For example a body displacing in to reveal a hidden limb. Perhaps that could be fixed by a hull with all positive displacements but it's a second order effect. The magnitude of the displacement and required search is a performance limiting factor and a positively displaced hull has no starting vector for the displacement search.
Posting Permissions
