READ THE RULES: Click here

Follow us on Facebook: https://www.facebook.com/xentax/ :)

Soul Calibur 3 Modding

Post questions about game models here, or help out others!
pceengied
beginner
Posts: 30
Joined: Fri Jan 22, 2010 7:55 pm
Has thanked: 2 times

Soul Calibur 3 Modding

Post by pceengied » Tue Dec 28, 2010 9:11 am

The contents of this post was deleted because of possible forum rules violation.
Last edited by pceengied on Tue Dec 28, 2010 9:48 am, edited 1 time in total.

pceengied
beginner
Posts: 30
Joined: Fri Jan 22, 2010 7:55 pm
Has thanked: 2 times

Re: Soul Calibur 3 Modding

Post by pceengied » Tue Dec 28, 2010 9:47 am

sc3

File7.olk:
1 - 4
9 - 315 Standard Model data
319 - 368
369 - 576 cas model
577 - 626 Standard Animation
627 - 1181 Bonus Model
1182, 1183
1184 - 1259
1260 - 1391
1392 - 1413 Bonus Animation

///////////////////////////////////////////////////////////////////////////////
// Standard Model data
///////////////////////////////////////////////////////////////////////////////

9 10 Mitsurugi
17 18 Mitsurugi Edit

21 22 Seung Mina
29 30 Seung Mina Edit

33 34 Taki
41 42 Taki Edit

45 46 Maxi
53 54 Maxi Edit

57 58 Voldo
65 66 Voldo Edit

69 70 Sophitia
77 78 Sophitia Edit

81 82 Siegfried
89 90 Siegfried Edit

93 94 Rock
101 102 Rock Edit

105 106 Ivy
113 114 Ivy Edit

117 118 Kilik
125 126 Kilik Edit

129 130 Xianghua
137 138 Xianghua Edit

141 142 Lizardman
149 150 Lizardman Edit

153 154 Yoshimitsu
161 162 Yoshimitsu Edit

165 166 Nightmare
173 174 Nightmare Edit

177 178 Astaroth
185 186 Astaroth Edit

189 190 Cervantes
197 198 Cervantes Edit

201 202 Raphael
209 210 Raphael Edit

213 214 Talim
221 222 Talim Edit

225 226 Cassandra
233 234 Cassandra Edit

237 238 Yun Seong
245 246 Yun Seong Edit


249 SC2 Lizardmen (red)

255 256 Setsuka
263 264 Setsuka Edit

267 268 Tira
275 276 Tira Edit

279 280 Zasalamel
287 288 Zasalamel Edit

291 292 Olcadan
299 300 Olcadan Edit

303 304 Abyss
311 312 Abyss Edit

315 Night Terror

///////////////////////////////////////////////////////////////////////////////
// Standard Animation data
///////////////////////////////////////////////////////////////////////////////

577 Mitsurugi Moveset
578 Mitsurugi Exhibition

579 Seong Mina Moveset
580 Seong Mina Exhibition

581 Taki Moveset
582 Taki Exhibition

583 Maxi Moveset
584 Maxi Exhibition

585 Voldo Moveset
586 Voldo Exhibition

587 Sophitia Moveset
588 Sophitia Exhibition

589 Siegfried Moveset
590 Siegfried Exhibition

591 Rock Moveset
592 Rock Exhibition

593 Ivy Moveset
594 Ivy Exhibition

595 Kilik Moveset
596 Kilik Exhibition

597 Xianghua Moveset
598 Xianghua Exhibition

599 Lizardman Moveset
600 Lizardman Exhibition

601 Yoshimitsu Moveset
602 Yoshimitsu Exhibition

603 Nightmare Moveset
604 Nightmare Exhibition

605 Astaroth Moveset
606 Astaroth Exhibition

607 Cervantes Moveset
608 Cervantes Exhibition

609 Raphael Moveset
610 Raphael Exhibition

611 Talim Moveset
612 Talim Exhibition

613 Cassandra Moveset
614 Cassandra Exhibition

615 Yun Seong Moveset
616 Yun Seon Exhibition

617 Setsuka Moveset
618 Setsuka Exhibition

619 Tira Moveset
620 Tira Exhibition

621 Zasalamel Moveset
622 Zasalamel Exhibition

623 Olcadan Moveset

