5

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


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


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


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


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