Deformable2
-
Hello,
I’ve been attempting to trawl through Dfm files, and have managed to get the basics of showing the model up and running (currently testable in LancerEdit).
I’ve had a hiccup in working with bones though.
/Skeleton/Name references a non-existent “Head02.cmp” I attempted replacing /Skeleton/Name with garbage values to enduce a crash to no avail (@adoxa is this value even read?)Composing the compound parts for the bone parts doesn’t seem to produce anything useful. “Bone to root” matrices by themselves or combined (transposed or otherwise) also don’t seem to be doing the trick for getting something that looks like a skeleton.
Any ideas?
-
DFM constraints header contains three names: parent (0x40), child (0x18), bone (0x28). Rigid compound hierarchies constraints only have two names for parent (0x40) & child (0x40). So reading DFM constraints list as you would rigid compound would yield only two names as you’d normally stop string at NUL terminator, and completely miss third one.
-
Ichiru wrote:
/Skeleton/Name references a non-existent “Head02.cmp” I attempted replacing /Skeleton/Name with garbage values to enduce a crash to no avail (@adoxa is this value even read?)Doesn’t look like it.
@Treewyrm: can you elaborate? I never noticed a “bone” entry when doing the XML converter.
-
There does seem to be 3 strings in the Cons section for dfm, but only in the Loose section.
Reading with the 64 byte/24 byte/40 byte buffers for example br_quigly_head.dfm gives entries like:
Head01/LOBR/B_Left Top Lip
Head01/LMBR/LOBR
Head01/B_SplineBone 9A/B_SplineBone 8BThese are not present in the humanoid bodies which only seem to use sphere joints, but are present in the loose joints in worm.dfm
Combining this information with “Bone to root” in some way that gives meaningful output is another thing
-
Had a few observations while parsing and digging through DFM recently.
Regular rigid compound model constraint data typically contains two strings of fixed length (64 bytes each) per each joint: parent and child object names. DFMs use spherical and loose constraints, but their header contains more than just two zero padded strings. With some it’s pretty clear there are three strings: parent (64 bytes), child (24 bytes) and another child (40 bytes). Worth to note sometimes parent string contains some junk after nul terminator, but the layout of 64/24/40 for triple strings remains common across.
Perhaps biped skeleton for bodies and hands might be hardcoded elsewhere, perhaps in dll, and not contained within DFM but heads and nomad worm aren’t, so they have to have custom rigging somewhere in the file.
-
I converted all the [c]CHARACTERS[/c] XMLs back to UTF in another directory, swapped that directory with [c]DATA\CHARACTERS[/c], copied back the ini files, and started FL. Characters showed up fine. Thus [c]child[/c] really is 64 bytes and you’re just seeing garbage that happens to look valid.
-
Turns out after deleting the .anm files from my install that the .dfm files for bodies don’t actually store a bind pose in their bones.
However the animations in bodygenericmale.dfm etc. are of different types to the other anm scripts.
You’ll find Channel type 128 (3rd integer in /Script/name/Joint map/Channel/Header) in these scripts. Type 1 is a single float, type 4 is a quaternion, but I’m not sure about type 128. It doesn’t seem to have an equal amount of bytes per frame. In some cases it seems to be 10 bytes per frame (joint maps with 2 or 16 frames). In other cases it seems to be left (Joint map 17 in Sc_MLBODY_CHRB_GRABR_PRDRNK_TABL_000LV_XA_08 has 1542 bytes of frame data for 257 frames, definitely not a multiple of 10).
-
They’re three 16-bit integers divided by 32767 to make three floats (have a look at [c]channel.cpp[/c] in the XML Project source).
-
Further poking and strings and wild guesses seem to indicate it’s some sort of input for inverse kinematics (with maybe child name pointing to the end effector?).
