Torque render node

Detail levels marked as AutoBillboards are different from usual detail levels in that they take a 'snapshot' of the geometry which is rendered as a single image that always faces the camera, and can be very useful to speed up performance. To generate the billboards, the Torque engine renders the object at certain angles and stores the resulting image. In-game, the Torque engine determines which snapshot is closest to the camera’s current orientation, and renders the single image instead of the shape geometry.

Note that this is quite different to billboard geometry, where the actual geometry (not a snapshot) is automatically rotated such that it always faces the camera.

To understand how the snapshots are generated, it may be helpful to think of the shape as a globe, with the 'equator' running around the center in the horizontal plane, and the 'poles' at the top and bottom of the vertical axis. The image below shows some of the billboard snapshots when the shape is viewed from different angles.

Geometry used for collision and line-of-sight (LOS) collision checks must be convex. These two types of geometry are usually invisible, so the detail level should be negative to indicate to the Torque engine that the geometry should not be rendered. Collision meshes should use as few polygons as possible to reduce the CPU load when determining collisions with other objects.

For collision meshes, the exporter will generate a detail marker with name 'CollisionXXX' and geometry 'ColXXX', where XXX is the LOD size (normally -1 to -9).

For LOS meshes, the exporter will generate a detail marker with name 'LOSXXX' and geometry 'LOScolXXX', where XXX is the LOD size (normally -9 to -15).

Parts of a shape can be billboard objects (i.e., they always face the camera). So, for example, you could have an explosion in which shrapnel flies out from the center and also have little explosion balls fly out that are just flat polygons that always face you.

Linked geometry can be made a billboard by selecting the Billboard or Z Billboard types from the dropdown menu. Note that not all detail levels of the object need to be billboard objects, so the highest detail level of a shape could be a complicated 3d shape, whereas the lowest detail could just be a billboard. Z billboards are the same as regular billboards except that they only rotate about the z (vertical) axis.

Objects with transparent textures often times appear to sort improperly in the engine. On modern graphics hardware, drawing on the screen amounts to storing values on the graphics card for the red, green, and blue channel, and also storing values for the distance of the fragment from the camera. The later value is often referred to as the “depth-value” or “z-value”. The depth value is important for determining what should be drawn in front of what.

To understand how this works, you have to understand one basic point: polygons are always drawn in an order. One is drawn first, another second, etc. So when the second is being drawn, the value of the first polygon is sitting in the frame buffer (the place on the graphics card that holds what you are drawing on the screen). This means that the graphics hardware can simply compare the depth value of the incoming pixel against the depth value of the stored pixel, and only update the frame buffer if the incoming pixel is in front of the stored pixel. That is exactly what happens.

Drawing transparent fragments also requires a combination of what is in the frame buffer already and the incoming fragment. With transparency, the incoming fragment has an “alpha-value” in addition to red, green, and blue, and the alpha value is used to blend the fragment with the framebuffer. An alpha of 1 means to over-write what’s in the buffer, an alpha of 0 means not to touch the frame buffer, and an alpha of 0.5 means to mix them equally.

Transparent drawing with depth tests gets very tricky. If polygons are drawn back to front, depth tests and transparency behave well together. But when some polygons in the front are drawn first, things start to get very messy. Imagine what would happen if you had a fully transparent texture (alpha of 0) drawn first, and that it fully covered the camera and was in front of everything else. Since the alpha value is zero everywhere, it would not draw to the RGB channels. But the depth value would still be updated for the entire screen. Now everything that was drawn would fail the depth test. The result is that you would see a blank screen no matter what you draw behind the phantom polygon.

Because of this issue, transparent polygons are normally drawn with special care: the depth value is not saved but the depth test is still used. Transparent polygons are drawn after non-transparent polygons, and transparent polygons are drawn from back to front. The result is that transparent polygons behave when they overlap each other because they are drawn back to front. Transparent polygons behave when overlapping non-transparent polygons because they only drawn when they are in front of the non-transparent polygons (remember, the depth test is still carried out, the depth value just isn’t stored). The phantom polygon issue is avoided because the depth value isn’t stored.

One consequence of all this is that any object that draws transparent polygons must do so with special care. Furthermore, the engine itself must take special care to draw everything in the right order. In particular, the most accurate way for the game to draw the scene is to first draw the non-transparent polygons of all objects, then draw the transparent polygons of each object from furthest to closest to the camera. Each object, then, is only responsible for drawing it’s own polygons so that they can sort amongst themselves.

