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
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
- On layer "Blocks" choose the block to which an
element should be added.
- On layer "Elements" simply press "Add
- You will be prompted for the filename (sorry, no browser
- 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
- 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
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
C:\GAMES\DESCENT2> ARJ E V:\D2DATA\DESCENT2.SOW DESCENT2.HAM
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
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
(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" -
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
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
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
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
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
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
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
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
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
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, [...]
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
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.