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

31–40 of 98 posts

Re: Writing a small ray tracer in Rust and Zig

#31

Post by the_duke »

0815test wrote: post #20
xiphias2 wrote: post #18

Earlier quoted context omitted.

I still don't understand why Rayon is not part of the Rust standard library. Rust was created to have easy and safe multithreading on the CPU, and Rayon is the clear winner in this space, for me it feels like something that should be part of Rust.

The Rust stdlib is specifically intended to be as lightweight as possible (while still providing those idiomatic abstractions that might be needed throughout the ecosystem, e.g. std.future) in order to avoid the Python "dead batteries" problem. What the Rust ecosystem is still lacking is a quasi-standard "Rust Platform" of best-practice library components where the community can freely deprecate something when a clea…

In my opionion the stdlib is a bit too conservative.

It is easy to end up with 200+ dependencies on more complex projects.

Some things should definitely be moved into std over the long term.

BUT: the time is not now. The language is still evolving rapidly. Upcoming features like specialization and a form of higher kinded types have the potential to impact API design a lot. I also really want named function arguments.

No-one wants to end up with a outdated and arcane standard library.

Re: Writing a small ray tracer in Rust and Zig

#32

Post by minxomat »

tjelen wrote: post #29
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…

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.

Yep. If the code doesn't clearly show the original intent, document your intent in a comment next to the code so future you or others can double check. Esp in gfx engines where some blocks are just math translated one to one to code.

Re: Writing a small ray tracer in Rust and Zig

#33

Post by Anonymous4C54D6 »

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.

Re: Writing a small ray tracer in Rust and Zig

#34

Post by xiphias2 »

0815test wrote: post #20
xiphias2 wrote: post #18

Earlier quoted context omitted.

I still don't understand why Rayon is not part of the Rust standard library. Rust was created to have easy and safe multithreading on the CPU, and Rayon is the clear winner in this space, for me it feels like something that should be part of Rust.

The Rust stdlib is specifically intended to be as lightweight as possible (while still providing those idiomatic abstractions that might be needed throughout the ecosystem, e.g. std.future) in order to avoid the Python "dead batteries" problem. What the Rust ecosystem is still lacking is a quasi-standard "Rust Platform" of best-practice library components where the community can freely deprecate something when a clea…

When I search for the Python dead batteries problem, the main issue is that the Rust developers don't want to maintain a growing list of libraries forever, especially that some of them will be depreciated over time.

This is totally understandable position, but it is still important to have sensible defaults for common tasks for end users.

One example that I can point to is Haskell, which I tried to learn from Haskell books, and it took me years to realize that it's not the language that's extremely inefficient, but the default libraries that use lists instead of arrays for most of the tasks.

I'm writing about Rayon because I see it as a reoccuring discoverability problem for people who are new to Rust.

There are many possible solutions, but one would be to have a default list of dependencies created in Cargo.toml that can of course be modified by the Rust users. Also that list can of course be changed over time by Rust developers.

Re: Writing a small ray tracer in Rust and Zig

#35

Post by forrestthewoods »

geokon wrote: post #24
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…

In my experience writing math code the intermediary values get quite goofy Ex: orthogonal-vector-to-plane-bisecting-input-vector-and-first-column-vector But I rather use crazy descriptive names than hiding it away. Otherwise it gets quite incomprehensible when you reread it 3 months later Anyone else hit this problem? I suspect most people just reference a paper or book and use the letters to match the source ( x/y/n…

That assumes there is a geometrically meaningful description. A lot of times a computation has no intrinsic meaning. Algebra is going to rearrange and cancel terms into nonsense.

A long name can tell you _what_ a value is. But it’s of zero use in explaining _why_ it’s being used.

The only solution is a lengthy comment explaining the process. Here some ballistic trajectory code I wrote awhile back. Good luck making sense of any single term!

https://github.com/forrestthewoods/lib_fts/blob/26a0d115eb44...

Re: Writing a small ray tracer in Rust and Zig

#38

Post by drcongo »

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…

This is how I've been helping my daughter understand some maths problems at school. Break it down and name everything, then write the sum with the names in and it makes sense.

Re: Writing a small ray tracer in Rust and Zig

#39

Post by cyphar »

the_duke wrote: post #31
0815test wrote: post #20

Earlier quoted context omitted.

The Rust stdlib is specifically intended to be as lightweight as possible (while still providing those idiomatic abstractions that might be needed throughout the ecosystem, e.g. std.future) in order to avoid the Python "dead batteries" problem. What the Rust ecosystem is still lacking is a quasi-standard "Rust Platform" of best-practice library components where the community can freely deprecate something when a clea…

In my opionion the stdlib is a bit too conservative. It is easy to end up with 200+ dependencies on more complex projects. Some things should definitely be moved into std over the long term. BUT: the time is not now. The language is still evolving rapidly. Upcoming features like specialization and a form of higher kinded types have the potential to impact API design a lot. I also really want named function arguments.…

The main problem is that you cannot version the standard library (well, there are "editions" but that's a bit of a workaround for other language changes).

Go has the exact same problem, and has also historically made similar mistakes to Rust in their stdlib (the "syscall" module is strongly recommended against -- instead you should use "golang.org/x/sys"). And it should be noted that Go is even more bare-bones than Rust -- the lack of generics means you have to use "containers" which is very limited (I also have a feeling it's used by effectively nobody, because of the bad ergonomics).

I think the best solution for this problem might be some form of "meta-crate" concept which would allow you to pull in all of the well-vetted and stable libraries that most people want, without having to curate ~20 libraries yourself.

Re: Writing a small ray tracer in Rust and Zig

#40

Post by cyphar »

Tuna-Fish wrote: post #23
sitkack wrote: post #10

Earlier quoted context omitted.

unsafe is the tool u are looking for.

No, there are plenty of safe ways to achieve this in the standard library. The chunks and split families of functions on slices are all designed to do pretty much exactly this.

In fairness to GP, they are implemented using unsafe (which is unsurprising since they take one &mut and return two to the same borrowed data).
Post reply on HN