Rs_pbrt v0.4.1 supports bump mapping


#1

Read the full release notes:


#2

Congratulations on yet another release!
I really like reading about your project, the spiffy pictures make for very good “marketing” :slight_smile:

I was wondering, is there anywhere that you write about the the bigger picture? I’d be interested in reading more “meta” on your experiences.
Specifically: I’m curious about your experiences of Rust-vs-C++. Also, in general, how have you found the Rust ecosystem for graphics?
I think your experience in porting the C++ code from the PBRT book makes you uniquely qualified to shed some light on this domain area.

I did find your “Happy new year 2018” post, which seems to be the most-meta thing you’ve published. Correct?


#3

Congratulations on yet another release!

Thanks :wink:

I’m curious about your experiences of Rust-vs-C++.

Well, in short: In software development you kind of have to deal with C/C++. There are too many libraries which you might want to use, most APIs of commercial software force you to use C/C++ etc. Code you might have written in pure C 30 years ago probably still compiles fine nowadays, but for C++ you had to deal with changed name mangling, compiler incompatibilities etc. for all those years, which make me kind of hate it. Therefore my interest in Rust.

Regarding Rust:

You’ll learn, that Rust has no classes, but traits (kind of classes with pure virtual interface functions, which implementors have to provide). You will learn how to fight the borrow checker. To be honest the learning curve is pretty steep, but worth it. I also love the Doxygen like build-in documentation strings and the resulting HTML documents. Or the (compilable) inline Rust code examples …

My gut feeling is: I would happily use Rust instead of C++ for any code written from scratch. What’s missing is a cross platform GUI library like Qt. I know people are working on wrappers for various such libraries, but right now things like a renderer, which do not necessarily need a UI, are easier to write.

I’d be interested in reading more “meta” on your experiences.

That’s pretty much all I have to offer right now. Anything else would be too time consuming and I rather spend that time on coding.

Also, in general, how have you found the Rust ecosystem for graphics?

I decided to write most of the lower functionality like points, vectors, normals, matrices, transformations, quaternions, rays etc. from scratch (to be fully compatible with the original C++ code), even though I knew I probably could have used already existing crates with similar structs and functions. Once there is a 1.0 version I would like to create several smaller crates for some of this functionality, so other people can reuse it for their projects, but right now I want everyting in one place.

A big help was that I did not have to implement an image processing library myself, I just used the image and openexr crates, but made the OpenEXR part optional. What would be even more useful for the future would be if someone would port (or wrap) the OpenImageIO and the OpenColorIO C++ libraries. They are pretty much the standard in the renderer industry right now.

Another idea, if someone is looking for a project to work on, would be a denoiser, which works independent of the underlying renderer. Right now everybody seems to work on their own solution. Blender’s Cycles renderer, e.g. is using a denoising filter, which probably could be used as a basis and you have the C/C++ source code for it.

Anyway, I hope that shed some light on the project and answered some of your questions …


#4

Thanks, fully understandable! I appreciate the time you’ve taken to explain this much already :slight_smile:

That’s definitely something that C/C++ people keep repeating, how lovely the dependency management is, good to see that the cargo vision from Rust 1.0 is paying dividends :smiley:

Ah yes, this keeps popping up again and again… The problem I see there is that the task is too big for any single project to stomach, and there isn’t really anyone available to “selflessly” coordinate it.
For such big projects, proper governance/coordination is often the limiting factor.
Nathaniel J Smith (Python: Trio, NumPy) wrote a nice piece on the governing problem, based on his experience reviving/reinvigorating NumPy: the unreasonable effectiveness of investment in open source infrastructure

Anyways, thank you for taking some time away from coding for satisfying this one’s curiosity!
I’ll let you get back to coding now, and try not to derail this announcement thread any further.