What: With 3D models and interblock culling enabled, certain configurations of iron bars/any sort of glass pane can cause the tops/bottoms of above/below matching blocks (different states) to have an exposed face culled (which is incorrect).
Why it matters: By having issues such as this, it makes attempting to optimize models less appealing, a little bit more frustrating, and at the very least might make pack makers remove interblock culling from iron bars/glass panes to prevent this issue, causing more of a performance drain than needed, especially in maps/saves that use tons of those blocks.
Note: bars/panes are the few "transparent" blocks that can cause interblock culling on itself. In reeds_not_culling.png you can see a 3D sugarcane model (with top/bottom interblock culling enabled) not culling the top/bottom of sugarcane when touching other sugarcane. Carl Nathans has noted (and I can confirm) that repeaters/comparators cull the top/bottom face if any cullface is specified (even if that case isn't true) and the sides (which do have culling arguments on the default models!) can't be culled at all.
Simple fix: Make it so certain models of iron bars/panes (n, ne, nse) do not cull faces of their other states.
Advanced fix: Remove all hardcoded cull restrictions/quirkiness and allow all blocks to have culled faces if they are specified by the model and are touching either 1)an opaque block or 2)the same state of themself. This is however, still a primitive fix, because there are cases where different states of blocks obscure faces. Examples possibly being the sides of rotated repeaters/comparators, corner+line panes/bars, or even something simple as a repeater being on and another being off.
A full separate cull control system would be fairly useful. For instance, on bars/panes you could make the sides cull as they do now (no limitations on state, since it doesn't cause issues there), but then the tops/bottoms have the state restriction. You also could make them only culled by themself (not by opaque blocks) which would allow a border around all of themself, including over opaque blocks (like they do now, but culled in the middle).
It would also help in the case, as I have done with farmland, where an artist switches a block to render as a full cube. Currently if you do this, the rendering is treated the same (in this case, farmland won't cause other blocks to be culled since it is still a transparent block) even though this could be taken advantage of for better performance. Similarly, in default the enchanting table (and repeaters/comparators, half slabs, and stairs) has a full bottom (or top/sides for the orientables) but isn't an opaque block... so it does obscure faces so it could cull those faces, but does not. These are (and should be) changeable, but optimizing these things should be a possibility.
Linked issues
Attachments
Comments 16
Ok Kumasasa, I've uploaded a screenshot with 14w21b.
However, the part of the issue about the default resource pack:
Culling is a feature of the model format, which does not work properly on iron bars or glass panes because if culling is applied it applies when different block states are next to each other even though they don't line up. The issue is still there, default just no longer enables culling for those blocks so you can't see it.
Saying this isn't an issue or is fixed is like saying that because vanilla doesn't use 3D mushroom models MC-50769 is invalid. This isn't fixing an issue, it's not using it.
Edit: Just bolding what you said while ignoring me? Ok, I see I can't reason with people who either aren't reading anything on the page or don't care. I'd be better off sending my bug reports to the recycle bin rather than here, considering how you guys are so one-sided on everything dedicated to resolving as much as possible. I've only ever had 2 issues fixed (MC-7098 and MC-50396), which both luckily were fixed by Grum before he mods here could get their grubby little paws on it with the "it's like that because Mojang intends it to be that way, I know we think alike" attitude. Seriously, of all of my issues, THOSE TWO were fixed by Grum, who initially detested the idea and could have likely said "No, we do not intend to allow NPOT textures because they add complication and POT texture are not only perfect implementation side, but also fit in with Minecraft's programming culture roots".
Thanks for showing me how bad a bug tracker can get when when it's ran by non-project members (and I say this as a moderator myself, but then again I wasn't given a paper sheriff's star by a multi-million dollar company).
Sorry I wasted your time by trying to help improve the game, not only vanilla, but how Mojang enables the community to build upon it, the same community that is the reason Minecraft is a popular as it is today, because people aren't bored with the game, as they can change packs, use maps servers and mods.
But no, you're right, I guess issues only exist if they happen in the game with completely vanilla settings. Please make sure the screenshot is taken with the default pack, in single player, using survival mode, default world type, and with default settings (render distance, difficulty, volume levels, controls). It's also not an issue if it's something small that a normal user wouldn't notice, especially if it requires actual inspection/testing (so in other words, anything that's not a blatant bug).
I guess I should go, because clearly this bug tracker is only for those who don't know anything about the issue they're reporting and provide as little amount of details as possible.
WTF ?
I just queried a vanilla resource pack screenshot from you, because you didn't write with a single word that this happens only with your resource pack.
Well, I could've guessed that, but wouldn't it been easier for all parties if you
a) have stated that clearly
b) attached the model file or the whole resource pack in question.
and thanks for insulting me and the other mods.
Plonk
Both the OP and my comments clearly describe that this is an issue with the models system.
In the OP (right at the start): With 3D models and interblock culling enabled
In my first response: mine is about culling itself erroneously culling different block states of models (custom included, so the entire system, not just default behavior) .....
but culling was just removed from the default iron bars/glass panes rather than fixing the fundamentals of how culling works.
I'm not sure how to get more clear than that, so it seemed to me that you or Mustek didn't read the description but just assumed it was exactly the same issue with the same scope.
Your response ticked me off because not only did it seem like you didn't read the issue or the comments, but after I added a 21b screenshot and further explanation of why I was using my pack in my Second response:
Culling is a feature of the model format, which does not work properly on iron bars or glass panes because if culling is applied it applies when different block states are next to each other even though they don't line up. The issue is still there, default just no longer enables culling for those blocks so you can't see it.
You edited your statement to be bolded. To me at the time it seemed intentional as to undermine the issue, and maybe that wasn't the case. But hey, I write my issues further than "duh huh, iron bars are borken!!
[media]" I'd appreciate it if the mods would read it first before marking it as "duplicate" to a fixed issue that in the back-end isn't really fixed. And if the mods here don't understand it or have the time to read it they should leave the issue alone.
a)I think I did a perfectly fine job of stating this was a model issue
b)this is apparent with any iron bars model with the top/bottom textures with cull:true set on those faces placed with different variants/rotations on top of each other, including default which just switched culling off on those faces.
Don't act like you can't guess where I'm coming from on this. It's clear the issue wasn't read, and you should be able to see why you going and bolding your comment right after I've already explained myself multiple times, paired with my disgruntled view of the bug tracker, would make me go off on a rant.
Most technical issues, ones not likely to be reported by normal users (especially if small or not prevalent with vanilla resources) don't get any attention if they're lucky. Things like this (the bug is now a duplicate even though it is not fixed, paired with mods deciding for Mojang that something is WAI) add a minefield for technical issues to traverse, to further cement their death before they can even get to an ignored state. So really the bug tracker seems to boil down to 90% of its value fixing major bugs that can be found with minimal testing, with occasional major issues for specific cases that take a while to notice, but are annoying or even feature breaking. So really it comes down to the bug tracker is mostly for things 50+ people are going to dupe. Why should I be happy about that, specifically when something like this happens?
EDIT: And looking through the issues that this is supposedly a dupe of, this issue is clearly different. MC-16587 and MC-19461 are specifically a torch somehow causing the top face to be improperly culled (which could be related to this issue, but why would a torch cause it?), MC-28145 and MC-18229 actually aren't this issue either (I thought it was at first, but just realized it's different), because the block is needed to cause culling on 1 legitimate face, which causes adjacent faces to be culled.
So those issues are caused by miscalculation somehow that results in too much to be culled. This issue is caused by blocks with different variants and rotations causing culling for other variants and rotations when they should not.
The moderators (and regular users) have built a number of useful filters and dashboards for tracking activity on the Mojira. However, they're not very discoverable. You can search for filters and dashboards from the respective Manage Filters/Dashboards pages, and there's a list of popular ones on each. But those tools are only effective if people use them, and it seems most users would rather go to the effort of creating a new issue, rather than searching for an existing one.
You're right that issues don't need to be resolved immediately, and that it's better to be sure before taking action – even though it's also extremely easy to fix a ticket if a mistake is made, like how I reopened this one. However, most issues are abandoned immediately, with the reporter never checking back or responding to requests for more information. Unresolved tickets do clutter up the search results for most users, increasing their frustration, and decreasing the likelihood of finding the right ticket in the event that they do search before creating one.
Although it would be possible to filter out most garbage issues with the sort of searching techniques you suggest, the goal is not to ignore or filter out garbage tickets, because a good ticket might get missed and passed over that way. If each ticket is properly resolved, then we know it's been seen and addressed. However, it appears that we need to improve on accuracy, because that value in marking tickets as resolved is lost if users (or the other moderators) cannot trust that it's been marked correctly. As a regular user, I personally stepped through over 47,000 tickets, because I wanted to make sure that nothing had been missed or marked incorrectly.
The moderation team is in direct contact with Mojang, and we can privately ask them questions about Minecraft or individual tickets. Sometimes a moderator may appear to be making a decision on a ticket, when actually they've been given an answer by Mojang. The whole point of the moderation team is to reduce the amount of time Mojang must spend on the Mojira themselves, so that they can spend their time on actual development. If there's some doubt about the resolution of a ticket, just leave a comment, and it can be re-examined, and Mojang can be asked to confirm or comment. It's not like there's a conspiracy to hide things from Mojang, or obstruct development. We're all here because we want Minecraft to get better, not buggier.
While you may not care if you're respected here, you've gained a reputation for being antagonistic, and it discourages people from engaging with you, or even working on tickets you create or comment on. I would think that your motivation for using the Mojira would be to get bugs fixed, so if the way you engage with others hinders that goal, then respect, both treating others respectfully and being respected in kind, should be important to you.
Repeater and comparators also have odd culling. Assuming cullface is specified logically for all six faces, the top and bottom are always culled, and the sides are never culled.
Kumasasa, MC-72891 is in no way related to this issue. That issue is about backface culling being used on iron bars, and seems to be fixed already. This issue is about inter-block culling, not backface culling.
EDIT: MC-72891 is actually a duplicate of MC-62118 which has been partially fixed. The complaint they do share certainly has been fixed.
Updated example pack. Has iron bars model from 15w47c with culling enabled on top/bottom faces showing that culling is happening in places it should not.
It also shows the removal of the middle faces on that previously didn't render on walls of iron bars, something is part of MC-62118 that wasn't addressed.
Mustek, you marked this issue as a dupe of a fixed issue, when this issue is NOT fixed.
That issue is about culling improperly happening by default, mine is about culling itself erroneously culling different block states of models (custom included, so the entire system, not just default behavior), which has no option to change the behavior. Yes-you could say this is the same issue, but the bottom line is that it is NOT fixed, but culling was just removed from the default iron bars/glass panes rather than fixing the fundamentals of how culling works.
Also note: I DID search for this issue (specifically I believe I searched "iron bars culling") but the other issues don't have a proper description that would net it in a search (the best some of them do is "graphical bug/glitch" which is too broad of a term and not technical).
Considering this ticket is more technical and complete (better description, talks about model files, better images, suggested solutions) I think this ticket should be re-opened and the other issues should be in the "is duplicated by" list for this ticket.