Page MenuHome

Cycles: Add lens distortion to the camera model
Needs RevisionPublic

Authored by Lukas Stockner (lukasstockner97) on Apr 4 2016, 9:07 PM.

Details

Summary

This commit adds the option to choose a movie clip in the camera settings, which will make Cycles
deform the rendered image according to the lens parameters of the clip.
This could already be done with the Movie Distortion node set to "Distort" in the Conmpositor,
but doing it directly in Cycles means that no unneccessary areas are rendered, areas that would
otherwise be outside of the frame are still rendered, there are no interpolation artifacts in the
result and the ray derivatives are correct.

Since LibMV can't be called from the kernel, the distortion model has to be inverted directly.
Blender only uses the radial distortion components, though, which means that simply inverting
the radius distortion using a few Newton iterations works well enough.

Diff Detail

Repository
rB Blender
Branch
lens_distortion

Event Timeline

Lukas Stockner (lukasstockner97) retitled this revision from to Cycles: Add lens distortion to the camera model.

`This is something what iwas playing around in the camera nodes actually and edned up being inconvinced we need to implement it as a part of path tracing kernel. Depending on complexity of model you might need more or less iterations needed to converge, we might want to extend distortion models even further..

And currently i'm tempting to think that as path tracing kernel is concerned it should be simply a 2D texture which defines raymapping. Reasoning:

  • It is actually what some other engines are using, so could be some existing databases of all possible cameras (you can find it by the name of UV remap)
  • There's no time penalty per camera ray (well, it's minimal and constant -- does not depend on how comples your camera model is)
  • It avoids any heavy calls such as solving LSM problems which is really good for GPUs.

Surely it has some downsides like precision, but in fact for lens distortion/undistortion we already using lookup table which then gets bicubic filetred.

So think using 2D texture in kernel is good for both short and long terms solutions:

  • For short-term solution (aka before camera nodes, if they happen) we'll have all weird and wonderful lens effects outside of kernel (keeping it small and simple. hey, we're removing sky model to keep it elegant, but keeping adding stuff which isn't so widely used either!)
  • For a long term solution (aka, camera nodes) we'll want to bake the tree ahead of a time to inimize performance losses caused by nodes evaluation during sampling.

At leats that's my vision.

P.S. We've been discussion nodes with Brecht and Martijn in the past, so adding them to the conversation.
P.P.S. Nice feature, just think something to be implemented differently.

I agree with @Sergey Sharybin (sergey). This can be a texture lookup in the kernel, I'm not too worried about precision loss. Any nodes or more advanced models can be baked to a texture.

Sergey Sharybin (sergey) requested changes to this revision.Apr 22 2020, 10:30 AM
This revision now requires changes to proceed.Apr 22 2020, 10:30 AM