DEV Community: Ibukun Sanni

My Renderer and Blender Painted the Same Gun

Ibukun Sanni — Fri, 30 Oct 2026 00:51:53 +0000

The SMG, textured from its own image map, in my renderer. Model: "SMG GUN Remastered" by ROHIT3DMODELS, CC-BY-4.0.

What is a texture?

In my earlier explorations, every object in my renders had one material with a single color. A texture allows multiple colors across the surface of an object. It simply tells us what color is supposed to be at the ray's hit location. It can be as simple as a checkered pattern like a chessboard, like the floors in all of these images, or as complicated as the texture on the SMG above.

To wrap an image, each point on the surface needs to know where it sits on that image. Since we are already using $(x, y, z)$ coordinates for the model, we adopt $(u, v)$ coordinates: two numbers from 0 to 1 that map a 2D image onto a 3D object.

Side bar: it keeps coming back to 2D

Rendering is already a 2D image made from a 3D scene. Then the white furnace test turned correctness into a flat grey square. Malley's method picks 3D bounce directions by lifting points straight up off a flat 2D disk. Now a texture runs the other way, taking a 2D image and mapping it to a 3D surface. I love it, and I am sure there's more to come.

We have to figure out a few things:

where the $(u, v)$ comes from, for spheres and for meshes
which way up the image is
what color space it's stored in

Painting from space, then painting the surface

Following Ray Tracing: The Next Week, we start with a checkered cut from space. For a checkered cut from space it is simple: take the floor of $(x, y, z)$ and add them up. If the sum is even, use one color; if it's odd, use the other. In my case, yin and yang.

glm::vec3 Value(float u, float v, const glm::vec3& p) const override {
  int x_int = static_cast<int>(std::floor(inv_scale_ * p.x));
  int y_int = static_cast<int>(std::floor(inv_scale_ * p.y));
  int z_int = static_cast<int>(std::floor(inv_scale_ * p.z));

  // Yin fills the cubes whose index sum is even, yang the odd ones.
  bool is_even = (x_int + y_int + z_int) % 2 == 0;

  return is_even ? yin_->Value(u, v, p) : yang_->Value(u, v, p);
}

And the floor under the SMG, from its scene file:

local floor = gr.checkered{ scale = 1.5,
                            yin = {0.2, 0.3, 0.1}, yang = {0.9, 0.9, 0.9} }

Cut from space, the color depends only on where the hit point is, no $(u, v)$ needed. It's perfect for a floor and for flat-sided shapes like a cube. On a sphere, it's not as glamorous: the curve slices the cells unevenly.

Left and middle: a checkered pattern painted in each sphere's (u, v), so the cells follow longitude and latitude. Right: the checkered pattern cut from space, sliced unevenly by the sphere's curve, and square on the flat faces of the cube in front.

The fix is to give every hit its $(u, v)$ . For a sphere, that's longitude and latitude, which gives the checkered look that narrows at the poles in the image above.

Reading an image

An image texture is a lookup: $(u, v)$ in, color out. Reading it right came down to two things:

Which way is up. Image rows run top to bottom; $v$ runs bottom to top. A test image with a different color in each quadrant pins that down, and a unit test holds it there.
Linear light. A PNG stores sRGB, which is brightness curved for screens. My renderer works in linear light, so each texel (a pixel of the texture) is decoded once, on load.

A test grid the right way up, and a Jupiter map wrapped onto a sphere. Jupiter map: NASA / JPL-Caltech / SSI / Southwest Research Institute / Malin Space Science Systems / Italian Space Agency (ASI) / Italian National Institute for Astrophysics (INAF) / JIRAM / Björn Jónsson, CC BY 3.0.

The Jupiter map is 170 MB, far too big for git, so a fresh clone doesn't have it. Instead of crashing, a texture that can't be loaded logs a warning and renders as a grey and white checkered pattern. A missing file is obvious, but the rest of the scene still renders.

The same scene on a fresh clone: Jupiter's file is missing, so its sphere gets the placeholder.

Meshes

A sphere can compute its $(u, v)$ . A mesh can't. The artist decided it, and it's stored in the OBJ file. A fine arrangement, because I was not writing those myself.

