build(dynamic cubemaps): fix X4000 warning

[davo0411]

didn't see anything out of the blue but review is definitely needed.
should address warning X4000 (“use of potentially uninitialized variable”) in dynamic cubemaps

Summary by CodeRabbit

• Bug Fixes
  • Refined dynamic cubemap skylighting specular handling to ensure specular irradiance and reflection terms are computed only where appropriate, improving blending and reducing lighting artifacts—results in more consistent lighting between interior and exterior scenes.
• Chores
  • Dynamic Cubemaps version updated (2.3.0 → 2.3.1).

[coderabbitai]

📝 Walkthrough

Walkthrough

Refactors DynamicCubemaps shaders to zero-init skylightingSpecular and compute it only for exteriors; in non-IBL fallback, specular irradiance/reflections default to 0.0 and are sampled only when skylighting thresholds apply; feature INI version bumped.

Changes

Skylighting Specular Refactor & Irradiance Defaulting

Layer / File(s)	Summary
Specular Computation (data/logic) features/Dynamic Cubemaps/Shaders/DynamicCubemaps/DynamicCubemaps.hlsli	GetDynamicCubemapSpecularIrradiance: skylightingSpecular now 0.0 by default and computed via Skylighting::EvaluateSpecular(...) only when !SharedData::InInterior (removes local SH lobe and interior branch).
Specular Computation (wiring/logic) features/Dynamic Cubemaps/Shaders/DynamicCubemaps/DynamicCubemaps.hlsli	GetDynamicCubemap: initialize skylightingSpecular = 0.0 and call Skylighting::EvaluateSpecular(...) only for exteriors (replaces prior 1.0-init plus branch).
Non-IBL Fallback (wiring/conditions) features/Dynamic Cubemaps/Shaders/DynamicCubemaps/DynamicCubemaps.hlsli	Non-IBL fallback: specularIrradianceReflections and specularIrradiance default changed from 1.0 to 0.0; each term is computed only when skylightingSpecular > 0.0 (reflections) or skylightingSpecular < 1.0 (environment), then blended with lerp(...).
Metadata features/Dynamic Cubemaps/Shaders/Features/DynamicCubemaps.ini	Version bumped from 2-3-0 to 2-3-1.
Tests / Docs n/a	No test or public API changes detected.

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant GetDynamicCubemap
  participant SharedData
  participant Skylighting
  participant EnvSampler
  Client->>GetDynamicCubemap: request cubemap
  GetDynamicCubemap->>SharedData: check InInterior
  SharedData-->>GetDynamicCubemap: InInterior flag
  alt exterior
    GetDynamicCubemap->>Skylighting: EvaluateSpecular(...)
    Skylighting-->>GetDynamicCubemap: skylightingSpecular
  else interior
    GetDynamicCubemap-->>GetDynamicCubemap: skylightingSpecular = 0.0
  end
  GetDynamicCubemap->>EnvSampler: sample env / reflections (gated by skylightingSpecular)
  EnvSampler-->>GetDynamicCubemap: specular terms
  GetDynamicCubemap-->>Client: blended cubemap

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• community-shaders/skyrim-community-shaders#1696 — Modifies specular logic in the same DynamicCubemaps functions.
• community-shaders/skyrim-community-shaders#1841 — Related edits to DynamicCubemaps.hlsli specular routines.
• community-shaders/skyrim-community-shaders#1376 — Changes interior skylighting/specular handling in the same functions.

Suggested reviewers

• doodlum
• jiayev
• alandtse

Poem

🐰
I nudge the shader, soft and light,
Ternaries tucked away from sight,
Defaults fall quiet, zeroed and neat,
Cubemaps hum with subtler beat,
A rabbit hops — the pixels bright.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title accurately reflects the main change: fixing an X4000 compiler warning in dynamic cubemaps shader code through reinitialization logic.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

No actionable suggestions for changed features.

[Copilot]

Pull request overview

This PR targets an HLSL compiler warning (X4000: “use of potentially uninitialized variable”) in the Dynamic Cubemaps feature’s shader code.

Changes:

• Refactors skylightingSpecular computation in two functions to a single-expression assignment.
• Reorders/initializes specular irradiance variables in the non-IBL skylighting fallback path to ensure defined values across control flow.

[coderabbitai]

🧹 Nitpick comments (1)

features/Dynamic Cubemaps/Shaders/Features/DynamicCubemaps.ini (1)

2-2: 💤 Low value

Consider refining the PR title per coding guidelines.

The current title "build: fix dynamic cubemaps X4000 warning" follows conventional commits format, but "fix" might be more appropriate than "build" since this addresses a compiler warning in shader code rather than build system changes.

Suggested alternative:

fix(dynamic-cubemaps): resolve X4000 compiler warning

Also, if this PR addresses an existing issue, consider adding a reference in the PR description:

• "Fixes #<issue_number>" for bug fixes
• "Closes #<issue_number>" for feature completion

