walther / clovers Goto Github PK

Currently, the rays are in RGB. According to remarks in the books, physically-based renderers may use rays of individual wavelength each & have scattering behavior affected by wavelength.

Should this project:

• Stick with RGB rays only?
• Move to spectral / wavelength-based rendering?
• Have an option to choose between two modes?

Objects should have various defaults - think e.g. Boxy defaulting to a unit cube, Sphere defaulting to a unit sphere, etc.

hitable.rs looks code-smelly.

• lots of repetition
• hitablelist, bvhnode, etc feel like they have weird relationships
  • how should the construction really be done at scene load time
  • how should the ownership model be
• in a PR long time ago, moved away from dyn traits to manual enums. this has made a lot of the codebase ugly. original justification was potential performance gains. does this really hold?
• is hitrecord good? should the material be a reference or should it be owned? something else? this also propagates around the codebase a lot, so changes here need to happen in a lot of places

Currently, if you have a typo in your scene file json, you can get default fallback parameters for the objects. This can lead to frustration, when modifying parameters doesn't have an effect on the output.

Use #[serde(deny_unknown_fields)] in all deserializable objects, or figure out another alternative.

Optionally, look into ways that still enable comments in the scene files: possibly a metadata field that has serde skip, or something else?

Everything in this library should be documented.

Wonder if there's a tool to show rustdoc coverage?
Wonder if there's a lint to force docs to exist?

Currently, a scene must have priority_objects. Without it, the application will panic at runtime with

UniformSampler::sample_single: low >= high

Ideally, the priority_objects list in a scene .json would be optional / can be empty: without priority objects given, an uniform sampling distribution would be used.

It could be useful to instrument debug logging for possible NaN values generated during the render. This would make it possible to trace their origin and fix their causes.

Currently, Color is a simple rgb three float struct.

Color could, for example:

• be more colorspace aware
• have helper methods for e.g. html hex colors, hsl/hsv colors, etc
• etc

Alternatively, consider spectral rendering - each ray only consisting of a single wavelength, reflecting and refracting differently based on the material and wavelength. See #16

Currently, the project is focusing on a CLI & GUI binary application for rendering scenes.

Should there be support for using clovers as a library in other projects?

Ideally, the program should be able to load custom objects (e.g. triangle-based?) from files and render them along with the other scene.

Open questions:

• Which format(s)?
• How to refer to these in the scene files?

Depends on #6

Currently, ConstantMedium is an object. Should it be a material instead?

Figure out what to license this as. Should this become a private project? Should this have an open, permissive license?

What kind of options could there be for physics support?

• Implement your own collision functions and location / movement logic?
• Investigate existing libraries that could be used to drive virtual objects and hook that to the rendering pipeline here?
• Other, what?

https://en.wikipedia.org/wiki/Open_Shading_Language
https://github.com/imageworks/OpenShadingLanguage/

Currently, the scene files can only specify the color as a list of floats, one per RGB component, with 0.0 being no reflected light, 1.0 being maximum reflectance on that component, and values above 1.0 being an emitting surface (i.e. operates as a light source).

Would be nice to have at least:

• hex rgb support, #ff8d0c
• decimal rgb support, rgb(255, 141, 12)
• others, what?

Materials, textures, colors, all sorts of various things should have default values.
This makes creating scene files easier and less verbose, and potential changes in default values can propagate "automatically" to old scene files for things that have not been manually specified.

EDIT: splitting object defaults into a separate issue

Currently, draw.rs and draw_gui.rs have a lot of overlap.

Ideally, there should probably be

• one main loader function for the scene
• one gui render loop and one non-gui render loop, shared features combined into helpers
• one file writer that gets called at the end of either mode (currently, GUI mode does not save a file!)

Could be fun to try and use some form of tracing and see if it could help with finding bottlenecks etc.

Of course, this could also add a way too large performance impact? Who knows. Have to try out to see!

High-potential library to try out: https://github.com/tokio-rs/tracing

This project is written in Rust, including all the "business logic" of computing intersections, color values, and so on. This means the project is run on a CPU, while GPUs are extremely efficient at highly-parallel computations like doing something for each pixel in a buffer.

I do not particularly wish to reimplement the project in GPU-specific languages (e.g. shader languages, such as SPIR-V, GLSL, etc). This means that libraries that provide "bindings" to more "GPU-native" languages and frameworks are out of scope for this issue.

Look into possibilities of general-purpose gpu computing (GPGPU).

• Ability to run Rust code itself on GPUs
• Ability to compile the Rust code into something that can be run on a GPU
• Other, what?

Currently, all the scenes are defined as code in the src/scenes directory as .rs files. To render a different scene, a whole recompile of the project has to happen.

It should be possible to run clovers --input scene and get a render of the specified scene, or helpful error messages pointing out mistakes in the scene file.

Open questions:

• which format? TOML? JSON? Other, what?
• what should a scene contain?
  • objects
  • camera
  • priority objects (used for probability sampling; e.g. lights, glass objects)
