First CVR mod!

[Ford_Prefect]

Update: !  2014-03-16    See original post bellow.
Link to the download file: http://alphacentauri2.info/index.php?action=downloads;sa=view;down=158




-------------- Original post------------------

I've had a breakthrough in deciphering the CVR file format. 

What I've figured out: (Updated list on 2014-02-26)

• Where the parts are located
• Part Names
• Object name
• Locations - Somewhat
• Palette codes 02/26
• Number of animation frames 2/26
• Number of parts 2/26
• How the voxels are placed in the engine 
• File version number

I haven't figured out (yet):

• How to assemble the skeleton
• Animation
• Absolute Locations - Somewhat
• Normals

Ok. Here is the nitty gritty details of what has gotten me so excited. 
Example hex dump from parts section:

Code: [Select]

6F D2 95 6F D2 95 6F D1 95 6F D1 95 6F D1 95
6F D1 95 6F D1 95 6F D0 95 6F D0 95 6F 76 95
6F 75 95 6F 1C 95 6F 1C 95 B6 C3 95 6E C2 95
5E C2 95 7E 69 95 B5 B6 95 15 5D 95 B4 AC 95
B4 AC 95 6C AB 95 ......
See that 95? That is the color that the voxel will use.
That was easy part.

Ok.  The part that was driving me nuts:  Position:  How was it calculated for each voxel?  First I thought it was an z, y with x being incremented every once and a while... but I was wrong.... So I got to toying with the numbers and ......

byte1 byte2 byte3  If I lay the data out like this.... with byte 3 being the color code.
60      D2     95

Lets look closer at byte 1 shall we?
x60 = 01100000
01100   000       
|-----| < this part, the first 5 bits, when it changes, changes the direction the next voxel will be located.  With 22 possible vectors.  (WARNING: Using a value larger than 11001 will cause access violations or crashes with the model viewer)

Yes, each voxel is a set distance from the last, with the first 5 bits of data telling which direction (in 45 degree increments) to go.

The 3 bits + byte 2 is something else.  Figuring out what they are used for is on my todo list. 

[Bertilak]

First, your post was very insightful and I hope you are successful in deciphering the caviar file format for this game.

If you are interested, this is how the cvr files are actually used inside  the game code. The method they used to create the multipart chassises in the game was to assemble them in a single procedure that had the skeleton of the chassis in one procedure and from there they would add other pieces like armor and weapons. In addition, they added a memory address and call function to some of the caviar pieces that had an animation associated with them.

[Ford_Prefect]

I've learned how single part objects store their coordinates.   

The general layout:
zz zz xx xx yy yy E8 FF C7 FF EB FF 31 00 74 00 2B 00 zz zz xx xx yy yy E5 12 00 00 00 00 00 00
                         |---? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? -------|                          |--Voxels---|
The voxel number is the number of voxels to the next jump.
zz, xx, yy are signed shorts.

I'm probably missing something with the coordinates as both sets have different numbers, but modifying them seemed to have the same results.

Also, multipart pieces have a different data structure so I'm gonna have to do some more work for figuring out their layout. 

