[tigital]

me again...

I'm plugging along with the byteswapping for model loading, but have come to a "blackbox" that needs some illumintation:  pm->submodel[n].bsp_data

...this data is referred to differently by different functions, and info is pulled out of it via offsets to the original pointer (ex. p+4, p+20, p+offset)...Is there any documentation of this data beyond the notes in modeloctant, modelcollide, and modelInterp?

Or, would anyone be able to send me a text file of the octant values read out in modeloctant for "fighter2t-02.pof", which is read in before mission selection?  In particular, I'm looking for vert values (src, Interp_verts[n]) and "normcount"...

tanx

[Bobboau]

it's a bunch of diferen't values of an asortment of diferent types in no particular order (ie not a structure), front list is the list of polygons in front of the current sort norm, back list is the list of polgons currently on the back of the current sortnorm, on list is a list of all the polygons that get's intersected by the current sortnorm, I have no idea what the pre and post lists are for

getting the data you need is a bit confuseing at first but after a bit of playing with it it comes as second nature.

what exactly do you need to know, XYZ of the verts, there index number, wich polygons use wich verts?

[tigital]

confusing, I'd agree!

I'm trying to figure out a way to byteswap the bsp_data at model_load, so that it doesn't need to be done when there's rendering going on...but like ya say, it seems to be a mess of different things...

so I started out by calling "model_octant_create", which seems to cause a cascade of interpretations/interpolations of the loaded bsp_data:  I figured that if I did byte swapping as different bits were pulled out of the bsp_data, then the model loaded in memory would be ok for use...but that doesn't seem to be the case...

does this sound like a good strategy?

as far as data I'm looking for, I could use maybe the first two and last two data's of the vert.u, vert.v, src->xyz.x,y,&z, Interp_vert[0], Interp_vert[1], and normcount, so that I can see if I'm getting anything in the ballpark...

tanx!

[tigital]

hey,

...I just noticed that model_octant_find_faces calls model_octant_find_faces_sub twice: first with just_count = 1, then with just_count =0...

...does this suggest that I just do byte swapping in the second pass?

[Bobboau]

what you need to do is build an interpeter, look at model colide for  the simpler one

Code: [Select]

int bsp_sub(void *model_ptr )
{
ubyte *p = (ubyte *)model_ptr;
int chunk_type, chunk_size;

chunk_type = w(p);
chunk_size = w(p+4);

while (chunk_type != OP_EOF) {

// mprintf(( "Processing chunk type %d, len=%d\n", chunk_type, chunk_size ));

switch (chunk_type) {
case OP_EOF: return 1;
case OP_DEFPOINTS: make_defpoints(p); break;
case OP_FLATPOLY: make_flatpoly(p); break;
case OP_TMAPPOLY: make_tmappoly(p); break;
case OP_SORTNORM: make_sortnorm(p); break;
case OP_BOUNDBOX: break;
default:
mprintf(( "Bad chunk type %d, len=%d in model_collide_sub\n", chunk_type, chunk_size ));
Int3(); // Bad chunk type!
return 0;
}
p += chunk_size;
chunk_type = w(p);
chunk_size = w(p+4);
}
return 1;
}


that will go through the data in the bsp data and send it to the apropriate chunk prosecing function. the first thing that needs to be done is the defpoints get copied to a global list of vectors, or something

// Point list
// +0      int         id
// +4      int         size
these first two you won't need in here
// +8      int         n_verts
the total number of verts there will be
// +12     int         n_norms
the number of normals
// +16     int         offset from start of chunk to vertex data
// +20     n_verts*char    norm_counts
the number of normals that are asosiated with this vertex, this is an array for all the verts
// +offset             vertex data. Each vertex n is a point followed by norm_counts[n] normals.    
the vertex followed by a number of normals, the number of normals is defined in that array of normals that was loaded just before this chunk

Code: [Select]

