3D Artist on Creating a Geometry-Based Plugin That Makes Realistic Worn Edges

Introduction

I'm Cornelius Dämmrich, and I'm a 3D artist based in Cologne, Germany. I've been doing 3D for about 23 years now.

I got into it when I was 15. Somebody handed me a burned CD with Cinema 4D R8 on it, and my friends and I started doing these little contests against each other, just for fun. I kept making images in my spare time, and at some point, that turned into an actual job. Over the years, I've worked for NASA, THQ Nordic, ZA/UM, Atlantic Records, Elastic.tv, and Elastique.

As for my skills, my focus is digital art. I can write a few lines of Python without too much help, but I've spent 90% of my career getting good at 3D, not programming. Agentic coding tools made this project a lot more doable for me, and what surprised me is how much of the 3D experience actually carried over. After 23 years of using this stuff, I know pretty well what exactly I want a tool to do, how it needs to feel when you use it, and what things to stay away from. That knowledge used to be worth nothing on its own, because you still needed somebody else to build it. That barrier is just gone now.

Which is more or less how I ended up making tools for other people. I wanted one; it didn't exist, and this time it wasn't the end of it.

Getting Started With Edgy

There was this research plugin for Cinema 4D that did the edge damage part, and it was really nice. It doesn't run in any current version anymore, and my first idea was to just patch the old one. But you can't find it anywhere online now; the research group moved on years ago, and the download is long gone.

So I looked up the paper that the people behind it wrote – "Exemplar-based Worn Edges", Eurographics 2007, by Christoph Brachmann, Benjamin Walther-Franks and Jorn Loviscach – and built my own version of the idea with Claude.

I've always liked the geometry-based approach to edge wear more than the shader one. Pointiness, curvature maps, AO, proximity masks – they all just shade the edge differently; none of them actually takes any material away. You wouldn't notice that on a flat-lit turntable, but you'd absolutely notice it in a real shot. As soon as the edge sits against a bright background, or the camera pushes in, a shaded fake reads as a perfectly sharp edge with a dirty texture on top of it. And I always wished somebody made a current version of that: basically a one-trick pony with presets that you can quickly run over an asset and then move on.

Doing both hosts wasn't really a plan – it was just math. I work in Cinema 4D, so that's where it started, and that's still the reference version. But the Blender market is bigger, and I'd already made the one decision that made the port cheap without knowing it: the geometry code doesn't touch a single Cinema 4D type. You hand it points and polygons, it hands you back mesh. So Blender ended up being a front end on the same compiled binary rather than a second implementation, and the same seed gives you the same damage in both, chip for chip. There's a test that feeds both of them identical input and requires an exact match, no tolerance.

Damage Modules

For the most part, as I was creating damage modules, I kept asking myself whether a module did something none of the others could, and cut it if the answer was no.

Chips are the base; that's the edges losing material. Edgy looks for every edge where two faces meet above a certain angle, links those into continuous ridges that follow a curve around a cylinder or over a bevel, and then spreads chips along them by length, each one in its own local frame so it sits properly on a curved rim.

Corners are there because a corner simply isn't an edge. It's the first thing that hits the floor and the last thing anybody repairs, so it gets one big crater pointing straight out along the average of the edges running into it. A corner doesn't chip sideways; it gets knocked off.

Craters on flat surfaces are impact-based rather than wear-based. They're spread by surface area instead of per polygon, and they're capped by how far they are from the nearest edge, because a crater that reaches over an edge gouges the face next to it and immediately looks like a bug.

Fracture was by far the hardest module, and it's the one I'm happiest with. My first version grew each crack for a fixed length and then stopped, and it looked completely wrong. It took me a while to figure out why: real cracks don't randomly stop in the middle; they run until they hit something, either another crack or the edge of an object. Once I made them go on until they meet a boundary, the network became a real partition of the surface, and that's what lets the second and third level break up the pieces the first one created.

Buildup does the opposite of everything else, which is exactly why it's in there. It adds material instead of removing it – the cement, paint, or rust that collects in the inside corners where nobody ever got in with a brush. Damage on its own looks like pure destruction; but damage with buildup looks old.

Breaker is a big one, where a whole chunk of your object is gone. You drop a gizmo into the scene; it carries a noisy surface, and everything on one side of it gets subtracted. Because it's a real Boolean against a noisy surface and not a flat cut, the break face has actual structure, and the rim it creates can get chipped in turn.

One thing I decided to keep instead of fixing is the breaker cutting the buildup. That is, if a piece breaks off, it takes the cement bead sitting on it with it. That surprised me at first, but then I looked at it, and it was just correct.

Technical Challenges

The tool modifies the mesh itself rather than relying on textures or normal maps, because you see it in the silhouette; that's really the whole reason I went for this approach. If you want a chip that reads as missing material from every angle, then the material has to actually be gone.

