walther / clovers Goto Github PK
View Code? Open in Web Editor NEWRay Tracing in Rust
Home Page: https://walther.github.io/clovers/clovers/
Ray Tracing in Rust
Home Page: https://walther.github.io/clovers/clovers/
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, ConstantMedium is an object. Should it be a material instead?
hitable.rs looks code-smelly.
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:
Depends on #6
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.
Some assorted points
src/
root directory has quite many filesmain.rs
and various "import files" look fairly verboseutils/
folder or similar, where to put internal helpers like camera
, scene
, draw
, etcCurrently, draw.rs
and draw_gui.rs
have a lot of overlap.
Ideally, there should probably be
The current checkered texture is a spatial texture, not a surface texture. Ideally, both should exist as options to the user.
Objects should have various defaults - think e.g. Boxy defaulting to a unit cube, Sphere defaulting to a unit sphere, etc.
The main colorize function isn't exactly clean. It has very deep nesting, a lot of branching, and is difficult to follow when reading.
Could be fun to have:
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
?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.
What kind of options could there be for physics support?
Look into using anyhow
or some such
Figure out what to license this as. Should this become a private project? Should this have an open, permissive license?
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?
There should be multiple convenient constructor options.
E.g.
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
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.
Implement the first test for the project.
Criteria:
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:
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
Could be fun to add support for some types of post processing, e.g.
What kind of structural changes would it require to support adding the simplest possible post processing step?
Currently, Color
is a simple rgb three float struct.
Color
could, for example:
Alternatively, consider spectral rendering - each ray only consisting of a single wavelength, reflecting and refracting differently based on the material and wavelength. See #16
It would be nice to be able to render SDF functions in addition to regular object-based scenes.
Todo:
hg_sdf
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:
#ff8d0c
rgb(255, 141, 12)
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
There should be some instrumentation to run cargo bench
.
Currently, there's a bunch of function implementations that only exist for specific object types.
See hitable.rs
and the various files in objects/
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).
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:
The current implementation of defocus blur based on the book seems to have somewhat strange results.
Investigate
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?
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, 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.
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.
hit
, scatter
, and others?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:
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.
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.
Try and see if clovers could become a renderer in bevy engine.
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.
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
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?
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!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.