624 Abyss Moveset
625 Abyss Exhibition

626 NightTerror Moveset

///////////////////////////////////////////////////////////////////////////////
// Bonus Model data
///////////////////////////////////////////////////////////////////////////////

627 628 Charade

629 630 Charade Legs

631 632 Charade Eyeball

633 634 Will' o' the' wisp (red)
635 Will' o' the' wisp Green
636 Seong Mina

637 638 Doppleganger

639 640 ShadowMaster

641 642 Amy

643 644 Colossus

647 648 Zasalamel (Old Man)
655 656 Zasalamel (Old Man) Edit

645 646 SC2 Lizardmen (yellow)

659 660 Lizardman (w/ Crown)
667 668 Lizardman Edit (w/ Crown)

671 Lizardman (w/ Voldo's mask)

681 Colorful Lizardman w/ no tail

682 Red/Green Lizardman w/ no tail

705 706 Miser

709 710 Greed

713 714 Arthur

717 718 Hwang

721 722 Luna

725 726 Valeria

729 730 Hualin

733 734 Girardo

737 738 Demuth

741 742 Arelia

745 746 Chester

749 750 Strife

753 754 Abelia

757 758 Lynette

761 762 Li Long

765 766 Revenant

769 Lynette

771 Valeria

773 Hualin

775 Berzerker

777 778 Samurai

781 785 Gladiator

789 793 797 Unknown Soul

801 805 806 809 810 811 812 FumaNinja

813 817 818 Bandit

821 Thief

825 Thief

829 830 831 833 836 Pirate

837 Assassin

841 Swordsman

845 FootSoldier

849 840 General

853 Sentrey

857 Kares

861 Dragon

865 868 872 878 Ninja

881 883 905 923 Assassin

897 899 913 Samurai

937 Sage

983 Night

1073 Dancer

1107 Gladiator

1114 Assassin

1123 Night

1124 1125 1126 Pirate

1129 1130 1131 Night

1137 1138 Abelia

1139 Abelia in Pink Dress

1140 Unused Female CaS model

1144 Unused Male CaS model (has female voice)

1146 Girardo

1148 Unused female CaS model (has male voice)

1151 Thief

1154 Demuth

1158

1163

1165 Ella

1171 Rellen

1172 Rowan

1174 Keerkes

1178 Mooncalf

1180 Ende

1181 Scrapped CotS character model

///////////////////////////////////////////////////////////////////////////////
// Bonus Animation data
///////////////////////////////////////////////////////////////////////////////

1392 Amy moveset

1393 Collossus Moveset

1394 Lizardman Prototype Moveset

1395 Hovering in the air (unplayable)

1396 Revenant Prototype (unplayable)

1397 Miser Moveset

1398 Greed Moveset

1399 Arthur Moveset

1400 Hwang Moveset

1401 Luna Moveset

1402 Valeria Moveset

1403 Hualin Moveset

1404 Girardot Moveset

1405 Demuth Moveset

1406 Aurelia Moveset

1407 Chester Moveset

1408 Stife Moveset

1409 Abelia Moveset

1410 Lynette Moveset

1411 Li Long Moveset

1412 Revenant Moveset

1413 Standing Stance

///////////////////////////////////////////////////////////////////////////////
// Stage data (incomplete)
///////////////////////////////////////////////////////////////////////////////

File 5.olk:

1 - Mountain Top
15 - Egyptian Temple Ruin
22 - Egyptian Temple (Minimum)
29 - Egyptian Temple (Minimum & Cage)
41 - Clock Tower

239 - Underground Buddhist Sanctum

273 - Grand Labyrinth
280 - Grand Labyrinth (Darkness)
287 - Grand Labyrinth (Corridor)
299 - Sacred Mt. Fuji - Lava bed
313 - Lost Cathedral - Ruin
327 - Pirate Raid
341 - Jyurakudai Villa
355 - Romanian Valley - Castle Siege
369 - Lotus Garden
383 - Old Toledo Burning Gallery
397 - Silk Road Ruin
411 - Chaos - Spiritual Realm

425 - Weapons & Armor Room

432 - Weapons Shop
439 - Armor Shop
446 - Items Shop

747 - Game Menu 'Water'
761 - Start Screen 'Soul Calibur 3 Logo'
775 - CaS Mode 'Blue Flying Rocks'

mariokart64n
ultra-veteran
ultra-veteran
Posts: 527
Joined: Sun Jun 05, 2005 12:00 pm
Location: Ontario, Canada
Has thanked: 23 times
Been thanked: 161 times
Contact:

Re: Soul Calibur 3 Modding

Post by mariokart64n » Tue Dec 28, 2010 10:32 am

SC2 is easier to mod, I was trying to get the models from SC3, but they're stored funny
Research: [DOA2U] [DOA5U]

pringerx
ultra-n00b
Posts: 3
Joined: Thu Jan 06, 2011 7:18 pm
Been thanked: 1 time

Re: Soul Calibur 3 Modding

Post by pringerx » Thu Jan 06, 2011 9:18 pm

I'm very interested in getting my hands on SC3 models as well, and I could barely found anything about its model format, so I've been cracking at it for the last few days. Here's what I've documented so far... (massive infodump incoming)

At the start of each model file is some unknown data, then shader/material data which are float arrays, then more unknown data, then the start of the mesh data, which takes up the majority of the file.

Mesh data:
01010001 = Start of object

There are 2 different types of mesh data.

TYPE 1:
Type 1 has multiple sets of data separated by data type as follows:

0380xx6C = Vertices (xx = Number of entries of the specified type)
0480xx68 = Normals

0280xx6C
-or- = ? (xx is the same as the number of verts and normals)
0280xx60

0180xx64 = Texture coords

With the 0280xx60 type, all entries are 00000043 (just 4 bytes).
With the 0280xx6C type, entries are 16 bytes and always end with 00000043, but the preceding three sets of 4 bytes are
a. Always identical
b. Either 00000043 OR
xxxxxxyy
where xxxxxx a value like 000080, CDCCCC, 9A9999, etc.
and yy is either 42 or 41.

The complete header is as follows:

01010001 0080016C xx800000 00403E30 12040000 yy000000 04010001 DataType

xx is some non-unique integer; my initial guess was that it's a shader/texture reference, but changing it either had no result or created strange rendering glitches, so I'm not sure.
yy is either 0F or 0E. Not sure if it's significant.
DataType is one of the various 0x80yy6z formats above.

TYPE 2:
Type 2 objects always have the data type 0080xx6C.

Type 2 is used for the majority of mesh data, and puts the normal, texture, bone index, and bone weight data together with each vertex in chunks like so (each line is 16 bytes):

VertX VertY VertZ Weight
NormX NormY NormZ BoneIndex? [ChunkEnd]
TexX TexY 1.0 Connection
00000043 00000043 00000043 00000043

BoneIndex is weird. At first glance it appears to be a one-byte int bone index, however the values are always multiples of four; knowing this I figured it might actually be a 6-bit integer just shifted left. However, changing this to non-multiples of 4 resulted in the vertices attaching to other, valid bones, so it must be getting translated somehow. Also, there aren't enough indices being used versus the number of bones in the model; for example, in Tira's model there are only 28 different indices used, which is maybe enough for one complete arm.

(ChunkEnd explained in a second)

The texture coordinates are always followed by a 0000803f, and then either a 00 or 01. This is simply connection data; polygons are connected in order for vertices (i-1,i,i+1) except when the connection data for i+1 is 01. (Vertices with 01 as connection data always come in pairs.)

Each chunk simply ends with 00000043 00000043 00000043 00000043.

It would be nice and simple if it stuck to this format, but when multiple bone weights are defined per vertex, suddenly the chunks have multiple vertex/normal line pairs, like so:

VertLine
NrmLine
[VertLine
NrmLine]...
TexLine
(Terminator)

In this case, the vertices and normals are actually different in each line pair. This is really bizarre, but looking at the weight data it's apparent that they always add up to one for each chunk. So, the different vertices and normals must somehow be relational to the bones they reference. From what I can tell from tweaking these positions, each vertex position is actually local to the bone referenced, using the bone's local coordinate space as well; this was obvious since modifying the x value of each coordinate resulted in different movements in world space. This is pretty much verified if you try to read the verts as being in world space, as you end up with a mass that's twisted and curled in on itself around the origin:

Image

(That's Tira's torso.) But look, the UVs are perfect!

Image

Finally, ChunkEnd simply notes the end of the vert/normal pairs in each chunk; it is 80 on the last pair, otherwise it is 00.

The complete header for this type of object is shorter than the first:

01010001 DataType xx800000 00403E30 12040000 yy000000

xx is presumably the same as in the header for the first object type (whatever it is).
yy, instead of 0F or 0E, is either 00 or 01.


Joint/Skeleton data

Here's where stuff gets hazy. First of all, the bone data starts immediately after the model data without any apparent header, so I'm not sure if there's something that tells how many mesh pieces there are or what. As for the joint format… I have no idea what most of this stuff is, so here's an example of one joint's data chunk:

F90609B3 CA9100B3 1F03B3B1 0000803F
00000000 00000000 04ADC08A 0000803F
00000000 00000080 0000803E xxxx1400
0000803F 0000803F 00000000 ??aabbcc

Line 1: Don't know.
Line 2: Position in local coordinate space
Line 3: Don't know. xxxxxx is some non-unique integer, generally counts upward over length of bone data
Line 4: This is bone bb, whose parent is aa. Root bones have a parent of FF. It seems that if this bone is physics-enabled, ?? is filled with another integer. cc appears to be some sort of group value, as related joints have the same value here (eg. 02 = hands, 03 = face).

After the bone data there's some more unknown data (more increasing integers), and then what I assume is texture data.

*Phew*

OK, so what's really stumping me right now is how the bone indices given in the model data are related to the skeleton. If anyone has ideas, I'm all ears. I'm pretty sure this is the only (big) thing left to solve before I can take a stab at writing a proper translator for the meshes. (I already wrote a crappy one, which is how I obtained the mess above.) Also this is the first time I've ever done this sort of stuff, so there's a good chance I'm missing some really obvious things :)

