FACULTY OF INFORMATICS

Blender plugin for procedural

generation of roads and road
systems

Master’s Thesis

ZDENĚK DOLEŽAL

Brno, Spring 2023

 FACULTY OF INFORMATICS

Blender plugin for procedural

generation of roads and road
systems

Master’s Thesis

ZDENĚK DOLEŽAL

Advisor: RNDr. Filip Opálený

Department of Visual Computing

Brno, Spring 2023

Declaration
Hereby I declare that this paper is my original authorial work, which
I have worked out on my own. All sources, references, and literature
used or excerpted during elaboration of this work are properly cited
and listed in complete reference to the due source.

Zdeněk Doležal

Advisor: RNDr. Filip Opálený

iii
Acknowledgements
I would like to thank my supervisor Filip Opálený, my consultant Jiří
Chmelík, and my colleagues from polygoniq for the time devoted to
consultations and multiple rounds of feedback.

iv
Abstract
With the growth of the 3D modeling, game, and film industries, the
demand, thus the opportunity to create tools that optimize workflow
increases. Since roads are an integral part of the human environment,
they are likely to be found in digital content. This thesis deals with the
generation of procedural roads in Blender. We discuss the necessary
background knowledge, survey existing solutions, and then explore
the implementation of a Blender plugin for the procedural generation
of roads with intersections, which is the key contribution of this thesis.

Keywords
Procedural Modelling, Road Generator, Procedural Road, Blender
Addon, Crossroads, Geometry Nodes

v
Contents
1 Introduction 1

2 Background 2
2.1 Procedural Generation . . . . . . . . . . . . . . . . . . . 2
2.2 Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Blender . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Blender Python API . . . . . . . . . . . . . . . . . . . . . 13
2.5 Roads In Real Life . . . . . . . . . . . . . . . . . . . . . . 14

3 State Of The Art 18

3.1 Methods in Published Literature . . . . . . . . . . . . . 18
3.2 Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Blender . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Proposed Method 25
4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Segment Geometry . . . . . . . . . . . . . . . . . . . . . 27
4.4 Crossroads Geometry . . . . . . . . . . . . . . . . . . . . 41
4.5 Addon Implementation . . . . . . . . . . . . . . . . . . . 48

5 Early Feedback and Further Work 56

5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 57

6 Conclusion 59

A Setup 60

B Electronic Content 62

C Third Party 63

Bibliography 64

vi
1 Introduction
Roads are an unmissable element of many environments, whether
complex street systems in cities, unpaved roads in the countryside,
multi-lane highways or cycle paths.
Interest in 3D graphics and modeling is growing [1]. Thus the
availability and variety of tools to facilitate the modeling process is
welcomed. Roads are an integral part of scenes in 3D environments.
Some form of a road is likely to be present in the scene, whether it is
architectural visualizations, movies, or games.
Manually modeling roads can be a repetitive and tedious process
in many cases. Using a procedural generator, the creation of roads can
be simplified into creating a trajectory of where the road should be and
choosing what the road should look like. Simplifying the repetitive
work allows the artist to focus on more creative and important aspects
of their work.
This thesis explores the methods and techniques of procedural
road generation, their use in the research domain, and their imple-
mentations in games and Blender.
Subsequently, selected techniques are implemented in a Blender
[2] plugin that allows the construction of a road system with simple
intersections using a custom modal interface. The system uses several
geometry generators implemented using the geometry nodes system
applied to each part of the road system and presents several options
for customization and creation of custom preset roads.
The implementation part of the thesis was done in collaboration
with the company polygoniq. The road generator will be subsequently
published in the traffiq1 addon.

1. traffiq addon https://blendermarket.com/products/car-library-traffiq-

vehicles-for-blender

1
2 Background
This chapter provides a short overview of procedural generation,
curves and their properties that are used in implementation, and
Blender procedural systems and its Python API.

2.1 Procedural Generation

Procedural generation, also noted as procedural modeling or procedu-
ral techniques, is a field of computer graphics that has been explored
for almost 40 years. First procedural techniques allowed to create
natural textures, such as wood, stone, and similar, to be used in ren-
dered scenes. This was further extended into the RenderMan engine
by Pixar in 1989 by implementing a shading language [3]. The field of
procedural generation continues to grow. Nowadays, some form of
procedural system can be found in most of the 3D engine, animation,
and rendering software.
The term procedural generation does not have a single definition,
as it encompasses multiple techniques that produce specific content
based on a set of input parameters [4]. However, an established generic
definition is provided by Ebert et al. – "Procedural techniques are code
segments or algorithms that specify some characteristic of a computer-
generated model or effect" [3]. Algorithms used for a procedural
generation often solve concrete classes of problems – combining them
is usually not possible, as the generators have specialized outputs [4].
However, generic procedural systems solutions like Houdini [5] exist,
which allow users to define procedural generators in the form of
connected nodes, making the process more accessible.
Procedural generators are controlled by a set of input parame-
ters. Input parameters define the result of the procedural generation.
Stochasticity is introduced into the system by using random num-
ber generators or noises to generate a wider variety of results using
one generator. Introducing randomness extends the set of generated
content, as some parts can be based on randomized properties. Ran-
domized properties are frequently based on the initialization values
of the random number generator – seed. When the generator can be
constrained by boundary areas or guiding curves, the term Guided

2
 2. Background

Procedural Modelling is used as defined in the work of Beneš et al. [6]

on a constrained procedural tree generator. Providing a user interface
that allows intuitive control of the generator is usually a complex prob-
lem, as the generator parameters may not be understandable without
additional knowledge. Fast performance is important, if the gener-
ated content can be created in real-time based on parameter changes,
immediate visual feedback is given on the designer’s action.
Favorable property of procedural modeling is the capability of
reducing the amount of time and effort to create digital content [4].
The work amount is reduced by allowing artists to iterate on content
using the generator’s parameters to generate variants quickly, rather
than manually hand-crafting each detail. However, a typical generator
currently does not achieve the quality and detail that is required for
a hero asset – an asset that is the main character, an essential part of
the environment, or generally a key point of attention. The decision to
use procedurally generated or hand-crafted content is in the artist’s
and designer’s hands.
Using procedurally generated content frequently yields smaller
file sizes. The content is described by the underlying mathematical
functions of the generator rather than information about the geometry
of the whole mesh. Content can be generated on demand at a trade-off
of computing power.
In addition to generating textures, vegetation, terrain, cities, or
game worlds are frequently tackled. Exemplar results of procedural
content generators are presented in Figure 2.1. Vegetation can be gener-
ated on multiple levels – a single procedurally generated tree, scattered
grass on a surface using multiple predefined models, or a generation
whole biome. There are specialized tools that use procedural genera-
tors like Speed Tree [7] to generate a variety of procedural trees that
can be used in games or environment design. Trees are frequently
generated using L-Systems [8] – a formal grammar for modeling veg-
etation growth. Grass or weed are frequently created by instancing
predefined models (or quads with textures) on randomized terrain
positions (so-called scattering) to create the illusion of a grass field.
A whole biome generator can be created with the addition of terrain
generation and integration of procedural trees.
Procedural generation of terrain uses a variety of methods. The
methods divide into physically based ones – simulating erosion or

3
 2. Background

particle hydrodynamics or algorithms using height maps [4]. One of

the most known methods is based on noise generators and summing of
the generated noises of different octaves and scales in order to produce
the final height map.
City generation, including buildings and roads, is handled by mul-
tiple solutions, further described in Chapter 3.
Procedural techniques are not tied to computer graphics topics
only. Procedurally generated music tools like Wolfram Tones [9] exist
or loot tables are being generated using procedural techniques as
implemented in Diablo 3 game [10]).

(a) Terrain1

(b) Tree2 (c) Dungeon3

Figure 2.1: Examples of procedurally generated content.

1. Image acquired from Speed Tree website https://store.speedtree.com/

store/speedtree-games-indie-9/
2. Image acquired from Terra Gen website https://planetside.co.uk/
whats-new-in-terragen-4/, artwork of Jeff Boser
3. Image of dungeon generated using d20 random dungeon generator, available
on https://donjon.bin.sh/d20/dungeon/

4
 2. Background

2.2 Curves
Curves are a fundamental part of computer graphics, required for
creating smooth surfaces, smooth models, and animation transitions.
In the context of procedural generation, curves can be used to create
the curved surfaces of generated models or also as an input for the
procedural generator. The user input curves can represent branches
of a tree, a river trajectory, a fence, or a desired road trajectory.
Curves can have different forms and representations – parametric,
explicit, implicit, and polynomial (Cubic, Bézier). Each form has its
advantages and disadvantages. In the case of parametric form, the
curve is a function p(t) that accepts independent scalar parameter
t. The function yields the position at the value t. The parameter t is
commonly defined on interval [0, 1] – the curve start is at t = 0 and
the end at t = 1.
Curves can be composed to a spline to allow finer control of multi-
ple curve segments without using higher-degree curves. The spline
is a piece-wise polynomial function joined at end control points. In
the parametrized spline, the parameter spans from [0, 1] on the whole
spline, passing through all the individual curves.
In the following sections, an insight into Bézier curves is described,
focusing on how they are used in Blender and its specifics, as those
are the curves used in the implementation. Further details, equations,
and definitions of curves can be found in the book 3D Math Primer for
Graphics and Game Development [11, Chapter 13], on which this section
is based.

2.2.1 Bézier Curve

The Bézier curve is a parametric polynomial curve. The proportions of
the curve are defined by a set of control points, the curve intersects the
endpoints, and control points define the control polygon. The main
properties of curves for our use case are tangent τ (t) and normal n(t),
as illustrated visually in Figure 2.2:

• Tangent τ (t) – Straight line passing through a point on a curve

defined by t and having a derivative equal to the slope of the
curve at that point.

5
 2. Background

• Normal n(t) – Straight line parallel to the tangent passing point

of a curve at position t. In 3D space, there are infinite lines
parallel to the tangent τ (t). In 3D software, there is usually
some form of control over how to align the normal. For example,
in Blender, there is a tilt angle a. Tilt angle defines the normal
– when a = 0, the normal is aligned horizontally, increasing
value rotates the normal clockwise.

Figure 2.2: Visualisation of curve parameters. Normal vectors are

displayed in purple color, and tangent vectors are in yellow. This
curve demonstrates Blender behavior – the normals are by default
aligned to the horizontal plane and additionally controlled by tilt.
Tilting starts when the normal vectors shift in direction from the right
side of the curve to the left side (in the direction given by tangents).

In Blender, the curve is rendered from line segments, so a resolution

parameter controlling the number of line segments of the spline is
present.

6
 2. Background

2.2.2 Extrusion

The curve extrusion in Maya4 also known as a sweep in Houdini5 ,

