XeNTaX

so is the tool ready? can we now take models out of tfu????

any body? so is the tool ready yet? and be so kind as to tell how to use it too

reappper wrote:any body? so is the tool ready yet? and be so kind as to tell how to use it too

Yes, in this post.

And please, don't dubleposting here.

Szkaradek123 wrote:Blender importer for models from Star Wars The Force Unleashed .
(Blender 249 and Python 2.6.)

Hi, Szkaradek123. Please tell me more detail how to automatically apply textures, because when i jointing (ctrl+J, maybe?) all objects and then importing in 3ds max (trough the psk), i gets only one material.

ok so I manage to get the models out of tfu now have we work on getting the rigs out? like the bones?

You wait for the experts to make a script.

I am posting this link because I have had many requests for the tutorial I have made about extracting a Storm Trooper from Star Wars The Force Unleashed. Your suggestions and comments would be greatly appreciated.

http://uberblack3d.com/articles/storm-t ... -tutorial/

so is this project dead or what? have we finally got bones no?? tired of waiting

The Force Unleashed plugin for Noesis has been updated: http://oasis.xentax.com/index.php?content=plugins

Fixes a bug with gto models and adds support for the .animations files.

If i get the chance i will try and put together documentation to supplement rogueclarkey's description earlier in the thread.

Have fun.

revelation wrote:The Force Unleashed plugin for Noesis has been updated

thank you revelation

revelation wrote:The Force Unleashed plugin for Noesis has been updated: http://oasis.xentax.com/index.php?content=plugins

Fixes a bug with gto models and adds support for the .animations files.

If i get the chance i will try and put together documentation to supplement rogueclarkey's description earlier in the thread.

Have fun.

It's been a long time coming.. thanks for letting me test it.

Well i was asked about how to interpret the information within the .animations file, and i had not gotten around to coming back to this thread, so i guess i shal do a quick and dirty explaination of things. Hopefully it will be enough to get those interested started in looking into the data (assuming i can express it clearly enough).

The animations files are structured into the following sections:
The HEADERS section can consist of up to 4 different headers:
The PACK_HEADER follows the R2D2pack header if it is present.

The ANIM_HEADER follows the R2D2mult header.

The data sizes in the R2D2pack and R2D2mult headers is used to access the name strings in a slightly peculiar way in the code. Using the the values starting from the begining of the data blocks that follow these headers actually takes you to the end of the string. But if you read the byte prior to this point, add 2, and subtract it from this end offset you can obtain an offset to the beginning of the string that specifies the name of the animations file and the animation pack file (.r2a) respectively.

The ANIM_HEADER is treated as somewhat of a split data structure in the code, the second portion starting at the location of the unknownSize0x24 value. This value contains an offset from this point to the beginning of the data section that follows. In all of the files i have investigated so far this has always been 0x1C, but my assumption is that the data section may have alignment requirements (on a 32-byte boundary?) and this value would contain the offset to the aligned position of the data should it not follow directly after the ANIM_HEADER. But for the most part i have not seen this needed, so i mention it solely to be complete.

The ANIM_HEADER jointInfoOffet and jointFramesOffset are relative to the beginning of the JOINT_KEYFRAME_DATA that follows the header.

The layout of the JOINT_KEYFRAME_DATA relies heavily on the flags specified in the JOINT_KEYFRAME_INFO structure that follows it, as does the JOINT_KEYFRAME_INDICEIS. So i will describe that first:
This section is a list of ANIM_HEADER.jointCount structure that define the data layout of each joints keyframe data and indices. Joints do not have to be present for every one that is in the model file. Since the animation it initialized with the base pose transforms, these joint will just not be modified.

The framesOffset and dataOffset values are relative to the JOINT_KEYFRAME_INDICES and JOINT_KEYFRAME_DATA sections respectively. The jointHash is a simple crc value based on the actual joint name from the model file.

The real important piece of information in this structure are the formatFlags. They specify whether or not the keyframe data is bit packed or not, whether it is 32-bit floats or 16-bit short values, whether position or rotation data is even present, which components of the position and rotation are valid, as well as what form the keyframe indices are in (8-bit byte, 16-bit short, 32-bit float).

The formatFlags can be assumed to have this format:
The idxFormat determines the data size of the individual elements of the joints keyframe indices and can have the following values:
Animations are 30 frames per second, so for the non-float frame index values simply divide by 30 to get the float time in seconds, or the reverse by multiplying the float frame times by 30 to get the fram index.

The posFormat and rotFormat specify the data type of the position and roation values (if present):
16-bit data values are normalized by dividing by 32767.

The dataFlag specifies if position, rotation, or both of them are present:
The rotFlag and posFlag specify how to interpres the rotLayout and posLayout respectively;
When the rotFlag or posFlag bits are not set (0) then the respective Layout values can be:
The Layout values should match the Format values for their respective components.

When the rotFlag or posFlag are set the rotLayout and posLayout are 3 separate bit values each for the x, y, and/or z component that is present in the data.
With 0 being the least significant bit, etc.

When data is bit-packed the rot- and pos- Flag bits should be set if the dataFlag specifies they are present.

Reading the data from the JOINT_KEYFRAME_DATA section requires the information above. When the data is not bit-packed the process if fairly straight forward. Rotation and position components are packed ones after the other: pos0,rot0,pos1,rot1,...etc. Assuming the dataFlag specifies they are present.

The skeleton for an animation is initialized using the base pose information from the model. If data is not specified for a joint based on the flags information, then the values are not overwritten during processing.


- Bit Packed Data -

Bit-packed data complicates things slightly as the data is tightly packed into a big-ending ordered bit stream, where the components of the position and rotation components can be variable bit sizes which are specified in the data itself.

If position data is present the first 4 bytes are a 32-bit floating point scaling value for the position information.

Following this are up to (18) bytes of data used to specify the base values and bit-sizes for the position and rotation xyz components. The presence of these values is controlled by the xyz bits in the posLayout and rotLayout respectively.

The values are used to specify the base values and bit sizes of each component of the position and rotation values.

The order is as follows:
These are specified for both the position and rotation data if specified as present. The 'base' values are 16-bits each, the 'bitSize' values are 8-bits each (3 * 2-bytes + 3 * 1-byte == up to 9 bytes each for position and rotation == up to 18-bytes).

The individial components will not be present if the corresponding bit is not set in the respective Layout values from the joint data flags.

So if bit 0 is not set for posLayout, then the z-component of the positions are not present (basePosX, basePosY, bitSizeX, bitSizeY). The rotation values are handled in the same manner using the respective flags and format information.

Following this information is framesCount number of bit packed values for the components specified as being present. The bit stream is read a big-endian data in x,y,z order for position then rotation for the compoents that are valid. The bitSize values specify the number of bits to read for each component from the stream.

The final value for each component is calculated using the following function: All the values are treated as signed 16-bit values.

Since only 3 components of the rotation are specified the w value is found through standard normalized quaternion methods.



Well that was simply a brain dump of how to interpret the animation data. i am not entirely sure if it will make sense to anyone as i have written it, so feel free to ask for clarification on anything if needed.

Hope it helps.

Thanks a lot revelation

UberBlack wrote:

Quick Render in Maya

quick question if thats ok how did you get it in a T-pose? when i import they are A-pose

Hi, i want to translate game. How can i do this?

so we ever figure out how to edit the xml.z files?