mariokart64n
ultra-veteran
ultra-veteran
Posts: 527
Joined: Sun Jun 05, 2005 12:00 pm
Location: Ontario, Canada
Has thanked: 23 times
Been thanked: 161 times
Contact:

Re: Soul Calibur 3 Modding

Post by mariokart64n » Thu Jan 06, 2011 11:09 pm

when I asked fatduck to look into it, his attempt looked imploded.. something appeared to be influencing the mesh positions.

is that what your seeing aswell? or are they whole parts, just the parts are rotated and centered to origin. guess we need to figure out bones and weights :\ soo close ^,^

good work by the way.
Research: [DOA2U] [DOA5U]

pringerx
ultra-n00b
Posts: 3
Joined: Thu Jan 06, 2011 7:18 pm
Been thanked: 1 time

Re: Soul Calibur 3 Modding

Post by pringerx » Fri Jan 07, 2011 12:53 am

Yeah, it was like all the individual vertices were imploded around the origin. From messing around with vertex and joint positions my best guess is that the joints are oriented with the x-axis forward (toward the next joint), and then the vertex positions use the bone's local coordinate space.
Basically, I figured out where a vertex was on the model, and then by looking at other nearby vertices, made a guess as to what each of the bones listed were (spine,shoulder,whatever). Then, whenever I tweaked the x position of the vertex, it would always move forward along the bone, and tweaking the y position always resulted in vertex moving tangent to the bone. So I'm pretty confident that this is how they're stored.

