What's everyone working on this week (37/2021)?

New week, new Rust! What are you folks up to?


I just released rs_pbrt 0.9.3 yesterday:

$ ./target/release/rs_pbrt -h
rs_pbrt 0.9.3
Parse a PBRT scene file (extension .pbrt) and render it

    rs_pbrt [OPTIONS] <path>

    -h, --help       Prints help information
    -V, --version    Prints version information

        --cropx0 <cropx0>        Specify an image crop window <x0 x1 y0 y1> [default: 0.0]
        --cropx1 <cropx1>        Specify an image crop window <x0 x1 y0 y1> [default: 1.0]
        --cropy0 <cropy0>        Specify an image crop window <x0 x1 y0 y1> [default: 0.0]
        --cropy1 <cropy1>        Specify an image crop window <x0 x1 y0 y1> [default: 1.0]
    -t, --nthreads <nthreads>    use specified number of threads for rendering [default: 0]
    -s, --samples <samples>      pixel samples [default: 0]

    <path>    The path to the file to read

The --samples command line option is new and if you set it different from the default (0) it will overwrite whatever was specified within the .pbrt file. I might add an option to switch the render algorithm (ao, directlighting, whitted, path, bdpt, mlt, sppm, volpath), like I provide already for parse_blend_file:

$ ./target/release/examples/parse_blend_file -h
rs_pbrt 0.9.3
Parse a Blender scene file and render it

    parse_blend_file [OPTIONS] <path>

    -h, --help       Prints help information
    -V, --version    Prints version information

        --bootstrap_samples <bootstrap-samples>        bootstrap samples [MLT] [default: 100000]
    -c, --camera_name <camera-name>                    camera name
        --chains <chains>                              number of Markov chains [MLT] [default: 1000]
    -i, --integrator <integrator>                      ao, directlighting, whitted, path, bdpt, mlt, sppm, volpath
    -l, --light_scale <light-scale>                    global light scaling [default: 1.0]
    -m, --max_depth <max-depth>                        max length of a light-carrying path [default: 5]
        --mutations_per_pixel <mutations-per-pixel>    number of path mutations [MLT] [default: 100]
    -s, --samples <samples>                            pixel samples [default: 1]
        --sigma <sigma>                                perturbation deviation [MLT] [default: 0.01]
        --step_probability <step-probability>          prob of discarding path [MLT] [default: 0.3]
        --write_frequency <write-frequency>            frequency to write image [SPPM] [default: 1]

    <path>    The path to the file to read

I'm also interested in the next step to bring the CLI command into some Linux distributions. Pretty much what ripgrep managed to do ...


New week, new release! Working on my database client for XML database and XQuery processor BaseX basex 0.3.0.

I'm pretty excited to implement async and connection pooling when all the core features are stable.

Working on a new animation library for FlowBetween, for performing animations by transforming keyframes. I'm writing this as a post-processing step on the (vector) canvas output so it'll actually work as a library to add animation to any 2D graphics. (The 'wibble' example from flo_draw is kind of a prototype, using the same technique to animate an otherwise static image)

I've got a simple example animation working, in this case taking a canvas containing a straight circle and animating different parts of it in different ways (the demo here is written using flo_draw, which saves a bunch of time for prototyping this kind of thing):

The glitch here is probably what I'll be working on mainly this week: it's a bug in the path arithmetic functions in flo_curves caused by a conversion to f32 and back to f64 again leaving two lines almost but not quite perfectly parallel, resulting in a missed intersection which ends up turning the resulting path inside-out: hopefully I'll get this to be a perfect circle by the end of the week.

This approach should make it much easier to edit animation in FlowBetween: traditionally with 2D vector animation, the animations are attached to the vector objects so a user trying to edit the animation has to continuously take account of that, which makes a lot of things very laborious. Here, the animations and the vectors are stored as entirely separate data structures, so either can be changed without having any destructive effects on the other. (In this example, the circle would still be fully edtiable as a circle, for instance, in spite of being animated in 16 different directions at once)


I wrote crates-io-proxy to cache dependency crate downloads in the context of CI builds.
It is built with rouille web framework and ureq.

We re-hosted crates.io index repository on the local GitLab instance and patched config.json in the local master branch to point to crates-io-proxy.

This setup allows to build Rust packages in GitLab CI even without internet access.
The downside is that the package index repository must still be synced manually.

I also recommend Alexandrie as a third-party crate repository solution. We use it to publish crates that may not be pushed to crates.io.

I started working on a Linux screenreader It is proving to be an interesting and fun learning experience.


I made a simple epidemic model with gradient descent optimization, fully modular and generic, using nalgebra. (code here)

@hjozwiak This interests me, once I get speech-dispatcher working on my system I'll see if I can contribute. GNU/Linux sadly lacks accessibility tools, compared to Windows.

It is proving to be quite an adventure. Learning a lot as I go.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.