perf(lighting): shader-based light bubbles + organize into lighting/

[santi1584]

Summary

Phase 3 of the lighting optimization: the 256×256 canvas-rendered light mask is gone. Each light is now a Mesh with a custom fragment shader that computes the radial gradient per pixel.

Three wins:

• VRAM — the canvas mask texture is deleted. The shader runs from a tiny shared unit-quad geometry; no per-light texture data.
• Smoothness — a Great Light scaled up no longer shows gradient banding; the falloff is mathematical.
• uTime plumbed — a uTime uniform is wired into the shader (currently unused). A torch-flicker pass can land later without any CPU work, just by sampling sin(uTime * k).

Shader cross-platform: ships both GLSL (300 es) for WebGL and WGSL for WebGPU. The vertex shader piggy-backs on Pixi's auto-assigned globalUniforms (group 0) and localUniforms (group 1) for the projection/world/transform matrices; our lightUniforms is group 2.

Falloff math: clamp(1 - (r - coreSize)/(1 - coreSize), 0, 1)^2 with coreSize = 0.1. Keeps the small flat core the canvas mask had, then a clean quadratic ramp to zero — no piecewise stops.

Bundled small fixes:

• The overlay Sprite is now caller-owned (was reallocated per rebuildTiles). Caller detaches it before tileContainer.destroy({ children: true }) so it survives the destroy.
• createLightMaskTexture and the lightMask parameter are gone.
• Reorganized lib/lighting.ts into lib/lighting/{index.ts,shader.ts} matching the existing lib/render/ pattern; the public import path (./lib/lighting) is unchanged so callers don't move.

PR is over the 100-line target (~150 net new) — the cross-platform shader code is the main bulk. Acceptable trade-off vs. dropping WebGPU support.

Test plan

• npx tsc --noEmit clean
• npx eslint clean
• npx vitest run — 37 files / 359 tests pass
• npm run build succeeds (shaders bundle as strings)
• Load the client and verify torches/lamps look right at night. Check both:
  • Chrome/Edge (WebGPU path): console should still log [render] PixiJS renderer: webgpu
  • Safari (WebGL path): console should log [render] PixiJS renderer: webgl
• Stand still and toggle Night a few times — confirm no leaks in DevTools heap snapshots
• Walk near a Great Light radius (intensity 7 or higher) and verify the gradient is smooth at the edges

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@santi1584, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 17 minutes and 57 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: cdc68120-2314-41a3-b480-eb91881540db

📥 Commits

Reviewing files that changed from the base of the PR and between 33caea8 and a944827.

📒 Files selected for processing (4)

• src/lib/lighting.ts
• src/lib/lighting/index.ts
• src/lib/lighting/shader.ts
• src/main.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/lighting-shader

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	otclient-web	a944827	Commit Preview URL Branch Preview URL	Jun 10 2026, 04:24 PM

[gemini-code-assist]

Code Review

This pull request replaces the sprite-based lighting system with a more efficient shader-based mesh system using custom GLSL and WGSL shaders. It introduces a LightMeshPool to recycle meshes and a new shader-based approach for rendering light bubbles with quadratic falloff. A critical issue was identified in the WGSL fragment shader where a missing closing brace would cause compilation errors on WebGPU-enabled browsers.

[gemini-code-assist]

The WGSL fragment shader mainFrag is missing a closing brace }. This will cause a shader compilation error on WebGPU-enabled browsers.

Additionally, for consistency with the GLSL fragment shader, it would be beneficial to include the comment explaining that uTime is plumbed for future use. This helps other developers understand why the uniform is present but unused.

fn mainFrag(input: VSOut) -> @location(0) vec4<f32> {
  let d = input.vUV - vec2<f32>(0.5);
  let r = length(d) * 2.0;
  let t = clamp(1.0 - (r - lightUniforms.uCoreSize) / (1.0 - lightUniforms.uCoreSize), 0.0, 1.0);
  let intensity = t * t;
  // uTime is plumbed but unused — reserved for a future torch flicker pass
  // (e.g. intensity *= 1.0 + 0.05 * sin(uTime * 6.0)) without CPU work.
  return vec4<f32>(lightUniforms.uTint * intensity, intensity);
}

[santi1584]

@gemini-code-assist confirmed real — and worse than 'compilation error on WebGPU-enabled browsers' suggests: PixiJS prefers WebGPU when available, so the broken WGSL bites modern Chrome by default rather than staying on the GLSL path. Will be fixed as part of the rebase plan in my assessment comment.

[gemini-code-assist]

Thanks for the confirmation, @santi1584. Since you are planning to address this in your upcoming rebase, I will leave this thread open for now. Please ensure the final WGSL implementation includes the closing brace and the requested comment for consistency with the GLSL version once you push the fix.

