Wrench/cutter grid line sometimes become too thin to see

Wrench/cutter grid line sometimes become too thin to see

Problem report and patch.

Screenshot: see same dropper from other directions


  • Sometimes grid lines of wrench/cutter become too thin to see.
  • It occurs frequently in TheEnd.
  • Player heading direction affects.
  • The problem has been occurring since a few months ago.

My environment:

  • Win7 Pro 64bit / 10 Home 64bit
  • GTX970 latest drivers
  • forge#1614(latest)
  • Gregtech 6.07.xx - 6.09.00
  • with mods / NEI only

I wrote and applied patch to next 3 files.

  • gregapi/GT_API_Proxy_Client.java #drawGrid()
  • gregapi/tilentity/base/TileEntityBase06Covers.java #onDrawBlockHighlight()
  • and maybe gregapi/tileentiy/notick/tileEntityBase04Covers.java #onDrawBlockHighlight()


//… code which draw grid lines


This patch works well in my enviroment.
But I don’t know much about OpenGL programming, so this may cause other problems.
If this problem is not my unique one and patch is suitable, please merge.


Hmm, that’s not a ‘thin’ thing but rather a floating aliasing mismatch thing, just changing the depthtest to <= instead of < should fix it and be more performant as well.


I need to refactor something I guess, because I dont think this list of classes you changed covers all cases. Something must be moved as utility up the class hierarchy

1 Like

I tested some more.

glEnable(GL_DEPTH_TEST) + glDepthFunc(GL_LEQUAL)


Both of them didn’t work.

If the depth is causing problem…

glTranslated(0, -0.505, 0) //from -0.501

Let grid line float more from block surface.
This works and simple.

1 Like

Its not a Z Fighting Issue as far as I had it happen in the past, it just somehow fucks up rendering the lines themselves even on Pipes.

I still try to find a way to reproduce the Issue, because I know its doable.

This implies a Z-fighting issue. I already submitted a PR to increase it to -0.5025 as I thought that might be it as that value is outside the floating point error bounds for any case where you are close enough to the object anyway (I.E. it should fix it for anything within about 50 blocks of the camera without starting to ‘float’ off the block too much).

I’ll check if newer version inclues fix.
Thanks for your works!

1 Like

Greg’s secretdownload would be the one to test until he makes the next release (the secretdownload is always his latest build, whether successful or not so it ‘usually’ works, but not always). :slight_smile:

1 Like

Here it is

1 Like

Thanks! I didn’t want to link to it myself since it’s your secret thing. ^.^


I downloaded file about 1hours ago, and test it.
It still have same problem.

I downloaded latest source and tested.(SHA1= 96dcce89cb)
Changed 0.5025 to 0.505, this didn’t resolve the issue this time.
Changed to first glDisable()s method, this still works.

Screenshot: glDisables() and LineWidth 2.0 to 5.0, and green

Changing grid color based on material color would be nice.


Just as I expected, I knew it wasn’t Z-Fighting. Its rendering weirdly. Last time I had that issue was on my Laptop, I dont get it on my current computer so its hard for me to reproduce, and I dont know shit about OpenGL so I need @OvermindDL1 to do it for me. ^^"

If glDisable(GL_DEPTH_TEST) fixes it then it is still Z-Fighting, but something about ya’lls drivers is borked. :wink:

You don’t want to use glDisable(GL_DEPTH_TEST) anyway, it will render ‘on top’ of everything, like if another player is standing in the way or so forth, rather you just want to change the depth test to be >= instead of > (or does MC use <… whichever).

1 Like

I once had an issue where it just skipped drawing random dots of the line, that looked like Z fighting but offsets couldn’t fix it either.

1 Like

@pochy could you try replicating the Issue with a recent Version please? I cant replicate it, @OvermindDL1 cant either, and you seem to be the only person who I know that can replicate it with their current hardware. (I know my old computer was able to replicate it aswell, but I dont use that one anymore at all)

1 Like

I tried SNAPSHOT build(with path).
Still have same issue in The End with peaceful mode.
But I couldn’t replicate same issue in OW even if 6.08.04.
What I changed to my environment is…Windows update only…maybe.

I noticed that when I have mob/dropped item(entity?) in my view(even if behind wall), grids are drawn correctly.


Let’s assume it is not that, even though the Win10 October Update tends to delete/corrupt a ton of User Files due to a bug with Intel Drivers.

This sounds like it only renders correctly when an Entity is onscreen, and last time I replicated the Issue I was in Multiplayer on a Server and made sure that no Entities were closeby (only got Squids at times). This might be the hint I need to replicate it at the very least.

1 Like

If so that sounds like that some mod’s entity is corrupting the GL state, which is not at all surprising… If you can figure out which entity, like via mobspawning eggs, that would be a great help!

1 Like

This sounds ACTUALLY like we rely on someone corrupting the Render State for us, since it happens when there is NO Entities around. :wink:

Though I again wasn’t able to replicate it… Maybe I need an actual nvidia card for that to happen.


Don’t forget TE’s as well as gui elements could effect it.

1 Like