- 23 8月, 2021 2 次提交
-
-
由 Matt Pharr 提交于
-
由 Matt Pharr 提交于
(Following a02c2d0c.) This includes two minor bugfixes related to proportional PDFs from BxDFs and volumetric emission that also eliminate consistencies with the VolPathIntegrator.
-
- 22 8月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
s/T_hat/beta/g s/uniPathPDF/inv_w_u/g s/lightPathPDF/inv_w_l/g In preparation for changes corresponding to a02c2d0c. Note that the variable names do not match their actual usage, but this makes the forthcoming actual logic changes easier to review. logic changes
-
- 19 8月, 2021 1 次提交
-
- 18 8月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
-
- 13 8月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
Qualify Medium::IsEmissive() with PBRT_CPU_GPU Get rid of the MediumSample structure; pass the various appropriate values directly to the lambda passed to SampleT_maj() rather than wrapping them up into that. Simplify MediumInteraction to not include sigma_* and Le (it's not necessary and just causes a bunch of data copying.)
-
- 12 8月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
Make SampleT_maj a standalone function Otherwise minor variable renaming and restructuring.
-
- 22 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
-
- 20 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
-
- 16 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
Rather than tracking them along with the ray (and incurring the corresponding bandwidth and memory costs), we always use the Camera::Approximate_dp_dxy() method, which may mis-estimate them in the presence of specular reflection and refraction, though generally works well. Mostly addresses issue #10.
-
- 14 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
This way, we can not increment the ray depth when it passes through a surface that markes the boundary between different media, matching the behavior of the regular CPU path. In particular, this fixes some undesirable noise in the wavefront integrator (and different behavior from the regular CPU path) that was due to the ray depth being incorrectly tracked in scenes with participating media and then Russian roulette inadvertently being applied after the very first surface intersection.
-
- 08 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
-
- 03 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
* Generalize GPU rendering path to run on both CPU and GPU Now we have a WavefrontIntegrator that can both run on the CPU (backed by ParallelFor() for parallelization and pbrt's aggregates for ray intersection acceleration) and on the GPU (backed by GPUParallelFor() for parallelization and OptiX for ray intersection on NVIDIA GPUs.) Beyond generalizing the code, this refactor allows CPU-side debugging and testing of the wavefront integrator. Doing so allows further isolation of the GPU-specific code into a few source files, now just ~2.5k lines of code. This includes a bug fix in the wavefront medium code to resolve MixMaterials to one of their constituent materials before enqueuing material evaluation and shading work. Note that on the CPU, the wavefront integrator runs 5-10x more slowly than pbrt's regular CPU integrators, so it is not recommended for regular use... Co-authored-by: NWenzel Jakob <wenzel.jakob@epfl.ch>
-