Chest model has overlapping parallel faces causing texture fighting

I believe the hinge point is intentional. If there is texture fighting the lid just needs to be a little bigger than the base.

True, but regardless intentional or not its bad modeling/rendering and in large amounts leads to severe performance and even graphical glitches... good example go play 'Second Life'. But anyhoot there is something wrong with end result. Either the hinge point is too low or as you said one of the polygon's should be bigger then the other.. top or bottom shouldnt matter long as they arent trying to occupy the exact same plane of existence.

Yes, this could easily be solved by moving the chest lid part of the model up 1 pixel (1/16th of a block). As someone who makes textures, I can't make the chest be properly shaded, because if I do the Z-fighting will occur. The chest intersecting itself is illogical, and an eyesore that if fixed will make chests immensely better.

Whats even more odd is this still has yet to be confirmed by someone (officially)..... and yes I_L thats how I actually stumbled upon it when trying to make a custom texture for chests.

Does not appear to cause Z-Fighting, but I can see what you mean by the hinge point overlapping.

Does not cause any major performance issues. I'd say that this not a bug.

Allowing texture packs to define their own chest models might work. As of right now everything is defined in code.

Xavier you wont see it on the stock textures as the color values are the same, but its still happening. easy way to see it clearly is just make a white lid and a black base. (just never posted the photo with that when I first found it) only showing how the model itself is not correct.. simple change in the model will fix this for all. And if someone can find the source code for it, I'll fix it myself. I just dont have the time to search for it. (hell wish RL paid me to do this stuff lulz)

From what I see this is intentional. The two dark borders should overlap. To prevent z-fighting the lid should be a tiny little bit larger than the bottom.

If anything, this seems more like an oversight than an intentional decision to me. This was done back in beta by Notch (I think it was Notch), and he probably didn't think the self-intersection would cause any issues down the road, or maybe he didn't even realize it was intersecting. The simplest measure is to move the chest lid up 1/16th of a block. If you resized the lid, it would either change the size of the pixels, or require a different texture for it, and also the top of the bottom part of the lid would still be covered, which is part of the annoyance of this bug. Moving the lid up 1 px (1/16th of a block) would not require any texture changes, would stop Z-fighting from ever occurring, and would allow texturers to use proper shading on their chest textures.

I vote for this issue to be solved.
That was a pain to texture the chest while knowing a part of those will overlap. And even knowing they overlaps, the lid and the body of the chest 3D model are not properly aligned and the 1pixel (in 16x) still produces graphical glitches. 🙂

Oddly enough its still not confirmed.

You really do have a good eye.
I never pay attention to those kinds of things

Yeah, this just bit me in the posterior (apologies for the earlier phrasing). It's even worse if you're making an HD texture pack, and it gets worse the H-er D it is.

I think making the lid slightly bigger is the best route to go here. Container lids often fit over the top of the container, after all, right?

Ok for me as soon as the Z-fighting is fixed... 🙂

It would be enough to make the lid a “pixel” (or whatever it’s called in 3D modeling) wider on each side. No-one will notice, and the fighting will be gone.

...Once again, no. The lid should be moved UP 1 pixel, not made wider. People WOULD noticed a wider lid as that would break texture packs as it would require a wider texture, not only that, them model would still be intersecting itself. Moving the lid up 1 pixel would not require a changed texture, and there wouldn't be anymore intersection.

The size of the lid can be changed without changing the size of the texture.

Sure it can, but that changes the pixel density. If you only make it wider (as Dirk Sohler suggests) and keep the same texture the pixel density will no longer be the same, meaning the texture will be stretched. And like I said, the model still intersects itself AND Z-fighting on the front and back will still be present.

Moving the lid up fixes all problems very simply, as probably only 1 translation value for the lid would need to be changed. Bam, no more Z-fighting, no intersection, no need for texture change, no pixel density change on the lid, and the bottom of the lid meets the top of the base (and as the same width/length) as most chests do.

Actually you could change the size of the lid, just when you render it ignore the one layer of pixels (thats overlapping ie. dont render it) or just do the simple solution. Move the lid up one layer of pixels.... which Ive suggested since the start of this. You also could just make the lid have a indent towards the center of the lid and then if you rendered the texture as is, it wouldnt fight as it would be inside the lid. There is plenty of ways to do this funny how no-one on the dev team hasnt still flat out ACK'd that is actually an existing bug instead of it just being 'community consensus'

