New week, new Rust! What are you folks up to?
Almost done with the second edition of 'the book'. Then first I'm going to port to rust an application I already have in Clojure and Kotlin, connecting to Kafka and PostgresQL.
Finally giving https://github.com/amethyst/amethyst a look. I experimented with https://github.com/three-rs/three for a bit, and I like it overall, but I don't think it's right for what I'm doing. It's cool to see what's going on in the Rust game dev community, lots of active work happening to flesh out the ecosystem :3
Still working on lpc82x-hal. I finished the rework of compile-time hardware state tracking that I was working on last week, which simplified the API a whole lot. Very happy with how this turned out.
I'm working on adding an I2C API now. Already have an example working, but need to do some more cleanup, and then extract the functionality into a nice API.
1 Like
I've aspired to write something here for a little while, and it's finally happening.
I made "baby's first crate," a TPS throttle. Because Rust goes fast, so obviously the next requirement is to make it go slow. It's actually a fairly useful tool in service programming to avoid hurting your downstreams. I didn't find anything else out there that exactly matched what I had in my head (in about a 3 minute search with a distinct lack of real knowledge about what to call things). I reason that if I'm reinventing the wheel it's a pretty small wheel, and it's a reasonably well-scoped project to cut my teeth on.
So I created mysteriouspants-throttle, inspired and educated by a John "Jonhoo" Gjengset livecoding recording to learn as much of good crate-authorship as I could absorb in one pass.
The crate itself is rather uninteresting: you make a throttle, which takes an Fn which tells it how long to wait until code can continue. You can return a single number from that Fn, or you could do something tricky and make it vary. It even has a pass-through argument so you can tell your closure things about how long it should wait when you ask it how long to wait.
1 Like
Playing a bit with Vulkan now that Apple gave me the excuse I needed in order to push myself to learn it.
Finally I nailed the Metropolis Light Transport (MLT) in the Rust implementation of PBRT:
Generation of bootstrap samples was multi-threaded already for a while using the crossbeam crate, now the remaining render loop is multi-threaded, which was surprisingly trivial using rayon ...
I will probably go through my test scenes and select some which are difficult to render noise free (or at least with significantly less noise) via uni- or bi-directional path tracing. For the volumetric caustics in the scene above (using participating media) MLT has a clear advantage 
2 Likes