This week, I finally released the MVP of Ornament Creator!

It’s been about two months since I started experimenting with the idea of creating customizable 3D-printed ornaments in Houdini. What began as a simple procedural snowflake has grown into a web platform where people can personalize ornaments, preview their designs, and either download an STL file or order a printed ornament.

It’s been exciting to see the idea grow, collaborate with my friend and former co-worker Garman Herigstad, who’s contributing design work, and explore where this project might lead.

Bringing Houdini to the Web

My original idea was to give people some of the same customization capabilities that I have when working with a Houdini Digital Asset (HDA), without requiring them to know anything about Houdini.

I built a web interface using React and Three.js that exposes the ornament’s customization parameters. Users can enter a name, choose a font and snowflake design, and see the results in an interactive 3D preview.

When they’re ready to generate their ornament, those parameters are sent to a Houdini process running on an AWS server, which creates the watertight geometry needed for 3D printing.

Getting the preview and the generated geometry to match has been an interesting challenge, particularly with fonts and text placement. But it’s also been satisfying to see the entire process working together.

Does Running Houdini in the Cloud Get Expensive?

One question I’ve had throughout this project is: Does this get expensive?

And the answer is—it can be!

I originally set up a Windows server on AWS because I wanted to mimic my local development environment. It was the easiest way to get started, but I discovered that the Windows licensing costs made it significantly more expensive than running a comparable Linux instance.

So I rebuilt the backend on Ubuntu Linux. That took some work, but it reduced my hosting costs and gave me a better foundation for running the application.

I’ve also applied for AWS Activate, Amazon Web Services’ startup program, which offers eligible startups credits and other resources.

We were recently approved for $1,000 in AWS Activate Founders credits! This gives us more flexibility to experiment with different server configurations and continue developing Ornament Creator without worrying quite so much about hosting costs.t.

From STL to a Printed Ornament

Another exciting part of the project has been connecting Ornament Creator to a 3D printing service.

I’m working with X3D Studios in Austin, Texas, to handle printing and shipping. I’ve integrated their API into the platform so that when a customer purchases a printed ornament, the generated STL can be sent directly to X3D for production and fulfillment.

Customers who have their own 3D printers can simply purchase and download the STL instead.

This was an important step for me because I wanted to create something that could operate without requiring me to manufacture and ship every product myself.

What’s Next?

For now, I’m focusing on improving Ornament Creator, adding more designs, and finding our first customers.

But I’m also thinking beyond Christmas ornaments.

The underlying idea is much broader: using procedural modeling to let people customize 3D-printable products through a simple web interface.

That could include other personalized decorative items, but also practical objects such as brackets, hinges, or compartments that need slightly different dimensions or configurations.

After Christmas, I’d like to explore some of those possibilities. We may eventually expand the platform under a different name, but for now, I’m excited to see where Ornament Creator goes. It’s been a busy two months, and I’m excited to where this leads us!

This week the goal was to finish the MVP. One of the main things I worked on was the GUI. I wanted to make sure that the live preview in Three.js closely matched the STL that Houdini would ultimately generate.  I also spent time this week working on some of the less-visible parts of getting the application ready for testing. I added input validation, isolated generated files into separate jobs, added automatic cleanup of old files, and added rate limits so one user can’t continuously trigger Houdini processes on the server.

I’m still interested in exploring Aurora, SideFX’s solution for bringing HDAs to the web, but there is an advantage to the Three.js approach I’m using now: cost. By simulating the HDA’s behavior in Three.js, the application doesn’t need to call Houdini on the server every time someone changes a parameter. The live preview updates in the browser, and the server only needs to run Houdini when it’s time to generate the final STL.

The disadvantage is that I have to reproduce some of the HDA’s behavior in Three.js. That works for this project, but it could become more difficult as the procedural assets get more complicated. That’s one reason I’m still interested in exploring Aurora as I think about what a larger platform might eventually look like.

I also started testing this week. It was really useful to watch my family members use the application without knowing how I expected it to work. I made several changes to the interface after seeing where they hesitated or got confused, and testing also uncovered a couple of bugs.

A few people have now tested it successfully, and I’ve printed several of the generated files as well. At this point I’m making the final changes before opening it up for a small public test.

And while I kept wanting to improve each aspect of the project, I kept coming back to one goal: finishing the MVP.

This week I’ve been working on setting up a server to run the Houdini backend of my project. The goal was to be able to run my Houdini Digital Asset (HDA) remotely and generate a printable STL file from a web application.