The file doesn't store a $(u, v)$ for every point on the surface, though. It stores one per corner: each vt line is a $(u, v)$ , and each corner of a face names one alongside its position.

vt 0.25 0.50
f 1/1 2/2 3/3

A ray almost never lands exactly on a corner. It lands somewhere inside the triangle, so its $(u, v)$ has to be a blend of the three corners' values, weighted by how close the hit is to each corner. Those weights are the triangle's barycentric coordinates.

Barycentric coordinates as areas: each weight is the sub-triangle opposite a corner over the whole triangle. The u, v and w here are those weights, not texture coordinates. Figure: Scratchapixel, CC BY-NC-ND 4.0.

Barycentric coordinates describe a point inside a triangle as three weights that sum to 1, one per corner, each the area of the sub-triangle opposite it. A hit on a corner gives that corner all the weight while a hit in the middle shares it equally.

The best part: the intersection test already computes these weights to decide whether the ray hit the triangle at all. So the hit's $(u, v)$ is just the three corners' $(u, v)$ blended by the same weights that placed it on the triangle.

Paint each piece of the result its own color and you see the artist's unwrap: the model cut into pieces, called islands, and laid flat on the image.

Top: the SMG with each UV island painted its own color. Bottom: the artist's unwrap, every island in the same color it has on the gun, so a patch on the gun and its island match. Model: "SMG GUN Remastered" by ROHIT3DMODELS, CC-BY-4.0.

Matching Cycles

I am proud of how far my renderer has come, but looking right is not the same as being right. So I checked it against my favorite renderer, or more specifically the easiest to access: Blender's Cycles.

Blender rebuilds the same scene from a script, and my tone map is applied to its output. Then a script compares the two.

Top: my renderer. Middle: Cycles. Bottom: their difference, four times brighter. Model: "SMG GUN Remastered" by ROHIT3DMODELS, CC-BY-4.0.

256 samples per pixel	Mean color (R, G, B)
My renderer	116.28, 138.90, 142.72
Cycles	116.30, 138.92, 142.73

Mean absolute difference: 2.36 out of 255, and I can assume that is just noise. I will take it that my renderer matches Blender Cycles. Take it or leave it.

Note: this is extremely simplified. Blender was instructed to use the same simplifications as mine, so not all the artist's changes are present. It is not the artist's full look, but I will still take the win.

Where did I mess up? Because that always happens

Rings on every floor. A debug view of surface color alone showed two clean colors, so the rings were shading. The floor is a sphere of radius 1000, and in single precision a hit that far out rounds to just inside it, so bounce rays shadowed the floor they started on. Double precision fixed it. In hindsight, it should have just been a plane.

Wrong: concentric rings on the floor, from rays shadowing the surface they started on. Car: "CAR Model" by Ignition Labs, CC BY 3.0.

Blender painted one part out of six. My first comparison model was a cartoon spaceship, and the comparison had whole parts missing. My solution was very elegant: I used a different model immediately. That's the reality of software development. It's a bug I will fix, but for now the main focus is getting a properly rendered image. Trade-offs had to be made and prioritized.

Wrong: the Blender side painting one of the ship's six parts. Model: "Cartoon spaceship" by pinguinoconpulgares, CC-BY-4.0.

What I do now

Check against a renderer I trust. Looking right is not being right. My initial hunch was right, but I will emphasize it. Cycles just made it quantifiable.
Build a debug view for every new input. The $(u, v)$ view showed the unwrap, and the surface-color view showed the rings were not the texture.

Credits

"SMG GUN Remastered" by ROHIT3DMODELS, from Sketchfab, CC-BY-4.0. Rendered with its base-color map only.
"Cartoon spaceship" by pinguinoconpulgares, from Sketchfab, CC-BY-4.0.
"Merged Cassini and Juno global map of Jupiter", processed by Björn Jónsson. Credit: NASA / JPL-Caltech / SSI / Southwest Research Institute / Malin Space Science Systems / Italian Space Agency (ASI) / Italian National Institute for Astrophysics (INAF) / JIRAM / Björn Jónsson, CC BY 3.0. Wrapped onto a sphere and rendered. Source.
"CAR Model" by Ignition Labs, from Poly Pizza, CC BY 3.0. Rendered with a checkered pattern in place of its own materials.
Barycentric coordinates figure from Scratchapixel, "Ray-Tracing: Rendering a Triangle", CC BY-NC-ND 4.0. Used unmodified.
Peter Shirley, Trevor David Black and Steve Hollasch, Ray Tracing: The Next Week, chapter 4.