• optional future pondering: how to specify change over time, for rendering video / multiple frames?

Currently, there are no good docstrings on functions and structs.

Should probably split this up into multiple tasks, one per file (or similar), in order to make it achievable in smaller pieces at a time.

Verify that the specified output file can be written at the startup - path exists etc.

This would avoid issues where you spend a long time rendering and fail at the end due to missing folder & lose all the work.

Some initial work done in #85.

Make the entire render process work on the GPU.

Considering how significantly faster direct lighting can be, there should be a CLI option for switching between the two modes. This should be especially useful if/when pondering realtime use, preview renders for video, etc.

What should this option be called?

• --mode global, --mode direct ?
• --global=true, --global=false?
• other?

Add a new CLI parameter --output, -o for specifying the location of the output file.

While at it, add logic for trying to create the renders directory in the current location if not present, in order to avoid a sad surprise at the end of a render when the file couldn't be saved.

Currently, there's a lot of utility functions for which the output is assumed valid.

Consider the possibility of using something like quickcheck to validate the various functions and inspect for possible outlier values.

Try and see if clovers could become a renderer in bevy engine.

Look into using anyhow or some such

A simple light cube in a cornell box projects a clear image on one wall and a smoother gradient on the floor.

Implement the first test for the project.

Criteria:

• renders a small, fast-to-render scene
• the file is saved successfully
• can be run on three major operating systems (Windows, MacOS, Linux)
• is run on CI for each PR

See http://graphics.stanford.edu/papers/metro/

Currently, there's a lot of serde Deserialize and Serialize derive macros across the project. Additionally, the project specifies serde features for some dependencies, as well as builds serde itself into the binary.

These should be cleaned up / removed, and a better approach or a new attempt should be made in terms of #6

There should be multiple convenient constructor options.

E.g.

• Plane with center, height, width given
• Boxy with center, height, width, depth given
• Boxy cube with center, width given
• etc

It would be nice to be able to render SDF functions in addition to regular object-based scenes.

Todo:

• Start with implementing a new hit function
• Write some objects - potentially port things over from hg_sdf
• Figure out a serialization & deserialization method: ability to have scene files for SDFs as well

https://docs.rs/enum_dispatch/0.3.4/enum_dispatch/

This could potentially clean up the objects and their hit methods etc a bunch. Try it out!

Could be fun to add support for some types of post processing, e.g.

• Lookup tables (LUTs) for color transforms?
• Variable color sensitivity black-and-white film simulation mode?
• Denoise step?

What kind of structural changes would it require to support adding the simplest possible post processing step?

Considering the usefulness of various set operations in Signed Distance Field rendering, it could be fun to try and get at least some of them to clovers as well. Subtraction is probably the first one to attempt.

• How would this affect AABBs?
• What kind of modifications are needed to hit, scatter, and others?

When using a blend of direct light sampling and global illumination as specified in the book 3, it may seem as if the new probability density function based sampling is causing more hot pixels than the naive random sampling from earlier books.

Investigate if there might be a bug causing significantly large values in the PDF functions and related codepaths.

Currently, the codebase has separate internal representation structs for the various objects, and separate init structs for the representations in the scene.json files.

Is this a good/bad thing? On one hand, it feels like there might be a lot of repetition. On the other hand, see e.g. #46 and #47 - these could potentially benefit from multiple init structs existing / more flexibility in the input...

Currently, all the coordinates in the basic scenes are based off of the raytracing.github.io books, which are also based off of something else.

The coordinates are a bit difficult to remember and do mental arithmetic on.

There should be:

• nice default scene coordinates
• nice default camera coordinates
• nice default orientation (currently, the axes may be flipped & otherwise weird)

See e.g. https://twitter.com/amandaghassaei/status/1348006462824484865?s=21

The main colorize function isn't exactly clean. It has very deep nesting, a lot of branching, and is difficult to follow when reading.

There should be some instrumentation to run cargo bench.

• Isolated test cases for specific functions
• Variety of said cases to test for performance changes across the project
• Optional: CI instrumentation to run the checks on PRs to check for regressions and improvements

The clovers library currently has a #[no_std] statement in it.
However, it looks like some of the dependencies might be pulling parts in that aren't no_std compatible.

Blocks #87

The current checkered texture is a spatial texture, not a surface texture. Ideally, both should exist as options to the user.

Some assorted points

• src/ root directory has quite many files
• main.rs and various "import files" look fairly verbose
• there could be some equivalent of a utils/ folder or similar, where to put internal helpers like camera, scene, draw, etc
• others

The current implementation of defocus blur based on the book seems to have somewhat strange results.

Investigate

• possible bugs in implementation
• possible sensitivity for other camera parameters
• possible better algorithms

Currently, there's a bunch of function implementations that only exist for specific object types.

See hitable.rs and the various files in objects/

Could be fun to try and run this in a browser with WebAssembly.

Caveat: wasm parallel compute / threading is still experimental in browsers, which might make this extremely slow.

Could be fun to have:

• Logo / icon
• banner image
• others?