<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi!</p>
<p>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.</p>
<p>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.</p>
<p>In terms of implementation, you'd want to:</p>
<p>- Add the model parameters to
intern/cycles/blender/addon/properties.py and ui.py</p>
<p>- 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).<br>
Two hints here:<br>
1., RNA_float_get accesses the properties you define in Cycles.<br>
2., generally speaking it helps a lot to follow a similar variable
through the code - here, aperture_ratio would be a good example.<br>
</p>
<p>- Handle the actual sampling in camera_sample_aperture.</p>
<p>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.</p>
<p>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.<br>
</p>
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.<br>
<br>
As for the process: Patch review is done on
<a class="moz-txt-link-freetext" href="https://developer.blender.org">https://developer.blender.org</a>. For your first patch, I'd suggest
creating a local branch, coding the feature, creating a diff based
on it, then uploading that on
<a class="moz-txt-link-freetext" href="https://developer.blender.org/differential/diff/create/">https://developer.blender.org/differential/diff/create/</a>. Later, you
could set up Arc to automate that process.<br>
<br>
Afaik there's no official document for the code layout, but a basic
guideline is (all paths in intern/cycles/):<br>
- /kernel/: Compute kernels, code here generally is compiled for
CPU, CUDA and OpenCL and runs the actual computations.<br>
- /render/: Host side of Cycles, handles data syncing to the device,
the general rendering process etc.<br>
- /device/: Device abstraction layer, sits between Host and Device
Kernels<br>
- /blender/: Blender-specific glue logic, implements the interface
between the Blender Renderer API and the Cycles Host code.<br>
- /util/: Utility functions, used on host and/or device.<br>
<br>
Lukas<br>
<br>
<div class="moz-cite-prefix">On 31.10.2017 14:41, Jan Scheffczyk
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b6d14216-091f-b7e3-dd1f-7df38c77a1b4@m1234.de">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div class="moz-text-plain" wrap="true" style="font-family:
-moz-fixed; font-size: 12px;" lang="x-unicode">
<pre wrap="">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:
<a class="moz-txt-link-freetext" href="https://knork.org/realistic-bokeh.html" moz-do-not-send="true">https://knork.org/realistic-bokeh.html</a>
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
<div class="moz-txt-sig">--
w: <a class="moz-txt-link-freetext" href="https://knork.org" moz-do-not-send="true">https://knork.org</a>
</div></pre>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bf-cycles mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a>
<a class="moz-txt-link-freetext" href="https://lists.blender.org/mailman/listinfo/bf-cycles">https://lists.blender.org/mailman/listinfo/bf-cycles</a>
</pre>
</blockquote>
<br>
</body>
</html>