- 20 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
-
- 17 5月, 2021 2 次提交
-
-
由 Matt Pharr 提交于
Also, add a check that issues an error if there is a MixMaterial that uses a complex texture to select between the materials (which isn't supported in the current implementation).
-
由 Matt Pharr 提交于
Implement them for GPU textures. Include the filename for all textures.
-
- 16 5月, 2021 5 次提交
-
-
由 Matt Pharr 提交于
Previously, they effectively required a multiple of 4...
-
由 Wenzel Jakob 提交于
-
由 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.
-
由 Matt Pharr 提交于
(And then explicitly instantiate the templates.) This gives roughly a 10% performance improvement for the kernels that call this on the GPU.
-
由 Matt Pharr 提交于
No effect currently other than using more memory (since the provided filter widths are all zero) and a 10-15% performance loss in the Coated*Material kernels due to that much more register pressure...
-
- 15 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
-
- 14 5月, 2021 2 次提交
-
-
由 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.
-
由 Matt Pharr 提交于
-
- 13 5月, 2021 3 次提交
-
-
由 Matt Pharr 提交于
- Renamed method and updated signature to not be SurfaceInteraction-dependent. - Inlined implementation and added check for CameraBase implementation to improve dispatch performance.
-
由 Matt Pharr 提交于
In turn, this gives us valid dzdx and dzdy values with GBuffer film.
-
由 Matt Pharr 提交于
Now a MultiWorkQueue templated on the phase function type is used for enqueuing work items for sampling direct/indirect lighting in media. With Henyey-Greenstein as the only phase function currently available, this reduces to the previous behavior, but it makes it easier to add new phase functions in the future. Also piped through time in a few places it was missing in the medium-related work queues.
-
- 12 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
-
- 11 5月, 2021 3 次提交
-
-
由 Wenzel Jakob 提交于
Removed another unused BSDF member. Other very minor changes; functionality unaffected.
-
由 Matt Pharr 提交于
Issue #129.
-
由 Matt Pharr 提交于
-
- 08 5月, 2021 3 次提交
-
-
由 Matt Pharr 提交于
Before we were supplying any hit shaders and asking OptiX for all intersections, once, along each probe ray. For reasons unclear, results were darker on the GPU than on the CPU. This implementation successively finds the closest hit along the segment, spawning a new ray after each intersection. With this, both CPU and GPU subsurface scattering images match (modulo noise).
-
由 Matt Pharr 提交于
Improvement to 852829c7; rarely, SampleWavelengths() would compute a lambda that was just slightly above Lambda_max, which led to NaNs...
-
由 Matt Pharr 提交于
-
- 07 5月, 2021 2 次提交
-
-
由 Matt Pharr 提交于
Given the same acceleration structure, then the images they generate should now match exactly (if there is no SSS or participating media, at least.)
-
由 Matt Pharr 提交于
via Nathan Vegdahl: https://psychopath.io/post/2021_01_30_building_a_better_lk_hash and then subsequent improvements communicated via email.
-
- 06 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
Assorted cleanups; no functional changes.
-
- 05 5月, 2021 2 次提交
-
-
-
由 Matt Pharr 提交于
Fixes #128.
-
- 04 5月, 2021 4 次提交
-
-
由 Matt Pharr 提交于
-
由 Matt Pharr 提交于
Relates to issue #100, #96, #89, and #48...
-
由 Matt Pharr 提交于
This fixes many of the Windows+GPU crashes. Issues #96, #100, and more...
-
由 Matt Pharr 提交于
-
- 03 5月, 2021 3 次提交
-
-
由 Matt Pharr 提交于
-
由 Matt Pharr 提交于
-
由 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>
-
- 01 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
Issue #124.
-
- 30 4月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
-
- 29 4月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
-
- 28 4月, 2021 4 次提交
-
-
由 Matt Pharr 提交于
-
由 Matt Pharr 提交于
-
由 Matt Pharr 提交于
Fixes #25
-
由 Matt Pharr 提交于
-