<!-- 
RSS generated by JIRA (9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13) at Sun Jan 12 12:14:16 UTC 2025

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>Mojang Studios Jira</title>
    <link>https://bugs.mojang.com</link>
    <description>This file is an XML representation of an issue</description>
    <language>en</language>    <build-info>
        <version>9.12.2</version>
        <build-number>9120002</build-number>
        <build-date>10-01-2024</build-date>
    </build-info>


<item>
            <title>[MC-7363] Very prone to rendering cracks between blocks</title>
                <link>https://bugs.mojang.com/browse/MC-7363</link>
                <project id="10400" key="MC">Minecraft: Java Edition</project>
                    <description>&lt;p&gt;Update: The cracks between 16x16x16 sections have existed for a long time, and still do. Crack theory has been, is, and will still be applicable. The lines that started to appear in between every block in the 1.5 snapshots and should be fixed in 1.5.1 were caused by texture coordinates overflowing their tile slightly in the rasterizer.&lt;/p&gt;

&lt;h5&gt;&lt;a name=&quot;Cracktheory&quot;&gt;&lt;/a&gt;Crack theory&lt;/h5&gt;
&lt;p&gt;Cracks occur in rasterizers like OpenGL when edges that should align don&apos;t match &lt;em&gt;exactly&lt;/em&gt;. This can happen if an inexact calculation is used, and vertices that should be the same end up in slightly different places. The errors may seem minuscule, but they invariably result in severe flickering along the cracks. The rasterizer &lt;em&gt;will&lt;/em&gt; miss a few pixels and fill others twice. Using different OpenGL transformations to move different vertices to the same place counts as inexact:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;glRectf(0, 0, 1, 1);
glRectf(1, 0, 2, 1);&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;glRectf(0, 0, 1, 1);
glTranslatef(0, 0, 1);
glRectf(0, 0, 1, 1);&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;The former will always, unquestionably align. The latter will have a crack. While associativity would tell us that both examples are the same, rounding error does not succumb to associativity. 32-bit floats are exact for integers in &lt;span class=&quot;error&quot;&gt;&amp;#91;-2^24, 2^24&amp;#93;&lt;/span&gt;, scaled by a power of two. 64-bit doubles reach a whopping 2^53. If both operands of an addition are round enough (in binary), the result will be exact. This would be typical for code like the first example. Rolling the same addition into a transformation matrix will almost certainly be inexact, because the matrix is polluted by everything else in it. Really the only way to get it right is to perform a separate addition before the matrix.&lt;/p&gt;

&lt;p&gt;If you perform the addition in a vertex shader, keep it separate and it should be okay, save for the hypothetical implementation that optimizes both into a matrix (if they&apos;re still technically allowed to optimize willy-nilly nowadays):&lt;br/&gt;
&lt;em&gt;Edit: Uniform state is slow to change, so an attribute used like a uniform would likely be faster than a uniform.&lt;/em&gt;&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;uniform vec3 translation;
void main() {
    vec4 vertex = gl_Vertex;
    vertex.xyz += translation;
    gl_Position = gl_ModelViewProjectionMatrix * vertex;
}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;What&apos;s cool about this is that even if you&apos;re very far from the world origin, you can still keep everything that matters exact. It also doesn&apos;t have a stepping or distortion problem in the Far Lands. The CPU code should do something like this:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;dvec3 camera;
dvec3 roundedCamera = camera.roundToMultipleOf(16); &lt;span class=&quot;code-comment&quot;&gt;// Assuming your world transformations are normally a multiple of 16. Can be demoted to &lt;span class=&quot;code-object&quot;&gt;float&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; you stay within 16 * 2^24 blocks. This is half of the magic, by reducing the translation fed into OpenGL to almost nothing.
&lt;/span&gt;dvec3 difference = offset - rounded; &lt;span class=&quot;code-comment&quot;&gt;// Not critical and rather small; can be demoted to &lt;span class=&quot;code-object&quot;&gt;float&lt;/span&gt;, and will be when fed to OpenGL.
&lt;/span&gt;&lt;span class=&quot;code-comment&quot;&gt;// Substitute difference &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; camera when calculating the camera transformation.&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;Then, before drawing each batch:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;dvec3 translationOfBatch; &lt;span class=&quot;code-comment&quot;&gt;// Can be &lt;span class=&quot;code-object&quot;&gt;float&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; roundedCamera can be.
&lt;/span&gt;dvec3 translation = translationOfBatch - roundedCamera; &lt;span class=&quot;code-comment&quot;&gt;// This is the other half of the magic. Two potentially huge numbers are reduced to a small, exact multiple of 16. Can certainly be demoted to &lt;span class=&quot;code-object&quot;&gt;float&lt;/span&gt;, and will be.
&lt;/span&gt;&lt;span class=&quot;code-comment&quot;&gt;// Load the uniform.&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;I hope this is enough theory to help you understand and fix cracks. Now, on to the actual problem description:&lt;/p&gt;

&lt;h5&gt;&lt;a name=&quot;Description&quot;&gt;&lt;/a&gt;Description&lt;/h5&gt;
&lt;p&gt;Previously, cracks would only appear in between 16x16x16 sections. Not as it should be either, but hardly worth reporting. In the latest snapshots, however, they appear in between every single block. That is too much.&lt;/p&gt;