From a path tracer I'm building in C++. Previously: a hexagonal aperture and the white furnace test.

Apparently, Bland 2D Grey Squares Are Important to My 3D Renderer

Ibukun Sanni — Thu, 22 Oct 2026 14:38:50 +0000

The white furnace test: like the Chūnin exams, handing in a blank page is how you pass.

A furnace render: an albedo-1 sphere inside a uniform environment of radiance 0.5.

There’s a sphere in that picture. Can you see it? No, you can’t. If you could, my renderer would be wrong, and I wouldn’t like that.

What is the furnace test?

Put a sphere of albedo 1 (a surface that absorbs nothing) inside an environment of radiance $L$ in every direction. Every camera ray either misses the sphere or hits it.

$P$ : a miss reads $L$ . It escapes straight to the environment.
$Q$ : a hit bounces until it misses, so it reads $L$ too.
$R$ : the square is flat grey. Every pixel reads $L$ , so the sphere has no edge.

P \land Q \Rightarrow R

Two camera rays in the furnace. One misses the sphere and reads the environment, L. The other hits the sphere, keeps all of its energy, bounces, and escapes to the same environment: 1 × L = L. Both pixels read L, so the sphere has no edge.

The test runs it backwards. If I can see the sphere, $R$ is false, so $P$ or $Q$ is. $P$ can't be, so $Q$ is: the renderer is losing energy if the sphere is darker, and making it if the sphere is brighter. If the furnace test is working, you see nothing. Naruto would be proud.

To see a real-world example of this, I highly recommend Julien Guertault's "The white furnace test". It opens with a ski-slope photo that matches what $R$ predicts.

One place to look

In my renderer, every material has the same three functions, the same split as pbrt's BxDF (f, PDF, Sample_f):

// How much light goes from `out` to `view_dir`: the BRDF, f_r.
glm::vec3 Eval(const glm::vec3& view_dir, const HitRecord& hit,
               const glm::vec3& out) const;
// The density Sample() draws `out` with.
float Pdf(const glm::vec3& view_dir, const HitRecord& hit,
          const glm::vec3& out) const;
// Draw a direction, and report its pdf and BRDF.
glm::vec3 Sample(Rng& rng, const glm::vec3& view_dir, const HitRecord& hit,
                 float* pdf_out, glm::vec3* brdf_out) const;

Each bounce, the renderer multiplies the ray's energy by one number built from them:

w = \frac{f _{r} cos θ}{p}

$w$ : the weight, the fraction of the ray's energy that survives the bounce.
$f_{r}$ : the BRDF, Eval(). How much light the surface sends from the new direction toward the old one.
$cos θ$ : the cosine of the angle between the new direction and the surface normal. Light arriving at a slant is spread over more surface.
$p$ : the pdf, Pdf(). How likely Sample() was to pick that direction.

That's the only way a material touches a ray, so it's where every energy bug lives. For a white diffuse surface, $w$ should be exactly 1.

What failing looks like

Seeing a correct test isn't enough, because a correct test shows literally nothing. So I broke the diffuse material to see what failure looks like:

The furnace with a correct material, and with two classic bugs. Counting the cosine twice makes the weight ρ·cos, which averages 2/3, so the sphere drops from 128 to 85. Forgetting the 1/π makes the weight πρ, and the sphere clips to white. At radiance 1, that same bug is invisible.

A cosine counted twice makes $w$ average 2/3, so the sphere should read 128 × 2/3 = 85. The render says 85.

A forgotten 1/π makes $w = π$ , so the sphere should read > 255. A byte stops at 255, so it clips to white.

The last panel is the same bug at full brightness. The background is already 255, the sphere clips to 255 too, and the bug hides. That's why I render at half brightness, where the target is 128 with room on both sides. Bland 2D Grey Squares Are Important to My 3D Renderer

Every material gets the same test

Nothing in $P$ or $Q$ says what the sphere is made of, so the same scene checks every material.

