Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a small ray tracer in Rust and Zig

nelari.us

Post reply on HN
Print view View original

71–80 of 98 posts

Re: Writing a small ray tracer in Rust and Zig

#71

Post by arve0 »

Anonymous4C54D6 wrote: post #33
oconnor663 wrote: post #3

> But rendering in separate threads turned out to be (unsurprisingly) harder than the way I would do it in C++...It was a bit frustrating to figure out how to accomplish this. Googling yielded a few stack overflow posts with similar questions, and were answered by people basically saying use my crate! Based on some discussion in r/rust ( https://www.reddit.com/r/rust/comments/c7t5za/writing_a_smal... ) I went ahead a…

Also, https://www.arewewebyet.org/ is somehow trying to provide a little bit of this but fails to actually recommend the best option.

What is the best option, in your opinion?

Re: Writing a small ray tracer in Rust and Zig

#72

Post by Fronzie »

monocasa wrote: post #46
mrec wrote: post #45

I didn't quite grok this bit: > The ability to return values from if expressions and blocks is awesome and I don’t know how I’ve managed to live up until now without it. Instead of conditionally assigning to a bunch of variables it is better to return them from an if expression instead. The example shown (aside from the fact it's assigning a tuple, which is a different point) would naturally be a ternary in C/C++. Do…

Yeah, exactly. YOu know how it becomes a pain to make a const variable that needs some setup in C and C++? This lets you const all the things.

You could assign it from a lambda function.

Re: Writing a small ray tracer in Rust and Zig

#73

Post by ddragon »

pjc50 wrote: post #55
tjelen wrote: post #29

Earlier quoted context omitted.

So why not just write the original formula into the comment above the code? Maybe it's not the purest approach, but it sure would help parsing the code in this case.

