enigmatisms / adapt

A physically based mesh renderer named Ada Path Tracer based on Taichi lang

I am Qianyue He. Bachelor of Engineering in Automation, graduated from XJTU. Pursuing further education in Tsinghua SIGS (Artificial Intelligence). I am currently an algo developer, interested in high performance graphics and AI-related computing.

I've been working on computer graphics and building an awesome renderer called Ada Path Tracer (AdaPT) based on Taichi Lang and a high performance CUDA path tracer cuda-pt with PTX assembly-level profiling. Computer graphics stackexchange: Enigmatisms

Seeking a way not to be so fresh-fish.

Language Preference	Recent Blog Posts
	※ 2024-04-26《NeRF-GS Interview Preparation》 ※ 2024-04-03《高性能异构计算相关知识》 ※ 2023-02-18《AdaPT - Volumetric Path Tracer I》 ※ 2023-02-11《AdaPT - Monte Carlo Path Tracer II》 ※ 2023-02-08《AdaPT - Monte Carlo Path Tracer I》 ※ 2023-01-15《Taichi-Learning-II》 Read more..

adapt's Issues

Remaining problems in AdaPT

Currently, BDPT is already implemented therefore I might slow down the development on this repo. Yet, some problems remain in the repo:

• Specular material rendering result inconsistency. When rendering mirror reflection / Frensel specular effect, BDPT tends to have darker (surface), while other non-specular parts are intact. BDPT rendering is not consistent with PT rendering (which looks better), nor is the result consistent with pbrt-v3 or Mitsuba0.6 (though, pbrt-v3/4 can't render a noise free image of csphere/single-ball.xml, Mitsuba0.6 itself doesn't look as good as pt rendering). This should be taken care of.
• Anisotropic BRDF burst noise. For FrenselBlend BRDF, there will be shot noises on the image. I suspect it's the problem of PDF calculation (MIS weight)
• Taichi function inlining introduces long JIT compilation time for BDPT since BDPT is lengthy and its member functions usually have complicated parameter. This should be optimized.
• VPT / volumetric BDPT seems to be fixed already, but the brightness seems not consistent with PT (no extensive experiment shows this yet, I just remember this vaguely). Brightness is not a huge problem, though.

---

New features that can be added:

• Since BDPT is added, we can implement collimated light and spot light in the repo.
• Scene visualizer should first experiment on mouse control (for view manipulation purpose). Since AdaPT is a real time rendering platform (on GPU and without BDPT, BDPT can only reach 12-16 fps, yet some scene for PT can achieve 120+fps), we can consider changing the camera extrinsic and other configs on the fly.
• More BSDF (for different transmission / reflection effect), this is relatively easy.
• Metropolis light transport can be added to further boost the rendering (low priority).

Transient rendering will show back faces of the opaque object

Though MIS weight seems to work (brightness is all normal), the backface color penetrates the surfaces, creating transparent look of the opaque objects in transient branch.

Future release plans

For version 1.5.0:

• Experiment on mixture BSDF, which should achieve: coating / plastic / realistic diffuse and more transmittance models.
• The demo scene for this version is the Lamborghini scene.

For version 1.6.0:

• Free view point rendering on the fly (camera pose / intrinsics being variables)
• Miscellaneous optimization: KD-tree implementation / code optimization for rendering speed
• Ambient occlusion renderer.
• The demo scene for this version is the Snooker scene and the Minecraft scene

For version 1.7.0:

• Volumetric rendering upgrade: equiangular sampling
• Heterogeneous rendering should be implemented. Density-based rendering / delta tracking.

Version 1.7.0 might be the last active version of this repo. I will shift my focus onto dynamic real-time global illumination rendering in the future.

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.

getting errors in importing

from la.cam_transform import *
from emitters.point import PointSource
from tracer.tracer_base import TracerBase

from parser.obj_desc import ObjDescriptor
from parser.xml_parser import mitsuba_parsing

Taichi] version 1.5.0, llvm 15.0.1, commit 7b885c28, win, python 3.10.11
Traceback (most recent call last):
File "d:\Python_RayTracing\AdaPT-1.2.1\tracer\path_tracer.py", line 18, in
from la.cam_transform import *
ModuleNotFoundError: No module named 'la'

Transient lit mode output is strange

Hi! I'm interested in rendering and have been learning taichi lang for a while. I played with your renderer several days ago and I think the outputs of transient lit mode is not so correct. It looks kinda strange if you actually use it in scenes like bunny and so on. Like in bunny scene, some places are lit too early, like those colored walls.

scene_viz.py is not compatible after BVH update.

Error will be thrown when running scene_viz.py, easy to reproduce:

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

Latest tasks for AdaPT

The latest tasks for AdaPT:

• Making the geometry more variable and look smooth. Normal mapping / bump mapping / vertex normal should be done. (task for 1.4.0, highest priority)
• Making python->taichi loading faster (1000 prims per second, too slow) (task for 1.4.0, highest priority)
• Making rendering faster (careful code optimization) (task for 1.4.0, 2nd priority)
• More BSDF and emitter:
  • For BSDF, there are three things I wanna do: (1) plastic material implementation. (2) refactoring for mod-phong (possibly-wrong implementation) and det-refract (unable to control the reflected ratio on surface). (3) Oren and Nayar rough diffusive BSDF. (2nd priority)
• Image reconstruction filter and advanced sampling methods (like equiangular sampling, forward-scattering sampling) (3rd priority)
• KD-tree accelerator: this is just for training purpose (C++ / pybind / algorithm) (4th priority)
• Logic check for single-sided mesh BRDF (we can actually hit both sides if the mesh is not closed, and standard is_mi checking will fail) (highest priority)

---

Done

• Texture mapping and shading normal should be implemented. This will make AdaPT fully usable for producing realistic scene rendering. (1.3.0)
• Emitter: Implement spot light source. I think..., spot source (limited angular distribution) can be applied to a wider range like area sources?

After tasks with equal-to and higher-than 3rd-level priority being finished, check the rendering result (against PBRT and mitsuba again). Then v1.3.0 can be released.