Disclaimer - I have no great grievance with using AI as a tool, or AI-assistance in code. It is incredibly hard to deny that AI-assistance in programming is a force multiplier when utilized by developers that understand the code, and do not simply slam out PRs. See Linus Torvalds.

However, I think that people should have a right to understand where the code they run on their PC is from. Not attributing it to AI is whatever, I guess - but outright denying that AI was utilised whatsoever even when asked is incredibly poor form.

This is one example of the issue, and is not in any way, shape, or form, an isolated incident. This is becoming the norm, since people want to be able to choose to avoid AI-assistance where possible. Getting upset that people have a preference is poor form - why would you be upset about that? Yes, almost every platform uses AI. Yes, you can try to minimize utilizing AI-assisted software. These are not mutually exclusive, and people should have that chance.

Quiet removal of AI use in the git history.

If you meant no AI use in the code -

I suppose, for feedback on the above, you can get Codex to make a harness and run the game for itself doing A/B tests - or Claude, I suppose.

My bigger issue, however, is this;

The code plagiarizes and violates another shader's licence - "You can't claim this patch or this shader is your own work".

Reforged code:

// Ported verbatim from SEUS GFME 1.22 RC1: per-berry animated warm glow colour

vec3 GetGlowBerryColor(vec3 worldPos)

{

`worldPos = floor(worldPos);`

`float hashTime = frameTimeCounter * 0.0;`

`vec3 hash0 = hash33(worldPos + mod(floor(hashTime), 256.0));`



`float time = frameTimeCounter;`



`vec3 color = textureLod(noisetex, (worldPos.xz + time) * 0.002 , 0.0).rgb;`

`color *= color;`



`color *= pow(hash0, vec3(1.0)) + 0.05;`

`color = color.rrr * 5.0;`

`color += 0.05;`



`color *= vec3(0.3, 0.09, 0.003);`



`return color;`

}

GFME's code:

vec3 GetGlowBerryColor(vec3 worldPos)

{

`worldPos = floor(worldPos);`

`float hashTime = frameTimeCounter * 0.0;`

`vec3 hash0 = hash33(worldPos + mod(floor(hashTime), 256.0));`

`// vec3 hash1 = hash33(worldPos + mod(floor(hashTime + 1.0), 256.0));`

`// vec3 hashSmooth = mix(hash0, hash1, fract(hashTime));`





`float time = frameTimeCounter;`



`vec3 color = textureLod(noisetex, (worldPos.xz + time) * 0.002 , 0.0).rgb;`

`color *= color;`

`// vec3 color = vec3(1.0);`



`// color *= hashSmooth;`

`// color *= hashSmooth;`

`// color *= hashSmooth;`



`// color *= exp((hash0 * hash0 * hash0 - 0.9) * 5.0);`

`color *= pow(hash0, vec3(1.0)) + 0.05;`

`color = color.rrr * 5.0;`

`color += 0.05;`



`color *= vec3(0.3, 0.09, 0.003);`



`return color;`

}

And for lava fog, the code mentions a GFME fix as it's own - Reforged Code:

#ifdef IMPROVED_LAVA_FOG

// Lava was previously tinted using GetWaterAbsorption() (a blue-water light absorption

// color) via the same UnderwaterFog() function used for water. That absorption color kills

// red/orange light the fastest, so being submerged in lava crushed the whole screen toward

// a dark teal/near-black very quickly, exposing dither/banding noise as a "checkered" look.

// GetLavaAbsorption() instead keeps red mostly intact and only attenuates blue/green, so

// lava stays a glowing orange the way it actually looks, instead of crushing to near-black.

vec3 GetLavaAbsorption()

{

`return vec3(0.0, 0.05, 0.2);`

}

void UnderLavaFog(inout vec3 color, float eyeLength, vec3 eyeDir)

{

`float underwaterDepth = 1.0 - (eyeBrightnessSmooth.y / 240.0);`



`float x = eyeLength * 5.0;`

`vec3 wAK = GetLavaAbsorption() + WaterM;`

`float v = eyeDir.y - 1.0;`



`color *= exp(-wAK * x);`



`vec3 w = (0.15 * WaterM / v) * (exp(-wAK * (underwaterDepth - v * x)) - exp(-underwaterDepth * wAK)) / wAK;`



`color += max(vec3(0.0), w * vec3(1.0, 0.08, 0.0));`

}

#endif

GFME code:

vec3 GetLavaAbsorption()

{

`return vec3(0.0, 0.05, 0.2);`

}

void UnderLavaFog(inout vec3 color, float eyeLength, vec3 eyeDir)