I started out not really knowing which direction to go. I looked into render farm options. Maybe there was one that would work for very small, on-demand processes like this? But after looking into several cloud services that support Houdini, I didn’t find a good match that offered the API access I needed and made sense for such small jobs. There was also the issue of testing on a budget, since some of the options would have required me to move up to at least Houdini Core just to experiment with the approach.

I eventually decided on a relatively simple solution: use Houdini Engine Indie on an AWS EC2 instance to run the HDA and save the resulting STL geometry for 3D printing.

Previously, I had done all of my tests using a non-commercial build of Houdini, so I rebuilt my snowflake ornament HDA in Houdini Indie. That also gave me a chance to revisit the asset and improve some of the geometry.

One thing I liked about this approach was that it allowed me to take the solution I had already built locally and essentially move it onto the server. The HDA was still doing the same job. The bigger challenge was figuring out how to make that process available to the web application.

Yesterday, I pushed the React project to my web host and connected it to the backend running on the AWS EC2 server. I also set up a subdomain for testing: ornaments.smithharbor.com.

And I got an end-to-end test working! I can now use the web interface to send parameters to the server, run the HDA in Houdini Engine, and download the generated STL file. For now, I’m only running the backend while I’m actively testing. My next step is to add more security and safeguards before opening it up for other people to try.

Last week, I built a Houdini HDA that creates personalized 3D-printable snowflake ornaments. Once I had that working, I started wondering: what if someone could customize the ornament themselves in a web browser?

That became this week’s project.

For the first prototype, I kept things simple. I exposed just two choices from the HDA: the snowflake design and the personalized name. Eventually, this could expand to include things like font choice, text size, and other parameters.

The idea was to let someone type in a name, see a preview of their customized ornament while they were designing it, and then have the actual 3D-printable model generated and ready to download within seconds.

To build the interactive preview, I used Three.js to display the snowflake model in the browser and update the personalization as the user types. Behind the scenes, I connected the web app back to Houdini so the HDA could generate the final customized geometry.

And it worked!

In the video, I start with the web customizer, choose a snowflake design, enter a name, and generate the personalized STL. I then download the model and open it in PrusaSlicer to inspect the final geometry.

For now, this is still a local prototype—Houdini is running on my own machine to generate the final STL. That’s fine for proving that the workflow works, but obviously my computer can’t be the production server for an online product.

So that’s the problem I’m tackling next: how do I move the Houdini side of this pipeline off my local machine and turn it into an on-demand service that could support a real web product?

If you’ve worked with Houdini Engine, cloud-hosted Houdini workflows, or something similar, how would you approach it?

September is the perfect time for making gifts, especially if you’re making them yourself. My experiment this week was to create a Houdini Digital Asset (HDA) that generates a personalized snowflake ornament.

The experiment was a prototype to see how far I could take Houdini for creating personalized, fabrication-ready assets. I used an L-system to generate the snowflake shape and added a parameter that lets me type in any text for the personalized area. For my first test, I used my family’s name — The Smiths.

Once I had a working HDA, I exported an STL file and was so excited that I drove to the library to get it 3D printed.

I had jumped the gun a little.

The person who runs the 3D printer at our library immediately spotted a few issues with my first attempt. First, the bars holding the name weren’t flush with the rest of the design — something I had simply overlooked in my excitement.

He also recommended making the back of the ornament completely flat. I had beveled both the front and back, but because the print is built up layer by layer from the print bed, a flat back gives it a better surface to start from.

Finally, he suggested checking the design to make sure all of the narrow sections were at least 2 mm wide.

So I went back home and worked on those issues.

The next morning, I went back into Houdini and worked through the fixes. I used a Clip node to flatten the back, making sure to fill the cut surface so the model stayed watertight. I thickened the PolyWire geometry that formed the snowflake, increased the depth in Z, and adjusted the bars around the name so their backs were flush with the rest of the design.

Back to the library I went. This time, it was deemed good enough for a test.

I was asked to choose an infill percentage—10%, 20%, or 30%—which controls how much material fills the interior of the print. He recommended 20% as a good starting point, so that’s what I chose.

After about ten minutes, my ornament was printed! Another five minutes for it to cool, and I had an actual object made from my Houdini setup.

The total cost: $1.

It was gray, though. The library uses each spool until it runs out, so I didn’t get to choose the color. For this print, I added a coat of gold acrylic paint—and finally, it looked like the ornament I had imagined. Seeing the design move from an L-system in Houdini to a finished physical ornament was deeply satisfying. There are plenty of directions I could take the tool from here, but for this first version, three snowflake designs and one successfully printed ornament felt like the right place to call it finished.