Developer Network
  File Specs
  Source codes
  Mailing lists
  Knowledge Base

Other Games



Descent Developer Network
Descent 1/2

IDTA Project


Welcome to this project! With this project we found out how to build new model_data, meaning creating new 3D polygon_models in Descent 2, such as robots, players and missiles/lasers/fusion! The result was such programs as

The project was a cooperation of Heiko Herrmann, Luke Schneider, Steve Klinger and Garry Knudson.


Some information about HAXMEDIT/DOS

You have two possibilites to start the HAM/HXM-Editor:

  • If the file is available directly (not within a HOG), start HAXMEDIT and enter the filename (incl. directory), or enter the name directly on the command-line:

  • If the file is within a HOG, you don't need to extract the HXM or HAM file first. Simply use the syntax:
    The two points indicate that you want to access a file within a HOG!


Then you can go into the model_data-editor using one of this way (depending on the file you're editing!):

  • DESCENT2.HAM or D2X.HAM: Select "MODEL_DATA" in layer "Blocks", select the element you want to edit in layer "Elements", then go to layer "Characteristics"!
  • HXM file: Select "POLYGON_MODEL+" in layer "Blocks", select the element you want to edit in layer "Elements", then select "model_data" in layer "Characteristics" and press F4!


Extracting an element out of a HAM (You cannot extract from a HXM yet!):

  • On layer "Blocks" choose the block from which you want to extract. Note: Some blocks belong together, e.g. POLYGON_MODELS, MODEL_DATA, DYING_MODELNUMS and DEAD_MODELNUMS. It doesn't matter which one you choose of them, they are here handled as one block.
  • On layer "Elements" choose the element you want to extract. Press "Extract (F4)".
  • You will be prompted for a filename.
  • After RETURN the element will be saved into the HMEL subdirectory of Descent Manager.


Adding an element to a HXM (You cannot add to a HAM yet!):

  • On layer "Blocks" choose the block to which an element should be added.
  • On layer "Elements" simply press "Add (F2)".
  • You will be prompted for the filename (sorry, no browser yet!).
  • After RETURN the element will be added at the end of the block as last element.



  • Supported H?M-files for now are: DESCENT2.HAM, D2X.HAM and HXM version 1 files
  • Always install alpha versions in a complete new directory!
  • Make a backup of the file you're editing (especially DESCENT2.HAM and D2X.HAM)
  • You can now create an empty HXM file for a level! It will be automatically made, if you press F4 on Mission Manager's "Special" screen in Robots mode!
  • One of Descent Managers powerful features is, that you don't need to extract a HXM file from a HOG before editing. This still is true, as adding an element automatically inserts it WITHIN the HOG and then corrects the size of the HXM file in the header.
  • Since Alpha 07a Build 14 the DEMo-Editor is not available anymore! If you need it, run the Beta 06f that can be installed parallel! In the future the DEMo-Editor will be a seperate tool.


Tools, files and specs you (might) need

The following tools/files are highly recommended for the experiments:


Tip: How to restore DESCENT2.HAM

When the DESCENT2.HAM is edited and you forgot to make a backup copy of it, go this way to restore the original one: The original DESCENT2.HAM is on the D2 CD in the subdirectory \D2DATA and is within the file DESCENT2.SOW, which is a normal ARJ archive. So with ARJ you can restore it using the following command (assuming that V: is your CD-ROM-drive, ARJ is in the path and you are currently in the D2 directory):



07/14/97 03:16 - Heiko Herrmann - My first custom robot

I have myself played a bit with the Internal Tactical Droid (the small blue guy at the beginning of D2 L1!), morphing him, and you can see the results below ("before-after" with "before" on the right)! Click on the small picture to view it in full-size!


07/14/97 06:39 - Steve Klinger - Report of my experiments so far

I did some experimenting with the latest version of Descman. I created a copy of Descent2.ham and used that as my source. I decided that the easiest robot to work on would be the Red Triangle. It turns out that under model_data all the names are offset by one. I selected Red Triangle and started to experiment. I edited the d_tmappoly (more than one of them) and changed texture to 7. Then in PMView2, I looked at my results and the Red Triangle was unchanged but the Baby Spider had nearly disappeared. I was editing the wrong model! (NOTE from HH: That was a bug in Build 14! The new HAM.DSC I sended all of you has this fixed, so when you click on "Red Triangle" you are really editing the Red Triangle now!)

I went back to edit the Red Triangle this time selecting Platform Missle. I knew I had the right one because of the small amount of data. I changed three vectors in d_defp_start and in d_tmappoly I changed all of the "texture" settings to 5.

My results were that I got the right bot but it disappeared! I then changed the texture settings back to "0". The results this time were that the Red Triangle was again red, but now elongated, which is what I expected. The Red Triangle may prove to be a good test subject as it is simple. Tomorrow I will try a few other things.

Have you thought of writing a hxm editor separate from the Descent Manager. Just a thought. (Answer from HH: Hm, I think I will develop a graphical editor for this, which will be seperate from DESCMAN.EXE but can be easily called from Descent Manager selecting the data to be edited within Descent Manager)

Anyway, I'll let you know if I figure out the texture thing. (Reply from Garry Knudson: If you look in the polymodel header, there is only one texture used for this model. Increase the number of textures to something like 8 and try again.)


07/14/97 19:41 - Luke Schneider - Block meanings

Here's what I understand so far:

  • EOF Denotes the end of a block. Pretty obvious...
  • DEFPOINTS Lists all of the points (in vector form) that the polymodel (or submodel) can use for polygons.
    (Reply from Garry Knudson: true not used in any of the descent models, suggest not using.)
  • FLATPOLY Single-color polygon. Can have 3 or 4 points (numPts). CVMSNormal defines normal (for lighting I think). Points are chosen from masterlist defined in DEFPOINTS.
    (Reply from Garry Knudson: I have seen up to 12 points... I think max is ~20.)
  • TMAPPOLY Same as FLATPOLY, but adds CUVLVector to align textures.
  • SORTNORM I'm not sure about this, but it might have something to do with robot animation. I'll have to check this out a little. I'm pretty sure it doesn't affect the model directly (changing the values had no effect when viewed in Polyviewer)
    (Reply from Garry Knudson: This is really needed to draw the overlapping parts in the models in the correct order. ** Also ** Note: pmview draws the shapes in a different way than descent does. Look at your changes in descent before releasing anything... Another thing, the voodoo drivers also work differently the the base descent2 version.)
  • RODBM Never seen it yet...
    (Reply from Garry Knudson: not used in any descent models)
  • SUBCALL Used to break down models into smaller sections. Notice that simple models and weapons never use this? That's because it's used for explosions and such (probably animation too). The CVMSVector is tells us where the submodel is centered
    (Reply from Garry Knudson: will also need to break for joint animation... I haven't been able to build a model with working (and moving) joints yet.)
  • DEFP_START Didn't really pay attention to this yet. Guess it's like DEFPOINT...
    (Reply from Garry Knudson: use this instead of DEFPOINT.)
  • GLOW Hmmm :)
    (Reply from Garry Knudson: only used on pyro)

So that's my short summary. For initial editors, I believe you'd only need EOF, DEFPOINT, FLATPOLY, and TMAPPOLY (and maybe SUBCALL if you want robots that explode into pieces).


07/15/97 00:52 - Steve Klinger - Custom robot crashes

I also noticed that on my last play through, a non-edited robot appeared totally invisible before the offending bot tried to appear, of course it never made it through. I knew what the first bot was because it squealed like a pig (Vulcan Man). The poly-modified bot that caused the crash is a PEST. This happened to me once before. Other poly-modified bots also caused the crash in other experiments. My first level, the one I discovered the problem in, is quite large so I opted to send the smaller one instead. The HXM file is the same one I used in both levels. Perhaps the problem is with the HXM. This HXM is actually borrowed from The Entropy experiment with all Robot behaviors set to normal. I haven't tried any other HXM's yet.

(Reply from HH: Well, I have tested the level and it seems to be that robots with custom polygon models cannot be produced! They are just invisible (meaning TOTALLY invisible, not only cloaked) but ARE there. To see what I mean download the following experimentation level by Steve and fly into to left side towards the producer! You'll see (or not see ;-) ) what I mean... If you try the HXM with a level using that robot directly (meaning not produced), you'll see the pyro-gx... Well, there can be two reasons for this: a) it is supported to produce custom polygon models or b) the producer needs "ROBOT_JOINTS" and those are AFAIK not defined in this HXM... We'll have to do some other experimentations with this one I believe!)