{

`float underwaterDepth = 1.0 - (eyeBrightnessSmooth.y  / 240.0);`



`float x = eyeLength * 5.0;`

`vec3 wAK = GetLavaAbsorption() + WaterM;`

`float v = eyeDir.y - 1.0;`



`color *= exp(-wAK * x);`



`vec3 w = (0.15 * WaterM / v) * (exp(-wAK * (underwaterDepth - v * x)) - exp(-underwaterDepth * wAK)) / wAK;`



`color += max(vec3(0.0), w * vec3(1.,.08,0.));`

}

These are not the only examples of directly copied code from GFME's edit, and it is not inherited from SEUS HRR 2.1.

I don't think this is an issue with a resolution, really, but I did want to shine light on the fact that people are intentionally attempting to deceive about the origins of their code, hopefully encourage people to properly disclose their AI usage, and for the love of god respect people's time and work, rather than having an AI copy out their code and avoid crediting them. See Rule 2's wording - "Shaders take a lot of hard work to make."

Hey everyone,

I wanted to address some questions and concerns regarding the use of AI in SEUS PTGI HRR 2.1 Reforged, especially after seeing discussions about whether AI was used to write the shader's code.

I understand why people want clarification, so I want to explain what I use AI for, why I use it, and which shader projects contributed to Reforged.

Q: Did I use AI to write the shader code?

No. I used AI for the descriptive text inside the shader menu, mainly to explain what individual settings do and to help translate those explanations. The goal was to make the settings easier for users to understand, not to generate the shader's underlying rendering logic.

I think it's important to distinguish between using AI to help document a feature and using AI to generate the code that implements it.

Q: Then why are some of the code comments written that way?

The comments are there to make the shader easier to understand and maintain, especially as Reforged has grown and more features have been added.

Shader code can get quite complicated, so comments help explain what certain sections do, why specific changes were made, and how different features work together. Some comments are more descriptive than others because they serve different purposes, from explaining an entire feature to documenting a specific implementation detail.

I understand why some of these comments might raise questions, especially considering the discussion about AI. However, the way a comment is written does not, by itself, establish how the code it describes was created.

I want to be transparent about the distinction between AI-assisted documentation and the actual implementation of the shader.

Q: Did I use code from other shader projects?

Yes. SEUS PTGI HRR 2.1 Reforged builds on an existing shader and incorporates contributions and ideas from other shader projects. Some code from GFME was incorporated to help fix bugs and implement features.

Although I previously included credits inside the shader files, I realize those credits weren't visible enough to people visiting the project pages. That's something I should have handled better.

To make everything clearer, I'm adding explicit credits to the GitHub and Modrinth pages and updating the license to clarify the project's terms.

Q: Which shader projects are used in Reforged?

Here is a list of the shader projects that contributed to SEUS PTGI HRR 2.1 Reforged, along with what each one is used for.

• SEUS PTGI HRR Test 2.1 — The base shader that Reforged builds upon.
• Bliss Shaders — Used for the clouds.
• Photon — Used for the clouds, stars, and wind animations.
• GFME — Used for bug fixes and improved ray-tracing features.
• Lumenite — Used for water ripples and footprints.
• My Own Improvements — Custom features, enhancements, optimizations, bug fixes, and visual refinements developed for Reforged to create its own distinct experience.

These projects have different roles in Reforged, and I want to make sure their contributions are acknowledged properly. This list is intended to give users a clearer overview of the project's origins and the sources behind some of its features.

Q: Why use AI for the descriptions at all?

Shader settings aren't always self-explanatory, particularly when they control complex rendering techniques. I wanted the menu descriptions to be clearer and easier to understand, so users could tell what a setting does before changing it.

AI was a tool for helping with that documentation. My intention was to improve the user experience, not to replace the work involved in developing and refining the shader itself.

Q: What am I doing to improve transparency?

I'm taking the feedback seriously. I'm improving the credits on the GitHub and Modrinth pages so contributors are easier to identify.

I understand that people want to know what they're downloading, how it was made, and which projects contributed to it. Those are fair questions, and I want the project documentation to reflect that.

Final thoughts

I'm not asking anyone to take my word for everything without question. I want SEUS PTGI HRR 2.1 Reforged to be transparent about its development, its inspirations, and the contributions it builds upon.

Thank you to everyone who has provided feedback, raised concerns, or taken the time to look into the project. I'd rather address these questions openly and improve the documentation than leave people guessing.

Thanks for reading, and thanks to the original shader developers whose work helped make Reforged possible.

Shader iteration 3.2.0

CPU R7 7700x GPU 7900gre RAM 32 9GB allocated

so recently after powering on my PC and loading up Minecraft. IterationT experiences extreme lag spikes when looking at the ground and oddly deformed. clouds I can only come up with one solution which is my driver but that's the only thing I recently updated or changed. I also tried to change mod loaders and versions but before doing something about my driver I want to see if I can get help from here

there are no shaders looking better than this one.

I really like how it looks.

Modrinth: https://modrinth.com/shader/seus-ptgi-hrr-reforged

Official Website: https://seusptgireforged.github.io/