Guide Minecraft — Reversing OpenGL Rendering for ESP with Nsight Graphics

[byte_corvus]

If you are tired of searching for offsets in Minecraft after every minor patch, it is time to stop playing with memory and start looking at what the GPU actually sees. NVIDIA Nsight Graphics is a beast for reversing render pipelines. It lets you fingerprint OpenGL functions, inspect buffers, and dump shader code in real-time.

In this breakdown, I will show you how to map the rendering algorithm for Minecraft (specifically targeting 1.15 through 1.16.5) to build a filter-exact ESP using frame debugging.

Setting Up the Environment
To get started, you need Nsight Graphics connected to your game instance.

1. Fire up your Minecraft version.
2. Open Process Hacker and grab the command line arguments for the javaw.exe process.
3. In Nsight, create a new project and paste only the command line arguments into the start options.
4. Launch the Frame Debugger and hit F11 once you are in-game to capture the current frame.

Render Timeline Analysis
Once captured, you will see a timeline of every draw call executed. Looking at the events, you will notice specific clusters for player models and chests. For instance, players often trigger a 288-vertex draw call using

glDrawArrays(Mode.Quads, 0, 288)

.

Hooking the Pipeline
To actually draw your own stuff (like a box through walls), you need to intercept the data. First, we need to understand the vertex structure. By inspecting

glVertexPointer

and its siblings, we can see a stride of 36 bytes.

Spoiler: Vertex Data Structure

We can recreate the structure in C# to map the buffer accurately:

unsafe struct Vertex
{
    public fixed float Position[3];
    public fixed byte Color[4];
    public fixed float TexCoord1[2];
    public fixed short TexCoord2[2];
    public fixed short TexCoord3[2];
    public fixed byte Normal[4];
} // sizeof(Vertex) == 36

The Filtering Problem: Scale and Texture Coords
Just filtering by vertex count (288) will give you false positives. Beds and horses often share similar vertex counts. To differentiate with 100% accuracy, we look at

glScalef

and, more importantly, Texture Coordinates.

Every entity has unique UV mappings. Horses and players use different areas of the texture sheet. By checking specific quads within the 288-vertex buffer against known UV constants, you can ensure your ESP only highlights actual players.

Implementation Logic
When hooking

glDrawArrays

, you verify the last captured buffer from

glVertexPointer

. If the vertex count and texture coordinates match your player predicate, you render your highlighted quads.

void DrawArrays(Mode mode, int first, int count)
{
    // Filter by scale (1/15 is common for entities)
    if (lastScaleF is not (1f / 15, 1f / 15, 1f / 15))
        return;

    // Filter by vertex count for players
    if ((mode, first, count) is not (Mode.Quads, 0, 288))
        return;

    var quads = (Quad*)lastBuffer;
    var quadsCount = count / 4;

    // Precise UV verification
    if (!TexPredicates.Player.IsSuitable(quads, quadsCount))
        return;

    // Render ESP logic here
}

This method is significantly more robust than basic memory scanning because you are working with the actual rendering primitives. If the game draws it, you catch it.

Any of you guys tried this on newer versions using shaders? Drop your captures if you've mapped the 1.20+ vertex structures.