bevel or mesh to curve in Blender6 is a modeling technique that creates
3D shapes by extruding a 2D curve along a specified path. Inputs are
the 2D curve that represents the cross-section of the shape along the
path and the path itself, which defines where the 2D curve will be
extruded. Figure 2.3 presents an exemplar mesh generated by this
algorithm.

Figure 2.3: Result of extrusion algorithm on a path using an 8 vertices

circle as the profile curve. The original curve is colored pink. The black
wireframe represents the edges of the generated mesh, and the red
wireframe is the generated caps.

The 3D software usually implements several methods how to han-

dle the endings of the extruded mesh. The simplest approach is to
create a face at the endpoints of the extruded mesh. Other approaches
are in the form of spherical or conical endings [5], often based on the
extruded mesh.

4. Maya Curve Extrusion https://help.autodesk.com/view/MAYAUL/2023/ENU/

?guid=GUID-FCB83BE0-2C27-4880-A353-02873D337311
5. Houdini Sweep https://www.sidefx.com/docs/houdini/nodes/sop/sweep.
html
6. Blender Bevel https://docs.blender.org/manual/en/latest/modeling/
curves/properties/geometry.html#bevel

7
 2. Background

2.3 Blender

Blender is a free and open-source 3D creation suite developed by

Blender Foundation [2]. This software provides tools for creating 3D
models, sculpting, animation and rigging, visual effects, as well as
procedural generation of textures and geometry.
Using Blender’s node-based shading language users can create
procedurally generated textures to replace manual texture creation.
One can also alter geometry using procedural modifiers driven by
noise textures, or create a new geometry together, using geometry
nodes – another node-based language within Blender. The geometry
node system is under active development and with each version new
nodes and functionalities are added as the system is popular in the
user community.
The following section describes the fundamental background of
Blender-specific features that were used in the development of the
thesis, mainly focusing on procedural generation systems. More de-
tailed information about all features is available in the online user
manual [12].

2.3.1 Modifiers

Modifiers have the ability to edit the displayed and rendered geometry
of the object in a non-destructive manner, preserving the original ge-
ometry for editing. There is a variety of modifiers available in Blender,
while some are available only on certain geometry types (e. g. curves
have fewer modifiers than meshes).
Modifiers are defined on a modifier stack. The modifier stack con-
sists of one or more modifiers that apply changes subsequently to the
original mesh – their order matters. For example, one can use Array
modifier to repeat the original geometry and Shrinkwrap to place the
repeated geometry on another object.
Each modifier has settings that can be customized, as modifiers
are defined per object in Blender. The settings and specific modifier
stack applies to the whole geometry inside the object. Modifiers can be
applied to make the changes permanent – this removes the modifier
from the stack and changes the original geometry irreversibly.

8
 2. Background

2.3.2 Geometry Nodes

Geometry nodes is a node-based system for editing the geometry of
objects implemented as a modifier in Blender. A set of predefined
nodes is available and can be used to create more complex node op-
erations. A modifier containing geometry nodes has reference to a
geometry nodes node group which also defines the modifier input
and output. Node groups and their interface are defined in the node
tree editor, shown in Figure 2.4.

Figure 2.4: Example of node group with nested node group inside the
node tree editor interface.

Nodes can be grouped to define a node group – a node that has

inputs and outputs and can be used elsewhere in the node tree like
the predefined nodes. This emphasizes the importance of reusing
node groups on multiple objects and nesting node groups inside other
groups in order to hide complexity and reuse functionality while
providing a simple interface.

Geometry Types
Geometry is the main data type passed through geometry nodes, it
is the base for all calculations (green links and sockets in Figure 2.4).
The flow of geometry data throughout the geometry nodes node tree
defines the resulting generated content. There are five basic types that
the geometry data type can contain, each having its specific use case.
• Mesh – Arbitrary mesh geometry, consisting of vertices, edges,
faces and face corners.

9
 2. Background

• Curve – Bezier, polynomial, Catmull-Rom, or NURBS curves,

consiting of control points and splines.
• Instances – Repeated geometry (meshes, curves, volume, ...)
placed on different locations – faster, less memory intensive
than pure geometry.
• Volumes – Blender representation of volumetric meshes using
volume grids.
• Point Cloud – Representation of 3D scans.

Node I/O
Inputs and outputs of the main node group referenced in the modifier
are exposed to the modifier stack as demonstrated in Figure 2.5. Node
groups inside a node tree have their inputs and outputs in the form of
sockets7 .
The inputs and outputs of any Blender nodes are called sockets.
Each socket is of a different data type (e. g. float, integer, vector, string).
Inputs and outputs of user-defined node groups can be customized –
it is possible to define a type, limits of the input, default value, and a
tooltip. One socket can represent a single value or multiple values. In
the case of multiple values, the socket is called field.
Fields represent a set of values on a certain domain, the domain
is a place where the values are stored. For example, there can be a
field of type vector stored on domain face corner that represents the
UV position or a type float field stored on point representing custom
computed value. Field values are evaluated in the form of callbacks
for each data flow node, starting at the node that outputs geometry
– the same computation does not necessarily yield the same result
in different places. Detailed explanation of the evaluation system is
available on its documentation page8 .
Input or output in geometry nodes modifier can also be an at-
tribute that is created by the user (e. g. per-vertex color paint of a mesh,

7. The main node group can also be used in a node group – then its input and
outputs are also sockets.
8. Fields Evaluation https://docs.blender.org/manual/en/3.3/modeling/
geometry_nodes/fields.html#field-context

10
 2. Background

Figure 2.5: Modifier stack with a geometry nodes modifier and its
inputs on an object. The inputs are defined by the geometry nodes
node tree from Figure 2.4.

custom UV map output), this follows similar principles to fields. At-

tributes have to be pre-created in the object mesh settings, user-created
attributes are currently not available for curves.
Additionally named attributes can be created in the node system
itself. Named attributes are created on geometry and the value is
computed at the time of creation and is present on the geometry until
the attribute is altered or removed. This creates a convenient way of
pre-computing some values and reusing them at multiple places. The
named attribute can be read in the node-based shading language – e.
g. to read the generated UV coordinates.
If a certain attribute from another geometry is required on po-
sitions of different geometry, the Transfer Attribute node can be
used. Attributes can be interpolated based on the nearest position or
sampled by index. In case of requiring a value that is recomputed on
the geometry before it is used a Capture Attribute node can be used
to freeze the attributes at the position of the node.
The demonstration of the above principles is shown in Figure 2.6
and the result in Figure 2.7.

11
 2. Background

Figure 2.6: Node tree demonstrating instancing of an object (monkey)

from scene on vertices of input geometry, that have more than two
neighbors, randomizing rotation of each instance and setting the shad-
ing to smooth.

Figure 2.7: Result of applying the node group from 2.6 on a subdivided
quad.

12
 2. Background

2.4 Blender Python API

The functionality of Blender can be extended using the Python API
provided by the Python package bpy. It is possible to create simple
snippets that can be run inside Blender Scripts interface or addons that
users install and use in their workflow. API is divided into modules
according to their functionality, the most important modules in our
context:
• bpy.data – Access to data collections in the current blend file –
objects, meshes, curves, node trees, etc.
• bpy.context – Context of application, defines selected objects,
active scene, tool settings and others.
• bpy.ops – Predefined operators (tools) that can be executed for
example by clicking a button.
• bpy.types – Definition of types used across the API.
• mathutils – Mathematical utilities, definitions of math classes.
• gpu – Platform independent wrapper of internally used Blender
renderer.
Python API allows extending Blender in many different ways. It is
possible to create asset bundle add-ons, that add assets to the scene
with one click, improve native workflows, or create new complex mesh
editing tools. For example, functionality can be extended by creating
an operator by subclassing bpy.types.Operator and registering the
class into Blender using bpy.utils module. The user interface can be
extended by adding layouts to existing interface areas by subclassing
and registering bpy.types.Panel that defines user interface in semi-
immediate mode or by using the low-level gpu module to render
custom interfaces or overlays in a similar style to OpenGL. Rendering
using gpu module is used by registering draw handlers, which can
overlay the scene before or after rasterization.
A complete description of the Python API is available in its docu-
mentation9 .

9. Blender Python API https://docs.blender.org/api/3.3/index.html

13
 2. Background

2.4.1 Data Management

Blender has a unique file format for storing data – .blend files. Each
.blend file contains metadata and information about the scene in the
form of data blocks (e. g. object, mesh, image, node group). Data
blocks can be loaded from different files and reused.
Data blocks can be loaded into other files in two ways. Firstly data
blocks can be appended - an exact copy of the data block is created
in the new location. The second approach is to link the data. Linking
of the data references the original data block in its original .blend file.
Using linking gives the advantage of having control over the specific
data blocks in their respective files allowing better data management
and cooperation, but on the other hand in the file that is not the source
.blend, it is not possible to perform most edit operations. Unless the
filenames change, the content of the original referenced .blend file will
be reloaded on a restart.

2.5 Roads In Real Life

Roads form different shapes and have unique looks across the world
based on multiple factors like geography, state development, approach
to urbanization, and available materials. State authorities frequently
define how the roads, crossroads, and nearby surroundings should
be built and how they should look in their jurisdiction with the coop-
eration of civil engineers. This section brings some concepts of civil
engineering into the context of this thesis to provide a baseline for
road generation.

2.5.1 Classification
Road classification is a complex topic in itself, this section is based on
the publication Review of Worldwide Road Classification Systems [13]. The
topic gives insight into how it is possible to categorize roads around
the world based on different parameters. Roads in most of the world
can be classified into hierarchical systems. For the context of this thesis
simplified classification based on road function is enough. The United
States generally differentiate between highways, arterials, collectors,
and local streets. European Union classifies only motorways, express

14
 2. Background

roads, and others (some countries have more detailed classifications).

Based on that, differentiation into four categories - motorways, express
roads, town roads (streets), and others is enough for our use case.
Separated bicycle lanes, pathways, gravel roads, or private plot roads
can be considered category other. Exemplar real-world roads from the
individual categories are presented in Figure 2.8.

(a) Highway (b) Arterial (c) Street

Figure 2.8: Real world examples of roads. The first row shows roads
from the United States and the second from European Union. All
imagery is acquired from Google Street View – © Google 2023.

Highways are the major roads designed for high-speed traffic over
long distances. A typical highway has a separate roadway - multiple
lanes in each direction, physically separated by a median. The median
can be in the form of crash barriers or jersey barriers. Access to high-
ways is usually limited to usage of on, off-ramps, and interchanges,
which are designed with low curvature not to slow down the traffic
flow going to various destinations.
Express Roads / Arteries connect major destinations within a
city or a city to its regions. The number of intersections on arteries
is generally higher than on highways. Traffic signals or stop signs
are used to control the traffic at intersections. More than one lane in
each direction can be present on such roads, sometimes divided by a
median.

