Silver 3d models and animations (CHR and ANM files)

[TaylorMouse]

Does the treasure chest animate ?
If so, maybe there is a reference to a bone or something, so that the cover of the chest is placed relevant to that position.

Btw, nice progress

T

[nerdyluke]

Yes, the chest has an animation. Idont know anything about bones however... do u know some tut that explains what it is and/or what to look for when reversing them? Its so annoying to be so close and still not be able to understand how the damn format works. Actually the section I do not understand has indices that seem to be mesh indices and those are followed by floats, does that sound like bone structure to you?

Also there seems to be a structure, the section always goes like this:

Code: Select all

<mesh index> <float x> <float y> <float z>
<mesh index> <float x> <float y> <float z>
<mesh index> <float x> <float y> <float z>
...

And judging from the order of the indices I'm guessing there is hierarchy in the order they appear.

Also sometimes there's just that and sometimes there's a "FF FF FF FF" separator and then another section. like this for example:

Code: Select all

<mesh index> <float x> <float y> <float z>
<mesh index> <float x> <float y> <float z>
<mesh index> <float x> <float y> <float z>
...
FF FF FF FF
<mesh index> <float x> <float y> <float z> // Sometimes the mesh index has already been mentioned earlier in the section, which is strange
<mesh index> <float x> <float y> <float z>
<mesh index> <float x> <float y> <float z>
...

Btw ill be on vacation soon so ill have more time to look into this

[TaylorMouse]

I think the MeshIndex x y z refers to bones?

T.

[nerdyluke]

I think the MeshIndex x y z refers to bones?

T.

ty for help. Btw sry for my ignorance but is bone description alone sufficient to place the cover over the chest or eg a foot at the end of a leg?

[TaylorMouse]

probably not, you should have some vertex weights somewhere, with an index to one or more bones, probably a fixed number of bones but not more than 4


T.

[nerdyluke]

I have a very weak 3d background, but is what you're telling me related to this http://www.misfitcode.com/misfitmodel3d ... tails.html ?

A bone joint is is an object that forms one part of a model's skeletal structure. The root bone joint has no parent joint, all other joints have one parent. A parent joint may have multiple children.

Vertices and points may be attached to bone joints to control their movements during skeletal animations. When a vertex or point's movement is controlled by a bone joint, the bone joint is said to be an "influence". Vertices and points may have up to four influences.

I have trouble finding a simple explanation about bones/joints and how they work

[nerdyluke]

Continuing research... I've tidied up my (incomplete) CHR specification if anyone wants to have a look at the format.

Code: Select all

Consists of chunks and subchunks, with 4 bytes for the chunk ID, 4 bytes for the chunk size and the next bytes for the chunk data.

0x8000: Root chunk
	+4   long   chunk size
	
	0x18000: unknown purpose chunk
		+4   long   chunk size

		0x7f01: unknown purpose chunk
			+4    long      chunk size
			+8    long      N
			+12   long[N]   unknown long array

		0x7f03: Model chunk (contains submeshes)
			+4    long   chunk size
			+8    long   submesh count
			+12   long   model ID (first submesh ID)
			
			0x7f02: Submesh
				+4                      long                   chunk size
				+8                      long                   1
				+12                     long                   submesh ID
				+16                     long                   0
				+20                     long                   vertice count VC
				+24                     long                   polygon count PC
				+28                     long                   PC again ?
				+32                     long                   unknown
				+36                     long                   unknown
				+40                     float[3]               submesh center
				+52                     char[64]               unknown (sometimes contains a string eg. "amera02" or "C:\3DS4")
				+116                    float[3 * VC]          vertices
				+116 + 12 * VC          float[3 * PC]          normals
				+116 + 12 * (VC + PC)   (struct polygon)[PC]   {char unknown, char polygonIndex, char pVerticeCount, char unknown, long unknown, (long vertexIndex, long unknown, long unknown, long unknown) * pVerticeCount}

		0x7f04: Model texture

		0x7f05: Bones ?
			+4    long         chunk size
			+8    long         unknown
			+12   long         unknown
			+16   byte[4]      0
			+32   (struct)[]   {long index, float x, float y, float z}, the structs are sometimes interleaved with FF FF FF FF and 12 null bytes inbetween...
			
		0x7f06: unknown purpose chunk (seems to be groups of submeshes)

