|
|
| Line 1: |
Line 1: |
| − | == Terrain chunks ==
| |
| | | | |
| − | Terrain in RIFT is split into "chunks". Each chunk is represented by a 256x256 mesh stored as a [[NIF]] file.
| |
| − |
| |
| − | The chunks are stored in the [[Asset Files]] and the name can be generated using the following template:
| |
| − |
| |
| − | Terrain chunks have two types, a far LOD and a close LOD version.
| |
| − |
| |
| − | <nowiki>%s_terrain_%d_%d_%s.nif</nowiki>
| |
| − |
| |
| − | Where the parameters are:
| |
| − | * World name
| |
| − | * integer X co-ordinate
| |
| − | * integer Y co-ordinate
| |
| − | * type of the terrain. For close terrain, this should be '''"split"''', for far it should be '''"lod_split"'''.
| |
| − |
| |
| − |
| |
| − | The X/Y co-ordinates are 256 aligned, and you can find out the available chunks by searching from 0 to some large value in 256 increments. Eg:
| |
| − |
| |
| − | * '''world_terrain_0_0_split.nif'''
| |
| − | * '''world_terrain_256_0_split.nif'''
| |
| − |
| |
| − | == World Objects ==
| |
| − |
| |
| − | The static world objects are stored within CDR files. These files are in [[DAT Format]] and are stored as binary serialized data.
| |
| − | The filename is similar to the terrain chunks above except without the LOD and have a CDR extension. This means that each chunk of terrain also has a corresponding CDR file.
| |
| − |
| |
| − | *'''world_terrain_0_0.cdr'''
| |
| − |
| |
| − | The initial class within the CDR file is '''107''' and in general looks something like this:
| |
| − |
| |
| − | class _107:
| |
| − | _600[] elements;
| |
| − | byte[] data;
| |
| − | _108[] elements;
| |
| − |
| |
| − | Where '''_600''' and '''_108''' refer to "classes".
| |
| − | The unknown '''data''' appears to be occlusion related and is of no use to us.
| |
| − |
| |
| − | == class 600 ==
| |
| − |
| |
| − | class _600:
| |
| − | int ID;
| |
| − | string objectName;
| |
| − | // array of objects, generally like so:
| |
| − | array {_602, _603, _601, _826}
| |
| − |
| |
| − | == class 602 ==
| |
| − |
| |
| − | This class appears to contain a single integer which is key to an entry in Dataset 623 within [[telara.db]]
| |
| − |
| |
| − | == class 603 ==
| |
| − |
| |
| − | This class contains a reference that links the object to it's NIF and [[HKX]] data, as well it's position, rotation and scale within the world
| |
| − |
| |
| − | class _603:
| |
| − | int ref;
| |
| − | array of floats { posX, posY, posZ }
| |
| − | array of floats { quaternion.x, quaternion.y, quaternion.z, quaternion.w }
| |
| − | int ref2;
| |
| − | array of floats { pos2X, pos2Y, pos2Z }
| |
| − | float scale
| |
| − |
| |
| − | Keep in mind that due to the way the deserialization protocol works ( see [[DAT Format]] ) in that it skips empty members, that some classes or members may not exist.
| |