15
 2. Background

Town Roads / Streets are roads that provide access to the local
properties and neighborhoods. Typically smaller sized roads, one lane
in each direction, with side spots for parking. Those roads usually
have features for pedestrian commuting like sidewalks, crosswalks, etc.
This type of road is also more often combined or shared with public
transport, tram tracks, bus, or taxi lanes. There can be intersections
with dedicated turning lanes and multiple traffic lights or basic yield
and primary road signs. Streets contain additional facilities for traffic
and pedestrians, like public transport stops, benches, trash bins, and
ticket machines. Streets often include greenery like trees, bushes, or
grass strips to introduce natural materials into the scenery.

2.5.2 Signs
Traffic and people movement regulation is communicated using signs.
Signs can be divided into two categories based on their location relative
to the road - vertical and horizontal. A steel pole or construction
elevates vertical signs so the information is visible high in the viewer’s
field of view. Horizontal signs are located on the road surface, and
extend the meaning of vertical signs – stop lane; or have their own
meaning – road markings. Road markings are used to control car
positioning on the roads. They split one road surface into several
parallel lanes, create a bidirectional lane of one road surface, or mark
places for parking spots.

Kerb Kerb

Trees Incoming Lane Median Outgoing Lane Sidewalk

Figure 2.9: Example of a road cross-section consisting of a median,

two driving lanes, sidewalk, and greenery area.

16
 2. Background

2.5.3 Cross-Section
Road cross-section defines how the road profile looks if the road was
sliced horizontally in a direction parallel to traffic flow. The cross-
section shows how an individual element’s width contributes to the
width of the whole road. This is often defined by standards in civil
engineering10,11 . Illustrative cross-section is presented on Figure 2.9.

10. http://hgf10.vsb.cz/546/VHZ1/vyuka/doprava/rez.html
11. https://streetsillustrated.seattle.gov/design-standards/roadway-
construction/design-cross-section/

17
3 State Of The Art
Procedural road generation is a topic explored for several decades.
Various methods and implementations can be found in literature,
3D engines, internet asset stores, and games. In this chapter, we first
introduce the methods described in known literature, explore imple-
mentations in games and explore existing implementations of road
generation in Blender.
The current state of the road generation can be divided into cate-
gories based on the field. Road generation in research usually focuses
on problems of generating road networks in cities [14, 15], while fre-
quently optimizing the trajectories based on terrain [16], or in the con-
text of simulators [17], but the actual geometry generation is described
sparingly. Systems for building roads are frequently implemented in
city building and transport simulation games [18, 19], where we can
observe the behavior of the tools but not the methods behind the
implementations, as they are proprietary.
In addition to procedural generation, there are various other tech-
niques to create the geometry of the road. A common approach is
modeling the roads manually, which can be time demanding and
imprecise. It relies on estimating the real-world dimensions or trans-
ferring the data from map sources. However, nowadays, it is more
frequent that models are created using some form of sensory-based
scanning – photogrammetry or laser scanning [20, 21], which yields
precise results with high detail. High detail and realism are required
for driving (racing) simulators or for training neural network models
of self-driving cars.

3.1 Methods in Published Literature

A lot of published literature introduces road generation into a broader

context – generating cities or recreating whole urban areas including
buildings. The goals of the city generators differ – frequently the main
goal is to generate the whole road network procedurally with an
emphasis on the realism of the network, but not with a focus on the
geometry and looks of the generated model.

18
 3. State Of The Art

The system City Gen by George Kelly and Hugh McCabe [14] gen-
erates procedural roads based on the terrain and a set of predefined
primary roads. The primary road path is defined by a start and end
point and the trajectory is optimized based on the terrain. The empha-
sis here is given to generating procedural street blocks with generated
secondary roads using L-systems and lots for buildings. This system
uses a concept of a multi-level graph structure to represent the road
network.
Tensor fields are used in Interactive Procedural Street Modelling [15]
to generate the road network with the possibility of adding constraints
and editing the procedural results. Three-dimensional geometry is
created using templated segments, defined by a cross-section lane by
lane. Crossroads are limited to X and T shapes with roundabouts and
their features like traffic lights and signs can be parametrized.
Realistic Road Modelling for Driving Simulators using GIS Data [17]
proposes a method of generating realistic road systems for driving
simulators including the generation of crossroads and construction
of 3D models. This method uses various road categories with differ-
ent road profiles (defined additively in width). Emphasis is given to
constructing continuous lanes for traffic simulation and pedestrians,
from the data.
Another use case for procedural road generation is optimizing
the road path based on a variety of terrain parameters. Procedural
Generation of Roads [22] provides a method of road path optimization
between two points. The path is chosen based on a cost function while
optimizing criteria like amount of bridges (their height, pillar depth),
tunneling costs, and cost to remove vegetation. This is further extended
in Authoring Hierarchical Road Networks [16], where multiple classes
of roads can be created between multiple points. Geometry in both
cases is generated by instancing generic parametric models, which is
no further elaborated on.
Research shows that in addition to traditional curve manipulation
tools, unique interfaces were also explored. For example, Sketch-Based
Path Design [23] implements an interface that allows sketching curves
with a widget tool selector for features, which is demonstrated on
generating roads with simple crossroads.

19
 3. State Of The Art

3.1.1 Overview

Mentioned publications often describe the generation of the road

network itself based on various inputs, which is not directly related
to the thesis. The road geometry generation itself is tackled either by
instancing predefined parametrized models or cleaning up GIS data
and generating geometry based on that.
Methods described in publications [22, 15, 17] mention the usage
of a cross-section of the road (as defined in Section 2.5.3) when con-
structing the geometry. The cross-section seems to be predefined on
precreated models rather than in full user control.
All methods use some form of a graph representation of the road
network. For simulations, there are multi-level graphs, where base
layers represent the road, and higher levels represent paths where
pedestrians and cars travel. For pure mesh generation, simple one-level
graph structures are used.

3.2 Games

City building and transportation games require tools to create road

geometry based on player input. In the case of more complex games,
the tools are generalized to create train tracks, ship canals, and pedes-
trian paths. Generated geometry is procedural and has to adapt to the
surrounding terrain, other paths, and other parts of the game (build-
ings, vegetation). Road generation and its tools in Cities Skylines [18]
and Transport Fever 2 [19] are explored in the following section.
Interfaces of such building tools have to be intuitive and simple
to use, as most of the players do not have in-depth civil engineering
or computer graphics education. Building begins by clicking in the
game world – the road starts building in a direction towards the mouse
cursor and finishes with a second click or a prompt. Titles implement
creating curved road sections in various ways, some old titles did
not implement it at all, and building only straight roads was possible.
Nowadays curved road sections are frequently introduced as a specific
mode into the building tool. In the case of Cities Skylines this mode
works with an additional middle-click, that defines the angle of the
segment.

20
 3. State Of The Art

Sometimes sticking the road to the terrain is not desired if the user
wants to create a bridge or a tunnel. Height controls are implemented
in step increments. A tunnel or bridge can be built if there is enough
height difference and adequate steepness. Transport Fever also imple-
ments a selection of bridge styles, each with varying speed and looks.
The build tool in both games is entered by choosing from a selection
of various pre-defined roads, spanning from simple dirt roads, and
two-lane streets to highways, respecting the road hierarchy. Creating
a new road preset is often possible as a part of modding.
The limitation of systems in games is that there is usually no finer
customization available. The crossroads are generated with a fixed
amount of traffic lights or a pre-defined crossroad style, the road mark-
ings on the roads are not editable and customizable. The generated
geometry sometimes overlaps and is generated with errors.

3.3 Blender

Solutions improving road and city modeling workflows are available

in many various implementations. The main goal is to reduce the
amount of steps necessary to get a road mesh, that can be set into a
context of a scene and then further customized.
Implementations are usually distributed in the form of an addon
that is installed in Blender or in a .blend file containing assets. Newer
asset packages use the Blender native asset browser.
We have searched for relevant plugins on plugin distribution plat-
forms like BlenderMarket and Gumroad. Keywords like road generator,
city generator, geometry nodes roads, procedural roads were used to find
relevant results. Furthermore, using conventional search engines we
found numerous tutorials (published as video tutorials, blog posts, or
forum posts) that explore the topics of road generation. Newer tuto-
rials frequently demonstrate the usage of geometry nodes to create
road geometry. In comparison, older tutorials showcase what features
and tools could be used to create road geometry before the procedural
system existed. Found implementations can be classified into three
categories based on the method used.

21
 3. State Of The Art

3.3.1 Modular Assets

There are solutions that have pre-created road segments and cross-
roads with tweakable materials. Models are created in a combinable
way that allows artists to put the assets in scene one next to each other
in order to create a more complex road network. However, the nature
of premade assets inevitably comes with limited customization op-
tions. All road systems created using the same asset pack will have
similar artistic styling.
Urbaniac [24] addon provides a bundle of modular assets that
can be combined to create roads and sidewalks with intersections. It
comes with addon code that eases manipulation with the predefined
geometry using array modifiers. Object origins are carefully selected,
so the roads snap together with minimal user effort.

3.3.2 Procedural Content

Procedural generation methods mostly use geometry nodes to con-
struct road surfaces. Most of the methods are a modifier or a set of
modifiers that construct road geometry on a curve or a mesh. Changes
to the curve or mesh defining the road mostly happens by functionality
that Blender provides natively, including drawing of curves.
Curves To Road [25] provides a simple geometry nodes node group
that can generate roads with road markings, and guard rails.
Easy Road Generator [26] creates road geometry based on a mesh
editing. Each face is generated with a road surface inside and curbs
outside. This is a less common approach to procedural modeling of
roads in Blender, but still, it makes creating crossroads and geometry
easier. On the other hand, this implementation does not come up with
additional features like distributing assets near the road, which has to
be done manually.
Flex Road Generator [27] presents a complete package that allows
the creation of more complex road networks, including bridges and
intersections. It implements cross-section by having multiple modifiers
each responsible for a part of the road mesh, distribution of objects,
or scattering. Crossroad construction is possible when using mesh to
define road layout and only for a unique cross-section defined by the
modifier stack.

22
 3. State Of The Art

3.3.3 Combined
Some implementations combine the procedural approach with pre-
defined models. City Road Maker [28] creates geometry on a curve
and lets the user specify what pre-modeled intersection to spawn on
one of the curve endpoints. Additional neighboring roads have to be
connected manually.

3.3.4 Other
Scene City [29] uses a custom node-based system for generating com-
plex cities and road systems. Users can use addon-specific nodes to
define building placement and road distribution. Road intersections
are available only when using meshes.
Blender OSM [30] gathers data from the OpenStreetMaps and
loads it in Blender. Buildings, roads, and terrain is generated in the
scene. Roads are currently generated as curves from the Python API
with a mesh equivalent to the width of the road and are snapped to
the ground if there is terrain below. Intersections are currently not
handled, the road meshes overlap each other, but a solution using
geometry nodes is on the way.