&lt;p&gt;The screenshot shows a superflat world with preset &quot;2;7,62x0,49;2&quot;, viewed from below. It should be viewed at its full 1920x1200 size to see the speckles. Incidentally, Minecraft thinks it should light the underside of the obsidian when I get close to it.&lt;/p&gt;

&lt;h5&gt;&lt;a name=&quot;Addendum%3Atextures%3F&quot;&gt;&lt;/a&gt;Addendum: textures?&lt;/h5&gt;
&lt;p&gt;After noticing the directionality of the cracks, I realized it&apos;s crossing over into adjacent tiles on the texture. That could explain some or all of this bug. I will upload a second screenshot demonstrating that. It&apos;s of a similar superflat world, but using purple wool (35:10) instead of obsidian.&lt;/p&gt;

&lt;p&gt;What you see is a close-up of the vertex joining four blocks. You can see some yellow seeping through one edge, and blue through the other. Indeed, those are wool blocks adjacent to the right and below, respectively, in stitched_terrain.png generated by an older snapshot. There is also some sky showing through next to the blue wool (I know it&apos;s the sky because it becomes black at night). I&apos;d expect it to be orange wool as that is located above it in stitched_terrain.png, but then that file is probably outdated. It may well be that the adjacent texture is transparent. Indeed, green wool doesn&apos;t have this &apos;crack&apos;. Texture coordinates should be the only difference between wool colors, therefore this should be responsible.&lt;/p&gt;

&lt;p&gt;Older versions of Minecraft used to move their texture coordinates inward just a tiny amount to avoid this issue. Was that tweak removed when the rendering engine was overhauled?&lt;/p&gt;</description>
                <environment>Mac OS X 10.6.8</environment>
        <key id="20149">MC-7363</key>
            <summary>Very prone to rendering cracks between blocks</summary>
                <type id="1" iconUrl="https://bugs.mojang.com/secure/viewavatar?size=xsmall&amp;avatarId=18903&amp;avatarType=issuetype">Bug</type>
                                    <status id="5" iconUrl="https://bugs.mojang.com/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="3">Duplicate</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="jonathan2520">jonathan2520</reporter>
                        <labels>
                            <label>block</label>
                            <label>crack</label>
                            <label>geometry</label>
                            <label>rendering</label>
                            <label>speckles</label>
                    </labels>
                <created>Sun, 13 Jan 2013 06:38:20 +0100</created>
                <updated>Mon, 7 Sep 2015 20:02:27 +0200</updated>
                            <resolved>Tue, 22 Jan 2013 17:58:16 +0100</resolved>
                                    <version>Snapshot 13w02b</version>
                    <version>Snapshot 13w03a</version>
                                                                        <votes>2</votes>
                                    <watches>4</watches>
                                                                            <comments>
                            <comment id="39092" author="banana478" created="Tue, 22 Jan 2013 17:58:16 +0100"  >&lt;p&gt;Duplicate of &lt;a href=&quot;https://bugs.mojang.com/browse/MC-1794&quot; title=&quot;White stitching on polygon edges / White lines or black dots between blocks&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-1794&quot;&gt;MC-1794&lt;/a&gt;, please use the &lt;a href=&quot;https://mojang.atlassian.net/secure/IssueNavigator.jspa&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;search function&lt;/a&gt; to see if your bug has already been submitted. Currently over 45% of tickets are being closed as duplicate.&lt;/p&gt;</comment>
                            <comment id="39083" author="jonathan2520" created="Tue, 22 Jan 2013 16:50:06 +0100"  >&lt;p&gt;The cracks also appear on a block supporting a torch, bordering the torch. I doubt those are caused by textures. If it&apos;s an attempt to make closed geometry, it failed.&lt;/p&gt;</comment>
                            <comment id="37517" author="jonathan2520" created="Thu, 17 Jan 2013 19:58:38 +0100"  >&lt;p&gt;Close-up of a vertex joining four purple wool blocks, viewed from below.&lt;/p&gt;</comment>
                            <comment id="37318" author="iamthepiguy" created="Thu, 17 Jan 2013 13:18:04 +0100"  >&lt;p&gt;Has been an issue for me for a long time. I think Optifine does improve (if not completely remove) this glitch.&lt;/p&gt;</comment>
                            <comment id="36387" author="kumasasa" created="Sun, 13 Jan 2013 12:18:45 +0100"  >&lt;p&gt;Confirmed.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10102">
                    <name>Duplicate</name>
                                            <outwardlinks description="duplicates">
                                        <issuelink>
            <issuekey id="13163">MC-1794</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                            <attachment id="18574" name="cracks.png" size="435610" author="jonathan2520" created="Sun, 13 Jan 2013 06:38:20 +0100"/>
                            <attachment id="18908" name="texture edge.png" size="8404" author="jonathan2520" created="Thu, 17 Jan 2013 19:58:38 +0100"/>
                            <attachment id="19406" name="torch.png" size="173801" author="jonathan2520" created="Tue, 22 Jan 2013 16:50:06 +0100"/>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                <customfield id="customfield_10701" key="com.atlassian.jira.plugin.system.customfieldtypes:datetime">
                        <customfieldname>CHK</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Sat, 2 May 2015 03:38:00 +0200</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10500" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Confirmation Status</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10303"><![CDATA[Confirmed]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_11700" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_11100" key="com.atlassian.jira.plugin.system.customfieldtypes:float">
                        <customfieldname>Linked</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                <customfield id="customfield_11600" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i09blz:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                    </customfields>
    </item>
</channel>
</rss>