Three space has several mechanisms built in to handle the sorting of polygons. First, parts with only non-transparent polygons are drawn first, then parts with a mixture of transparent and non-transparent polygons, and then transparent parts. Note that if you have several parts with mixed polygon types, you will likely get some inappropriate sorting, so don’t do this. These are all the measures 3space takes by default. However, there are special objects that do a little more sorting on their own. These are the sort objects described below. What these objects do is order the polygons so that they will always draw back to front. Believe it or not, it is often possible to do this for all camera angles. This however, it is not always possible. In those cases, the object has different orderings for different angles (usually only a few are needed) and in really bad cases, polygons have to be split. The latter can sometimes lead to large file size. If you see this happening, you should redesign the shape.

The faces of these objects are presorted so that faces are drawn from back to front. This is used to force the sorting order of transparent objects (which are not z-buffered) This sometimes involves splitting faces and sometimes involves different orders depending on where the camera is.

To make linked geometry a sort object, select the Sorted type from the dropdown menu. Other detail levels of this object do not have to be sort objects.

This type of animation captures the mesh geometry as a series of snapshots. ie. the position of every single point in the mesh is stored for each frame of the animation. This is useful for certain types of animations (e.g. flags or facial movements), but it will produce large files and does not contain animated nodes.

One way of animating the points in a mesh is to add a Point SOP to the output of the geometry, then animate the TX, TY, TZ parameters.

This type of animation allows the texture UV coordinates to change over time, and is useful for things where the texture itself must animate. Scrolling computer monitors, waterfalls, and tank treads are just a few of the applications for animated texture coordinates. To animate the UV coordinates, simply add a Point SOP to the output of the geometry, and animate the MAPU and MAPV parameters (MAPW is not used during DTS export).

A DTS Material has a 'Visibility' parameter that can be animated to control the transparency of the object using the material over time. This is useful for parts of the model that you may only wish to show during certain animations.

Note that environment mapping (the DTS Material 'Env. Mapping' parameter) should be set to 0 for DTS materials that animate the 'Visibility' parameter, as otherwise the visibility will be either on (1) or off (0), without values in between.

IFL (image file list, or image file library) animation allows the texture applied to an object to be switched automatically over time. The IFL file defines a list of textures, and optionally the number of frames to display each texture for.

Blend animations allow additive animation on the node structure of the shape. These will not conflict with other threads, and can be played on top of the node animation contained in other threads. Such animations are relative. Blends only read the changes that occur over the course of the animation and not the absolute position of the nodes. This means that if a node is transformed by a blend animation, it includes only the transform information for that node, and it will add that transformation on top of the existing position in the base shape (the DTS).

Bear in mind that a blend can be played as a normal sequence, or it can be played on top of other sequences. When another sequence is playing, it will alter the root position, and the blend will be applied on top of that.

If you try to do a blend sequence where the root position is different than the 'normal' root (in the default root animation), you might expect that the blend will blend it to the new root (the position the character is positioned in during the blend animation). However, it does not work this way. Since nothing would actually be animating, it doesn’t move the bones to the new position. What is contained in the blend sequence is only transform offsets from the blend sequence root position.

It is not a good idea to have a different root position in your 'normal' animations and your blends, as they can easily get out of sync.

You can determine the position that the blend animation uses for the animation offset by using the blend reference frame.

The values added from the blend animation are based on the root position in the DTS/DSQ file. This root position does not have to be the beginning of the animation. You can pick any position for the blend animation to reference.

This is useful, because you can have a blend animation that can have a reference position that is the 'root' position. For animation like hip twists and arm movements (as in the 'look' animation), the character can be in a natural default state. In this way, you can have one animation control the character through the base pose to an extreme in either direction while referencing the default 'base' state, which will exist somewhere in the middle of the blend animation.

Animation sequences that move the character must export a ground transform. The engine knows that the character has a specific velocity in all directions (this is set in script). When the animations are being played, the engine is aware of what the distance covered is and plays the appropriate animation. If, for instance, the forward velocity of the character increases past the point of a walk animation to the speed of a run, the engine will automatically transition to the run animation.

The Torque exporter figures out the ground transform (meters per second over a given distance) by determining how much the bounding box has moved over the course of the animation. The bounding box is a box at the scene root level (/obj) called 'bounds', which can be automatically created by the Torque output node.

If you have no ground transform, the animation will not play properly when the character moves. In the Torque engine with the default character, the forward ground transform is approx=4m/sec.