3.3.5 Overview
The roads in described solutions are usually generated on a curve
or a mesh. Generating on a curve has the advantage of finer control
over the curvature, but generating on a mesh allows defining points
with more than two neighbors, which is useful for crossroads. Most
of the solutions generate roads on a curve with a fixed number of
predefined parameters in one modifier, except for the Flex Road Gener-
ator [27], which provides some control of the road cross-section and
uses multiple modifiers.
Crossroads are either not handled at all or handled in a simplified
manner – predefined crossroad assets can be spawned on the endpoint,
or crossroads can be generated only when all the neighboring roads
have the same cross-section.
Most of the tools provide controls for the width of various road
elements, sizes of objects, randomness controls (seed, min, max val-
ues), material and input curve settings. In the case when geometry

23
 3. State Of The Art

nodes functionality comes in a Python addon, there are functions to

load the asset into the scene and the parameters of the modifiers are
exposed in the user interface (frequently in the sidebar, also known
as N-panel) in a clear and sorted way.
All implementations require some basic Blender knowledge – edit-
ing meshes, creating curves, navigating in the user interface, and
installing addons. No-code implementations require additional knowl-
edge of asset browser system and data management, but on the other
hand are portable, as they work without addon presence.

24
4 Proposed Method
This chapter describes our approach to procedural road generation
in Blender. We implement a solution that extends on other Blender
road generation methods by having multiple road types with different
cross-sections while generating crossroads and road mergings.
The chapter starts with the proposed requirements and follows
up with a high-level concept of the solution. Geometry generators are
described and subsequently, the implementation of the add-on and
integration of the generators concludes the chapter.

4.1 Requirements
Informal requirements were specified based on the state-of-the-art re-
search, on requirements for the polygoniq code base and best practices
of bpy usage1 .
• Blender LTS version – Implementation has to work in Long Term
Support version of Blender. Blender LTS version is supported
with fixes for additional two years. We are targeting Blender
3.3 LTS.
• Various Road Cross-Sections – As there is a large variety of
roads in real life we want to support roads with various profiles
– streets with a sidewalk, highways, customizable curbs, etc.
• Crossroads – Generate crossroads between intersecting seg-
ments. The crossroads should have reasonable geometry and
the generator should cover the most common crossroad cases.
• Real World Units – The tool will be used mostly in environ-
ment creation, where real sizes are important. All inputs that
manipulate sizes of generated geometry must correspond to
the other units in the scene.
• Reusabillity – Geometry nodes and code are created so that
parts of the system are reusable in other projects.

1. https://docs.blender.org/api/3.3/info_best_practice.html

25
 4. Proposed Method

4.2 Concept
Our approach consists of a new interactive operator to build roads
which uses geometry generators to construct the road and crossroad
objects. The interactive operator provides a simple game-like interface
for constructing roads and transfers data between objects in the back-
ground to construct contextually fitting road system geometry from
multiple disconnected objects. The operator with additional support
features is presented in Section 4.5.
Road and crossroads geometry is constructed using Blender’s pro-
cedural geometry generation system – geometry nodes, as defined
in Section 2.3.2. Roads and crossroads are generated using multiple
modifiers that cooperate together and share data through the modifier
stack, similarly to Flex Road Generator [27]. Geometry generation is
split for road segments and crossroads, as illustrated in Figure 4.1.
A road segment is one section of a road with the same properties –
road profile, distributed objects, road markings, and material. Segment
generation is described in detail in Section 4.3. A crossroad generator
is used on points where any three roads meet or where two different
roads meet, its implementation is described in Section 4.4.

Segment 1

Segment 4

Segment 3
Segment 2
Crossroad 1
Crossroad 2
(different road merging)

Figure 4.1: Simple network of roads consisting of four segments and

two crossroads. The second crossroad is a merging between two dif-
ferent roads.

4.2.1 Conventions
Geometry nodes node groups are stored in library .blend files un-
der the blends directory in the root folder of the addon. Library

26
 4. Proposed Method

RG_Geonodes_Library contains node groups that define generated

geometry of one segment and RG_Crossroad-Geonodes_Library con-
tains content for generating crossroads while reusing node groups
from the segment library.
Names of all node groups use prefix RG_ to avoid data name clash
as the name is the unique identifier for data blocks in Blender. Prefixing
data blocks with a unique prefix reduces the chance of name-clashing
with user data. This prefix will be omitted in the descriptions of the
names in the text.
Names of named attributes are prefixed with @ to differentiate from
other attributes present on the geometry in the value spreadsheet.
Prefixing named attributes distinguishes our named attributes from
the default ones on the geometry, making them more visible.

4.3 Segment Geometry

Input for one segment is a curve object, that contains multiple splines
on which the geometry is generated. The geometry of the road is gen-
erated by combining multiple modifiers. Road-specific modifier stack
begins with InputCurve modifier and ends with Cleanup modifier. An
exemplary modifier stack is presented in Figure 4.2. The following sec-
tion describes the modifiers found in our implementation, interesting
implementation details and highlighted generator parameters.

Figure 4.2: Modifier stack demonstrating cooperation of multiple mod-

ifiers generating simple road with asphalt surface, curb, sidewalk,
lamps, and benches.

27
 4. Proposed Method

4.3.1 Input Curve

The InputCurve modifier prepares the user input by resampling the
original curve and storing named attributes for further computations.
@layer integral named attribute is initialized to 0 and stored on
each spline, this value is used in Profile modifier later.
Approximate curvature is stored in @curvature attribute. This
attribute is calculated by sampling previous and next spline point
normals ⃗ni−1 , ⃗ni+1 and applying a formula
ci = |⃗ni−1 × ⃗ni+1 |
acquired from a tutorial [31]. Attribute @slope is calculated using a
forward difference of heights (z coordinate of position) of current and
next spline points position pi and pi+1 :
(⃗p − ⃗pi+1 )z
si = p i
(⃗pi+1 − ⃗pi )2
Both @slope and @curvature are named attributes of type float
stored on each point. Those attributes are calculated on the input curve
once and then reused in other modifiers.

Parameters
Resample Length changes the number of points in the input curve
based on input length. A value of 0.5 means that the curve points will
repeat after 0.5 meters.
Fillet Radius can be used to round sharp corners of the input curve.
The input is connected directly to the Fillet Curve node and works
the same way as described in the node documentation2 .

4.3.2 Road Profile

Multiple Profile modifiers are used to construct the cross-section
(defined in Section 2.5.3) of the road as demonstrated in Figure 4.3.
Profile modifiers store information about the accumulated width
of parts of the cross-section for easier customization and cohesion of

2. https://docs.blender.org/manual/en/3.3/modeling/geometry_nodes/
curve/fillet_curve.html

28
 4. Proposed Method

(a) Median (b) Asymmetrical (c) Custom Profile

Figure 4.3: Various combinations of Profile modifiers in a road mod-

ifier stack. (a) defines road split with median with curbs, (b) demon-
strates the possibility of creating asymmetrical roads, and (c) show-
cases the usage of a custom shape for a cross-section part.

generated geometry. The newly added cross-section geometry always

starts at the end of the previous part of the cross-section. The geometry
itself is constructed using the Curve To Mesh node described in its
own section. Cross-section mesh generation and calculation of the
accumulated width of the geometry happens in the following steps:

1. Base curve C is separated from other geometry using Separate

Input Curve node group. The input of the modifier can already
contain geometry data from previous modifiers. In order to
keep the previous geometry it is important to also include it in
the output.

2. Previous widths pl and pr are acquired from non-modified

geometry.

3. Profile object is reset to the origin and its width w is acquired.

4. New curves Cl and Cr are created by offsetting base curve C

by pl + w and −( pr + w) in the direction of the curve normal
vector at each point.

29
 4. Proposed Method

5. Both curves are converted to meshes Ml and Mr using the im-

proved Curve To Mesh node that is described in eponymous
Section 4.3.2.
′ ′
6. New widths pl = pl + w and pr = pr + w are stored on the
modified data and the old geometry is joined with the new Ml
and Mr meshes.

There are additional calculations in the implementation node tree

to allow working with parts of cross-sections that do not necessarily
build up in the horizontal direction and to allow gaps between cross-
sections, however, the key concept is the same. It is also possible to
create the cross-section only in one direction – left or right.
To ensure that the multiple cooperating profile modifiers generate
continuous geometry, no additional curve resampling can happen after
offsetting along normal. The original curve is offset along normal as it
is, creating continuous mesh along the width without holes. Although
this can result in overlapping geometry if the curve is offset too far
along normal in tight corners – it starts to wrap around itself. However,
it is a worthy trade-off for geometry continuity. Wrapping can be
slightly mitigated by tweaking the fillet radius parameter mentioned
in the previous section. Figure 4.4 showcases the difference between
resampled and non-resampled curves.

(a) Without curve resampling (b) Resampling based on length

Figure 4.4: Comparison of generated geometry without and with

resampling of curves offset along normal. Mesh created on the offset
curve without resampling produces continuous geometry across the
whole road cross-section.

30
 4. Proposed Method

Curve To Mesh
Custom node group CurveToMesh is a wrapper of the eponymous
Blender node (our node group is prefixed with RG_). This is the most
repeatedly used node in our generator, as it creates a selected profile
geometry across the input curve, similar to the algorithm described in
Section 2.2.2. Our node group extends the original node function by
generating UV coordinates.
The UV coordinates are calculated separately for sides, caps, and
top-bottom faces. The UV calculation is chosen in the node graph
based on the direction of face normal Fn relative to the input curve
tangent and normal Ct , Cn . The mapping functions utilize coordinates
of the profile object P and the position on the length of the curve Cl .
Individual sides mapping with their enabling conditions (conditions
are evaluated in this order in the node tree):

1. Caps – In case of face normal pointing to the curve tangent

|Ct · Fn | > 0.5 mapping is created using the positions of the
profiled object; uv
⃗ = ( Px , Py )

2. Sides – If the previous condition does not hold and the normal
is aligned to the curve normal calculated by |Cn · Fn | > 0.5 then
the mapping is in the form of uv
⃗ = (Cl , − Py ). Where the gener-
ated side is unwrapped along the curve length Cl and height
component of profile position Py . Py represents height because
the profile curve is in the XY plane at this point. Negative Py is
used to flip the coordinate growth direction.

3. Top-Bottom – If the face does not align to curve normal Cn nor

tangent Ct , then top-bottom mapping is used. UV is calculated
using curve length Cl and Px component of profile position and
stored as uv
⃗ = ( Px , Cl ).