The same furnace with three other materials. The mirror vanishes exactly. The rough metal leaves a dark ring at its silhouette. The glass vanishes on average, with a few noisy pixels at its rim.

Mirror: vanishes exactly. It sends all the light one way, and every way looks the same.
Rough metal: a dark rim, and that's correct. At grazing angles some reflections get nudged into the surface and are absorbed. It can lose energy but never make any, so its test is "nothing brighter than 128".
Glass: vanishes on average (127.9). Its radiance goes up by η² going in and back down coming out, so the two cancel out.

Limits of the furnace

It only measures how much light comes back, not where it went. A material that scatters the right amount in the wrong directions still vanishes. I found that out with a hexagon-shaped sampler in a previous post.

What I do now

Render the furnace for every new material.
Predict the failure. If the math says 85, the render should too.

Just for fun: the Byakugan (because of all the Naruto references)

The furnace at full brightness with an eye painted on the sphere.

References

Julien Guertault, "The white furnace test", 21 October 2023.

From a path tracer I'm building in C++.

A Hexagonal Aperture Would Break Every Diffuse Surface in My Renderer

Ibukun Sanni — Sat, 26 Sep 2026 16:28:46 +0000

I have experimented with a lot of features on my raytracing journey. I played with reflections, implemented shadows, and lost braincells getting scenes to render. Finally, I implemented defocus blur.

My defocus blur, focused on the near plane

The image reminded me of the bokeh you see in photos. Sometimes they aren't always round.

Not a render. Photo from "Bokeh Effect in Photography: A Guide to Gorgeous Background Blur" by Annie Tao, Digital Photography School.

So I tried it with what I already had: two passes of the same scene, one circular and one hexagonal.

Same scene, different sampler

At that point I felt like I could turn anything into bokeh. I could have hearts, stars, concentric circles. Why not push it further?

Then I noticed something. Every diffuse surface in my renderer would suffer.

Here is the primitive that both my lens sampler and diffuse surface lean on. It rejection-samples a square until a point lands inside the unit disk, and that test is the only reason the shape comes out round.

inline glm::vec2 SampleUnitDisk(Rng& rng) {
  while(true){
    float x = rng.Range(-1.0f, 1.0f);
    float y = rng.Range(-1.0f, 1.0f);
    if (x * x + y * y <= 1.0f) return glm::vec2(x, y);
  }
}

And here is what the hexagonal change looked like:

// Regular hexagon inscribed in the unit circle: corners at radius 1, flat top
// and bottom, flat edges at the apothem sqrt(3)/2 ~= 0.866.
constexpr float kApothem = 0.8660254f;

inline glm::vec2 SampleUnitDisk(Rng& rng) {
  while (true) {
    float x = rng.Range(-1.0f, 1.0f);
    float y = rng.Range(-1.0f, 1.0f);
    // WAS: if (x * x + y * y <= 1.0f) return glm::vec2(x, y);
    if (std::fabs(y) <= kApothem &&
        std::fabs(kApothem * x + 0.5f * y) <= kApothem &&
        std::fabs(kApothem * x - 0.5f * y) <= kApothem) {
      return glm::vec2(x, y);
    }
  }
}

The two separate call sites:

// The camera: a physical aperture.
const glm::vec2 lens_uv = SampleUnitDisk(rng) * cfg.aperture_radius;

// The diffuse BSDF wrapper
inline glm::vec3 CosineWeightedHemiSphereSurface(Rng& rng,
                                                 const glm::vec3& normal,
                                                 const glm::vec3& tangent,
                                                 const glm::vec3& binormal) {
  const glm::vec2 d = SampleUnitDisk(rng);
  const float z = std::sqrt(std::max(0.0f, 1.0f - d.x * d.x - d.y * d.y));
  return d.x * tangent + d.y * binormal + z * normal;
}

Why do my BSDF and my lens share a disk sampler?

Fair question. If testing, or more fittingly, playing with my lens can break my diffuse surfaces, why the coupling?

The BSDF side is Malley's method. Sample a point inside a unit disk, then project it along the normal onto a hemisphere originating from the ray's intersection with the surface. That is how you implement a diffuse surface.

