Under the Hood: An Extension Ecosystem with Christina Eneroth

If a tool or command doesn’t exist in SketchUp, Julia Christina Eneroth builds it. A designer and developer, Christina has published 66 extensions and plugins to Extension Warehouse, virtually creating her very own 3D modeling ecosystem (which she’s graciously shared with the rest of us).

Out with the old, in with the reimagined. Christina redesigned an old silo as a residential building in the suburb of Staffanstorp, Sweden.

Let’s start from the beginning: What was your first experience with SketchUp?

I was first introduced to SketchUp when shadowing an architect in elementary school. Fortunately, I was able to download it for free and continue modeling at home. That very first SketchUp download took five hours on my family's dial-up modem, and to this day, I’m very thankful my mum didn’t interrupt it. It made us late for a dinner, and I had to pay for a taxi as we couldn’t make the bus. That was probably the best spent money in my life.

Back in those early days, 3D Warehouse had a 10 MB file size limit. That wasn’t enough space to publish the models I working was on, so I started making my own websites. That’s when I was introduced to how computers execute code, how they blindly follow instructions, and how you very precisely tell them what to do.

Christina’s first model in SketchUp is a far cry from her more recent designs, but her early projects served as the gateway to her future as a visual artist and extension developer.

Talk about your progression as an extension developer. How do your first extensions compare to your later ones?

If I remember correctly, my first script was for assigning layers to geometry. I was working on my castle, Schloss Eneburg, which had many levels with different ceiling heights and floors. That essentially made it impossible to look inside the model using SketchUp’s native section cut tool. Coming up with a solution to that issue was the catalyst for writing my first ever SketchUp Ruby script.

In general, the quality of the code is light years beyond what it once was. I had to abandon some projects early on because the code was too messy and impossible to maintain. Everything was interconnected to everything, and all of it had to be adapted when trying to make the smallest change. I’ve learned about code readability, decoupling, and organization the hard way: by losing months of hard work. All of this has helped me advance as a developer, and has helped me get where I am today.

In that same vein, I highly recommend that anyone developing an extension think about its intended scope. It’s so easy to add just one more feature to an extension, but if that feature isn’t within the scope, it gets messy. What if someone wants just that one feature, but not the rest of your extension? What if a user can’t find a feature at a later time because it’s arbitrarily packed into an unrelated extension? My rule of thumb: if you’re unsure whether a feature is within the scope of the extension, try making it a separate extension. If it makes sense as a stand-alone extension, keep it that way.

One of the things I love the most about SketchUp is its modular architecture, and how that allows for a very simple core.

What’s the story with the castle project?

I’ve always been fascinated by castles, and as a kid, I dreamt of living in one myself. I started the project in high school, and in a way it was a throwback to what I had sketched when I was young. The castle has many eccentric details, like the bridge that takes you between two different towers.

Looking back, the castle feels like a single project in a long string of work, but when I actually look at how much time I spent on it and how much work I put into it, it dwarfs all my other previous projects combined. When I started working on the castle, I had been using SketchUp for about a year and a half, and I worked on it actively for five years.

Schloss Eneburg is a fictional castle Christina created that took more than five years of active modeling to complete.

How do you come up with so many ideas for new extensions?

All of my extensions spring from the needs of my own modeling workflow. In my opinion, this is the reason why many of them have been so well received by the community. Rather than coming up with an idea to increase sales or develop new products, I design exactly what I need as a user; by myself for myself. And unsurprisingly, a lot of other people have those same needs.

Many of my extensions start as a few lines of code, sometimes a single line, that I write in the Ruby console to get the job done. Then, when I have time, I build a proper UI, design the icons, write documentation, and create images to describe what the extension does. Ironically that’s more work than writing the code itself, but creating an extension that solves any workflow discrepancy is incredibly fulfilling and important work.

Christina often creates plugins mid-project; an example of this is the Eneroth Cylindrical Coordinates plugin shown here.

Can you share your five favorite extensions (yours or otherwise)?

Eneroth Swift Layer Visibility Control makes layer visibility control more fluid. Often, I need to hide or show layers, but even in a neatly organized model I find it very disruptive to go into the Layers panel and search the list for a certain name. Instead, I created a shortcut for hiding the layers of whatever is selected. Another shortcut shows all layers (used in the active drawing context), and another re-hides all layers that were last shown, except for those of the new selection.

ThomThom’s Selection Toys is also a must-have. It allows you to select entities by a certain criteria, often based on what is already selected, which makes modeling much more efficient.

Eneroth Tool Memory is another personal favorite of mine that lets you cycle through the last used tools. It may seem useless to some as you already have shortcuts to the most used tools; however, I think my workflow is more fluid when I can swap back and forth between tools without having to move my fingers to their different shortcuts. It’s also very helpful when you use those rare tools that aren’t assigned to a custom shortcut.

Eneroth Solid Tools and ThomThom’s Solid Inspector are both extensions I use frequently.

Some honorable mentions beyond these five examples are CleanUp, SuperGlue, Eneroth Layer Painter, and Component Properties.

One of our personal favorites is Eneroth Visual Merge, an extension that makes your separate groups look like one single group.

If you had it your way, which extensions would be native to SketchUp?

Honestly, I think very few extensions should be native to SketchUp. One of the things I love the most about SketchUp is its modular architecture, and how that allows for a very simple core. This makes the program so much more accessible, as you can just test your way through it. With new software, it’s easy to get overwhelmed by the amount of bells and whistles, and you need a tutorial just to identify the basic drawing tools. Not with SketchUp!

That said, I think Weld should be a native command. It’s really just the inverse of explode curve, which is native. Adding STL export was a great choice. It doesn’t add any more cognitive load; it’s simply an extra item in the export format menu rather than in the interface itself.

Another view of Schloss Eneburg, a project that served as the catalyst for many future extensions and plugins.

In general, it seems like SketchUp is more to you than a drawing platform. How did SketchUp become such an integral part of your creative process?

As a teenager, SketchUp became one of my biggest hobbies, and other hobbies, like coding, are a direct result of that. Now, I make a living developing extensions and modeling in SketchUp, and I would go so far as to say that it’s not only an integral part of my design process, but an integral part of my life.

To answer the question, “Why SketchUp?” I think it boils down to two simple things: SketchUp is incredibly well-designed and it’s free for non-commercial use, both of which made it accessible to me.