Fix z-fighting for voidstone blocks #71
Open
+100
−65
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixes GTNewHorizons/GT-New-Horizons-Modpack#21220
Before

After

There are two parts of the problem and two commits to resolve them for good
Fix z-fighting for regular blocks
I just changed the order of rendering: now I first render animated base texture and then overlay texture. This way overlay always wins and renders above the base
I also tried to fix z-fighting for CTM blocks by adding
shiftBoundaryandresetBoundarymethods, but epsilon-based approach is always unstable so you could still encounter micro-tearsin minecraft material spaceon edges in some cases and z-fighting when the block is far away enough from youFix z-fighting for CTM blocks
Regular blocks got fixed because vertices have the same coordinates and minecraft have only one way left to decide what texture to render first: by using order in which they were added. Unfortunately, for CTM textures this isn't the case. Let's look at their rendering process:
RenderBlocks.renderFace*()methodRenderBlocksCTM.renderFace*()methodThese methods are very different: the native one creates only 4 vertices per side, but the
RenderBlocksCTMone create 16 vertices per side, 4 per a quarter of the side. Vertices are different, calculations don't match, imperfections occur and z-fight begins(Why do I even write it, you already know what z-fighting is and why it happens)So, what if we choose just one method to render both textures, just as it works for regular blocks? Finally, this is the only attempt that actually worked. Obviously we're going to use CTM rendering in both cases to keep connected textures
Before
super.renderFace*()call there is asetOverrideBlockTexture()call which sets a base texture we want to render. Thesuper.renderFace*method have two branches: in first it renders given face the vanilla way, and in second it renders it the CTM way. There were two main reasons to render the vanilla way:hasOverrideBlockTexture()andsubmap == null. Now we want to render the CTM way whenhasOverrideBlockTexture()is true, but we'll still render the vanilla way whensubmap == null, which basically means that we don't have a CTM textureThe last part of solution is to handle the CTM rendering itself. If we leave it as is, it will render the full texture in every corner 4 times. To solve this problem we need to change UVs to render only a desired quarter of the texture in every corner