#devlog #blender #3D-modeling #geometrynodes #geonodes
Starting out
Sometimes I like to dive down into a new and niche interest. It so happened that I stumbled on a YouTube channel called DamiLee, which offers videos on popular architecture.
Relating to that, I started to think about in-game architecture. How can I leverage Blender to produce buildings quickly and efficiently? I don't have a background in architecture, so I had to find some nice blueprints to work from. The first step was to go to archive.org and search for "floor plans". There is a great selection of different books and magazines there with floor plans to take inspiration. But where to start? To make a system quick and efficient for a potential 3D artist I decided to aim for a flexible and modular system and give Blender's Geometry Nodes System a try.
The goal for this experiment was to learn the foundations of Geonodes firstly, and work out a method for creating assets secondly. But Geonodes is not something that one just picks up. I spent a day or so following tutorials, some foundational, some geared at Blender users with an architecture focus.
Ok, Let's Go for Modular, and Now What?
As someone with a media and art background, my approach was to conceptualize modularity by recreating the floorplan in 2D first using Adobe Illustrator. By starting to work in 2D I shaved off one dimension of the problem, which made the thought process more straightforward.
The source for this floor plan is a floor plan called The New Haven. I had to work out a scale, and then create different shapes for inner and outer walls, doors and windows to puzzle together the floors of the building. To work out the scale later in Blender, I added a scale of one unit, in this case, one meter.
Then it was the question of creating and extracting pieces, to see what the goal was when blocking out the house. A few questions came to mind:
How many pieces are needed?
How many of those pieces are a variation on an already existing piece?
Do some pieces need to be customized? Doors, windows, stairs et cetera.
Let the Visual Scripting Experiment Begin!
Geonodes is a visual scripting system, which means that the methods have been encapsulated in visual representations called nodes. By connecting different slots between the nodes the code flow is created, and it allows for the creation of a small program, where nodes represent incoming data primitives and classes. Custom nodes can also be created for representing classes and an encapsulated functionality.
My main focus was to work on a piece of wall shaped like an L. This tile has an optional floor. The floor and wall thickness can be adjusted by five-centimetre increments. There is also a cut-out. The corner window in the first image of the 3D project showcases this tile. Below is a further completed model of the house floor plan, using generated pieces.
What Did I Learn?
This was not my first attempt at working with visual scripting. On different occasions, I have used Unity's shader graph, which works in an analogue way. In this graph though, I get the impression that the size of the project balloons fast to big proportions.
There are of course reasons for this, I have avoided creating many custom nodes to keep an overview of the project and this architecture functionality might not be really what the Geometry Nodes system was designed to do. The graph above represents the L-shaped wall piece.
Pros
The system is easy to use as soon as one gets what information is available, and how to access it.
A finished system would be fast and flexible to use. The complexity is the slowing factor, but only a few pieces are needed and they can be copy pasted.
The system can easily be adjusted and expanded for new architecture. Many aesthetic choices can be addressed with normal maps and textures.
Cons
It is hard to keep an overview of the project.
It is difficult to debug the project, due to the size and (possibly) nested levels of nodes.
There is no good note system to document the code, which impacts maintainability.
Building a diagram of the size above becomes hard to follow and read, which means it is hard to come back to the diagram later when it's not fresh in memory any longer.
There is no clear way to script custom nodes.
Where to Next?
I hope to continue this project and create more pieces for this tool. It is possible to take it further. Some problems need to be addressed. The system needs to be very precise, to make the building parts bake into one mesh. I also have to figure out how to best handle the UV-unwrapping for the buildings, so that it requires little or preferably no cleanup after combining all individual meshes.
The next step after solving these problems would be to explore how to create a more unified tool for building creation. Creating custom nodes in code might also be worthwhile looking into.