Page MenuHome

Optix render errors with motion blur and unknown bone constraint relationship
Closed, ResolvedPublicBUG

Description

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 px \
| 0 sy c py |
\ 0 0 sz pz /

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 factors more inline with what OptiX uses, but I'll need to do some testing to make sure this wouldn't break anything.

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Confirmed.Jan 15 2020, 8:17 PM
Philipp Oeser (lichtwerk) changed the subtype of this task from "Report" to "Bug".

I am getting the following [which is very likely caused by trying this in a hacked build on a non-RTX 970m...]

Failed to build OptiX acceleration structure
OptiX CUDA error CUDA_ERROR_INVALID_CONTEXT in cuMemAlloc(&motion_transform_gpu, motion_transform_size), line 1450

Leaving that aside, I would assume from the previous comments that this is actually confirmed, @Patrick Mours (pmoursnv)?

The invalid context error has been fixed in rBff430dea663521f742ff2f8f79b5d7f4978ecc04, but that was just a simple oversight. But yes, this is confirmed.
It is also relevant for D6575, since Embree uses the same decomposition (see RTCQuaternionDecomposition documentation, they call the parameters "skew" and "shift") that OptiX uses.