Talk:Mod Tool

Old dev notes

Just keeping the notes here for the unlikely case that I will continue work on that OniTool addon someday again.

New door animations

Final door animation depends on:

• BINACJBODOOR position and rotation
• OBAN positions and rotations
• ZAxisUp (Does this flag do something else?)

Theory of the (Oni to ModTool) import from scratch:

• import BINACJBODOOR
• get door classes
• extract M3GM from DOOR, etc.

• import M3GM
• move center to lower bounding box Z
• move object to Z = 0
• import OBAN
• apply rotations and positions to object

• create null object
• make null a parent of door object
• rotate null in X = -90 (to make Z axis pointing up)
• add BINACJBODOOR rotation and position to null object

The current version of onisplit (v0.9.68.0) imports the doors from AKEV without animations.

Those door have there centers at the lower bounding box Z, got corrected from their ZAxisUp, and have (BINACJBODOOR) rotation and position.

Writing an own combined import would not only take more time, also it wouldn't be so fast and efficient. So, I will go with the existing import but then do some changes on the doors (appling null object, custom properties, etc.)

The door objects can be identified by their naming. Each name contains the BINACJBODOOR ID, e.g. <DOOR Id="7294">.

There could be a loop scanning all objects for those numbers.

Hierarchy builder for characters

Based on old knowledge. See HERE for an easy manual way to change the meshes in hierarchies.

(old notes in the following)

hierarchy breaker beta

(Automatic rigging.) Maybe null objects could stand for the centers of body parts. Then one click and the real centers gets positioned. The rotations are known and the names would lead to the correct hierarchy.

In order to make edits there is also a need of destroying the hierarchy again while preserving the rotation and position of the meshes.

code pieces

hierarchy breaker

• hierarchy_breaker_beta.txt (works only with strict correct names)

hierarchy builder

• delete_keyframes.txt (deletes keys, saves and reloads character)
• [...]

Keyframe affects hierarchy building

situation: "cube" and "cube1" were created

• case 1:
  • apply 45° y rotation to cube
  • make cube1 a child of cube
  • cube1 will not inherit the 45°

• case 2:
  • apply 45° y rotation to cube
  • make rotation keyframe for cube1
  • make cube1 a child of cube
  • cube1 inherit the 45°

• case 3:
  • apply 45° y rotation to cube
  • make rotation keyframe for cube1
  • remove that keyframe again
  • make cube1 a child of cube
  • cube1 inherit the 45°

• case 4:
  • apply 45° y rotation to cube
  • make rotation keyframe for cube1
  • remove that keyframe again
  • save both cube to a dae file
  • make new scene and load dae
  • make cube1 a child of cube
  • cube1 will not inherit the 45°

Case 1 might be a bug (case 4 is a variant of it) but it simplify the hierarchy creation.

While doing those test you can observe red letters next to the meshes in the Schematic window.

A means the presence of keyframes. Removing the keyframe doesn't remove the A. Object must be saved and reloaded.

D means that mesh center was changed by rotation or translation (center mode) or by clicking Transform > Freeze(...). D can be removed by clicking the normal Freeze button. Yea, whatever...

C can be seen next to camera objects, present when Camera_Interest is horizontal attached to it.