Is this still a concern in the current Minecraft version 1.6.4 / Launcher version 1.2.5 ? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Yes, even in all of the snapshots, as the chest model has still not been changed. All they have to do is move the lid up 1/16th of a block so there is no intersection and the issue is fixed.

Is this still a concern in the current Minecraft version 1.7.4 / Launcher version 1.3.8 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Confirmed in 1.7.4, 1.7.5, and 14w10c.

Is this still a concern in the latest Minecraft version 14w30c? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Can’t confirm the Z fighting and the hinge position looks okay for me.

Tested with default textures and Misa’s Realistic for all three available chest types and the two double chest types.

Resolved as fixed. If anyone can confirm this, please let me know.

Not fixed for 14w31a. Z-fighting still occurs, and more importantly the bottom and lid still intersect each other, meaning the texture will always overlap. This won't really be fixed until the model is changed (as I've previously said, by moving the lid up 1/16th of a block) or until chests are changeable using the vanilla model format which means we can make this change ourselves.

Still existing even in 1.8. updated affected versions to reflect this.

Screenshot of issue still unresolved as of 1.8

Here is a very simple resource pack for testing and verification without having to jump thru hoops to prove its still there. I cant remember how chest textures and resources were arranged for chests for older versions this will work for 1.8 just a simple texture mod nothing fancy but makes it very simple to see the problem that is normally just not 'visible'

Even though this could be solved with a simple model change, I doubt they'd be willing to do it (seeing as they haven't done so in the past near 2 years), the most current solution is to give the chests non-hardcoded models (in other words, in the new model format). While other entities dabble in the new model format (item frame, particles can use models from their item, ignited TNT, mushrooms on mooshroms even though inverted, etc.) this raises a few things that need to be sorted:

1) Textures. Currently any textures called through model files are added to the blocks/items texture atlas. Most of the entity files have padding in them that they don't need. They either need to be excluded from being added to the blocks/item atlas, or be added to an entity atlas, possibly after being sliced based on used UVs.

2) Joints. For a comprehensive system, there should not only be a way to define a joint of an element, but also the name. This can be used elsewhere to define what type of joint it is, and how it is used. In this case, the joint type would be "hinge" (can only rotate on 1 axis).

3) Action. In a separate container (on the same level as "elements" and "display") should be how you control skeleton mappings and how joints are used, such as animations. For mobs, this is where you would define the arms/legs/head etc. and walk/hit animations. For the chests, all you would need to do is define the open animation, which would just be defining that the joint is a horizontal hinge, and should rotate 90 degrees (to point up) within a certain amount of (defined) ticks.

If this were done, as previously said, users/artists could fix this issue just by increasing the Y values of a single element.

Well likely the issue of why its never been fixed is the fact that both the lid and the case has that trim of brown around where the overlapping is occuring and they just are not seeing it for that fact (same colors but the Z fight still happens just not visibly) Im going to try and make up a fix since its clear this is 'considered' not important, maybe they'll implement it if someone else does the leg work ^_. j/k I love MC and I have zero problems with mojang infact I never have or had issues with MC other then lil non serious glitches.

Still affects 1.8.3.

Confirmed on 1.8.7. It's weird.

still existing all the way up to 15w40b and you wonder why you have still performance issues in rendering when you still allow Z texture fighting to continue to happen.

Why not update the affected versions?

no offense but look at the age of this.... and also pls add the rest of 15w versions because we cant add them users can only add 'current' versions anymore.

If you don't keep your reports up to date it's even less likely they get fixed. We can't add any older versions either, they are achived - for good reason: It doesn't matter what affects them, it will almost always suffice to know if it affects the current version and the few before that, as well as the last released version. Anything older than that can be considered unsupported.

Sycholic: not sure what you mean, click the versions list and then type 15, snapshots should pop up.

redstonehelper: there's also the issue of devs not taking notice of bugs (or refusing to address them) even if they are consistently updated.

I'd say a large numbers of bugs are like this one: they aren't bugs because of fringe case, but because of implementation. It's unlikely that they'll ever be changed without the bug having been marked as fixed. Some of the bugs have not changed at all since they were implemented when Notch was coding the game, so in cases like being expected to change affected versions 3 times a week is ludicrous.

I have 9 issues (certainly others have more) so it's even worse. Jira is so clunky with version control, There HAS to be a better way (is there a batch version change I'm not aware of?). I would love if there could be an "implicit" version for easily repeatable bugs (those of obvious implementation) that way they'd be treated as always affects until they are fixed.

