Ben Sims retweeted
DX12 Bindless Plugin for Unity3D is now open source, and you can use it in your projects! Can be useful for writing a custom GPU Driven Renderer. (github below)
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.
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.
I've been seeing some 'branchless code' posts making the rounds again. The posts are aimed at CPU, but the same approach seems to be common for shaders too. Replacing conditionals with math is generally always going to be bad. If it helps, your code is probably compiling badly.
Hey, don't "optimize" conditional moves with mix()+step(). Please stop advising that. Why: iquilezles.org/articles/gpuc…
On a GPU mul/mad/select are full rate, eg the fastest op you can do. On a CPU fp32 mul is fast but it's not going to be faster than a conditional move or select which are single instructions, not branches. If you keep branches simple, compiler will optimise them into conditionals
Every time I implement volumetric lighting (Using froxels) I end up having a huge performance hit from the final raymarch/integration stage. At 1440p and 8x8 tiles I'm seeing nearly 5ms on an RTX 3070 yet the technique was used as early as Assasins Creed 4. What am I missing here
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.
AC4 used 12x12 tiles (190x60 @ 1080p) with 64 or 128 depth tiels and reports 0.116ms on an XboxOne for the final scattering integration pass. They also mention that brute force was the way to go. bartwronski.com/wp-content/u…
So something definitely isn't adding up.
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.
To avoid needing to set the sun to very large angular diameters for soft transitions, I'll probably add a transition region based on angle between light and normal. Since visibility cones are only an approximation and likely to over-occlude, this seems like a reasonable tradeoff.















