First CVR mod!

[Buster's Uncle]

I doubt that's doable, but  for doing anything at all.

[Buster's Uncle]

BTW, I don't get any notice that something's been posted to Downloads, so files will get approved a lot faster if you tell me...

for posting the purple tank mod to Downloads.

[Ford_Prefect]

Just thought I post that I'm not dead.  With the weather becoming nice, I'm becoming busy with my job.  So I have less free time working on this project.  That said....

Status:
I'm writing up a program for editing the 'texture' data of cvr files.  Currently you can load a file and see the left side of it displayed in the viewer.  You can also see what colors are available (minus the 10-20 that are unknown) for painting.  I'm still working on getting the object to display correctly.  Progress is slow because... its python.  It  sucks for anything more complex than a simple linear script and the documentation for tkinter is pretty bad.

[Geo]

Just thought I post that I'm not dead.  With the weather becoming nice, I'm becoming busy with my job.  So I have less free time working on this project.  That said....

Oh, you're selling ice cream on a road stall?

[Ford_Prefect]

No, I'm a farmer.  So I'm outside fixing my combine, planter, etc... for the upcoming harvests, planting, etc... while the weather is nice.

[Geo]

I take it you're living somewhere in West Europe then. I've been having a blast with 15-18° C weather lately.

[Ford_Prefect]

Lol.  No, Kansas, USA.

[Kilkakon]

Pretty impressive to see someone start to unpack the format. Good on ya!

[Ford_Prefect]

Progress Report:
What's done:

• I can now view a part, or its individual meshes
• I can paint each voxel individually, whatever color I want 

Todo:

• I need to be able to click and hold down to paint.  (Really annoying to have to click on each individual pixel)
• I need to improve the performance of the program to usable levels (It takes it a second to re-render after each click)
• Have it increment through the parts

[Buster's Uncle]

Impaler was telling me the other night how impressed he is with what you've done.

[Ford_Prefect]

I've released the tool
http://alphacentauri2.info/index.php?topic=7866.0

 

[Geo]

 

[PlotinusRedux]

Ford--I don't know if you're still working on this, but I'm interested in the work you've done.  I'm considering a DX/OpenGL conversion of the graphics engine, where I might convert the .cvr files into a vertex format.

Did you ever get anywhere with the normals?

I'm just starting to look at the data, but looking at the lighting in the Caviar Player, something I've noticed is that edge voxels are not sharp.  I.e., where you have two planes that meet at right angles, if you can adjust the viewing angle so that you can see both planes, you get 3 colors--1 for the 1st plane, 1 for the 2nd, and 1, between the other 2, for the edge or seam between the planes.

That makes me suspect the normals may be calculated rather than stored in the file, along the lines of vertex formats that don't contain normals.  In such vertex formats, the normal is computed from the angles of the planes that meet at it (with the order of the triangles, clockwise or counterclockwise, determining which of 2 possible directions it could point, which is only needed if you distinguish interior from exterior).  Without the proper shading model, that gives precisely the effect I'm seeing in the cavier viewer--that edges seem to be filed down, so where planes meet at right angles, there's a single line of voxels at a 45 degree to them.

If so, there are a few ways that could be accomplished.  One would be using the direction vectors to the next voxel themselves to compute the normals--if you take the position of the previous voxel, the current voxel, and the next voxel in that chain, that gives you 3 points to define a plane with the normal being perpendicular to it.  Another possibility would be once the voxels are loaded, to give each voxel a normal based on the N nearest voxels to it.  In either case, the 11 bits you haven't identified could contain material information--how reflective the material was, etc.  It could even have something to do with palette stepping, since this is shading going on in a very restricted color space.

Alternately, the 11 bits might give addition information used in combination with the direction vector in the first 5 bits to determine the normal.

Or--I haven't looked at the data yet, do parts correspond to planes?  If so, the part itself may have normal information that applies to all the voxels it contains.  Since many neighbor voxels would have identical normals, it would kind of make sense to provide a single normal applying to a whole group of voxels rather than a separate normal for each one.

Really, the data you've already interpreted is enough for a conversion to vertex format, since it's enough to build a 3d block map I can then write code (if I can't find some already written somewhere) to convert into planes and thus vertexes--reducing thousands of voxels to 10's of vertexes that will themselves allow OpenGL or DX to compute the normals.  Though having the normals would simplify the conversion code, by making plane detection as simple as searching for adjacent voxels with the same normal.

And kudos on working out that direction translation table.  With just 6 bits they could have given each dimension its own 2 bits, it wouldn't have occurred to me they would go to a look up table to save 1 bit.

[Ford_Prefect]

 

Ford--I don't know if you're still working on this, but I'm interested in the work you've done.

Its on hiatis.  If someone figures out the rest of the color data or the normals, I'll work on it again.  I'm glad to answer any questions you may have.

I'm considering a DX/OpenGL conversion of the graphics engine, where I might convert the .cvr files into a vertex format.

Oh cool.    That would be really neat.

Did you ever get anywhere with the normals?

No.  I gave up. 

That makes me suspect the normals may be calculated rather than stored in the file, along the lines of vertex formats that don't contain normals.

The reason I think those 11 bits affect the normal is because when I modified them, I could reliably get the normal to be identical regardless of the slope. 

Or--I haven't looked at the data yet, do parts correspond to planes?

No.  There can by quite complex 1 part models.  Parts can have multiple planes.  Parts just mean that the file can move them in an animation.

If so, there are a few ways that could be accomplished.  One would be using the direction vectors to the next voxel themselves to compute the normals--if you take the position of the previous voxel, the current voxel, and the next voxel in that chain, that gives you 3 points to define a plane with the normal being perpendicular to it.  Another possibility would be once the voxels are loaded, to give each voxel a normal based on the N nearest voxels to it.  In either case, the 11 bits you haven't identified could contain material information--how reflective the material was, etc.  It could even have something to do with palette stepping, since this is shading going on in a very restricted color space.

The 3 points wouldn't get you the same gradient that the original model has for curved slopes (since each voxel is at 45 degree increments).   The n voxel idea could work, I had a similar idea, but I was rather burned out at that point and wanted to work on something different.

[Ford_Prefect]

Oh.  Most of my notes on the format is here.

http://alphacentauri2.info/wiki/Caviar