![[V] Knobby](/forum/data/avatars/m/44/44150.jpg?1371153262){kind=avatar}
[V] Knobby
Volition Staff
This is probably better explained in a doc, but for now this will have to hold you over.
Objects in the zone files should be hackable...we also support dynamic objects so it isn't out of the question to get object creation done via lua script. I'm personally hoping for that. You guys write lua(maybe even a dll?) and you can create a mission start node and do your own thing. Currently if you knew the correct offsets you could change an existing object, but that doesn't seem to interesting. It might be easy enough to figure out the format of the compressed objects and add them to the data file. I'm not entirely sure.
PS3 made us go to c/g split files. This is a cpu and gpu file. Since the PS3 has split memory, we had to do that to load the file into the proper place in memory. I generally refer to a file by the cpu name only, but I'm usually talking about the collection of both of them.
CZN, zone file:
We break the world up into multiple layers for streaming purposes. We have a grid of always loaded, a medium lod and a high lod. We also have trigger based streaming originally for interiors, but used a good deal on SR3 for missions as well. Things like the Stilwater bank are trigger based.
Originally there was just the czn file, but we found that the header on that file added up to a lot of memory, so we broke it off into a czh file that we load just to load the zone and then toss out. The header will list the assets needed to load the zone(for streaming container building) and some other information that is only needed once at load time.
Medium LOD:
A medium lod zone is named the brick xz coordinate(1609). There can be a s or f, which stand for fast and slow. When we originally made the pipeline we tried to put things that took a long time to crunch like havok data into the slow file thinking that we would usually just crunch the faster crunching fast file and live with bad collision data. It turned out they were both plenty fast to crunch so it wasn't an issue. It is somewhat of a relic now, but we split things up into fast and slow files still.
Always loaded:
Always loaded zones come in two flavors. First is the always loaded for each brick/trigger zone. 1609~al for example. These are the AL things like objects for this specific zone. The other type is the global always loaded. We tried not to put many things into this file(awld.czn) because of file contention issues with revision control. Other than when these are loaded, they are just zone files.
High LOD:
These files end in ~h0/~h1/~h2/~h3 and represent the high lod data for a zone. This is just mesh data in SR3. A zone is simply broken up into 4 equal parts with the southeast portion being h0, southwest is h1, northeast is h2 and northwest is h3.
Trigger zones:
These zones have a trigger BSP volume in the ~al portion that drives when to load the zone. We have two versions in SR3, small and large. The small triggers are for stores like Let's Pretend and the large ones are for things that require more memory. The small triggers load into their own mempool and we only load one at a time. The large triggers use the same memory as the zones, so we have to kick out zones in order to load them. Things like 3count is a large interior with a small interior gating the entrance(which is why it has a somewhat convoluted entrance, we don't want you to see things loading).
Zone swaps:
This is why sometimes you can see things and sometimes you can't. We can swap any zone and things like the bridges going up or blown up buildings and upgraded strongholds are often accomplished with a zone swap. These are zones with a ^swap_name on the end. To swap to bridges up, you might enable to ^bridge swap which will load 1609^bridge instead of 1609 when you are in the area. We also do the swap on the AL, which is a bit more complicated since it is always loaded. We also use zone swaps for missions that need a unique area like the bank for mission 1.
str2 files are just packfiles with a different extension. They are specifically made from the streaming container to load the data, so we don't have to seek all over the place in order to load something. We smash together all the parts(czn, cmesh, vbm, etc) into a single file.
Peg files are just files which hold multiple textures so we can interleave mips for the 360 to save space. These existed in in previous titles like SR2. In SR3, we use pegs for some things like characters and vehicles, but use vbm's (which came from RFG IIRC) for most other things. A vbm is simply a peg file with a single texture entry inside it. I assume it stands for Volition BitMap, but I'm not positive on that one. The advantage there is each zone file can have multiple textures inside it, but brick.tga is probably used in a lot of the neighboring zones. If we load the vbm, we can store it in memory only once easily, but if we are loading the PEG with the texture interleaved, we just duplicate that data. We took a hit on the 360 by not interleaving the texture data, but the duplication savings made up for it.
Here is a probably massive map with the zone overlay. 3count is mostly in zone 1608 here. The zones start at 0000 in the southeast and go to 2525 in the northwest. The world doesn't actually extend that far though.
Objects in the zone files should be hackable...we also support dynamic objects so it isn't out of the question to get object creation done via lua script. I'm personally hoping for that. You guys write lua(maybe even a dll?) and you can create a mission start node and do your own thing. Currently if you knew the correct offsets you could change an existing object, but that doesn't seem to interesting. It might be easy enough to figure out the format of the compressed objects and add them to the data file. I'm not entirely sure.
PS3 made us go to c/g split files. This is a cpu and gpu file. Since the PS3 has split memory, we had to do that to load the file into the proper place in memory. I generally refer to a file by the cpu name only, but I'm usually talking about the collection of both of them.
CZN, zone file:
We break the world up into multiple layers for streaming purposes. We have a grid of always loaded, a medium lod and a high lod. We also have trigger based streaming originally for interiors, but used a good deal on SR3 for missions as well. Things like the Stilwater bank are trigger based.
Originally there was just the czn file, but we found that the header on that file added up to a lot of memory, so we broke it off into a czh file that we load just to load the zone and then toss out. The header will list the assets needed to load the zone(for streaming container building) and some other information that is only needed once at load time.
Medium LOD:
A medium lod zone is named the brick xz coordinate(1609). There can be a s or f, which stand for fast and slow. When we originally made the pipeline we tried to put things that took a long time to crunch like havok data into the slow file thinking that we would usually just crunch the faster crunching fast file and live with bad collision data. It turned out they were both plenty fast to crunch so it wasn't an issue. It is somewhat of a relic now, but we split things up into fast and slow files still.
Always loaded:
Always loaded zones come in two flavors. First is the always loaded for each brick/trigger zone. 1609~al for example. These are the AL things like objects for this specific zone. The other type is the global always loaded. We tried not to put many things into this file(awld.czn) because of file contention issues with revision control. Other than when these are loaded, they are just zone files.
High LOD:
These files end in ~h0/~h1/~h2/~h3 and represent the high lod data for a zone. This is just mesh data in SR3. A zone is simply broken up into 4 equal parts with the southeast portion being h0, southwest is h1, northeast is h2 and northwest is h3.
Trigger zones:
These zones have a trigger BSP volume in the ~al portion that drives when to load the zone. We have two versions in SR3, small and large. The small triggers are for stores like Let's Pretend and the large ones are for things that require more memory. The small triggers load into their own mempool and we only load one at a time. The large triggers use the same memory as the zones, so we have to kick out zones in order to load them. Things like 3count is a large interior with a small interior gating the entrance(which is why it has a somewhat convoluted entrance, we don't want you to see things loading).
Zone swaps:
This is why sometimes you can see things and sometimes you can't. We can swap any zone and things like the bridges going up or blown up buildings and upgraded strongholds are often accomplished with a zone swap. These are zones with a ^swap_name on the end. To swap to bridges up, you might enable to ^bridge swap which will load 1609^bridge instead of 1609 when you are in the area. We also do the swap on the AL, which is a bit more complicated since it is always loaded. We also use zone swaps for missions that need a unique area like the bank for mission 1.
str2 files are just packfiles with a different extension. They are specifically made from the streaming container to load the data, so we don't have to seek all over the place in order to load something. We smash together all the parts(czn, cmesh, vbm, etc) into a single file.
Peg files are just files which hold multiple textures so we can interleave mips for the 360 to save space. These existed in in previous titles like SR2. In SR3, we use pegs for some things like characters and vehicles, but use vbm's (which came from RFG IIRC) for most other things. A vbm is simply a peg file with a single texture entry inside it. I assume it stands for Volition BitMap, but I'm not positive on that one. The advantage there is each zone file can have multiple textures inside it, but brick.tga is probably used in a lot of the neighboring zones. If we load the vbm, we can store it in memory only once easily, but if we are loading the PEG with the texture interleaved, we just duplicate that data. We took a hit on the 360 by not interleaving the texture data, but the duplication savings made up for it.
Here is a probably massive map with the zone overlay. 3count is mostly in zone 1608 here. The zones start at 0000 in the southeast and go to 2525 in the northwest. The world doesn't actually extend that far though.
![[V] IdolNinja](/forum/data/avatars/m/0/62.jpg?1394026296){kind=avatar}
