OniSplit/WIP: Difference between revisions

OniSplit/WIP (view source)

Revision as of 00:39, 23 January 2022

221 bytes added , 23 January 2022

→‎v1.0 (WIP): alpha 6

Geyser

Administrators

5,389

edits

@@ Line 1: / Line 1: @@
 ==v1.0 (WIP)==
-::Really? Yes, really. Get the nightly [http://geyser.oni2.net/OniSplit/1.0a5_2022.01.09/ HERE] (1.0a5, 2022/01/09)
+::Really? Yes, really. Get the nightly [http://geyser.oni2.net/OniSplit/1.0a6_2022.01.22/ HERE] (1.0a6, 2022/01/22)
 :&nbsp;&nbsp;0. '''''Possible introduction of aliases''''' for the notoriously confusing '''-export''' and '''-import''' (easily mistaken for the '''-extract'''/'''-create''' functionality).
 ::Historical synonyms for '''-export''' and '''-import''' are "unpack" and "pack", but I am leaning towards new aliases, most probably '''-split''' and '''-link'''.<br/>(OniSplit itself may be rebranded as ''GameDataTool'', and a lightweight app (limited to the split/link functionality) may be dubbed ''(Oni)SpLink'', although this is likely a bad idea.)
@@ Line 14: / Line 14: @@
 #'''Characters/animations have been consolidated.''' Quaternion math is more accurate (preventing "upside-down" pelvis animation and other artifacts), as well as the "filtering" a.k.a. "smoothing" of rotation curves (Euler angles). The identification of animation curves in Collada input (when '''-create'''ing) is more robust. For long animations, warnings are now given for any data that is out of range for TRAM storage, most importantly when/if the rotation keys do not fit into 65535 bytes.
 #New options pertaining to dense rotation keyframes are available for TRAM operations:
-#*When '''-extract'''ing a TRAM to .xml/.dae, Oni's sparse rotation keys are now preserved by default (with Euler smoothing/filtering applied); re-keying can be forced through '''-rekey''', with the following flavors: '''-rekey:-1''' (or with any negative parameter) will produce "dense" Euler curves, with a key for every bone at every tick; '''-rekey:0''' (or simply '''-rekey''') will generate new curves with default/optimal trimming settings; a looser tolerance, resulting in sparser keyframes (and less accurate rotations) can be specified through '''-rekey:0.1''', '''-rekey:1''', etc.
+#*When '''-extract'''ing a TRAM to .xml/.dae, Oni's sparse rotation keys are now preserved by default (with Euler smoothing/filtering applied); dense Euler curves (with 60 keyframes per second) can be forced through '''-dense'''.
-#*For TRAMs '''-create'''d from .xml/.dae, the new default is again to preserve the keys from the .dae, without any additional interpolation or trimming; '''-rekey''' (or '''-rekey:0''') will generate new keys with default/optimal trimming settings; '''-rekey:-1''' (or with any negative parameter) will produce dense keys at every tick (not recommended); a custom tolerance can be specified through '''-rekey:0.1''', '''-rekey:1''', etc.
+#*For TRAMs that are '''-create'''d from .xml/.dae, the new default is also to preserve the rotation timeline, not filling in or trimming rotation keys for any bones. If the rotation data in the .dae is not directly compatible with Oni (e.g., keyframes occur between game ticks), then OniSplit will attempt to generate new keys with default/optimal trimming settings; the '''-rekey''' switch (or the equivalent '''-rekey:0''') have the same effect of default regeneration of rotation keys; dense keys (not recommended) can be produced with '''-rekey:-1''' or any negative parameter; a custom tolerance can be specified through '''-rekey:0.1''', '''-rekey:1''', etc.
+#A new '''-norle''' switch affects the conversion of Oni textures to TGA (in any context, such as ONCC or AKEV extraction, not just '''-extract:tga''' for a TXMP). The effect is that RLE encoding is not attempted, and the TGA files are typically larger.
+#A new '''-nocolor''' switch affects '''-extract:dae''' for AKEV. The effect is that vertex color information is omitted from the .dae scene (useful, e.g., if you work on lightmaps and don't need vertex colors at all).
 At the time of writing, the status of the above features is as follows:
-*items (1) through (10) are done and ready for testing as described;
+*items (1) through (13) are done and ready for testing as described;
-*item (11) is being re-done (replacing the '''-dense''' and '''-trim''' options from alpha 6 with '''-rekey''' logic)
+*item (0) is readily feasible, but not yet implemented (subject to debate?):
-*item (0) is redily feasible, but not yet implemented (subject to debate?):
 **the '''-link''' and '''-split''' aliases will likely be added (and their use instead of the ambiguous '''-import''' and '''-export''' will be encouraged);
 **the "rebranding" part (GameDataTool, SpLink, Navarre/Picasso, etc) will likely be dismissed as a not-so-good idea.