17.2PreachingbyExample:TheArticulatedPlaceholderModel 299
// Input attributes
attribute vec4 vertex;
attribute vec3 normal;
attribute vec4 weight;
attribute vec4 boneId;
// Skeleton bones transformation matrix
uniform mat4 bonesMatrices[40];
void main(void)
{
vec4 Position = vertex;
vec4 DefV = vec4(0,0,0,0);
vec4 DefN = vec4(0,0,0,0);
Position.w = 1.0;
for (int i = 0; i < 4; ++i)
{
mat4 BoneMat = bonesMatrices[int(boneId[i])];
DefV += BoneMat * Position * weight[i];
DefN += BoneMat * vec4(normal,0) * weight[i];
gl_Position = gl_ModelViewProjectionMatrix * DefV;
}
}
Listing 17.2. GLSL implementation of the linear blend skinning vertex shader.
IDs in the previous vector. With this information, the linear-blend skinning given
by Equation (17.8) can be directly implemented, giving us the skinning shader
shown in Listing 17.2 (with an added calculation for the normal vector).
Skinning now integrated, the mesh can be loaded in your game, the anima-
tions can be run, and you should now be able to see what looks like an articulated
balloon running in your scene. The completed technique can be seen in Fig-
ure 17.7. From this point on, it should be pretty obvious that the placeholder is
not a final asset, other programmers are able to test their game logic by using
300
Figure 1
7
is articul
a
existing
accurate
ent skin
n
new pla
c
modeler
s
required
Limita
t
The met
h
holder t
y
scored.
provide
s
and det
a
mostly
a
subtle t
e
b
e impr
o
distance
Ano
skeleton
in the g
e
b
one is
c
tions. T
h
7
.7. Articulate
d
a
ted and follo
w
animations,
performanc
e
n
ing method
s
c
eholder in
y
s
, animators,
to obtain co
n
t
ions
h
od presente
d
y
pe of asset.
The weakes
t
s
good result
s
a
iled work a
g
a
pparent in r
e
e
aring can be
o
ved to redu
c
methods on
t
ther artifact
t
join
t
s on th
e
e
ometry arou
n
c
onsidered i
n
h
is artifact ca
n
d
placeholder
s
w
s the animati
o
and they wi
l
e
tests by twe
a
s
on the plac
e
y
our product
i
and progra
m
n
venient and
u
d
above sho
u
However, it
t
part of th
e
s
for a place
h
g
ood animat
o
e
gions with
m
seen in the
m
c
e this artifa
c
t
he mesh.
t
hat should
b
e
generated
m
n
d the skelet
o
n
dividually, a
n
n
b
e attenuat
e
17.Plac
e
s
kinned to an
a
o
n.
l
l most likel
y
a
king the am
o
e
holder. Mo
s
i
on environ
m
m
mers since
o
u
seful place
h
u
ld give resul
t
has some s
h
e
process, t
h
h
older asset
b
o
r or modele
r
m
ultiple bon
e
m
esh. The a
u
c
t by using h
e
b
e mentione
d
m
esh. As can
o
n’s articulat
i
n
d their dens
i
e
d by reduci
n
e
holdersbey
o
a
nimation
p
os
e
y
be able to
a
o
unt of geo
m
s
t importantl
y
m
ent should
d
o
nly a very
b
h
olde
r
geome
t
t
s of sufficie
n
h
ortcomings
t
h
e automatic
b
ut in no wa
y
r
would do.
T
e
influences (
u
tomatic wei
g
e
at diffusion
d
is the “
b
all
o
be noticed,
r
ion. This is
b
ity fields ad
d
n
g the intensi
t
o
ndStaticAr
t
e
. The placeho
l
a
ccomplish r
m
etry and usi
n
y
, the additio
n
d
ecouple the
b
asic skeleto
n
t
ry.
n
t quality for
t
ha
t
should b
weight ass
i
y
replaces th
e
T
he problem
b
(
three or fou
r
g
ht assignm
e
methods or
g
o
oning” effe
c
r
ound artifac
t
b
ecause each
d
up near the
t
y of the den
s
t
Replaceme
n
l
der mesh
elatively
n
g differ-
n
of this
work of
n
is now
a place-
e under-
i
gnment,
e
precise
b
ecomes
r
), where
e
nt could
g
eodesic
c
t of the
t
s appear
skeleton
articula-
s
ity field
n
t
17.3IntegrationinaProductionEnvironment 301
near the extremities of a bone. Keep in mind, though, that some people tend to
prefer this look since it clearly defines the presence of an articulation.
Finally, the generated mesh might appear a bit flat, with undefined features,
if every bone has the same effect on the density field. A possible improvement to
this is to add a simple “influence” property to every bone and manually increase
the influence of some of them (such as the head of a humanoid character to make
it appear rounder). This is, however, a purely aesthetic improvement and other-
wise affects the system in no way.
17.3IntegrationinaProductionEnvironment
Placeholder systems are usually far down the priority list, or nonexistent, for a
production or technology team unless very heavy prototyping is required for a
game. Therefore, the gain of creating such a system often does not seem to be
worth the risk of disrupting an already stable pipeline. In this regard, it is im-
portant to reduce the footprint of this new system by eliminating as many poten-
tial risks as possible, and this means reusing as much of the existing
infrastructure as possible. This begs multiple questions: In which part of the re-
source pipeline should the placeholder be created? Who should be the person in
charge of creating it? How can it be integrated into existing pipelines? These
questions, unfortunately, do not have a single clear answer and mostly depend on
your own production environment. We do, however, attempt to give some an-
swers by taking our articulated placeholder model as an example and discussing
how and where it should be integrated in an existing engine. Hopefully, this
should give you an idea of the things to look for and the things to consider when
integrating a placeholder system in a production environment.
WhoMakesIt,andWhereDoYouMakeIt?
One of the most natural questions to ask is, “Who makes the placeholder?” The
answer is straightforward: “As many people as possible.” What truly results de-
pends on where you decide to integrate the placeholder into the assets pipeline
and what the production rules are for your team or studio.
Taking the articulated placeholder as an example, if it is added too far into
the asset pipeline (for example, if it is generated exclusively in code at run time
based on an animation skeleton), then you limit the placeholder creation to the
programmers. This obviously doesn’t help in decoupling the work since the re-
sponsibility of creating placeholders falls on the shoulders of a small part of your
team. The opposite case, generating the placeholder at the beginning (e.g., as a
302 17.PlaceholdersbeyondStaticArtReplacement
plug-in in the 3D modeling software), might be a good solution if everyone on
your team has basic knowledge of these tools and knows how to generate the
placeholder from them. However, some studios do not install these applications
on game programmer or designer stations to ensure that they don’t start produc-
ing artistic assets or simply to reduce operational costs. In this case, a plug-in for
the 3D software might not be the best solution.
The common ground that seems to be the best compromise is to perform the
generation directly in the game asset auditing tools (the game editor) or through a
custom tool that falls between the game editor and the artistic production soft-
ware. These tools are often available to everyone and created in-house by tool
programmers, so training remains easy, and this ensures that you always have all
the required support and control over the placeholder generation system. On the
downside, you might not be able to reuse features that were available in other
production applications. On the bright side though, this should give you access to
the shared features of your game engine that are available both in-game and in
the game tools.
Ideally, you should try to maximize the number of different people and de-
partments that can generate the placeholder. If you have studio rules limiting ac-
cess to some of your software, try to target a spot in the pipeline that opens it to
the most people. In practice, the beginning of the asset pipeline or the game edi-
tor is usually the best place to ensure that. Finally, refrain from creating a purely
code-oriented system. Programmers should not be the only team members to
know how to use the system or benefit from it.
GamePipelineIntegration
We have seen the different options as to where a placeholder system can be inte-
grated in the asset pipeline. However, we haven’t seen how it can be integrated.
What we suggest here is to treat the placeholder as a real asset as much as possi-
ble. This allows you to reuse all the available features of your existing asset pipe-
line, and it preserves homogeneity throughout your resource base. Creating
special cases to manage placeholder assets differently only makes asset manage-
ment more complicated and creates confusion during development.
In the case of our articulated placeholder, the best idea is to generate an ar-
ticulated mesh out of the skeleton and output it with the animated mesh format
you normally use for animated assets. Using this approach, the placeholder be-
haves and appears exactly as any other asset from an asset pipeline point of view,
which greatly reduces the amount of work required to integrate it in the
game.
17.4IntheEnd,IsItReallyNeeded? 303
Physics, rendering, and sound pipeline integration depends in great part on
your asset pipeline integration. If your placeholder is generated with the same file
formats as your standard assets, integrating it in game pipelines should require
absolutely no cost. For the articulated placeholder, the system could also be ex-
tended to add support for your physics and sound pipelines. Collision primitive
geometry could be generated from the skeleton and then exported to be used in
the physics engine. As for the sound pipeline, if your system uses the same con-
structs and infrastructures as the usual mesh or collision geometry, sound events
and collision sounds should be easy to add with the tools your audio designer
already uses.
All in all, the idea remains the same: integrate your placeholder in the most
transparent fashion in your game engine and reuse as much of it as possible to
reduce the time required to integrate the system in your production environment.
17.4IntheEnd,IsItReallyNeeded?
The question probably seems obvious, and you might wonder why it is asked so
late in this chapter. The reason is simply because it’s hard to answer it without
having in mind the possibilities and advantages provided by a placeholder sys-
tem. The true answer is that unless you have a perfect team that never has a sin-
gle delay and organizes things so well that no one ever waits for anyone’s work,
building placeholder systems where they are needed is definitely a plus and will
positively impact your development speed for many productions to come. But
yet, is it really always needed? Yes, but the complexity varies greatly and is often
so low that you might not even consider it a placeholder “system.”
The articulated placeholder system we present above is what we could con-
sider complex, which is correct since animated models are relatively complex
resources. For the case of simpler assets, such as text strings, you probably don’t
need to have something as complex. Generating a temporary string that displays
standard information, such as the current language and string ID, is fine enough
and truly does the trick. There is no need to start overthinking the whole system
and begin building a huge lorem ipsum generator for such simple assets. As long
as the placeholder you devise follows the guidelines mentioned earlier, you can
consider it efficient. It remains important to keep in mind that adding a new
placeholder system takes some time and that this overhead should be considered
when deciding if it is really needed or not. Moreover, keep in mind that a com-
plex system isn’t always the way to go, and simpler placeholders often do the
trick.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.