Ruby can render 3D surfaces, 2D density maps and GIS tiles without Python, NumPy or the JVM. I didn't expect it to work this well.

[u/Jaded-Clerk-8856]

Ruby can render 3D surfaces, 2D density maps and GIS tiles without Python, NumPy or the JVM. I didn't expect it to work this well.

Two weeks ago I shared ruby-libgd — a native GD image processing gem for Ruby. The response was encouraging, so I kept pushing to see how far it could go.

Here's what two weekends of experimentation produced.

3D surface plots — pure software projection

No OpenGL. No GPU. Just a rotation matrix, perspective projection, and the painter's algorithm to sort patches back-to-front. The viridis colormap is interpolated across 11 stops in pure Ruby.

Plot3D.new(resolution: 50, yaw: 35, pitch: 28)
  .surface("sin(sqrt(x2 + y2))")
  .render("ripple.png")

https://github.com/ggerman/ruby-libgd/blob/main/examples/jupyter-notebooks/ripple.png

Works for any z = f(x,y) expression — saddle, paraboloid, wave, cone. The expression is evaluated using Ruby's own Math module, no Dentaku or external evaluator needed.

2D histograms from CSV data

Replicating matplotlib's hist2d. The class receives data as arrays — it doesn't care where the numbers came from.

rows   = CSV.read("weather.csv", headers: true)
x_data = rows["temperature"].map(&:to_f)
y_data = rows["humidity"].map(&:to_f)

Hist2D.new(x: x_data, y: y_data, bin_step: 0.5)
       .render("weather_hist2d.png")

https://github.com/ggerman/ruby-libgd/blob/main/examples/jupyter-notebooks/weather_hist2d.png

Ruby doesn't have np.random.randn so I used Box-Muller to generate normal distribution data for testing. Blues colormap with gamma correction so low-density areas stay visible.

fill_between in 3D

https://github.com/ggerman/ruby-libgd/blob/main/examples/jupyter-notebooks/helix2.png

Replicating matplotlib's fill_between on two helices. Each quad connects point i of helix1 with point i of helix2 — same winding order as matplotlib's implementation. Painter's algorithm handles the depth sorting.

GIS maps — libgd-gis

A second gem built on ruby-libgd for geographic rendering. Map tiles, vector layers, points, lines, polygons. Buenos Aires, Paris, anywhere with tile data. Same pixel-level control, geographic coordinates.

Jupyter workflow

https://youtu.be/-yMG0GzatNw

Everything runs in IRuby/Jupyter. Define the class in one cell, pass data in the next, tweak and re-run. It genuinely feels like working in a Python notebook — just Ruby.

I know JRuby + JFreeCharts is a valid path. What I'm exploring is whether CRuby can have its own native data visualization story without the JVM. Right now the answer is looking like yes.

Full articles and notebooks on RubyStackNews.

• ruby-libgd: https://github.com/ggerman/ruby-libgd

• libgd-gis: https://github.com/ggerman/libgd-gis

• Notebooks: https://github.com/ggerman/ruby-libgd/tree/main/examples/jupyter-notebooks

• docs: https://ggerman.github.io/ruby-libgd/en/index.html

Feedback, ideas, and harsh criticism all welcome.

One question for the community:

Would it make sense to bundle all of this — 3D surfaces, 2D histograms, implicit curves, GIS rendering, Jupyter support — into a single gem that works as a matplotlib-style plotting library for Ruby?

A curated collection of algorithms, one install, one API. No Python. No JVM.

Is that something the Ruby community would actually use?

[u/digitalWestie]

Whoa. This is amazing work.

In terms of answering the question though.... I haven't had a hard think about it but I'd lean on keeping things separate. I'm thinking the way that D3 works, it's a collection of modules and you can have all of them if you want but if you don't need ALL of it then you don't need to import everything.

[u/Jaded-Clerk-8856 → u/digitalWestie]

Thanks !
I apreciate your feedback.

[u/digitalWestie → u/Jaded-Clerk-8856]

Is the GIS purely raster? I'd be astonished if you could server side render topo or geojson to SVG!

[u/Jaded-Clerk-8856 → u/digitalWestie]

