11

What you're talking about is commonly called "dependent texture reads" in the mobile development community. It's an implementation detail of certain hardware, and therefore it really depends on the GPU as to whether or not it has any performance implications. Typically it's something you see brought up for PowerVR GPU's in Apple hardware, since it was ...


7

Without seeing the error message I can't be sure but I think it's failing on the 1 being int instead of a float. float inv_coord = v_coord - 1.0; There is a simpler method, you can do 1.0 - v_coord and do away with the abs.


7

It has been suggested in comments repeatedly, but noone felt the need to give a proper answer, so for the sake of completeness, a straight-forward and common solution to this problem might be to use a texture as lookup table, specifically a 1D texture that contains all the values of your function for the possible input range (i.e. $[0,360)$ / $[0,2\pi)$). ...


6

It works almost exactly the same way as vertex shader inputs. In vertex shaders, you have inputs. And these inputs represent vertex attribute indices, the numbers you pass to glVertexAttribPointer and glEnableVertexAttribArray and so forth. You set up which input pulls from which attribute. In GLSL 3.30, you use this syntax: layout(location = 2) in color; ...


5

I don't think your approach is viable for a variety of reasons. a GPU is heavily cache-dependent for performance. Pulling the same pixels over and over will just measure how fast a cache hit is. Sampling random pixels will only measure a cache miss. Neither are useful statistics. each texture2d call will pull in multiple pixels to leverage that, in a ...


5

Noise functions are definitely your friend here—FBM would be one good candidate. You’re right that it can look too uniform on its own, but if you blend multiple layers of it together, using different speeds / directions for each and maybe distorting their domains a bit, you should be able to get very close to the look of that footage. There’s lots of clever ...


4

It depends. On a desktop, if the Gaussian function is always called with the same arguments, the shader compiler will probably optimize it so it's evaluated only once. On a mobile platform though, the compiler has less time to do optimizations and might miss it. Either way, you can confirm by looking at the generated assembly. Note that Aras Pranckevičius ...


4

When depth testing is enabled, the testing occurs after the fragment shader executes. The procedure is relatively simple (and spelled out pretty well here): Get depth of fragment Test against depth buffer Discard if it fails Early-z discard is when a rasterizer discards a fragment before a fragment shader runs because it's clear early on that it won't pass ...


4

There is good glsl source of noise (simplex noise) online to make real time noise. In addition to this, to make effect of moving fog/smoke like in this video you can make 3D FBM function. This is my function: float default3DFbm(vec3 P, float frequency, float lacunarity, int octaves, float addition) { float t = 0.0f; float amplitude = 1.0; float ...


3

You are doing completely different things in Matlab than in your Fragment Shaders. In Matlab you are generating bunch of points that can be drawn anywhere on the screen and then you are transforming them. This would be loose equivalent of your Matlab code in Fragment Shader: #define ARRAY_SIZE 256 void main() { vec2 st = gl_FragCoord.xy / u_resolution....


3

You're getting a cross shape in the output because in your loop, you're counting pixels on the center row and column multiple times. For example the pixel at (0, 0) offset will be counted on every iteration of the inner loop, so 100 times. Similarly, (±i, 0) and (0, ±i) will be counted on every iteration of the inner loop, so 10 times for each value of ...


3

Yes, ray differentials are the way to go. The Paper by Igehy introduces them for the use case of filtered texture lookups. When generating the primary rays, you initialise the differentials to reflect the pixel footprint. As the ray progresses through the scene, you update the differentials at every bounce. When it comes to a texture lookup, you need to ...


2

You seem to be using additive blending against its purpose. Additive blending is supposed to represent light from multiple sources being combined. It is not physically possible for one source of light to eclipse another. Furthermore, even if you hack an alpha of exactly 1 to mean "opaque", you will get a strange circumstance where an alpha of 0.99 is quite ...


2

I think the most efficient way might be either return float(shadowValue > shadowTexZ); or return step(shadowTexZ, shadowValue);


2

The shader compiler will very likely perform common-subexpression consolidation, and compute that function once, and reuse it each time it appears in the shader. You might think that, since deviationScale and all the other args are constants, it is possible it gets constant-folded entirely and never executes at runtime at all. But this is incorrect, as ...


2

It doesn’t matter that it’s a point light; the 1/π normalization factor is what’s causing your surface to be 1/π as bright as you’d like it to be. You can either up your light intensity so the maximum brightness is π or just get rid of the normalization factor. There’s a good article with some notes about this and how it interacts with more complex lighting ...


2

If you are using Processing the variable lightPosition must be declared as a vec4, otherwise it won't be passed in, and will be always 0. Then your diffuse computation is not correct, the dot product we want it's between the normal and the light direction: float LdotN = max(0, dot(normalizedPos,transformedNormal)); I'm not sure about the uniform ...


2

since that is the case for window-space coordinates in the vertex stage. There are no "window-space coordinates in the vertex stage". Or at least, not in the vertex shader. Window-space is not relative to the viewport; it's relative to the window (or framebuffer, in this case). The viewport transform is used to convert from NDC-coordinates (which are ...


2

It looks like you're drawing with pre-multiplied alpha. This means that the red, green, and blue channels have been multiplied by the alpha channel. So your shader should look more like this: precision mediump float; uniform sampler2D uSampler; varying vec2 vTextureCoord; void main() { vec4 originalColor = texture2D(uSampler, vTextureCoord); vec4 ...


1

So, I figured it out. While UAV will be necessary when I start manipulating data in Compute Shaders, for the time being, SRV works fine provided the resource is read-only from the fragment shader. The two big problems were Creating an ImageTexture that was receiving the data. Note that the data copy was occurring just fine, but the texture was never used ...


1

What you do is shifting the texture coordinates. This will move the texture on your polygon, and depending on your settings it will handle the borders which are now probably wrong. however, this will not move your polygon - if you want to move an entire object, you should not do that within the shader. you do that via modifying your model matrix. I assume ...


1

It would be helpful if you posted some more information about what you're trying to do (rather than problem links) and some screenshots of what is actually happening. Being here I basically see "My code doesn't work, fix it.", which is not motivating to answer your question... That being said, you calculate an offset for reading out from your texture. ...


1

Though I have never used them myself OpenGL in modern versions gives you something called "Shader Storage Buffer Object" These are buffers that you can fill with your data. They are guaranteed to be able to hold up to 16 MB of data and most implementations seem to have no problem with them taking up the whole GRAM. This feature is core since OpenGL version ...


Only top voted, non community-wiki answers of a minimum length are eligible