Ripping Dead Space 1-3 models with animations and textures.

[kodikat]

Using Noesis v4.433. The majority of the models are fine but some models just look wrong, like the triangles were built incorrectly.

DS1_badTris.png

And on some other models, Noesis gives me a python error:
Traceback (most recent call last):
File "F:\Noesis\plugins\python\fmt_DeadSpace1_geo.py", line 82, in noepyLoadModel
rapi.rpgCommitTriangles(IBuf, noesis.RPGEODATA_SHORT, FCount, noesis.RPGEO_TRIANGLE_STRIP, 1)
RuntimeError: Position buffer would have been read out of bounds by provided indices.

Has anyone else encountered this? Did you have a fix or workaround?

[MaZTeR]

Using Noesis v4.433. The majority of the models are fine but some models just look wrong, like the triangles were built incorrectly.
DS1_badTris.png

And on some other models, Noesis gives me a python error:
Traceback (most recent call last):
File "F:\Noesis\plugins\python\fmt_DeadSpace1_geo.py", line 82, in noepyLoadModel
rapi.rpgCommitTriangles(IBuf, noesis.RPGEODATA_SHORT, FCount, noesis.RPGEO_TRIANGLE_STRIP, 1)
RuntimeError: Position buffer would have been read out of bounds by provided indices.

Has anyone else encountered this? Did you have a fix or workaround?

id-daemon was unable to make the Noesis script work with the level assets, so they appear as random triangles like that. Too bad, I would really like if someone could make a proper script for everything from the three main games.

[shakotay2]

Using Noesis v4.433. The majority of the models are fine but some models just look wrong, like the triangles were built incorrectly.
DS1_badTris.png

And on some other models, Noesis gives me a python error:
Traceback (most recent call last):
File "F:\Noesis\plugins\python\fmt_DeadSpace1_geo.py", line 82, in noepyLoadModel
rapi.rpgCommitTriangles(IBuf, noesis.RPGEODATA_SHORT, FCount, noesis.RPGEO_TRIANGLE_STRIP, 1)
RuntimeError: Position buffer would have been read out of bounds by provided indices.

Has anyone else encountered this? Did you have a fix or workaround?

Without the sample in question nothing will happen, I guess...

Also, which fmt_DeadSpace1_geo.py did you use? Is it the original from here (click up arrow to view):

---------------------------------------
.

Too bad, I would really like if someone could make a proper script for everything from the three main games.

You're dreaming of this since 5 years, don't you?

[MaZTeR]

Using Noesis v4.433. The majority of the models are fine but some models just look wrong, like the triangles were built incorrectly.
DS1_badTris.png

And on some other models, Noesis gives me a python error:
Traceback (most recent call last):
File "F:\Noesis\plugins\python\fmt_DeadSpace1_geo.py", line 82, in noepyLoadModel
rapi.rpgCommitTriangles(IBuf, noesis.RPGEODATA_SHORT, FCount, noesis.RPGEO_TRIANGLE_STRIP, 1)
RuntimeError: Position buffer would have been read out of bounds by provided indices.

Has anyone else encountered this? Did you have a fix or workaround?

Without the sample in question nothing will happen, I guess...

Also, which fmt_DeadSpace1_geo.py did you use? Is it the original from here (click up arrow to view):

---------------------------------------
.

Too bad, I would really like if someone could make a proper script for everything from the three main games.

You're dreaming of this since 5 years, don't you?

Hold on, I'll post level geometry related samples from each three games.

[MaZTeR]

Alright, here, samples from all three games.

The atrium from the bridge level in Dead Space, the flight lounge and I believe the Ishimura model you see outside in Dead Space 2 and Isaac's apartment from Dead Space 3 which I have actually ripped in its entirety from the game a few years ago and ported to Source Filmmaker:
https://www.mediafire.com/file/d3vrme56 ... 1.zip/file