As per coding guidelines, conventional commit titles should follow https://www.conventionalcommits.org/ format with appropriate type, scope, and description.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@features/Dynamic` Cubemaps/Shaders/Features/DynamicCubemaps.ini at line 2,
Update the PR title to follow conventional commits by changing the type and
scope to reflect a code fix rather than a build change (for example:
"fix(dynamic-cubemaps): resolve X4000 compiler warning") and, if this PR
resolves an existing issue, add "Fixes #<issue_number>" or "Closes
#<issue_number>" to the PR description; ensure the new title and any issue
reference align with the repository's conventional commit guidelines.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@features/Dynamic` Cubemaps/Shaders/Features/DynamicCubemaps.ini:
- Line 2: Update the PR title to follow conventional commits by changing the
type and scope to reflect a code fix rather than a build change (for example:
"fix(dynamic-cubemaps): resolve X4000 compiler warning") and, if this PR
resolves an existing issue, add "Fixes #<issue_number>" or "Closes
#<issue_number>" to the PR description; ensure the new title and any issue
reference align with the repository's conventional commit guidelines.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 283cf45e-7820-4b03-b1cc-2290fd80d53d

📥 Commits

Reviewing files that changed from the base of the PR and between 45dcc63 and 1c19ab3.

📒 Files selected for processing (1)

• features/Dynamic Cubemaps/Shaders/Features/DynamicCubemaps.ini

[coderabbitai]

🧹 Nitpick comments (1)

features/Dynamic Cubemaps/Shaders/DynamicCubemaps/DynamicCubemaps.hlsli (1)

1-1: ⚡ Quick win

Consider tightening PR title and linking the tracking issue.

Suggested title: fix(dynamic-cubemaps): resolve x4000 uninitialized warning
If there is a tracker, add Closes #<id> in the PR description.

As per coding guidelines, "Conventional Commit Titles ... Format: type(scope): description" and "Issue References ... Suggest adding appropriate GitHub keywords."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@features/Dynamic` Cubemaps/Shaders/DynamicCubemaps/DynamicCubemaps.hlsli at
line 1, Update the PR title to follow Conventional Commits (type(scope):
description) using the suggested tightened title `fix(dynamic-cubemaps): resolve
x4000 uninitialized warning` and add an issue reference in the PR description
like `Closes #<id>` if there is a tracker; also ensure the commit message that
touched the DYNAMICCUBEMAPS_HLSLI header guard follows the same format so the
change is properly linked to the tracker.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@features/Dynamic` Cubemaps/Shaders/DynamicCubemaps/DynamicCubemaps.hlsli:
- Line 1: Update the PR title to follow Conventional Commits (type(scope):
description) using the suggested tightened title `fix(dynamic-cubemaps): resolve
x4000 uninitialized warning` and add an issue reference in the PR description
like `Closes #<id>` if there is a tracker; also ensure the commit message that
touched the DYNAMICCUBEMAPS_HLSLI header guard follows the same format so the
change is properly linked to the tracker.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 57e54dae-334f-4722-b4f1-a606860bd95a

📥 Commits

Reviewing files that changed from the base of the PR and between 1c19ab3 and 2f26512.

📒 Files selected for processing (1)

• features/Dynamic Cubemaps/Shaders/DynamicCubemaps/DynamicCubemaps.hlsli

[doodlum]

@coderabbitai does this change any functionality or is the output identical

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
git diff HEAD~1 HEAD -- "features/Dynamic Cubemaps/Shaders/DynamicCubemaps/DynamicCubemaps.hlsli"

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Get the PR diff via GitHub CLI
gh pr diff 2278 --repo community-shaders/skyrim-community-shaders

# Also cat the file for context
cat "features/Dynamic Cubemaps/Shaders/DynamicCubemaps/DynamicCubemaps.hlsli"

Length of output: 3834

---

@doodlum Great question — I went through the diff carefully.

TL;DR: The output is functionally identical for all valid inputs.

Here's the breakdown:

---

Change 1 — skylightingSpecular initialization (both functions)

The old code initialized to 1.0, then set it to 0.0 in an explicit else branch. The new code initializes to 0.0 and skips the else:

Scenario	Old result	New result
Interior	1.0 → else → 0.0	0.0 (default)
Non-interior	EvaluateSpecular(...)	EvaluateSpecular(...)

✅ Identical in both paths. The specularLobe intermediate variable is also just inlined — no semantic change.

---

Change 2 — specularIrradiance / specularIrradianceReflections defaults (1.0 → 0.0)

The final output uses lerp(specularIrradiance, specularIrradianceReflections, skylightingSpecular). Checking each case:

skylightingSpecular	Old lerp(...)	New lerp(...)
== 0.0	lerp(sampled, 1.0, 0.0) = sampled	lerp(sampled, 0.0, 0.0) = sampled ✅
== 1.0	lerp(1.0, sampled, 1.0) = sampled	lerp(0.0, sampled, 1.0) = sampled ✅
0 < t < 1	both variables sampled, same lerp	both variables sampled, same lerp ✅
< 0 or > 1	extrapolates with 1.0 default	extrapolates with 0.0 default ⚠️

The only theoretical difference is for out-of-range skylightingSpecular values (below 0 or above 1), but Skylighting::EvaluateSpecular should always return values in [0, 1], making this a non-issue in practice.

---

Conclusion: This is a safe, purely cosmetic/compiler-hygiene fix. The rendered output should be bit-for-bit identical under normal conditions.

[alandtse]

These aren't fixes. These are compilation warnings.