Why not one step further, and let the original formula be the code? Directly compilable Latex: \vec r = \frac {n_{1}}{n_{2}} \cdot (\vec v - dot(\vec v, \vec n) \cdot \vec N) - \sqrt{1 - \frac {n_{1}^2}{n_{2}^2} \cdot (1 - dot(\vec v, \vec n))} \cdot \vec N (This is partly a joke and partly a serious suggestion, there are definitely people out there who would find that easier to write, especially if the IDE rendered…

Julia (a language focused on science/math) does it partially. For example in the editor or REPL you can just type \sqrt [tab] \alpha [tab] and it will generate √α which is valid code. Most math symbols in unicode are supported and overloadable. And you can also write matrix like a table, such as

[1 2 3

4 5 6

7 8 9].

And you can transform Julia expressions to LaTeX:

https://github.com/korsbo/Latexify.jl

But even they didn't go as far as being able to parse full LaTeX expressions (though you technically could with reader macros plus editor support).

Re: Writing a small ray tracer in Rust and Zig

#74

Post by pgt »

fiddlerwoaroof wrote: post #66
dahart wrote: post #59

Earlier quoted context omitted.

> I’m convinced that there’s a proper mathy / lighting-y word for each component in that expression. Sometimes yes, but often no. Frequently this kind of expression is the result of solving an equation, so it’s just an expression. Graphics people often use two approaches for sub-expressions: - You can name them with the same letters that are in the expression, just with the punctuation & operators removed, for exampl…

People say “the two hardest problems in computer science are cache invalidation, naming and off-by-one errors” and we often design systems so that we don’t have to think about cache invalidation and off by one errors (e.g. list.map rather than a for loop). I often wonder if we should think about minimizing how often we name things as well.

Excel is the most popular functional programming language in the world. Its killer feature is that you don’t have to name your values before you can use them.

Re: Writing a small ray tracer in Rust and Zig

#75

Post by davemp »

steveklabnik wrote: post #63
oblio wrote: post #21

Earlier quoted context omitted.

Rust needs something like Rust dev blessed "extension packs", in my opinion. Sort of like VS Code has extension packs. Basically have some metapackages for common development areas, that pull in community vetted, high quality libraries for certain areas.

We have tried to suggest this, but the community has overwhelmingly rejected it, both as an explicit plan, and when people provided such a thing.

That's unfortunate. Whenever I talk about rust with my coworkers, getting crates through IT comes up as a major deal breaker. I imagine cooperate approved "packs" would make it much easier for us rust hobbyists to get some projects started at work in rust.

See python: my workplace (and I'm sure many others) is stuck with what's in anaconda for better or worse. The situation is certainly better than pure std.

Re: Writing a small ray tracer in Rust and Zig

#76

Post by superdimwit »

pgt wrote: post #74
fiddlerwoaroof wrote: post #66

Earlier quoted context omitted.

People say “the two hardest problems in computer science are cache invalidation, naming and off-by-one errors” and we often design systems so that we don’t have to think about cache invalidation and off by one errors (e.g. list.map rather than a for loop). I often wonder if we should think about minimizing how often we name things as well.

Excel is the most popular functional programming language in the world. Its killer feature is that you don’t have to name your values before you can use them.

Well, it just has a cartesian namespace

Re: Writing a small ray tracer in Rust and Zig

#77

Post by BubRoss »

0815test wrote: post #26
skrebbel wrote: post #22

This is an awesome post. At the risk of shedding it to bikes, one point that the author makes is that Zig's lack of operator overloading makes him write vector math like this: if (discriminant > 0.0) { // I stared at this monster for a while to ensure I got it right return uv.sub(n.mul(dt)).mul(ni_over_nt).sub(n.mul(math.sqrt(discriminant))); } He signs off with: > How do C programmers manage? The answer is simple: w…

The most principled approach there, I think, would be to build a little Expression data-structure, and then feed it to an evaluation routine, trusting the optimizer to compile the whole thing down to something efficient. If Rust didn't have operator overloading anyway, you could do the job with procedural macros. In practice, if I had to write that quasi-monstrosity in something like C, I'd probably just comment it a…

Why would you need to do that with small vectors? The compiler is going to do that anyway. Eigen originally took this approach because it could avoid heap allocating temporary variable before C++ had move operations. This isn't applicable here.

Re: Writing a small ray tracer in Rust and Zig

#78

Post by tombert »

pgt wrote: post #74
fiddlerwoaroof wrote: post #66

Earlier quoted context omitted.

People say “the two hardest problems in computer science are cache invalidation, naming and off-by-one errors” and we often design systems so that we don’t have to think about cache invalidation and off by one errors (e.g. list.map rather than a for loop). I often wonder if we should think about minimizing how often we name things as well.

Excel is the most popular functional programming language in the world. Its killer feature is that you don’t have to name your values before you can use them.

I'd argue that its killer feature is that everything is inherently reactive.

Re: Writing a small ray tracer in Rust and Zig

#79

Post by pcwalton »

gmueckl wrote: post #50
OskarS wrote: post #43

Earlier quoted context omitted.

I will say, the one example they have there which is sort-of analogous to "render each pixel of this image in parallel" is the "draw a julia set" one [0], and it's a very bad way of convincing a C/C++ programmer that Rust is good at this sort of thing. Even if the "loop over all rows in the main thread, adding to the pool a lambda that loops over each column" is somehow optimized in a good data-parallel way (I doubt…

To me, this somehow says that most truely interesting problems can only be solved efficiently in Rust using unsafe. Granted, my definition of interesting may be a bit limited, but my initial takeaway here is that Rusts safety story is much more limited than its proponents claim.

> To me, this somehow says that most truely interesting problems can only be solved efficiently in Rust using unsafe.

Even Vec is implemented with unsafe code under the hood. Rust isn't about not using unsafe code anywhere: it's about encapsulating that unsafe code in reusable abstractions that can be easily audited. This is how essentially all languages work to begin with: unless you're using CompCert, the compiler itself is not proven correct, and so the compiler's code generator is "unsafe".

Here's an example of how rav1e, an AV1 encoder in Rust, builds safe abstractions out of unsafe primitives in order to solve a similar problem: https://blog.rom1v.com/2019/04/implementing-tile-encoding-in...

Re: Writing a small ray tracer in Rust and Zig

#80

Post by mhh__ »

skrebbel wrote: post #22

This is an awesome post. At the risk of shedding it to bikes, one point that the author makes is that Zig's lack of operator overloading makes him write vector math like this: if (discriminant > 0.0) { // I stared at this monster for a while to ensure I got it right return uv.sub(n.mul(dt)).mul(ni_over_nt).sub(n.mul(math.sqrt(discriminant))); } He signs off with: > How do C programmers manage? The answer is simple: w…

The fruity method should be preferred: Any compiler worth using will immediately eliminate/register-allocate the variables and now you don't have undebuggable spaghetti code
Post reply on HN