Say I was writing a program that rendered a full screen quad using a texture of the exact size of the full screen quad. So each texel represented a pixel exactly.
There’s no way, using a fragment shader, even using multipass, that I can transfer any value from one pixel to another, is there (without using vertex buffers/shaders)?
I could not implement a particle system in the fragment shader alone, could I?
You can only read from arbitary pixels, but not write to arbitary pixels - so I know I can move data from a neighbour into the current pixel, but not an arbitary pixel.
There’s no twist of logic I’m missing here, is there? I just need to check.
You’re right; it is not possible to specifically write to a particular pixel on the screen. A fragment shader is responsible for computing the value at the (sub)pixel specified by the rasterizer.
You can read from another pixel and write your own pixel. However, it would result in undefined behavior. There is no definition of the order in which pixels are drawn. In fact, many pixels are usually sent through the pipeline at the same time. So you may sample the framebuffer at a pixel that has not yet been drawn for this frame. Shaders are designed for parallel operations on individual, and separate, pixels. The result of one pixel during any particular pass should not have any effect on another pixel during the same pass.
-Raystonn
Thought so.
raystonn, I wasn’t talking about the framebuffer at all - just double buffered textures.
Ah well.
If your domains allow, you can of course read from any pixel you like. If you have a function which maps a->b and need the function that maps b to a and use that to pull the data from a. I’m sure there are mathematical terms for this but it’s a long time since I sat maths!
Well I wanted to add the velocity onto a position and write into the new pixel - basically do a particle system using just a fragment shader (or number of fragment shaders)…but there’s no way the destination pixel can figure out that.
You can just use the velocity at the target and subtract to get the source particle.
I know intuitively this seems wrong, but it’s an approximation either way, just the other way round. Instead of integrating the motion with a linear approximation using the tanget at the source, you use the tanget at the target.
Depending on the nature of your particle system, this might even produce a result that’s numerically more stable than the standard forward integration.
yes i recently implemented this a week ago in the menus in my game, it has snow that falls on them (like xsnow) it looks a bit cheesy though so i might remove it.
u have another texture with the velocity offset vectors.
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.