Creating
the town's ground layer
In
Pizza Connection 2 the player has the choice to build his pizza
empire in 10 different metropolis. The towns are displayed using
an isometric view assembled from two layers:
Initially
we had planned to let an 2D artist draw the complete ground layer
to get as much detail and variation as possible. This approach
resulted in several problems:
- The
painted ground image did not match the rendered sprites stylistically.
-
Painting the image was complicated, because the artist had to
consider the underlying isometric grid used to place street,
pavement and premise elements.
- Due
to the enormous size of the ground layer painting the image
took up very much time.
While
the 2D artists had been working on the first paintings, Dirk Bialluch
did some research if the ground layer could be assembled procedurally
in the 3D package Maya and rendered as one complete image. After
about a week he had developed a solution, that provided the 2D
artists with an easy control over the map layout using their favourite
paint tool. In addition the method enabled us to make use of real
lighting, shadows and reflections. Due to the flexibility of the
solution changes could be realized quickly.
The
ground layer should be assembled from 3d modules that had to
be rendered later on as one complete background image. The first
step was to develop a system that allowed us to generate the
underground layer as easy as possible, without having a 3d artist
place every 3d module by hand. At 144*144 (20736) modules per
map and 10 towns this process would have taken too much time.
The
idea was to create sets of 3d modules for element groups like
street, pavement, grass and so on, that we could put together
by duplicating, rotating and positioning them within the 3d
software.
| |
Perspective
rendering of some modules |
Pixelmap
To
automate the placement of modules Dirk Bialluch wrote a MEL
script that was capable of assembling different elements based
on an indexed 256 color image called "pixelmap". Each
color index of this pixelmap represented a specific ground element
group. In the example shown below yellow stands for pavement
modules, white for street modules, blue for river modules and
so on. To create the pixelmap we scanned an original map of
each metropolis. An 2d artist then recreated the town's layout
to match the isometric representation with only four directions.
| 
|
The
original map of paris |
| |
The
pixelmap |
| |
A
Maya snapshot of the tool's user interface |
Converting
pixel to 3d modules
Based
on the pixelmap the script now created the complete ground layer
by duplicating, rotating and translating modules. The script
was capable of determining how to handle modules to match neighbour
elements to create i.e. street or pedestrian crossings. The
2d artist simply defined the specific ground type group in the
pixelmap. The script decided which module actually had to be
chosen to match its neighbours. For certain module combinations
we had no fitting elements. In this case a red marker was placed
into the scene named by the possible reason of the mismatch.
The script had about 5000 lines of code and there were quite
a lot of calculations going on. On a P3/500 the creation process
of one complete map with 144*144 modules took about half an
hour.
| |
In
this test scene only street, pavement and grass modules
were used. In the upper left corner you can see the original
pixelmap. |
The
script creates a ground layer in 11 primary passes:
-
street
- traffic
island
- house
site
- grass
- sand
- river
- sea
- ocean
- bridge
- path
- pavement
Using
three secondary passes all river, sea and ocean modules are collected
and randomly deformed using a vast lattice deformer. Thus we achieved
an irregular underground and shore appearance regardless of the
underlying modules. During the development of this geometry deformation
we encountered Maya's lattice deformer limit of 50.000 points.
Dirt
We
used several different methods to give the map a dirty and irregular
look. For each base module existed several slightly modified
variants that were chosen randomly at map creation time. In
a prepass the script checked the source scene how many variations
of each base module exist. Taking this information a weighted
usage was calculated so the base module had a chance of 50 percent
being used. Using this weighting we avoided to place modules
with distinctive features too often.
Border
modules like i.e. elements containing a kerb had a transparent
dirt surface that overlapped neighbour modules. In the script's
GUI we could modify the transparency value of the texture to
adjust the intensity of the dirt layer.
To
add more shading irregularity to the complete ground layer we
mapped the main light's intensity with a procedural fractal
texture. The fractal's intenstiy was again adjustable from the
GUI..
Paint
Effects
To
liven the scene up we added three separate Paint Effects layer:
As
Paint Effects are rendering including shadows these elements
add even more depth to the map. The seed value of duplicated
Paint Effects strokes were altered for each copy so each plant
has an individual and natural shape.
| |
Some
of the Paint Effects nature elements we used |
Rendering
the ground layer
The
ground layer was rendered finally at a resoluation of 4608*2304.
The scene required an average of 800MB RAM during rendering.
As the modules were modelled we had already made sure to keep
them geometrically as simple as possible. Wherever possible
we used single sided polyongs and disabled reflection, refraction
and shadow casting. One image took about two hours to render
on a dual P3/500.
| 
|
Details of final ground layer renderings. The red spots
mark positions where houses will be placed later on in the
game. |
| |
|
| |
|
| |
A
complete ingame snapshot (4094*2044) |
|