Triggers are arbitrary markers that can be used to call events on specific frames in a sequence. An example of a triggered event is calling footstep sounds and footprints during walk and run animations. You may define up to 32 triggers per sequence.

There can be up to 32 trigger states each with their respective on (1 to 32) and off (-1 to -32) values. What each of those trigger states means is up to you. You should work with your programmer to define what the trigger states mean and how you should use them.

For example, you could have one trigger for each foot of a character that creates a footprint when the foot is down on the ground. Let’s say that a triggerState of 1 is the left foot down and a triggerState of 2 is the right foot down. When the sequence plays the frame during which the left foot touches the ground, you could have a trigger on that frame that has a triggerState of 1 to create a footprint. You would then create another trigger with a triggerState of 2 for the right foot. You don’t necessarily need to turn off the footprints (let’s assume that the programmer will turn them off when it is necessary), but you could by creating two more triggers with triggerStates -1 and -2.

There is one Frame and State per trigger. Trigger numbering starts at 0. For example, Frame0 and State0 are the first trigger, Frame1 and State1 are the second trigger, etc. Note that when you delete triggers from the list, all of the remaining triggers are renumbered starting from 0. Their frame and state attributes are retained.

1. Geometry must be converted to triangles before exporting. Add Convert and/or Divide SOP nodes to the output of geometry nodes as required.

2. The exporter attempts to export what you see in Houdini, so it is important to set the 'Render/Display' flag correctly within each geometry container. The SOP nodes within a geometry container generally form a chain (the output of one node connects to the input of another), and the 'Render/Display' flag determines which node output is both rendered in the Houdini viewport and used for DTS export. Generally, the best practice is to set the 'Render/Display' flag on the last node in the chain, indicating that the accumulated output of the entire SOP chain is to be used (see image below). Note that Houdini does not do this automatically!

3. Add a new 'Torque' node to the /out network (TAB->More->Torque).

4. The Torque DTS exporter does not require any special node hierarchy, but it is important to set the 'Export Root' parameter to point at the root node of the scene to be exported. The default ('/obj') is usually correct.

5. Create the detail levels manually, or use the Init Details From Scene button to generate them automatically.

6. Create animation sequences as desired

7. Set the name of the shape to be exported, and select whether to export a DTS (geometry and animation) or DSQ (animation only)

8. Export the scene using the menu bar (Render->Start Render) or directly from the Torque node parameter view (using the Render button).

The following image shows the chain of SOPs within a geometry container:

Note that the last SOP in the chain has the 'Display/Render' flag set (the double circles around it). This means that the output of this node will be used both for rendering in the Houdini viewport and for DTS export. If the 'Display/Render' flag was moved to the 2nd node in the chain (texture1), we would still have the geometry (from the grid1 node) and the UV coordinates (from the texture1 node), but we would no longer render or export the material assignment (material1) or the point animation (point1).

Because the DTS format supports only a subset of the Houdini shader functionality, it is best to use the DTS Material provided in the OP_dts.otl library. The DTS Material node must be added to a SHOP Network, and a Material SOP added to the object node which points towards the DTS_Material path as shown below.

You can add multiple DTS Material nodes to the SHOP Network, and assign each to a different group (or groups) of geometry primitives using the Material SOP.

• If you are having trouble with UI elements flashing or not being drawn correctly (common with older or less capable video cards), set the following environment variable and restart Houdini: HOUDINI_OGL_SOFTWARE = 1

• Warning message in dump file: This object contains unsupported geometry.: The DTS format supports only triangular primitives, so any geometry that is to be exported must first be converted into this form. There are two SOPs that can help with this:

  1. Convert: Used to convert from NURB/Mesh etc to polygons (and can also output triangles, removing the need for the separate Divide node).

  2. Divide: Used to split polygons into triangles.

• Houdin crash on export: First check the dump.html file for errors or warnings. If the export process crashes during the “Optimising geometry” stage, the problem could be that the geometry has too many polygons for the tri-stripper. Try reducing the polygon count, breaking the geometry into separate pieces, or turning off geometry optimization.

• Missing textures in exported shape:

• check that the Houdini geometry container has the Display/Render flag set for the correct node

• check dump file to confirm that materials were found during export

• the Torque engine requires the texture files to be in the same directory as the .dts file

• textures do not need to be square, but the width and height must be powers of 2 (eg. 2, 4, 8, 16, 32 etc)