[Bf-cycles] Optical vignetting by biasing lens sample position and contribution
lukas.stockner at freenet.de
Thu Nov 2 05:36:26 CET 2017
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
- Pass the values through to the kernel (relevant files:
intern/cycles/render/camera.cpp and .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.
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:
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-cycles