Suggested change

	fn mainFrag(input: VSOut) -> @location(0) vec4<f32> {
	let d = input.vUV - vec2<f32>(0.5);
	let r = length(d) * 2.0;
	let t = clamp(1.0 - (r - lightUniforms.uCoreSize) / (1.0 - lightUniforms.uCoreSize), 0.0, 1.0);
	let intensity = t * t;
	return vec4<f32>(lightUniforms.uTint * intensity, intensity);
	fn mainFrag(input: VSOut) -> @location(0) vec4<f32> {
	let d = input.vUV - vec2<f32>(0.5);
	let r = length(d) * 2.0;
	let t = clamp(1.0 - (r - lightUniforms.uCoreSize) / (1.0 - lightUniforms.uCoreSize), 0.0, 1.0);
	let intensity = t * t * 0.55;
	// uTime is plumbed but unused — reserved for a future torch flicker pass
	// (e.g. intensity *= 1.0 + 0.05 * sin(uTime * 6.0)) without CPU work.
	return vec4<f32>(lightUniforms.uTint * intensity, intensity);
	}

[santi1584]

Correcting my earlier reply after actually verifying against the current branch: the WGSL is brace-balanced (6 open / 6 close; mainFrag closes properly before the template literal ends). Either this was fixed in a later push or the original finding was off — either way the critical doesn't hold against today's diff, and I repeated it without re-checking first. The remaining blockers are the ones in my assessment: the rebase over the pooling commits and renderer verification. Doing the rebase now.

[santi1584]

Assessment — the direction is right and worth landing, but not mergeable as it stands. Three findings:

1. The critical review comment is real and unaddressed: the WGSL fragment shader is missing its closing brace, which fails shader compilation on WebGPU browsers — and PixiJS prefers WebGPU when available, so this breaks modern Chrome at runtime rather than falling back. Must fix before merge.
2. Three weeks of drift, in the worst place: main since gained 650da85+7824f43, which pooled exactly the sprites and reused exactly the RenderTexture this PR's shader approach deletes. The rebase isn't mechanical — it should consciously remove the pooling layer this supersedes (LightSpritePool, the texture-reuse plumbing in main.ts), or the two approaches will coexist confusingly.
3. Connection to Investigate light issues #125: the visual regression reported there is blamed on the pooling commits (my A/B couldn't reproduce it at spawn — details on the issue). If this PR lands, the implicated code path is deleted wholesale, so Investigate light issues #125 should be re-tested against the shader renderer rather than debugged twice.

Verification constraint: I can validate the GLSL path headlessly (software WebGL), but the WGSL path needs a WebGPU-capable run — worth a manual check on real hardware before merge.

Recommendation: rebase over the pooling commits (removing them as part of the rebase), fix the WGSL brace, verify GLSL headlessly + WGSL on hardware, then merge — and close #125 if the regression doesn't survive the new renderer. Happy to execute the rebase + fix next session; flagging rather than doing it now because shader work without hardware verification is exactly the kind of change that merges green and breaks on someone's phone.

[santi1584]

Rebase done and pushed (b5974d7): merged current main into this branch — the rename detection carried the lighting.ts → lighting/index.ts move cleanly, the pooled-sprite/canvas-mask code from 650da85+7824f43 is consciously gone (only LightMeshPool remains), and main.ts call-sites compile against the shader API alongside all the cache/landing work that landed since. Lint, 475 tests, build all green.

Verification status:

• ✅ GLSL path renders under software WebGL (the offline demo boots and draws with the shader renderer)
• ✅ Ambient parity: at a no-lights-in-frame scene, mask vs shader night renders are byte-identical — the ambient model carried over exactly
• ✅ WGSL re-checked: brace-balanced (the earlier 'missing brace' critical doesn't hold against the current source — corrected in that thread)
• ⏳ Bubble visuals need eyes on hardware: headless A/B at a torch cluster can't pixel-compare (walk positions drift between runs), and the falloff difference — the actual point of this PR — is a quality judgment anyway. One manual night-mode look at torches (WebGL) + one on a WebGPU browser (the WGSL path PixiJS prefers) and this merges.

@santi1584 it's ready for that look whenever you next play-test — and per #125, judge the new falloff against your memory of the good lighting, since this deletes the implicated code path entirely.

[santi1584]

@santi1584 — this PR is ready except for two things only you can do. Clear steps:

1. Visual check of the new shader lighting (~3 min)

npx vite          # in otclient-web, then open http://localhost:5173/map.html

• Walk north ~35 tiles from spawn (hold ↑) until torches/lamps are on screen
• Press N to toggle night mode
• Judge: do the light bubbles look as good or better than you remember from before commits 650da85/7824f43? (Smooth falloff, no banding rings, tint reads at the bubble, not washed white)
• 👍 here if good / describe what looks off if not

2. WebGPU run (~1 min) — the WGSL path PixiJS prefers on modern Chrome

• Same page in regular desktop Chrome (not headless), check the console says [render] PixiJS renderer: webgpu
• If lights still render at night → WGSL works; if the screen is black/broken or it fell back to webgl with shader errors → paste the console error here

Bonus (closes #125 in the same look): while you're at step 1, this branch deletes the code #125 blames — if the lighting looks right here, comment on #125 and we close it.

CI note: the current red is GitHub's auth incident hitting CodeQL's own runner token (third wave today) — I'm retriggering until it sticks; ignore it.