4.1
Anatomy of a procedure
4.1.1
Upstream and downstream
How does
a procedure work ? At first, I thought it would work exactly like the
procedural texture procedures. However, things got a bit more
complicated in the process, especially with the multiple input link
feature. However, multiple input links should not be the tree that
hides the forest : multiple output links can be also a bit disturbing.
To understand all these key points, let's have a look at a simple
procedure :
Figure 1.a : a simple tree procedure
Figure 1.b : the tree produced by the
procedure
Here is how the procedure work in this case :
- The starting object (trunk module) sends the trunk object
to the coil #1 module and asks for decoration
- The coil #1 module asks the primary branch module for a
decorator object and the customised function module for size values.
The primary branch module sends the object to the coil#2 module. which
is in turn sent to the coil #2 module for decoration.
- The coil #2 module asks the secondary branch module for a
decorator object. This object is sent to the coil #2 module. Since the
output port has no link, the decorated primary branch object and its
decoration returns to the coil #1 module.
- The coil #1 module decorates the trunk with decorated
primary branches
- The decorated trunk returns to the starting object module.
It is then considered as the TaPD object to paste into the AoI scene.
The most
important thing to notice is that there are two kinds of object links :
- Object
links where a decoration process is asked for. These links go left to
right in figure 1.a.
- Object
links where a single object (usually a decorator) is asked for. These
links go from the bottom to the top in figure 1.a.
Another
way of looking at this process is a "downstream/upstream" point of
view. The decoration process flows "downstream". At some point of the
process, decorator objects are needed and the procedure goes "upstream"
to find the necessary decorator objects.
4.1.2 Object
ports
Now, the
point is that some object ports are only concerned by the downstream,
decoration process, whereas some others are only concerned with
upstream, yielding decorators, process. Plugging an downstream port
into an upstream port (and vice-versa) won't get you anywhere. Let's
look at the following example which is a rewriting of the figure 1
procedure :
Figure 2 : A wrong rewriting of the
procedure shown in figure 1.a
At first, figure 2 seems sound. The primary branch is decorated with
secondary branches and the whole lot is used for decorating the trunk.
The problem is that the decorator port entry asks for one object
(upstream process) and receives a collection of objects (downstream
process). In that case, the coil #2 module refuses to send an object to
the coil #1 module and the trunk is not decorated.
Why not differentiate the two kinds of ports, then, and identify them
by different colours ? Well, some ports act as hybrid ports. The
following procedure fragment is perfectly valid :
Figure 3 : A procedure fragment showing
hybrid nature of starting object output port
What happens in this procedure ? The starting object asks for
decoration through the two links that come out of its output port. The
first link goes to the decorator port of the coil module. The decorator
port does not do any decoration, so an empty object is returned. The
second link is plugged into the object to decorate entry port, and this
time the decoration process starts. The decorator port of the coil
module now asks for a decorator oject. The link is followed upstream to
the starting object output port which, in this case, yields only the
object the module holds and not the fully decorated object. The coil
module then decorates the trunk with copies of itself. The output port
of a starting object thus presents a hybrid nature : it is both used
for downstream and upstream processes. The distort module, for example,
also has hybrid ports, see figure 4.a and 4.b.
Figure 4.a : Distort module used
"downstream"
|
Figure 4.b : Distort module used "upstream"
|
So far, we just explained what a TaPD procedure was about, but this has
little impact on procedure editing and design by itself. The downstream
and upstream consideration has however great significance on the
meaning of mutliple links and that is precisely the point that is about
to be discussed.
4.2
Multiple links
4.2.1 Mutiple value output links
This case
is really straighforward : it's like the procedural texture case.
The value is sent to all modules the value module is linked to.
4.2.2 Mutiple value input links
Value modules are always part of upstream processes : they don't do any
decoration. Look at figure 5 : the starting object asks "upstream" for
a size to resize the object prior to decoration process. There are more
than one link plugged into the size input port, so it has to choose
between of of these links. The choice is made at random, each link
having an equal probability of being chosen (1/3 in this particular
case).
Figure 5 : Multiple value input links
example
4.2.3 Multiple object output links
This
time, there are two cases to consider :
Case 1 : upstream process
As for multiple value output links, this
case
is straighforward.
The object is sent to all modules it is linked to that asked for a
decorator object.
It's the case for example of the secondary branch module in figure 9.
Case 2 : downstream process
Let's consider the
example shown in figure 6.
Figure 6 : Multiple object output links -
downstream example
The
starting object has two links coming out from its output port. It does
not choose between one or the other : both decoration processes are
carried out and both results are merged
into a single collection of objects. For this reason, it is possible to
state two different origins for the two coil modules decoration
processes so that the decorator objects do not overlap.
Sometimes, it is wished that the output port links are chosen at
random. In that case, use a random module as shown in figure 7. Half of
the time, the primary branch will be decorated using the coil #1 module
and the other half using the coil #2 module. Please note that this is
not equivalent to mixing randomly secondary branch and another
secondary branch for the decoration of a single primary branch : this
can be only obtained by linking the two object modules output ports to
the decorator entry of a single coil module.
Figure 7 : Randomising multiple object
output links - downstream example
4.2.4 Multiple object input links
As before, we will consider upstream and downstream processes :
Case 1 : upstream process
This case is equivalent to the multiple value input links, since in
both cases an upstream process is considered. In the following example
(figure 8), the coil module has to choose between two object module
each time it needs a decorator object. The choice is made at random, as
for the value multiple input links case.
Figure 8 : Multiple object input links -
upstream example
Case 2 : downstream process
Reconsider the
example shown in figure 6, and
let's suppose we want to decorate both primary branches with the same
object given by a secondary branch module. If object ports were limited
to one input link only, we would have to setup two coil modules as
shown in figure 9. That is not very practical : each modification of
the coil module would have to be duplicated to its alter ego. It is
possible to link both output of the coil #1 and coil #2 modules as
shown in figure 10. This setup is equivalent to the one shown in figure
9 whithout having to manage two coil modules.
Figure 9 : Extending the figure 6 procedure
Figure 10 : Same as above, but using
multiple object input links in a downstream context
