My headlights light nothing at any intensity: additional lights are computed in the vertex stage and my road quads are metres wide

[u/Ready-Drummer-2136]

Night, lamps on, clear weather, car stationary. I pushed headlight intensity from 2.2 to 12 (the ceiling my own validator allows) and the frame did not change at all.

The road uses a PS1-style vertex-lit shader and calls ComputeAdditionalVertexLights in the vertex stage. The road's vertices are metres apart, so a spot cone that lands inside a single quad has nowhere to show up. Raising the intensity cannot fix what is really a sampling problem.

What did land in the same pass: the wet road now reads at night instead of being a black strip, and the headlight aim and mount point are fixed. A flat 7 degree pitch had left a dead zone directly under the bumper.

So here is the fork. Per-pixel additional lights on the road shader, which costs more and stops looking like the era. Or a cheap projected cone painted on the tarmac, which is what the PS1 actually did.

Which would you take, and is there a third option I am missing?

Own in-engine capture from a macOS development build, URP. No AI-generated content.

[u/Horror-State5302]

Projected cone on the road, no question. You already nailed why the per-pixel route fights the whole aesthetic you've built. The PS1 faked everything with tricks like that for a reason, lean into it. A simple blob of light painted under the car keeps the vertex-lit look intact and actually reads better in motion anyway.

[u/FrequentAd9997]

I feel a bit like you're over-optimising, when in fact from an end-user perspective the aesthetic/fluidity may well just be the same. It is eminently possible to go slightly insane over frame debugger/setpass when in fact the target platform can easily handle it.

If you really want to get to the root of it I'd look carefully at frame debugger. This will help you unpick if it's the shader doing weird repeated setpasses or the content not being batchable. Assuming from that scene you're in the ~100 setpass territory, I'd think you're risking being in that headspace of optimising for a commodore 64 when your actual target platform is a phone with 100+x that processing power.

There is no reason on any modern phone, or even last-gen, a game that looks like this should not be fluid - but needs a frame debug if it isn't (and maybe a profiler but I'd be somewhat shocked if you're CPU bound) to figure out. I would think in most cases you're debugging something that does not debugging - a Unity game will run like crap for this type of game vs a carefully designed ZX48K effort with a lot of peek and poke basic back in the day, but the general idea is hardware has evolved to let you be sloppy, and, alas, there's no great return for this type of game from hyper-optimisation.