Lori Green Smith Portfolio

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.