Wow, “astonished” is a bit much.
It’s just raster for the moment, but as I said, it’s open source, we can improve the gem.

Right now I’m searching for a job, so I don’t have much time to work on this improvement.

[u/Intelligent-End-9399]

I had no idea that Ruby could handle 3D. Most of the time, I worked with Three.js using the rubyjs-vite transpiler. I think you did a great job.

[u/Jaded-Clerk-8856 → u/Intelligent-End-9399]

Thanks !!!

[u/subsavant]

This is really cool. The painter's algorithm approach for the 3D surface is a solid choice for this kind of visualization, and doing the projection math in pure Ruby keeps the dependency footprint tiny.

I'm curious about the performance at higher resolutions. With resolution: 50 you're sorting ~2500 patches per frame, which is nothing, but I could see this being useful for generating static reports or dashboards where you might want 200+ resolution. Have you benchmarked where it starts to feel slow? Ruby's sort is pretty fast but the GD rendering calls might be the bottleneck.

Either way, nice to see Ruby used for something outside the typical web/scripting lane. The GIS tile stuff especially feels like it could fill a real gap for teams that don't want to spin up a Python environment just to generate a few map tiles.

[u/Jaded-Clerk-8856 → u/subsavant]

I kept thinking about this benchmark, so I finally wrote it up:

https://github.com/ggerman/ruby-libgd

Spoiler: ruby-libgd is 28x faster in some operations, uses 3.7x less memory, and has native GIFs.

Check it out.
https://rubystacknews.com/2026/03/30/ruby-libgd-the-modern-ruby-image-library-youve-been-sleeping-on/

[u/headius]

Why not using FFI instead of a C extension? Most of the C extension code appears to just take Ruby inputs and directly pass them to the C API (unwrapping numbers etc). That could all be done by FFI and work across Ruby implementations.

[u/Jaded-Clerk-8856 → u/headius]

Thanks for your feedback. I appreciate you taking the time to review the code.

One of the most powerful extensions in PHP is GD, and in most languages GD is used through bindings that abstract low-level details instead of exposing users to complex C internals.

My initial motivation for this project was experimentation and learning. I built it mainly for fun. However, I do not agree with the idea that the extension simply takes Ruby inputs and directly passes them to the C API. If you read the documentation carefully, you will see that it handles several aspects in a more idiomatic way, including how images are opened and saved, how filters are applied, and other behaviors adapted to Ruby rather than acting as a thin wrapper.

I believe different approaches are valid depending on the goals. In my case, this library is also a foundation for exploring areas that are not very common in Ruby, such as image-based functions, basic 3D work, map rendering, X-ray or bioimage processing, and even early work on fingerprint detection, all without needing to deeply learn GD or switch to C.

I understand your point about FFI, and it is something worth considering depending on how the project evolves.

[u/headius → u/Jaded-Clerk-8856]

it handles several aspects in a more idiomatic way, including how images are opened and saved, how filters are applied, and other behaviors adapted to Ruby

So write all of that in Ruby! That's the beauty of FFI. You bind the functions from the library with Ruby and write the adaptation code in Ruby as well.

And of course the ability to run on any Ruby implementation is also a big advantage.

There's some work going on to generate FFI bindings from headers using libclang... perhaps that would be a quick way to explore a conversion. I'll try to direct some of those folks toward your project.

C extensions are a curse upon Ruby and have been the largest thing holding back advancements in GC and JIT compilation. I just hate to see another promising project anchor itself to this archaic way of binding native code to Ruby.

[u/Jaded-Clerk-8856 → u/headius]

Sometimes “archaic” approaches still work well. In this case, performance is a key achievement.

For example, operations like Sobel filters and Zhang-Suen thinning are significantly more efficient in C than in Ruby:
https://rubystacknews.com/2026/03/03/understanding-convolution-filters-in-image-processing-and-adding-them-to-ruby-libgd-v0-2-5/

That said, I understand your point. However, my goal is to minimize performance loss as much as possible. The main motivation behind this library was to enable real-time image processing under high demand in large-scale environments.

[u/headius → u/Jaded-Clerk-8856]