UVs are calculated per each face corner (domain attribute for
storing UVs) and are stored in a vector named attribute @uv that
can then be accessed in a material shader for mapping. Mappings
are flipped so the growth starts on the top-left corner of the mesh
and grows to the bottom-right corner for predictable results. The
mapping direction is mirrored along the input curve, so by default, the

31
 4. Proposed Method

⃗ = (0, 0) coordinate is nearer to the input curve, and the coordinates

uv
grow outwards. Visualization of generated UV mapping is presented
in Figure 4.5.

(b) Cross-section with custom pro-

(a) Simple cross-section file object

Figure 4.5: Visualisation of UV mapping of a cross-section constructed

from squares and of a cross-section with a custom profile.

Node group input is a Curve and a desired Profile Curve with

additional parameters controlling the UVs – Scale and Offset. Addi-
tionally Material for the generated mesh can be set and a threshold
angle for Auto Smooth shading. Those parameters are exposed to
the parent node group so they can be edited in the Profile modifier
directly.

Profile Modifier Parameters

Width defines the width of the profile. In the case of mesh generated
on both sides, the width is the total width of the two meshes.
Exclude From Width Stack disables or enables the additive width
offsetting. Useful for situations where the cross-section has multiple
levels vertically.
Is Road Surface marks the profile as a road surface and stores the
information internally. This is required for correct crossroad width
calculations and for crosswalks.

32
 4. Proposed Method

Height specifies the height of the cross-section. The profile can be

vertically offset using Vertical Offset parameter.
Horizontal Offset offsets the profile in a direction of a normal
curve. If the profile is excluded from the width stack this starts at the
curve position, the accumulated width is the start otherwise.
Mode switches between creating mesh on both sides, left or right.
Profile Object is an optional template object for creating the ge-
ometry on the curve. The object has to have applied scale and has to
be defined in the YZ plane, so the width and height parameters work
correctly. If left empty a rectangle is used by default.
Ending Length defines a distance from both ends of each curve
where the mesh starts to incline to the base curve height. This can
be used to create simple sloped endings. If the value is 0, the default
filled cap ending is used.

4.3.3 Distribute
Distribute modifier can be used to repeatedly instance additional
objects on a curve in a regular pattern. Useful to add additional detail
to the road by instancing objects that surround roads in real life, like
lamps, trash cans, benches, and others.
The instanced objects are input to the modifier as a collection, those
objects will be repeatedly created as instances based on user-specified
parameters. In the case of multiple objects in the collection, the objects
are instanced in alphabetical order repeatedly.

Choosing Instance Positions

The target positions are based on the Curve Normal Offset parameter,
which offsets the base curve specified distance along the normal. Dis-
tance between objects can be customized and is specified by parameter
Instance Spacing. If Fill parameter is set to a value different than
zero, then the modifier will try to fill the whole curve with the input
collection, the dimensions are calculated based on the bounding box
of the input collection, additional space between filled assets can be
applied using Fill Spacing parameter.
Blender provides Instance On Points node that is used to create
instances from arbitrary geometry on points. The usual approach to

33
 4. Proposed Method

instancing is to resample the original curve to the number of points re-

quired for the instances and create instances on those points. However,
this approach is sub-optimal for our use case as there were problems
found during the implementation with the position not being at the
expected place after offsetting the curve.
A different solution was created using an approach where the
curve is firstly offset and then all points that will not be used for the
instancing are removed, preserving the point’s positions from the
original curve resolution. This is achieved using the Delete Geometry
node and its Selection input. The points are deleted based on their
index Pi , on curve length Cl , and the number of points in curve C p .
Firstly the number of required points can be calculated N = Cl /s
where s is the user-selected spacing or calculated one if Fill parameter
is on. Whether the point should be deleted or not is decided based on
equality Di = 0 of the following equation

⌊C p ⌉
Di = Pi mod
N
Then the points do not change positions and are left in the same
places and used as base positions for instancing. However, if the num-
ber of points in the curve C p is less than the required points by the
instancing, then some positions will be omitted completely. This is
left up to the user to use a finer curve for finer detail and adjust the
parameters accordingly.

Curvature and Slope Based Instancing

The Distribute modifier supports instancing of objects based on the
slope and curvature of the input curve. Information about slope and
curvature is read from the pre-calculated named attributes stored on
the curve from the Input Curve modifier.
The design for both controls is the same, only the names of in-
puts change, thus it will be presented only on the curvature. Points
for instancing are additionally (to points selected based on spacing)
excluded if the boolean input Curvature Instancing is toggled on,
based on Curvature Threshold. The curvature from @curvature is
compared to the input threshold. In order to control instancing both in
and out of corners, we allow setting the threshold to negative values.

34
 4. Proposed Method

If the threshold is positive then smaller curvature than the threshold

is considered; if the threshold is negative, larger curvature values than
the threshold are considered. Curvature-based instancing is visualized
in Figure 4.6.

(a) t = −0.3 (b) t = 0.3

Figure 4.6: Negative and positive value of curvature instancing thresh-

old t demonstrated in a top-down view on instancing of a cube in and
out of corners.

Additional Control

There are additional input parameters that allow finer control of in-
stanced objects. The instances can be mirrored (offset in the direction
opposite to normal) using Mirror modifier parameter.
Default, randomized and seed values can be controlled for the
Rotation, Scale, and global Offset. The default value specifies a value
that applies to all instances – e. g. rotate all lamps by 90 degrees and
offset by 20cm. The randomized value defines an interval from which
a random value is chosen to be added to the default value uniquely
per each instance with seed control using the seed value. Rotations of
all instanced objects are by default aligned to the base curve normal
vector. Offset is in world coordinates, not relative to the alignment.

35
 4. Proposed Method

4.3.4 Road Markings

The RoadMark modifier can be used to add road markings that follow
the original curve with a specific offset along the normal direction.
Road markings are generated as a mesh on the offset curve. The gen-
erated mesh is ray-casted to the road geometry, so the user does not
have to adjust the position manually to the road surface. Figure 4.7
showcases possible results of the markings generator.

Figure 4.7: Three roads with various road markings. Configuration of

different spacing lengths, offsets, widths, and materials is presented.

Additional Control

It is possible to customize and create dashed markings by customizing

Marking Length and Space Length. If the length of space is zero, then
a solid continuous marking is created. Additionally, the Width of the
marking can be customized. To prevent z-fighting after the ray-cast
the Ground Offset parameter can be used to offset the mesh upwards.
The generated geometry can be mirrored along the original curve by
using the Mirror parameter.

36
 4. Proposed Method

4.3.5 Crosswalks

Multiple Crosswalk modifiers can be put onto a road segment. Each

modifier creates a new crosswalk on a specified position on the curve.
This position is specified as a length from the start of the curve in
Position From Start parameter.
Crosswalks are generated as geometry in the following steps:

1. Firstly the base curve C is separated from other geometry using

Separate Input Curve node group.

2. Line L with the length equal to the width of the road is created
on the position defined by Position From Start. The line is
aligned to the direction of normal and additionally rotated
based on Rotation input.

3. New lines L p representing the width of the crossroads are gen-

erated parallel to the previous line L and are positioned on
the previous line. The width can be controlled using Width
parameter.

4. Lines L p are selectively (Dashed Select node group) deleted

to create markings and spaces with the desired length based
on Marking Length and Spacing Length inputs.

In addition to the crosswalk shape-defining parameters, Material

and Ground Offset parameters can be set. As the crosswalk is con-
structed as a mesh the number of generated points can be tweaked by
Resample Length parameter. Results of the crosswalk generator with
various parameters are presented in Figure 4.8.
Crosswalk is automatically snapped to the geometry of the cross-
section created by previous Profile modifiers. Crosswalk geometry
that ends up on non-road marked parts is removed, as it is unwanted
to have crosswalks on sidewalks or greenery.

37
 4. Proposed Method

Figure 4.8: Three crosswalks generated with different parameters on

one road. The first crosswalk is with default settings, only resampling
was changed. The second crosswalk demonstrates width and rotation
change and the third crosswalk uses a different material.

4.3.6 Scatter
The scatter modifier instances one or more objects from a collection on
a surface of an object. This is a supplementary modifier as scattering
is a topic in itself and is not related only to the road generation. There
are add-ons that specialize in scattering for Blender like GeoScatter3 .
However, to provide a complete modifier package, a simple scattering
modifier was implemented. One of the main goals was to have control
of the proximity of scattered assets to the road surface to prevent
overlaps and unwanted geometry.
The implementation contains two variants of scatter node groups,
both using the same base but with different approaches. The first
approach is scattering from the perspective of the road object, im-
plemented in ScatterToTarget. The modifier is added onto the road
object and Target Collection for scattering is specified as input – all
objects in that collection will be considered as scattering targets. In
the second approach, the modifier (Scatter) is present on the object
where the objects are scattered, which is the usual implementation.

Road Proximity Control

Proximity in the first modifier variant is calculated based on the dis-
tance to the generated mesh – the position of the scatter modifier
matters in the modifier stack. In the second modifier variant, there

3. https://www.geoscatter.com/

38
 4. Proposed Method

is a Proximity Objects input collection parameter that defines the

geometry from which the proximity is calculated.

(a) dmin = 3.5; dmax = 11.5 (b) dmin = 9; dmax = 14

Figure 4.9: Difference of resulting scatter based on distance from road

parameters.

Proximity from objects and roads can be controlled using parame-

ters Min Distance From Roads dmin and Max Distance From Roads
dmax as seen in Figure 4.9.

Parameters
In addition to inputs described for proximity and objects, it is possible
to control multiple parameters. The most important parameter is the
Density that controls the number of scattered assets per square meter.
In case of unwanted overlaps of the scattered assets the Collision
Distance parameter can be set, defining the minimal distance between
scattered points.
To allow finer control based on the properties of the input mesh,
parameter Boundary Min Distance removes the instances that are
close to the outer edges of the mesh, Align To Face Normal aligns
the rotation to the normal and Max Slope limits the instancing to a
certain slope.
Similarly to Distribute modifier, the scatter allows control of the
base and randomized values of scale, rotation, and seed inputs. An
example of different parameters configuration is presented in Figure
4.10.

39
 4. Proposed Method

(a) Randomized Scale (b) Multiple Scattered Assets

Figure 4.10: Variety of possible controls of the scatter modifier. Both

images show randomized rotation.

4.3.7 Cleanup
The Cleanup node group should always finalize the road segment
modifier stack. This node uses Merge By Distance node to merge all
closely overlapping geometry based on the user-specified distance.
In addition to the geometry cleanup this node also has a boolean
input called Realize Instances. If the input is toggled in then all the
instances are converted to a mesh before they are output. This input is
important for further conversion to a mesh of the generated geometry
as the Blender operators for converting curve to mesh do not consider
instances from the geometry nodes system.

40
 4. Proposed Method

4.4 Crossroads Geometry

