tzuchieh / photon-v2 Goto Github PK

safe_xxx() methods/functions can provide a default value if the requested operation cannot be done, e.g., when normalizing a zero vector, use the default vector specified by the user instead

Need to do the following:

• make them respond
• check for missed ones in other methods
• properly test this (integration test maybe?)

The structure of Photon's resource system is becoming more and more complex, increasing the risk of smart pointer cyclic reference. Consider using weak_ptr or just raw pointers.

A file format for a series of commands, this will allow users to easily share their data, e.g., materials, geometries...

• allow recursive construct: a command file using other command files
• anonymous policy: names inside a command file should not conflict with the main scene resources
• each file represents a single resource with user (includer) determined name
• possibly pack into a single file

This should be done with #32 integrated

Generally, optimize memory-related parts.

possible solution is adding check in Actors (by checking Intersectable::hasTransformation())

• A dialog window with settings inside
• A simple widget comprising two buttons:
  1. "Save Options": opens the dialog
  2. "Save": actually save the image

This problem can also appear when appending materials/nodetrees from other blend files.

• Refactor path tracers into a generalized path tracing framework (preferably templatized for performance & flexibility)
• Plug the implemented path guiding technique into the framework

Mostly because there is no surface for photons to land on. Photon tracer will keep shooting photons and cannot reach a certain number of recorded photons.

Relevant file:
https://github.com/TzuChieh/Photon-v2/blob/develop/Engine/Source/Math/constant.h

The idea would be somehow store the most precise constant and derive other type-safe constants using constexpr.

Purposes:

• Solve the problem when input parameters have the same type and name: they can reside in unique structs now
• Reuse input parameter declarations and parsing, which is also cleaner
• Potentially benefit future implementation of OutputPacket and serializations

TODOs:

• Registering SDL structs
• A new SDL syntax for structs & parsing them
• Access SDL values and structs in a unified way (probably via TMP, and access like SDL references)
• Make sure encapsulating a struct with another one is possible

Perhaps the compression level is too high.

The following scripts need this fix. They occasionally fail.

https://github.com/TzuChieh/Photon-v2/blob/master/scripts/download_resource.py
https://github.com/TzuChieh/Photon-v2/blob/master/scripts/download_thirdparty_library.py

Seems like worker threads get blocked quite often when progress is being reported too frequently.

Currently, emitters are single-sided. If a ray hits some back-facing emitters, its intersection point may be slightly in front of the emitter. Consequently, if the emitter's material is double-sided and picks a sample direction on the same hemisphere with V, we will intersect ourself and this time causing light leaks. The amount of leaking light is tiny but visible. This scene demonstrate the issue:

## camera(pinhole) [real fov-degree 30] [vector3r position "0 0 0"] [vector3r direction "0 0 -1"]
## sample-generator(stratified) [integer sample-amount 18] [integer num-strata-2d-x 256] [integer num-strata-2d-y 256]
## renderer(sampling) [integer width 1280] [integer height 720] [string filter-name gaussian] [string estimator bvpt]

-> light-source(sphere) @source1 [real radius 1] [real watts 200] [vector3r linear-srgb "1 1 1"]
-> light-source(rectangle) @source2 [real width 2] [real height 2] [real watts 200] [vector3r linear-srgb "1 1 1"]
-> actor(light) @light1 [light-source light-source @source2]
-> actor(light) translate(@light1) [vector3r factor "0 0.5 -6"]
-> actor(light) rotate(@light1) [vector3r axis "1 0 0"][real degree 180]

First steps include

• investigate and standardize the xml tags for the feature
• able to automatically generate Blender node definitions

After we have interactive renderer

• able to automatically generate PhotonStudio UI (for material debug)

Currently the implementation parses SDL strings as raw bytes, which means we treat them as ASCII codes. This can lead to serious error if some SDL strings contain UTF-8 characters.

• a fast renderer for previews (can be biased)
• convenient UI widgets for it

Rendering spherical area light with tiny radius (~0.005) starts to show signs of numeric error. Specifically, render the following scene with triangles then with a sphere produces different results:

## camera(pinhole) [real fov-degree 30] [vector3r position "0 6 40"] [vector3r direction "0 0 -1"]
## film(hdr-rgb) [integer width 800] [integer height 800] [string filter-name "gaussian"]
## sample-generator(stratified) [integer sample-amount 10000][integer num-strata-2d-x 800][integer num-strata-2d-y 800]
## integrator(bneept)
//## integrator(surface-normal)