falconcool
veteran
Posts: 87
Joined: Tue Jun 16, 2009 4:41 am
Has thanked: 11 times
Been thanked: 6 times

Re: Soul Calibur 3 Modding

Post by falconcool » Tue Jan 18, 2011 12:21 pm

TYPE 2:
Type 2 objects always have the data type 0080xx6C.

Type 2 is used for the majority of mesh data, and puts the normal, texture, bone index, and bone weight data together with each vertex in chunks like so (each line is 16 bytes):

VertX VertY VertZ Weight
NormX NormY NormZ BoneIndex? [ChunkEnd]
TexX TexY 1.0 Connection
00000043 00000043 00000043 00000043


(ChunkEnd explained in a second)

The texture coordinates are always followed by a 0000803f, and then either a 00 or 01. This is simply connection data; polygons are connected in order for vertices (i-1,i,i+1) except when the connection data for i+1 is 01. (Vertices with 01 as connection data always come in pairs.)
Do you mean mutiple vertex share same uv coordinate data here?
Each chunk simply ends with 00000043 00000043 00000043 00000043.
It changes a lot in this part,not always 00000043
It would be nice and simple if it stuck to this format, but when multiple bone weights are defined per vertex, suddenly the chunks have multiple vertex/normal line pairs, like so:

VertLine
NrmLine
[VertLine
NrmLine]...
TexLine
(Terminator)

