Point as texture with depth test enabled

Hi everybody,

I’m trying to create a grid of points as textures following the pointAsTexture Example in the examples/gl folder.

I need alpha blending and depth test enalbed to place background points behind foreground points. As I enable the depth test (in the OF example is disabled) I get this error (texture is a png with alpha channel). Depending on the degree of rotation, the alpa channel turn to black.

I read that I should sort my vertices/points on their distance from the camera, but I get no advantage.

I created a small example where you can rotate the grid by moving the mouse on the X axe and change some other viewing parameters.

pointsAsTexturesDepthTest.zip

I hope this colud be usefull. Thanks!!!

I might be of no use here, but I think I’ve seen something like this before when drawing ofImages with alpha channels one at a time. I don’t remember exactly why I ended up with what I have, but my working code does this:

ofEnableBlendMode(ofBlendMode::OF_BLENDMODE_ADD);
(*itShip)->pMainLatPortThrust->Image.draw(...);
ofEnableBlendMode(ofBlendMode::OF_BLENDMODE_ALPHA);

each time it draws an image. (But I think maybe I did that just so that I didn’t create side-effects on other later draws of other things.)

I also notice that in your resulting image, some of your points seem to be blending, and others not. Is it possible that some of your images are different from the others (either in the image data itself, or in the way you have the object set up)?

alpha blending has issues with depth testing – this is a common problem with computer graphics generally and there’s a lot of research / discussion in the field of OIT (order independent transparency – Order-independent transparency - Wikipedia). Usually the best solution is use a blend mode as @Drazinut suggests and turn off depth testing, or to simply sort your objects from back to front to draw them in the right order.

The issue, if I can explain it right, is that depth testing involves dropping fragments if they are “behind” the current fragment in terms of “depth”. When you drop fragments, you don’t get the bending right.

The circles comes from the same texture. The effect you see depends on the degree of rotation of the entire grid, you can see if you launch the application. The grid should be 1024x0124 so I should draw point by point, changing blend mode at each point. It could slow down the frame rate.

Anyway thanks a lot for your suggestion I’ll make a try.

Thanks so much Zach. I was trying just to create a large grid of points that could be nicer than a grid of simple glPoints without no texture. I tried to sort the object by this way:

bool sortPoints(glm::vec3 p0, glm::vec3 p1) { return (p0.z > p1.z); }


void ofApp::setup() {
	
	ofPlanePrimitive plane;
	size = 1024;
	plane.set(size, size, 12, 12);
	planeMesh = plane.getMesh();
	ofDisableArbTex();
	ofLoadImage(pointsTexture,"dot.png");
	ofEnableArbTex();
}

void ofApp::draw() {

	...

	ofEnableDepthTest();
	vector<glm::vec3> & v = planeMesh.getVertices();
	std::sort(v.begin(), v.end(), sortPoints); 
	ofDisableArbTex();
	ofEnablePointSprites();
	pointsTexture.bind();
	planeMesh.draw(OF_MESH_POINTS);
	pointsTexture.unbind();
	ofDisablePointSprites();
	ofEnableArbTex();
}

Maybe there is something wrong here but I get no differece. The real problem is “how to draw nice points?” It’s something similar to the well know issue about fat lines that someone in the forum called back few days ago. That is " how to draw primitve graphic objects with any size looking nice?" With triangles, rectangles, circles is ok, with lines and points is hard, especially if you need plenty of these objects.

it’s hard to see how the sorting in your code is working, but you are just sorting in z, I think you may need to sort them relative to their distance from the camera after any translations you are performing… If you want to, feel free to upload a sample project.

tbh, I don’t think this problem you are discussing is similar to the thick lines – this is really about depth testing and transparency which is a specific and well known problem in computer graphics. I’ve had this problem for example with typography (https://apps.apple.com/us/app/weird-type/id1352785248) where in some cases it would be really performant to use textures for type, but if you can’t control the blend mode, you get issues with depth testing and transparency. I usually use geometric type instead of textures for this reason.

Thanks so much Zach, you touched the problem. I do not consider rotations on sorting, that is the reason why the issue come out with certain rotations and not with others. This is the zip

You’are right also with the second point, but was just telling how these apparently simple operations (drawing a point or drawing a line) becomes tricky under certain conditions. I use a lot of simple geometry for my shows but it’s always hard to make them appear nice as the audience expects.

I am almost sure that sorting in the proper way will fix the code, but I’am also afraid that doing this kind of calculation for each vertex (I should manage a 1024x0124 points grid) will be time consuming. I think I need to come back to draw geometric points instead of texture, as you do.

thanks again.

For those want to test performance between geometric points and texture points, I updated my small app on Git Hub click here