Maybe with a "depends on", like this bug could depend on "entity models" so as soon as that feature is added to the game this bug could be unmarked as implicitly affects and maybe as "awaiting response" so it could be confirmed fixed.

IL: only ones that show up are the 3 you see nothing else for 15w* shows up.
Mods and Devs: seriously you need to keep versions up to fix stuff? I'm sorry that is about the biggest cop out I have heard yet. Unless you fix it, its not going to fix itself. and for it now to be 3 years old AND still an open ticket is just unbelievable esp. given the fact we have custom models now for how long. And heck it still not even a officially acknowledged bug....still. Before custom models were implemented I could understand the hesitation of trying to fix it but that is not the case anymore. Hearing that any old versions are not even supported anymore officially means that this and any other ticket should been closed the moment you dont support the last version reported. so sorry will not accept that fact you need to keep versions updated so you know about it.

ps. sorry if I'm being a lil crude and harsh but the truth is know few tickets that code fixes have been given flat out to you and still don't implement them so I can hope you can relate to my frustration as a player.

Mods and Devs: seriously you need to keep versions up to fix stuff? I'm sorry that is about the biggest cop out I have heard yet. Unless you fix it, its not going to fix itself.

All I'm saying is you have no right to complain about bugs not getting fixed if you don't keep the tickets up to date. Nothing more, nothing less.

and for it now to be 3 years old AND still an open ticket is just unbelievable esp. given the fact we have custom models now for how long.

I don't think we can supply custom models for chests yet.

And heck it still not even a officially acknowledged bug....still.

What makes a bug officially acknowledged and why should they be? I think it's a waste of time to acknowledge bugs if you're not going to fix or decide not to fix them. That time could be spent actually fixing other bugs or working on other things.

Hearing that any old versions are not even supported anymore officially means that this and any other ticket should been closed the moment you dont support the last version reported. so sorry will not accept that fact you need to keep versions updated so you know about it.

Not my point. My point is that since old versions are not supported there is no point in reporting bugs for them or confirming bugs for them. For fixing this bug, right now, it is pointless to know whether this issue occurred on 15w35e. It is important to know that it still occurs on 15w40b. We understand it is annoying to re-confirm a bug for every snapshot or even every week, that's why we don't require issues to be up to date at all times.

ps. sorry if I'm being a lil crude and harsh but the truth is know few tickets that code fixes have been given flat out to you and still don't implement them so I can hope you can relate to my frustration as a player.

I understand your frustration, I'm sure some of us have (had) similar experiences.

Fixed in 1.8.8 or before. (Doesn't occur to me)

no, it's not:

Affects Version/s:
Minecraft 1.4.2, Minecraft 1.4.6, Minecraft 1.4.7, Snapshot 13w03a, Snapshot 13w04a, Minecraft 1.5.1, Minecraft 1.5.2, Minecraft 1.6.2, Minecraft 1.6.4, Minecraft 13w38a, Minecraft 13w38b, Minecraft 13w38c, Minecraft 14w08a, Minecraft 1.7.5, Minecraft 14w10b, Minecraft 14w10c, Minecraft 1.7.10, Minecraft 14w30c, Minecraft 14w31a, Minecraft 1.8-pre3, Minecraft 1.8, Minecraft 1.8.1, Minecraft 1.8.3, Minecraft 1.8.7, Minecraft 1.8.8, Minecraft 15w39c, Minecraft 15w40a, Minecraft 15w40b

attached texture file which has bottom part black, and top white, this is easy for debugging
attached result of this texture in 15w44b as well

really... so how did you go back in time to post it in 2014? not to mention I also appreciate the poaching, Swekob. I'm done.

Sycholic, did you look at MC-93554? It's about ALL z-fighting in the game and covers at least 7 other issues.

So a mod forgot to comment "resolving as duplicate for a more general issue". And if it feels bad, I have one of my issues (a typo I had posted near when it happened and kept the affects versions up-to-date) marked as duplicate because a newer version of it (what should have been marked as a duplicate) was posted and the dev saw it and fixed it... afterwards mine was marked as a duplicate...

Just remember that bug trackers are free-for-alls.

The goal of this bug tracker is to fix bugs. I recommended MC-93554 be created so we have a central ticket for what is essentially the same issue, this was not @unknown's idea. It doesn't matter who reported a bug as long as description, title and affected versions are kept up to date. It is not unusual to resolve older tickets as duplicate of newer tickets.