This issue track enhancements to the library that may be implemented soon. They are mostly additions or cleans that do not affect the current system. I prefer to have all enhancements in one issue to avoid overwhelming the issues lists.
[x] library layout
[x] image_data into yocto_image
[x] shape_data into yocto_shape
[x] image_io into yocto_imageio.cpp
[x] shape_io into yocto_shapeio.cpp
[x] scene_io into yocto_sceneio.cpp
[ ] simpler path handling
[ ] do not rely on std::filesystem
[ ] dirname return "." when empty, or always ends with '/', to make it easier to join
[ ] remove path join that makes the code hard to read
[ ] use stat, mkdir functions also on windows
[ ] check for simple file exists on linus and windows
[ ] cheeck filesystem around github
[x] material naming:
[x] metallic -> reflective
[x] UI
[x] consistent navigation keys
[ ] quality of life
[x] square function
[x] clamp and power function with integer exponents
[x] eval_XXX function that take indices only, as well as eval_XXX that take intersections
[x] eval_frame and eval_shading_frame
[ ] add frame to make shape functions
[x] IO
[x] scene file should contain shapes and textures explicitly
[x] use exceptions instead of errors
[x] add back common io
[x] consider splitting imageio and shapeio
[x] consider custom parsers in shapeio
[ ] simplify modelio to return arrays directly
[ ] this seems to be hard to do now since there a lot of assumption on behaviour
should get_XXX throw when something is missing? right now hey just do nothing
should set_XXX override and clear values or do nothing like now?
[ ] cleanup
[ ] const refs for small math types
[ ] better names
[x] shape_data, material_data, etc.
[ ] shape_bvh, shape_intersection
[ ] simpler implementations
[x] subdivision using lambdas as shorthands
[x] subdivision returning after one level
[x] subdiv integration with simpler tesselation and displacement on non-face-varying
[ ] subdiv integrates catmull-rom
[x] edge_map using index/face1/face2
[ ] bvh implementation
[ ] should we use one or two data structures?
probably use two data structure
[ ] removev shape bvh to avoid code duplication
[ ] rename
[ ] intersect_shape, etc
[ ] make_XXX_bvh, etc.
[ ] update_XXX_bvh
[x] should I stick the BVH in geometry and parametrize it?
[x] build with range and enumerate
[x] recursive build
[x] remove build-vs-make
[x] remove high quality?
[x] make_bbox functions
[x] intersection without pointers
[ ] sampling generalisations
[ ] all samples should generalize to take frames as input as we should avoid having the free functions
xelatihy
commented
2 years ago
This issue track enhancements to the library that may be implemented soon. They are mostly additions or cleans that do not affect the current system. I prefer to have all enhancements in one issue to avoid overwhelming the issues lists.