Houdini for Videogames Course Update June 2023: Importing Houdini Building Generator in Unreal 5

Adolfo Reveron
Houdini - UE5 Building Generator

Empty space, drag to resize
We just updated our Building Generator Houdini course for beginners. Within the latest added content, you'll get an idea on how to get complex generations ready to be imported in Unreal 5. 
Have you ever bumped in to the need of importing your awesome Houdini generations into a game engine?

If the answer is 'yes', we are pretty sure you've probably faced a couple of issues. Within this article, we´ll cover our impressions: some issues we found were well known in advance, we foresaw them early on; whilst some others were unexpected. We´ll share next what we learnt through the process.
CHECK THE TARGET PLATFORM IN FIRST PLACE
It may sound obvious, but please make sure you do check what is the target platform your generation (output data/files) needs to be imported to. 

To provide you with some context, say you are creating a ZBrush sculpt, and let's assume you are not addressing a further retopology optimization pass. Well, if you have some experience with 3D asset production pipeline, you may already know that this will be a 'tricky' geo to deal with, as you'll face (probably) bad  to non-existing UVs and a heavy topology with several millions of polygons, among other specs. This example setup is already shrinking your rendering/visualizing/shading/importing capabilities by a lot. 

Similarly, if you kick off a Houdini tool without explicitly defining the output constraints, chances are you are about to start a painful journey: the more you progress through your Houdini generator, the more you'll make assumptions and you'll hook into some approaches. Eventually, you'll call it almost done, and the result might look great from an artistic point of view, but (here comes the killing blow), your data, outside of Houdini, is useless.

By useless, we mean it is either too heavy (millions of polygons), it is not understandable by the target platform (you may stored color values beyond 0-255 range) or the format is simply not universal (say you exported your output in a Houdini-specific file extension, like '.bgeo.sc') among other possible gotchas. Long story short, there may be tenths of issues.

When creating the new lessons within our 'Intro to Houdini course for beginners', we wanted to face exactly this:
We had a beautiful Houdini Building Generator running perfectly inside of Houdini, and among other assumptions, we even bumped to disk sections of the cooking process as intermediate data in the form of '.bgeo' files.
This is a very valid lesson, as this kind of scenarios happen all the time within real-world game production studios: you need to know how to adapt your data constantly.

For instance, you may already know that this Houdini-specific file type is able to store all kind of attributes and it is highly optimized, so it is usually a smaller file if compared to other formats (.obj, .fbx,...).
Then, If you try to export, say a 1Gb '.bgeo' geometry in the format of 'fbx', you'll find, among other issues, that you may end up with a file 5x~ times heavier file...and not only this: your Houdini session might get frozen when trying to write to disk such big file and/or, your game editor (Unreal 5 in our case) is not able to import it.
BECOME RESILIENT: IMPROVE YOUR TOOLKIT/KNOWLEDGE ARSENAL

Adapting our Generated building to Unreal 5 as Blueprint

Sometimes you'll get the option of rolling up your sleeves, and diving into the guts of the Houdini process and say 'I can improve this that way and improve the output, make it compatible with our needs'.

Sometimes you simply can't: imagine it is a huge node network made out of tenths of custom HDAs with complex processes going on, nested  in a never ending fashion, you can hardly follow how the data and dependencies flow, and there is nobody around you can ask: the guy/girl who did this tool left the company six months ago and nobody knows how the tool works.
In this scenario, you simply can't dive into the process and you need to deal with the output it generates.

So, you'll need to shine and save the day through building a process or tool around an existing process/HDA nobody else wants to touch. Honestly, this is not ideal by any means and it is similar to doubling the bet, but sometimes, there is simply no way around it.
We replicated this situation through creating a fresh new Houdini session and importing our huge '.bgeo' files, each one containing a different building.

If you learn how to look for the proper data existing within your imported geometry, you'll learn how a given attribute or collection of them might be extremely helpful, as they'll represent an anchor point you may hook in.
Then, say you are extremely lucky and there is a nice string-primitive attribute called 'type', or 'name', or whatever, which allows you to iterate over the components of your  building. This will let you filter by the 'columns', 'windows', etc from your building and creating custom processes for each of them.
For instance: 'in case this piece of geo is a column, move it to the origin, make it unit size, delete all the attributes but x,y,z and dump to disk two column variations'.


In conclusion, aim for the best and plan your design to the project needs beforehand, but in case you cannot do it, plan for the worst, face the challenge: benefit from your tricks, knowledge and ask around for help. Chances are some other experienced Houdini Technical Artist faced the issue before. There is usually a 'not ideal' solution/approach that might do the job.