The adapt from enigmatisms

Ada Path Tracer is a simple Monte Carlo path tracing renderer based on Taichi Lang, with which you can play easily. The name AdaPT is given by my GF and I think this name is brilliant. Currently, this renderer stops at version 1.5.x, since I think I should focus on something else until we have a better version of the backend (Taichi).

This renderer is implemented based on MY OWN understanding of path tracing and other CG knowledge, therefore I DO NOT guarantee usability. The output results look decent nevertheless:

Steady state rendering

For more example scenes, please refer to Enigmatisms/AdaptiveGallery

Sports car scene (~290k primitives, 16 bounces, with many different BxDFs):

Bathroom scene (~400k primitives, 8 bounces, source can be found here):

Material orb scene (~500k primitives, 24 bounces, CUDA backend 16 fps):

Kitchen scene (100k+ primitives):

Stuff scene:

Bunny scenes are not uploaded in the repo (90k+ primitives).

"Spotlight Foggy Bunnies"	"Three Bunnies"

"The cornell spheres"	"The cornell boxes"	"Fresnel Blend"

Console output

Transient state rendering

Note that the gifs presented here are made by compressed jpeg files and optimized (compressed gif). The actual number of images for making the gif is divided by 2, due to the large size of the resulting gif.

Transient balls (camera unwarped¹)	Transient cornell box (camera warped¹)

Here are the features I currently implemented and support:

A direct component renderer: a interactive visualizer for direct illumination visualization
A unidirectional / bidirectional Monte-Carlo MIS path tracer: supports as many bounce times as you wish, and the rendering process is based on Taichi Lang, therefore it can be very fast (not on the first run, the first run of a scene might take a long time due to taichi function inlining, especially for BDPT). The figures displayed above can be rendered within 15-20s (with cuda-backend, GPU supported). The rendering result is displayed incrementally, or maximum iteration number can be pre-set.
Volumetric path tracer that supports uni/bidirectional path tracing in both bounded and unbounded condition
A transient renderer with which you can visualize the propagation of the global radiance.
Texture packing and texture mapping, see scenes/bunny.xml for an configuration example. We support bump map / normal map / roughness map (this is not tested) for now.
Shading normal is supported for a smooth appearance.
Rendering checkpointing and rich console pannel support.
Ray tracing accelerating structure, for now, we only support BVH. KD-tree will be implemented in the future.
Global / indirect illumination & Ability to handle simple caustics
BRDFs: Lambertian, Modified Phong (Lafortune and Willems 1994), Fresnel Blend (Ashikhmin and Shirley 2002), Blinn-Phong, Mirror-specular.
BSDFs (with medium): deterministic refractive (glass-like)
mitusba-like XML scene file definition, supports mesh (from wavefront .obj file) and analytical sphere.
scene visualizer: which visualizes the scene you are going to render, helping to set some parameters like the relative position and camera pose
Extremely easy to use and multi-platform / backend (thanks to Taichi), with detailed comments and a passionate maintainer (yes, I myself). Therefore you can play with it with almost no cost (like compiling, environment settings blahblahblah...)

BTW, I am just a starter in CG (ray-tracing stuffs) and Taichi Lang, so there WILL BE BUGS or some design that's not reasonable inside of my code. Also, I haven't review and done extensive profiling & optimization of the code, therefore again --- correctness is not guaranteed (yet the steady state rendering results are compared with mitsuba(0.6) and pbrt-v3)! But, feel free to send issue / pull-request to me if you are interested.

/ Recent activity

Other branches:

ad: support for inverse rendering (automatic differentiable feature from Taichi), but due to the AD support of Taichi being too... lame (I think), there will be strange exceptions preventing using differentiable rendering.
more: BSDF mixture model (mixing different BSDFs). The BSDF management is entirely rewritten, but the code is slow for both runtime and compile time performance though it indeed supports more interesting features. I figure that since mixture is rarely used, we should opt for faster implementation.

Rendering Example

To run the rendering, use:

# For bidirectional path tracer
# Make sure you are in root folder.
# pip install -r requirements.txt			# Dependencies should be satisfied
python3 ./render.py --scene cbox --name cbox.xml --iter_num 8000 --arch cuda --type bdpt
# For volumetric path tracer: --type vpt, for vanilla path tracer: --type pt

