[Bobboau]

figured it wouldn't be a bad time for us to start considering this, new object chunk data specifications.

here is what I think would be good.
first off the basic OBJ2 isn't bad for the most part, in the upper levels I wouldn't change much, the biggest two additions I can see would be the addition of an orientation matrix and an index to another OBJ3 chunk that holds the identical geometry data. these two together would allow a significant improvement in the number of vertex and index buffers required in game, or if we should chose to make the move to shared buffers it would make the resultant buffers smaller, that's not as significant of an improvement, but it's still better than what we would have otherwise.

in addition we could add binary animation data, if it is locked inside the model then the model editing program would be able to make nesisary adjustments to parent bounding boxes to ensure proper colision detection (especaly important if we ever implement transitional animation)

these specs are the less than obvius portions, I will omit things like chunk identifiers and sizes

OBJ3 spec

Code: [Select]

float radius
int parent
vector offset
vector min_box
vector max_box
string name
string properties
int movement_type
int movement_axis
int geometry_owner
//other subobject that has my geometry, -1 if I own my own geometry
int BSP_size
//0 if I don't have my own geometry
void BSP_data[BSP_size]
//will elaborate later

matrix orientation
//the orientation of this object in it's nutral resting position

I formed that so it would not break backwards compatibility with the existing code, geometry_owner is in an unused block of space and orientation would only be read in if the chunk id was OBJ3. if you look at the pof specs, there is very little diference, the big changes come in the BSP specification.

BSP chunk order

Code: [Select]

defpoints
polys
tree

unlike the existing BSP chunk the new one will have it's data a little more organized, raw poly data will be accessible without a need for running through the tree. I've considered breaking the BSP tree into two, a true BSP tree and an octree, but I'm not sure if that would offer much advantage, for the moment I'm going to stick with one BSP\octree. one of the reasons I'm thinking a single tree would be better is due to the addition of detail control into the tree, I want to import the exsisting detail box and sphere feature into the BSP structure, this will allow the polychoping benefits of the detail feature without incuring the multable subobject penalty. the existing detail box code should remain unchanged to allow animated objects and destroyable subsystems the option of only being drawn when near them. the basic idea, is that the first few steps in the BSP tree will be sorting through detail data, the child nodes of the detail reigons will be full trees similar to how data is now, but it will be in the same. the ingame implementation would read through these subtrees and construct an index buffer out of them, the vertex buffer would remain static always.

