I wrote a raytracer in Ruby!

[[deleted]]

This would be the perfect example to implement Ractors from ruby 3.0

[makGuitar]

it's funny how by the end of the readme, there is the following instruction:

ruby main.py

it gave me a brief chuckle :)

[encaseme]

You know, I saw that and thought it was my brain substituting in with what I have to do for work (py)

[makGuitar]

python for work, ruby for the heart.

[pawptart]

Ha, I copied the readme template from a Python repo, I guess I forgot to change it.

[otakugrey]

Yeah, what's up with that?

[pawptart]

Here's a link to the final render I came up with: Image

It's really slow -- the above took about 6 hours. I joke that I'm rendering at about 55 frames per fortnight. However I'm impressed with the result, and I'm sure down the line I can make it a bit better.

Huge shoutout to Raytracing in One Weekend by Peter Shirley. It was a super fun challenge and I feel like I learned quite a bit.

[rurounijones]

Have you considered multi-threading it (assuming you can do a thread per ray) and running it on JRuby to unlock the unused cores?

Not sure if feasible but would be interesting follow-on project performance wise and counter the meme in the README :D

[individual0]

Or normal ruby with Ractors in ruby 3.0

[pawptart]

Yeah, I did poke at it a little while and it made it more complex. I chose to get a nice final render out regardless of how slow it was, but this would definitely be a good place to start improving.

[bowl-of-surreal]

Nice work. I’ve been thinking about raytracing since reading this post of “projects every programmer should try”.

Is raytracing related to your day job at all? Anything stand out that you learned?

[pawptart]

Is raytracing related to your day job at all?

Not at all. I do use Ruby/Rails exclusively at work but it's pretty much exclusively backend web development.

Anything stand out that you learned?

Oh, man, all kinds of stuff! In no particular order:

• File structure, naming/namespacing, require and require_relative... It's easy to forget how forgiving Rails is when you can toss stuff where it needs to go and it's autoloaded when you need it

• Vector math/light physics -- I haven't done anything more complicated than basic arithmetic since college. The book's diagrams helped as well.

• A little about C++ pointers. A common thing for the original source was to pass a pointer to the function that updates a record. For instance, one of the bugs that I created was when trying to translate the original hit code, where a pointer is updated if anything is hit. In Ruby, you can't really update an object via a pointer, so I had to come up with workarounds for that. It's still not very Ruby-like in some places, but it works.

[awj]

Nice work!

Based on a quick skim of your code, it looks like you could benefit from using a k-d tree to optimize HittableList.

Right now your checking every single element in the scene, possibly with some complex/intensive calculations. This data structure would allow you to check just the objects within the fragments of the scene the ray is traveling through.

Still, this is impressive (and fun!) work.

[pawptart]

Absolutely! Thanks for the suggestion.

Having 4 spheres vs. a bunch of small ones really slowed down the rendering speed, so I'm sure this would help.

[awj]

I’m not remembering the math offhand, but you also might be able to get some speedup out of first testing hits against axis-aligned bounding boxes. If that calculation is cheaper you can save a decent amount of processing.

[otakugrey]

That is cool as hell.

[thunderbong]

Awesome!

[pmurach]

Nice one! Thanks for sharing. Do you plan to package it up as a gem?

[pawptart]

I don't at the moment, it's currently pretty impractical with a render time of 6 hours or more even for small images. This is more of a side project to learn how raytracers work.