useful parameters

--scene: in the folder scenes/, it specifies the folder to load from.
--name: in the specified folder, for example: ./scenes/cbox/, we choose one scene xml file to render.
--iter_num: number of iterations for rendering. Note that my implementation is not tile-based, therefore you can stop rendering any time you want (using esc, or closing the window. Do not use ctrl+c)
--arch: cuda / gpu / cpu / vulkan is supported (Taichi lang feature)
--type: bdpt for bidirectional path tracing, vpt for volumetric path tracing, pt for path tracing
--save_iter: Iteration milestones for saving rendering checkpoints (as .pkl file), you can load from it later.
-l: load from the check point. For more configurations for checkpointing, please see parsers/opts.py.
--img_ext: extension for output images: support ['jpg', 'png', 'bmp']
--no_cache: Disable Taichi JIT caching (to save disk space), by default we will enable caching, since BDPT is a complicated renderer and due to the auto-inlining of Taichi functions, JIT is slow (50s-1min, machine-dependent)
--no_gui: For simpler renderer and simpler scenes (without too many primitives and path bounces), disable the interactive GUI and accelerate rendering.
--normalize: For some scenes and some particular emitter configurations, the rendering result can be very dark. Using for example --normalize 0.99 can normalize the resulting image with 0.99 quantile number of the image.

Note that some scene has default ray-intersection accelerator, like scene/bunny.xml. If you are using Linux, BVH support can be easily turned on, but make sure you have eigen3 installed in /usr/include/eigen3, running:

cd tracer/
python3 ./setup.py install --user

BVH module will be compile to dyn-lib, therefore we can import the BVH module and use this accelerator.

If you want to configure your own scene, you can use the simple scene visualizer (without texture / shading) scene_viz.py:

python3 ./scene_viz.py --scene cbox --name cbox.xml

Using interactive UI to configure the camera extrinsics / intrinsics and object placement.

AdaPT is licensed under GPL-v3. Copyright @Qianyue He.

'Camera unwarped' means the transient profile shows the time when a position in the scene is hit by emitter ray. 'Camera warped' means the transient profile shows the total time of a position being hit by the emitter ray which should finally transmits to the camera. ↩ ↩²

Problem with spherical emitter NEE sampling.

Clearly the code was written during the time I did not fully understand the essence of MC path tracing. Starting from line 102 in emitters/abstract_source.py:

if is_sphere:
    tri_id    = prim_info[self.obj_ref_id, 0]
    center    = dvs[tri_id, 0]
    radius    = dvs[tri_id, 1][0]
    to_hit    = (hit_pos - center).normalized()
    local_dir, pdf = cosine_hemisphere()
    normal, _ = delocalize_rotate(to_hit, local_dir)
    ret_pos   = center + normal * radius
    # We only choose the hemisphere, therefore we have a 0.5. Also, this is both sa & area measure
    ret_pdf   = 0.5 * pdf

The normal (defining the final position on the sphere), is sampled locally and transformed around the hit pos. First, we can't have something being both area and solid angle measure unless the geometric term is exactly 1. Second, why should we have 0.5 here? We are sampling the same hemisphere with proba 1, i.e, the whole proba (consists of a conditional proba, which means that given the condition that we sample the same hemisphere, the proba of sampling the point, and the a marginal proba, meaning the proba of sampling the same hemisphere, which should be 1 here).

Also, there should be geometric term, now I think this comment made by me is totally bullshit:

We only choose the hemisphere, therefore we have a 0.5. Also, this is both sa & area measure

Yeah, cosine_hemisphere will produce PDF of which the measure is solid angle, but this PDF is still not what we are looking for! We need to now the PDF for the point that reflects the light ray and hit the diffusive area emitter.

The best (and also, the simplest) practice for this sampling problem is to use the current vertex position and the sphere, get the tangent (angles) for the sphere and do a uniform sampling (for polar angles), convert the result to the solid angle measure.

enigmatisms / adapt Goto Github PK

adapt's Introduction

Steady state rendering

Console output

Transient state rendering

/ Recent activity

Rendering Example

useful parameters

Footnotes

adapt's People

Contributors

Stargazers

Watchers

Forkers

adapt's Issues

Done

Recommend Projects

Recommend Topics

Recommend Org

Jobs