[Bf-cycles] Optical vignetting by biasing lens sample position and contribution

[Lukas Stockner]

Hi!

Your parametrization of the bokeh shape seems pretty good, the only 
issue I can see is that certain parameter combinations result in 
negative values which shouldn't happen I guess.

But yeah, camera aperture sampling is a pretty good spot for starting, 
it's fairly localized and you don't have to consider some of the more 
tricky areas of Cycles yet.

In terms of implementation, you'd want to:

- Add the model parameters to intern/cycles/blender/addon/properties.py 
and ui.py

- Pass the values through to the kernel (relevant files: 
intern/cycles/blender/blender_camera.cpp, 
intern/cycles/render/camera.cpp and .h, 
intern/cycles/kernel/kernel_types.h).
Two hints here:
1., RNA_float_get accesses the properties you define in Cycles.
2., generally speaking it helps a lot to follow a similar variable 
through the code - here, aperture_ratio would be a good example.

- Handle the actual sampling in camera_sample_aperture.

Regarding your pitfalls: If you absolutely need to use rejection 
sampling, you can instruct the code to disregard that camera sample by 
setting ray->t to zero in the respective camera_sample_... function. For 
weighting, you'd indeed want to modify the throughput, so you'd need to 
return it all the way to kernel_path_trace.

However, I really don't like the idea of using rejection sampling here - 
since the model is analytically integrateable, proper inversion sampling 
should be possible. If there's no way to find a analytical inversion, I 
guess using some basic approximation and a few iteration of 
Newton-Raphson should be easily good enough and still a lot faster than 
rejection sampling (especially on GPUs, rejection sampling kills 
parallelism). Also, if you sample perfectly you don't need to modify the 
throughput of course.

Regarding integration into master: Hard to say for sure, but I think 
this is a reasonable feature that doesn't require large-scale 
modifications and is unlikely to have any downsides as long as it's 
disabled, so I guess they're decent.

As for the process: Patch review is done on 
https://developer.blender.org. For your first patch, I'd suggest 
creating a local branch, coding the feature, creating a diff based on 
it, then uploading that on 
https://developer.blender.org/differential/diff/create/. Later, you 
could set up Arc to automate that process.

Afaik there's no official document for the code layout, but a basic 
guideline is (all paths in intern/cycles/):
- /kernel/: Compute kernels, code here generally is compiled for CPU, 
CUDA and OpenCL and runs the actual computations.
- /render/: Host side of Cycles, handles data syncing to the device, the 
general rendering process etc.
- /device/: Device abstraction layer, sits between Host and Device Kernels
- /blender/: Blender-specific glue logic, implements the interface 
between the Blender Renderer API and the Cycles Host code.
- /util/: Utility functions, used on host and/or device.

Lukas

On 31.10.2017 14:41, Jan Scheffczyk wrote:
> Dear Cylces-gurus,
>
> i have recently looked into DOF/Bokeh shape and distribution and how to
> approximate them by altering the lens sampling. For this i used the
> pbrt-v3 ray-tracer which is probably familiar to most of you. You can
> find a article on what exactly i implemented here:
>
> https://knork.org/realistic-bokeh.html
>
> As my modification to the lens-sampling requires very little interaction
> with the rest of the ray-tracing system i figured it would be a great
> project to get started with in cycles. I just quickly skimmed through
> the cycles code and it would probably alter/replace the
> /inter/cycles/kernel/kernel_camera.h::camera_sample_aperture(...) and of
> course add some parameters to the kernel_data as well as some function
> parameters.
>
> I see two possible pitfalls so far:
> 1. I use rejection sampling for the optical vignetting thus it needs to
> be ensured that they not integrated.
> 2. I am guessing that throughput is something like the weight which i
> could simple create before lens sampling and use to store the weight.
>
> Anyways my question if i where to implement this in cylces what are the
> odds of it actually making it into the master branch? How should i go
> about developing? Creating a new branch and after a merge request? I've
> also read that you add small changes through patch files.
>
> Also is there a document that describes the design of the cycles code?
>
> Thanks for your time.
>
> Greeting Knork
>
>
> -- w: https://knork.org
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-cycles/attachments/20171102/b41607c9/attachment.html>