-> geometry(rectangle) @plane [real width 15] [real height 15]
-> geometry(rectangle) @smallPlane [real width 0.5] [real height 0.5]
-> geometry(sphere)    @smallBall [real radius 0.005]
//-> geometry(sphere)    @target  [real radius 3]
-> geometry(rectangle) @target [real width 4] [real height 4]

-> material(matte-opaque) @white [vector3r albedo "0.8 0.8 0.8"]
//-> material(abraded-opaque) @white [vector3r albedo "0.8 0.8 0.8"] [real roughness-v 0.02] [real roughness-u 0.1] [vector3r f0 "0.9 0.9 0.9"]

-> actor(model) @ground [geometry geometry @plane] [material material @white]
-> actor(model) rotate(@ground) [vector3r axis "1 0 0"] [real degree -90]
-> actor(model) scale(@ground) [vector3r factor "10 10 10"]

-> actor(model) @object [geometry geometry @target]  [material material @white]
-> actor(model) translate(@object) [vector3r factor "0 4 0"]
-> actor(model) rotate(@object) [vector3r axis "1 0 0"] [real degree -90]

-> light-source(area) @areaSource [vector3r emitted-radiance "400000 400000 400000"]
-> actor(light) @topLight [geometry geometry @smallBall] [material material @white] [light-source light-source @areaSource]
-> actor(light) translate(@topLight) [vector3r factor "0 10 0"]
-> actor(light) rotate(@topLight) [vector3r axis "1 0 0"] [real degree 90]
-> actor(light) rotate(@topLight) [vector3r axis "0 0 1"] [real degree 45]

Currently, I believe the problem lies in ray-sphere intersection test.

The implementation should allow

• easy to use coordinate transforms
• fast
• handle index transforms too

IIRC using PhotonBlend to export scene files with height > width will produce the problem. After rendering, the image looks like having incorrect camera parameters (something like strange FOV).

• export only active layer in a scene
• export only the objects with the "render toggle" on

Currently, integer type in SDL is implemented using int32; this can potentially lead to bugs caused by integer overflow.

E.g.
on large sample amount

Error parsing image filename with spaces. Issue discovered when parsing simple Lambertian diffuse with textured albedo.

Transforms do not occupy memory as much as primitives (unless meshes are created with one-transform-per-primitive basis); we should just pass data around rather than raw pointers.

Several notes:

• FrameOperator can be categorized into
  • local (pixel-by-pixel), e.g., simple tone mapping, scale
  • zone (neighbors may contribute to the final pixel), e.g., blur, bloom
  • global (the whole frame can affect the pixel), e.g., exposure like eye adaption
• FrameProcessor should be thread-safe (const methods) once constructed
• Post processing should be a separated operation with its own API
  • This way we no longer need to distinguish processed & raw frames in APIs
• Need better mechanism/spec to avoid processing non-updated region, which caused unwanted effects during asynchronous result queries in previous versions
  • Currently this is solved by hacking, see a36de40

The website: https://rgl.epfl.ch/materials

The implementation requires

• flexibility and functionality similar to Minecraft's NBT
• as fast as possible since this may be used for
  • async querying APIs
  • out of core rendering

It is unclear for now that who is responsible for the creation of PrimitiveMetadata. Specifically, we need a clear documentation or implementation that clears the following mysteries:

1. Who is responsible for filling-in the data members of PrimitiveMetadata?
2. When should a PrimitiveMetadata be created?
3. Should instances/pointers of PrimitiveMetadata be passed into cook() methods?

Currently unit test do not cover higher level functionality test. Need to have them (such as BSDF varification).

Some parts of the codebase are messed up to quickly support some features:

• renderer
• static canvas display in studio
• estimators

these should be cleaned up or refactored

Split normal and its related features are not respected by the depsgraph passed to the RenderEngine. This can be a Blender bug. Exporting scene files from the menu and render in PhotonStudio does not have this issue since split normal effects are faked using modifiers.

Currently a mis-press is very likely to crash the program.

The stack trace message should incorporate with Photon's assertion macros, and should be cross-platform (or at least on MSVC and g++).

• generating markdown might be a good choice

It would be beneficial to have a helper class/method to load binary files into a vector of chars or bytes.

This feature should be done as soon as possible, since every change in the SDL syntax can potentially break a bunch of existing scene files.

This can better self-document the intention of a parameter instead of just a raw string.

TODOs:

• Implement the type on engine side (possibly just a type name alias for string?)
• Able to document possible values using SDL xml description
• Transform existing code into using SDL enum

To be done:

• save statistics data (including rendering method, threads, etc.) as a text file
• log statistics data on the rendered image
• able to write custom message

• cleaner cooking process
• better handling rotation and different uv mapping for background emitter
• able to rotate IES light modulators

Makes the type of film used by some renderers changeable (by users).