You might know that the DRIVING, DRIVING2, SHOOTING and BIPLANE examples from SGL all use a similar method for handling polygon display:
The 3D world consists of a 2D map of polygons and a corresponding map of collision data.
Now I made a tool which converts arbitrary (amounts of)PDATA and XPDATA structures like
to such a 2D map of polygon data.
Being the last tool in the chain, it overcomes size restrictions
that the 3DEditor of SS-SDK for Win95 got.
Conversion is influenced by some options,
such that it can break objects apart at tile boundaries and
merge them together to one inside a tile.
Removal of duplicate points and polygons is partially implemented and will be expanded soon.
Furthermore, I added the possibility to verify the converted data to the original.
Here is the original DRIVING .MDL data together
with 4 different verified and compilable(but DRIVING would need little modification for type MapData) conversions with my tool.
[attachmentid=1073]
Meaning of the filename suffix:
first number is option break_over_tiles,
second is merge_in_tile
The current map format is:
It is superior to that of the DRIVING example, since it allows multiple objects inside a tile, such that (real time gouraud) XPDATA can be mixed with normal PDATA.
The collision system of those examples instead is not fully clear to me. :huh
I've read some stuff about collision detection,
but it lacks explicit formulas like the book
"Real-Time rendering" got(which I don't have anymore).
It might help if someone else would have a look at the DRIVING source,
especially Collison_put(FIXED x,FIXED y,FIXED z) and tell me what you thing about the those lines:
Any information about ground following(keeping the car flat on the track) would be appreciated, too.
I intent to generate collision info with the tool in the future.
For example the track could be seperated from the rest by texture ids...
The 3D world consists of a 2D map of polygons and a corresponding map of collision data.
Now I made a tool which converts arbitrary (amounts of)PDATA and XPDATA structures like
Code:
POINT point_BOX[]={
POStoFIXED( -16.00, 16.00, -16.00),
POStoFIXED( -16.00, 16.00, 16.00),
POStoFIXED( 16.00, 16.00, 16.00),
POStoFIXED( 16.00, 16.00, -16.00),
POStoFIXED( -16.00, -16.00, 16.00),
POStoFIXED( 16.00, -16.00, 16.00),
POStoFIXED( -16.00, -16.00, -16.00),
POStoFIXED( 16.00, -16.00, -16.00),
};
POLYGON polygon_BOX[]={
NORMAL( 0, 50, 0), VERTICES( 0, 1, 2, 3),
NORMAL( 0, 0, 50), VERTICES( 1, 4, 5, 2),
NORMAL( 0, -50, 0), VERTICES( 4, 6, 7, 5),
NORMAL( 0, 0, -50), VERTICES( 6, 0, 3, 7),
NORMAL( 50, 0, 0), VERTICES( 3, 2, 5, 7),
NORMAL( -50, 0, 0), VERTICES( 1, 0, 6, 4),
};
ATTR attribute_BOX[]={
ATTRIBUTE(Single_Plane,SORT_CEN,No_Texture,C_RGB(31, 0, 8),No_Gouraud,MESHoff,sprPolygon,UseClip),
ATTRIBUTE(Single_Plane,SORT_CEN,No_Texture,C_RGB(31,23, 0),No_Gouraud,MESHoff,sprPolygon,UseClip),
ATTRIBUTE(Single_Plane,SORT_CEN,No_Texture,C_RGB(31, 0, 0),No_Gouraud,MESHoff,sprPolygon,UseClip),
ATTRIBUTE(Single_Plane,SORT_CEN,No_Texture,C_RGB(31,23, 0),No_Gouraud,MESHoff,sprPolygon,UseClip),
ATTRIBUTE(Single_Plane,SORT_CEN,No_Texture,C_RGB(10,10,31),No_Gouraud,MESHoff,sprPolygon,UseClip),
ATTRIBUTE(Single_Plane,SORT_CEN,No_Texture,C_RGB(10,10,31),No_Gouraud,MESHoff,sprPolygon,UseClip),
};
PDATA PD_BOX = {
point_BOX,sizeof(point_BOX)/sizeof(POINT),
polygon_BOX,sizeof(polygon_BOX)/sizeof(POLYGON),
attribute_BOX
};
to such a 2D map of polygon data.
Being the last tool in the chain, it overcomes size restrictions
that the 3DEditor of SS-SDK for Win95 got.
Conversion is influenced by some options,
such that it can break objects apart at tile boundaries and
merge them together to one inside a tile.
Removal of duplicate points and polygons is partially implemented and will be expanded soon.
Furthermore, I added the possibility to verify the converted data to the original.
Here is the original DRIVING .MDL data together
with 4 different verified and compilable(but DRIVING would need little modification for type MapData) conversions with my tool.
[attachmentid=1073]
Meaning of the filename suffix:
first number is option break_over_tiles,
second is merge_in_tile
The current map format is:
Code:
typedef enum {
IS_EMPTY,
IS_PDATA,
IS_XPDATA,
} PdataType;
typedef struct POLYGON_DATA {
PdataType type;
XPDATA data;
} PolygonData;
typedef struct TILE_DATA {
unsigned short nObj;
PolygonData *obj;
} TileData;
typedef struct POLYGON_MAP {
// mapSize in tiles
struct {
unsigned short x;
unsigned short y;
} mapSize;
// tileSize in world coordinates
struct {
FIXED x;
FIXED y;
} tileSize, mapOrigin;
TileData *tiles;
} MapData;
It is superior to that of the DRIVING example, since it allows multiple objects inside a tile, such that (real time gouraud) XPDATA can be mixed with normal PDATA.
The collision system of those examples instead is not fully clear to me. :huh
I've read some stuff about collision detection,
but it lacks explicit formulas like the book
"Real-Time rendering" got(which I don't have anymore).
It might help if someone else would have a look at the DRIVING source,
especially Collison_put(FIXED x,FIXED y,FIXED z) and tell me what you thing about the those lines:
Code:
// what kind of distance is this,
// since it's sx =(a_collison[aa].cen_x+x)>>16;
// and not sx =(a_collison[aa].cen_x-x)>>16;
li =slSquart(sx*sx+sy*sy+sz*sz);
// is this the distance to a plane?
// perpendicular to the plane or to the ground?
col_hight =-(A*((-x-poa)>>16)+B*((-y-pob)>>16))/C-(poc>>16);
// why this fixed point format conversion?
col_x =A*3;
Any information about ground following(keeping the car flat on the track) would be appreciated, too.
I intent to generate collision info with the tool in the future.
For example the track could be seperated from the rest by texture ids...