I'm gonna take a break from looking at the hex files for a bit and try writing an exporter for single pieces.  After that I'll try to pin down where the data stores the center-point (I'll be able to do some trial and error with my own file viewer) and then start work on multi-part files.

[Ford_Prefect]

(click to show/hide)

My first attempt at importing the data. 

I haven't programmed in the color, so I set it to random.
I need to get lighting to work properly in the viewer.  Learning how to program in this 3d engine will be interesting.

[Buster's Uncle]

 

[Ford_Prefect]

Status Update:

I've got my first cvr to convert and display!  I did try loading in some other pieces... but some of them failed halfway through the conversion.  So I guess one of my assumptions was wrong. Gonna have to take a look.

In other news.... Looking at the performance of just plopping in cubes for each voxel seems to give really bad performance.  So I'm gonna need a better method of rendering the data.  I mean seriously, the original CVR viewer is rendering the same data at 2000 fps!  If anyone has some suggestions, I'd be happy to hear them as I'm a complete noob when it comes to working with 3d graphics.

[Ford_Prefect]

Woohooo!  Can now load more one part models!  Both the ship and the missle now load.

Downside is that these high voxel count models really drive home the fact I need to come up with a better method of rendering them.

[Ford_Prefect]

Good news, Bad news.
Good news - I've changed the way the engine renders the files and it can now handle them.  I've also got it loading the colors.

Bad news - the palate color codes from the palate file are not the same as the color codes in the CVR file.   Which means I'm gonna have to reverse engineer the palette location.   

TODO to get models into another game engine:

• Find the color pallet location - critical for pieces having the right color
• Normals - Probably will take quite a while if I manually change values slowly in a cvr file and noting the normals direction, because it will be hard telling which way the normal is pointed. 
• Positions - apparently some single-part locations are failing.  Gonna have to figure out why.

TODO:  To make it easier to get into another game engine

• Figure out how multi-part/animated models are rigged - I might take a stab at figuring this out.  If worse, comes to worse, one can always manually place the individual pieces
• Animation - No.  Someone else can spend the time figuring this out.  If you do, post your discoveries! 

[Ford_Prefect]

I'm back!

I've been playing dungeon keeper 2 in my free time... which is why you guys haven't heard from me in a while. :-D

So, I spent half a day trying to pin down why the positional data appears and disapears in this one part.... and I haven't figured it out yet, but I did pin down some other data.

New stuff I can read:

• Number of frames
• Number of parts - Somewhat useful, as I had found a workaround, but this will probably make it less glitchy.
• Center of rotation - will probably be useful in the future
• Another positional data set? - Not sure need to dink around with the number more to make sure
• Where the palate is located, but haven't figure out how colors are numbered yet

I also know where the value for units per 3d voxel is stored.  I don't know how to read it yet.

What's next?
I'll probably try to read in the new data, and try to get both non-animated files to convert properly.  Sadly, I think I already figured out all the easy stuff.  I think all that's left is manually changing values or formulas and seeing what changes, which is slow.  I'll probably make some changes to my renderer so that I don't have to open and close it to view different models.

[Buster's Uncle]

If this ultimately results in a .cvr editor so art modders could, for example, make appropriate-looking units for a Middle Earth mod --- the SMACX modding world will be laid at your feet.  I can't do a lot to sweeten the deal for you, but there's definitely a .cvr King badge for your postbit in it.  And the community would respect and owe you.

[Geo]

...and awe you.

Corrected.

[Buster's Uncle]

[Ford_Prefect]

Picture of my work with ACP00.cvr



Spent some more time on it and I think I've figured out how to grab the color palate.   
I'm also making progress on the positional data.  The main issue currently is that I think its supposed to have a different rotation location.  This is the simplist of the cvr files in alpha centari.  It was converted from a single mesh.  Infuriating me is the fact that this stores its location data differently than every other single part (but converted from multiple meshes) files.  So... I have to figure out how to detect this anomoly, or just stick in an exception for the ACP0# files.

.cvr editor

  Ok.  A .cvr editor... I wasn't originally planning on writing one.... but....
With what I know currently, I or someone else could write a "texture" editor for the models. 
I could also probably make it possible to move some parts relative to each other.

Without knowing how normals are stored, mesh editing wouldn't work.  As things would be very, very, very, ugly.




 

[Buster's Uncle]

Y'know, I gather from your work that the files are true 3D - all I could tell from the .cvr viewer lo, all those many years ago, was that eight different positions displayed.  That's all the game needs anyway.  If, then, it was possible to substitute eight 2D flat shots of a covered wagon in place of the eight angles the colony pods display depending on which way they went - it would be a lot of work, but totally doable, and make that wild west mod someone dreamed of SO much better...

[Ford_Prefect]

Actually, it would be more like spray painting the desired image onto the model using the palette colors.  Not sure what a different color palette would do to the object models in the game.  They both use a 256 color palette.  If you change the games color palette, does it change the colors of the units as well or does the game just crash?