Download experimentation level showing this effect (30 kB)


07/15/97 06:27 - Steve Klinger - Report #2

I've been able to replace the texture on the (formerly) Red Triangle. What I did was go to "Polygon models". Under "characteristics" I changed "First Texture" from 78 to 99. By changing some data under DEFP_START and the texture, it now looks like a stealth fighter with a strange paint job. The entire robot was changed to this new texture, but this was a small polymodel. Next I'll try a bot that consists of multiple polygons to hopefully have multiple textures on it. Perhaps in a future revision of Descman, you could substitute texture names for the numbers under "First Texture". Do you know of a source somewhere for the names of these textures to use in the interim? (Reply from HH: No, sorry, I'm searching for a list of those myself...)


07/16/97 01:00 - Luke Schneider - BSP Trees and PolyModels

I modified a Gopher (the robot) almost completely last night to come up with a new bot. The textures aren't done yet, but it definitely is far different than the original. In fact, I planned it out on paper first and created all new points from scratch. Figuring out how to get all the polygons to face the right direction was a pain... I can't remember if they use the right- or left-hand rule for calculating the facing direction. The normal (for each ..POLY) only determines lighting as far as I can tell (Garry I'm sure you knew all this before...) and I don't know what the single Vector is for.. (Reply from Garry Knudson: The normal determines if the polygon will be drawn, if polygon faces the other direction, then it doesn't draw it. The vector is the first point in the polygon. I believe it is used to test(also using the normal) to determine if the polygon is drawn.)

The textures are easy enough to calculate and figure out it would seem. I haven't really messed with them yet but I'll learn more tonight. Every other robot attribute is should be easy to calculate or enter manually (for an editor) except for...

The BSP Trees aka Sort_Norm. This seems to be the most cryptic part of the robot models. I mean, I'm sure it's not difficult once the code is in place, but getting there will be difficult unless one of you two knows a lot about this subject. Do you guys think you'll need more help in this respect? If so, who do you think we should contact? I'll be willing to ask Parallax or whoever if you guys don't feel like doing even more work (ie lobbying for help). I'm really thankful that you two are so skilled at programming (or robots might forever be the same). (Reply from Garry Knudson: I think I have a good start for a first attempt... I will try to implement so that the present planes(in the polymodel) are used to split the model.)

Anyway, I'll send you both a copy of my work once I feel like it's complete (except for the SORT_NORM values which I won't touch). Polygons disappear while playing, but everything else should be high-quality...


07/16/97 01:50 - Garry Knudson - My working model

Here is a pic of the present model that I am building... It will be the one that I play with to see if I can get the BSP tree stuff working.


07/16/97 04:04 - Garry Knudson - My working model

I have now got the texture problem fixed. At this time it has no BSP tree stuff in the polymodel, you can see what it should look like using pmview. I suggest that you look at the model in descent as well to see what the lack of the sorting data can look like...

(please don't release the model at this time...) (Reply from HH: Well, as Garry didn't want to release this here, I am trying to describe what can be seen: The robot is almost done (its the model seen above), only the textures are not all implemented (the eye for example is mission). Also the shots coem out from the body instead of the arms! The coolest (unwanted) effect is, that the body is quite transparent: In some angles you see the guns through the body... Well, here it seems to be the SORTNORM, that are needed to define, what is seen in top of the other... Below you see some pictures I took of this situation (Click on one of the thumbnails to see it in full-size!))

(I don't think the final shuttle will be gray... now that I have seen it in descent.)

I now will see if I can get the bsp tree stuff working.


07/16/97 04:37 - Luke Schneider - Morphed Gopher

The following two pictures are shots from Garry's PMView 2. That's a modified Gopher by the way, but I used textures from Vertigo (so it needs a load of that first). Anyway, I'm not too confident about cutting from an entire HAM yet, so I haven't tried (even though I could try Garry's little prog).

I've been calculating the normals in my head, although I only have the top section done. The process should speed up quickly as it's taken me a little while to get used to alignments and stuff. Note that if you have a normal of <0,1,1> instead of <0,.7,.7> that the polygon will appear extra bright. The old BSP tree hasn't affected the bot while playing (it seems to be near the right position) so I haven't seen that overlapping effect...

The bot may change a little bit in terms of texture before I'm satisfied, so I'll wait until it's complete before letting people look over it all.


07/16/97 06:53 - Steve Klinger - Report #3

Under "Polygon_Models" - Characteristics

  • n_models - Means the number of parts or submodels that the robot is made up of. You will see d_defp_start appear this many times under "Model_Data" - Characteristics for the same robot. I've verified this with 4 robots. Red Triangle (1) Class 1 Drone (3) Supervisor (4) and Vulcan Man (1).

  • submodel_ptrs - This points to submodels. It would appear that a robot can have up to 10 submodels. If n_models = 3 then you will see 3 numbers here. I don't know what there numbers mean yet.

  • submodel_offsets - I think this shows the location of the center point of each submodel. No. 1 seems to always equal 0.000,0.000,0.000. (The center of the robot).

  • n_textures - Means the number of textures this bot uses.

  • first_texture - the first texture of (n_textures). If n_textures = 3 and first_texture = 17, then the second texture would be 18 and third would be 19. But I'm not sure of this yet. (Class 1 Drone)

Under "Model_Data" - characteristics

  • d_defp_start (appears once for every submodel). num_defp_start - Number of vectors in 3d space this submodel has. Class 1 drone for example has 9 in the main submodel. Use PMView2 with Options Line/Poly unchecked to see this.

  • There appear to be 2 types of surfaces textured (d_tmappoly) and solid color (d_flatpoly). Class 1 drone main submodel has 14 surfaces, all texture mapped. Thus it has 14 d_tmappoly's. I've only explored d_tmappoly so far. In this edit box num_tmappoly means the number of textures this surface has available for use. I think this should be the same as n_texures under Polygon_Models - Characteristics. Class 1 Drone has 3 n_textures and num_tmappoly is also three. Under "texture" this number tells which texture this surface uses. Class 1 Drone has 3 n_textures so the choices are 0 - 2. In this case if 3 or above is selected the surface will be black in Pmview. So I believe if 1 is selected here the texture would be 18 (see first texture above). I'll have to check this again because my notes are a mess.

That's all I have to this point.

What I plan to try is create a submodel in AutoCad LT in 3D mode. I'd then take the vectors of this submod and transpose them onto an existing D2 polymodel with the same number of vectors. The next step would be to enter these vectors into a new or blank polymodel. Do you know how we might do this?


07/17/97 09:54 - Steve Klinger - Report #4

What follows next is an explanation of what the vector coordinates mean in d_defp_start. This will hopefully help anyone who may not understand how to interpret the x,y, and z values.

As an example, "1.234,5.678,9.012". 1.234 is the X value, 5.678 is the y value, and 9.012 is z value.

The origin of a robot should be "0.000,0.000,0.000". The origin being the starting point or center.

Viewing the robot by looking in its eyes, the X value is the left right coordinate. A negative value would be left of the origin point. Positive would indicate right. In the example above, "1.234" would appear 1.234

units to the right of the origin point of 0,0,0.

Still viewing the bot from the same vantage, a Y value would be the up/down coordinate. A negative value here would appear below the origin point. A positive value would appear above the origin. Thus "5.678" would appear 5.678 units above the center point.

From the same vantage, the Z value would be the front/back coordinate. A negative value would appear in back of the origin or away from you. Positive would appear in front of the origin or closer to you. Therefore, "9.012" would appear 9.012 units in front of the origin. However, to see this in PMView2, you would have to view it from the sides or the top or bottom.

So to sum it up, the vector "1.234,5.678,9.012" would appear 1.234 units to the right, 5.678 units above and 9.012 units in front of the origin.

To view this with a real example such as the Class 1 Drone, look at this bot in PMView2 (7/166) with the Option Line/Poly and color set to off. On the main polymodel you will see 9 vectors, (the points where the lines meet). In DM07, under Model_Data - characteristics, hi light the first occurrence if d_defp_start and hit F4. Here you will see Vectors #1 through #9. These are the coordinates of the nine vectors seen in PMView2. Change these values to change the shape of the Class 1 Drone.

I hope this is of value to anyone not familiar with 3D coordinates.

By the way, I'm in the process of turning the Class 1 Drone into a King Cobra! I need to remove/hide the guns and change the gun points to make it spit. Of course the textures will need changing also. I'll let you see it once I get a little further in it.


07/17/97 15:40 - Matthew Longworth - My discoveries so far

I have been playing with the vertecies now... I can clearly say the following: (If I am wrong, tell me!)

1: Submodels are part of the robot's explosion. All the submodels, except the first one, are flung off the robot and become debris. The first submodel is the body, and is therefore evevidently destroyed in the explosion. Now I have debris set to MAX, so this may not be the case on all machines. (Reply from HH: Correct! Additionally to that, submodels are used when producing the bot in a producer).

2: Textures for the T_MAP_POLY are a bit awkward! Now if you go over to the POLYMODEL info there are two fields - the Number of textures and the first texture. I belive that the number of textures should not excede 10 - I tried 17 and Garry Knudson's polymodel Viewer II crashed when I tried to view the model.

Suppose that the number of textures is 3. Valid textures in the T_MAP_POLY field are 0, 1 and 2. This number is then added to the 'first texture' field. Suppose it is 15. Texture 0 is 15, 1 is 16 and 2 is 17. I hope that is clear.

3: In his Polymodel Viewer, Garry Knudson did not use the same BSP system as Descent used - He used native OPEN GL ones. So although a robot may look OK in Polymodel View, parts of it may still dissappear when you put it in Descent. I had this problem.


07/19/97 01:54 - Steve Klinger - Texture numbers

Polygom_Models - Characteristics - First_Texture. This is a list used by individual polymodels. The list starts with the textures used by the first polymodel (Medium Hulk), and proceeds in order all the way up to Polymodel 166 (Flash Missile ROBOT). To explain how it is used, look under First_Texture, we see "0". Under n_textures we see "3". What this means is that this polymodel uses 3 textures starting at texture 0. Using PMView2, we look at this polymod and view Help - Polymodel Info. Here it lists the textures this PM uses (rbot010, 011, 012). Thus, texture "0" = rbot010, "1" = rbot011, etc. Polymodel 2 uses first texture "3" and n_textures "2", or textures 3 and 4. These turn out to be rbot010 and rbot 011, the same as textures 0 and 1. This is the way the list proceeds for all the polymodels ending with textures 500 and 501 for the Flash missile ROBOT.

Now in Descman under Model_data - characteristics d_tmappoly_1 - texture=(for Med. Hulk), we see "0". This is not texture "0" per se, but the first texture in a sub-group of 3 that starts at texture #0 (In this case the texture is texture #0). So for this poly, under the heading "texture=" You will see only a 0,1, or 2 for all occurrences of d_tmappoly. Selecting any other number will result in an invisible texture on that surface, where you can see entirely through the submodel. If the polygon uses 2 textures (n_textures), then "texture=" can be 0 or 1 only (unless you want an invisible portion on your 'bot).

Now, if this list is different from yours, would you want me to send you a file containing this list? (Note from HH: Steve is talking of the list, that is now downloadable from the top of the page!) I have only figured out the list for the first 100 items so far and seeing as it is a long list of 500+, I won't finish it unless you think that it would be useful to you or anyone else. If you want it just let me know and I will complete it and send it to you. It may be useful for people to see where regular wall textures are used and thereby know which textures not to replace in a POG.

What I don't know is where the list is actually located in the ham and if it can be added to in a v-ham. I know that any polymodel can use any texture subgroup in this list but this may not be convenient for brand new polys unless a person wants to duplicate the same texture as a standard polymodel.

On my Cobra bot, I've noticed in game play that the tail disappears and reappears. Could this be the same as you've seen in Garry's "shuttle craft" or a possible occurrence of the vanishing wall effect as seen in the game. I'm going to see if I can eliminate this. I have some idea's on what to try and will let you know if successful. If anyone has figured this out already please let me know.


07/19/97 18:13 - Garry Knudson - Some notes on the texture stuff...

The texture list (see link below) has the list of all the textures from the pig file. If the texture is animated, only the first texture in the animation is listed(however you can see the index number jump before the next texture...)

The texture number in the polymodel header is not directly telling which textures are used in the model. The texture number tells which pointer to go to, the pointer tells which index to go to, and the index tells the real texture to use. The texture list also comes with an index.txt file, this file lists the texture->pntr->index data for all the descent2 and vertigo robots...

BTW: I think the max textures used in any of the normal robots was 11 textures, used by one of the vertigo robots. I don't know the max that descent will allow in the game. but I think I set the pmview max to ~15.

Download Texture List by Garry Knudson (25 kB)


07/20/97 03:26 - Luke Schneider - First new robot...

The included level contains my first new robot for Descent II. It was created using Descent Manager 07 alpha (and HXMEdit 1.1 for the original HXM file). To witness the proper textures, please load the Vertigo Series first (start a NEW GAME in Vertigo, then exit out once the level starts).

The robot is a modified Gopher 'bot. The sorting normals aren't completely correct, which is why the guns of the bot don't appear correct from every angle. I had to calculate these normals in my head (there are actually three in the bot and two of them are correct, but third for the guns is not). I entered every point and normal by hand for this point, which actually adds up to a lot of manual work. Hopefully a graphical editor will arrive soon so this will be unnecessary in the future.

Anyway, enjoy the robot, but I wouldn't recommend using it in your levels. It doesn't look completely professional and uses the D2X.HAM texture index (meaning the user needs the Vertigo series to see the right textures). I might release a new version once a real editor is available...

Download "First Bot" by Luke Schneider (15 kB)


07/21/97 02:18 - Luke Schneider - HXM / V-HAM and weapons

For any new PLAYER weapons (not ROBOT) to actually be implemented, you'd need to distribute the entire Descent2.HAM. This is also true for other types of modifications to the player (like changing the ship attributes). (Reply from Garry Knudson: You can change the shape of the player ship, as well as the textures. Also you can change the same for the laser and missile shots. I think you might be able to change the size of the shots/missiles in the polymodel header file, perhaps the size is used to test for a hit. (that might only update after a reload though))

Have either of you tried adding this data to an HXM file? I'm pretty sure it won't work, but I'm just wondering. And I doubt it'd work for V-HAMs either. Anyway, I just wanted to see if there was anything you guys knew of that would allow modifications of this sort. (Reply from Garry Knudson: I think the d2x.ham adds 3 more robot weapons. Can't change the player ship but the robots can get an upgrade...)


07/21/97 02:39 - Heiko Herrmann - Bug?

(Steve Klinger found out a quite strange thing: First, after inserting my extracted polymodel into a hxm, Descent crashed. The game would play when I used a modified Descent2.ham. I tried using an unmodified polymodel inserted into a hxm but with the same results.)

Well, the thing above is a complete mystery to me! I have checked the data, Descent Manager copies into the HXM, and it is okay (meaning nothing is changed or left out!). But the following happens: (I have always copied the unmodified robots from DESCENT2.HAM and copied to a HXM, then changed the "replaced_polymodel" field to a robot, that exists in the test level! Then I checked if the robot's appearence has changed to the new one...)

a) With MEDIUM HULK everything works.

b) With MEDIUM LIFTER it is just ignored (the robot is displayed normal :-( )

c) With CLASS 1 DRONE Descent crashes when loading the level.

So, why does this happen? Has anyone of you (Garry Knudson?) an idea for this???


Reply from Luke Schneider: How do you think I got the new Gopher to work? I used exactly what you describe. BUT... After seeing it crash, I reloaded the file into HXMEdit, and examined the robot data (I think it was the wrong size but I'm not sure), I saved the file again (in HXMEdit) and everything was fine. So the workaround... Open the broken HXM in HXMEdit! Look at the robot data (you might not need to do this) Save the file...

Reply from Garry Knudson: My guess(after seeing Lukes response) is that you are not setting the *model_data field to null when you move the polymodel to the hxm format. Descent has a problem loading the polymodel data in hxm files, it doesn't release the memory in the correct way. However it will handle the null pointer, so the workaround is to zero *model_data. Hxmedit will set the *model_data pointer to zero when it saves the hxm file... (that was one of the fixes for ver 1.1). Luke had a good workaround... open the hxm file and save again using hxmedit.

Reply from John M. Aldrich: The reason I did it the way I did in HXMEdit 1.1 was because I use an exact representation of the HXM data structures in the program. I had to keep the model_data pointer because it points to the model data! :) So when I save it I keep the pointer in a temporary variable, set model_data to NULL, and then restore it once I write the data to the file. If you use a different internal format to store the data in Descent Manager, you can use whatever workaround you like.

Reply from HH: Well, then another workaraound is to set the "*MODEL_DATA" in POLYGON_MODELS of the same element to Zero (0). Thanks for your help!


07/22/97 05:16 - Steve Klinger - SORT_NORM

Build 18 with the -1 to 0 vector fix seems to work fine now. Has anyone gotten the sortnorm thing figured out yet? My project bot has a serious case of the disappearing parts phenomenon. Am I looking in the right place for a solution to this problem by playing with the values in d_tmappoly? If someone has a handle on this area could you please clue me in. I'm suffering from brain lock on this one.

By the way, Luke's robot seems to be coming along nicely. And I like the way he displayed the bot so you could give it a good look. I think I'm going to have to make a display level like his to look my own bot over.


07/23/97 00:15 - John Ratcliff - Bug in the D2 graphic engine?

I finally got to messing with the class 1 drone (with the help of that note on your page) and noticed a disappearing effect were sometimes the bot would halfway dissapear (like that dissapearing walls thread on ddl)... but what's more odd is that the level i played this class1 drone in also had a lou guard (among other bots) and some reason I noticed it had a little of this effect to! Is this just a limitation of the d2 engine or something?


07/23/97 00:30 - Steve Klinger - Wrong assignments of numbers

In the D_defp_start editor, The vectors are labeled starting with Vector #1 etc. Now in Tmappoly, the points refer to these vectors. However point number with a value of "0" refers to Vector #1. A point value of "1" refers to Vector #2, etc. I think these values and the vector numbers should match to avoid confusion. (Reply from HH: You're right! I will fix that in the next release!)


07/23/97 00:44 - John Ratcliff - Bad Bug

I was still editing that Class1 drone, except I now had it in a hxm (that worked btw). I was changing some values back to their defaults, and when I exited back (from the defstarts thing) to the model_data subsection, I accidentally scrolled up past the top. It naturally dropped down to the bottom of the list, like it should, except there wasn't anything there! I scrolled up to the top, the down, and saw that the list was to long (you saw the real list of items, then it scrolled off into infinite blankness). I tried selecting one of the blank values and nothing happened, so I quit descman.. Then later I wanted to extract the hxm from the hog it was in, but now descman crashes whenever it tries to read that hog file. I fired up hoggle (seems that yahoma don't work with the new ie4p1) and saw there was this weird new file in the hog.. looked like some garbage out of ram (ya know the type that comes up when you read to far or something) Anyhow... deleted the weird file in hoggle, and it seems the hxm was trashes but oh well.. no biggy.

(Reply from HH: Argh! Yes, this is a bad bug! It happens when you edit MODEL_DATA, then after that the POLYGON_MODEL, and then the MODEL_DATA again! I will fix this... So long: If the thing with the blank lines appears, get out of Descent Manager and restart it!! That should avoid crashing the HXM!)


07/23/97 06:54 - Steve Klinger - Disappearing polygons solution

I think I figured out how to set "vector =" and "normal" in tmappoly.

vector= ... This should be set to the vectors that Point #1 refers to. Look the vectors up in d_defp_start. If Point #1 = 5 then the coordinates are the ones beside Vector #4. (In build 18) Now the tough one.

normal= ... You have to visualize a vector centered and away from the polygon defined by the point #'s. How far away? I just took a guess. The coordinates of this point are what should be entered here. I don't yet know the optimal settings, but this has worked so far. (If we could only adjust this setting in our RL2's maybe we could take care of that disappearing wall effect.... :). Anyway back to the point. The tough part is figuring this vector in your head. Now I think I understand what Luke was saying. Can anyone figure out an equation to determine this point using a calculator? Perhaps this could be built in to the editor (with manual tweaking if needed) and entered automatically.

If anyone can add to this please do so. I'm sure there is a little more to it than what I've just described. I've also learned that Monday's are my brains day off. Tuesdays are much better :).


07/28/97 05:38 - Steve Klinger - New Problems...

Since last Tuesday I have been trying to eliminate the disappearing polygon problem on my 'bot. I thought I had this figured out but I was wrong. I have made progress though. After spending a few hours every day I have been only able to correct the normals on 10 of 14 polygons on the main polygon. I haven't even started the subs yet. Have you or anyone else figured out how the normals actually work? I've been using the trial and error method to get any results and its very slow and tedious work. But I haven't given up yet.


07/30/97 05:30 - Steve Klinger - TMapPoly

After working for a week on setting the normals in Tmappoly for my robot, I confess that I really don't understand the theory behind this stuff. I have been successful in getting most of the polygons from disappearing but I'm not quite finished. Also I'm not sure that some of the polygons can ever be totally purged of this effect. But I've found a possible way around this. By setting certain robot behaviors you can keep the robot from showing these bad sides to a player. I need to experiment with this theory some more before I elaborate.

Adjusting the normals in tmappoly are at this point totally hit and miss. What I have to do is adjust the values, load the game and examine the bot in a special level with a holding pen for the bot. I have to move my pyro to examine the bot from every possible angle. Then I have to look for results of my changes, exit the game and go back to Descman and play some more with the values. Very time consuming.

I think what we need is a graphical editor that draws the bots and textures the same way that Descent2 does, (PMView2 does it differently). The bot should be movable as it is in PMView2 so the bot can be viewed from any angle. Then have a symbol for the vector point that can be selected on screen. This point should be moved with the keyboard because the mouse can not effectively manipulate a 3d point in 3 dimensions. This way we could immediately view the results on screen saving (in my case) many days of mind numbing work. I'm sure there is some kind theory behind how this vector point causes the disappearing texture problem but I'm not going to be able to figure it out. (Sorry). I know it will be awhile yet.

Also concerning the stretching of the textures on the polygons, this is not so hard to do but an easier method might be to do it the same way as textures are stretched and adjusted in Devil. I mention this as an idea for when you get to that point in the development of the editor. If you would like me to elaborate on these idea's, just ask and I'll try to do so.

I am hoping to send you my robot possibly tomorrow. It won't be finished yet, but you can view it and put snapshots on your page if you like.

What I would like to know from you is what area's of data do you need explored right now. I could try to focus on those areas that you need more info on. I need to get away from tmappoly before I go crazy :) (Reply from HH: Well, I have not had that much time for the IDTA project in the last days, so I'm not quite within the complete thingy... Any other here, that have any ideas what is important to be explored next?)


07/31/97 05:05 - Steve Klinger - Another Report

Here is something I noticed. By adjusting sub-call vector under model_data, I was able to move the submodels in relation to the main polymodel. However the original data for subcall vector matched the data found under Sub_model offsets under Polygon models. After adjusting the values for subcall vector, the change was not reflected in submodel_offsets. Should this be changed automatically? I changed the values to match the subcall vector but there was no change when viewed from PMView2.

I've also noticed that data in model_data sortnorm matches the values found under polygon models Sub_model norms. These values may also need to match, however I have not yet adjusted either yet so I am not certain of the outcome.

The sortnorms are the first two that appear before the first occurrence of d_defp_start. Also I am referring to the Class 1 drone data. I don't know if any of this is of value to you but I thought I'd report it to you anyway.


08/07/97 10:25 - Steve Klinger - My robot

Here is my robot that I promised (a bit late). It is a Class 1 Drone modified into what I'm going to call the "Bird of Prey". It is not yet finished but people can view it if they wish. The normals are pretty much finished, but not perfect yet. I had a hard time setting them but with Garry and Luke's help, I was finally able to get them to this point. The sorting data I haven't touched yet, and at this point I may not be able to finish it until I am able to insert sortnorm data. Garry pointed this out to me so I will likely have to wait until it's possible to insert data into the model.

Notice on this model that the eyes can be seen through the back of the wings and also the guns are also visible from the back. This is the due to the sortnorm problem. Also from extreme angles there are at least two polygons that turn black. This I should be able to fix.

The level that is included is how I check my robot. It is similar to the small level that Luke made where you can view the robot from any angle undisturbed by incoming shots. It has two switches for releasing the robots to test their behavior. If anyone wants to use it as a tool, please do so. However, I would ask that people should not use the robot in levels of their own because of the bugs in it.

Also, I noticed when viewing an unmodified Class 1 Drone, that the tail section disappeared from certain angles! But when you fight this robot you would have a hard time trying to see it. This should be taken into account; some imperfections won't be noticeable.

I also have a few comments about DescMan. First a request. Could you have the color values in Type 2 Data show the R G B values. I would find this much easier to read and adjust. (Reply from HH: Will be made till next release) Second, [...]

birdprey1.jpg (57047 bytes) birdprey2.jpg (41281 bytes)

Download "Bird of Prey" (17 kB)


08/10/97 15:52 - Steve Klinger - 3D Studio

[...] Also, do you know how Parallax built the original robots? Did they use 3D Studio? I read somewhere that they used this app. I found a book in a store for 3D Studio and I looked through it. It explained what normals were and what the point should be set at. The normal should be a point that lies perpendicular to the plane extended from the center of the surface opposite of the viewing side. The reason for this is if the polygon is curved, the normal located on the inside would draw the surface with the curve pointed out. The normal located on the outside would draw it pointed in (Like a crater on the moon). I already knew this thanks to Garry and Luke's help. However, I found that on my model these points are often, but not always on the inside and not on in the center. But my polygons were all triangular. I haven't looked at the data for rectangular polygons yet, maybe this makes a difference. The original model showed similar settings. But, if 3D Studio is the program that was used originally, perhaps we could learn more about the data from a knowledgeable 3D Studio user. I did not buy the book because it was very expensive and I don't own the program so this is all I could learn from it.


09/14/97 18:22 - Garry Knudson - Robot Construction Tutorial

I have added robot construction tutorials to my webpage. These tutorials show how I made a robot using Truespace, and also show how to add the new shape into a hxm file. (not for the faint of heart...)

In these tutorials I am telling what needs to be changed, but not how to make the changes.   There is no tool at this time, that will do all the settings required to add a robot/shape. I plan to add more details to the pages later.

The Estranged Automated Terror (EAT) robot is cool.  This is the robot built in the tutorials.


  • Constructing Polymodels for Descent 2... Via Truespace
  • Moving/Adding Robots...Via a HXM file

To my homepage, containing the Tutorials


09/18/97 02:35 - Heiko Herrmann - Newer DM-HAM/HXM-Editor Build

The Build 21 of the HAM/HXM-Editor, a subpart of the Descent Manager, is out! It contains many bugfixes.


This project is now closed! We have reached our goal: making an own robot-editor - POLYTRON. Thanks for everybody who helped :). I know hope this document is of use for somebody.



All pages (C) 1996-2000 Descent Network Team
Everything taken from the Descent, FreeSpace, Red Faction and Summoner series games are
Copyright Interplay Productions , THQ Inc. , Parallax Software , Volition Inc. and/or Outrage Entertainment