The way it works is that every bit of damage is a small closed solid – a bowl for a chip, an ellipsoid for a crater, a wedge along a crack, a volume for a break. They all go into one batched Boolean subtraction against the mesh using Manifold, and doing it in batches instead of one at a time is what makes overlapping damage merge into one cavity instead of leaving broken shells lying around.

The performance side caught me off guard, because my instincts were wrong. I assumed the cost scales with mesh size, so that's the part I optimized. It doesn't. What matters is the number of cutters, pretty much regardless of how big the mesh is. Once I actually measured that instead of guessing, the fix was obvious – every cutter now gets tessellated based on how big it's actually drawn – and one of my test scenes went from 40 seconds to 13 with a result you can't tell apart.

Another thing that took a lot of time was the caching problem. Edgy remembers what it already built so it doesn't recalculate everything after every little change, and it works that out by comparing all the inputs. Then I animated a scene, and it rebuilt everything from scratch on every single frame. What was going on was that the numbers describing where an object sits drift by an unimaginably small amount per frame, way too little to ever see, but enough that they never count as the same twice. And it got worse: the viewport and the renderer ended up with slightly different numbers, so if you cloned the object across a surface, about forty percent of the copies sat somewhere else in the render but not in the viewport, some of them two meters off.

Presets

Honestly, presets exist because the first version failed. I had someone else try Edgy; they opened an object, saw seven tabs full of parameters, and did nothing at all. So I added three buttons: Mild, Strong, Heavy. One click, you see damage, and now you have something to react to instead of a wall of numbers.

The rule behind them is that a preset sets strength, but never determines which edges qualify. It'll change your chip size, your crater amount, your crack width. It won't touch your seed, your edge threshold, your topology mode, or your breakers, because those are your decisions about your particular object. Once people know they can't break anything by clicking a button, they click it, and that's how they figure out what the tool does.

The values also aren't numbers I typed into the code. They live in an actual Cinema 4D scene that I tuned by eye, and a script reads that scene and generates the tables for both applications. That's what makes Mild in Blender bit-for-bit the same Mild as in Cinema 4D.

User library is the obvious next step: save what you've got right now, name it, get it back on any object later. What I think people will build is a vocabulary per material rather than per project. Cast concrete doesn't wear like a painted handrail, and neither of them wears like a wooden crate. The interesting presets are the ones somebody tunes once against a reference photo and then uses for years, and if people are up for sharing theirs, I'd happily ship a library.

Switching Between Blender and Cinema 4D

The rule I set right at the start was that Cinema 4D is the baseline. The Blender version and the Cinema 4D version are not equal; it's not like each one is getting whatever design fits it best. Instead, one is the reference and the other one matches, down to parameter names, ranges, defaults, and the order of the tabs. Without that, they drift apart within a month, and you're maintaining two products.

The architecture makes that cheap, because the geometry code doesn't name a single Cinema 4D type or make a single SDK call. It compiles twice, once into the plugin and once as a standalone module that Blender loads, and there's a check that fails the build if a Cinema 4D type sneaks into the shared part.

The differences that were left had almost nothing to do with geometry. The two applications shade a surface a bit differently, so the Blender result needs one extra step to look the same. And a few things simply exist in one and not in the other: Cinema 4D lets you tag the damage as named polygon selections so you can put a material on them; Blender doesn't have those, so there you have one material slot per damage type instead. Nothing about the actual damage changes, only how you get at it.

One licensing thing people ask about: the Blender add-on is GPL v3, so the compiled core inside it is too, and that source is up on GitHub. The Cinema 4D plugin ships the same code as proprietary, which I can do because I'm the only copyright holder.

What's Next

I'm planning to expand Edgy further, and at the top of the list is the thing the original paper is actually named after.

Right now, every chip outline is procedural – basically an ellipse with a few harmonics on it. It looks convincing at a glance, but it has one genuine weakness: every chip is the same smooth lens shape at a different size. "Exemplar-based" means the shape comes from a real example, so what I want is to hand Edgy splines actual traced-off damage and let the character come from real material instead of a formula.

The second one is buildup on the whole object instead of only the original inside corners. At the moment, it finds the concave edges of the model you give it, and it should also collect inside a chip, along a crack, around a break rim.

Past those two, I'm not going to promise a roadmap. Edgy has been on sale for just a little while, and I'd rather build the third thing somebody actually asks for than the fifth thing I came up with on my own.

Get Edgy

Edgy is available on Gumroad. It's 15 dollars, and one purchase covers everything – Cinema 4D 2024, 2025, and 2026, Blender 4.2 LTS and newer, Windows and macOS. I didn't want anybody doing math on which version they needed.

The core's source, the part that's GPL because of Blender's side of things, is on GitHub.

The rest of my work is on my website, my other tools are on Gumroad as well, and you can also find me on Instagram and X.

And if you make something with it, please show me. I've been staring at my own test cubes for six weeks, and I'm very ready to look at somebody else's work.

Cornelius Dämmrich, 3D & VFX Artist

Interview conducted by Emma Collins