The lift, drawn. Every point on the disk rises straight up to the dome above it. Figure A.10 from Physically Based Rendering: From Theory to Implementation, 4th ed., by Matt Pharr, Wenzel Jakob and Greg Humphreys.

The lens side never heard of Malley. Randomizing around the origin allows the ray to focus on a particular plane. Near and far objects blur out, while whatever sits on that plane stays in focus. Guess how we randomize around the origin. Exactly!! We sample within a unit disk.

"Camera focus plane", Figure 1.22 of Ray Tracing in One Weekend by Peter Shirley, Trevor David Black and Steve Hollasch, released under CC0.

So both sides have to sample a unit disk, and voila; one function, two callers. Apparently PBRT does it the same way, so I will take that as great minds thinking alike.

I only caught it by reading the code

So how did I catch it? I read the code, because I wrote it. Nonetheless, I cannot rely on that catch. I could easily have missed it, someone opening the file a year from now could miss it too, and neither of us would know the diffuse was off until much later.

Looking at the render does not help either. I can make the hexagon, sure, but the diffuse barely moves.

Every surface in that box is Lambertian, so there is nothing else to look at.

Do you notice the difference? Do you see the shadows shift? Yeah, neither do I. Without the two frames side by side I would have walked straight past this.

So I said to myself, "What can I actually check for?"

Check that it is still a circle? I can only answer that by looking at what the sampler draws rather than the lines that produce it.

Any sampler is correct as long as the `Pdf()` tells the truth

So start with the shape mine draws, and why it works at all. It works because solid angle projects onto the disk with a factor of cosine, $d A = cos θ d ω$ , so a uniform disk sample lifted to the hemisphere has density

p (ω) = \frac{cos θ}{π}

For a Lambertian surface, whose BRDF is $ρ / π$ , the estimator then cancels completely:

\frac{f _{r} cos θ}{p ( ω )} = \frac{( ρ / π ) cos θ}{cos θ / π} = ρ

Each bounce multiplies output by exactly the albedo, ρ (the fraction of light a surface sends back, [0,1]).

Read that derivation again, though, and notice what it never asks for. It never asks for a disk.

Which means I can build the same lobe without one. Here is the road Ray Tracing in One Weekend takes: stand at the tip of the normal, push out by a random unit vector, and normalise where you land.

const glm::vec3 dir = glm::normalize(normal + RandomUnitVector(rng));

That one draws from a ball. It never touches a disk, and it arrives at the same cosine lobe anyway. Two roads, one distribution and I can compare without knowing in advance where the distribution is supposed to be. Get it memorized.

The lift, and what the hexagon does to it

Malley's method is one picture. Put the shape underneath the hemisphere like a floor plan, and let every point on it rise straight up to the dome. The height it lands at is cos θ. The cloud of directions you end up with is the lobe: the fat dome.

Same dome, same straight-up lift, same horizon, and in both the rise is cos θ. The only thing that differs is the rim. The disk's sits on the horizon the whole way round; the hexagon's plunges there at six corners and arches up to cos θ = 0.5 midway along each edge.

Look at the hexagon in that diagram and notice how little moved. Every point still lands above the horizon, the centre still maps to the normal, and it is still a fat lobe crowding around it.

What moves is the rim, and only the rim. A hexagon's corners reach r = 1, but its edges cut in to the apothem (as close as an edge ever gets to the centre) = √3/2 ≈ 0.866, and √3/2 lifts to cos θ = 0.5. It's SOH CAH TOA again. So the grazing directions survive in six chunks and are gone the rest of the way round.

Which is enough to price the damage before anything runs, because the lift hands every question about the lobe back to the floor plan. Malley over a region $R$ of area $A$ gives density $cos θ / A$ , so every moment is an integral over the shape:

E [cos^{k} θ] = \frac{1}{A} \int_{R} (1 - r^{2})^{k /2} d A

Read $E [\cdot]$ as "the average of". At $k = 2$ we lose the square root entirely:

E [cos^{2} θ] = 1 - E [r^{2}]

so the second moment is the floor plan's mean squared radius. At $k = 1$ , one polar integral per edge, and for a hexagon it closes:

