Defining Routes

A path by its lonesome self does you little good; there are times when you need to string together a series of paths that an object must follow. I'm talking about complex paths that are both straight and curved. In fact, we're no longer discussing paths; we've moved on to the advanced topic of routes!

As you can see in Figure 2.6, a route is a series of paths that are commonly connected from endpoint to endpoint.

As you have probably surmised, you can define a route using an array of path objects. By creating a generic path structure, you can store information for both straight and curved paths in one structure. The secret is to look for commonalities and expand on those. For example, the straight and curved paths both have starting and ending points. Therefore, you can define two sets of coordinates that represent the starting and ending coordinates inside your generic path structure, as follows:

typedef struct {
  D3DXVECTOR3 vecStart, vecEnd;
} sPath;

The only real difference between the two path types is that the curved paths have two additional control points. Adding another two vector objects to your budding sPath structure will work just fine for holding the control point coordinates.

typedef struct {
  D3DXVECTOR3 vecStart, vecEnd;
  D3DXVECTOR3 vecPoint1, vecPoint2;
} sPath;

Now the only thing missing is a flag in the sPath structure to determine which type of path is defined−straight or curved. Include a DWORD variable and an enum declaration to determine which type of path is defined.

enum { PATH_STRAIGHT = 0, PATH_CURVED };

typedef struct {
  DWORD Type;
  D3DXVECTOR3 vecStart, vecEnd;
  D3DXVECTOR3 vecPoint1, vecPoint2;
} sPath;

From here on, you only need to store a PATH_STRAIGHT value or a PATH_CURVED value in the sPath::Type variable to determine the use of the contained data−either for a straight path with starting and ending points or for a curved path with starting, ending, and two mid−path control points.

Allocating an array of sPath structures is easy, and filling that array with your path's data (such as the data shown in Figure 2.7) is as simple as the following code demonstrates.

sPath Path[3] = {
{ PATH_STRAIGHT, D3DXVECTOR3(−50.0f, 0.0f, 0.0f),
D3DXVECTOR3(−50.0f, 0.0f, 25.0f),
D3DXVECTOR3(0.0f, 0.0f, 0.0f),
D3DXVECTOR3(0.0f, 0.0f, 0.0f) },
{ PATH_CURVED, D3DXVECTOR3(−50.0f, 0.0f, 25.0f),
D3DXVECTOR3(0.0f, 0.0f, 50.0f),
D3DXVECTOR3(50.0f, 0.0f, 0.0f),
D3DXVECTOR3(25.0f, 0.0f, −50.0f) },
{ PATH_STRAIGHT, D3DXVECTOR3(25.0f, 0.0f, −50.0f),
D3DXVECTOR3(−50.0f, 0.0f, 0.0f),
D3DXVECTOR3(0.0f, 0.0f, 0.0f),
D3DXVECTOR3(0.0f, 0.0f, 0.0f) }
};

Of course, you really shouldn't hand−code routes into your project; it's best to use an external source such as an .X file to contain your route data.

 

Creating an .X Path Parser

The easiest place from which to obtain your path data is−you guessed it−an .X file! That's right, you can construct a couple simple templates to use with a custom .X parser to obtain the paths you want to use for your project. You can even construct routes from your path templates to make things easier!

You can duplicate the generic path structure you developed in the previous section to use as a template in your .X files. This generic path template will contain four vectors−the first two being the starting and ending coordinates of the path (for either a straight or curved path), and the last two being the handles' coordinates (for curved paths). Take a look at the single template definition you can use.

// {F8569BED−53B6−4923−AF0B−59A09271D556}
// DEFINE_GUID(Path,
// 0xf8569bed, 0x53b6, 0x4923,
// 0xaf, 0xb, 0x59, 0xa0, 0x92, 0x71, 0xd5, 0x56);

template Path {
  <F8569BED−53B6−4923−AF0B−59A09271D556>
  DWORD Type; // 0=straight, 1=curved
  Vector Start; // Start point
  Vector Point1; // Midpoint 1
  Vector Point2; // Midpoint 2
  Vector End; // End point
}

After you've defined your .X file Path template, you can instance as many times as you need in your data files. To load those paths, you should create a route template (called Route) that allows you to define multiple path data objects. This route template merely contains an array of Path data objects, as you can see here:

// {18AA1C92−16AB−47a3−B002−6178F9D2D12F}
// DEFINE_GUID(Route,
// 0x18aa1c92, 0x16ab, 0x47a3,
// 0xb0, 0x2, 0x61, 0x78, 0xf9, 0xd2, 0xd1, 0x2f);
template Route {
  <18AA1C92−16AB−47a3−B002−6178F9D2D12F>
  DWORD NumPaths;
  array Path Paths[NumPaths];
}

