[MC-1559] Chest model has overlapping parallel faces causing texture fighting Created: 01/Nov/12 Updated: 03/Sep/18 Resolved: 01/Dec/15 |
|
| Status: | Resolved |
| Project: | Minecraft: Java Edition |
| Component/s: | None |
| 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, Minecraft 15w44b |
| Fix Version/s: | Minecraft 14w30c |
| Type: | Bug | ||
| Reporter: | Sycholic | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 20 |
| Labels: | chest, item, rendering | ||
| Environment: |
Microsoft Windows 7 Home Premium |
||
| Attachments: |
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| CHK: | |||||||||||||||||||||
| Confirmation Status: | Community Consensus | ||||||||||||||||||||
| Description |
|
Chest both single and double wide the lid is hinged at the wrong point creating a overlapping of two textures in the identical plane (texture fighting). It is not a texture mapping issue but a modeling issue. Screenshots included closed, open, and showing proper plane of alignment for the third. This is not just a visual issue this is also a rendering issue and in large amounts can lead to serious performance issues. |
| Comments |
| Comment by [Mod] redstonehelper [ 02/Dec/15 ] |
|
The goal of this bug tracker is to fix bugs. I recommended |
| Comment by insomniac_lemon [ 02/Dec/15 ] |
|
Sycholic, did you look at 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. |
| Comment by Sycholic [ 02/Dec/15 ] |
|
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. |
| Comment by user-f2760 (Inactive) [ 02/Nov/15 ] |
|
attached texture file which has bottom part black, and top white, this is easy for debugging |
| Comment by user-f2760 (Inactive) [ 02/Nov/15 ] |
|
no, it's not:
|
| Comment by Swekob [ 02/Nov/15 ] |
|
Fixed in 1.8.8 or before. (Doesn't occur to me) |
| Comment by [Mod] redstonehelper [ 30/Sep/15 ] |
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.
I don't think we can supply custom models for chests yet.
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.
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.
I understand your frustration, I'm sure some of us have (had) similar experiences. |
| Comment by Sycholic [ 30/Sep/15 ] |
|
IL: only ones that show up are the 3 you see nothing else for 15w* shows up. 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. |
| Comment by insomniac_lemon [ 30/Sep/15 ] |
|
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. |
| Comment by [Mod] redstonehelper [ 30/Sep/15 ] |
|
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. |
| Comment by Sycholic [ 30/Sep/15 ] |
|
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. |
| Comment by [Mod] redstonehelper [ 30/Sep/15 ] |
|
Why not update the affected versions? |
| Comment by Sycholic [ 30/Sep/15 ] |
|
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. |
| Comment by Samuel Lembas [ 12/Jun/15 ] |
|
Confirmed on 1.8.7. It's weird. |
| Comment by insomniac_lemon [ 05/Mar/15 ] |
|
Still affects 1.8.3. |
| Comment by Sycholic [ 12/Sep/14 ] |
|
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. |
| Comment by insomniac_lemon [ 11/Sep/14 ] |
|
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. |
| Comment by Sycholic [ 11/Sep/14 ] |
|
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' |
| Comment by Sycholic [ 11/Sep/14 ] |
|
Screenshot of issue still unresolved as of 1.8 |
| Comment by Sycholic [ 11/Sep/14 ] |
|
Still existing even in 1.8. updated affected versions to reflect this. |
| Comment by insomniac_lemon [ 31/Jul/14 ] |
|
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. |
| Comment by [Mod] Ezekiel (ezfe) [ 27/Jul/14 ] |
|
Resolved as fixed. If anyone can confirm this, please let me know. |
| Comment by dirk (switched to Minetest) [ 26/Jul/14 ] |
|
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. |
| Comment by [Mod] Ezekiel (ezfe) [ 26/Jul/14 ] |
|
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. |
| Comment by WolfieMario [ 09/Mar/14 ] |
|
Confirmed in 1.7.4, 1.7.5, and 14w10c. |
| Comment by Galaxy_2Alex [ 21/Jan/14 ] |
|
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. |
| Comment by insomniac_lemon [ 26/Sep/13 ] |
|
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. |
| Comment by [Mod] CubeTheThird [ 26/Sep/13 ] |
|
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. |
| Comment by Sycholic [ 22/May/13 ] |
|
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' |
| Comment by insomniac_lemon [ 22/May/13 ] |
|
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. |
| Comment by Tavis [ 21/May/13 ] |
|
The size of the lid can be changed without changing the size of the texture. |
| Comment by insomniac_lemon [ 21/May/13 ] |
|
...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. |
| Comment by dirk (switched to Minetest) [ 16/Mar/13 ] |
|
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. |
| Comment by Sphax [ 31/Jan/13 ] |
|
Ok for me as soon as the Z-fighting is fixed... |
| Comment by Eris [ 31/Jan/13 ] |
|
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? |
| Comment by Robert Tulley [ 29/Jan/13 ] |
|
You really do have a good eye. |
| Comment by Sycholic [ 29/Jan/13 ] |
|
Oddly enough its still not confirmed. |
| Comment by Sphax [ 28/Jan/13 ] |
|
I vote for this issue to be solved. |
| Comment by insomniac_lemon [ 17/Dec/12 ] |
|
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. |
| Comment by user-571ee (Inactive) [ 16/Dec/12 ] |
|
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. |
| Comment by Sycholic [ 14/Dec/12 ] |
|
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) |
| Comment by Tavis [ 14/Dec/12 ] |
|
Allowing texture packs to define their own chest models might work. As of right now everything is defined in code. |
| Comment by FireHunterX [ 14/Dec/12 ] |
|
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. |
| Comment by Sycholic [ 14/Dec/12 ] |
|
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. |
| Comment by insomniac_lemon [ 13/Dec/12 ] |
|
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. |
| Comment by Sycholic [ 21/Nov/12 ] |
|
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. |
| Comment by Tavis [ 16/Nov/12 ] |
|
I believe the hinge point is intentional. If there is texture fighting the lid just needs to be a little bigger than the base. |