There's also a script for DS2-3 which does infact extract level geometry from those two games, but the UVs are completely messed up. It can extract npcs, weapons and level related entities like say the Store or Bench somewhat fine. But it breaks the normals and flips the models 180 degrees backwards, I've been using it to port quite a lot of models in the past to SFM, along with a script which also extracted the skeletons but not weights.

There also is a script for getting at least some skeletons with weights from 2 and 3, but a lot of models I think do not work and you are required to extract each mesh one by one, meanwhile the models in the game consist of at worst dozens of parts. Good luck doing that.

[shakotay2]

Alright, here, samples from all three games.

well, thanks. But you wouldn't expect me to care for all those samples of all three games?

What I ask for was a DeadSpace 1 sample which caused the script to display a weird mesh.

And what do I have to say? The underlying problem can be tracked down very quickly with a basic understanding of (Noesis) python scripting:
for 0460_lodmodel03.geo it's just that the script's tristrips check fails.

So simply replace
checkTri = int(FCount % 3) #check if FCount is evenly divisible by 3,
by
checkTri = 1# forcing triangle strips to be used.

See image for result:
.

460_lodmodel3.png

Yeah, I know, you want to have it corrected automatically.
No time to search for a flag, or something like that.

[SUNN]

Please, anyone know how to convert an exported file back to .t4gd?

[Alexstr525]

Not sure how dead the thread is, but after managing to get the havok files; they don't seem to be in a "readable" format, the error it spits on loading them via the content tools (preview tool) is this:


This was done via, shakotay2's suggestion from earlier in the thread:

For Death Space 2 animations are hkx (hkx.win). There's a lot of posts concerning hkx in this forum. Read them, please.

Best results so far I got using the Havok Standalone tool. Rename hkx.win to hkx to test it.

Below are some sample files from the brute itself; if they can be properly formatted, maybe they'd be possible to load. I've been speaking with PredatorCZ about this as well.

EDIT* I'd like to clarify this is from Dead Space 2, I'm not sure if Dead Space 3 or Dead Space one follow suit--as far as the animation files are concerned. Can anyone take a look at these and hopefully provide some good news on the subject?

EDIT** To further clarify, I've ran this by PredatorCZ and will be in contact with him tomorrow morning 1/30/23 to further discuss the animation format if it's at all possible to really get them working. I'll provide any further details on this hopefully soon.

[einherjar007]

havok in dead space is only used for physics. The animation should be included in bnk.win.

I think dead space is a popular title, but it is very unfortunate that the format has hardly been reverse engineered, including mods.

Considering the fact that even in this remake, similar motions were created from scratch without using past formats, I can assume that the format is relatively difficult to reverse.
Of course, it is possible that past assets were not useful to accommodate more advanced graphics. Frankly, in parts, the 2008 version has better animations, so it would be interesting to be able to swap when the remake animation mod becomes available. That's just idealistic though.

[Alexstr525]

havok in dead space is only used for physics. The animation should be included in bnk.win.

I think dead space is a popular title, but it is very unfortunate that the format has hardly been reverse engineered, including mods.

Yeah I had noticed the bnk file list as well, I've already forwarded that to PredatorCZ too. I figured the Havok data was mostly reliant on physics based stuff rather than animation. I've included samples here if someone wants to take a look?

Brute BNK file list googledrive link

EDIT* Included the RCB file that stores the bone/skeletal data

[MeltyPlayer]

Hello! I've actually been working on trying to figure out these formats, too, as part of my generalized model/rig/animation-ripping tool: https://github.com/MeltyPlayer/FinModelUtility

Here's a photo of a model within my viewer:

Capture.PNG

I've made some progress on Dead Space 1 in terms of models/skeletons, and minor progress in terms of textures/materials, but I'm still incredibly lost on how this animation format works. I'll summarize what I've figured out so far below:

Here's the start of a sample animation:

Code: Select all

