Rendering fix for Semi-Transparent, Non-Liquid Blocks #475

wants to merge 1 commit into


None yet

Hello, Minecraft has a fairly well-known bug detailed here:

Essentially, the problem is that semi-transparent render objects must be rendered back to front, and minecraft's current behavior is this:

  • Semi-transparent quads are rendered in sub-chunk order, front to back. Each sub-chunk renders its semi-transparent quads in arbitrary order.
  • Particles, liquids, and clouds are each rendered in separate phases from semi-transparent blocks and from each other, in a fixed order.

This causes a number of problems detailed in the linked bug. This task only fixes the following problems:

  • When viewing a semi-transparent block in Fast graphics mode, arbitrary backfaces of the object are rendered or not rendered.
  • When looking through a semi-transparent block, other semi-transparent blocks in the same subchunk on Fast graphics mode will have arbitrary faces rendered or not rendered.
  • When looking through a semi-transparent block, other semi-transparent blocks in other subchunks, or in the same subchunk on Fancy graphics mode, will not appear.

Mojang deals with this issue by using very few alpha-blended non-liquid blocks (glass, for instance, is not actually blended) and using very high opacity for those blocks which are alpha blended (such as ice).

For modders who would like to provide basics such as MineFactory Reloaded's stained glass, this is a very serious issue that directly impacts the player experience and the ability of modders to be creative.

Thank you for reading all this, and please know that I am prepared to make any changes necessary to help this fit with Forge code and satisfy your coding standards. I am very serious about this fix finding its way into player hands. Thank you.


immibis commented Mar 23, 2013

@luacs1998: does it mention item frames anywhere?

To dispel any confusion, here is what this PR does, in picture form:

I would greatly appreciate this being accepted.

I could see this being really useful for my mod.


MachineMuse commented Mar 24, 2013

This affects my tinker table block with the translucent bits, although it's barely noticeable.

Sorry, do you mean it breaks something?


MachineMuse commented Mar 24, 2013

No, I mean the tinker table has some translucent bits and they are affected by the issue that this PR addresses.

Oh... good!

I have heard mention that this PR could negatively affect performance on the computers out there that are getting on in age. I can't say one way or another, but I can provide some information for everyone to see.

Some Info on my specs:

BEFORE Patch Test:

AFTER Patch Test:

Settings used during both tests:

In summation, in both tests the FPS varied from 16-24 FPS, with no clear winner between the two. If this helps modders out with their fancy transparent blocks, what the hell? 👍

That may be the worst computer I've ever seen. Also thank you so much for doing this. My gut and my own unscientific tests were telling me that this change had a low performance impact but I couldn't prove it so this means a whole lot to me.

One thing: a lot of the stuff that rebuilds rendering (both in vanilla, and resorting quads for this fix) happens while you're in motion. Can you do some motion tests?

I conducted a similar test just running around the ice lake

Before Fix:

After Fix:

While walking I get roughly 15-20 fps, it seems to vary pretty widely. The result is identical for both. Whether this shows what people care to see, I haven't got a clue. Good luck fixing notch-code you poor bastards 🎱

Thanks so much, this is a great test. The only thing that could be more complete is I guess a stained-glass megastructure, but I think that'd require either MFR or Forestry to be 1.51-ready.


ShetiPhian commented Mar 25, 2013

👍 I like this,
a while back I added a third render pass and had my semi-transparent blocks use it just so water could render behind them. (couldn't see my blocks through water though) Though I didn't notice a difference in performance after getting several testers it was discovered it basically killed Minecraft on older hardware 😞

No only does this look better then what I tried, it doesn't cause the world to render a third time

Yeah @ShetiPhian my hardware is just about as old as it gets where Minecraft can still be considered playable at all 👊


micdoodle8 commented Mar 25, 2013

This has my vote. Currently a pretty major problem in Galacticraft, since oxygen bubbles are transparent and players are often inside huge oxygen bubbles. Also is a problem since 1.5, the rocket launch particles appear behind the water when flying upward and looking down.

I've rebased my 3 commits to 1 for all you good people.

Minecraft renderer changes - semi-transparent, non-liquid blocks now …
…render correctly on their own and when viewed through other semi-transparent, non-liquid blocks.

@micdoodle8 I appreciate your support for this fix, but this fix is only for block-to-block rendering. The five major groups of semi-transparent rendering: entities, blocks, clouds, liquids, and particles, still don't play well with each other, and I didn't change the rendering for any group except blocks. So I hope that this change will help with oxygen bubbles (assuming they're blocks and not entities or whatever), but it definitely will not help with the particle-liquid interactions, or block-liquid interactions.


micdoodle8 commented Mar 25, 2013

@CannibalVox Oh okay, I didn't look into the code for the commit too much as I was on my phone. I just saw that there was a mention of particles on the mojang bug report. Still, will help out if this is merged :)


AbrarSyed commented Mar 27, 2013

I am a retard who can not provide anything valid to the discussion so I just post stupid thumbs upping and want to be annoying.


I totally support this. Anyone who has made transparent blocks/rendering with a low alpha will know of these problems. Any effort to correct the rendering so it looks correct, without dirty hacks or inefficiency is greatly appreciated :D

It was conveyed to me that lex indicated in #minecraftforge that he did not intend to accept this PR. I'm closing this so I can scrap the fork and reconfigure it in a way that will allow me to easily put together modded forge builds for the modpacks I contribute to.


micdoodle8 commented Apr 24, 2013

Did he give a reason? This is clearly a problem affecting many modders.

The two reasons given (secondhand, mind) were that he was not happy with the implementation method, and he believed this was too invasive an issue to correct in forge, and we should wait for action from mojang, which is forthcoming. I'm not really clear on the details of the former, but the latter I can empathize if not agree with.


micdoodle8 commented Apr 24, 2013

True, thanks for the update.


cpw commented Apr 24, 2013

Who told you that cannibal?


AbrarSyed commented Apr 24, 2013

that would be me. Cafaxo was in the forge channel asking about this PR, and lex said what CanVox summarized above. I passed the information to vox a few days later.


Soaryn commented May 26, 2013

Wait for mojaang to take action... on this? Since Ice was conceived... yeah we are going to be waiting a while... anybody else want to take a shot at this?

@npdev453 npdev453 referenced this pull request in MinecraftPortCentral/Cauldron Aug 9, 2013


Crash withoit reason #79

LexManos added a commit that referenced this pull request May 11, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment