OniGalore

Talk:Mod Tool/OniTools addon: Difference between revisions

Page Discussion

Talk:Mod Tool/OniTools addon (view source)

Revision as of 16:36, 27 April 2016

92 bytes removed ,  27 April 2016
m
working on ghost quads management again, today: heights
mNo edit summary
m (working on ghost quads management again, today: heights)
Line 131: Line 131:


Download link should only provided if Oni retail installation is found on client machine.
Download link should only provided if Oni retail installation is found on client machine.
===Editing simultaneously multiple ghost quads heights===
Onisplit-generated ghost quads vertex ids can differ sometimes. So before changing multiple ghosts in height, their lowest and highest points must be identified.




Line 163: Line 166:


==More wild ideas==
==More wild ideas==
===Vertex shading on doors, consoles, etc.===
XML-based AKEV editing isn't possible. But now I know about binary file reading, so it should be possible to do binary file patching as well.
Neo said that adding vertex shading to re-imported OBJC meshes is something he isn't really keen on because the current level building is based on M3GM files which can't store vertex shading data.
Also he isn't convinced that OniSplit could easily associate these M3GMs with vertex shading saved in another file.
Still I'm not willing to give up on this. ^_^
Here's the plan:
# import a console into Mod Tool
# associate an ID (and everything else necessary to build the "BINACJBOconsole.xml" file later)
# apply vertex shading
# hit level export button to build the BINACJBOconsole and other xml and eventully all level files as onis
# now it would be time for the binary AKEV patching
## console id can be used to identify the polygons in AKEV's AGQG instance where the vertex shading is stored (<Colors>)
## now we have to hope that onisplit imported the mesh's polygons in the same order as Mod Tool read the polygons
## getting the vertex color from Mod Tool: there's already a code piece on MT's page ("[42] get vertex color")
I'm not fluent with binary stuff so I will dump some notes here:
'''Data table'''
[[Mod_Tool/Scripting#as_binary|Reading the AKEV's name table]] was more or less easy. This time we need to look up the data table.
Three things to take care about: '''reading hex numbers backwards''' (as usual in Oni), '''adding relative offsets''' to data table's offset (took a pretty while to find that one out*), '''subtracting 8 bytes''' for no other reason to get the correct offset.
: * Regarding binary information I found [[OBD:Instance_file_format|THAT]] page very useful.


What AKEV data do we need? The structure is fixed, so actually only the size or the item count is needed to pin down all colors.
: data table offset at 0x20
: AGQG offset (A) at 0x94
: AGQG size (B) at 0x9C
: AGQG items at 0x20 + A + 0x1C - 8
: AGQG start at 0x20 + A - 8
: AGQG end at 0x20 + A + B - 8
'''Color data in AGQG'''
The byte array is like this: BF BF BF FF (191 191 191 255 = grey).
The format is BGRA whereby I couldn't see Alpha to have an effect on the color strength. Maybe it will be different with a texture (not tested yet).
'''AGQG reader'''
https://dl.dropboxusercontent.com/u/139715/OniGalore/temp/AKEV_AGQG_reader.txt
output sample:
' INFO : 000280
' INFO : data table offset: 640
' INFO : 0004A8
' INFO : AGQG table offset: 1192
' INFO : 0001E0
' INFO : AGQG table size: 480
' INFO : ------------------------------
' INFO : AGQG_start: 1824
' INFO : ------------------------------
' INFO : AGQG array size: 8
' INFO : ----------
' INFO : element: 1
' INFO : 00000000
' INFO : 01000000
' INFO : 02000000
' INFO : 03000000
' INFO : 00000000
' INFO : 00000000
' INFO : 00000000
' INFO : 00000000
' INFO : BFBFBFFF (color: 191 191 191 255)
' INFO : BFBFBFFF (color: 191 191 191 255)
' INFO : BFBFBFFF (color: 191 191 191 255)
' INFO : BFBFBFFF (color: 191 191 191 255)
' INFO : 00000804
' INFO : FFFFFFFF (object id: -1)
' INFO : ----------
' INFO : ''[...]''
'''Complications'''
M3GM files use triangles while AGQG instances use quads (look, there are always 4 points each with its own 32-bit color slot).
That means Onisplit converts the M3GM triangles into quads on import.
So Mod Tool would need to exactly mimic OniSplit's way turning triangles into quads.
This information is based on following experience:
* Console0 triangles = 94
* After triangle-to-quad conversion.
: Console0: 47 quads = 38 (main) + 6 (collision box) + 1 + 1 + 1 (light tex quads)
* AGQG has 47 elements.
There are now 3 options:
* get Neo's OniSplit algorithm to quadrangulate the mesh in Mod Tool (complicated)
* <strike>read the AKEV xml file to get the mesh's vertices/quads (slow and uncool)</strike>
* <strike>extract the mesh as dae from AKEV and use that as vertex shading object (reference for M3GM) (faster but uncool because it still requires all consoles, doors, etc.)</strike>
AKEV data and extracted console mesh have different polygon IDs and point IDs. Identifying each point by position (taking tolerances into account) and then identifing the quads and triangles would take too long. So, it's still possible but at the moment it's a black hole consuming too much dev time... Darn.


===Animated reference===
===Animated reference===
Line 493: Line 389:
  ' INFO  : counted body parts: 19
  ' INFO  : counted body parts: 19
{{divhide|end}}
{{divhide|end}}
==Canceled==
===Reimporting and recovering of original vertex shading on doors, consoles, etc.===
:Q: Can we reimport and recover such data?
:A: XML-based AKEV editing isn't possible. But editing the binary file is possible.
::However, OniSplit cannot easily reapply original vertex shading since the used M3GMs have different vertex ids.
----
Old notes from realization attempt:
# import a console into Mod Tool
# associate an ID (and everything else necessary to build the "BINACJBOconsole.xml" file later)
# apply vertex shading
# hit level export button to build the BINACJBOconsole and other xml and eventully all level files as onis
# now it would be time for the binary AKEV patching
## console id can be used to identify the polygons in AKEV's AGQG instance where the vertex shading is stored (<Colors>)
## now we have to hope that onisplit imported the mesh's polygons in the same order as Mod Tool read the polygons
## getting the vertex color from Mod Tool: there's already a code piece on MT's page ("[42] get vertex color")
I'm not fluent with binary stuff so I will dump some notes here:
'''Data table'''
[[Mod_Tool/Scripting#as_binary|Reading the AKEV's name table]] was more or less easy. This time we need to look up the data table.
Three things to take care about: '''reading hex numbers backwards''' (as usual in Oni), '''adding relative offsets''' to data table's offset (took a pretty while to find that one out*), '''subtracting 8 bytes''' for no other reason to get the correct offset.
: * Regarding binary information I found [[OBD:Instance_file_format|THAT]] page very useful.
What AKEV data do we need? The structure is fixed, so actually only the size or the item count is needed to pin down all colors.
: data table offset at 0x20
: AGQG offset (A) at 0x94
: AGQG size (B) at 0x9C
: AGQG items at 0x20 + A + 0x1C - 8
: AGQG start at 0x20 + A - 8
: AGQG end at 0x20 + A + B - 8
'''Color data in AGQG'''
The byte array is like this: BF BF BF FF (191 191 191 255 = grey).
The format is BGRA whereby I couldn't see Alpha to have an effect on the color strength. Maybe it will be different with a texture (not tested yet).
'''AGQG reader'''
https://dl.dropboxusercontent.com/u/139715/OniGalore/temp/AKEV_AGQG_reader.txt
output sample:
' INFO : 000280
' INFO : data table offset: 640
' INFO : 0004A8
' INFO : AGQG table offset: 1192
' INFO : 0001E0
' INFO : AGQG table size: 480
' INFO : ------------------------------
' INFO : AGQG_start: 1824
' INFO : ------------------------------
' INFO : AGQG array size: 8
' INFO : ----------
' INFO : element: 1
' INFO : 00000000
' INFO : 01000000
' INFO : 02000000
' INFO : 03000000
' INFO : 00000000
' INFO : 00000000
' INFO : 00000000
' INFO : 00000000
' INFO : BFBFBFFF (color: 191 191 191 255)
' INFO : BFBFBFFF (color: 191 191 191 255)
' INFO : BFBFBFFF (color: 191 191 191 255)
' INFO : BFBFBFFF (color: 191 191 191 255)
' INFO : 00000804
' INFO : FFFFFFFF (object id: -1)
' INFO : ----------
' INFO : ''[...]''
'''Complications'''
M3GM files use triangles while AGQG instances use quads (look, there are always 4 points each with its own 32-bit color slot).
That means Onisplit converts the M3GM triangles into quads on import.
So Mod Tool would need to exactly mimic OniSplit's way turning triangles into quads.
This information is based on following experience:
* Console0 triangles = 94
* After triangle-to-quad conversion.
: Console0: 47 quads = 38 (main) + 6 (collision box) + 1 + 1 + 1 (light tex quads)
* AGQG has 47 elements.
Failed on:
* read the AKEV xml file to get the mesh's vertices/quads (slow and uncool)
* extract the mesh as dae from AKEV and use that as vertex shading object (reference for M3GM) (faster but uncool because it still requires all consoles, doors, etc.)
AKEV data and extracted console mesh have different polygon IDs and point IDs. Identifying each point by position (taking tolerances into account) and then identifing the quads and triangles would take too long. So, it's still possible but at the moment it's a black hole consuming too much dev time... Darn.
Paradox-01
8,018

edits

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