3F CC 08 49 00 00 00 09 01 00 00 00 3F 7E 00 00
01 00 00 00 05 4C 3D 2B BD 00 00 00 00 00 00 00
01 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00
DC 0B DC 0B DC 0B DD 0B DC 0B DC 0B DC 0B 25 00
47 0A E6 88 3E BF 8F 36 C3 D1 04 D5 9F DA 8A E1
CF E8 A6 EF 79 F5 DF F9 86 FC 13 FD 93 FB 59 F8
45 F3 44 EC 70 E3 23 D9 FE CD E2 C2 DD B8 0A B1
35 AB 64 A6 6A A2 14 9F 39 9C BD 99 95 97 C3 95
50 94 4A 93 DA 92 16 93 E9 93 8B 95 64 97 8F 99
F5 9B 7F 9E 1B A1 B3 A3 95 A6 07 AA F1 AD 38 B2
BF B6 63 BB FF BF 65 C4 65 C8 C7 CB A7 CF D9 D4
B5 DA 8C E0 A9 E5 58 E9 DF EA 87 E9 98 E4 5B DB
6E CB 74 B4 F7 98 8E 7B 82 5E 94 43 14 2C 0D 19
6F 0B 27 04 43 01 00 00 33 00 B8 01 6C 04 2D 08
D9 0C 4D 12 67 18 FF 1E EC 25 02 2D 12 34 E8 3A
4E 41 0B 47 E4 4B 9C 4F F7 51 FD 50 DC 4B 1E 44
48 3B BF 32 C8 2B 91 27 46 27 33 2A B4 2E 96 34
...

