Previous : Modules
Index
Next : Texturing

title.jpg

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 :

figure1b.jpg

Figure 1.a : a simple tree procedure

figure1_tree.jpg

Figure 1.b : the tree produced by the procedure

Here is how the procedure work in this case :
  1. The starting object (trunk module) sends the trunk object to the coil #1 module and asks for decoration
  2. 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.
  3. 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.
  4. The coil #1 module decorates the trunk with decorated primary branches
  5. 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 :
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 :

figure2.jpg

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 :

figure3.jpg

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.

figure4a.jpg

Figure 4.a : Distort module used "downstream"
figure4b.jpg

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).

figure5.jpg

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.

figure6.jpg

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.

figure7.jpg

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.

figure8.jpg

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.

figure9.jpg

Figure 9 : Extending the figure 6 procedure

figure10.jpg

Figure 10 : Same as above, but using multiple object input links in a downstream context



Previous : Modules
Index
Next : Texturing