Fix rendering differences observed in 2025.07

[RyeMutt]

Description

Fixes rendering differences observed in 2025.07 from changes done for mac performance.

Related Issues

Issue Link: #4707

---

Checklist

Please ensure the following before requesting review:

• [ X] I have provided a clear title and detailed description for this pull request.
• [ X] If useful, I have included media such as screenshots and video to show off my changes.
• [ X] The PR is linked to a relevant issue with sufficient context.
• [ X] I have tested the changes locally and verified they work as intended.
• [ X] All new and existing tests pass.
• [ X] Code follows the project's style guidelines.
• [ X] Documentation has been updated if needed.
• [ X] Any dependent changes have been merged and published in downstream modules
• [ X] I have reviewed the contributing guidelines.

---

Additional Notes

[aiaustin]

I am seeing a big difference on rendering on Windows too - much darker and harsher shadow areas - when testing 2025.07 recent development builds compared to last 2025.06 release. For two comparison images below, the Midday preset was selected in both cases with same graphics settings on Windows 10 with NVidia GTX 1080 GPUU to show difference:

Current Release: Second Life Release 7.2.1.17108480561 (64bit)

Development Version: Second Life Release 7.2.2.17953906098 (64bit)

Look at avatar front, plywood object in sky and shadows under vehicle.

In case its location related this test was at secondlife://Aditi/secondlife/Rumpus%20Room%202048/142/102/23

[Copilot]

Pull Request Overview

This PR fixes rendering differences introduced in version 2025.07 by addressing texture parameter setting and screen buffer allocation issues. The changes ensure proper texture type handling and consistent buffer format usage.

• Force GL_RGBA16F format for screen buffer allocation regardless of HDR setting
• Modify texture parameter functions to accept explicit texture type parameters
• Update texture parameter calls to use correct texture types instead of relying on current state

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
indra/newview/pipeline.cpp	Forces GL_RGBA16F format for screen buffer allocation
indra/llrender/llrender.h	Adds texture type parameters to fast texture parameter functions
indra/llrender/llrender.cpp	Updates texture parameter functions to use explicit texture types

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The hardcoded GL_RGBA16F format ignores the computed screenFormat variable on line 859. This creates dead code and makes the HDR conditional logic meaningless. Either remove the unused variable or use it in the allocation call to maintain the intended behavior.

Suggested change

	if (!mRT->screen.allocate(resX, resY, GL_RGBA16F)) return false;
	if (!mRT->screen.allocate(resX, resY, screenFormat)) return false;

[cosmic-linden]

This line reverts to the behavior in the release/2025.06 branch, which does seem relatively safe on its own.

[brad-linden]

I'm concerned that the bool hdr initialization on line 812 wasn't corrected. I don't think we should force the render target format to be HDR all the time. On machines where we have forcibly downgraded them to OpenGL 3.1 Fallback Mode in order to avoid crashiness, I think we probably need to keep hdr screen format off. Possibly it should be changed to something like this?

    bool hdr = gGLManager.mGLVersion > 3.1f;

[brad-linden]

@RyeMutt am I understanding this correctly?

[Copilot]

Line 479 uses sGLTextureType[tex_type] but should use GL_TEXTURE_CUBE_MAP for cube maps to match the original behavior. The original code specifically used GL_TEXTURE_CUBE_MAP for the R coordinate, which may be required for proper cube map handling.

Suggested change

	glTexParameteri(sGLTextureType[tex_type], GL_TEXTURE_WRAP_R, sGLAddressMode[mode]);
	glTexParameteri(
	tex_type == TT_CUBE_MAP ? GL_TEXTURE_CUBE_MAP : sGLTextureType[tex_type],
	GL_TEXTURE_WRAP_R,
	sGLAddressMode[mode]);