GR2 Editor/Viewer/Extractor/Importer

[BIGREG]

Hi all

Thank TDW for the new release ,I'll try that right now

[pedrobas]

Originally Posted by BIGREG

Hi all

Thank TDW for the new release ,I'll try that right now

Me too.

[Vanilla]

Ok. I got it now what is wrong with this turning-on-spot problem. It is the animation. Most of the animations are of, let's call it such, 'oriented' type. That is they are somehow flagged for the 'path-finder' that it should align them first with the world axii (or parent bone axii, that I don't know). That is before they start to play the path-finder first makes char turn to what it thinks is the correct orientation of the animation even if it is totaly wrong. This makes a char turn when it appears on this waypoint (came, teleported, or spawned onto it). Then the char plays the animation correctly in-line with its waypoint orientation (turning the waypioint bone does turn the animation on it), this change in orientation results in 'snap-into-animation-stance' glitch. When the animation finishes and next animation takes over the path-finder make our char turn again to align with the world axii if the animation finishes with the char facing somewhere else, this results in 'out-of-the-bed-jump-then-turn-away-then-turn-again-only-then-run' behaviour, same is true if you teleport him, teleport happens right at the end of the animation just before the path-finder do this 'alignment', this is why when a char just appears on a new waypoint path-finder takes this opportunity to 'catch-up' and aligns him on the new waypoint. This rules out teleporting as mean to circumvent it.
All seemed to be lost when three 'non-oriented' animations were discovered and those were: walk, run, crawl. This animations don't care how they are aligned since they are specificaly made to be rotateable mid-playing (making turns while walking). So if you insert an animation just after an oriented one then path-finder doesn't care to align the char anymore so you can then teleport the char without turns. While not helping now (you wouldn't want a char to do a few steps on his bed or better still in the mid-air before running), it gives us hopes for the future when TDW will empower us to change animations, so we will 'disorient' them. All praise all-mighty TDW!

There is as well the cross-compartment bow-wards teleport turning issue, but it seems to be solved, at least for now.

With it given I will now try to do some crew modding, we will have to live with some of this retarded turning for now.

[Vanilla]

Oh my! How stupid I was, there is these animation_info files. They define this 'orientation'! Jump out of the bed and no turning afterwards! Ain't it cool?! Problem solved!

[longam]

Oh baby, this game is going places now!

[Rongel]

Originally Posted by Vanilla

Oh my! How stupid I was, there is these animation_info files. They define this 'orientation'! Jump out of the bed and no turning afterwards! Ain't it cool?! Problem solved!

Just great! Keep up the good work. Really wonderful to read these breakthroughs!

[TheDarkWraith]

Originally Posted by Vanilla

Ok. I got it now what is wrong with this turning-on-spot problem. It is the animation. Most of the animations are of, let's call it such, 'oriented' type. That is they are somehow flagged for the 'path-finder' that it should align them first with the world axii (or parent bone axii, that I don't know). That is before they start to play the path-finder first makes char turn to what it thinks is the correct orientation of the animation even if it is totaly wrong. This makes a char turn when it appears on this waypoint (came, teleported, or spawned onto it). Then the char plays the animation correctly in-line with its waypoint orientation (turning the waypioint bone does turn the animation on it), this change in orientation results in 'snap-into-animation-stance' glitch. When the animation finishes and next animation takes over the path-finder make our char turn again to align with the world axii if the animation finishes with the char facing somewhere else, this results in 'out-of-the-bed-jump-then-turn-away-then-turn-again-only-then-run' behaviour, same is true if you teleport him, teleport happens right at the end of the animation just before the path-finder do this 'alignment', this is why when a char just appears on a new waypoint path-finder takes this opportunity to 'catch-up' and aligns him on the new waypoint. This rules out teleporting as mean to circumvent it.
All seemed to be lost when three 'non-oriented' animations were discovered and those were: walk, run, crawl. This animations don't care how they are aligned since they are specificaly made to be rotateable mid-playing (making turns while walking). So if you insert an animation just after an oriented one then path-finder doesn't care to align the char anymore so you can then teleport the char without turns. While not helping now (you wouldn't want a char to do a few steps on his bed or better still in the mid-air before running), it gives us hopes for the future when TDW will empower us to change animations, so we will 'disorient' them. All praise all-mighty TDW!

There is as well the cross-compartment bow-wards teleport turning issue, but it seems to be solved, at least for now.

With it given I will now try to do some crew modding, we will have to live with some of this retarded turning for now.

Originally Posted by Vanilla

Oh my! How stupid I was, there is these animation_info files. They define this 'orientation'! Jump out of the bed and no turning afterwards! Ain't it cool?! Problem solved!

Excellent I would work on mine but this GR2Editor/Viewer is top priority

Now let's see something tangible in the form of a mod...even if it's just a tester

[TheDarkWraith]

Reviewed the code today and fixed any upcoming pitfalls and shortcomings. There were a lot of things that needed to be fixed

Turned the app into a multi-threaded app. There's only one problem with multi-threaded apps - you can never be 100% sure they are fully bug free. It's nearly impossible to do. Everything should work. Report bugs as usual.

Worked on optimizing the exporter. Last night I exported Room_QR1's QR1_Objects (it has 15 subsets and the models are HUGE - large number of verticies in each subset) and it took well over 10 mins That was ridiculous. I optimized it as best as I could and here's the result:

[2680] Exporting of QR1_Objects started at 6:21:51 PM
[2680] Exporting of QR1_Objects finished at 6:27:07 PM
[2680] Exporting of QR1_Objects total time 00:05:15.6821504

Took 5 mins and 16 secs to export it without the AO That's more like it

Coding in the ability to select what the textures are exported as currently (image format). After that's complete I'll release the new test version.

Also adding the ability to import the AO

[THE_MASK]

I dont like to spam this thread but i think the mods for SH5 up till now are only the tip of the iceberg

[TheDarkWraith]

Originally Posted by sober

I dont like to spam this thread but i think the mods for SH5 up till now are only the tip of the iceberg

We will see Once I give the ability to alter geometry and add/remove geometry then the flood gates will really open

I'm not one for using tools to do the work that I can hex edit but this GR2 file warrants a tool. It's WAY too complex to try and hex edit. Too many things to change and keep track of (pointer wise). Plus you make one little mistake in those changes and it's game over. So I have to live with the fact that I must use this tool I'm developing to make/edit GR2 files

[TheDarkWraith]

Now when you check import AO from the import screen you are able to import the AO data (of all the AO data read in the only thing the app uses if the texture coordinate data - this data gets set as texture coordinate 2 data in the mesh)

You can now select the file type to save the textures as when exporting:



Just a few little things to tidy up and then I'll release a new test version

[pedrobas]

Sorry for asking, but what is AO?

[TheDarkWraith]

Originally Posted by pedrobas

Sorry for asking, but what is AO?

It's the ambient occlusion. Here's the best way to see what it is:
- fire up the app
- load up Room_QR1
- position camera like I have in screenshot above
- click on the rendering tab
- unselect diffuse
- you are now looking at the AO map
- select diffuse
- unselect Self-Illumination
- you are now looking at the diffuse map (aka SH3 mode)
- now you see why the AO is so important

[pedrobas]

Originally Posted by TheDarkWraith

It's the ambient occlusion. Here's the best way to see what it is:
- fire up the app
- load up Room_QR1
- position camera like I have in screenshot above
- click on the rendering tab
- unselect diffuse
- you are now looking at the AO map
- select diffuse
- unselect Self-Illumination
- you are now looking at the diffuse map (aka SH3 mode)
- now you see why the AO is so important

Thank you very much

[Ekmek]

Originally Posted by TheDarkWraith

test version 1.1.70.0 available here: http://www.mediafire.com/?a41hb428jd4267h

Fixed all problems and errors so far except for BIGREG's 3DS Max one on import.

All objects now correctly translate and rotate based on their axis
The XYZ in the bottom right corner now means what axis of freedom/rotation is enabled
Spawned worker threads for the importer and exporter so main thread is not locked up
Exporter and importer now tell you what they're doing so you have some idea what's going on
While importing/exporting the main thread is 'alive' thus you can move camera around view the loaded objects. All other functions are disabled while importing/exporting
Picking problems solved
Fixed logic errors in the cursors and the displaying of axis of freedom/rotation
Under the misc tab you have the ability to show/hide the world and camera axis panels. You also have the ability to show/hide the lock diamond
Fixed bug of where you could possibly rotate/scale/translate an object if it's Flags were 0
Fixed bug of where you could edit position/rotation/scale data for an object even if the Flags didn't allow it

Hopefully I covered everything you all have posted so far except for BIGREG's import problem with 3DS Max file. If I left something out let me know

Next version I'll spawn worker threads when loading the file so that it will load even faster (I can spawn worker threads for each PrimaryVertexData and Mesh so that all these can be loaded in parallel)

Also looking into why the exportation of some meshes (Room_QR1's Objects_01) takes so long. Will try to optimize it.

As you know or don't know the app is currently using my first importer I wrote. I'm going to revise that importer so that it will read in AO items also (since we have the ability to export AO items we need to be able to import them also)

Working on revising the second importer I wrote. The second importer will allow you to change the geometry of the object. You will no longer be locked into the mesh's number of verticies you exported from. You'll be able to replace the object with an entirely new object. The main things I have to do to it is make it compatible with my linked list code and tell it how to interface with Sentinel.

Waypoints: thinking out loud here: app gives you the ability to load a waypoint_edges_x file so that you can visually see the waypoint interconnects. Maybe even let you define the interconnects and have the app write/update the waypoint_edges_x file...

Keep the bug reports coming. Ideas always welcome also

you are a machine! any chance you looked at blender scripts yet? or my gr2s? probably not but just wondering.