Water Renders Over Particles

40+ Duplicate of MC-1379, please use the search function to see if your bug has already been submitted. Currently over 58% of tickets are being closed as duplicate.

I had this issue on 1.6, even 1.5 i think. I don't understand why it cant be fixed. Its just an opengl layer issue. The water is rendered at a higher layer than the particles, that is why the water renders on top, the particles do not get transparent, they are simply rendered under the water (the water is transparent thus letting only some of the visibility out)

This is also the same with the hit-box which is small to notice, but very unnatural and unrealistic. Just make sure the particles are above the clouds and water layers. This issue is almost a year old, and it is really annoying.

It would be very nice to see this fixed in the next snapshot. When Jeb took over that is when i noticed it. It never happened before, im assuming it may have changed when the new Shaders, and other render-able objects, Jeb must have accidentally mixed a layer.

@Daniel Mills:
Stop spamming your comments all over this site.
First and last warning.

@Daniel Mills:
Your explanation is born of ignorance and has very little basis in fact. Somehow I don't think you know anything about how rendering in OpenGL actually works, or rendering in general. There is no concept of "layers" in OpenGL, I would love to know where you got this entirely wrong notion.

I created a framebuffer for layered rendering in c++ to explain what I mean. like this

GLuint buffer;
glGenFramebuffers(1,&buffer);
glBindFramebuffer(GL_FRAMEBUFFER,buffer);

glFramebufferTexture(GL_FRAMEBUFFER,GL_COLOR_ATTACHMENT0,textures[0],0);

GLenum blub[] = {GL_COLOR_ATTACHMENT0};

glDrawBuffers(1,blub);

where textures[0] is a 3D texture for layered rendering. This layers the textures onto the attatchment (frame buffer)

When you aren't using pixel accelerated graphics (not using open gl, just from scratch) you usually run into issues with clipping. Its mainly objects behind other objects popping through.

Then I create and fill a buffer with vertex data for the points like this:

vector<vec2> points;
points.push_back(vec2(0.0f,0.0f)); //should draw in the middle
points.push_back(vec2(0.5f,0.5f)); //3/4th in each direction
points.push_back(vec2(-0.5f,-0.5f)); //opposite of second point
points.push_back(vec2(-0.95f,-0.95f)); //first texel on the bottom left

glGenBuffers(1,&result);

glBindBuffer(GL_ARRAY_BUFFER,result);
glBufferData(GL_ARRAY_BUFFER,points.size()*2*sizeof(float),&points[0],GL_STATIC_DRAW);
where vec2 is the vec2 floating point vector class provided by GLM.

Then I render it by doing this:

glViewport(0,0,textureSizeX,textureSizeY);
glBindFramebuffer(buffer);
glUseProgram(shader);
glBindBuffer(GL_ARRAY_BUFFER,_pointbuffer);
glEnableVertexAttribArray(0);
glVertexAttribPointer(0,2,GL_FLOAT,GL_FALSE,0,0);
glDrawArrays(GL_POINTS,0,4);
where shader is a shader constructed from vertex, geometry and fragment shaders. It compiles fine without warnings. Depth and stencil testing are disabled. textureSizeX and textureSizeY are the width and height of the 3D texture.

Anyways my point is that layering is not done in three dimensions it is done after it is rastered onto the screen

Believe what you want.

That's not how most actual game engines work. Blitting a screen-sized buffer onto the screen is pretty costly in terms of overdraw, especially with blending turned on, and there are a lot of people who are already complaining about performance issues.

As an aside, around 5% of our userbase still only supports fixed-function GL, and the majority of that 5% also don't support the ARB necessary for framebuffer objects. From a pragmatic standpoint, I'm not willing to shut out 500,000 of our paid users to fix a visual bug.

This proposal also won't fix the issue. All particles are currently rendered behind any translucent geometry due to draw order, but your proposal makes all particles render in front of any translucent geometry. It solves the immediate problem of particles rendering behind water, but introduces other problems. I've tried it before. If I implemented this fix, all of your torches' particles would render in front of any stained glass that you may have. Since you mention water, consider the case of torches in a room built on the bottom of the ocean: The particles would render in front of the water when looking at the room through the surface.

There is no good solution that involves batching all particles either before or after translucent geometry, layers or no. I've been down this path already, and have seen that no matter when the particles are rendered - before or after translucent geometry - it won't be 100% correct in all cases. The correct fix, which I plan to eventually get around to, is going to be to group off particle effects in the same fashion as chunk geometry, render the particle effects at the same time as the chunk geometry, then sort the particle geometry at the same time as the translucent geometry is sorted. As you're probably aware, this is a rather painful change, and I have other rendering-related tasks on my plate right now that are more pressing than a visual bug.

I appreciate the fact that you're trying to help, just trust me when I say that there is no easy solution to this particular problem.

this bug is still in the game in 1.14, and it always has been, i don't know why or who tag it as solved