Răzvan T. Cristea showed how he uses Houdini to create completely customizable buildings, assets, and props.
Răzvan Teodor Cristea showed how he uses Houdini to create completely customizable buildings, assets, and props. The project he’s been working on is called Venetian Building Generator.
Intro
My name is Cristea Răzvan Teodor and I am a soon-to-graduate student at Teesside University, currently finishing my bachelor in “Computer Animation and Visual Effects”. I am originally from Bucharest, Romania and have traveled to England to pursue a career in the Visual Effects industry.
I was always passionate about computer graphics, being a kid that would spend hours and hours playing video games in my childhood, but during my high-school years, I’ve developed an interest into advertising and commercials, more specifically by looking at my favorite musicians and their music videos and being like: “Wait, how did they do that?”.
From then on, I’ve worked on small personal projects and some design and motion graphics work before starting my undergraduate course, and that’s when I’ve discovered Houdini.
Meeting with Houdini
I started learning Houdini during my 2nd year at Teesside. To be honest, I wasn’t really that intimidated by Houdini, given its node-based structure and proceduralism. I’ve used Maya and Cinema 4D before, but Houdini seemed oddly comfortable because, at the end of the day, it’s still a different way of moving data around. Maybe I’ve had an advantage by learning how to code during high school because I’ve found myself applying the same thinking patterns in Houdini as well.
In terms of exploring, the best way of learning Houdini still is the internet. There are a whole number of great (and bad) Houdini tutorials online, but I would say that the best way to start would be in those places:
- The SideFX Website
- The ODForce Forum
- Matt Estela’s Cgwiki website
- The “Applied Houdini” courses by Steven Knipping
- Entagma
The last one is for more advanced lessons.
Venetian Building Generator
Idea of the Project
At the beginning of the project, I was looking to replicate a shot from 2006’s “Casino Royale”. I could say I was overly ambitious for the timeframe of 4 months, but the initial idea was to create a procedural building generator that I would later use to recreate that scene and then start doing the rigid body simulations, along with smoke and flip simulations.
Somewhere around being half into the project, I’ve realized that I could either try to do the simulations and maybe finish the shot, which would have resulted in a semi-mediocre project, or I would try to do this building generator as best as possible, and looking back at it now, I think I’ve made the right call. I wanted to create a tool that I could later use for other types of projects as well, without having to deal with many problems during a transition process (for example, changing the architectural style or modeling new asset packs).
Assets
All of the geometry was procedurally modeled in Houdini. After seeing the true potential of the project, I wanted to develop everything as a standalone feature that would be used in the final thing. So, I have the brick walls generator, the Venetian windows generator, the rooftops generator, etc. This is what makes the project endlessly expandable. I like to think about it as Lego pieces, and every time I want, I can construct new pieces to add more variety to the buildings.
For example, the Windows are broken into different types of assets such as: the wooden frame, the sills, the balconies, the arches, etc. The beauty of it is that I can model any type of arch, and then just plug it into the network and it would all update itself, given the procedural nature of Houdini. This is something that I would never get from any other 3D software as fast as it is with this workflow, and the fact that I can import it into Unreal and still maintain the UI created in Houdini is perfect!
Working on Pattern
During development, I had to find some initial rules for all of the measurements and window patterns, kind of like an architect would plan to create a building. This meant taking a lot of reference images and videos and finding a rough estimate of the real-life measurements of every asset and how it would all fit together.
For example, I’ve noticed an interesting pattern for almost all Venetian houses and palazzo’s regarding their windows, from which I’ve constructed a couple of rules for my pattern generator:
- There are 3 choices when you have to populate a wall: no window at all, a regular window, a special window.
- At the middle point of every wall, it starts out every time with a special type of window.
- At both ends of the wall, there must be a type of window.
- The special window exists only on the floors between the ground floor and the floor below the roof.
- With the exception of the ground floor and the floor below the roof, all floors have the height of 4M.
Of course, there would be certain cases where the rules do not apply (generally to the walls that have less than 5 primitive faces).
In terms of scripting, even though I am a big fan of VEX, I’ve taken a more node-based approach, rather than creating geometry with VEX. When doing procedural modeling, I like having a way of visualizing all the operations applied through sops, but this is just a matter of preference.
The best advice I can give for anyone trying to do a procedural modeling project that would require measurements is to keep everything organized and keep it simple because it can be so easy to get lost into not knowing what you have done 2 days before.
Optimization
The optimization work went by two principles: “Is this node useful or redundant?” and “Can the network be compiled?”. This was kind of like looking at a code written in any scripting language and thinking if there is another way that would be better and more efficient. There were many mistakes along the way, but it was just a matter of patience and problem-solving. As I’ve mentioned before, planning played a big part in the project, while testing different types of setups.
For example, after the brick walls are generated, I would have to take the bounding boxes of the windows and use them for the boolean operation that would make room for them inside the wall. One trick that I’ve found to make this process significantly faster is to only use the brick pieces that are in proximity with the bounding boxes. That way, I could use the bounding boxes in a Group Sop to isolate the bricks affected by the Boolean and separate them from the ones that are outside. This way, the Boolean Sop doesn’t have to process all of the brick pieces outside and the cooking time will be lower. The same technique was used for the rooftops as well.
Areas of Improvement
There are a couple of features that I chose not to include for the moment, given that they are still work in progress, like having garden rooftops, adding a preview method to see the windows pattern before they are generated (so that you wouldn’t have to wait for the whole building to cook to see what result it gives you), adding flowers and awnings to the balconies or even changing the architectural style to something completely different. But for the moment, all of the energy is focused on the simulation aspect and trying to improve the network so that it won’t be very heavy in the simulation stage.
I’m definitely looking forward to expanding it even further and maybe creating tutorials for it as well, given the overwhelmingly positive response I’ve had on the Houdini Artists Facebook group.
Afterword
I would like to give a big thank you to 80 Level and Kirill Tokarev for giving me the opportunity to be part of this interview. If you are interested to see more of my work, you can find me on
Thank you for your time!