What's everyone working on this week (25/2020)?

community
1

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

2

I wrote an library for handling vectors, matrices and some other gfx algorithm in Rust as port of my own c lib. I will use this library inside a lib who should be able to create a 2D Rendering Scenery for handling Pen and Paper Town-, Village-, Cave- and Dungeon Maps. Furthermore there should be a Button who can create whole landscapes with villages, houses Rooms and a different Kind of Secrets.

Yes, thats the current Plan... :slight_smile:

2 Likes
3

Writing a general purpose SVG loader for Pathfinder capable of animations.

4

I working on a Matrix homeserver implementation in Rust called Conduit (https://conduit.rs).

Matrix is a secure, private, decentralized, open source messaging platform (https://matrix.org)

2 Likes
5

Now that async/await has been available for no_std environments I'm implementing my bare-metal brain - an executor - utilising all 4 cores of the RaspberryPi to enable my further projects to be implemented with async running code with less boilerplate and footprint compared to my current implementations :slight_smile: - looking forward to a more concise code base of my projects :smiley:

6

I'm working less and less on the Rust code of my renderer but on Render Comparison in general. I normally work on a particular test scene in Blender, first using a slightly older version (Blender 2.79), read the resulting .blend file via Rust code and render the scene with several algorithms I provide in rs-pbrt. Then, when everything works, I continue with providing slightly modified Blender (version 2.8x) scenes for a particular 3rd party renderer (using mainly their 3rd party Blender add-ons). If I run into problems or need new features, I modify the Rust code (e.g. last week issue #126). If everything works satisfactorily I also prepare Houdini and standalone scenes for other 3rd party renderers (more details can be found here). It's pretty time consuming and it's taking away time for Rust coding, but the renderer is pretty much finished (except speed optimizations). The future plan is to write a render delegate using The Hydra Framework for rs-pbrt so it can be used directly from within Houdini (and potentially other DCCs) in the future ...

7 Likes
7

Here is some more info about USD, Hydra, and the future plan:

1 Like
8

Working on my cargo-criterion subcommand. I wrote up a full comment on reddit but I wanted to ask the same questions here.

Is anyone aware of a production-ready data-serialization system with the following properties?

  • Must be able to encode f64 without precision loss.
  • Must be able to evolve the message types (within reasonable limits) without breaking compatibility between different versions. Some of this data may be persisted to disk and read later after a version update, or sent between different versions of Criterion.rs and cargo-criterion.
  • Lightweight compile times are desired. Currently using Serde, but unsatisfied with the resulting compilation times, especially from serde_derive, but serde_json is pretty heavy too.
  • Runtime performance and serialized data size are not major concerns so long as they're not unreasonable.

I know about miniserde, but it's officially not production ready and it's too limited for my needs.

I've considered various Protobuf and CapnProto crates. Those would be ideal if their compile times are light enough. Does anyone have any experience to share on that? I was a bit turned off by how they all recommend running the code generator in a build script; I'd prefer to check in the generated code so that my users don't need to compile the code generator as well as the generated code. Is that supported?

9

I'm working on a small cli project for git. This is kinda github account switcher in shell.

10

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.