In this case, the vertices and normals are actually different in each line pair. This is really bizarre, but looking at the weight data it's apparent that they always add up to one for each chunk. So, the different vertices and normals must somehow be relational to the bones they reference. From what I can tell from tweaking these positions, each vertex position is actually local to the bone referenced, using the bone's local coordinate space as well; this was obvious since modifying the x value of each coordinate resulted in different movements in world space. This is pretty much verified if you try to read the verts as being in world space, as you end up with a mass that's twisted and curled in on itself around the origin:

Finally, ChunkEnd simply notes the end of the vert/normal pairs in each chunk; it is 80 on the last pair, otherwise it is 00.

The complete header for this type of object is shorter than the first:

01010001 DataType xx800000 00403E30 12040000 yy000000

xx is presumably the same as in the header for the first object type (whatever it is).
xx likely uv coordnate numbers in this chunck, but have no idea about yy
[/quote]
yy, instead of 0F or 0E, is either 00 or 01.



Great job,,i'm glad someone is still digging SC3's models:)

fatduck
mega-veteran
mega-veteran
Posts: 315
Joined: Wed Aug 02, 2006 10:07 pm
Has thanked: 10 times
Been thanked: 93 times

Re: Soul Calibur 3 Modding

Post by fatduck » Tue Jan 18, 2011 2:31 pm

As far as I can remember, the struct of the mesh chunk ??010001 ??80???? is like this

Code: Select all

struct Mesh {
  byte          numData
  byte          ukn02         //01
  byte          ukn03         //00
  byte          ukn04         //01
  struct Data {
    byte        DataType      //1 = UV, 3 = coordinate, 4 = normal
    byte        Const0x80
    byte        DataCount
    byte        BytesPerData  //0x60 = 4-bytes, 0x64 = 8-bytes, 68 = 12-bytes, 0x6C = 16-bytes
    <Data>
  }
}

and the coordinates are base one bone reference. You need to use "matrix palette skinning" to transform the coordinate back to the proper position(I was stuck on this)!
Unfortunately, I lost 90% of work on this game, so I can't help!

a picture for your reference:
Clipboard01.jpg
You do not have the required permissions to view the files attached to this post.
No more Fatduck, no more FatImporter, Byebye everyone!

falconcool
veteran
Posts: 87
Joined: Tue Jun 16, 2009 4:41 am
Has thanked: 11 times
Been thanked: 6 times

Re: Soul Calibur 3 Modding

Post by falconcool » Thu Jan 20, 2011 12:33 am

The texture coordinates are always followed by a 0000803f, and then either a 00 or 01. This is simply connection data; polygons are connected in order for vertices (i-1,i,i+1) except when the connection data for i+1 is 01. (Vertices with 01 as connection data always come in pairs.)
Do you mean mutiple vertex share same uv coordinate data here?
I've extracted vertices data,but can't figure out how to draw polygons.
here is an example picture,would you please draw triangle to show how these vertices with 01 marked
been connected,TYVM

Image
Image

pringerx
ultra-n00b
Posts: 3
Joined: Thu Jan 06, 2011 7:18 pm
Been thanked: 1 time

Re: Soul Calibur 3 Modding

Post by pringerx » Thu Jan 20, 2011 10:53 pm

falconcool wrote:Do you mean mutiple vertex share same uv coordinate data here?
The chunks with "multiple" vertices in fact represent one single vertex; each coordinate is local to the bone indexed in the second line (with the normal data). I have no idea why it's stored this way though...

So for the polygons, just connect them as described previously: For any vertex i, make a polygon with vertices i-1 and i+1 except when the connection data for vertex i+1 is set to 1. Actually, this isn't the exact solution, since half of the polys come out with their normals reversed, but this is easily correctable in pretty much any modelling software so it's pretty low priority ;)
falconcool wrote:It changes a lot in this part,not always 00000043
I totally forgot about that when I was writing it. That's another thing I haven't figured out yet.
fatduck wrote:Unfortunately, I lost 90% of work on this game, so I can't help!
That sucks... it looks like you were really close, too!
fatduck wrote:and the coordinates are base one bone reference.
Could you clarify this? I'm currently stumped by how the mesh data references the bones, both in this type of mesh data and the other.

