Open Cheesse opened 8 years ago
Are you using the OpenGL or Direct3D9 build?
Secondly, are these lines always at the same coordinates (in terms of their position on a block face), or do they vary when you move around?
I've only tested this with the D3D build, and these lines remain only on the edges of the blocks, never between edges. However, their visibility might change with distance and angle.
More importantly, does it also occur with other texture packs? (Such as the default)
I remember a while ago that when I tested an AMD card it had issue with non power of two textures similar to this (OpenGL build), though I don't have access to that computer anymore.
This issue occurs in the D3D and OpenGL builds of the client and with all texture packs that I've used, which all include 16x16 textures for each block. I would also like to note that I got very noticeable FPS issues in the OpenGL build. These strange lines also appear on some edges of player models.
amd's earlier opengl support is questionable, which might explain the performance issues.
On Sun, Oct 11, 2015, 1:07 PM Cheesse notifications@github.com wrote:
This issue occurs throughout all builds of the client and all texturepacks. I would also like to note that I got very noticeable FPS issues in the OpenGL build.
— Reply to this email directly or view it on GitHub https://github.com/UnknownShadow200/ClassicalSharp/issues/99#issuecomment-147240908 .
@Cheesse This sounds a lot like texture bleeding of some sort to me. If you place a red wool block, do you get pink(block below red wool in texture atlas) or orange(block to right of red wool in texture atlas) artifacts on the border of the block?
What you describe doesn't happen, but I noticed that these aren't lines actually being drawn, these are open spaces that I can actually see through.
In these examples I have a red block with obsidian surrounding it, and I have a few cyan blocks behind this wall:
I am able to see the color of the cyan blocks in between the edges of the horizontally aligned edges of each block on the wall.
I did some further research into this. http://0fps.net/2012/07/07/meshing-minecraft-part-2/ mentioned this about the greedy meshing strategy that I use:
I’ve heard old ghost stories that on some ancient ATi cards, when the moon is full, these type of cracks actually do appear and make a big difference;
To see if meshing is the problem, can you see cracks through the obsidian when it is set up like this?
I still see cracks:
Welp, this looks like it won't be a fun bug to solve.
Do you get the issue with ClassiCube? Also, here is an older build of ClassicalSharp that only uses display lists. Do you still have the same issues with cracks in this build?
I've noticed that these cracks only appear in Classicube when smoothing effects are turned on and at blocks at a distance.
Also, the issue still exists with that build, although the cracks appear to be smaller. They are probably the same size.
Hm, your comment on the effect with ClassiCube makes me wonder again if this is something to do with textures.
What happens with this build? (This one renders the map as coloured quads with no textures).
Definitely an AMD bug, used to get this on both premium and classic when I had a Radeon HD 7450, now that I use a GTX 660 I have yet to see this bug.
It does probably have something to do with textures, there are no cracks in the build that you gave me.
Hm okay, I'll try making a build that offsets texture sampling slightly to see if that helps.
@Cheesse Okay, here's the build with slightly offset texture sampling.
I think you might have meant to stretch in another direction. The direction of the stretching and shifting is parallel to the cracks. It should be perpendicular.
In other words, stretch and shift the textures across the Y axis instead of the X axis of the texture
I take it the build didn't help? Note that all that build was change texture sampling coordinates from green to the blue, it didn't change anything about the meshing. Okay - will make a build that does that at some point soon.
No, that build did not help at all, but I've noticed that the texture appears too short to fit on a block face. The bottom part of the texture is not able to reach the top part of the texture of the next block. The cracks appear to be smaller when a texture pack with higher dimensions is used.
In the first build, it appears that textures are stretched on the x-axis for 16 blocks. The texture is too short on the x+ side, which means that the texture should probably be stretched towards the x+ direction a bit.
In the second build, all blocks' textures are too short on the x-axis and z-axis. What I mean by this is that the textures are too short and should possibly be stretched towards the y+ and x+ directions in each texture.
That looks like a texture sampling issue. The stone has part of the dirt(which is one texture to the right in the terrain atlas)
What do you see for bedrock? (Sand is one texture to the right) What do you see for iron blocks? (Gold block is one texture to the right)
This is exactly what happens in this build, but it still doesn't describe what happens in the original client. If it did, I would be able to see a piece of a crate texture below obsidian, but all I see is transparency below it. It seems that each block texture behaves differently. For example, logs appear to have their texture offset, wood also has its texture offset and has some kind of stone texture shown below it, even though there is none below it in the texture atlas, cyan blocks have a blue texture below them for some reason,
Ok, I've come up with a diagram that should explain all situations when the normal client is being used:
Not to scale.
This would result in there being transparency below obsidian, since fire is next to obsidian and the top of fire is transparent.
This is also not exactly what is going on, this is just how I see it.
Using the test clients that you've given me, the textures would look like what you described.
The 1D atlas is created by combining the rows into a single 1D array, then rotating the array 90 degrees.
So yes this would place fire below obsidian - since the client is sampling transparent texels from the top of the fire texture, and as the client uses alpha testing, would discard these and thus show the various blocks behind. This would also place double slabs below wooden planks.
So, what are you able to do about this issue?
I'll see about adjusting the texture coordinates to be slightly smaller. Have to leave now though, so you'll have to wait until the afternoon.
@Cheesse Hey, sorry for the long delay. This build adjusts the right and bottom UV coordinates to be slightly inside the grid, rather than exactly on the edges.
This seems to decrease the inclusion of other textures slightly, too.
It doesn't fully fix it though?
Fixed as of 6c7fca02ef96841f786e1ef743ae50f2cfd61974
Thanks @Cheesse for continuously testing changes.
This bug is back.
This bug was never fixed. Probably just lessened.
What does it appear on? Blocks, entity models, ?
What GPU?
The problem is most noticeable on my old desktop with the same GPU mentioned here (if it is). I've noticed it also occurs on my laptop, which is much newer. I'll give the specs for that soon, too.
It's most noticeable on block edges, though I think this would apply to anything else.
A screenshot too would be useful.
Laptop:
-- Using Direct3D9 api -- Adapter: Intel(R) Iris(TM) Graphics 540 Mode: HardwareVertexProcessing Texture memory: 4093 MB Max 2D te xture dimensions: 8192 Depth buffer format: D24X8 Back buffer format: X8R8G8B8
It's much more noticeable when moving.
Desktop:
-- Using Direct3D9 api -- Adapter: ATI Radeon HD 3800 Series Mode: HardwareVertexProcessing Texture memory: 2295 MB Max 2D texture dimensions: 8192 Depth buffer format: D24X8 Back buffer format: X8R8G8B8
Don't worry man, I got you with the screenshots!
First screenshot seems to be about 1 white pixel gaps, which is another issue. (And one that's difficult to address without hardware that shows the issue)
Do you have mipmaps on in the second screenshot? Does it occur on both opengl and direct3d9 backends?
Mipmapping are on in the second photo, but even with them turned off the problem occurs.
ILL try the open gl version soon.
This problem does not occur in the open gl version.
There always appears to be lines on some of each block's edges. These lines shown here are mostly white:
The second picture shows that these lines appear on the edges of the horizontally aligned faces of each block that are aligned to the x-axis.
The first picture shows that these lines appear on the edges of the vertically aligned faces of each block that are aligned to the x- and z-axis.
This might just be an issue with my graphics card, an ATI Radeon HD 3870, but if possible, could you fix this issue?