OniGalore

Mod Tool: Difference between revisions

Page Discussion

Mod Tool (view source)

Revision as of 19:09, 30 March 2014

4,366 bytes removed ,  30 March 2014
m
del/moving a few notes
m (roadmap notes)
m (del/moving a few notes)
Line 1,935: Line 1,935:
* character auto-rigger
* character auto-rigger
* character exporter (TRBS/TRMA/TXMP)
* character exporter (TRBS/TRMA/TXMP)
The following sections feature some thoughts/code about those and other ideas.




Line 2,055: Line 2,053:
* making loops from parts of animations
* making loops from parts of animations
* copying animation data from one character to another
* copying animation data from one character to another
=====Selection tracking camera=====
* https://dl.dropbox.com/u/139715/auto_selection_tracking.txt
' enable automatic tracking
set_auto_tracking ("yes")
' disable automatic tracking
set_auto_tracking ("no")
There could be other buttons to jump to previous/next object grouped under their parent.
SelectNeighborObj , 2
SelectNeighborObj , 3




Line 2,250: Line 2,235:
  ' INFO  : counted body parts: 19
  ' INFO  : counted body parts: 19
{{divhide|end}}
{{divhide|end}}
=====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 [[Mod_Tool#exchange_of_meshes_in_hierarchies|HERE]] for an easy manual way to change the meshes in hierarchies.
'''(old notes in the following)'''
{| border=0 cellpadding=0 style="float: right;"
| hierarchy breaker beta<br>[http://i305.photobucket.com/albums/nn207/unknownfuture/Oni_Galore_Images/3D_modding/hierarchy_breaker_beta.png http://i305.photobucket.com/albums/nn207/unknownfuture/Oni_Galore_Images/3D_modding/hierarchy_breaker_beta_tn.png]
|}
(Automatic rigging.) Maybe null objects could stand for the centers of body parts. Then one click and the real centers gets positioned. The [[User:Paradox-01/for_WIP_pages#Mod_Tool:_putting_a_character_together_while_preserving_body_part_positions|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
* [https://dl.dropbox.com/u/139715/OniGalore/ModToolScript/hierarchy_breaker_beta.txt hierarchy_breaker_beta.txt] (works only with strict correct names)
hierarchy builder
* [https://dl.dropbox.com/u/139715/OniGalore/ModToolScript/delete_keyframes.txt 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.




Paradox-01
8,452

edits

Retrieved from "https://wiki.oni2.net/Special:MobileDiff/23397"