Page MenuHome

Optix render errors with motion blur and unknown bone constraint relationship
Open, Needs Triage by DeveloperPublic


System Information
Operating system: Linux-5.3.0-19-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 435.21

Blender Version
Broken: version: 2.81 (sub 16), branch: master, commit date: 2019-11-03 03:57, hash: rB8ab6ef30ab28
Worked: (optional)

Short description of error
For the past couple of hours I've been trying to figure out what exactly is causing this bug, so apologies for it being a bit vague.

Find attached part of a character from a project I'm currently working on. When rendering with Optix with motion blur switched on, the character shows errors on certain parts of the body, the eye being one of them. I've stripped the rig down as far as I can while keeping the bug active, but I can't narrow it down further to find the exact cause. I believe it's something to do with the stretch to constraint on the 'body' bone, which is also squashing the eye bone. The error doesn't occur when rendering with CUDA.

Currently, the eye is parented to the eye.l bone. If the the Armature modifier is used instead of parenting, the render error doesn't occur.

Exact steps for others to reproduce the error
Open 'rtx-optix-motion-blur-bug.blend'.
Change Cycles Render Device to OptiX and hit render
Turn off motion blur and hit render.
Compare results.



Event Timeline

So, this is an interesting one. The problem here is that there is a mismatch between the motion SRT transform that OptiX uses for traversal and the one Cycles computes for shading. Which causes these artifacts.

OptiX essentially expects a SRT with a scaling/shear matrix of the form

/ sx a b \
| 0 sy c |
\ 0 0 sz /

But the transform decomposition code in Cycles generates a scaling matrix of the form

/ sx d e \
| d sy f |
\ e f sz /

Currently the OptiX implementation in Cycles mistakenly assumes that a = d, b = e and c = f, which is why things go wrong. I think the cleanest way to fix this is to modify the decomposition code to create a scaling matrix more inline with what OptiX uses, but I'll need to do some more testing to make sure this wouldn't break anything.