[Kazan]

ok, so with full index buffer support (read: FASTER) coming up, I think that we should have the data internally setup in the propery way so you can just bitblit it into memory instead of having expensive processing when you load the model.


if an OBJ3 is detected the OBJ2 would be automatically ignored - if no OBJ3 then the OBJ2 will be used.

I will make PCS save both - and if it loads up a model missing OBJ3s you will be able to tell it to generate them

this is assuming you explain the data to me.


Here is the present OBJ2 structure - modify and propose your OBJ3 off it (most comments stripped)

Code: [Select]


struct OBJ2
{
int submodel_number;  

float radius;      
int submodel_parent;
vector offset;      

vector geometric_center;
vector bounding_box_min_point;
vector bounding_box_max_point;

string submodel_name;
string properties;
int movement_type;
        int movement_axis;


        int reserved;         // must be 0
        int bsp_data_size;  
        char *bsp_data;  

};



I am assuming you're going to want something like this

Code: [Select]


struct obj3_poly
{
         int mat_num;
         int num_points; // <= 20 [current max]
         
         //indecies
         int point_ind[MAX_VERTS];
         int norm_ind[MAX_VERTS];
         int u_ind[MAX_VERTS];
         int v_ind[MAX_VERTS];
}

struct OBJ3
{
int submodel_number;  

float radius;      
int submodel_parent;
vector offset;      

vector geometric_center;
vector bounding_box_min_point;
vector bounding_box_max_point;

string submodel_name;
string properties;
int movement_type;
        int movement_axis;


        // Points List
        int num_points;
        vector3d *points;
   
        // U list
        int num_us;
        float  *u;

        // V list
        int num_vs;
        float *v;
 
        // Norm list
        int num_norms;
        vector3d *norms;

        // polygons
        int num_polys;
        obj3_poly *polys;
};


[Bobboau]

for index buffers the big change we're going to need will be in the bsp block, the defpoints and tmappoly will need to be totaly redone, defpoints are going to need to consist of (and this is going to seem inefeshent, but this is how index buffers fork) the position, the normal, and the UV coords (I'd like to enable the posability of more than just one set), that is each one, no block of position data and another block of normals. no, if a poly is going to have one of it's points with a particular set of UV coords and the poly next to it has a point with the same position and normal but diferent UVs that is going to be two seperate defpoints, same thing with points that have the same position and UVs but diferent normals. now I supose we could cache them have a list of normals positions and UVs and make an index buffer comprised of three indecies to these lists, but I'm not sure how much that's going to save us in the long run.

[Kazan]

i was thinking about DITCHING the BSP

using a seperate collision tree (which I forgot to put in the above theorectical OBJ3 example)

so you're saying

Code: [Select]


struct uv { float u,v; };
struct point
{  
     vector3d position, normal;
     uv tex_coords[UV_TYPES];
}

struct polygon
{
    vector3d normal;
    int vertecies;
    point vertecies[MAX_VERTS];
}


that's the polygon list and then a seerate collision tree is used and it's leaf nodes index the polygons they contain

[Goober5000]

Shouldn't this be in the internal?

[Kazan]

i want as much input as possible

[Flaser]

Does the usage of a separate collision tree allow more dynamic models?

As far as I saw, the prime reason for lack of moving parts in models was the bounding box collision detection.

Does this separation change that thing?

[Kazan]

A) that doesn't make sense
B) no it's just the polydata and the collision tree are seperated indexed data - they still work the same way

[Bobboau]

if we're going to totaly ditch the BSP, I think we should spend a good bit of time trying to find something that we can use that will give us a more dynamic gometry structure.

[Kazan]

we CANNOT totally ditch BSP - compat

[Flaser]

Could U expand on that for the uninitiated ones?

Thank you for your effert.

[Kazan]

i think the code is rather self explanatory

"struct" = structure
"int" = integer
"vector" = 3 value vector (used for points and vectors)
float = floating point value


a * associated with the name means "pointer to" and is used for arrays of indeterminant size [] after a name is another way of definiting an array, but with a definite size in this case - all caps text generally means a preprecessor directive - ie something which stands for something else

like MAX_VERTS stands for a number, in this case we know it to be 20

[kasperl]

Wait a minute, is a vector a vector as in XYZ movement, or XYZ co-ordinates? If it is a coordinate set, then how is the 0,0,0 defined?