For an example of using the Route template, take a look at how the route defined in the previous section would look in an .X file.

Route MyRoute {
3; // 3 paths
0; // Straight path type
−50.0, 0.0, 0.0;
0.0, 0.0, 0.0;
0.0, 0.0, 0.0;
−50.0, 0.0, 25.0;,
1; // Curved path type
−50.0, 0.0, 25.0;
0.0, 0.0, 50.0;
50.0, 0.0, 0.0;
25.0, 0.0, −50.0;,
0; // Straight path type
25.0, 0.0, −50.0;
0.0, 0.0, 0.0;
0.0, 0.0, 0.0;
−50.0, 0.0, 0.0;;
}

You can access the route data objects from your .X files by using a custom .X parser. This parser only needs to look for Route objects. When it finds one, it will allocate an array of sPath structures and read in the data. The route data itself is kept inside a linked list of structures so that you can load multiple routes. This route data uses the following class:

 

The sPath structure also needs to be spruced up a bit. You need to add the length of each path to its respective structure, as well as to the starting position of the path in the series of paths. This is a simple process. The length, as you saw in the previous few sections, is only a floating−point number, and the starting position of the path is the combination of the lengths of all prior paths in the list. Your new sPath structure should look like this:


The reason to include the length and starting position of the path in the sPath structure is really a matter of speed. By pre−computing the length values loading the path data, you can quickly access that data (the length and starting position) when you are determining the path in which an object is located based on its distance into the route.

I know it sounds strange, but think of it like this−the starting positions and lengths of each path are like key frames; instead of measuring time, you are measuring the lengths of the paths. By taking the position of an object in the route (say 516 units), you can scan through the list of paths and see the path within which the object lies.

Suppose the route uses six paths, and the fourth path starts at 400 units. The fourth path is 128 units long, meaning that it covers the lengths from 400 to 528 units. The object at 516 units is located in the fourth path; by subtracting the object's position (516) from the ending position of the path (528), you can discover the offset in the path that you can use as a scalar value to calculate the object's coordinates along the path. In this case, that position would be 528−516, or 12 units, and the scalar value would be 12/128, or 0.09375.

Enough talk, let's get to some code! The following class, cXRouteParser, is derived from the cXParser class, meaning that you have access to the data−object parsing code. All you want to do with the cXRouteParser class is scan for Route data objects and load the appropriate path data into a newly allocated Route class that is linked to a list of routes.

Check out the cXRouteParser declaration, which contains the root Route class pointer and six functions (three of which contain code inline to the class).

 

The most important function of cXRouteParser is the template data object parser, of course. I'll show you the parser function in a moment. The load function merely sets up the call to parse, which in turn loads all your Route templates into the linked list. The locate function calculates the position along the route's path that you can use to position an object. Again, I'll get to the locate function in a moment. For now, I want to get back to the parse_objects function.

The parse_objects function only scans for one template data object−Route. Once it is found, a cRoute class and the path structures are allocated, and the data is loaded. The cRoute class is linked in the list of loaded routes, and the parsing of the .X file continues. Here's what the parse_objects function code looks like:

 

As usual, you don't call parse_objects directly−it's up to your cXRouteParser::Load function to call Parse, which in turn calls parse_objects. Knowing this, take a look at the Load function (which takes the file name of the .X file to parse as the only parameter).


Short and sweet, just how I like them! The load function is really just a gateway to ensure that prior route data is freed and the Parse function is called. There's not much more to it!

Now that you've defined the templates, created your custom class, and loaded the route data, it's time to start moving those objects! It's time to get back to the cXRouteParser::locate function.

By taking the current time and the distance (in 3D units) that an object can move, you can iterate through each path in your route to determine exactly which path an object would be on at a specific time. From there, you can calculate exactly how far between the beginning and end of that path the object lies and correctly position your object.

Suppose you have an object that is moving at 200 units per second, which is 0.2 units per millisecond. Multiply the distance per second by the total time along the path to obtain the object's location within the route. You'll use this total distance inside the route as the distance parameter in the call to locate.

The locate function takes the distance you provided and scans through each path contained in the route. Remember, you've already calculated the starting position and length for each path, so this is merely a check to see whether the object's distance is greater than the start of the path and less than the distance of the path. Take a look at locate's code to see what I mean.

 

WinMain.cpp:

Runtime Snap:

 

download soure file