Polytron32 Manual - written by Steve Klinger
| Robot Basics |
This section doesn't tell us much about Polytron32 itself but it is very important none-the-less. Without understanding how Descent 2 robots are constructed, building a robot with Polytron32 would be a hit or miss prospect. It isn't sufficient to just jump in and draw a robot and expect it to display correctly within the game. It's very easy to draw a nice looking robot but if the parts of the robot are not integrated properly, we will have problems. So this section will attempt to explain the important background information needed to achieve a properly functioning polymodel.
A Descent 2 robot polymodel can be broken down into a number of blocks. They are the Submodel, the Chunk, the Polygon and the Point. The first block type below the complete polymodel, is the submodel. All polymodels have at least 1 submodel, but can have up to 10 submodels total in a Descent2 robot.
A submodel can be broken down into a single or series of three-dimensional shapes called chunks. Each chunk is required to be completely convex in form, meaning that if we were to draw a line from any corner of the shape to another corner, the line drawn would never leave the boundaries of the shape. A submodel can be constructed as a one convex chunk or a number of convex chunks stuck together to form non-convex chunks. (Note: Polytron only supports one convex chunks per submodel at this time.) When they are constructed in this way, there must be a split between the non-convex chunks to divide them into convex shapes. The split takes the form of a polygon.
Chunks can be broken down into a set of two-dimensional shapes called polygons. Polygons are formed of a set of at least three, and up to 20 edges, arranged on a two-dimensional plane to form a flat convex shape. A number of polygons are joined by the edges to form a completely sealed 3d shape. The polygon surfaces are flat and can be textured to give the color patterns that give the robot its textured look.
Points are used to define the corners of polygons. There can be from 3 to 20 points on a polygon. The points are the smallest block type of a Descent 2 robot polymodel. We will begin this discussion by examining points.
The most basic building block of a Descent 2 robot is the point. Points define the vertices or corners of polygons. They can exist anywhere in three-dimensional space and are located by the use of the Cartesian Coordinate System. The points that are used to define the polygon, must lie on a flat plane in three-dimensional space. Points are never seen but merely define the corners of polygons.
A polygon is a multi-sided two-dimensional figure bounded by a closed circuit of straight-line segments joining successive pairs of vertices. The line segments are called edges and the vertices are points. The areas represented by a polygon are known as planes or surfaces.
The shapes of polygons must follow a few rules to avoid
unwanted side effects. In Descent 2, a robot can have polygons that have up to 20 edges.
Polygons must be convex. A convex polygon is just one without any indentations. It can also be defined formally as having the property that any two points inside the polygon can be connected by a line segment that doesn't cross outside of the polygons boundaries. All polygons must be convex. This is an important rule. The Descent engine does not display non-convex or concave polygons properly. It has to divide them into smaller polygons which causes the polygons to do strange things.
Polygons should always be flat or planar. A three-sided
polygon is always flat by its very nature, but four, five and greater-sided polygons are
capable of being non-planar. Make every attempt while creating polygons to keep them flat.
A planar polygon will appear as a line when viewed from its edge.
The points used to define polygons do not need to be unique to that polygon. Polygons can share points with other polygons to form chunks. We could construct a cube by assembling six four-sided polygons, each with four points, for a total of twenty four points. But we need only define eight points to construct a cube. Because points can be shared when creating a chunk, we merely place the points in position, then attach polygons to them. There is a restriction to this rule. Points and their polygons cannot be shared between submodels.
Polygons in Descent 2 also have a parameter known as 'Normals'. Normals tell the Descent 2 graphics engine whether or not to display the polygon, or more accurately, which side of the polygon to display. Although polygons have two sides, we can only see one of them; the outside surface of the polygon. The game engine needs to know which side to display. The Normal provides this information to the game.
The Normal is a vector placed at a point perpendicular to the plane of the polygon. The side of the polygon that the Normal resides on is the side that the game engine will display. Polytron includes the normal when we insert a polygon. We do not have to set the vector for the normal but we need to set which side of the polygon the normal is to be set on. In doing so, we are telling the computer which side of the polygon is the outside. Changing the normal is referred to as 'Flipping the Normal'.
We use three-dimensional shapes to form the robots. Chunks, are completely sealed three-dimensional figures. A cube, sphere or a pyramid would be a chunk. A chunk, like a polygon, must be completely convex. If a line were to be drawn between any two points that make up the chunk, the line must not leave the boundaries of the chunk.
Now keeping in mind that all of these shapes must be convex in form, how do we create non-convex or concave shapes such as those we see in D2?
Well to answer this question, we can make concave shapes work by placing a chunk in a submodel. These submodels are then placed next to each other, thus creating the concave shape. This is not exactly how all robots are made but this is how it is done in Polytron32. Because Polytron32 is a "Work in Progress" application, you can expect this to change.
Another restriction is that chunks cannot penetrate the surface of other chunks. If a part of a chunk were to protrude inside of another chunk, the game engine would get confused as to how to display the chunk because the object that penetrates the surface of another, creates a concave shape in that chunk. If the surface being penetrated has BSP Tree data, it still would not work, because the penetrating object itself is not split.
Submodels are the final blocks of Descent 2 robots. There is always at least one submodel and up to ten submodels in a Descent 2 robot.
Submodels are constructed with at least one convex chunk, but are often made up of multiple chunks to achieve an otherwise illegal concave shape. Therefore, if a submodel is made up of one chunk, it must be convex. Keep in mind that Polytron only supports submodels that are made up of one convex chunk as mentioned in the section above.
Robots always have a parent submodel that all other submodels are children of. For example, the main body of a robot would be set as the parent submodel (or submodel 0) and the strut and gun combinations (each being one convex shape) on a two-gun robot, would be child submodels of the main body defined as submodels 1 and 2. Submodel 2 would be the child of Submodel 1. Both would be children of Submodel 0.
A Descent 2 robot can be constructed as a one submodel robot, but there are some useful characteristics of submodels that make using more than one of them appealing.
Submodels provide the moving parts seen on robots in the game such as the cutting arms of the Diamond Claw. The submodel to submodel joint is where the pivot point is located. Keep in mind that having submodels doesn't mean that they will move, but if you want a moving part, you will have to use at least two submodels. A moving joint between two chunks is not possible in Descent.
Another use of submodels is that they provide the shrapnel seen when the robot is destroyed.
A Binary Space Partitioning Tree (or BSP Tree) is a data structure that is used to organize objects within a space.
We don't need to understand BSP Trees in detail but we can think of them as cutting or sorting planes. They are surfaces in the model that separate concave shapes into convex shapes and sort them into a front to back viewing order. These cutting planes are invisible but provide important information to the graphics engine. The engine needs to know which shape to display first, the convex shape directly before our eyes, or the partially obscured one directly behind it. Without this data, we might see portions of the robot through other parts that should obscure them from view or we might see parts disappearing and reappearing again.
understanding the concept of cutting planes is very important
when designing our polymodel so as to insure a properly displaying robot in Descent 2. The
Cutting Plane/BSP Tree info is placed semi-automatically by Polytron where two submodels
are joined. In simple terms, they provide a way for us to use otherwise illegal concave
shapes for our robots. Cob2PM takes care of this all by itself but the construction of the
polymodel in Truespace must be done similarly with knowledge of how the can be done.
In the example to the right, we can see an illegal non-convex chunk as seen from an angle. The problem that the game engine encounters with this particular chunk is that it doesn't know which prong to display first, the left or the right. Obviously, the left prong should be displayed first when seen from this vantage point because in the area where the two prongs meet, the left prong sits in front of the right one. What will happen to this shape is that the left prong would disappear if viewed from this angle or the right one would show though the left one.
This chunk can be used in Descent if we use a cutting plane in between the two prongs thereby creating two convex chunks. This cutting plane will not make the chunks appear any different but it possesses the BSP Tree data that sorts the chunks on either side of the plane and tells the game engine which prong to draw on the screen last, which is the prong that we will use first. On a side note, the Illegal Concave Shape shown above could be constructed using only five points but because it needs to be split, it should be constructed with eight points. Four points per prong.
One way of visualizing cutting planes is to think of them as
a piece of thin glass placed on the surface of the polygon where the shape is joined to
another shape. The cutting plane that separates a concave shape into two convex
shapes is not confined by the polygon that defines it. Our 'piece of glass' extends beyond
the edges of the polygon into infinity. 
In this example, the cutting plane is drawn with imaginary edges to demonstrate its orientation.
This is important to know because these cutting planes must not intersect with another 'physical' part of the robot that lies on the same side of the cutting plane. The cutting plane, however, can intersect with a part that lies on the opposite side of another cutting plane. We can see this in the example below.
In this diagram, we can see that a new shape has been added to the model. It is attached to Surface A (seen in blue). In order for this shape to work, we must have a cutting plane that separates it from Surface A. Plane A represents this new cutting plane. We can see that Plane A will cross into Prong A. Because Prongs A and B are 'already' split by Plane B, and Prong A lies on the opposite side of Plane B from Prong A, this will be alright. If we split off the New Shape by creating Plane A before we split the two Prongs with Plane B, then we would have a problem.
The order of the splits does make a difference. The 3d engine looks at the BSP Tree data in the order that it finds it when reading from the Hxm or Ham file. In the first scenario where Plane B splits the prongs before Plane A splits the new shape from Prong B, the engine encounters the Plane B split first. Then when it encounters the Plane A split, the intersection rule would not be broken because the Plane B split is already there.
In the second scenario, where the Plane A split is made before the Plane B split, the 3d engine would think that there is no Plane B split in existence because it has not encountered it yet, thereby breaking the intersection rule. The shape would not be rendered properly as a result.
So we need to keep this in mind when it comes time to set the order of the splits. This order generally follows a top down approach sort of like a pyramid or tree. This is why they are called BSP 'Trees'. Remembering the section about submodels, the parent submodel would be at the top of the tree with the children submodels branching off below it.
The ordering is set in Polytron by simply assigning each shape to a submodel. What submodel number the shape is assigned to sets the order for the splits. In the example above, we would assign prong B as the root submodel, or submodel 0. Prong A would be submodel 1 with the parent set to submodel 0. This would create a BSP plane between these two submodels as seen by Plane B. The New Shape would be assigned to submodel 2 with Submodel 0 (Prong A) as the parent. This creates Plane A. Because the New Shape is submodel 2, or the third submodel in the list, its sorting plane is read after the sorting plane created for submodel 1.
We must design our robot with BSP Tree data/Cutting Planes in mind. This applies to both Polytron and Truespace/Cob2PM. It really isn't just a simple matter of drawing the robot. These restrictions are not something that any robot editor can overcome. They are imposed by the Descent 2 game engine and we must work within this frame work. But if we understand these restrictions then we can successfully create new robots for our own add-on missions.
Descent 2 Robots use two types of textures. Texture-mapped polygons and Flat-shaded polygons.
The Texture Mapped variety is the most common of the two types. It uses textured images just like those used in levels. The Flat-shaded type are solid colors. They are used infrequently, mostly for small parts and require no lists from which they must be selected from. Texture mapped polygons, however, must be chosen from a list of existing textures.
The Polymodel Texture List is a list of the textures used by the Original Descent 2 robots. It starts with the first texture of the first robot and proceeds, in order, through all the textures for all the robots until it ends with the last texture of the last robot. The Polymodel Texture List points to another list of textures; the textures of the pig file.
The textures are set in the model data block of the HXM/HAM file. The way this is done is we set a first texture number. This first texture number is the number of a texture in the Polymodel Texture List mentioned above. Then, the number of textures to be used is set. What this does is set a first texture of a set of textures. For example, if the first texture is 23 and the number of textures is 5, then the texture set would be textures 23, 24, 25, 26 and 27 from the Polymodel Texture List.
The big drawback of this method is that this list is extremely in-flexible. The list contains a number of repeated textures and does not allow the use of just any texture. We are restricted to use the textures in sequence. So we can't use textures 23, 78, 134, 190 and 445 for example.
But, there is a way to use any texture we want. In the HXM/HAM file, there is a block called Object Bitmaps. This block is where replacement textures are set. Simply, the replacement texture is defined for the texture number of the Polymodel Texture List.
Now this may sound simple, but because the two texturing methods are set in different blocks of the HXM/HAM, a polymodel-only editor, such as Polytron, cannot take advantage of replacement textures. This little understood fact has caused a certain amount of confusion among Polytron32 users. This really is not a Polytron32 problem, but it is a limitation of the POL file that Polytron32 edits. Polytron32 constructed robots can use replacement textures but Polytron cannot implement them. So selecting textures in Polytron32 should be based on textures that are similar to the pattern of the desired textures. That way the texture can be aligned properly and look good when the textures are replaced with an editor that edits replacement textures.
For Flat-shaded polygons, we can just set the desired color, and not have to worry about lists and such.
There is one more subject to cover in this section. Descent 2 robot file types.
The original Descent 2 robots are stored in the Descent2.ham file. To use replacement robots, we must store robots in either a HXM file or a VHAM file. These files are special files that hold custom data.
The HXM file contains only robot data. This file is divided into four blocks of data. These blocks are called Robot Types, Robot Joints, Polygon Models and Object Bitmaps.
The VHAM file is a HAM file introduced by the Vertigo Series. The VHAM allows us to add robots to the existing robots as well as a few other things. The file contains the same type of data for robots as the HXM file but also has a few other blocks that we will not get into here. Robots created by Polytron32 can be used in both types of files.
Polytron32 edits the data that is covered in the Polygon Models block. It currently does not edit any of the other three blocks. The data held by a POL file is the Polygon Models block. This is why Polytron32 does not handle the gun points and texture replacement items. The data for these things are not held in the POL file. The difficulty in setting textures in Polytron32 is in fact a limitation of the POL file, not a poor implementation of robot texturing. Tentative plans for future versions of Polytron32 may include editing of these other blocks.
To edit the Robot Types block, You can use Haxmedit32, Haxmedit/Dos (both of these are Descent Manager tools), Hxmedit by John Aldrich or Rbotedit by Garry Knudson. To edit the Robot Joints and Object Bitmaps blocks, Rbotedit is an easy to use choice. Haxmedt32 is a great tool to insert and extract any of these blocks for use in other HXM and VHAM files as well as edit some of the other data types found in the Descent2.ham file
This pretty much covers Robot Basics, and I hope it helps clear things up. You may need to re-read this section to understand it fully. The more that you understand these concepts, the better your chances at success. So now we can take a look at the Polytron32 interface itself..
WebHits
counts accesses on this page since 02/08/97. View detailed
statistics!