Floor plan	Area	`E[cos]`	`E[cos²]`
disk (correct)	π ≈ 3.142	2/3 ≈ 0.6667	1/2 = 0.5
hexagon	3√3/2 ≈ 2.598	3π/4 − 8√3π/27 ≈ 0.7439	7/12 ≈ 0.5833
hexagon, off by	−17.3% of the area	+0.077	+1/12 ≈ 0.083

Nothing is specific to hexagons. Hand it a square, a heart, a five-pointed star, and the same two integrals price that sampler too. And the other road has no floor plan at all, which is the point of it: built out of SampleUnitBall, it sits on the disk's row, 2/3 and 1/2, exactly, whatever shape the lens becomes.

So we currently have a few predictions in before a single test run: 0.744 against 0.667 with a gap of 0.077.

Get that memorized, also.

So I built the bug on purpose

I reverted to a hexagon in SampleUnitDisk and ran my tests.

The disk (blue) lands on the exact cosine lobe (grey); the hexagon (orange) does not. Its step at cos θ = 0.5 is the apothem, lifted, and the two markers on the axis are the means: 2/3 and 0.744.

Check	Compares	Real sampler	Hexagon
10 render tests (6 furnace)	pixels vs environment	pass	pass
Mean cosine	vs 2/3	0.6663	0.7437 -- fail
`cos²/pdf` integral	vs 2π/3 ≈ 2.0944	2.0943	2.3373 -- fail

The furnace passed, as expected. All 10 render tests stayed green, the 6 furnace tests among them. The furnace check essentially checks the radiance, and that was virtually no different.

Correct looks like this. So does broken. The third panel is every pixel that moved between them → 9 of 65,536, one byte each.

The two below it check shape (for a Lambertian the second is π times the first on average; the two tests draw separate samples) and both failed. In line with our prior prediction. Remember the 0.744 number. Yeah, we are in business now.

The test that caught it

Let's dive deeper into that test. Before making the change I had already written a test that builds the cosine lobe that way, and it draws from SampleUnitBall, not SampleUnitDisk, so it cannot move when the aperture does. Two constructions of one distribution have to agree on every moment, which makes them a differential test: no reference renderer, no known answer needed. Over 2 million samples each:

	`E[cos]`	`E[cos²]`
Malley (disk lift)	0.66634	0.49964
`normalize(n + RandomUnitVector())`	0.66662	0.49999
hexagon lift	0.74374	0.58309
exact, cosine lobe	0.66667	0.50000
exact, hexagon lobe	0.74393	0.58333

We can see from the table above that we were right to 3 significant figures, and the gap that is left is within sampling noise. In other words, we were still right. The earlier predictions for both E[cos] and E[cos²] match up.

What I do differently now

Share on mechanism, never on coincidence. I will still share primitives. The ideal move is creating new primitives for specific cases. I already knew that. Utilizing a proper separation of concerns.
Test the shape, not just the total. The furnace passed, and it measures totals. I still needed to test the shape.
Build the bug on purpose. You just might learn something.

The shapes I wanted in the first place

The lesson was never "don't shape the aperture." It was "give the lens its own sampler first." So that is what I did, and then I spent an evening on the part that has no excuse.

Same field, same seeds, four openings. Only the rejection test moved.

Look at all those images. "chef kiss." This was really all I wanted and it could have broken such a key section of my ray tracer. Sometimes that is the price of having one.

From a path tracer I'm building in C++. Next: getting total internal reflection wrong in four different ways before getting it right.

DEV Community: Ibukun Sanni

My Renderer and Blender Painted the Same Gun

What is a texture?

Painting from space, then painting the surface

Reading an image

Meshes

Matching Cycles

Where did I mess up? Because that always happens

What I do now

Credits

Apparently, Bland 2D Grey Squares Are Important to My 3D Renderer

What is the furnace test?

One place to look

What failing looks like

Every material gets the same test

Limits of the furnace

What I do now

Just for fun: the Byakugan (because of all the Naruto references)

References

A Hexagonal Aperture Would Break Every Diffuse Surface in My Renderer

Why do my BSDF and my lens share a disk sampler?

I only caught it by reading the code

Any sampler is correct as long as the Pdf() tells the truth

The lift, and what the hexagon does to it

So I built the bug on purpose

The test that caught it

What I do differently now

The shapes I wanted in the first place

Any sampler is correct as long as the `Pdf()` tells the truth