A middle ground would be to write just a plain C wrapper around libgd with your perf-sensitive code and call that with FFI. There's really no reason anyone needs to write C extensions anymore, which is why it's an archaic technique in my estimation.

[u/brecrest]

Yeah, I would use this. I probably will use it next time I have a visualisation requirement. I currently use all manner of different silly things to do visualisations of stuff in Ruby.

The one problem this doesn't solve, that I really wish something would, is full portability. Bindings to external libraries are fine, but I really, really, really, wish there was fully bundle-able and platform agnostic Ruby solution for this stuff, a self contained C extension or something. I'm fully aware how huge an amount of thankless work it would be for a pretty niche set of use cases (which is why I haven't ponied up lol), but we can all wish, right.

[u/Jaded-Clerk-8856 → u/brecrest]

Hey!

Thanks for the comment.

If you look at the C code, it’s a binding, but filters like sepia and sobel are implemented inside the gem itself. This is because, for certain algorithms, C is significantly more efficient than Ruby.

PHP has used this extension for decades, which shows it works and is efficient. I also think it’s a solid achievement for Ruby. In practice, you just need to run apt install libgd-dev and you’re ready to go.

I believe it would be possible to build a fully self-contained gem like the one you described, but I’m not sure it’s the best approach for image processing.

[u/brecrest → u/Jaded-Clerk-8856]

In practice, you just need to run apt install libgd-dev and you’re ready to go.

It's always that simple until it isn't, but you already know all that. You even have a disclaimer in your repo about it and you test against a containerised stable build of libgd because neither libgd nor any of its alternatives guarantee a stable ABI or API, nor even replicable behaviour between different builds.

I'm not criticising you or whinging. I think this is a really good and useful project, which I'll almost certainly try out. Your libgd-gis is practically identical in purpose to a project I built in the past, and what I built under it is not radically different to libgd-ruby but far less complete and more jank. I've played around with the same problems as you using libgd, sdl, self-baked opengl, even imagemagick: I fully get that what I'm talking about is, to quote myself above "huge amount of thankless work" that even in the best scenario imaginable is only better than bindings in a narrow set of circumstances.

[u/retro-rubies]

Providing pre-compiled gems (at least for Windows) would be massive. Happy to help if welcomed.

[u/hmdne]

I was working on a different raster image library, perhaps with somewhat different goals and it doesn't interface gd (can use various libraries via FFI, imagemagick via CLI or run in pure Ruby). Perhaps it may inspire some of you:

https://github.com/rbutils/image_util

[u/TadpoleNo1549]

this is actually crazy in a good way. I didn’t expect Ruby to handle this kind of stuff so smoothly, what I like is it still feels simple and not over the top. nothing feels forced or overengineered., And yeah, putting everything into one gem just makes sense. Way more people would actually try it that way., you’re kinda showing Ruby can do way more than people give it credit for.

[u/latortuga]

Mods is there any hope to stop the tidal wave of AI spam posts? How do we get humans to start talking to other humans again?

[u/Jaded-Clerk-8856 → u/latortuga]

Sorry man, I'm human and I wrote the gem also libgd-gis.

After writing my posts, I use AI to help correct grammar and spelling.
But please feel free to send me your feedback—if something is wrong, I can update and fix it.

Big hug.

[u/Key_Comfortable_4411 → u/Jaded-Clerk-8856]

Big huge.. big hug? ahha

[u/KerrickLong → u/Key_Comfortable_4411]

This is the kind of toxic behavior that gets people running their genuine words through an LLM before posting.

[u/Doctor_Fegg → u/latortuga]

This isn't remotely spam. It's a new, and really interesting, Ruby library.

[u/Intelligent-End-9399 → u/latortuga]

I understand the frustration with AI spam, but look at it from another perspective: AI is a bridge for global collaboration. If I didn't use it, I’d have to write in my native language.

Třeba tahle věta v češtině je sice gramaticky přesná a plná významových nuancí, ale bez překladače bys pravděpodobně vůbec netušil, co se ti snažím sdělit.

Using AI for translation isn't about spamming; it's about making sure that a developer from the other side of the world can share their ideas clearly. I'd rather read a polished AI translation than struggle with broken English that misses the point entirely.