void make_defpoints(ubyte * p)
{
int n, a;
int nverts = w(p+8);
int offset = w(p+16);

ubyte * normcount = p+20;//normal array
vector *src = vp(p+offset);//start of vert data

Assert( nverts < MAX_POLYGON_VECS );

for (n=0; n {//for each vert
global_point_list[n] = src;
src ++;
for(a=0; normcount[n]){//for each normal in each vert
global_normal_list[n /*wich vert these go to*/ ][a /*wich normal this is*/]
src ++;
}
}
}


now you need something that will handel the sortnorm data, this can be as simple as this, it will go through all branches of the BSP tree

Code: [Select]

void make_sortnorm(ubyte * p)
{
// mprintf(("entering decal_create_sortnorm\n"));
int frontlist = dw(p+36);
int backlist = dw(p+40);
int prelist = dw(p+44);
int postlist = dw(p+48);
int onlist = dw(p+52);

if (prelist) decal_create_sub(p+prelist);
if (backlist) decal_create_sub(p+backlist);
if (onlist) decal_create_sub(p+onlist);
if (frontlist) decal_create_sub(p+frontlist);
if (postlist) decal_create_sub(p+postlist);
}


now the super duper fun part, the tMapped polys

// Textured Poly
// +0      int         id
// +4      int         size
again, you don't need these
// +8      vector      normal
the face normal, only used for backface culling
// +20     vector      normal_point
I beleve this is the center of the face
// +32     int         tmp = 0
I'm not sure what this is, but I think it's like a face radius or something
// +36     int         nverts
the number of points used to make this face
// +40     int         tmap_num
the texture number used on this face
// +44     nverts*(model_tmap_vert) vertlist (n,u,v)
a pointer to a model_tmap_vert structure

Code: [Select]

void make_tmappoly(ubyte * p)
{
int i;
int nv;
uv_pair uvlist[TMAP_MAX_VERTS];
vector * points[TMAP_MAX_VERTS];
model_tmap_vert *verts;
vector normal[TMAP_MAX_VERTS]

nv = w(p+36); //the number of verts in this poly
if ( nv < 0 ) return;

int tmap_num = w(p+40); //the texture used

verts = (model_tmap_vert *)(p+44); //fill out the model_tmap_vert structure array for this poly

for (i=0;i {
points[i] = global_point_list[verts[i].vertnum];

//note verts[i] is a vert on the model_tmap_vert structure array vertnum is an index to the global_point_list

uvlist[i].u = verts[i].u;
uvlist[i].v = verts[i].v;

normal[i] = global_normal_list[verts[i].normnum];

}

}

that will give you a poly in the form of
points[nv]
uvlist[nv]
normal[nv]
all the data you'd ever need to make a gaorud shaded texture mapped polygon
if you can make you're own interpeter it'll be easy to get the other two chuncks that aren't realy needed (becase I don't think there are any flat polies and the bounding box is only usefull not needed, depending on what are you doing with it)

NOTE: I have not actualy tested this code!

[tigital]

thanks for the info!

...it basically confirmed what I had already been working on, which was based on the model_octant parsing code....the good news is, I think I have the octant's loading correctly (no points with e-39!)...

...I've now moved on further in the program, and I think the model_interp parsing code needs to have norms swapped...so it's time to figure out the best place to do that...

here's a question:  it seems as though model_octant parsing only happens on model_load, and I assume that model_collide stuff happens all the time during a game...but what about model_interp stuff?  is it more "load-only", or is something called all the time?

...on another subject, I got sound working this weekend!  I thought I'd covered it before, but the bitspersample was coming out incorrectly, and now I can hear button selections and doors opening and stuff...

[Bobboau]

model interp is used all the time, it is actualy what is used to render the models, and is the reason for the data to be in this format, it's a BSP tree after all , I don't think throwing this into a data structure will make it render faster though

[Kazan]

there is an interpreter for the POF IDTA/BSP data in POF Constructor Suite - interpretering into and interpreting from

you know i my program has to be able to speak it to make it

[tigital]

thanks for the info re:POF constructor, but it seems more confusing to me than the source code!

I think I'm doing really good as is now, but still can't get past a ship_render crash;  the problem seems to be with submodel[6] of fighter2t-02.pof, which is "thruster06a"...I can tell that it's bsp_data is still not swapped, but I can't find out why it isn't and the other thruster's seem to be...here's some relevent output from my debug log:

General: Loading model 'fighter2t-02.pof'

MALLOC: src/model/modelread.cpp:2063 5424 bytes

General: Processing chunk , len = 96

General: Processing chunk , len = 492

MALLOC: src/model/modelread.cpp:1309 14148 bytes

MALLOC: src/model/modelread.cpp:1401 440 bytes

General: Processing chunk , len = 99296

General: Subobj 0, offs = 0.0, 0.0, 0.0

MALLOC: src/model/modelread.cpp:1515 99200 bytes

General: Submodel 0, name 'herca', parent = -1

General: Processing chunk , len = 3244

General: Subobj 1, offs = -1.9, 4.4, -1.2

MALLOC: src/model/modelread.cpp:1515 3144 bytes

General: Submodel 1, name 'thruster01a', parent = 0

General: Processing chunk , len = 3928

General: Subobj 2, offs = -2.2, 1.2, -6.8

MALLOC: src/model/modelread.cpp:1515 3828 bytes

General: Submodel 2, name 'thruster02a', parent = 0

General: Processing chunk , len = 3244

General: Subobj 3, offs = 1.9, 4.4, -1.2

MALLOC: src/model/modelread.cpp:1515 3144 bytes

General: Submodel 3, name 'thruster03a', parent = 0

General: Processing chunk , len = 3708

General: Subobj 4, offs = 2.1, 1.2, -6.8

MALLOC: src/model/modelread.cpp:1515 3608 bytes

General: Submodel 4, name 'thruster04a', parent = 0

General: Processing chunk , len = 3244

General: Subobj 5, offs = -2.6, -1.0, -0.8

MALLOC: src/model/modelread.cpp:1515 3144 bytes

General: Submodel 5, name 'thruster05a', parent = 0

General: Processing chunk , len = 3092

General: Subobj 6, offs = 2.5, -1.0, -0.8

MALLOC: src/model/modelread.cpp:1515 2992 bytes

General: Submodel 6, name 'thruster06a', parent = 0

General: Processing chunk , len = 68432

General: Subobj 7, offs = 0.0, 0.0, 0.0

MALLOC: src/model/modelread.cpp:1515 68336 bytes

General: Submodel 7, name 'hercb', parent = -1

General: Processing chunk , len = 3244

General: Subobj 8, offs = -1.9, 4.4, -1.2

MALLOC: src/model/modelread.cpp:1515 3144 bytes

...as you can see, submodel 7 is much larger (68336 bytes) than the other thruster submodels (which are around 3100 bytes):  do these numbers look correct?

Again, my strategy has been to do a swap in the first call to model_octant_create(), to which I've added several "swap_*" functions that are only called the first go through...they also have incorporated loops from model_interp parsing, plus some stuff I've thought necessary...

fr'instance, model_octant_find_faces() only loads pm->detail[0] submodels, which usually seems to be zero:  I put in a for loop to go through pm->submodel[n_models].bsp_data the first time...

unfortunately, I'm officially stuck!  Any help would be greatly appreciated!  This particular crash has been my endpoint since I started fooling with the model_load swapping, so something still isn't there, and I'm not seeing it...

;-P

[Bobboau]

umm, submodel 7 is the LOD1 main hull

Code: [Select]


General: Processing chunk , len = 68432

General: Subobj 7, offs = 0.0, 0.0, 0.0

MALLOC: src/model/modelread.cpp:1515 68336 bytes

General: Submodel 7, name '[b]hercb[/b]', parent = -1

see
look in model view if you don't beleve me
and it looks like submodel 8 is were you're crashing

a bit of further looking (useing POF d-view, available for D-Net) the sizes of the data chuncks look a bit off, might be nothing, you might have a diferent version of the file or D-Veiw might be screwed up, or the debug spew might not include the ID and size bytes or something
well there is no paturn to the diferences, so..

you might want to include data about what is in the chunks as well, mainly haveing an entry for every t_mappoly, and sortnorm within every obj2,
yes that will be a lot of debug spewing

[Kazan]

um.. my code harder to read than the volition code? hahahahah *dies laughing*

try opening up the files starting with "BSP" when you're looking at BSP data stuff, and "POF" when you're looking at general pof stuff (COBConversion (COB->POF) includes some BSP code - just translating COB structs into BSP structs, POFRenderer contains a parser for dealing with BSP code without unpacking it)

[tigital]

hi kazan,

...um, what I meant about "hard to read code" was only referring to your use of classes and stuff:  I'm a c++ beginner ;-(  I know a little bit, but get lost easily; that's why the volition code seems more straightforward...uh, that is, after ya spend millions of hours trying to understand what it's actually doing...hehehe

bobboau:  I'm using the demo .pof files, so maybe that's why we get different sizes?  Also, what is d-view/d-net?  I'm beginning to realize I might need to install virtual pc in order to use some of these programs to get this port done...and ya should know that the crash was happening a bit later:  I just cut and pasted some output I was curious about...

...oh, and I've decided to go ahead and start a-new, with bsp_data swapping at the point of loading...which is how I shoulda done it from the beginning, I suppose...

[Bobboau]

D-Net
D-view
other tools

[tigital]

...well, one thing I've learned in this project is not to be afraid to scrap your first thought!  After moving the bsp_data parsing/swap stuff from model_create_octant() to where it's actually first being loaded, I'm now seeing the models and stuff!  Very exciting!

I apparently don't have the ability to post a picture here, but here's a link:

http://homepage.mac.com/tigital/PhotoAlbum3.html

...this is running in heavy debug mode, so that's why it's only getting about 15 fps...guess it's time to find an actual copy of freespace2!

a coupla questions:  the sounds are working (I can hear clicks when buttons are rolled over, I can hear the instructor's voice), but the ambiant wave sounds weird:  is the beginning background sound supposed to be some kind of white noise?

also, I'd like to start incorporating stuff from the non-icculus code:  has much been done with opengl, or is it mostly directX/3d?

Any suggestions on mods to try?  I've got a full copy of freespace great war/silent threat, so maybe I'll look into incorporating support for that...

thanks guys for the help!

[tigital]

hiya...

...well, got around to moving all of the byteswapping to model_read(), and now I'm up to about 45-50 fps with -O0 (I'm using a 667MHz G4 tiBook w/radeon mobility, and the game is in a 640x480 window):  what are other people getting?

I do have one weird problem:  I can fire my primary laser weapons, but they do now damage!?!  The weird thing is that I can fire the secondary rockets, and they do damage, no prob...any ideas on where to look for this?

Also could use answers to some of the above posted questions...

tanx!

[Bobboau]

we have a new DX and OGL renderer for both
not sure on much of you're questions,

what was you're FPS before you made the changes

I sudgest you find a copy of full FS2 otherwise you're likly to have problems.

[Darkage]

Is this about burgerking?