Crossroad geometry is generated on a separate object. The generator
utilizes multiple modifiers cooperating together, incrementally gath-
ering the data from other objects about adjacent roads into geometry
nodes to have enough information to construct the final crossroad
geometry.

4.4.1 Crossroad Decomposition

Each crossroad is decomposed into incoming roads and their adjacen-
cies. An incoming road is an endpoint of a curve (road segment) with
geometry nodes generated mesh. Adjacency marks the neighboring
side of roads. The minimum number of adjacencies for crossroad is
two – in the case when a road merging between two different road
types needs to be created. To ensure consistency with generation and
data-feeding to the crossroad modifiers, the adjacencies are numbered
in counter-clockwise order with an arbitrary start point. Figure 4.11
showcases an overview of the decomposition.

ROAD 2

p2
2 3 2

ROAD 2 p2 p1 ROAD 1 ROAD 3 p3 p1 ROAD 1

1

0 p0 1 0 p0 1
ROAD 1 p1 p0 ROAD 0
ROAD 0

ROAD 0

(a) Two Roads (b) T crossroad (c) X crossroad

Figure 4.11: Crossroad decomposition into adjacencies, adjacency

numbering. Each black curve with an index number is one adjacency.
The arrow notes the index increment direction. Points pi are endpoints
of a spline containing a road segment.

Each adjacency is represented by a base curve (arc) connecting the

two road surface endpoints. Additional features like sidewalks or road
markings are based on the base curve. The adjacency curve starts and

41
 4. Proposed Method

ends at the furthest point of the road surface from the middle of the
road (along the endpoint normal). The construction of one adjacency
in detail can be seen in Figure 4.12.

SIDEWALK
ROAD 2
p2 r2

w2 r1 SIDEWALK
w1 ROAD 1
p1

Figure 4.12: Adjacency detail. The adjacency base curve begins and
ends at the furthest road surface points r1 and r2 . The position of the
points can be calculated by offsetting along the normal vector of the
curve at p1 and p2 using road surface half-widths w1 and w2 .

4.4.2 Crossroad Modifier Stack

The crossroad modifier stack consists of a Register Adjacency node
group that adds one adjacency to the crossroad. Then several Profile
modifiers can be present to add adjacency geometry before the next
adjacency modifier. The final geometry of the crossroad surface is
constructed by adding the Build modifier. The modifier stack is in-
tended to be constructed by code, as the inputs and outputs can be
technical and do not have to make sense to a 3D artist at first glance.
However, it is possible to construct the modifier stack manually if
wanted. Crossroad generated using a crossroad modifier stack with
four adjacent roads can be seen in Figure 4.13.
Unfortunately, geometry nodes do not have array inputs, otherwise
a simpler modifier stack would be possible, as the information about
adjacent roads would be passed in batches.

42
 4. Proposed Method

Figure 4.13: Crossroad with four adjacent roads generated using cross-
road modifiers.

Crossroad geometry nodes node group names are prefixed with

RG_CX similarly to the segment geometry nodes. The node groups
try to reuse functionality from the main geometry nodes library, if
possible. The individual geometry nodes modifiers are described in
the next sections.

Register Adjacency
The RegisterAdjacency modifier registers the adjacency of two roads
by creating multiple curves with various parameters that are further
reused in follow-up modifiers.
Each adjacency modifier creates three curves. Those are marked
with an integer named attribute @type stored per each spline, so it is
possible to distinguish those curves in subsequent modifiers in the
stack. Each curve type has its specific use case:

• @type = −1 – This is the base curve – the arc connecting the

adjacent road surface endpoints. Used for constructing subse-

43
 4. Proposed Method

quent parts of the cross-section on the adjacency. This curve is

not adjusted to the road surface height.

• @type = 0 – This is the same curve as −1, but its height po-
sition is adjusted based on the input parameters. The curve
of type zero is used as the base for the crossroad mesh in the
Build modifier and can be used for road markings of the whole
crossroad.

• @type = 1 – Curve line parallel to the curve normal spanning

across the width of the incoming road. This curve type is used
to complete the curve loop around the whole crossroad and is
used for the triangulation of the road surface of the crossroad
in the Build modifier afterwards.

Each RegisterAdjacency modifier has multiple inputs in order to

gather information about the neighboring road from the scene. Most
of the information is used mainly to correctly calculate the points and
handles of the base curve. Passing data this way is necessary because
the crossroad is a different object in Blender than the road, so we do
not have information about its geometry in the modifier. Mainly the
curve normal and tangent at the road endpoints are required in order
to maintain reasonable continuity of the road and crossroad geometry.
The following inputs are passed twice, firstly for the adjacent road at
the start and then for the next road counter-clockwise afterward:

• Road Object – The curve object containing the adjacent road

segment.

• Road Width – Width of the road surface at the endpoint.

• Road Height – Height of the road surface at the endpoint.

• End Point – Position of the incoming road curve end point

that neighbors the crossroad in world space coordinates. This
position influences the resulting mesh of the crossroad the
most, as the incoming road curve parameters are based on this
position.

44
 4. Proposed Method

The normal and tangent are received based on the specified posi-
tion of the end point from the road object. In geometry nodes, it is pos-
sible to sample information from other geometry using the Transfer
Attribute node. However, it is not possible to sample curves by po-
sition, which we require. In order to sample the curve by position a
custom solution was created. The curve is converted to mesh and the
index i of the nearest point is sampled, then using this index i we can
use the Transfer Attribute to transfer the normal and tangent from
the original curve geometry based on position. In order to always
return the normal and tangent in a consistent direction for both the
start and endpoint of the curve, they are scaled by −1 in the case of
an endpoint. This implementation is present in a custom node group
called CurveSampleNearest.
Using the sampled normal and tangent we can calculate the points
and handles and create a Bézier arc connecting the two roads. Points
r1 and r2 as defined in Crossroad Decomposition 4.4.1 are used as
the start and end point of the arc. One point is used for both start
and end arc handles as a baseline. We try to calculate the point by
finding the estimated intersection4 of the tangents as seen in Figure
4.14a. However, such a point might not exist in all cases. When the
roads have parallel tangents (in the case of T crossroad) there is no
intersection. In such case, the mean position of r1 and r2 is used as
illustrated in Figure 4.14b.

Profile
The crossroad Profile modifier works in a similar way to the profile
modifier for the road segment. The main difference is that the cross-
road profile modifier always creates geometry on the curve from the
last registered adjacency.
This modifier reuses the CurveToMesh node (described in Section
4.3.2), thus the generated mesh already has working UV mapping,
and custom profile objects are supported.
Multiple profile modifiers can be present after the register adja-
cency modifier. Similarly to one segment profile modifier subsequent

4. The intersection is estimated by creating two lines in the direction of a tangent,

merging them by distance and finding a vertex with more than two neighbors.

45
 4. Proposed Method

RO SI
DE
AD W
AL
2 K

SI
r2

DE
W
r2 t2

AL

SI
K

DE
ph

SI

W
DE
r1

AL
W
t1

K
AL
K
ph r1 t1

RO
AD

RO
RO

AD
AD

1
1
t2

(a) Using intersection of offset (b) Using mean position of r1

tangents t1 and t2 . and r2 .

Figure 4.14: Calculation of adjacency arc handles position ph .

modifiers are offset by the width of previous ones. Generated geome-

try is controlled separately for each adjacency.
Additionally, the generated geometry tries to snap to the geometry
of the road based on the distance between vertices to provide better
results. A low threshold was selected, so the geometry does not snap
to itself or snap in cases where an overlap is acceptable.

Build

The Build modifier uses curves from previous modifiers to build the
road surface of the crossroad.
The geometry of the road surface is constructed using a node
called Fill Curve. This node triangulates the area constrained by
given curves. The node requires the curve to be in one piece – the
individual curves from previous modifiers need to be joined together.
Each adjacency modifier created two curves that contribute to the
final boundary of the crossroad mesh. The first is the arc between two
adjacent roads and the second is a curve line following the normal
of the first road. However, it is not possible to join all curves into one
curve directly. We use a solution where the curves are first converted
to a mesh, then the vertices (points) are merged by distance with

46
 4. Proposed Method

a small threshold – the overlapping vertices connect, and then the

connected mesh is converted back to a curve and filled afterwards.
This modifier also filters all the created curves and outputs only
the @type = 0 – the base arc between roads. This is useful for having
road markings modifier subsequently in the modifier stack.

4.4.3 Limitations
The main limitation of the crossroad generator is that in the real world,
there are sometimes crossroad adjacencies with very sharp corners.
For such cases, parameters to tweak the sharpness Road 1 Sharpness,
Road 2 Sharpness of the adjacency were introduced. Those parameters
affect what position is used for the handles of the base curve arc. Based
on the parameter the position interpolates between the intersecting
point and the furthest road surface point along normal.
The generated crossroad has to be on the same height level. It is
possible to generate a crossroad that is inclined, but the generated
geometry will have visible steps and it will not be smooth.
The crossroad surface mesh generated from the Build modifier
does not consider the profiles of the incoming road surfaces and gen-
erates flat. In most use cases this is negligible, in real life, a typical
crossroad surface is flat, if not considering special use cases, which
would have to be modeled manually anyway.

47
 4. Proposed Method

4.5 Addon Implementation

The implemented Blender addon provides functionality to load prede-
fined road types and contains the main build road systems operator
and utility features.
The implementation is split into several modules and classes based
on the functionality. For example CrossroadBuilder can be used to
construct crossroads solely, but RoadBuilder is a more high-level class
that uses CrossroadBuilder to create road systems while updating the
internal representation of road network implemented in RoadNetwork.
Predefined road types can be loaded and applied onto an object in the
scene by accessing a singleton instance of RoadTypeBlendLoader.
Addon features are accessible in the sidebar under a polygoniq
tab and Road Generator panel.

4.5.1 Road Types

One road type is the modifier stack and its values. All the roads that
can be added to the scene are predefined in separate .blend files. The
.blend file has to comply with the following conventions:

1. The .blend name starts with RG_ and is unique.

2. There is one curve object with the same name as the .blend file

3. The modifier stack present on the curve object defines the road
type.

4. Modifiers on the modifier stack are linked from the geometry

nodes library. This enables propagating changes from the li-
brary to all road types – when the node groups update, they
are updated in the road type blends as well.

The road types for the addon are supposed to be pre-created by a

3D artist and stored in the addon source under blends/road_types
folder. Any added road type is then automatically loaded into the
addon when using the interface to build or spawn roads.

48
 4. Proposed Method

Loading Road Type

As each road type has a unique modifier stack it has to be present on a
unique curve object – each road type has only one object in the scene,
but multiple splines, each representing a road segment.
Loading road types happens using bpy.data.libraries.load API
in class RoadTypeBlendLoader. A whole directory can be loaded on
demand and there are utility functions as return the list of road types
as Blender enum items to be displayed in the user interface.
During the loading process, the values from the modifier stack are
parsed and processed to gather additional information about the road
type.

