anydsl / imbatracer Goto Github PK

The connection and merging steps have a poor performance.

We can improve it by:

• Using an importance sampling scheme that favors merging/connections with vertices that are close to each other in memory + Sorting vertices spatially in the cache.
• Cutting the merging/connection loop in two.

MIS in Path Tracing can greatly improve the quality of the rendered images, at a very little cost. It is also very easy to add, which makes it a must-have.

I see several places where the code has been commented. We should rid this from the code base:

• For the cases where the code is commented for testing, we should simply remove it, or add a specific #ifndef NDEBUG clause around it.
• For the cases where the commented code is here to suggest an alternative (e.g. the mis heuristic), we should have a couple of defines with documentation for them (or templates with constexpr, which I would prefer).

There should be a clean scene API in the frontend.

The renderer currently does not support dynamic geometry. We need to implement the necessary boilerplate to support rigid body transformations.

Before we can investigate rewriting it with AnyDSL, we should think about separating the parts where the textures/material data is loaded from the pure material computation (i.e. BRDF/BTDF). This would allow us to have a more declarative syntax for materials, and maybe a graph representation: We could then link inputs (texture color/normal, ...) to a chain of computations.

Currently, the documentation is pretty lacking. We need a better documentation (through Doxygen). This obviously goes hand-in-hand with a better API.

Having an interface to a 3D software like Blender would ease testing and allow us to experiment with even more scenes.

Something simple that suffices for our purposes does not appear to be very difficult, see for instance: https://agraphicsguy.wordpress.com/2015/09/06/my-external-renderer-for-blender/

We would have to come up with a simple (node based) material representation that can be edited in Blender, and create (or find) a file format to store those materials.

I would like to clean up a bit the scheduling API. More precisely, we should:

• Create a derived class of RayGen, TiledRayGen, which should be more restrictive than the RayGen class.
• Loosen the restrictions of the RayGen class. The RayGen class no longer needs a precise width, height and sample/pixel. We could replace that with a virtual function estimate_ray_count that returns an estimate of the number of rays.