[Kazan]

a "vector" in computer memory, three floating point values can be used as both a point and a vector

it's a confusing application of the multiple definitions of vector

ie "a variable consiting of more than one piece of information" or "a variable containing magnitude of movement and direction"

0,0,0 = 0,0,0 in both cases, i fail to see what you're getting at

[Bobboau]

well if/when we switch over the geometry to a new system, I think we should go full bore, write a converter for the old system, and just totaly ditch it, otherwise I guess all we can realy do is add another type of polygon to the exsisting BSP structure.

as for how it would actualy be packaged in the chunck, we probly will need either a new version of the defpoints chunck, or modify the exsisting one seveirly. I'm thinking it would be easier to simply make a new one, it'd be fairly simple, what you'd have is:

Code: [Select]


defpointchunk{
int n_defpoints;
vertex *points;
}

I'm trying to use struct notation to describe what it'd look like in the file, wich isn't exactly perfict points is a vertex array of size n_defpoints, the vertex defenition shall be modifyed to include a normal, wich it realy should already have, if you look our vertex class is _realy_ ugly, thinking about it more, we should probly make up a new vertex class for this specific situation, wich would basicly be what you posted

Code: [Select]


struct defpoint{
vector pos;
uv_pair uv;
vector norm;
};


and use that as the array of size n_defpoints.

ok, that could basicly be read from directly by the polys (this would only be done during colision ditection, we'd set pointer to a defpoint to the points array from the defpoint chunk and read directly from it as it's already in memory)

the polygon structure, I guess we could call them "tmap_htl"s would consist primaraly of an int array, there would though be things like a bounding box or center point and radius, poly normal, one thing I would realy like to have is offsets to all neboring polys, this would spead decal creation up __massively__
/*goes off on decal system tangent*/ as currently I basicly have to rework the entier colision ditection on a per poly basis, though I am useing the exsisting BSP tree to (I beleive) it's fullest potential, part of the culling proces involves finding the closest point on a polygon to the decal (wich is extreemly procesor intinsive as you find a point on the polys plane thin if it isn't on the poly you have to go on an edge by edge basis and find the point closest to that) and seeing if it's in the decal (wich involves rotateing it into the decals space), the actual creation of the decal polys is very quick, I just set the UV's acording to there distance from two of the clipping planes and copy them to the decal.
/*back on topic*/

Code: [Select]


struct tmap_htl{
vector center; // center of poly
vector norm; //the normal of the poly
float rad; //radius of the poly (distance of the furthest point from the center)
int tmap; wich texture/material of the model's textures/materials is this poly useing (I still want that material system)
... //anything else we come up with :)
int n_points; //number of points in this poly
int *points; //points[n_points], these are indecies into the defpoints chunck
int *neighbor;//neighbor[n_points], neighbor[N] == the offset to the polygon shareing edge defined by points (N,(N+1)%n_points)
}


I think it would be ok to have these organised by a sort of octant system, rather than a full BSP, as the only thing the BSP (the real BSP with the sortnorms and crap) was used for was in the now obsoleate rendering code, colision ditection only uses the bounding boxes

[Kazan]

meh.. look closer at the BSP DEFPOINTS specs you're confusing constructors

Code: [Select]


struct vertdata
{
vector vertex;
vector *norms;
};

struct BSP_DefPoints // 1 - Defines Verticies
{
BSP_BlockHeader head; //8 |8
int n_verts; //4 |12
int n_norms; //4 |16
int offset; //4 |20 |from start of chunk to vertex data
unsigned char *norm_counts; //n_norms |20+n_norms |n_verts in size;
// DM: I don't know WTF data size/format the vertex data is in.. so im GUESSING it's vertex point followed by vertex norms
    // DM: Ok after staring at that insanely bad code written by Knudson i finally made sense of it.. and YES im correct :)
vertdata *vertex_data; //Equasion |20+n_norms+Equasion
//char *vertex_data // at startofmemory+BSP::DefPoints.offset; Each vertex n is a point followed by norm_counts[n] normals.

//---------------------------------------
BSP_DefPoints() { memset(this, 0, sizeof(BSP_DefPoints)); }
int Read(char *buffer, BSP_BlockHeader hdr);
int Write(char *buffer);
int MySize();
void Destroy();
};



im advocating DITCHING the BSP entirely for a polygon list and a bouding box tree