Parsing Road Type

Parsing modifier input values and tracking their state in code is useful
for crossroad and road merging construction. Several features of the
road type are parsed, from which the following are important:

• Road surface width – total width of the cross-section that is

marked by Is Road Surface in the modifier.

• Road markings position – whether there are any road markings

that should be applied also on the crossroad.

• Road surface materials – to decide what material can be used

for a crossroad.

The parsed values are stored in the RoadType class, which pro-
vides API for accessing features of the road type and is then used to
determine properties of crossroads.

4.5.2 Road System Builder

The core of the road system builder is a modal operator Build Roads.
The operator itself mainly contains input handling and draw handlers
from where the overlay is redrawn. All the input information is then
passed to other classes, which then actually modify the scene.

49
 4. Proposed Method

User Input

A click of a button invokes the operator. After the button click the user
interface switches to road-building mode, overlays are shown and the
3D view is set to top-down. The user can click to start a road segment
with the selected road type and with a second click a road segment
is built. If the user selects a point that requires creating a crossroad,
then a crossroad is created with the second click. The operator can be
closed with an escape key. All possible keyboard inputs are shown in
the overlay to guide the user.
Only inputs relevant to the movement of the 3D view and the op-
erator itself are handled. This allows passing of other non-relevant
inputs back to the Blender event system, which keeps other user inter-
face features interactive and we can use a Blender interface to control
additional properties in the addon panel.
The Build Roads operator implements two types of snapping for
more precise controls. First is snapping to a grid, which is similar to
Blender’s behavior – by holding CTRL key the current point snaps to a
grid. The snapping grid size can be modified. The second type is the
snapping of current build points to other build points if the mouse
cursor is in range of the underlying road width.

Overlays

In order to make the BuildRoads modal operator intuitive, two types

of custom overlays were introduced in addition to the interface in the
sidebar (N-panel). The overlays are rendered using the gpu module
through our render module.
The types of overlay are based on when they are drawn. First is
the user interface overlay drawn in window coordinates and second
is the roads overlay drawn in the world space. Both overlays can be
seen in Figure 4.15. Both overlays scale according to global Blender
user interface settings.

50
 4. Proposed Method

Figure 4.15: Screenshot of an enlarged user interface with overlays

when the build roads operator is active. On the lower left side, a user
interface overlay displaying information about the tool state can be
seen. World space overlay is drawn over the build points. Additional
controls are in the side panel.

4.5.3 Road Network Representation

Implementation of a custom data structure that holds information

about the road system was required, because we are using multiple
objects together, and without a road network structure, their relation-
ship would not be marked in any way.
Our road network is a high-level graph structure G = (V, E) over
Blender scene data, where each vertex V is a crossroad and edge E is
a spline. Adjacent edges are stored in each vertex V with information
about what endpoint is connected. The implementation of the graph
structure uses the following components:

• RoadSegment – One road segment corresponding to a spline in

Blender. Has information about the curve containing the spline,
the spline itself, and the segment road type.

51
 4. Proposed Method

• Crossroad – Connection of multiple segments using adjacen-

cies. Has a unique identifier, a reference to its collection, an
object, and a set of adjacencies.

• SegmentAdjacency – Represents one connection of road seg-

ment to a crossroad. Has information about the adjacent seg-
ment and whether its first or last point is connected to the
crossroad.

Additionally, an adjacency mapping of segment and endpoint to

crossroad is constructed internally upon modification of the road
network for faster queries about segment endpoint connections.
As the structure contains references to Blender data, it has to be
correctly updated with each operation to the data in the scene. Oth-
erwise, the structure becomes corrupted with invalid references to
non-existent (already removed) data.

4.5.4 Crossroad Builder

Crossroad builder encapsulates creating a crossroad modifier stack

based on adjacent roads. The main API is build_crossroad method.
This method takes a list of SegmentAdjacency representing the adja-
cent road segments and endpoints. Crossroad modifiers are created
based on the input adjacencies. Each newly generated crossroad has a
unique identifier used for its name in the scene with a prefix.
Crossroad modifiers are built incrementally for each adjacency
ai . Firstly RegisterAdjacency modifier is added for ai and ai+1 , and
modifier inputs are filled from the road type of the adjacency. After-
ward, multiple Profile modifiers are added after the register modifier
for adjacency ai based on the adjacent road types. The outer profiles
are constructed only if both endpoint roads of the adjacency have the
same modifiers. the space is left empty otherwise. After all adjacencies
are added, the Build modifier is added to create the crossroad surface
geometry. The modifier stack is finished with RoadMark with settings
based on the widest adjacent road if it has any road markings.

52
 4. Proposed Method

4.5.5 Road Builder

The road builder is a high-level class that manipulates the scene to
create a road system using other modules. The road builder stores a ref-
erence to the road network and updates based on requested changes.

Build Points
Segment building can start and end on different points. Those points
are called Build Points and are based on the information from the
road network and current mouse position. There are three types of
build points:
• EmptyBuildPoint – There is only an empty space under the
mouse cursor.
• RoadSegmentBuildPoint – Build point is located on an existing
road segment and contains information about the index of the
point on the segment and the road segment itself. Each point
of the Bézier spline (except endings connected to crossroads)
is considered a road segment build point.
• CrossroadBuildPoint – If crossroad is under the mouse cursor,
the reference to crossroad is stored in the build point. Each
crossroad corresponds to a crossroad build point.

Building a Road Segment

Building of one segment composes of calls of multiple methods, each
of which takes a build point as an input:
1. start_segment – Begins a new segment on a specified start
build point. This adds a new spline to the currently selected
road type curve object. If the curve object is not yet in the scene,
it is added with its modifier stack.
2. update_provisional_endpoint – Until the final segment po-
sition is confirmed, the provisional endpoint can be updated.
This is mainly to be transparent to the user about what geome-
try is being built – the final position is updated on mouse move
and the position is used when finish_segment is called.

53
 4. Proposed Method

3. finish_segment – Finishes current segment on a specified end

build point by updating the road network and performing ad-
ditional object changes if necessary.
When a segment is started or finished, multiple cases of behavior
can happen based on the build point:
• When the build point is empty, the segment is built at the posi-
tion.
• Build point is the endpoint of a segment and of the same road
type – a new point is added or two splines are joined in the case
of both build points being on a road segment.
• Build point is the endpoint of a segment and a different road
type – a crossroad representing road merging is built.
• Build point is a non-endpoint of a segment – the original spline
is split, and a new crossroad is built.
• Build point is a crossroad – the original crossroad is removed,
and a new one is rebuilt with added adjacency based on the
currently built segment.
When crossroad is created out of existing road segments, RoadBuider
offsets the original points in the direction from the crossroad point to
the neighboring point of a distance specified by Crossroad Points Off-
set property, which value can be edited in the sidebar user interface.
The information about the road network stored in the road builder
is refreshed only when requested. Road builder tracks (using the road
network) the changes happening during the lifetime of the class in-
stance, which correspond to when the build roads operator is running.
However, to make the changes persistent and not lose the information
when the operator or Blender closes, we initialize the road builder
based on the scene’s contents in init_from_scene when it is invoked.

4.5.6 Utilities
Spawn Road
In addition to the road system builder, there is also a possibility to
load a curve containing a road segment directly using the Spawn Road

54
 4. Proposed Method

operator. This use case is viable for scenes without crossroads or com-
plex road features. For some users, it might be simpler to get the curve
object with road geometry nodes and tweak the curve manually to
their liking using native Blender workflow.
Similarly to Spawn Road a Draw Road operator is present that loads
the road into the scene, but it also starts the draw curve operator.

Convert To Mesh
When the generated road geometry is finalized, or some specific
tweaks are required, it is expected to have access to the generated
geometry. However, this is not possible directly, as the objects in the
scenes defining the road systems use modifiers, and the generated
geometry is not editable.
The Convert To Mesh operator takes selected objects generated
by the road generator and converts them to editable mesh. The oper-
ator firstly goes through all Cleanup modifiers and sets the Realize
Instances input to true. This allows a subsequent call of the Blender na-
tive Convert Curve To Mesh operator that applies all geometry nodes
modifiers, resulting in an editable mesh.

Add Road Generator Modifier

An operator which adds user selected road generator modifier to the
active road segment. This adds a geometry nodes modifier and sets
its node group to one linked from the road generator library. This
operator saves the user (or artist defining new road types) several
clicks – linking node group from the library, adding a modifier, and
selecting modifier node group.

55
5 Early Feedback and Further Work
Based on internal testing and discussion with 3D artists, the road
generator seems a good baseline for 3D visualizations, and the ba-
sic features seem to be implemented accordingly to requirements
specified in Section 4.1. Throughout internal testing sessions and de-
velopment, a lot of feedback and suggestions were provided. Some
suggestions, like mirroring for various modifiers or having global
resampling options were implemented. However, there were requests
for additional features that would increase the scope dramatically.
Limitations, requested features, and possible solutions are discussed
in the subsequent sections.

5.1 Limitations

5.1.1 Curved Segments

Currently, the implementation of the build roads operator does not

contain functionality to build curved segments directly through the
modal operator. The curve generated by the operator has to be edited
manually to have other than simple shapes. This was not implemented
in the scope of the thesis, as Blender does not provide API to evaluate
Bézier splines at arbitrary parameters, so we would not be able to
draw an overlay without creating a wrapper for Blender splines.

5.1.2 Updating Crossroad Position

The crossroads generated by the build roads operator are generated

based on input parameters when the crossroad is built. If any of the
parameters change after the crossroad is built, the crossroad mesh will
not change, including the positions of adjacent road spline endpoints.
When the endpoint of a spline is moved, the crossroad mesh does not
update until the position is changed in the register adjacency modifier
directly.

56
 5. Early Feedback and Further Work

This limitation can be avoided by using the Blender animation

system and its drivers1 to reference the positions of the endpoints in
the crossroad modifiers.

5.1.3 Expressivity of UI
Using a custom modal operator hides the native Blender functionality
behind it. On the one hand, this benefits novice users unfamiliar with
all Blender functionality – the addon works for them out of the box.
However, for users with detailed knowledge about Blender, the op-
erator may hide some customizability, as if they customized curves
by hand. Our solution provides simple options to spawn one road
segment, which the user can edit in any way likable and does not
necessarily have to use the modal operator.

5.2 Future Work

The following section discusses features requested or mentioned in
feedback and their possible implementation into the existing system.

Traffiq Addon Intergration

Shortly after submitting this thesis, the road generator is going to
be integrated inside the traffiq addon from polygoniq, so it can be
shipped to users. The addon was developed separately as it would
interfere with other minor releases of the addons, and there was an
ongoing internal system overhaul. Shipping the road generator to
users will provide additional feedback, and the implementation of
further fixes and features will be mostly decided by users’ needs.