[nerdyluke]

I'm trying to understand the 057f and 067f sections and things are getting very tricky . For TREASURE.CHR it's quite simple:

TREASURE.CHR, 057f:

Code: Select all

0: 0, 0, 0
1: 0, 80, -50
2: 0, 0, 100

and the 067f:

Code: Select all

3576
3578
3577

The values above are submesh IDs, when offsetting the submeshes in this order, relative to the previous submesh (ie 3576 offset with (0, 0, 0), 3578 offset with (0, 80, -50) and 3577 offset with (0, 80, 50)) then the cover and the lock are placed perfectly. But when looking at BAT.CHR things are not as easy:

BAT.CHR, 057f:

Code: Select all

0 :  0      -0.3    0.68
1 :  0      0.3     -0.7
2 :  0      0.17    32.5
3 :  0      0       7.6
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
2 :  13.5   -0.22   -1.7
24:  21     0.1     16.1
2 :  -12.3  -0.3    -2
26:  -22    0.6     17.2
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
-1:  0      0       0
25:  28.7   0.1     7.75
27:  -28.5  -0.35   6.6

and the 067f:

Code: Select all

11874, 11865, 11864, 11875
19 * null
11873
11872
11869
11868
16 * null
11870, 11871
11866, 11867

I'm not even posting the values for DAVID.CHR because it's even messier... I don't think this structure looks like a bone matrix has anyone seen something like this in another format ? Looks like somekind of C array since there are sizes before both sections but I just can't make sense of it because the indexes don't make sense, apart from the fact that contiguous indexes (24,25,26 etc) seem to have to do with parenting... Halp please

[nerdyluke]

Gave it another shot today, been focusing on UVs. I know where they are and I have these UVs for the face of the "inside" of the chest:

Code: Select all

F4 38 00 00 7A 1C 00 00 
D0 C6 3B 00 7A 1C 00 00 
D0 C6 3B 00 68 E3 1D 00 
F4 38 00 00 68 E3 1D 00

I've also managed to extract the texture:



Now from this texture, the real coords should be something like this (the order may be wrong but the numbers are the correct ones):

Code: Select all

100,0
160,0
160,30
100,30

Now does anyone know how to convert the ints I've found to the real coords? thx

[fatduck]

absolute pixel coordinate, mate!

[nerdyluke]

absolute pixel coordinate, mate!

I'm not sure I understand what you mean:

F4 38 00 00 7A 1C 00 00 = 14580, 7290
D0 C6 3B 00 7A 1C 00 00 = 3917520, 7290

How do I get to 100, 0 and 160, 0 from there ? its not even proporsional

[TaylorMouse]

He means that the values you got are absolute pixel coordinates, meaning that you need to convert them to uv coordinates

ex. If the texture is 256 wide, and you pixel coordinate is 160 then the uv coordinate is 160/256 = 0,625

T.

[nerdyluke]

He means that the values you got are absolute pixel coordinates, meaning that you need to convert them to uv coordinates

ex. If the texture is 256 wide, and you pixel coordinate is 160 then the uv coordinate is 160/256 = 0,625

T.

yes sure I understand that, but the values I posted (100, 0; 160, 0 etc) are the pixel values I SHOULD find, but the corresponding values in the CHR are 14580, 7290; 3917520, 7290 etc and I don't know how to convert those to absolute pixel coords. Sorry if I'm missing something here but I can't find how to do that

[TaylorMouse]

Ah, ok, I think that we both misunderstood you.

What makes you think that the data should point to the texture coordinates?

T.

[nerdyluke]

nvm