Remember that pin table map from ‘X-Men’?

Here’s how it was simulated, two decades ago.

X-Men, released this week 20 years ago, is full of great visual effects, from character work through to one-off VFX shots. One of those was the pin table map seen as the heroes plot to stop Magneto from unleashing chaos on New York City.

Behind the visual effects for the table map, which featured pins re-configuring themselves as pieces of NYC geometry such as the Statue of Liberty, was C.O.R.E. Digital Pictures.

Berj Bannayan, now a co-founder of Soho VFX, was in R&D at the time at C.O.R.E., where he played a key role in engineering a solution for the pins using SideFX’s Houdini. He shares his memories of that time with befores & afters.

The problem of pins

Berj Bannayan: It was during shooting that we started to do the R&D on the table. My boss at the time, [C.O.R.E. VP] John Mariella, was doing a lot of the visual development. This was in Houdini. The team was referencing those executive toys that you’d press your face into with the pins. We had to work out, are the pins square? Do they have a head on the top? Are they hexagonal? How many of them per inch? The table itself was a physical thing in the world. It was just this big round table with some tracking markers on the top.

Back then, Houdini was still fairly rudimentary in terms of its feature set, and we were finding a lot of speed problems stimulating all of those pins. I was one of the software developers working at C.O.R.E. I realized we’d been trying to make something with expressions and animation, but that made it too slow. So I said, ‘Look, let me work on making a real simulation engine for this table.’ I started to explore making custom SOPs for this specific task.

The first idea was to show something static, just a location. The ‘camera’ of the map wasn’t moving but the pins would come up. But then they wanted this springy bouncy feel to the pin animation. So now we had to work out how to do all that. How do we make all of the technology that allows us to be arbitrary for what the director wants on the table? That became a software task for me, essentially a simulation.

Solving the problem

We would ultimately build the table of pin-heads as a piece of digital geometry with, I think, 10 pins per inch. We ended up with a square head on them. It was just the center of each pin head; a field of dots that we built. And then what we were able to do is basically make them do anything.

The modelers would build a piece of geometry on top of the table. All of the pins would fire up and there was a little spring stimulation, and they would intersect with the geometry and it would bounce and settle into its place and then it would stop and settle there.

Once we had the position of the top of the pins, there was some SOPs that I built in Houdini that would actually build the geometry of the pin from its simulated top position all the way down to the surface of the table. It was pretty cool because you could move the geometry and press the ‘go’ button again and all of the pins would, instead of the rest position at the table surface, they would simulate down to the new position.

So if a pin was up at a certain location and it needed to go to the new position then it would bounce down. And then if one was low, it would bounce to the top. It was able to do these changes from one position to another.

I think I just built blobs first – a typical programmer, I didn’t have any real modeling ability – I’d put a square down and ‘boink’, the pins came up into the shape of the square. And then if I moved the square over and pressed the go button again – ‘boink’ – the pins that were high would go low, and the pins that were low would go high. Ones that were already in the right place would stay where they were.

The artist would be able to tweak how much springyness the pins had and how much lag time they had, too. We tried to make it so that it was an ‘anything’ engine. You could put anything on the pin table that you wanted. It could be any shape, but you just fed it pile of pins.

For the Statue of Liberty, under her arm, they didn’t want to just have long pins to come up and make this kind of extruded blob of stuff. So, what we did was we – the conceit was that the pins could have a length. We would shoot a ray up along the distance of the pin. We would pre-load a spring that has two distances, and just fire up a little stick that floats in the air. It would cheat, really. That way, we could make something that looked a little bit more like a shape with voids and overhangs. It worked for the bridges as well.

Wrangling the render

Once we had the geometry of it, we then had to work out, how was it lit? It was still the late 90s – we didn’t have the fastest machines in the world. This geometry was fairly heavy. Each of those pins at the end of the day became a five-sided cube. We simulated on very light geometry just the points first, and then built the geometry around it at the end.

Every time a shot needed to be done, it was a couple of days of work. If they changed the camera or changed the shot or wanted something different to move, it was a process to go through. We’d have to track the camera, then simulate the pin table, then build the geometry of the pin table, save all of that out, and then it went on to look and lighting.

In lighting those things, back then, there wasn’t a lot of ray tracing. RenderMan was only very nascent in its support of any sort of ray tracing. So the idea was to use shadow maps. We did do that but it never quite looked right. The geometry was long and thin and getting shadow maps to work was very hard.

Then I said, ‘Let me try some sort of ray tracing thing.’ My idea, which worked but it was a huge pain, was that we would ‘turn’ ray tracing on and bake it into the tops of the pins. I built what we would now call some kind of reflection occlusion in Houdini SOPs. From the top of each pin, I would shoot a ray and I would raytrace to the center of a point light or a spotlight. Depending on how much stuff was in the way, I would color the top of the pin. I would make it lighter or darker from white to black, ie. fully in shadow.

We would run that ray tracing over the surface of every piece of geometry and that then became the basis for a shader that would take that color and use it to deal with the reflections of the scene and all of the real lighting. It was a baked-in ray traced shadow that was on top of the pins and along the length of the pins. It worked out pretty well, but it was very slow. If the lighting changed, we would have to go through this whole process again.

Also, there was a thing in RenderMan at the time where it rendered in buckets that went across the image. But as soon as it hit a piece of geometry, it would have to maintain that piece of geometry in memory until the last time it saw that piece of geometry. With the pins being long and vertical, the renderer would first see the pin at the top and that whole pin would have to stay in memory the whole time. So we actually rendered it on its side so that it would render along the pin and then it was done with that pin and it could leave RAM.

It was one of those little hacks; all of this stuff that we had to do just to get render times in the order of hours a frame. Today, I would probably do the pin table software the same in Houdini. But the rendering would be a whole different thing now, it would be almost trivial.

Memories of a pin table, and X-Men

We did that New York map and also a scene at the end where Professor X is showing Wolverine the location of his birthplace. That work stands out in my head, mostly because people kept asking me about it. It was amazing – I would be at SIGGRAPH and someone would say, ‘Oh, you guys did that pin table thing!’ And it lasted for years, long after I’d left C.O.R.E.

It’s funny because I happened to work on the first Fox X-Men movie and the last Fox X-Men movie, which was Dark Phoenix. They really book-ended this moment in time for me and they were almost exactly 20 years apart in terms of me working on them.