Terrain Adaptation
If the user scene already contains terrain, it might be difficult to create
the road system to fit the terrain as the roads do not adapt to the terrain
automatically.

1. Drivers Documentation https://docs.blender.org/manual/en/3.3/

animation/drivers/introduction.html

57
 5. Early Feedback and Further Work

This would require changes to the geometry nodes and how the
input is handled. This feature is already prototyped. However, the
solution is not polished enough and does not work as expected in
some cases.
With a proper height adaptation solution, there is also a require-
ment for generating bridges and tunnels, as sometimes the road would
become too steep or too far from the ground.

Traffic Animation Curves

Currently, it is possible to create animating cars only by creating cus-
tom curves that follow the road trajectory and go across crossroads
manually.
This can be implemented based on the internal road network rep-
resentation as another layer of the road generator. After a user creates
their own road system, we can use the road network information to
generate a set of traffic curves that could be used for traffic animation.

Road Editor UI
The complex modifier stack for road segments and crossroads is hard
to edit manually as there is a lot of information and it requires knowl-
edge of how the system works.
This will be solved in the future by introducing a segment and cross-
road editor panels. Inside editor panels modifiers will be grouped
according to their functionality – e. g. cross-section modifiers, dis-
tribution modifiers, road markings modifiers, and their respective
parameters in a custom specialized interface.

58
6 Conclusion
To tackle the thesis topic, the Blender procedural geometry generation
system – geometry nodes – was studied on several small experimental
projects. A survey of other solutions on various popular Blender addon
distribution platforms was conducted, as well as a research of solutions
and methods used in the published literature and gaming worlds.
The results of the work are two libraries containing geometry nodes
for generating road segments and intersections and a Python plug-in
that extends Blender with a custom interface for creating road systems.
With this combination, we have a unique ability to create intersections
where several roads that differ in parameters other than width meet.
However, if the users do not feel like using all the plugin’s custom user
interfaces, they can use only the procedural generators with native
Blender curve editing tools.
The goal was to create a design that is extensible for the future, as
there are plans to work on the solution in the future. Since we have all
the information regarding the road segments available in the code, it is
possible to bypass the limitations of the procedural generation system
and use custom algorithms that solve the problems more creatively.
Implementing our solution in the Blender environment proved
that Blender is not a game engine and there are limitations. Some
features are not implementable because of the lack of access to under-
lying Blender data, and some require workarounds. However, as a
3D creation suite, Blender seems exceptionally extensible, allowing
developers to push for innovative game-like solutions.
The addon has been tested internally, and feedback from several
people has been considered in its development. Further work will be
done on the addon to improve the existing features, and then it will
be released as part of the traffiq addon by polygoniq. With a few
more iterations, the addon will be fine-tuned, and a broader library of
roads will be gradually created. All images of the generated roads in
this work come from the implemented generator.

59
A Setup
1. Launch Blender 3.3 LTS.
2. Open preferences by opening up the Edit menu.

3. Click Install in the top right corner and select the road_generator.zip
file provided in the electronic attachment.

60
 A. Setup

4. Enable the addon by clicking on the checkbox next to the addon

name.

5. Addon is located in the sidebar under polygoniq tab in Road Gen-

erator panel. The sidebar can be toggled by the N key.

61
B Electronic Content
The electronic thesis archive contains the following:

• blender-road-generator.pdf – The thesis text.

• road_generator.zip – Installation file and a source code archive.

Decompress to access source code, for installation, use the orig-
inal compressed .zip file. Readme and documentation files in a
.md format are present inside the archive.

62
C Third Party

Models, Textures and Materials

RG_Assets_Library.blend contains models and materials that were
used to create exemplary roads and are from various polygoniq ad-
dons. This library references textures in the textures folder, which are
also third-party.
Materials, models, and textures used in this thesis are the property
of polygoniq and are shared under royalty-free rights. Further detail
is available in documentation1 .

Code
Logging from polygoniq shared library polib is used. The library and
the addon are shared under GNU GPL 3.0 license2 , complying with
the licensing rules of extending Blender.

1. Assets Licensing https://docs.polygoniq.com/traffiq/1.7.0/endnotes/

license/#other-assets-royalty-free
2. GPL License https://www.gnu.org/licenses/gpl-3.0.html

63
Bibliography
1. 3D Mapping And 3D Modelling Market – Growth Trends COVID-
19 impact, and forecasts (2023 - 2028) [online]. 2023. [visited on
2023-04-28]. Available from: https://www.mordorintelligence.
com/industry-reports/3d-mapping-and-3d-modelling.
2. COMMUNITY, Blender Online. Blender – a 3D modelling and
rendering package. Stichting Blender Foundation, Amsterdam:
Blender Foundation, 2023. Available also from: http : / / www .
blender.org.
3. EBERT, David S.; MUSGRAVE, F. Kenton; PEACHEY, Darwyn;
PERLIN, Ken; WORLEY, Steven. Texturing and Modeling: A Proce-
dural Approach. 3rd. San Francisco, CA, USA: Morgan Kaufmann
Publishers Inc., 2002. isbn 1558608486.
4. SMELIK, Ruben Michaël; TUTENEL, Tim; BIDARRA, Rafael;
BENES, Bedrich. A Survey on Procedural Modeling for Virtual
Worlds. In: 2014.
5. Houdini [online]. Side Effects Software. [visited on 2023-04-28].
Available from: https://www.sidefx.com/.
6. BENES, Bedrich; STAVA, Ondrej; MECH, Radomir; MILLER,
Gavin. Guided Procedural Modeling. Computer Graphics Forum.
2011, vol. 30, pp. 325–334. Available from doi: 10.1111/j.1467-
8659.2011.01886.x.
7. Speed Tree [online]. Interactive Data Visualization, Inc. [visited on
2023-04-28]. Available from: https://store.speedtree.com/.
8. LINDENMAYER, Aristid. Mathematical models for cellular in-
teractions in development I. Filaments with one-sided inputs.
Journal of Theoretical Biology. 1968, vol. 18, no. 3, pp. 280–299. issn
0022-5193. Available from doi: https://doi.org/10.1016/0022-
5193(68)90079-9.
9. Wolfram Tones [online]. Wolfram, 2005. [visited on 2023-04-28].
Available from: https://tones.wolfram.com/.

64
 BIBLIOGRAPHY

10. Defining Loot Tables in ARPG Game Design [online]. Game De-
veloper, 2014. [visited on 2023-04-28]. Available from: https :
//www.gamedeveloper.com/design/defining- loot- tables-
in-arpg-game-design.
11. DUNN, Fletcher; PARBERRY, Ian. 3D Math Primer for Graphics
and Game Development [online]. 2011. [visited on 2023-03-15].
Available from: https://gamemath.com/book.
12. Blender 3.3 Reference Manual [online]. Blender Foundation, 2023.
Available also from: https://docs.blender.org/manual/en/3.
3/index.html.
13. PARAPHANTAKUL, Chutipong. Review of Worldwide Road
Classification Systems. In: 2014. Available from doi: 10.13140/
RG.2.1.4579.7843.
14. KELLY, George; MCCABE, Hugh. Citygen: An Interactive System
for Procedural City Generation. In: 2007.
15. ESCH, Greg; WONKA, Peter; MÜLLER, Pascal; ZHANG, Eugene.
Interactive procedural street modeling. In: 2007, 35–es. Available
from doi: 10.1145/1278780.1278822.
16. PEYTAVIE, Adrien; GALIN, Eric; GUÈRIN, Eric; BENES, Bedrich.
Authoring Hierarchical Road Networks. Computer Graphics Forum.
2011, vol. 30. Available from doi: 10.1111/j.1467-8659.2011.
02055.x.
17. DESPINE, Guillaume; BAILLARD, Caroline. Realistic Road Mod-
elling for Driving Simulators using GIS Data. In: 2011, pp. 431–
448. isbn 978-3-642-19213-5. Available from doi: 10.1007/978-3-
642-19214-2_29.
18. Cities Skylines [Game [PC]]. Sweden: Paradox Interactive, 2015.
Available also from: https://www.paradoxinteractive.com/
games/cities-skylines/about.
19. Transport Fever 2 [Game [PC]]. Switzerland: Urban Games, 2021.
Available also from: https://www.transportfever2.com/.

65
 BIBLIOGRAPHY

20. ERNST, Ines; ZHANG, Hongmou; ZUEV, Sergey; KNOCHE, Mar-

tin; DHIMAN, Amita; CHIEN, Johnny; KLETTE, Reinhard. Large-
Scale 3D Roadside Modelling with Road Geometry Analysis: Dig-
ital Roads New Zealand. In: 2018. Available from doi: 10.1109/I-
SPAN.2018.00013.
21. IRACING.COM. iRacing.com Laser Scanning [online]. Youtube,
2010. [visited on 2023-01-15]. Available from: https : / / www .
youtube.com/watch?v=IcqLEIE8MBk.
22. GALIN, Eric; PEYTAVIE, Adrien; MARÉCHAL, Nicolas;
GUÉRIN, Eric. Procedural Generation of Roads. Computer
Graphics Forum. 2010, vol. 29, pp. 429–438. Available from doi:
10.1111/j.1467-8659.2009.01612.x.
23. MCCRAE, James; SINGH, Karan. Sketch-based path design. In:
2009, pp. 95–102. Available from doi: 10.1145/1555880.1555906.
24. Urbaniac! City Asset Pack [online]. Blender Market [visited on
2022-12-11]. Available from: https : / / blendermarket . com /
products/city-asset-pack.
25. Curves To Roads V2 (Geometrynodes) [online]. Gumroad [visited
on 2022-12-15]. Available from: https://bbbn19.gumroad.com/
l/vhjmqh.
26. Easy Road Generator [online]. Blender Market [visited on 2023-01-
20]. Available from: https://blendermarket.com/products/
easy-road-generator.
27. Flex Road Generator 3D model [online]. CG Trader [visited on
2023-01-11]. Available from: https://www.cgtrader.com/3d-
models/scripts- plugins/modelling/blender- mesh- curve-
to-road.
28. City Road Maker [online]. Blender Market [visited on 2023-01-20].
Available from: https://blendermarket.com/products/city-
road-maker---geonode.
29. Scene City [online]. CG Chan [visited on 2023-01-20]. Available
from: http://www.cgchan.com/store/scenecity.
30. PROCHITECTURE. Blender OSM [https : / / github . com /
vvoovv/blender-osm]. GitHub, 2013.

66
 BIBLIOGRAPHY

31. BUFFER, Color. Procedural Curvature of a Curve in Geometry Nodes -

Blender [online]. Youtube, 2022. [visited on 2023-02-23]. Available
from: https://www.youtube.com/watch?v=JuSLy2Cy8dM.

67