I have a number of points, say 512x512, & I want to copy some input texel values from a texture, to the exact same coordinates in the output color attachment, both sized 512x512. Something like copying texel values, but the catch is that I want to use points (& later lines, but that’s another story).
I use a shader and I override the ftransform() & texcoord generation with the following :
If I use a quad, from (0,0) to (1,1), it’s correct of course.
If I use points, I have errors.
I already adjust the gl_Vertex.xy by +(0.5 / textureSize) ( the texture attached has same width & height ), to compensate for the points’ positions,but still doesn’t work.
Only for the texture coordinate, I tried deducting the above adjustment, but still doesn’t work.
Am I doing something terribly wrong?? ( besides covering a large buffer with some hundred thousand points )
Point size is the same (1.0) & point_smooth is disabled. All the fetches also use GL_NEAREST.
The error is the following :
I have 3 functions.
One updates the ‘active’ texels.
Another sets some values & makes ‘active’ some other texels.
And the last one renders all the ‘active’ texels.
And you can replace ‘texels’ with particles to make sense.
The problem is that when rendering, in the beggining, some particles are rendered, whose values are wrong, making me believe that somewhere in the first 2 procedures, I actually write instead of, say, 123 - 514, but to 124 - 515.
The debugging I believe isn’t THAT simple, because the error variables are a bit many
I would upload an image if it made any sense, but apparently doesn’t.
What I meant by easy debugging is that you can e.g. try to output intermediate results such as the texture coordinates to a floating point FBO and check whether the coordinates for each pixel are what you expect them to be.
Thanks for the clarification, I realized that you meant that soon after I answered The texcoords seem to be correct (for texture rectangle) [0.5, textureSize-0.5], so the problem probably lies elsewhere, hmm…
Try to replace 2D texture with GL_texture_rectangle_arb.
It has easier pixel center texture coordinates.
Like 0 is first pixel, n-1 is the last pixel in row/column.
For 2D it is not that easy (like texture borders, …)
I did that mfort, thanks for the suggestion anyway, coordinates like 0.00012354432 didn’t help at all And I never use texture borders anyway. I’m still baffled a bit about the difference of GL_CLAMP / GL_CLAMP_TO_EDGE though.
GL_CLAMP clamps the texture coordinates to [0.0,1.0], so on the edges of the textures it samples half the texture edge and half the border color (0.25/0.75 for the corners). GL_CLAMP_TO_EDGE makes sure you only sample from the texture edge and not the border color.
Yes, I’ve read that, but if you don’t specify borders at all??
Anyway I’m starting to think that the problem might really lie elsewhere, cause I switched the order of operations & now this problem is fixed, but I get some strange ‘flashes’ when blending is on.
EDIT : I use 920,000 points to generate a total of 11,040,000 vertices through a gs, if I go for lower, it seems that the flashes go away, could this possibly a hw limit problem?
There’s a limit of how many vertices a GS may output in one go. From NV_geometry_shader4, “Geometry Shader outputs” section:
A geometry shader is limited in the number of vertices it may emit per invocation. The maximum number of vertices a geometry shader can possibly emit needs to be set as a parameter of the program object that contains the geometry shader. To do so, call ProgramParameteriEXT with <pname> set to GOMETRY_VERTICES_OUT_EXT and <value> set to the maximum number of vertices the geometry shader will emit in one invocation.
[…]
If a geometry shader, in one invocation, emits more vertices than the value GEOMETRY_VERTICES_OUT_EXT, these emits may have no effect.
@Nico
Thanks once more for the final ‘fine’ point in the difference
@HexCat
I hope I won’t sound too naive, but what difference has e.g. texelFetch2DRect from texture2DRect, except from the int / float lookup? Assuming the samplerRect has nearest as filtering.
@Lord crc
I’m aware of the limitation, and I only output 12 vertices / 12 varyings per point (out of 1024), as 4 triangles. And I’ve also messed with it enough to find this sweet spot at least for my app, and also realized that a variable output count REALLY hurts performance…
)
The texcoords seem to be correct (for texture rectangle) [0.5, textureSize-0.5], so the problem probably lies elsewhere, hmm…