As for the matrix transformations, I understand how they work in principle but I can't figure out how (what I'm assuming are) the matrices are stored in the bone data. There doesn't seem to be any pattern consistent with how matrix transforms are normally represented, and then there are these totally random (extremely large) numbers thrown in sometimes...

Also, while I haven't really made any progress with decoding the joint data, I did find some other useful data in the model files (mostly pointers to where various groups of data are located), which makes it possible to simply process the whole model file at once. I'll post that as soon as I get the info organized...

Edit:
OK, the model file header looks like this:
090E1C0B 00000201 aa00bb00 cccc0000

aa - unknown
bb - the total bone count for the model (odd that it's up here, but handy)
cccc - unknown integer, though it seems to correlate directly to the file size (probably unimportant)

- After that, 16 empty bytes.
- Then, a 4-byte offset where the joint information begins (yay, useful!)
- Then another 4-byte offset to the (unknown) information immediately following the joints
- Then 00010000
- Then another 4-byte offset to some more unknown data near the beginning of the file.

Then there are several more offsets like these, all pointing to various data sets in the file, which seem unimportant. I also found that the list before the model data points to every individual mesh piece in the file.

zombiemkii
ultra-n00b
Posts: 3
Joined: Fri Sep 04, 2009 9:40 pm
Has thanked: 1 time

Re: Soul Calibur 3 Modding

Post by zombiemkii » Tue Sep 13, 2011 1:28 pm

:?:Any progress ?

User avatar
zaramot
double-veteran
double-veteran
Posts: 717
Joined: Wed Jan 05, 2011 12:41 pm
Has thanked: 39 times
Been thanked: 766 times

Re: Soul Calibur 3 Modding

Post by zaramot » Mon Sep 08, 2014 3:00 pm

Hi guys! Always was a fan of Soul Calibur series. So, decided to try this awful and complex format. I already obtained some meshes, and tried to import bones. Almost all, is understandable here, but for some reason - I can get proper skeleton. Here's the pic

Image

Need some help now, maybe someone could help me with this :) Here couple samples and script to import bones into 3ds max

https://www.mediafire.com/?rg2z78g8im6cnbd
Making model-import scripts, PM

mariokart64n
ultra-veteran
ultra-veteran
Posts: 527
Joined: Sun Jun 05, 2005 12:00 pm
Location: Ontario, Canada
Has thanked: 23 times
Been thanked: 161 times
Contact:

Re: Soul Calibur 3 Modding

Post by mariokart64n » Mon Sep 08, 2014 6:09 pm

Lol i figured out the skeleton format last month then was struggling to parse the mesh data...

... And omg here is the mesh format lol

I'd complete my importer but looks like all the info is here now :)

good luck guys
Research: [DOA2U] [DOA5U]

fatduck
mega-veteran
mega-veteran
Posts: 315
Joined: Wed Aug 02, 2006 10:07 pm
Has thanked: 10 times
Been thanked: 93 times

Re: Soul Calibur 3 Modding

Post by fatduck » Mon Sep 08, 2014 9:23 pm

zaramot, I had a quick look on your maxscript.
your bone rotation is not correct!!!
c31 = ReadFloat f*3.0; c32 = ReadFloat f*5; c33 = ReadFloat f*4.0;
...
tfm = (quat c31 c32 c33 -1) as matrix3
it should be:
c31 = ReadFloat f*360 ; c32 = ReadFloat f*360 ; c33 = ReadFloat f*360;
...
tfm = (eulerToQuat (eulerAngles c31 c32 c33) ) as matrix3
No more Fatduck, no more FatImporter, Byebye everyone!

User avatar
zaramot
double-veteran
double-veteran
Posts: 717
Joined: Wed Jan 05, 2011 12:41 pm
Has thanked: 39 times
Been thanked: 766 times

Re: Soul Calibur 3 Modding

Post by zaramot » Mon Sep 08, 2014 9:34 pm

Thanks a lot Fatduck! How could I miss this, I knew rotation was wrong, but I couldn't even imagine they were euler
Making model-import scripts, PM

Post Reply