The top three lines make up a header (though there's also a separate header that defines this animation above):

Code: Select all

3F CC 08 49 00 00 00 09 01 00 00 00 3F 7E 00 00
01 00 00 00 05 4C 3D 2B BD 00 00 00 00 00 00 00
01 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00

And then the part below encodes the animation:

Code: Select all

DC 0B DC 0B DC 0B DD 0B DC 0B DC 0B DC 0B 25 00
47 0A E6 88 3E BF 8F 36 C3 D1 04 D5 9F DA 8A E1
CF E8 A6 EF 79 F5 DF F9 86 FC 13 FD 93 FB 59 F8
45 F3 44 EC 70 E3 23 D9 FE CD E2 C2 DD B8 0A B1
35 AB 64 A6 6A A2 14 9F 39 9C BD 99 95 97 C3 95
50 94 4A 93 DA 92 16 93 E9 93 8B 95 64 97 8F 99
F5 9B 7F 9E 1B A1 B3 A3 95 A6 07 AA F1 AD 38 B2
BF B6 63 BB FF BF 65 C4 65 C8 C7 CB A7 CF D9 D4
B5 DA 8C E0 A9 E5 58 E9 DF EA 87 E9 98 E4 5B DB
6E CB 74 B4 F7 98 8E 7B 82 5E 94 43 14 2C 0D 19
6F 0B 27 04 43 01 00 00 33 00 B8 01 6C 04 2D 08
D9 0C 4D 12 67 18 FF 1E EC 25 02 2D 12 34 E8 3A
4E 41 0B 47 E4 4B 9C 4F F7 51 FD 50 DC 4B 1E 44
48 3B BF 32 C8 2B 91 27 46 27 33 2A B4 2E 96 34
...

At first this just looks like a random sequence, but notice how "DC 0B" repeats multiple times? If you look above in the header, you'll see the sequence "05 4C 3D 2B BD 00 00 00". The "BD" in that sequence impacts those repeated "DC 0B" blocks--those seem to actually be shorts set to "0BDC". Based on what I've seen across multiple animation files, the last nibble (in this case, "C") appears to be some kind of enum or opcode. I've been suspecting these are essentially "commands" in the animation format. I haven't noticed any consistent patterns for these other than for commands with the value "0" (e.g. "D0 0B"/"0BD0"), which is consistently followed by three float values (possibly encoding a position or rotation?). At the end of commands, it seems to either go into a new "DX 0B" command or what I've been referring to as "subcommands", which encode additional information and follow a separate format. I haven't really found any useful patterns here yet, but I've noticed some subcommands use a series of bytes that smoothly transition in value, and some subcommands follow the sequence byte/float/byte/float/etc.

I think I've exhausted the "breakthroughs" I can have by simply staring at this data and brute forcing things, haha, so I'm interested to hear if any of you have found anything new? If not, I think the only other way to make forward progress will be to try decompiling the animation logic via Ghidra.

[MaZTeR]

Hello! I've actually been working on trying to figure out these formats, too, as part of my generalized model/rig/animation-ripping tool: https://github.com/MeltyPlayer/FinModelUtility

Here's a photo of a model within my viewer:
Capture.PNG

I've made some progress on Dead Space 1 in terms of models/skeletons, and minor progress in terms of textures/materials, but I'm still incredibly lost on how this animation format works. I'll summarize what I've figured out so far below:

Here's the start of a sample animation:

Code: Select all

3F CC 08 49 00 00 00 09 01 00 00 00 3F 7E 00 00
01 00 00 00 05 4C 3D 2B BD 00 00 00 00 00 00 00
01 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00
DC 0B DC 0B DC 0B DD 0B DC 0B DC 0B DC 0B 25 00
47 0A E6 88 3E BF 8F 36 C3 D1 04 D5 9F DA 8A E1
CF E8 A6 EF 79 F5 DF F9 86 FC 13 FD 93 FB 59 F8
45 F3 44 EC 70 E3 23 D9 FE CD E2 C2 DD B8 0A B1
35 AB 64 A6 6A A2 14 9F 39 9C BD 99 95 97 C3 95
50 94 4A 93 DA 92 16 93 E9 93 8B 95 64 97 8F 99
F5 9B 7F 9E 1B A1 B3 A3 95 A6 07 AA F1 AD 38 B2
BF B6 63 BB FF BF 65 C4 65 C8 C7 CB A7 CF D9 D4
B5 DA 8C E0 A9 E5 58 E9 DF EA 87 E9 98 E4 5B DB
6E CB 74 B4 F7 98 8E 7B 82 5E 94 43 14 2C 0D 19
6F 0B 27 04 43 01 00 00 33 00 B8 01 6C 04 2D 08
D9 0C 4D 12 67 18 FF 1E EC 25 02 2D 12 34 E8 3A
4E 41 0B 47 E4 4B 9C 4F F7 51 FD 50 DC 4B 1E 44
48 3B BF 32 C8 2B 91 27 46 27 33 2A B4 2E 96 34
...

The top three lines make up a header (though there's also a separate header that defines this animation above):

Code: Select all

3F CC 08 49 00 00 00 09 01 00 00 00 3F 7E 00 00
01 00 00 00 05 4C 3D 2B BD 00 00 00 00 00 00 00
01 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00

And then the part below encodes the animation:

Code: Select all

DC 0B DC 0B DC 0B DD 0B DC 0B DC 0B DC 0B 25 00
47 0A E6 88 3E BF 8F 36 C3 D1 04 D5 9F DA 8A E1
CF E8 A6 EF 79 F5 DF F9 86 FC 13 FD 93 FB 59 F8
45 F3 44 EC 70 E3 23 D9 FE CD E2 C2 DD B8 0A B1
35 AB 64 A6 6A A2 14 9F 39 9C BD 99 95 97 C3 95
50 94 4A 93 DA 92 16 93 E9 93 8B 95 64 97 8F 99
F5 9B 7F 9E 1B A1 B3 A3 95 A6 07 AA F1 AD 38 B2
BF B6 63 BB FF BF 65 C4 65 C8 C7 CB A7 CF D9 D4
B5 DA 8C E0 A9 E5 58 E9 DF EA 87 E9 98 E4 5B DB
6E CB 74 B4 F7 98 8E 7B 82 5E 94 43 14 2C 0D 19
6F 0B 27 04 43 01 00 00 33 00 B8 01 6C 04 2D 08
D9 0C 4D 12 67 18 FF 1E EC 25 02 2D 12 34 E8 3A
4E 41 0B 47 E4 4B 9C 4F F7 51 FD 50 DC 4B 1E 44
48 3B BF 32 C8 2B 91 27 46 27 33 2A B4 2E 96 34
...

At first this just looks like a random sequence, but notice how "DC 0B" repeats multiple times? If you look above in the header, you'll see the sequence "05 4C 3D 2B BD 00 00 00". The "BD" in that sequence impacts those repeated "DC 0B" blocks--those seem to actually be shorts set to "0BDC". Based on what I've seen across multiple animation files, the last nibble (in this case, "C") appears to be some kind of enum or opcode. I've been suspecting these are essentially "commands" in the animation format. I haven't noticed any consistent patterns for these other than for commands with the value "0" (e.g. "D0 0B"/"0BD0"), which is consistently followed by three float values (possibly encoding a position or rotation?). At the end of commands, it seems to either go into a new "DX 0B" command or what I've been referring to as "subcommands", which encode additional information and follow a separate format. I haven't really found any useful patterns here yet, but I've noticed some subcommands use a series of bytes that smoothly transition in value, and some subcommands follow the sequence byte/float/byte/float/etc.

I think I've exhausted the "breakthroughs" I can have by simply staring at this data and brute forcing things, haha, so I'm interested to hear if any of you have found anything new? If not, I think the only other way to make forward progress will be to try decompiling the animation logic via Ghidra.

I don't know if it helps with the reverse engineering, but here are all the Noesis and 3D Max model and texture scripts for Dead Space 1, 2 and 3 I've collected from here, Zenhax and somewhere else if you want to take a look at their code.

viewtopic.php?f=16&t=21530

[MeltyPlayer]

I've had some breakthroughs! Finally figured out a large amount of the animation structure, I'll document my findings here:

Animation files are split up into two main types of chunks: what I've been referring to as "definitions" and "data blocks".

Definition
Each definition corresponds to a certain animation. It first points to a name string, and then to a branching tree structure. Below is a simple definition:

Code: Select all

0x0070 | 80 00 00 00 90 00 00 00 5F 5F 5F 5F 5F 5F 5F 5F
0x0080 | 67 72 69 70 5F 70 6F 73 65 00 5F 5F 5F 5F 5F 5F | "grip_pose"
0x0090 | 02 01 00 00 A0 00 00 00 00 00 00 00 B0 00 00 00
0x00A0 | 00 00 00 00 00 00 00 00 5F 5F 5F 5F 5F 5F 5F 5F
0x00B0 | 16 00 01 00 C0 00 00 00 00 00 00 00 D0 00 00 00
0x00C0 | 00 00 00 00 00 00 00 40 00 00 00 40 5F 5F 5F 5F

Between 0x0090 and 0x00CF is the sample tree; the two nodes in the tree start with 0x0201 and 0x1600. The first byte in each node is the type--a few types I've discovered so far are 0x02 (the root), 0x05 (a parent node), and 0x16 (an animated node). The second byte in each node is the number of children, which will then be defined at the end of the node (notice that line 0x0090 ends with 0xB0, the address of its child). Animated nodes are special in that they also (or perhaps instead?) have an pointer to a data block at the end. So in this case, the animated node points to a data block at 0xD0. In this way, it's possible for a single definition to point to multiple data blocks.

Data blocks
Each data block defines some keyframes for the animation; naturally, this is where the bulk of the animation file comes from. It first starts with three lines of header, and then it goes into keyframes. Below is a simple data block:

Code: Select all

0x00D0 | 7E 62 11 DF 00 00 00 09 00 00 00 00 00 00 00 00
0x00E0 | FF FF FF FF 3D 72 94 8B 02 00 00 00 00 00 00 00
0x00F0 | 01 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00
0x0100 | 2C 00 2C 00 2C 00 2D 00 2C 00 2C 00 2C 00 2C 00
0x0110 | 2C 00 2C 00 2D 00 2C 00 20 00 8B ED AF 2C 00 5F

I still don't actually understand most of the header, haha. But the most important thing is the integer 0x3D72948B from the second line. This actually corresponds to data from the corresponding RCB file:

Code: Select all

0x0160 | 74 01 00 00 3D 72 94 8B 7C 01 00 00 74 01 00 00
0x0170 | 00 00 00 00 7C 01 00 00 00 00 00 00 84 01 00 00
0x0180 | 02 00 00 00 03 00 00 00 00 00 00 00 90 01 00 00

As you can see, the first line contains the same integer, 0x3D72948B! The value immediately after this points to the tuple (0x0184, 0x02), which itself points to 0x03. It's not necessarily clear from this example, but 2 is the number of bones in this model, and 3 is a bitmask for the bones that will have keyframes defined in this data block. Since 3 in binary is just "11", this effectively means that all 2 bones in the model will have definitions in the current data block.

After the header in the data block, it then goes right into animation data. This is the part that starts with some 0x2C values. I had been referring to these as "commands" before, but it turns out that this is actually frame data for each axis! Specifically, it lists out the XYZW quaternion axes, and then the XYZ position axes for each bone in the bitmask mentioned above.

Frame data can be listed out as either singletons or as multiple keyframes.

Singletons
Singletons, i.e. single keyframes, will start with the 3 nibbles that immediately comes after the important integer mentioned above. In the example above, the 3 nibbles immediately after 0x3D72948B are 0x020 (i.e. 0x002). (The endianness makes it a bit hard to read, but you just kind of have to flip the order around in your head) As you can see, the above example exclusively contains singletons: 0x2C00, 0x2D00, 0x2000. It's important to note that this 3-nibble prefix doesn't necessarily need to start with 0s; it can be arbitrary hex.

The value to use in the single keyframe is identified by the last nibble:
- 0xC: 0
- 0xD: 1 (primarily used for the W axis of the quaternion)
- 0x0: The reader will step back a byte and then read a 4-byte float. Since it steps back, this float will actually contain part of the 3-nibble prefix mentioned above!

So here's how you can interpret the above animation data:

Code: Select all

- Bone 1:
  - Quaternion X: 0 (0x2C00) 
  - Quaternion Y: 0 (0x2C00) 
  - Quaternion Z: 0 (0x2C00) 
  - Quaternion W: 1 (0x2D00) 
  - Position X: 0 (0x2C00) 
  - Position Y: 0 (0x2C00) 
  - Position Z: 0 (0x2C00) 
- Bone 2:
  - Quaternion X: 0 (0x2C00) 
  - Quaternion Y: 0 (0x2C00) 
  - Quaternion Z: 0 (0x2C00) 
  - Quaternion W: 1 (0x2D00) 
  - Position X: 0 (0x2C00) 
  - Position Y: -4.320881e-10 (0x20008BEDAF) 
  - Position Z: 0 (0x2C00) 

Multiple keyframes
From what I've seen, lists of multiple keyframes will start with some nibble and then 5, i.e. 0xB500. The first nibble actually corresponds to the number of keyframes that will be defined--in this case, it would be 11 (0xB). It then lists out the keyframes immediately afterward. Below is an example of a data block that contains an axis with multiple keyframes:

Code: Select all

0x01C0 | 59 E1 D9 E0 00 00 00 09 01 00 00 00 00 00 00 00
0x01D0 | FF FF FF FF 39 B5 AF 45 C2 01 00 00 00 00 00 00
0x01E0 | 01 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00
0x01F0 | 2C 1C 2C 1C 2C 1C 2D 1C 2C 1C 2C 1C 2C 1C 2C 1C
0x0200 | 2C 1C 2C 1C 2D 1C 2C 1C 2C 1C 2C 1C 2C 1C B5 00
0x0210 | 23 03 01 D2 34 E5 19 B8 9C 80 BB 89 7E BB 23 03
0x0220 | C4 A5 34 08 B3 37 B6 9A BB FC 73 BE 23 03 D4 2C
0x0230 | 35 09 AC B7 79 0A 39 E4 C3 BE 22 03 D3 F8 37 3C
0x0240 | 2A 3B D6 B3 BE 23 03 39 63 B4 6C 92 37 92 AC 3B
0x0250 | 50 1D BE 22 03 8F E0 B7 CB BA 3B CB F6 3D 82 02
0x0260 | 81 36 B8 86 3E 3B 51 AB 3E B0 00 EF C3 3E 23 03
0x0270 | E7 95 34 F9 90 B8 B2 C5 39 BF C3 3E 93 03 8D CA
0x0280 | 34 3F E7 B7 94 8E BB 0F 89 3E 21 00 44 7C BB 44
0x0290 | 7C 3B 2C 1C 95 00 22 03 E1 56 B7 56 26 38 F7 7F
0x02A0 | 3F 23 03 7F 89 34 B0 13 B7 DC 95 BA 9E 78 3F 23
0x02B0 | 03 68 82 34 12 F3 B6 D2 1D 38 88 6C 3F 22 03 14
0x02C0 | 7B B5 B9 94 3A 87 6F 3F 22 03 2F 85 B7 9D 64 3A
0x02D0 | EC 7C 3F 22 03 77 80 B6 F8 64 BA 51 7E 3F 23 03
0x02E0 | 7D 18 B4 E1 C9 37 83 9F BA 5E 71 3F 23 03 01 7F
0x02F0 | B4 5F 05 38 A4 3F B9 90 6C 3F A2 03 3E 4C B7 B4
0x0300 | AF 3A 8C 76 3F 20 1C 00 40 3D 20 1C EF DA 3D 20
0x0310 | 1C 87 FF 3D 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F

In this case, the multiple keyframes begin on line 0x200, with 0xB500. (To be explicitly clear, this is a substitute for a singleton; this clump of multiple keyframes will all be used within a single axis.) I haven't fully worked out the keyframes format, but I've noticed some key patterns. They start with two nibbles: one for the number of frames corresponding to their length, and another for the type of keyframe. Then, it lists off some data, and finally the value of the keyframe. I'm not entirely sure what this extra data means, but I'm assuming it's things like tangents for easing.

In the above example, the keyframes after 0xB500 look like this:

Code: Select all

23   03 01 D2 34 E5 19 B8 9C 80   BB 89 7E BB
23   03 C4 A5 34 08 B3 37 B6 9A   BB FC 73 BE 
23   03 D4 2C 35 09 AC B7 79 0A   39 E4 C3 BE 
22   03 D3 F8 37 3C 2A            3B D6 B3 BE 
23   03 39 63 B4 6C 92 37 92 AC   3B 50 1D BE 
22   03 8F E0 B7 CB BA            3B CB F6 3D 
82   02 81 36 B8 86 3E            3B 51 AB 3E 
B0                                00 EF C3 3E 
23   03 E7 95 34 F9 90 B8 B2 C5   39 BF C3 3E 
93   03 8D CA 34 3F E7 B7 94 8E   BB 0F 89 3E 
21   00 44 7C                     BB 44 7C 3B

As mentioned above, the first nibble of each row is the length of the keyframe and the second is the type. The data immediately after is presumably for things like easing--the amount of extra data depends on the type. A type of 0 has no extra data, 1 has 3 bytes, 2 has 6 bytes, and 3 has 9. The last four bytes are the float value for that keyframe.

I'm currently working on a parser for this format and will continue researching this to see what else I find out, but I thought I might as well share my findings for posterity. Hopefully this all made sense and is useful to you folks!

[einherjar007]

Really great research, Dead Space has a number of cutscenes that seem to have been lost in all series as far as the internal text data is concerned.
I don't know if any of those animations are still inside, but that will become clear when you or someone else is able to analyze the animations someday!
Originally this game has some of the best animations of any TPS game of its time. I am very much looking forward to the new news!