below is a visual aid for understanding the detail region's place in the BSP tree, detail boxes (red D's in boxes) should only exist near the root, this is because each detail region has as children either more detail regions or the root sortnorm of a BSP tree (green S's in circles), and the leaf geometry nodes of these diferent BSP trees will not be in sorted order, however it can be assumed that detail geometry will more or less be on top of it's parent's geometry from a visual point of view. note it is not a coincidence that I have as the first children the BSP subtrees, this is to ensure the parent->child rendering order.


so in addition to the existing node types, of the sortnorm bounding box and tmappoly, there will be two new detail region nodes:

detail box

Code: [Select]


vector min
vector max
int type //-1 render when out, 1 render when in
int offset //to consectutive child nodes

detail sphere

Code: [Select]

float radius
vector pnt
int type
int offset

in addition we might as well revamp the sort norm chunk and strip out some usless stuff

sortnorm

Code: [Select]

vector norm
vector pnt

int front_list
int on_list
int back_list

vector min
vector max


now we've gotten into the very interesting part, the geometry as I mentioned earlier poly data is now seperate from the BSP tree, were polies once were we will now have references to polies, in the form of poly lists. it's a simple enough idea you would simply have the number of polys in the list (rarely will be more than 5, oftine will be just 1 or 2), an index to which vertex type all polygons in the list will use (I'll explain this in a minute) and n_poly*3 ints or shorts (depending on how big the vertex buffer is), for this last bit we will probly have to define two separate poly list nodes.

poly list

Code: [Select]

int n_poly
int vertex_idx
int polys[n_poly]//reference to the poly list
int/short tri_list[n_poly][3]

before I get to the polygon definition I need to cover that vertex type thingy I mentioned. there are a number of different vertex data options available in OGL (and D3D) but they are not always used for all situations, so if a model is not going to need lighting data it's waistfull to send it off, some models in the future may have multable sets of UV coordanants in multable dimentions, I think it's best to leave the exact vertex format undefined and have it specified via flags, what sort of data is preasent, there already exsists in FSO code for handeling this in this exact way, no code in game realy needs to know what the hell is going on within the vertex buffer. now of course you must be thinking to yourself 'colision detection? those decals you've tried half a doesen times to implement? a thousand other bits of code that use the raw geometry?' well these bits of code only use the position of the vert and the polygon normal so as long as we can still find this information out this code should be relitively unharmed. so in addition to the graphic verts there will be a seperate list of vectors which will be nothing but the position of each vert. now into details, there needs to be the ability to specify more than one class of grverts, so in the defpoints you will have sevral lists of vertex data, and a single list of vertex point data.

defpoint

Code: [Select]

int n_cpoints
vector cpoints[cpoints]
int n_vertex_types
for(n_vertex_types){
int format
int n_gpoints//there is, or should be, code for finding the size of a vertex of a given format
void gpoints[n_gpoints*gpoint_size]
}

with this we can construct vertex buffers simply by passing the raw buffer to the abstraction layer code.

now finaly, polygons. the basic form of the polygon I don't plan on changeing too radicaly, but there will need to be an additional index for the vertex type. also I think there should be an additional radius added, one such that if you are within the radius and intersect the plane then you are defninately hitting the polygon, this I think could vastly speed up colision detection, because otherwise you have to project the vertex onto the plane of the polygon and do a very expensive test to see if the hit point is outside the poly.
but to me the most important change will be the addition of neighbor data, there needs to be a way to figure out which polygons are nearby, this information is extremely important to getting a fast decal and shadow code working, and could posably be used to speed up colision detection. the way I see it  every polygon can have either one or no neighbor along each edge, and each edge is comprised of one point and the next point, so the n'th neighbor should be the one which shares point n and n+1, and obviusly there would be as many neighbors as there are points in the polygon (if you include the potential -1 null references to nobody).

polygon definition

Code: [Select]

vector norm
vector center
float max_radius // if you are outside this you are definately not hitting
float min radius // if you intersect the plane and are within this radius you definately are hitting
//alternatively we could try to use a bouning box
int vertex_type
int n_vertex
for(n_vertex){
int c_idx//index to the colision vert
int g_idx//index to graphic vertex (might not be needed as these are in the poly list in triangulated form already)
int neighbor//index to another poly that uses point n and point n+1
}
well that's my thoughts on it, anyone else whant to comment?

[Vasudan Admiral]

Well I don't really understand what things like sortnorms and buffers and stuff are (I do intend to find out though - any hints?), but the detail box stuff looks very interesting.
Am I understanding it correctly that it would allow you to define detail boxes for chunks of geometry as you can now, yet still have those chunks read as part of the one object by the game?

Also, something I was been thinking about a while ago might be good to bring up here: (Sorry if this is unrelated to what you're talking about - I *think* it might apply, but I'm just not sure)

About the collision detection calculations, it might be good to be able to control more of how the model collides through the subobject properties section in each POF. Here's basically what I mean:

- Something along the lines of $CollisionLOD: X where the object will always use it's equivalent LOD X object for the collision detection, while displaying itself as normal. Having it definable would allow the modeler to pick out where that was and was not a good idea. Fighters for example could have it applied to their whole LOD 0 hulls, because you're probably not going to be able to tell the difference.

- $NoCollide would exclude that associated subobject completely from any sort of detection, though I don't really know if it should then propogate to all subobjects or not - could get a *little* tricky there. This would be very useful for cockpits, parts of a model that you know will never collide with anything, or for parts that are actually for effects (ie, an invisible set of polys that you want to apply an animated effect glowmap to)

If these could be applied in the same way I think you're talking about applying detail boxes, might it have some reasonably big efficiency boosts in places?

[Bobboau]

"Am I understanding it correctly that it would allow you to define detail boxes for chunks of geometry as you can now, yet still have those chunks read as part of the one object by the game?"

yes, thats exactly what I'm going for with this.

it might be a good idea to be able to flag some geometry as non-colideing, especaly detail geometry (I was actualy thinking all geometry not in the base tree would be excluded from colision detection.)

[Vasudan Admiral]

Oh, err, what's the base tree actually referring to then? I've been assuming it was pretty much the submodel hierarchy. :\

On that note, do you know of any places that explain the concepts being dealt with here? It's intriguing, but frustratingly just-out-of-reach.

[Bobboau]

I sort of worded that poorly, it would basically be the geometry not held in a detail region. in my picture that would be the topmost green S. I'm assuming the typical (probably only) implementation would have only one tree, but the pof BSP setup allows for as many child nodes as you could want so technically you could have more than one tree in the typical thinking of the concept, so base tree realy isn't a very good way of describing it actualy, base geometry would have probly a been better choice of words.

[Col. Fishguts]

How did you write so much text with so few spelling errors ?

[Bobboau]

firefox has a built in spell checker.

[Nuke]

sence you guys are updating pof specs. any chance for a chunk for advanced turrets? sence you seem to be having some difficulty with your turret code, mainly in upgrading them while maintaining reverse compatability. anyway id want to include the following features:

support for at least 4 submodels in any heirarchial configuration (children inherit parent motion).
up to 2 axes of motion per object (to make things like single part gimbal guns possible)
support for principal and arbitrary axes
support for multiple banks
organized gunpoints which may be grouped independantly by bank and/or parent (inherit motion)
in-pof animation code features (with triggers such tracking (tracks target vector along axis(es) by rate), firing, reloading, ect)
and a few other tweaks i havent thought about

basicly a rewrite of the turret code based on your modifications + a ton of new features. old style turrets remain in place and so it wouldnt affect reverse compatability goals. it would be sorta tree like. you would select the highest level parent subobject (the one containing all other geometry for that turret). the pcs interface would show the options for each piece and display the motion inheritance based on the model heirarchy. then it would also store options for each part of the turret. mainly an axis def, gunpoints, all vectors maybe a center offset (so you can do things like animate recoils). then youd define motion for that object, to you want it to track the target's position, its lead, or do you want to use that piece for an animation. you could probibly do a drop down for this and store it as a string/int. and then other options could be stored in various other data types. you could probibly use this format: rotate for (tracking pos, tracking lead, firing, reloading, ect) by (amount) and (amount2) at (rate). this config is good cause you can discribe the motion for all animation modes using the same set of vars. for tracking modes, amount and amount2 can be the arc range of the axis and rate the speed of rotation, for reload and firing anis rate would mean the same. a recoil or breaching animation would go to the first amount and then to the second at the rate specified. reload would use rate for the whole animation, while firing would snap to the first number and slowly return to the second. for something like gatling turrets you could set the first amount to 0 (meaning dont snap anywhere) and add the second amount to it.

so the chuunk would look something like this

turret
name (str)
numbanks (int) (number of distinct banks in this turret)
parent sobj (int) (submodel num)
|-child sobj 1 (int) (submodel num)
--|-pivot offset (vec)
--|-axes (vec)
--|-bankref (int) (what bank this point is in)
----|-gunpoints (vec)
----|-gunpoints (vec)
--|-motion (motion object/struct)
----|-type (str/int)
----|-amt1 (float)
----|-amt2 (float)
----|-rate (float)
|-child 2
--|-pivot offset (vec)
--|-axes (vec)
--|-bankref (int) (what bank this point is in)
----|-gunpoints (vec)
--|-motion (motion object/struct)
----|-type (str/int)
----|-amt1 (float)
----|-amt2 (float)
----|-rate (float)
--|-child 3
----|-pivot offset (vec)
----|-axes (vec)
----|-bankref (int) (what bank this point is in)
------|-gunpoints (vec)
------|-gunpoints (vec)
----|-motion (motion object/struct)
------|-type (str/int)
------|-amt1 (float)
------|-amt2 (float)
------|-rate (float)

im sure i left some stuff out, oh and i think this ssetup eliminates the need for any sobj properties changes. so a atrt chunk will work by itself. then theres the engine side :shudder:

[Kazan]

this really belongs in an SCP forum

[Bobboau]

yeah well I didn't want to invoke anyone's wrath there, I've been harping on this sort of stuff for a few years now.

[Kazan]

speaking of this.. tolwyn tells me that shield meshes on capships cause huge slowdowns.. he said that you said it had something to do with collision detection...

no BSP tree on the shield meshes?

[Bobboau]

nope. it simply uses octants. you thinking about upgrading that.

[Kazan]

i could use PCS2's BSP tree generator to generate a tree on the mesh, and then make a new chunk SLDC "Shield Collision" so we can have a mesh for the shield collisions

doesn't have to be that fancy either - just recursive bounding boxes (no need to worry about sortnorm vs bbox) w/ leaf node lists of polygons (Basically the tree we generate in memory just recorded into the POF with polygon #s corresponding to shield poly #s)

[Kazan]

basically what i'm thinking for SLDC would be

Code: [Select]

struct SLDC_node_head
{
     char type; // 0 = SPLIT, 1 = LEAF/polylist
     unsigned int size; // size
}

struct SLDC_node_split
{
    SLDC_node_head header;
    vector3d bound_min;
    vector3d bound_max;
    unsigned int front_offset;
    unsigned int back_offset;
}

struct SLDC_node_leaf
{
    SLDC_node_head header;
    vector3d bound_min;
    vector3d bound_max;
    unsigned int num_polygons
    unsigned int *shld_polys; // = new int[num_polygons]
}

struct SLDC
{
      unsigned int tree_size;
      char *tree_data; // = new char[tree_size]
};

no tail recursion, recursion only happens on front/backoffset

[Bobboau]

I'm assuming the neighbor data is still maintained int the list of shield polies.

[Kazan]

yup - this chunk if for use in conjunction with the existing SHLD chunk

[Bobboau]

so, it would be an ADDITIONAL chunk? hmmm.... that could be interesting to implement in FSO.

[Kazan]

all FSO would have to do is

if (sldc is present)
    use sldc for collision test
else
   use legacy for collision test

this way we don't have to break reverse compatibility of the models

[Kazan]

SLDC chunk is now being written by PCS2

[Kazan]

oh bob... as for collision detection/polylist in OBJ3 .. i think we should use index/vertex buffers instead of the BSP - and the collision tree i just made for SLDC can easily be used for collisions into an index/vertex buffer set