# Tag Info

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 ...

9

After more analysis, the TL;DR here is that, yes, the slowdown is due to memory locality, and yes the pixel order is to blame. More interestingly, by writing the shader differently, we can greatly surpass the fragment shader's performance—though we obviously shouldn't rely on being able to do that regularly. First, to expand on the analysis: the best way ...

9

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)$). ...

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.

6

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 ...

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

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

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 ...

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 ...

4

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....

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

1) Scale the texture coordinates from [0,1]x[0,1] -> [0,3]x[0,3]. It works with higher integer scales as well. This creates an imaginary 3x3 tiles grid. st *= 3.; 2) Split the upscaled texture coordinates into the integer part and its float reminder. vec2 i_st = floor(st); //the tile coords of the fragment - an integer pair {0,1,2}x{0,1,2} vec2 f_st = ...

3

You tile idea seems to be a good one to cut down on local complexity. You can't reasonably evaluate every primitive everywhere. Not if you want good performance anyway. So you need a simplified version for each tile, where you remove elements which have insignificant contribution. This is an interesting problem of its own. A simple version of this would be ...

3

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 ...

3

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

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 ...

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

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 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 ...

2

The rasterizer determines, which pixel is rendered depending on vertex positions that come out of the vertex shader. For each rasterized pixel, the rasterizer knows where it lies inside the triangle formed by its three positions. With the known position inside the triangle, the rasterizer can also interpolate the vertex values for each pixel. So it also ...

2

Everything in this code functions as intended, until I try to translate the entire grid (grid lines) to the center of the screen by adding v_Resolution.x / 2 to uv.x. Not sure what your intention is here since the Shadertoy example you referenced generates an infinite grid. So maybe you can clarify that. However, I think I can help you with this problem: .....

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 ...

1

Yes you can. There are basically two approaches: You draw everything to a framebuffer object. Then you apply image processing fragment shaders to resulting texture of the previous draw call, where the shaders take the pervious texture with a sampler. or if you have a particular image and you would like to have more control on the numeric precision, the ...

1

Here is a (mostly) minimal version of an SDF for a line segment using a signed distance field as suggested in the comments. I take no credit for this code, it is your function pieced together with IQ's SDF function done in the style you listed above. Be sure to go to IQ's website, it is one of the best learning resource out there for this material. Though it ...

1

I'm assuming that you don't know how many objects there will be or have any way to index them until the image processing operations are completed, i.e. you have some final pass that determines for each pixel "do I want to put an object here, or no". OpenGL ES 2.0 is pretty limiting. There may be no better way to do this than what you described: ...

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. ...

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