Decided to try implementing camera-roll when strafing without relying on broken physics. It works reasonably well, using the same quaternion spring damping as my weapon-recoil camera shake. This is more camera shake than you'd want for a casual FPS, but might suit a tactical one.

(Here is the less broken version for completion. Trying to find a nice balance between root-motion/animation-driven camera/player movement, procedural effects, and control. Making it framerate+physics framerate independent is a fun challenge, this is for multiplayer+perf reasons)

Turns out if you accidentally break some player rigidbody interpolation logic, your game ends up feeling like the game Bodycam. Maybe this was their trick all along. The accidental lean is cool tho. Windows having bad HDR capture making the game look super overexposed also helps

I often see "Use a PID controller" in response to "How do I achieve a given rotation using physics/torque?" If you know how the physics engine updates rotation, you can derive an exact torque. This is the code for Unity/PhysX, and an example rotating in a single frame.

Just some mildly moody screenshots from the thing that I'm trying to make into a thing. Also pictured: rewritten gpu driven foliage, terrain and grass renderers. Writing a device radix sort was fun-ish. Currently reworking the terrain shader, needs better height blending.

Exhibit A. This is HDRP's default 'lit' shader. Each variant doubles the total number of shader variants. This is not how the core shader of an engine should be designed.

I'm also using a logarithmic depth partition, but afaik this is pretty common, and simplifies to a mad and an exp2, so nowhere near enough ALU to cause concern on a modern GPU. I'm guessing maybe there's less coalescing in the reads/writes, or something related to thread layout.

Granted I'm doing a little bit more work than usual since I'm combining atmospheric extinction with the luminance+extinction of the volume, but if anything, the extra ALU should be hidden by the latency of texture reads anyway. Maybe parallel sum is the way to go?

A close-up example. Due to insufficient terrain tessellation, some gaps in the shadowmap appear. Combining with the terrain micro-shadows reduces this. (Will fix properly with better terrain soon, once I rip out Unity's ancient heightmap rendering system)

Results without any shadow mapping. The technique can add plausible shadowing outside of the max shadowmap range. Nice for reducing light leaking, and most of the work is done in the precomputation stage.