[Wii] Spore Hero 3D models (.rpm)

[HaoMao]

Hello! I tried to rip models from Spore Hero, and I was able to handle the vertices and UV coordinates, but I had problems with faces: I can't find their exact data at all.
All I know about the rpm structure at the moment is that polygons have a "blocked" structure: a polygon that consists of faces(?), vertices, UV coordinates, and possibly some other information. Each such polygon has the following header:

50 48 01 96 01 34 00 31 01 46 20 11 00 00 07 00
00 00 07 20 00 00 0A C8 00 00 0E 34 00 00 00 00

All I can say about the header is that 01 34 indicates the number of faces. How can I understand this if I can't display them? Well, the game Spore has exactly the same models in a different format (.rw4/.rdx9), but not all of them. Immediately after the header, there are presumably faces, and here repeats the bytes 98 00 04 00, after "faces" following 16 bytes of 00, then vertices and UV cords.
Here is an archive with the model and the addresses of the vertices and UV cords:
(Hope this info helps to figure out how rip rpm models)
UPD: I just noticed that I used a header from another model as an example. Now the header is from the archive

CE_simple_sphere.zip

Edited 13 hours ago by HaoMao

[shak-otay]

Hello! You could try using byte face indices starting from 0x1034 in the .rpm.

(I thought of using strips with 0xFF being the terminator but the sequence FF 7F FF at 0x1088 seems to exclude that.)

Auto generated faces are too ugly:

Edited yesterday at 05:58 PM by shak-otay
typo

[DKDave]

It seems as though the model data starts at 0x200 with a 0x20-byte header, which contains some offsets to the data sections relative to 0x200.  So you've got 0x720 for vertices, 0xac8 for UVs, 0xe34 for normals maybe.  The 0x31 in this header indicates the number of face sections (0x31 = 49) starting just after this header.  Each face section starts with a face type - 0x98 seems to be a tri-strip, then a short count value, followed by 4 bytes per count.  These 4 bytes are probably texture number (not sure), then it's something like vertex number, UV number, normal number.  So you have to reconstruct the buffers because they're not a direct 1:1 match.  For example, you have more UVs than vertices.

 

 

 

[HaoMao]

13 hours ago, shak-otay said:

Hello! You could try using byte face indices starting from 0x1034 in the .rpm.

(I thought of using strips with 0xFF being the terminator but the sequence FF 7F FF at 0x1088 seems to exclude that.)

Auto generated faces are too ugly:

I'm... a little confused rn. How did you make this model so that it looks like... a sphere?
To make you understand what I mean, right now my sphere looks like this:

...I really thought that's okay for this rpm models ._.
this is what the model looks like with my template from the archive

Quote

You could try using byte face indices starting from 0x1034 in the .rpm.

I tried to do this, but it doesn't work for me because there are fewer vertices than the number of bytes that follow this address (total vertices is 0x9C, and here there is 0xFF)
 

Quote

Each face section starts with a face type - 0x98 seems to be a tri-strip, then a short count value, followed by 4 bytes per count.  These 4 bytes are probably texture number (not sure), then it's something like vertex number, UV number, normal number.  So you have to reconstruct the buffers because they're not a direct 1:1 match.  For example, you have more UVs than vertices.

If I understood you correctly, then each 0x98 should be followed by the following: faces, then vertices, UVs and normals? I tried to do this, but I only get a cloud of vertices.

Edited 14 hours ago by HaoMao

[shak-otay]

46 minutes ago, HaoMao said:

To make you understand what I mean, right now my sphere looks like this:

You'll need to use unsigned shorts for vertices here.

Quote

I tried to do this, but it doesn't work for me because there are fewer vertices than the number of bytes that follow this address (total vertices is 0x9C, and here there is 0xFF)

That's why I wrote about "terminator" FF. But not sure whether .rpm uses triangle strips. You could skip the bytes bigger than 0x9C for a test.

Or you could wait for Dave.

Edited 13 hours ago by shak-otay

[HaoMao]

3 minutes ago, shak-otay said:

You'll need to use unsigned shorts for vertices here.

Well, that's what I've done since the beginning of the topic... this is odd, I don't have this problem with other model formats.

[shak-otay]

Your pictures shows use of signed shorts, imho. (characteristic splitting of the mesh into 4 separated parts)

using unsigned shorts
# 0x920: verts= 156
v 134.273438 160.218750 119.273438
v 137.363281 160.218750 105.683594
v 145.921875 150.296875 124.898438
v 150.296875 150.296875 105.683594
v 154.863281 137.363281 129.218750
...

signed shorts
# 0x920: verts= 156
v -121.726562 -95.781250 119.273438
v -118.636719 -95.781250 105.683594
v -110.078125 -105.703125 124.898438
v -105.703125 -105.703125 105.683594
...

(The actual values depend on the factor (or divisor) used for the conversion.)

Edited 13 hours ago by shak-otay

[HaoMao]

oh i see now! But yes, I'll wait for Dave for now, because I have absolutely no ideas and understanding of how to continue.