GR2 Editor/Viewer/Extractor/Importer

[TheDarkWraith]

just got a good render of the Augustus.GR2 file. All my changes worked :D Can't post any pictures because subsim says I've exceeded my total album limit :06: We have an album limit? :huh:

[gap]

just got a good render of the Augustus.GR2 file.

Cool :up:


All my changes worked :D Can't post any pictures because subsim says I've exceeded my total album limit :06: We have an album limit? :huh:

Try using imageshack or photobucket ;)

[gap]

When I try editing any of the GR2's contained in the Objects/Guns folder, this is what happens when I select (left click) a checked bone, or viceversa, when I check a selected bone:

http://imageshack.us/scaled/thumb/442/unmanagedexception.jpg (http://img442.imageshack.us/img442/434/unmanagedexception.jpg)

What's that diamond rendered around the bone?

The Windows error message says, more or less:

Unmanaged exception in a component of the application, bla bla.
Object reference not set to an instance of an object

Details:


************** Testo dell'eccezione **************
System.NullReferenceException: Riferimento a un oggetto non impostato su un'istanza di oggetto.
in TheDarkWraith.SilentHunter5.GR2EditorViewer.GetSel ectedItemCanScaleRotateTranslate(Boolean& canscale, Boolean& canrotate, Boolean& cantranslate)
in TheDarkWraith.SilentHunter5.GR2EditorViewer.SetCam eraLocked(Boolean cameravalue, Boolean xaxisvalue, Boolean yaxisvalue, Boolean zaxisvalue)
in TheDarkWraith.SilentHunter5.GR2EditorViewer.SetSel ectedItem(enumSelectedItem si, Object& item)
in TheDarkWraith.SilentHunter5.GR2EditorViewer.tvBone s_AfterCheck(Object sender, TreeViewEventArgs e)
in System.Windows.Forms.TreeView.OnAfterCheck(TreeVie wEventArgs e)
in System.Windows.Forms.TreeView.WndProc(Message& m)
in System.Windows.Forms.Control.ControlNativeWindow.O nMessage(Message& m)
in System.Windows.Forms.Control.ControlNativeWindow.W ndProc(Message& m)
in System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Assembly caricati **************
mscorlib
Versione assembly: 2.0.0.0
Versione Win32: 2.0.50727.5466 (Win7SP1GDR.050727-5400)
Base di codice: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
GR2EditorViewer
Versione assembly: 1.1.285.1
Versione Win32: 1.1.285.1
Base di codice: file:///C:/Ubisoft/Silent%20Hunter%205/TDW_GR2EditorViewer_v_1_1_285_1/GR2EditorViewer.exe
----------------------------------------
System.Windows.Forms
Versione assembly: 2.0.0.0
Versione Win32: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
Base di codice: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Versione assembly: 2.0.0.0
Versione Win32: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
Base di codice: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Versione assembly: 2.0.0.0
Versione Win32: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
Base di codice: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
Microsoft.DirectX.Direct3D
Versione assembly: 1.0.2902.0
Versione Win32: 9.05.132.0000
Base di codice: file:///C:/Windows/assembly/GAC/Microsoft.DirectX.Direct3D/1.0.2902.0__31bf3856ad364e35/Microsoft.DirectX.Direct3D.dll
----------------------------------------
Microsoft.DirectX
Versione assembly: 1.0.2902.0
Versione Win32: 5.04.00.2904
Base di codice: file:///C:/Windows/assembly/GAC/Microsoft.DirectX/1.0.2902.0__31bf3856ad364e35/Microsoft.DirectX.dll
----------------------------------------
Microsoft.DirectX.DirectInput
Versione assembly: 1.0.2902.0
Versione Win32: 5.04.00.2904
Base di codice: file:///C:/Windows/assembly/GAC/Microsoft.DirectX.DirectInput/1.0.2902.0__31bf3856ad364e35/Microsoft.DirectX.DirectInput.dll
----------------------------------------
Microsoft.VisualC
Versione assembly: 8.0.0.0
Versione Win32: 8.00.50727.4927
Base di codice: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualC/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualC.dll
----------------------------------------
System.Xml
Versione assembly: 2.0.0.0
Versione Win32: 2.0.50727.5420 (Win7SP1.050727-5400)
Base di codice: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
mscorlib.resources
Versione assembly: 2.0.0.0
Versione Win32: 2.0.50727.5466 (Win7SP1GDR.050727-5400)
Base di codice: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
System.Core
Versione assembly: 3.5.0.0
Versione Win32: 3.5.30729.5420 built by: Win7SP1
Base di codice: file:///C:/Windows/assembly/GAC_MSIL/System.Core/3.5.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Configuration
Versione assembly: 2.0.0.0
Versione Win32: 2.0.50727.5420 (Win7SP1.050727-5400)
Base di codice: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
Microsoft.DirectX.Direct3DX
Versione assembly: 1.0.2902.0
Versione Win32: 5.04.00.3900
Base di codice: file:///C:/Windows/assembly/GAC/Microsoft.DirectX.Direct3DX/1.0.2902.0__31bf3856ad364e35/Microsoft.DirectX.Direct3DX.dll
----------------------------------------
System.Windows.Forms.resources
Versione assembly: 2.0.0.0
Versione Win32: 2.0.50727.5420 (Win7SP1.050727-5400)
Base di codice: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_it_b77a5c561934e089/System.Windows.Forms.resources.dll
----------------------------------------


Note that I can resume working on the file without apparent problem. Right clicking on bones and editing their properties works flawlessy, but when I close the bone editing window, the same error message pops up again.

Also note that the Update button it still not working as supposed (always greyed out, even after a bone change). I am nonetheless allowed to Store the changes without Updating them. When I want to save the changes on file, I am warned that there are changes not Updated and not Stored, but I can just ignore this message, since if I confirm that I want to continue with the save all the same, the next time I open the file my changes are there :hmm2:

[Ekmek]

just got a good render of the Augustus.GR2 file. All my changes worked :D Can't post any pictures because subsim says I've exceeded my total album limit :06: We have an album limit? :huh:


PURE GENIUS! and you did it so fast. :rock:

I look forward to the next build of the app!

[TheDarkWraith]

PURE GENIUS! and you did it so fast. :rock:

I look forward to the next build of the app!

Here it is rendered:
http://www.mediafire.com/view/?rkffp7pip6e2ktv

There are a TON of bones defined in this GR2 file (> 1000). I would've rendered the bones also but because there are so many that's all you would basically see.

There are no textures because this GR2 file doesn't define any textures. It has materials but the maps of most of the materials aren't defined in the materials :dead: Furthermore, some of the maps have texture pointers but there are no textures defined in the GR2 file. Totally breaks all the rules I've figured out so far :nope: I have to figure out a way to overcome this :-?

I still have lots of work to do on next version :dead:

[Sartoris]

Just dropping by to express my joy at seeing TDW back at work! :woot::rock:

[GT182]

Just dropping by to express my joy at seeing TDW back at work! :woot::rock:

He's always "at work".... just not always here at work. ;) LOL

[TheDarkWraith]

This looks like someone I know from Civ5...someone who causes me much grief at times:
http://www.mediafire.com/view/?73z9zfnbxln1lx7

Yep, got the textures loaded. They (whoever made this GR2 file) tried to hide materials and textures in it. I had Sentinel give me a report of the chains in section 0 and it reported back many broken chains. When I looked over the output from it I noticed that most of these holes (broken chains) were sizes of Textures and Materials in a GR2 file. I made a couple changes to the app to make it look for hidden materials and textures and sure enough it found them :D

There are still some broken chains I'm investigating. Broken chains are bad because that means I didn't read something from the file. If I didn't read it that means I can't use it and I sure can't write it :cool:

[Ekmek]

I think I have something that may help. Give me a few minutes.

[Ekmek]

Since you are probably getting tired of Augustus, I think Otto Bismarck may help. THat Augustus file may be from an old granny build and have errors. Its not the current game file because you can't open those with grannyviewer so I found that file that can open with granny viewer. But Augustus may have errors that are giving you a headache.


I poked around some more and I found Otto Bismarck that appears to work better. Attached is the current game file which is compressed and you can't open in granny viewer. This one the game uses - German_Bismarck.gr2. I put it there if you are curious but its not necessary to crack.

It appears that there is another uncompressed (or a more public compression?) gr2 format that can be viewed in game AND in granny viewer. It is also in the zip and its named German_Bismarck_OLD.gr2. This version should be better than the Augustus one.

This one may have rigging issues to animation (in game the animations look weird) but it shows in game and may unlock the other problems you are having. I included texture files and animations (one animation is probably the current compressed type and the other with the OLD suffix probably isn't). I hope this helps!

Thanks for all the work!

http://www.mediafire.com/?2rih2onrw884xxe

[TheDarkWraith]

The Augustus.GR2 file was a great file to decompress and test the app with. It exposed many items that needed fixing/second look and it exposed many problems I didn't know existed in the app :-? Now that I have everything fixed and updated I read in the file and saved the image I read from the file to a new file (to ensure I read everything correctly). Then I had Sentinel give me a report of any broken chains and none were reported. Then I closed the file in the app. I did a compare of the original file to the new file and they were nearly identical (some very slight rounding errors for some of the float values). Granny Viewer was able to open the new GR2 file without problem and the app was able to read the new file without problems also. This means that what I read in from the original file was saved in entirety to the new file :rock:

In keeping with the GR2 tradition that the file hates to duplicate items this is what was really causing the app problems (duplicate pointers and duplicate extendeddata). I figured out how to overcome this and everything is fine until I add new data to the file. Then these duplicate pointers get all screwed up. I know why it's happening (my pointer update code is the problem) and now just have to fix this. It's not as easy as it sounds and will take some time to think over the best way to overcome this small problem :cool:

[gap]

The Augustus.GR2 file was a great file to decompress and test the app with. It exposed many items that needed fixing/second look and it exposed many problems I didn't know existed in the app :-? ...

does it all imply that GR2 files edited with previous versions of your editor are somehow broken or corrupted? :hmm2:

[Targor Avelany]

interesting...
It's awesome to hear that GR2EditorViewer is progressing so much! :rock:
Nice job, TDW!

On the gap's post: yeah, it is possible that a lot of them will have to be re-done. I also wonder if the above is the cause for my texture problems.

[Ekmek]

The Augustus.GR2 file was a great file to decompress and test the app with. It exposed many items that needed fixing/second look and it exposed many problems I didn't know existed in the app :-? Now that I have everything fixed and updated I read in the file and saved the image I read from the file to a new file (to ensure I read everything correctly). Then I had Sentinel give me a report of any broken chains and none were reported. Then I closed the file in the app. I did a compare of the original file to the new file and they were nearly identical (some very slight rounding errors for some of the float values). Granny Viewer was able to open the new GR2 file without problem and the app was able to read the new file without problems also. This means that what I read in from the original file was saved in entirety to the new file :rock:

In keeping with the GR2 tradition that the file hates to duplicate items this is what was really causing the app problems (duplicate pointers and duplicate extendeddata). I figured out how to overcome this and everything is fine until I add new data to the file. Then these duplicate pointers get all screwed up. I know why it's happening (my pointer update code is the problem) and now just have to fix this. It's not as easy as it sounds and will take some time to think over the best way to overcome this small problem :cool:


Great to hear. I guess the Otto Bismarck GR2 is no different than Augustus?

[TheDarkWraith]

does it all imply that GR2 files edited with previous versions of your editor are somehow broken or corrupted? :hmm2:

Depends. If there was any extendeddata that had a granny_struct_pointer that had a null value then yes. There is an easy way to tell if your file is broken and/or corrupted. Load the file in question with the app. After it's loaded and displayed press F1 to bring up the Sentinel window. Type:

getchainforsection 0 true

Scroll to the very top of the report. If it reports that it found broken chains then your file is broken and/or corrupt :-?

Here is an example using the Augustus.GR2 file:

Augustus_Sentinel>
Augustus_Sentinel>getchainforsection 0 true
Linked list for section 0 (arttoolinfo)
this section's chain is complete

This example shows no broken chains

interesting...
It's awesome to hear that GR2EditorViewer is progressing so much! :rock:
Nice job, TDW!

On the gap's post: yeah, it is possible that a lot of them will have to be re-done. I also wonder if the above is the cause for my texture problems.

It's quite possible that your texture problems can be caused by a broken and/or corrupted GR2 file. Follow the procedure above to see if you have any broken chains.

Great to hear. I guess the Otto Bismarck GR2 is no different than Augustus?

Haven't loaded it yet.


Now the good news: Found where the pointers were getting corrupted when any data was written to the Augustus.GR2 file (my error). Due to the duplicate pointers and/or extendeddata that the Augustus.GR2 file contained I was using an incorrect offset for the exporterinfo extendeddata (when I create these new entries in the GR2 file). Changed it to use the correct offset and everything is perfect :rock: The exporterinfo extendeddata was written to the file, file was saved to disk, Granny Viewer was able to open the new file with no problems and so was the app :D

I've included a little more error checking in this version so load/save times may increase a little. One major error checking during a save is the app will check for any broken chains and if any are found will inform you before saving the file to disk.

Have to do some more testing with this current version to ensure I didn't break anything major. There might be some bugs in this next version I release since I did a major overhaul to it from the bugs/errors found when trying to load the Augustus.GR2 file

:|\\

[TheDarkWraith]

Forgot to mention that in order to decompress compressed GR2 files you will need Granny Viewer v2.8.33.0 installed on your computer (as that's the version I RE'd to find where to install my hooks at). The app will spawn the Granny Viewer when it needs to decompress a GR2 file. You will need to select the same file in Granny Viewer so that it loads it and decompresses it (and while decompressing it will spit out the decompressed sections a la my injected code into it :D). My app then takes these decompressed sections and builds a new GR2 file out of them

:|\\

[Targor Avelany]

It's quite possible that your texture problems can be caused by a broken and/or corrupted GR2 file. Follow the procedure above to see if you have any broken chains.

it is actually slightly more interesting...

http://img824.imageshack.us/img824/8085/sentinellifeboat.jpg

[TheDarkWraith]

That is another way of checking for any broken chains. Your output is fine as section 0 reported no broken chains :salute:. I have all the other sections disabled from reporting currently in the release versions you all are using :cool:

[Targor Avelany]

That is another way of checking for any broken chains. Your output is fine as section 0 reported no broken chains :salute:. I have all the other sections disabled from reporting currently in the release versions you all are using :cool:

ah, that will explain it, then. hehehe.

Still, makes you wonder wth with the textures then. :-? :/\\!!

[TheDarkWraith]

Still, makes you wonder wth with the textures then. :-? :/\\!!

After this next version is completed I'll look into the reported Texture issues. The more data everyone can give me about whatever problems they are having with this the better. I need files, write ups of the problem, what you did to make the problem appear, etc. so that I can try and duplicate it and single step it in Visual Studio's debugger to try and figure out why :yep:

[Targor Avelany]

After this next version is completed I'll look into the reported Texture issues. The more data everyone can give me about whatever problems they are having with this the better. I need files, write ups of the problem, what you did to make the problem appear, etc. so that I can try and duplicate it and single step it in Visual Studio's debugger to try and figure out why :yep:
That - will not be a problem :-)
I'll run through various options over this weekend and will write up all the details step by step.

[gap]

On the gap's post: yeah, it is possible that a lot of them will have to be re-done. I also wonder if the above is the cause for my texture problems.

Depends. If there was any extendeddata that had a granny_struct_pointer that had a null value then yes. There is an easy way to tell if your file is broken and/or corrupted. Load the file in question with the app. After it's loaded and displayed press F1 to bring up the Sentinel window...

Thanks to both of you for the explainations :salute:

After this next version is completed I'll look into the reported Texture issues. The more data everyone can give me about whatever problems they are having with this the better. I need files, write ups of the problem, what you did to make the problem appear, etc. so that I can try and duplicate it and single step it in Visual Studio's debugger to try and figure out why :yep:

Probably unrelated, but have you seen my report in post #1753 (http://www.subsim.com/radioroom/showpost.php?p=2004003&postcount=1753)?

[TheDarkWraith]

Fixed more problems found in previous versions.

Wanted to record information about the decompression in the GR2 file and found the perfect place to put it: Under the ExtendedData of the main menu :D Since I've never seen this populated in any GR2 file I've opened I decided to put it to good use (and even if the app finds it populated it will just add more entries to it)

http://www.mediafire.com/view/?e3t1cqbh533m25g

Once you click the ExtendedData (and if the file is decompressed) you'll see:

http://www.mediafire.com/view/?0rk1wjlr7fl9ha8

Clicking the Decompression link will show you the decompression information:

http://www.mediafire.com/view/?81qbckwicqc08sa

I'm finally coding in my Author Info idea. This will let the author of the file record information about it in the GR2 file. This will be added to the main menu's ExtendedData also but the link will say 'Author Info'. In this section I plan on letting the author add name, contact info, notes, description, whether the file is viewable by the app, whether the file is editable by the app, whether the file is viewable by the Granny Viewer or not. Since my application is the only one that can currently edit and view GR2 files outside of Rad Games Tools apps this will give the author the options of how tight they want their work protected. If the author chooses to not let the file be editable by the GR2 Editor/Viewer then they will need to supply a password to protect it. The app will check to see if the file is marked as editable or not and if it's not the end user will only be able to view the file with this app (if the author chooses to let them view it). Viewing the file is just as it means - you can only view it (you cannot extract, change, edit, zip, nada, nothing). If the author chooses to not let you view the file then the app will enforce this and not let you load the file in question (unless you supply the correct password).

I plan on letting the author specify two passwords: one for viewing and one for editing. This way the author can give the viewing password to others so they can view their work but not make any changes to it.

:|\\

[reignofdeath]

Fixed more problems found in previous versions.

Wanted to record information about the decompression in the GR2 file and found the perfect place to put it: Under the ExtendedData of the main menu :D Since I've never seen this populated in any GR2 file I've opened I decided to put it to good use (and even if the app finds it populated it will just add more entries to it)

http://www.mediafire.com/view/?e3t1cqbh533m25g

Once you click the ExtendedData (and if the file is decompressed) you'll see:

http://www.mediafire.com/view/?0rk1wjlr7fl9ha8

Clicking the Decompression link will show you the decompression information:

http://www.mediafire.com/view/?81qbckwicqc08sa

I'm finally coding in my Author Info idea. This will let the author of the file record information about it in the GR2 file. This will be added to the main menu's ExtendedData also but the link will say 'Author Info'. In this section I plan on letting the author add name, contact info, notes, description, whether the file is viewable by the app, whether the file is editable by the app, whether the file is viewable by the Granny Viewer or not. Since my application is the only one that can currently edit and view GR2 files outside of Rad Games Tools apps this will give the author the options of how tight they want their work protected. If the author chooses to not let the file be editable by the GR2 Editor/Viewer then they will need to supply a password to protect it. The app will check to see if the file is marked as editable or not and if it's not the end user will only be able to view the file with this app (if the author chooses to let them view it). Viewing the file is just as it means - you can only view it (you cannot extract, change, edit, zip, nada, nothing). If the author chooses to not let you view the file then the app will enforce this and not let you load the file in question (unless you supply the correct password).

I plan on letting the author specify two passwords: one for viewing and one for editing. This way the author can give the viewing password to others so they can view their work but not make any changes to it.

:|\\

Holy clown face batman!! When did you get back TDW!?!?:arrgh!:

[Targor Avelany]

Nice!!! :rock:

[TheDarkWraith]

when the app spawns the Granny Viewer it will change the title of the Granny Viewer app to reflect it's current purpose. It will also have the Granny Viewer app spawn a MessageBox stating what to do:

http://www.mediafire.com/view/?1zeboyjlz76ptbb

:|\\

EDIT:

I'm more than likely going to change this. Since I know where in the app it goes to read the string of the filepath you selected I will write the necessary string value to that memory address and just bypass the openfiledailog box. That way you just have to press Load file... and sit back and watch the show...

[Ekmek]

great work!

[Ekmek]

when the app spawns the Granny Viewer it will change the title of the Granny Viewer app to reflect it's current purpose. It will also have the Granny Viewer app spawn a MessageBox stating what to do:

http://www.mediafire.com/view/?1zeboyjlz76ptbb

:|\\

EDIT:

I'm more than likely going to change this. Since I know where in the app it goes to read the string of the filepath you selected I will write the necessary string value to that memory address and just bypass the openfiledailog box. That way you just have to press Load file... and sit back and watch the show...


So the granny viewer will be the "muscle" for loading gr2s now? Basically anything you can open in granny viewer can be modified?

I ask because I found an issue with my custom gr2s were the civ5 ones have something called "submaps" in their materials but i cant duplicate them. I think this is what you mean by embedding the textures.

[flighttools]

The granny viewer can take a command line argument of the file to load. Have you tried that instead of playing with memory addresses?

[TheDarkWraith]

So the granny viewer will be the "muscle" for loading gr2s now? Basically anything you can open in granny viewer can be modified?

I ask because I found an issue with my custom gr2s were the civ5 ones have something called "submaps" in their materials but i cant duplicate them. I think this is what you mean by embedding the textures.

The Granny Viewer is only spawned and used when the app needs to decompress the GR2 file the user asked it to load. The app still does all the heaving lifting of reading/parsing/creating the GR2 file.

I have changed how the Granny Viewer works now also. Now a dialog box will show saying you only have to click load file... to begin. The granny viewer app will close itself down automatically when it has finished decompressing the GR2 file. Why do you have to press Load file... at all? To avoid legal issues/problems. I could easily cut the code out of Granny Viewer that does the decompressing and put it into a DLL or even the app but doing so could/would raise legal problems. By using the Granny Viewer app and only modifying process memory (and not the exe itself) I avoid all legal problems. By having to click Load file... you are still using the app as it was intended (only slightly modified for what I want it to do).

Your Granny Viewer app on your computer will remain unharmed. All the changes I do to the Granny Viewer are done in process memory after the winloader has placed it in your computer's memory (basically after windows has finished creating the process and is 'running' the app). This means all changes to the Granny Viewer app are lost when it closes itself. And before anyone asks, no you can't stop the Granny Viewer from closing itself down. The code I inject/change forces it to terminate after it decompresses all the needed sections.

These submaps you are referring to are the hidden textures and materials in the GR2 file. The app will expose them so you can edit/view them (though they will remain hidden when the app writes the file - this means not viewable in Granny Viewer) :up: I might code something in in later versions to make these invisible textures and materials visible. It's just a simple matter of adding a pointer for each invisible one to expose it.

The granny viewer can take a command line argument of the file to load. Have you tried that instead of playing with memory addresses?

Yes I know it will take command line arguments. When I was REing the Granny Viewer app one of the first things it does is read the command line arguments.

I had to write the path to the Granny Viewer memory because I didn't want the user to be able to pick the wrong file. Now when you click load file... the granny viewer automatically starts loading the file I wrote into it's memory. Thus no user error can occur :D

You have to think about how the end-user can screw up and code for it (or try to at least) :up:

Version 1.1.314.1 is complete and is undergoing final testing. The author info idea will not be in this version. This version will be able to decompress compressed GR2 files and it contains some bug fixes for the bugs I was able to find. Expect to see a release date of tomorrow (Saturday) for it if all goes well :salute:

I was able to load the Otto_Bismark_OLD.GR2 file also. The Decompressor is working perfectly so far :D

The app's name has changed to GR2 Editor/Viewer as it is no longer confined to just SH5 GR2 files.

The app is unable to decompress a GR2 file that is compressed AND has pointers before data. The reason being is I haven't been able to test it with a GR2 file like this. I need a GR2 file like this so I can verify the decompressor works as it should with this special type of GR2 file. If you find one (the app will tell you if you try to decompress one) please send it to me.

In the next version I hope to have some code/window in place so that you can specify to the app which mapusage is for diffuse, bump, ambient-occlusion, etc. Currently I have them hard coded to SH5 values.

Your anti-virus software may complain about the app now. Reason being is the code I have for modifying process memory. I use this same code to change/extract data/code from apps loaded on other's computers. It's very good at what it does! The best part is the app it's changing/reading/modifying has no idea that anything ever happened to it :D

:|\\

[TheDarkWraith]

Might be a slight delay in releasing new version. Followed up on a note I made to myself about some data that I found that I didn't really know it's purpose. I found this data in the Augustus.GR2 file and also in the Undine.GR2 file. After playing with a bunch of numbers trying to get something to work out I finally figured out that this data is a special type of datatype definition. It's exact purpose is still unclear but they are definitely a type of datatype definition. What does this mean? This means that I haven't been updating them :dead: This really isn't a problem unless a section in your GR2 file has this (referring to unknown_count):

[8528] Reading section 1 (vertex_data) data starting at 0x94
[8528] Compression Type=0x0 0x94 always 0x0
[8528] Section file offset=0x4D534 0x98 where this section starts in the file
[8528] Compressed size=60992 0x9C compressed size and uncompressed sizes should equal for SH5 GR2s
[8528] Uncompressed size=60992 0xA0 compressed size and uncompressed sizes should equal for SH5 GR2s
[8528] Alignment=0x4 0xA4 what the alignment boundary is in the file
[8528] Start of data offset=0x780 (0x4DCB4) 0xA8 start of data
[8528] Start of data offset2=0x780 (0x4DCB4) 0xAC start of data
[8528] Pointers file offset=0x1189AC 0xB0 where the pointers for this section are located
[8528] Number of pointers=0 (0x0) 0xB4
[8528] End of pointers file offset=0x11C648 0xB8 where the pointers for the file end
[8528] Unknown_Count=0x1 0xBC
[8528] Current position in file is 0xC0

unknown_count used to be an unknown to me but I finally figured out that it is the number of these special datatype definitions in the file. If you total all these unknown_counts for all the sections and multiply by the size of this data structure it works out to be what it should be :woot: I've figured out the data structure for the most part, only 0x4 bytes of it I'm still scratching my head over. There are two 0x4 byte parts of this data structure that I have to update when Sentinel makes any changes to the file. I'll have to add code to my pointer updater code to handle these special data structures.

Now the purpose of these special datatype definitions is still unclear to me. I've found where they show in the Granny Viewer but it still doesn't make any sense to me yet :hmmm:

[TheDarkWraith]

Figured these special datatype definitions out :D They are describing vertex data, specifically vertex data that has mixed values (Real32 and UInt8 mixed together for instance). All the vertex data that had the same values (Real32 for instance) didn't 'trigger' any of these special datatype definitions. These also play a part in the section's data offset. Wow. More error checking and code needed in my app now :shifty: These things are very important and I've been ignoring them :o

[Ekmek]

Thats great. I cant wait to test this out!:yeah:

[gap]

Looking forward to your next update TDW :up:

When you get time, can you please have a look at this post? :D

http://www.subsim.com/radioroom/showpost.php?p=2010717&postcount=106

[TheDarkWraith]

Looking forward to your next update TDW :up:

When you get time, can you please have a look at this post? :D

http://www.subsim.com/radioroom/showpost.php?p=2010717&postcount=106

Uncheck (or check) use local settings in the options (Edit-->Options). If that doesn't work post a link to the files here so I can see what's going on in Visual Studio's debugger.


These new special datatype definitions finally unlocked what sections 3 and sections 4 are in the GR2 file: deformable vertex data and deformable indices respectively. That means sections 1 and 2 are rigid vertex data and rigid vertices respectively :D Another piece to the puzzle added........but the mystery deepens :shifty: Adding all the new error checking code in for these special datatype definitions revealed that all the vertex data I'm currently reading from Augustus.GR2 is deformable. I'm reading no rigid data :-? This is not the apps fault, it's because this data is being hidden in the GR2 file. Now just have to figure out how to find it...

[gap]

After unchecking 'Use local regional settings' something changed. Now when trying a strict vertex data import I get this error message: :hmm2:

http://img822.imageshack.us/img822/3577/dialogu.jpg

I want to try importing a GR2 Editor-generated obj file tweaked with Wings 3D vertex coordinates. I will report back in a few minutes...

[TheDarkWraith]

After unchecking 'Use local regional settings' something changed. Now when trying a strict vertex data import I get this error message: :hmm2:

Please post a link to the file that gave this error (include all the other files also so I can try and import it while watching in Visual Studio's debugger).

[gap]

Please post a link to the file that gave this error (include all the other files also so I can try and import it while watching in Visual Studio's debugger).

at last the "hybrid" file worked :up: :woot:

seems that your tool can't recognize some Wing 3D's setting. Give me time to pack the files :up:

[TheDarkWraith]

at last the "hybrid" file worked :up: :woot:

seems that your tool can't recognize some Wing 3D's setting. Give me time to pack the files :up:

Please include a write-up that details the steps you took to get the error. I need to try and simulate what you did to recreate the error to understand why it's happening.

[TheDarkWraith]

No hidden rigid vertex data in Augustus.GR2...I asked for information on wrong section and the app readily applied with nothing found :dead: Problem fixed in the app and more testing/coding continues...

[gap]

Please include a write-up that details the steps you took to get the error. I need to try and simulate what you did to recreate the error to understand why it's happening.

Here are the files:

http://www.mediafire.com/?3ck9oot5ivgox01

I followed the steps described in this (http://www.subsim.com/radioroom/showpost.php?p=2010717&postcount=106) post. Always tried strict imports. Exporting/Importing vertex data alone.

The only difference is that now I unchecked the 'use regional settings' option. :yep:

[TheDarkWraith]

Here are the files:

http://www.mediafire.com/?3ck9oot5ivgox01

I followed the steps described in this (http://www.subsim.com/radioroom/showpost.php?p=2010717&postcount=106) post. Always tried strict imports. Exporting/Importing vertex data alone.

The only difference is that now I unchecked the 'use regional settings' option. :yep:

I just posted the thread where you described the problem. I see the problem in the app now :up: The problem is in the strict import (and more than likely in the loose importer also). The problem is in the face definitions. I check for normals, texture coordinates, and vertices. If all 3 are found then the number of parameters for the face definitions is 3. If one or more isn't found then the number of parameters for the face definition reflects this. What I had coded was if the number of parameters != number of parameters in face definition then throw error. I'm making the necessary changes so that the app is checking for the possibility of nothing in a face definition parameter (1//2).

[gap]

I just posted the thread where you described the problem. I see the problem in the app now :up: The problem is in the strict import (and more than likely in the loose importer also). The problem is in the face definitions. I check for normals, texture coordinates, and vertices. If all 3 are found then the number of parameters for the face definitions is 3. If one or more isn't found then the number of parameters for the face definition reflects this. What I had coded was if the number of parameters != number of parameters in face definition then throw error. I'm making the necessary changes so that the app is checking for the possibility of nothing in a face definition parameter (1//2).

I see. :up:

While we are waiting for the next update, can I obviate the problem by pasting the face definitions of the GR2 Editor-exported obj file into the Vings3D export? Should I expect any side effect? :hmm2:

[TheDarkWraith]

I see. :up:

While we are waiting for the next update, can I obviate the problem by pasting the face definitions of the GR2 Editor-exported obj file into the Vings3D export? Should I expect any side effect? :hmm2:

Not a good idea. I've seen Wings3D move vertices around.

I have fixed the bug you reported (it was in the strict and loose importers) and was able to successfully import your Wings3D file. I hope you looked at the results of that Wings3D file in the app. It actually made the tree LARGER.

I'll release a new version here very shortly with this problem fixed. This new version will have the decompression disabled as it's not finished yet :yep: There have been many bug fixes and this current bug fix is a major one.

I have to finish coding and testing of the updating of these special datatype definitions that I found first before I can release this new version. Bad things will happen if these new special datatype definitions are not updated (if the GR2 file even has them - very few do).

[gap]

Not a good idea. I've seen Wings3D move vertices around.

I have fixed the bug you reported (it was in the strict and loose importers) and was able to successfully import your Wings3D file. I hope you looked at the results of that Wings3D file in the app. It actually made the tree LARGER.

I'll release a new version here very shortly with this problem fixed. This new version will have the decompression disabled as it's not finished yet :yep: There have been many bug fixes and this current bug fix is a major one.

I have to finish coding and testing of the updating of these special datatype definitions that I found first before I can release this new version. Bad things will happen if these new special datatype definitions are not updated (if the GR2 file even has them - very few do).

Okay, I will follow your suggestion and I will wait for the next version of your tool before releasing a DynEnv update with the reworked trees :up:

As usual you have been resolutive. Thank you! :salute:

P.S: I have made the tree much larger on purpose: I wanted to make sure I could spot the difference beyond any doubt. Next trees will be SMALLER ;)

[gap]

Another anomaly tha I forgot to mention before:

when I want to replace an existing obj file, during an export, GR2 Editor crashes. I can replicate this bug as many times as I want :yep:

[TheDarkWraith]

Another anomaly tha I forgot to mention before:

when I want to replace an existing obj file, during an export, GR2 Editor crashes. I can replicate this bug as many times as I want :yep:

Post a link to the file you had opened. Give me a step by step procedure of what you did so I can try and replicate the problem.

[TheDarkWraith]

v1.1.317.1 released. See post #1

Features disabled in the app:
- If any section has mixed values defined the app will refuse to open the file (I haven't finished coding this yet)
- If any GR2 file you try to load is compressed the app will immediately close it (because of the first item)

This version does not include the bug fix for the bug gap just reported. Once I get the file in question and the step-by-step procedure of what he did to create the bug I'll see what the problem is. If I fix it I'll release another new version as soon as it's fixed :up:

[gap]

Post a link to the file you had opened. Give me a step by step procedure of what you did so I can try and replicate the problem.

It is the same GR2 file that I had uploaded two hours ago. :up:

Testing v1.1.317.1 now :03:

[TheDarkWraith]

It is the same GR2 file that I uploaded two hours ago. :up:

Vegetation or Vegetation_stock? And what were you trying to do with it? I really need a step-by-step procedure so I can try and duplicate the problem. I have to walk it in Visual Studio's debugger so I can see what's going on.

How does it crash? What is the error? I currently see nothing wrong in the code for the exporter as far as creating the obj file. The app will not be able to export the same OBJ file if you have it opened via some other app (it has a lock on it by Windows). Ensure no other app has the file opened.

[gap]

Vegetation or Vegetation_stock? And what were you trying to do with it? I really need a step-by-step procedure so I can try and duplicate the problem. I have to walk it in Visual Studio's debugger so I can see what's going on.

select any mesh (tested with tree2 and tree6, but should be the same with other meshes)
export it (export settings don't really matter)
when requested if I wanted to specify a save location I clicked yes, and selected a folder on my desktop
everything should be okay :yep:

Now repeat the same steps, selecting the same save folder and file name. The saving process will hung up, and the preview window will show a flashing "Exporting Tree# Reading Mesh Data.." message, that cannot be closed. Everything else works normally (I can switch tabs, access menu, etc)

The same happens if the application is minimized before selecting the salve folder, during an export. :yep:

PS: there is not difference between Vegetation and Vegetation_stock, except for the additional strings added by GR2 Editor in Vegetation.GR2 ;)

[gap]

Little update:

I found a way to restore the correct working of GR2 Editor, and getting rid of the "Exporting Tree# Reading Mesh Data.." message: it is done by exporting again a mesh, and selecting a previously unused save name.

[TheDarkWraith]

select any mesh (tested with tree2 and tree6, but should be the same with other meshes)
export it (export settings don't really matter)
when requested if I wanted to specify a save location I clicked yes, and selected a folder on my desktop
everything should be okay :yep:

Now repeat the same steps, selecting the same save folder and file name. The saving process will hung up, and the preview window will show a flashing "Exporting Tree# Reading Mesh Data.." message, that cannot be closed. Everything else works normally (I can switch tabs, access menu, etc)

The same happens if the application is minimized before selecting the salve folder, during an export. :yep:

PS: there is not difference between Vegetation and Vegetation_stock, except for the additional strings added by GR2 Editor in Vegetation.GR2 ;)

ah ok, that should be an easy one to fix :up:
It didn't crash since you were able to select tabs, access menu, etc. If you notice that when it does something that it doesn't want you to mess with anything it will lock those out :D

[gap]

ah ok, that should be an easy one to fix :up:
It didn't crash since you were able to select tabs, access menu, etc. If you notice that when it does something that it doesn't want you to mess with anything it will lock those out :D

A possibly related fact I have noticed:

when the export options dialog pops up, minimizing GR2 Editor is forbidden. Not so for the next dialog (the one about save name and location). When an existing file name is selected, a window's window pop ups, asking if we are sure we want to overwrite the file. Is is possible that your program doesn't like it?

P.S: even after restoring the normal functioning of GR2 Editor (see my previous post), the hung up Export window remains in menory :hmmm:
Even after closing the application, it is still there...

[TheDarkWraith]

gap your problem should be fixed now.

v1.1.318.1 released. See post #1 for details.

Features disabled in the app:
- If any section has mixed values defined the app will refuse to open the file (I haven't finished coding this yet)
- If any GR2 file you try to load is compressed the app will immediately close it (because of the first item)

:|\\

[gap]

gap your problem should be fixed now.

v1.1.318.1 released. See post #1 for details.

Features disabled in the app:
- If any section has mixed values defined the app will refuse to open the file (I haven't finished coding this yet)
- If any GR2 file you try to load is compressed the app will immediately close it (because of the first item)

:|\\

v1.1.317.1 good bye, yours was a short existence http://www.smileyhut.com/sad/rip.gif :D

[gap]

v1.1.318.1 released. See post #1 for details.

Have you changed the way additional strings are read by the editor (v1.1.318.1)?

Now, every time I try opening a Vegetation.GR2 which had been previously patched with the missing strings (don't matter which version of the Editor/Viewer had added them), I receive the following error message:

http://img546.imageshack.us/img546/5033/dialogj.jpg

Native Vegetation.GR2 files are opened correctly. But as soon as they get patched, saved and closed, they can't be opened again. In other words, the last version can add missing strings, but can't read files which had been added those strings :hmmm:

[TheDarkWraith]

Have you changed the way additional strings are read by the editor (v1.1.318.1)?

Now, every time I try opening a Vegetation.GR2 which had been previously patched with the missing strings (don't matter which version of the Editor/Viewer had added them), I receive the following error message:

http://img546.imageshack.us/img546/5033/dialogj.jpg

Native Vegetation.GR2 files are opened correctly. But as soon as they get patched, saved and closed, they can't be opened again. In other words, the last version can add missing strings, but can't read files which had been added those strings :hmmm:

ah yes I did. Those darn duplicate pointers were causing me a nightmare! I know why it's doing this, I'll have a fix here shortly :up:

I'm also fixing the float precision problem that has existed since day 1 of the app. The problem was any float value read in was not being rounded to six decimal places.

[gap]

ah yes I did. Those darn duplicate pointers were causing me a nightmare! I know why it's doing this, I'll have a fix here shortly :up:

I'm also fixing the float precision problem that has existed since day 1 of the app. The problem was any float value read in was not being rounded to six decimal places.

Okay, waiting online for your updates :up:

[gap]

...and as we are at it: have you seen this other report by me? ;)

http://www.subsim.com/radioroom/showpost.php?p=2004003&postcount=1753

[TheDarkWraith]

v1.1.320.1 released. See post #1

Same restrictions as last as what features are disabled. Fixes problem posted by gap.

[TheDarkWraith]

...and as we are at it: have you seen this other report by me? ;)

http://www.subsim.com/radioroom/showpost.php?p=2004003&postcount=1753

I'll check it out tomorrow :up:

[gap]

v1.1.320.1 released. See post #1

Same restrictions as last as what features are disabled. Fixes problem posted by gap.

First test report:

the problen with the export process being hung up by unmanaged events (window minimization/file overwriting request) is still unsolved, but this is a minor flaw.

What matters is that now the editor is able to read correctly the Wings3D object file I had sent to you :yeah:

Tomorrow I will test if the modified trees are diplayed correctly in game. :up:

I'll check it out tomorrow :up:

no hurry :03:

[Targor Avelany]

edit: ugh... didn't read what app DOESN't do.

Btw, there are still problems with updating names/bones in any of the submarines. The only version that it is working on for me is 1_1_230_1

[Ekmek]

v1.1.320.1 released. See post #1

Same restrictions as last as what features are disabled. Fixes problem posted by gap.


I see it. But looks like the decompressor is still disabled. Keep up the great work! :woot:

[TheDarkWraith]

First test report:

the problen with the export process being hung up by unmanaged events (window minimization/file overwriting request) is still unsolved, but this is a minor flaw.

really? Then there is something I'm totally missing here :hmmm: How do I make this problem appear again?

Btw, there are still problems with updating names/bones in any of the submarines. The only version that it is working on for me is 1_1_230_1

What exactly is the problem and what do I do to make the problem appear?

I see it. But looks like the decompressor is still disabled. Keep up the great work! :woot:

Yep. It's disabled due to not finished coding in these special datatype definitions I found. They play major part in the vertex data.

[TheDarkWraith]

ok I think I finally see why you would still be having that problem gap. I was not enclosing any new objects created in at least try...finally blocks where in the finally I would dispose of the object. I was rather disposing of the object at the end of the function BUT there were chances the function would return before the end of it was reached (the finally block ensures the code contained in it will be executed before the function returns) :nope: Lots of changes to make...:dead:

[gap]

really? Then there is something I'm totally missing here :hmmm: How do I make this problem appear again?

Export a mesh, and when requested to specify file name and location, choose to overwrite an old obj file. A window requesting you to confirm the overwriting will pop up, but you won't be able to select neither 'yes' nor 'no':
you can resume working on GR2 Editor, but the mentioned window will remain in memory, and if you force its closing, the main process (GR2 editor) will be closed as well.

http://imageshack.us/scaled/thumb/839/screenshotler.jpg (http://img839.imageshack.us/img839/5492/screenshotler.jpg)


On a side note, I have checked a maginified tree in game. This is how it looks:

http://img37.imageshack.us/img37/5144/sh5img20130217131134.jpg

Some copies of it look okay, while others are cut in diagonal. :hmmm:
Evidently at least one of the 4 faces got screwed. Now I need to discover if someting I did in Wings 3D screwed it, or rather GR2 Editor is misreading its information.

Stay tuned :up:

[gap]

ok I think I finally see why you would still be having that problem gap. I was not enclosing any new objects created in at least try...finally blocks where in the finally I would dispose of the object. I was rather disposing of the object at the end of the function BUT there were chances the function would return before the end of it was reached (the finally block ensures the code contained in it will be executed before the function returns) :nope: Lots of changes to make...:dead:

As I told you, this bug is not such a big problem, as far as we remember not to save over existing files. Take your time on it TDW :salute:

[Targor Avelany]

What exactly is the problem and what do I do to make the problem appear?


In regards to the editing submarine gr2's:

Open any of the Uboat gr2s (VIIA for example).
Try renaming a bone.
Try saving:

Error comes up:
http://img834.imageshack.us/img834/5589/uboatgr2errorjpg.jpg

http://img850.imageshack.us/img850/3299/uboatgr2errorjpg1.jpg
Also, if I rename en-mass via 010Editor, after which try opening in more recent version: it obviously comes up with the checksum error, I click to fix it, it fixes it, but when I try to save: same as above.

In version 1_1_230_1 - no problem with either.

Also, of course, in the newest version, can't open any of the uboats.. Because of the error "Section 6's mixed values count calculated != file size in bytes"
I assumed that it was due to you disabling any loading of gr2s with mixed values.

[TheDarkWraith]

Export a mesh, and when requested to specify file name and location, choose to overwrite an old obj file. A window requesting you to confirm the overwriting will pop up, but you won't be able to select neither 'yes' nor 'no':
you can resume working on GR2 Editor, but the mentioned window will remain in memory, and if you force its closing, the main process (GR2 editor) will be closed as well.

On a side note, I have checked a maginified tree in game. This is how it looks:

Some copies of it look okay, while others are cut in diagonal. :hmmm:

Evidently at least one of the 4 faces got screwed. Now I need to discover if someting I did in Wings 3D screwed it, or rather GR2 Editor is misreading its information.

Stay tuned :up:

Easy way to determine if my app is causing the problem or not. Export the tree without making any changes to it. Re-import back into app. Save file. Exit app. Check in game. If renders fine then problem is not with app.

As far as the export problem you reported I finally got the app to do the problem. The problem is now fixed for good :up: You can export to an existing file without hanging anymore. That was an odd problem because it wasn't the apps fault - it was an OLE problem with the SaveFileDialog box running in a thread I spawned off :hmmm:

In regards to the editing submarine gr2's:

Open any of the Uboat gr2s (VIIA for example).
Try renaming a bone.
Try saving:

Error comes up:

Also, if I rename en-mass via 010Editor, after which try opening in more recent version: it obviously comes up with the checksum error, I click to fix it, it fixes it, but when I try to save: same as above.

In version 1_1_230_1 - no problem with either.

Also, of course, in the newest version, can't open any of the uboats.. Because of the error "Section 6's mixed values count calculated != file size in bytes"

I assumed that it was due to you disabling any loading of gr2s with mixed values.

You should've been able to open most of the sub files still. I'll look into the problems you have reported now :up:

[gap]

Easy way to determine if my app is causing the problem or not. Export the tree without making any changes to it. Re-import back into app. Save file. Exit app. Check in game. If renders fine then problem is not with app.

Yep I wanted to run exaclty this test, but didn't get time to do it yet :-?

As far as the export problem you reported I finally got the app to do the problem. The problem is now fixed for good :up: You can export to an existing file without hanging anymore. That was an odd problem because it wasn't the apps fault - it was an OLE problem with the SaveFileDialog box running in a thread I spawned off :hmmm:

:yeah:

[gap]

Easy way to determine if my app is causing the problem or not. Export the tree without making any changes to it. Re-import back into app. Save file. Exit app. Check in game. If renders fine then problem is not with app.

Okay TDW

I did as suggested by you, and I can confirm that GR2 Editor in not the culprit. Similarly, I can exclude Wings3D: I took the object generated by your app, I imported it in Wings and I exported without making any change. The tree, imported back in vegetation.GR2, showed correctly in game :yep:

Whatever was wrong, it had to be my mistake. Probably when I split one of the base edges in Wings, I broke object's geometry :hmmm:

[gap]

Tree update:

after several tests, I can declare that nothing was wrong with my scaled trees, except for the fact that they were... too big :huh:

Seems that SH5 trees can't trespass a given size. The fact that during my first test, where I had changed just one mesh, some trees were looking okay and some others were cut diagonally may depend on the fact that SH5 randomizes the size of each tree, for adding variety. Probably only the bigger trees were corrupted.

The good news is that we can reuduce their size at wish and by any percent with no adverse effects :up:

[Trevally.]

The good news is that we can reuduce their size at wish and by any percent with no adverse effects :up:

:Kaleun_Party:

[TheDarkWraith]

In regards to the editing submarine gr2's:

Open any of the Uboat gr2s (VIIA for example).
Try renaming a bone.
Try saving:

Error comes up:

Also, of course, in the newest version, can't open any of the uboats.. Because of the error "Section 6's mixed values count calculated != file size in bytes"
I assumed that it was due to you disabling any loading of gr2s with mixed values.

There's actually many reasons why the app was giving you problems with these sub GR2 files. It has nothing to do with mixed values (except for the Type II). Once loaded it has many broken chains which is causing all the problems.

These special GR2 files are a freakin nightmare. One thing they allow is embedded strings to not have to follow an alignment value (they only need 1 null termination character) but the sections still have to fall on a multiple of 0x4. Each section's alignment is also different - most of the sub's section 1 is set to 0x20 where this is usually 0x4. This obviously will cause problems if you try to add an embedded string that is not a multiple of 0x4 (including it's null termination character) because all the following sections will not be aligned to a 0x4 multiple anymore. My solution was to add 'filler' in the linked list to align these sections back to a 0x4 multiple and it works. I'm just working through some other problems noticed with these special GR2 files.

[TheDarkWraith]

Here's version 1.1.332.1 for testing: http://www.mediafire.com/?bgni4keov4ngq4w

What it will not allow:
- any GR2 file with mixed values
- any GR2 file with trackgroups
- any GR2 file with animations

What is enabled that is new:
- decompressor (remember that you have to have a specific version of the Granny Viewer installed on your computer for the decompressor to work!)

The problems with the subs (changing bone name and error from it) has been fixed. The problem gap reported of 'hanging' when exporting has been fixed. Many, many other problems I found by accident and from trying to load/modify the decompressed Augustus.GR2 file have been fixed also.

Starting with this version and forward the app will check for broken chains on file load and before saving. If any are found when loading the file it will close it (because it failed to read it in correctly). If any are found when trying to save it will refuse to save the file (because it's more than likely corrupt in memory). Let me know if you encounter any files with broken chains and send them or post a link to them here.

If you decompress a file I ask that you view it in Granny Viewer to ensure it opens correctly AND also reopen the decompressed file with the app to ensure the app reads the file correctly.
All decompressed files will be placed in app path\Decompressed\filename. Inside of that folder will contain all the decompressed sections and the actual decompressed GR2 file that the app made. You will also find another folder called Old. Inside that folder are the previous decompressed section files (if you chose to move them when decompressing).

NOTE: any file that has duplicates of anything (mainly extendeddata and extendeddatadata) will cause broken chains if you delete the main object that the duplicates are based on. I do not provide you this information in this version. The only way you will know this has happened is the app will report broken chains when trying to save. I'm coding this part currently for the next version.

:|\\

[gap]

Here's version 1.1.332.1 for testing: http://www.mediafire.com/?bgni4keov4ngq4w

The problems with the subs (changing bone name and error from it) has been fixed. The problem gap reported of 'hanging' when exporting has been fixed. Many, many other problems I found by accident and from trying to load/modify the decompressed Augustus.GR2 file have been fixed also.

:yeah:
I will test the fixed features asap


What it will not allow:
- any GR2 file with mixed values
- any GR2 file with trackgroups
- any GR2 file with animations

This excludes guns GR2's that I was messing with a while ago, but for the moment I will live with it :)


What is enabled that is new:
- decompressor (remember that you have to have a specific version of the Granny Viewer installed on your computer for the decompressor to work!)

which version? I have v 2.9.1.0, is it okay?
moreover, it didn't come with an installer, how can I tell your app where to look for granny viewer's exe? :hmm2:


Starting with this version and forward the app will check for broken chains on file load and before saving. If any are found when loading the file it will close it (because it failed to read it in correctly). If any are found when trying to save it will refuse to save the file (because it's more than likely corrupt in memory). Let me know if you encounter any files with broken chains and send them or post a link to them here.

yes, vegetation.GR2's: I can open vanilla ones, but if I tell your application to add the missing strings to them, when it tries to write the changes on disc a warning message pops up saying that broken chains were found in section 0. Files saved with previous versions of GR2 Editor can't be opened at all (same message on opening them) :03:

[Targor Avelany]

yay! Very nice, TDW!

Will be testing later today.

btw, it is hillarious to attempt and figure out replacement of mesh on an existing animation. Some funny stuff happens.

[TheDarkWraith]

which version? I have v 2.9.1.0, is it okay?
moreover, it didn't come with an installer, how can I tell your app where to look for granny viewer's exe? :hmm2:

yes, vegetation.GR2's: I can open vanilla ones, but if I tell your application to add the missing strings to them, when it tries to write the changes on disc a warning message pops up saying that broken chains were found in section 0. Files saved with previous versions of GR2 Editor can't be opened at all (same message on opening them) :03:

You'll have to send me v2.9.1.0 so I can RE it to find out where to inject my code and where to tell my code to install it's hooks.

I had a feeling that I was unknowingly corrupting GR2 files with previous versions :-? I'm still learning this file format to this very day.

Just adding missing strings shouldn't be causing you any problems. Have you tried this on a stock unmodified file?

yay! Very nice, TDW!

Will be testing later today.

btw, it is hillarious to attempt and figure out replacement of mesh on an existing animation. Some funny stuff happens.

The next version should discern between ridig and non-rigid (deformable) meshes in the meshes list box. This should help with that.

Working on the mixed values now so I can remove that file limitation on the next version.

[gap]

You'll have to send me v2.9.1.0 so I can RE it to find out where to inject my code and where to tell my code to install it's hooks.

v2.9.1.0:

https://www.dropbox.com/s/z5pajescgo2zlcg/Granny%20Viewer.rar :03:

Let me know if you find a more up-to-date version online :)


I had a feeling that I was unknowingly corrupting GR2 files with previous versions :-? I'm still learning this file format to this very day.

Rethink of all the progress you have done since when you started this project, I feel optistic :)


Just adding missing strings shouldn't be causing you any problems. Have you tried this on a stock unmodified file?

yes, unmodified vegetation.GR2. I can't save the missing strings on file. Previously modified files are not opened at all. In both cases I get a "broken chains in section 0" message.

[Targor Avelany]

You'll have to send me v2.9.1.0 so I can RE it to find out where to inject my code and where to tell my code to install it's hooks.

I had a feeling that I was unknowingly corrupting GR2 files with previous versions :-? I'm still learning this file format to this very day.

Just adding missing strings shouldn't be causing you any problems. Have you tried this on a stock unmodified file?

The next version should discern between ridig and non-rigid (deformable) meshes in the meshes list box. This should help with that.

Working on the mixed values now so I can remove that file limitation on the next version.

Awesome! Very excited!
It is possible that it also will eventually lead to my problem with the textures in the lifeboat project. I still haven't had time to sit down and write up w/ screenshots the process how the mess reproduced, but hopefully will be able to do it today.

[TheDarkWraith]

Rethink of all the progress you have done since when you started this project, I feel optistic :)


yes, unmodified vegetation.GR2. I can't save the missing strings on file. Previously modified files are not opened at all. In both cases I get a "broken chains in section 0" message.

I'll check this problem of adding the strings.

I wish the learning experience with this file type would end :shifty: It seems every time I turn around I learn something new! I'm nowhere near the end yet either as I have to decode animations yet :dead:

The good news is I just finished the code for reading these new special datatype definitions that describe vertex data (more specifically vertex data with mixed values) and all the error checking for them. Wow. It's amazing to me how important these suckers are. So much depends on these if the section's mixed values are > 0. The layout of the vertex data and each vertex data's size (for those that contain mixed values) is linked with these special datatype definitions!

The bad news is if you have added/removed vertices from a mesh that was defined by one of these special datatype definitions before the next version of the app I release then the file is corrupt :-? The next version of the app with all this special datatype definition checking will tell you if your file is corrupt or not :yep:

Awesome! Very excited!
It is possible that it also will eventually lead to my problem with the textures in the lifeboat project. I still haven't had time to sit down and write up w/ screenshots the process how the mess reproduced, but hopefully will be able to do it today.

High probability.

[TheDarkWraith]

all my mixed values code works flawlessly :rock: Thus I can lift the mixed values restriction (for certain sections) on the app now :D

My mixed values code knows how to deal with mixed values in sections 1 and 3. If it finds mixed values code in other sections it will refuse to open the file and will prompt you to contact me and send me the file you tried to open so I can examine it. I've actually added many of these contact me with file for anything that I'm unsure about/have no idea about. If you encounter one of these dialog boxes please send me the file and the error you encountered with it.

Gotta couple of things to wrap up before I can release the new version. With this new upcoming version you should be able to decompress most of the units in Civ5 :D

@gap - how does the app know which granny viewer? Simple. I tell it which versions it's allowed to use. Currently it's only allowed to use the one I specified earlier. Once I RE the one you have a link to I'll add it to the list of acceptable Granny Viewer versions. If the app cannot find the Granny Viewer (a virgin app starts with this path in the cfg file as blank) it will prompt you to point the app to it via an openfiledialog box. Once you open the correct Granny Viewer it will write the path to the cfg file so it remembers it :up:

[Ekmek]

Looks like TDW is using GrannyViewer 2.8.33.0.

http://www.mediafire.com/view/?0rk1wjlr7fl9ha8#

I couldn't find alink anywhere. Does someone have it? I have 2.8.46.0


After we decompress Civ5 files will we be able to recompress them?

[Targor Avelany]

ugh, lovely... You fixing things, broke most things I worked on, lol. :nope:

Also, replacing the names of bones and meshes via hex editor now breaks the chains and you cannot open it with the GR2 app.

So, I'm sitting renaming bones and meshes as it, via app. Which is painful. But I'm glad that it will be right! :salute:

I will also try and re-do the lifeboat and see what happens.

[TheDarkWraith]

v1.1.337.1 released . See post #1

Current restrictions (app will fail to load file):
- no trackgroups
- no animations

Restrictions lifted:
- mixed values

Bugs fixed:
- adding missing strings to GR2 file bug

Enhancements:
- when adding missing strings you no longer have to close and reload. App will add missing strings and continue loading the file
- more error checking

:|\\

[V13dweller]

I can't edit Aircraft, I just get this error.
********* Section 0 (arttoolinfo) has 74 mixed values defined.
The app has been temporarily disabled from reading any section that has mixed values defined. *********

Can anyone help me fix this? because I want to give the JU-290 bomber, bombs, because it doesn't carry any.
Also, what is a "Mixed value"?

[TheDarkWraith]

I can't edit Aircraft, I just get this error.
********* Section 0 (arttoolinfo) has 74 mixed values defined.
The app has been temporarily disabled from reading any section that has mixed values defined. *********

Can anyone help me fix this? because I want to give the JU-290 bomber, bombs, because it doesn't carry any.
Also, what is a "Mixed value"?

Interesting :hmmm: Section 0 has mixed values...I will take a look at this file and see if I can't figure out what these mixed values are defining :up: I don't know if mixed values are the correct term for these items in the GR2 file. It's a name I used to define them that makes sense to me.

[Targor Avelany]

Well, tested primarily on uboat7b_ai gr2, but will test some more on various files today.

So, as I mentioned before, now I cannot rename the bones/meshes via hex editor en-mass and then open the file with GR2 Editor/Viewer and change the checksum error, fix it and it's all awesome.

In light of that, as I assumed that it breaks the chains when I edit with hex, I decided to rename via app itself. Unfortunately, it does not work either. The app gives 2 variations of error:
1) There are broken chains in section 0, so no opening the file
2) can't find bone bindings, so no opening the file

Steps to reproduce:
1) open NSS_Uboat7b_AI. GR2 with the app.
2) rename 1-2 bones or meshes.
3) save the gr2 (doesn't matter if you save with the same name or "Save As..."
4) close the file
5) attempt to open the above saved file.

Rename of 1 bone (Model), the top bone, sometimes works. But not when trying to rename the rest of them.

[TheDarkWraith]

Well, tested primarily on uboat7b_ai gr2, but will test some more on various files today.

So, as I mentioned before, now I cannot rename the bones/meshes via hex editor en-mass and then open the file with GR2 Editor/Viewer and change the checksum error, fix it and it's all awesome.

In light of that, as I assumed that it breaks the chains when I edit with hex, I decided to rename via app itself. Unfortunately, it does not work either. The app gives 2 variations of error:
1) There are broken chains in section 0, so no opening the file
2) can't find bone bindings, so no opening the file

Steps to reproduce:
1) open NSS_Uboat7b_AI. GR2 with the app.
2) rename 1-2 bones or meshes.
3) save the gr2 (doesn't matter if you save with the same name or "Save As..."
4) close the file
5) attempt to open the above saved file.

Rename of 1 bone (Model), the top bone, sometimes works. But not when trying to rename the rest of them.

I will follow your above to try and simulate the problem now :up:

v1.1.339.1 released. See post #1

- fixes bug where duplicate data could possibly not be updated correctly
- linked list now correctly handles removing the main object of duplicates
- Essential embedded strings now displays only the missing strings to be added to the GR2 file when asking if user wants to add them

[TheDarkWraith]

Just tried v1.1.339.1 and everything works excellent. I was able to rename any number of meshes or bones without error. Saved and reloaded with no problems either. Probably the bugs I just fixed with the new version fixed the problem :up:

You should still be able to edit the names with hex editor. As long as you don't change the number of characters in the name with the hex editor the app will have no problem with them :salute:

[Targor Avelany]

Just tried v1.1.339.1 and everything works excellent. I was able to rename any number of meshes or bones without error. Saved and reloaded with no problems either. Probably the bugs I just fixed with the new version fixed the problem :up:

You should still be able to edit the names with hex editor. As long as you don't change the number of characters in the name with the hex editor the app will have no problem with them :salute:

WOOOOT!!!!!!!!!!!! :woot: :D :sunny:

Will test as soon as I get home today!

[V13dweller]

In your update, did you allow aircraft to be edited?

[Targor Avelany]

not quiet sure if I am doing something wrong or missing something:

this is an attempt to open a file, which was saved after editing from NSS_Uboat7b to NSS_Uboat9b via hex editor en-mass.

http://img835.imageshack.us/img835/6150/error113391.th.jpg (http://img835.imageshack.us/i/error113391.jpg/)

:/\\!!

[TheDarkWraith]

not quiet sure if I am doing something wrong or missing something:

this is an attempt to open a file, which was saved after editing from NSS_Uboat7b to NSS_Uboat9b via hex editor en-mass.

sounds like you changed the number of characters in one of the strings. You cannot simply add null characters (0x0) to take up space for a shorter name, the app will balk at that depending on:
- if pointers come before data the app knows that all strings have only 1 null character (0x0)
- if pointers come after data then the number of null characters are the number required to get to the alignment boundary (most in section 0 [where the strings are] are 0x4 (0x...0, 0x...4, 0x...8, 0x...C). If the alignment is 0x4 and the app reads 4 null characters and cannot find a pointer referencing it then it will throw an error (this is only true if the string doesn't end on an alignment boundary - if the string ends on an alignment boundary then the app will expect to read alignment number of null characters).

If the name was Test and alignment is 0x4 then the app is looking for:
Test00000000 (Test of course would be in hex numbers)

If the name was Test2 and alignment is 0x4 then the app is looking for:
Test2000000 (Test2 of course would be in hex numbers)

Try loading the stock 7b GR2 file to ensure you can load it without problems. I can load it without error using 1.1.339.1. I can also rename bones and meshes without error.

[Targor Avelany]

hmm. Strange. I guess I was messing it up somewhere, because this time it worked. Everything the same, even replacing the same way.

meh at me :nope:

Well, will be testing more later.

[TheDarkWraith]

hmm. Strange. I guess I was messing it up somewhere, because this time it worked. Everything the same, even replacing the same way.

meh at me :nope:

Well, will be testing more later.

Sounds good. Let me know of any problems :up:

I'm working on the next big thing for the app now :D

[Kaicokid]

For a DarkWraith you have a very bright uniform. Maybe that's why I found it a bit of a shock. Never mind you'll soon reach vice admiral. That will sound even better !!:salute:

[Targor Avelany]

ok, a quick question:

what style the .obj files should be in order to add subset meshes to gr2? The reason I'm asking is because when I'm attempting to add meshes the app comes up with this error:

http://img59.imageshack.us/img59/2475/errorsubsetadding.th.jpg (http://img59.imageshack.us/i/errorsubsetadding.jpg/)

[V13dweller]

Once again, I get an error trying to edit aircraft, just opening the GR2 causes this.
********* Section 0's mixed values count was found to be 45 vice 0.
Please forward file and error to TheDarkWraith @ Subsim.com for review *********
This is very annoying because I just want to add more nodes to the JU-290 so it is actually useful, because it currently only has 2 bomb nodes, and in real life it could carry 30 100 Kg bombs.

[TheDarkWraith]

ok, a quick question:

what style the .obj files should be in order to add subset meshes to gr2? The reason I'm asking is because when I'm attempting to add meshes the app comes up with this error:

http://img59.imageshack.us/img59/2475/errorsubsetadding.th.jpg (http://img59.imageshack.us/i/errorsubsetadding.jpg/)

Just regular OBJ format. Post a link to the OBJ file you were trying to import along with step-by-step of what you were doing so I can try and reproduce the error in Visual Studio's debugger.

Once again, I get an error trying to edit aircraft, just opening the GR2 causes this.
********* Section 0's mixed values count was found to be 45 vice 0.
Please forward file and error to TheDarkWraith @ Subsim.com for review *********
This is very annoying because I just want to add more nodes to the JU-290 so it is actually useful, because it currently only has 2 bomb nodes, and in real life it could carry 30 100 Kg bombs.

I haven't figured out what these mixed values are in section 0 yet. I believe that GR2 file has trackgroups and animations also so it might be awhile before the restrictions I put on the app about them are lifted. Reason being I found I wasn't reading everything from the file in regards to them. If I don't read something then I can't write it. If I don't write everything to the file it becomes corrupt.

[TheDarkWraith]

Created a copy of the CMD_small_boat so I could 'play' with it. Did some playing with it with new version I'm working on. What is new in it?

http://www.subsim.com/radioroom/picture.php?albumid=755&pictureid=6383

:D

[silentmichal]

Hi TDW!

I'm glad that you're on :subsim: :up:. O have a question: how to duplicate GR2 files, and make it visible ingame? For eg, I have 2 files: QR1_Room.gr2 and silentmichals_objects.gr2. And I want to join this files - using PRT files / LNX files. I made it with engine room - no problems, because there was a PRT file. But QR1_Room hasn't got own PRT file, so I created it, but game doesnt' see it! So, my main question is: How to "tell" game, that it must see my created PRT file? I hope you know it :yep:.


Best regards, Micha³.


EDIT


I found big bug, when I load file "Room_QR1.gr2" from my mod (silentmichal's interior mod 1.2.1), I have this:


https://dl.dropbox.com/u/97170234/bugs/2013-02-22_210726.png

[TheDarkWraith]

ah yes, Room_QR1 was the odd ball. I was trying to remember which one defined DiffuseColor0 as 3 floats instead of 3 bytes. Now I have to figure out how to account for this :hmmm:

[silentmichal]

And what about duplicating GR2 files?

[TheDarkWraith]

And what about duplicating GR2 files?

It's easily done. Follow the file structure of the diesel room. You have to tell where to find the PRT in one of the other files.

[silentmichal]

It's easily done. Follow the file structure of the diesel room. You have to tell where to find the PRT in one of the other files.


So, can I add "......MergeCtrl.........[text].....data/Submarine/Common/Rooms/QR1_Room.PRT" into DER_Room.PRT file?

[TheDarkWraith]

v1.1.343.1 released. See post #1

This version fixes the problem that silentmichal found.

The problem was due to DiffuseColor0 can be either a granny_real32, granny_uint8, or an uint8. I had it hard coded to uint8. Thus I had to change the app to make this value be generic (object) and cast it to the correct type when needed.

:|\\

[Targor Avelany]

v1.1.343.1 released. See post #1

This version fixes the problem that silentmichal found.

The problem was due to DiffuseColor0 can be either a granny_real32, granny_uint8, or an uint8. I had it hard coded to uint8. Thus I had to change the app to make this value be generic (object) and cast it to the correct type when needed.

:|\\

I alsmost want to skip my judo class tonight and just mess around with my meshes and gr2 files!!!! :rock:

[TheDarkWraith]

I alsmost want to skip my judo class tonight and just mess around with my meshes and gr2 files!!!! :rock:

Let me know of any problems :up:

Things are going to get really interesting with this app here very soon :sunny:

[gap]

Let me know of any problems :up:

relative to the judo class?!! :huh:

Things are going to get really interesting with this app here very soon :sunny:

:yeah:

[Targor Avelany]

relative to the judo class?!! :huh:



:yeah:
LOL

Let me know of any problems :up:

Things are going to get really interesting with this app here very soon :sunny:

will do.

[gap]

LOL

Keep us informed if someone bullies you during your lesson, Targor, you know we are a family :03: :D

[Ekmek]

Let me know of any problems :up:

Things are going to get really interesting with this app here very soon :sunny:


Sweet I hope it works with my version of grannyviewer or the 2.9 one that was posted because I cant find 2.8.33.0 anywhere...unless you post it with your app ;)

[Targor Avelany]

ok. Here's first:

Deleting a subset from a mesh:

1) load file (for me it was a uboat_9b (yeah yeah, renamed, but loading perfectly :P)
2) select a mesh with 2 or more subsets
3) delete 1 subset from selection, leave material bindings (if you try to delete material bindings, it will come up with error in screenshot 2)
4) attempt to save the mesh
5) see screenshot 1

http://img32.imageshack.us/img32/4720/deletesubseterr.th.jpg (http://img32.imageshack.us/i/deletesubseterr.jpg/)

http://img651.imageshack.us/img651/7492/deletesubseterrmat.th.jpg (http://img651.imageshack.us/i/deletesubseterrmat.jpg/)

[TheDarkWraith]

ok. Here's first:

Deleting a subset from a mesh:

1) load file (for me it was a uboat_9b (yeah yeah, renamed, but loading perfectly :P)
2) select a mesh with 2 or more subsets
3) delete 1 subset from selection, leave material bindings (if you try to delete material bindings, it will come up with error in screenshot 2)
4) attempt to save the mesh
5) see screenshot 1

http://img32.imageshack.us/img32/4720/deletesubseterr.th.jpg (http://img32.imageshack.us/i/deletesubseterr.jpg/)

http://img651.imageshack.us/img651/7492/deletesubseterrmat.th.jpg (http://img651.imageshack.us/i/deletesubseterrmat.jpg/)

Looking into it now :up:

I finally coded in the ability to discern between rigid and non-rigid (deformable) vertex data:

http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=6384

Will be available in next version.

[Targor Avelany]

here's another one:

1) subset per subset import
2) loose import
Imports properly, but when attempting to save:

http://img29.imageshack.us/img29/7600/import1mesherrj.th.jpg (http://img29.imageshack.us/i/import1mesherrj.jpg/)

[TheDarkWraith]

ok. Here's first:

Deleting a subset from a mesh:

1) load file (for me it was a uboat_9b (yeah yeah, renamed, but loading perfectly :P)
2) select a mesh with 2 or more subsets
3) delete 1 subset from selection, leave material bindings (if you try to delete material bindings, it will come up with error in screenshot 2)
4) attempt to save the mesh
5) see screenshot 1

oh that deleting of a mesh subset was a NASTY error :nope: I found the problem. The problem was the indices size was static to what the app calculated them to be from reading them from start to finish instead of being dynamic (number of indices * indice size). I've changed it to be dynamic now and that problem is fixed. Looking into the deleting material bindings one now :up:

[TheDarkWraith]

here's another one:

1) subset per subset import
2) loose import
Imports properly, but when attempting to save:

http://img29.imageshack.us/img29/7600/import1mesherrj.th.jpg (http://img29.imageshack.us/i/import1mesherrj.jpg/)

This is more than likely due to problem I just fixed above :yep:

[TheDarkWraith]

Here's v1.1.344.1 that fixes the nasty problem from above: http://www.mediafire.com/?1fzb3lv7ahkv25v

Test it out and make sure the problem is gone for good. I'm working on the material binding problem now.

[TheDarkWraith]

v1.1.345.1 released. See post #1

The material bindings bug was an error on my part. The index to be removed was being tested against something it shouldn't have thus resulting in the error you were receiving.

Fixes bugs reported so far :salute:

[V13dweller]

Has this fixed the aircraft bug yet?

[TheDarkWraith]

Has this fixed the aircraft bug yet?

There's no bug with aircraft. They contain trackgroups and animations and the app is currently disabled from loading any file containg any trackgroups and/or animations currently because I found I'm not reading everything in for them.


v1.1.346.1 released. See post #1

Instead of storing the vertices in my PrimaryVertexData class I hand them off to a new class so that they can be tracked in the linked list. Now you can get linked list data for sections 0-4 (which means I can error check them also). Section 5 is textures and have yet to run into a file with them. Section 6 I'm working on to get it tracked in the linked list. Section 7 I have no clue what it's for :-?

[gap]

There's no bug with aircraft. They contain trackgroups and animations and the app is currently disabled from loading any file containg any trackgroups and/or animations currently because I found I'm not reading everything in for them.

The next question is:

if someone used one of the older versions simply for adding bones to an object containing animations/trackgroups, would it corrupt the file anyway?

[TheDarkWraith]

The next question is:

if someone used one of the older versions simply for adding bones to an object containing animations/trackgroups, would it corrupt the file anyway?

more than likely yes :-? Try viewing it in Granny Viewer to see if the animations are screwed up or not.

[TheDarkWraith]

Using the Granny Viewer as my guide I'm going through my trackgroups and animations code to see where I might have screwed up in not reading in all the data. Hope to have it sorted out here soon :salute:

The trackgroups and animations code just reads in all the data. I have no clue yet how to assemble that data to view/change the mesh data to make animations possible.

[gap]

more than likely yes :-? Try viewing it in Granny Viewer to see if the animations are screwed up or not.

Just opened in Granny Viewer a copy of 37mmTSA.GR2 where I had changed bones hierachy and position using a previous version of your application.

Animations are displayed correctly :yep:

[TheDarkWraith]

Just opened in Granny Viewer a copy of 37mmTSA.GR2 where I had changed bones hierachy and position using a previous version of your application.

Animations are displayed correctly :yep:

you got lucky. By all accounts it shouldn't work because of what I'm about to explain.

Found the error with the TrackGroups and Animations. The error wasn't actually in any of them per se but actually in my ExtendedData class, specifically the reader function :huh: In the TrackGroups they define curve data. Well that curve data has a special type of granny data type, what I call an integer-string layout. It's only found in this curve data (that I've come across so far). That in itself is not the problem. The problem was I set a flag denoting that the reader encountered this so that it knew what to do with the number of items it had to read into for this. I never reset the flag when it was done reading the required number of items :nope: This was wreaking havoc on anything read in after that from then on. The fix was easy: reset the flag when done reading the required number of items. Finding the problem was like finding a needle in a haystack though! :dead:

I should be lifting the TrackGroups and Animations restrictions with the next version. I also plan on adding an Animations tab to the app. Don't get too excited - I still don't understand how all these TrackGroups make animations possible yet :-?

What I do know: the TrackGroups work on the deformable mesh data (section 3). Each TrackGroup somehow defines how to deform some part of the mesh. What the curve data means in those TrackGroups is still a mystery to me.

:|\\

[TheDarkWraith]

What I said about TrackGroups working on only deformable vertex data just got shot to pieces:

http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=6386

the pericope_ct proved me wrong. It contains nothing but rigid vertex data. It is also a compressed GR2 file but the app had no problem with that :D

I also had a perfect load of this compressed GR2 file (no broken chains in ANY section!) :rock: Looks like I fixed the not reading all the TrackGroups and Animation data finally :sunny:

[Targor Avelany]

yayay!!!!

I also will write up my problem with textures. Unfortunately it persists even with the newest version. I'll write up the adding subsets problem too.

[Targor Avelany]

Ok.

http://img402.imageshack.us/img402/7130/snap001b.th.jpg (http://img402.imageshack.us/i/snap001b.jpg/)
http://img824.imageshack.us/img824/4376/snap002v.th.jpg (http://img824.imageshack.us/i/snap002v.jpg/)
http://img145.imageshack.us/img145/6994/snap003j.th.jpg (http://img145.imageshack.us/i/snap003j.jpg/)
http://img849.imageshack.us/img849/4448/snap004f.th.jpg (http://img849.imageshack.us/i/snap004f.jpg/)
http://img152.imageshack.us/img152/9004/snap005y.th.jpg (http://img152.imageshack.us/i/snap005y.jpg/)

1) open stock file
2) select the mesh you want to add the subsets to
3) Go through the menu...
4) select the mesh (in this .obj file there are 4 meshes - so it is possible I have to add one by one, but not sure)
5) get the error

TDW, here's the file that I was attempting to use to add the subsets:
p.s. I deleted the link and file, assuming you grabbed it already.

[TheDarkWraith]

What all did you have checked for import (ao, normals, etc.)? Strict or loose import?

[Targor Avelany]

What all did you have checked for import (ao, normals, etc.)? Strict or loose import?

Selections: default as they come up. There is no selection for strict or loose, as I went through "Add Subsets" menu.

p.s. the second error reproduction, with textures, will write up tomorrow.
But one interesting point there: the way I get all the subsets into the GR2 is actual regular import of a mesh (loose, selecting everything). It imports all of the subsets and arranges them perfectly:
http://img834.imageshack.us/img834/130/snap007e.th.jpg (http://img834.imageshack.us/i/snap007e.jpg/)

Reason mentioning it is in regards to the above problem.

[Targor Avelany]

So, problem with textures:

http://img254.imageshack.us/img254/7135/snap008.th.jpg (http://img254.imageshack.us/i/snap008.jpg/)
http://img171.imageshack.us/img171/4222/snap009.th.jpg (http://img171.imageshack.us/i/snap009.jpg/)
http://img547.imageshack.us/img547/3376/snap010.th.jpg (http://img547.imageshack.us/i/snap010.jpg/)
http://img191.imageshack.us/img191/3870/snap011n.th.jpg (http://img191.imageshack.us/i/snap011n.jpg/)
http://img515.imageshack.us/img515/8513/snap012.th.jpg (http://img515.imageshack.us/i/snap012.jpg/)
http://imageshack.us/a/img39/6738/snap013.th.jpg (http://imageshack.us/photo/my-images/39/snap013.jpg/)
http://img26.imageshack.us/img26/3613/snap014r.th.jpg (http://img26.imageshack.us/i/snap014r.jpg/)
http://img89.imageshack.us/img89/3237/snap015e.th.jpg (http://img89.imageshack.us/i/snap015e.jpg/)
http://img854.imageshack.us/img854/3143/snap016p.th.jpg (http://img854.imageshack.us/i/snap016p.jpg/)

1) so, as I mentioned in my last post, I'm not able to add meshes. But, replacing the mesh altogether, works extremely well: it replaces the mesh, arranging the subsets in perfect order (see pic. 1)
2) now, for the textures. Currently, with materials import/textures import locked out, have to go through it manually. First: add all the textures.
3) Now, need to add 1st layer of material. It doesn't work if you finish here - need to go through the second layer of materials. First layer is just adding materials with 0 maps with existing textures.
4) Now, need to go through and define maps. This is the second layer
5) The next step is to add all the maps to material bindings of the mesh. :sunny:
6) Fix all the materials for each subset, hull for hull, floor for floor. Etc.
7) Save, reload, look pretty!
8) Load in Goblin Editor - not so much fun.

[Targor Avelany]

Found another little problem with materials/textures. This also has been tested on a stock file of Uboat_7b_AI.gr2

http://imageshack.us/scaled/medium/843/snap018e.jpg (http://imageshack.us/photo/my-images/843/snap018e.jpg/)
http://imageshack.us/scaled/medium/145/snap017x.jpg (http://imageshack.us/photo/my-images/145/snap017x.jpg/)
http://imageshack.us/scaled/medium/171/snap019.jpg (http://imageshack.us/photo/my-images/171/snap019.jpg/)

The error appears when you attempt to save the edited gr2.

Process:
1) add new texture
2) add new material with no maps for the above texture
3) add a materials with above texture as diffuse (or any other) map

[TheDarkWraith]

1) open stock file
2) select the mesh you want to add the subsets to
3) Go through the menu...
4) select the mesh (in this .obj file there are 4 meshes - so it is possible I have to add one by one, but not sure)
5) get the error

TDW, here's the file that I was attempting to use to add the subsets:
p.s. I deleted the link and file, assuming you grabbed it already.

The error was on my part. I retrieved the current number of vertices AFTER allocating space for more vertices. Which will throw an error because index is quite out of range. I now read the number of current verices before allocating space for more of them. That problem fixed.

That also exposed a bug in my function that calculates tangents and binormals (if the user decided to have them calculated). I forgot to pass an offset to this function to account for the current vertices. That problem has also been fixed.

I was finally able to import your OBJ file into the lifeboat:

http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=6403

I hope that is what your file was supposed to add to the lifeboat. Looks very strange to me. I viewed it in Wings3D and I see the same thing (minus the original lifeboat).

Yes the materials are messed up because I never coded that in. I currently set all new subsets to default to the first material binding of the mesh. Why? Well because I haven't decided how to best implement the correct way to do this yet. Same thing applies for importing a mesh. Once I have finally decided on the correct way to implement adding the materials defined in the mtllib I'll implement it.

I finally figured out what the mixed values for section 0 were for. I have that coded in and working correctly also now :D Now I'm just looking for a GR2 file that has mixed values for section 2 and/or 4. Those mixed values are probably defining Int16 indices vice Int32 indices but won't know for sure till I can look at one.

:|\\

[TheDarkWraith]

Found another little problem with materials/textures. This also has been tested on a stock file of Uboat_7b_AI.gr2

The error appears when you attempt to save the edited gr2.

Process:
1) add new texture
2) add new material with no maps for the above texture
3) add a materials with above texture as diffuse (or any other) map

I'll look into this now :salute:

[TheDarkWraith]

So, problem with textures:

1) so, as I mentioned in my last post, I'm not able to add meshes. But, replacing the mesh altogether, works extremely well: it replaces the mesh, arranging the subsets in perfect order (see pic. 1)
2) now, for the textures. Currently, with materials import/textures import locked out, have to go through it manually. First: add all the textures.
3) Now, need to add 1st layer of material. It doesn't work if you finish here - need to go through the second layer of materials. First layer is just adding materials with 0 maps with existing textures.
4) Now, need to go through and define maps. This is the second layer
5) The next step is to add all the maps to material bindings of the mesh. :sunny:
6) Fix all the materials for each subset, hull for hull, floor for floor. Etc.
7) Save, reload, look pretty!
8) Load in Goblin Editor - not so much fun.

What does it look like in Goblin? What is it supposed to look like?

[Targor Avelany]

What does it look like in Goblin? What is it supposed to look like?

The main hull texture is correct. The rest are very replaced; it seems like the textures/maps are assigned to wrong subsets. If you look close at the pics from GR2 Editor and Goblin you will see that the floor, the benches, the mid-section and the board/railing of the boat are messed up.

The error was on my part. I retrieved the current number of vertices AFTER allocating space for more vertices. Which will throw an error because index is quite out of range. I now read the number of current verices before allocating space for more of them. That problem fixed.

That also exposed a bug in my function that calculates tangents and binormals (if the user decided to have them calculated). I forgot to pass an offset to this function to account for the current vertices. That problem has also been fixed.

I was finally able to import your OBJ file into the lifeboat:

http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=6403

I hope that is what your file was supposed to add to the lifeboat. Looks very strange to me. I viewed it in Wings3D and I see the same thing (minus the original lifeboat).

Yes the materials are messed up because I never coded that in. I currently set all new subsets to default to the first material binding of the mesh. Why? Well because I haven't decided how to best implement the correct way to do this yet. Same thing applies for importing a mesh. Once I have finally decided on the correct way to implement adding the materials defined in the mtllib I'll implement it.

I finally figured out what the mixed values for section 0 were for. I have that coded in and working correctly also now :D Now I'm just looking for a GR2 file that has mixed values for section 2 and/or 4. Those mixed values are probably defining Int16 indices vice Int32 indices but won't know for sure till I can look at one.

:|\\

The weirdness comes from missing a hull. Since I needed to add meshes, I didn't want too many meshes :) So, in the file that I have sent you, there are just meshes of the rest of the boat, but the hull. :P

[TheDarkWraith]

The main hull texture is correct. The rest are very replaced; it seems like the textures/maps are assigned to wrong subsets. If you look close at the pics from GR2 Editor and Goblin you will see that the floor, the benches, the mid-section and the board/railing of the boat are messed up.

Can you post a link to the GR2 file the app made with all the materials and such set the way you wanted them (viewed correctly in app)? This way I can see what Granny Viewer and Goblin Editor are doing different and maybe I'm not understanding something correctly in regards to this.

The material file for those lifeboat parts exposed a flaw in my mtllib reader. The map_Ka and map_Kd had some entries that it didn't recognize: -s x y z where x,y, and z were float values. The -s means there are 3 floats after it that describe the texture scaling. I'm not quite sure how to utilize these values. I modified the app so that it can handle these (but no others) by reading them in but other than that it does nothing with them. You might be seeing strange renderings because of these texture scale values present in the mtllib file. Try editing the mtllib file and removing these -s entries from map_Ka and map_kd and see if you don't see the same thing you were seeing (same problem).

[Wurmonkel]

Hello TheDarkWraith,

can You send me the current Version of your GR2 Tool?
Thank you very much

P.S. Your PO box is full :03:

Regards,
Wurmi

[TheDarkWraith]

Hello TheDarkWraith,

can You send me the current Version of your GR2 Tool?
Thank you very much

P.S. Your PO box is full :03:

Regards,
Wurmi

You can find it at post #1 of this thread. I'll be releasing a new version here shortly that will allow files with animations and trackgroups again.

[Wurmonkel]

Thanks :up:

[Targor Avelany]

Can you post a link to the GR2 file the app made with all the materials and such set the way you wanted them (viewed correctly in app)? This way I can see what Granny Viewer and Goblin Editor are doing different and maybe I'm not understanding something correctly in regards to this.

The material file for those lifeboat parts exposed a flaw in my mtllib reader. The map_Ka and map_Kd had some entries that it didn't recognize: -s x y z where x,y, and z were float values. The -s means there are 3 floats after it that describe the texture scaling. I'm not quite sure how to utilize these values. I modified the app so that it can handle these (but no others) by reading them in but other than that it does nothing with them. You might be seeing strange renderings because of these texture scale values present in the mtllib file. Try editing the mtllib file and removing these -s entries from map_Ka and map_kd and see if you don't see the same thing you were seeing (same problem).

got it. Once I get home I'll test it and will let you know. If the problem continues, I'll post the file.

[TheDarkWraith]

got it. Once I get home I'll test it and will let you know. If the problem continues, I'll post the file.

I just did a little test to see what's going on. I added subsets to the cmd_small_boat from the OBJ file. Then I defined all the new textures and materials and set the mesh subsets to them:

http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=6407

Saved the new file. Opened in Granny Viewer and all is good (looks just like the app):
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=6408

Opened in Goblin and not even close:
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=6409

Now I just have to sit down and analyze all this to figure out what Goblin/SH5 is doing in regards to materials/subsets :hmmm:

Being that it rendered fine in Granny Viewer means the app is working correctly. Goblin/SH5 just does something funny with materials/subsets...

[TheDarkWraith]

Looks like I finally figured out what's going on with Goblin/SH5. You can only define 2 materials for each mesh. The third material (if defined) is an opacity or something else map (not quite sure but if you define a third material that has a texture Goblin/SH5 crashes). If a third material is defined it has to have no texture and no maps.

Now that's not all. The material bindings need to be defined in the order you will be using the materials. A subset can use the same material as another subset.

Materials added to a mesh's material bindings need to have maps defined (no textures). The material can have only 1 map defined - Diffuse.

Obviously the SH5 devs didn't understand the Granny system or they imposed their own set of rules :nope:

[TheDarkWraith]

v1.1.355.1 released. See post #1

Lifted restriction on GR2 files that contain trackgroups and/or animations (so yes you can now load any air unit now)
Fixed bugs reported/found few posts up

I'm working on adding the TrackGroups and Animations tabs to the app so the end-user can edit the data in them. Should be available in next version.

I have tested modifying/saving GR2 files that contain animations and/or trackgroups and didn't encounter any problems. That is not to say it is 100% perfect. Always save, exit the app, and reload the GR2 file to ensure it doesn't have any problems if it contains any of these. Also view in Granny Viewer to ensure the animations work correctly. You have been warned :)

:|\\

[Targor Avelany]

So, from what you said, if I understand correctly, each mesh cannot contain more than 2 materials with maps of textures defined? No matter how many subsets there is.

Hmm, that is workable. Annoying, but workable.

[TheDarkWraith]

So, from what you said, if I understand correctly, each mesh cannot contain more than 2 materials with maps of textures defined? No matter how many subsets there is.

Hmm, that is workable. Annoying, but workable.

That is correct. No matter how many subsets are defined each mesh can only contain 2 materials (that have maps defined). Not exactly limiting but not exactly freedom either.

I've been working on something that will fix this problem. Still working on it though :cool:

[TheDarkWraith]

v1.1.356.1 released. See post #1

This version fixes a bug I found. The bug only appeared if you made multiple changes to the file and saved the file multiple times during your 'session' with the app (like after every change) OR you were deleting items from the GR2 file or the app was reducing the size of the GR2 file for whatever reason. The bug would corrupt the GR2 file.

:|\\

[Targor Avelany]

quick question: if I have 3 maps defined in 1 material (diffuse/AO/bump), I still can have a second material assigned to the mesh, correct? (hopefully?)

I will be testing this all tomorrow - need to re-do all the uvws for the lifeboat.

[TheDarkWraith]

quick question: if I have 3 maps defined in 1 material (diffuse/AO/bump), I still can have a second material assigned to the mesh, correct? (hopefully?)

I will be testing this all tomorrow - need to re-do all the uvws for the lifeboat.

By all accounts yes. Each material can have any number of maps but each mesh can only have 2 materials assigned to it (SH5 restriction).

[TheDarkWraith]

v1.1.358.1 released. See post #1

While coding in the TrackGroups tab I noticed that the number of trackgroups displayed was doubled :o This was due to a bug in the animations code that was inadvertantly increasing the reference count of the TrackGroups and thus corrupting the GR2 file. This bug has been fixed in this version.

[Ekmek]

Does this still only work with your version on granny? (sorry cant check right now)

[TheDarkWraith]

Does this still only work with your version on granny? (sorry cant check right now)

yes currently only works with v2.8.33.0. I'll be REing a newer version sometime this week :up:

[TheDarkWraith]

v1.1.362.1 released. See post #1

Finished coding the TrackGroups tab for now. You can edit anything related to TrackGroups. You cannot add or delete them though as I don't understand their purpose yet. I'm hoping that by exposing them to you all (the ability to edit/change them) we can discover their purpose :yep: You'll have to open them up in Granny Viewer to check the animations/what has changed from your edits. I've already discovered a couple things about them...

I'm coding the Animations tab currently.

:|\\

[TheDarkWraith]

v1.1.363.1 released. See post #1

Finished coding in the Animations tab.

Let's start experimenting with the settings in these Animations and TrackGroups tabs so that we can figure out what they mean/do :yep:

:|\\

[gap]

v1.1.363.1 released. See post #1

Finished coding in the Animations tab.

Let's start experimenting with the settings in these Animations and TrackGroups tabs so that we can figure out what they mean/do :yep:

:|\\

:yeah:

[TheDarkWraith]

If you manage to discover anything in regards to the animations/track groups please post it here. Doesn't matter how trivial it may seem. A couple of small pieces of the puzzle can unlock a large piece of the puzzle :yep: Did I mention that I love puzzles? :D

Anything that has Flags means this:
- a value of 0x0 means no translating, no rotations, and no scaling/shearing
- a value of 0x1 means has position (translating) info
- a value of 0x2 means has orientation (rotation) info
- a value of 0x4 means has scale/shear info
The above are bit values so you can combine them. Thus a value of 0x5 would mean:
- has position (translating) info and scale/shear info but no orientation (rotation) info

TrackGroup TransformTracks:
- The name of the transform track comes from either a bone or mesh
- PositionCurve.CurveData: Controls: the three float values define the X,Y,Z offset of the object. If they are defined then these will be added to the object's original defined position. How do we know which object this is working on? The name property (the name displayed) is the name of the bone or mesh this will be applied on.

[gap]

If you manage to discover anything in regards to the animations/track groups please post it here. Doesn't matter how trivial it may seem. A couple of small pieces of the puzzle can unlock a large piece of the puzzle :yep: Did I mention that I love puzzles? :D

Sure, these days I am just messing with guns elevations, which are strictly connected with their animation :up:

[TheDarkWraith]

what I posted about the Flags doesn't seem to always apply in the TrackGroups :hmmm:

[TheDarkWraith]

I wrote some code that allows the app to delete VectorTracks from a TrackGroup. You will be able to either delete a VectorTrack one at a time or delete them all at once :D Writing the code to delete the TransformTracks currently.

As a test I deleted all the VectorTracks from an aircraft and viewed it in Granny Viewer. The animations still work so that means the TransformTracks and responsible for animations :yeah: Now just have to figure out these TransformTracks. Once the code is in place to delete TransformTracks I will be able to narrow down which one (TransformTrack) is responsible for the propeller's animation and thus should make it easier to decipher these TransformTracks :sunny:

Now I just have to test how the game handles this (all VectorTracks removed). I'm hoping for a certain effect :cool:

:|\\

[TheDarkWraith]

well that theory was shot to pieces. I was hoping that maybe by deleting all the VectorTracks the airplane would still be visible after it died (exploded). Don't understand the purpose of these VectorTracks :hmmm:

v1.1.365.1 released. See post #1

You now have the ability to delete VectorTracks from a TrackGroup.

[gap]

As a test I deleted all the VectorTracks from an aircraft and viewed it in Granny Viewer. The animations still work so that means the TransformTracks and responsible for animations :yeah:

Following your progress with high interest. I couldn't get the sense of the above sentence though: did you mean that TransformTracks are responsible for animations or, as it would be more logical, tha they are not? :hmm2:

[Ekmek]

My GR2s aren't opening. It was either 355 or 356 that I first tried it and it opened that old augustus gr2 but wouldn't open others. Now with 365 it says "failed to retrieve handle to Granny viewer process"


I attached a rar with a few gr2's that are created with "grannymaterialhacker" it was a quick utility that made game playable GR2s for reskinning. The program cant access all the textures (probably because if the hidden stuff you found) but I included it and all the DLLs so maybe you can find how they did it. They lost their source code in a burglary but said that the program can be decompiled in Reflector and was done in C++. I hope it helps

http://www.mediafire.com/?mtv89wmrbabatv1


Also, they made their program use the one of the DLLs to make the GR2s for civ5. Maybe you can see what they did so we can recompress? just a thought, nothing urgent. Thank you for your work!

[TheDarkWraith]

My GR2s aren't opening. It was either 355 or 356 that I first tried it and it opened that old augustus gr2 but wouldn't open others. Now with 365 it says "failed to retrieve handle to Granny viewer process"


I attached a rar with a few gr2's that are created with "grannymaterialhacker" it was a quick utility that made game playable GR2s for reskinning. The program cant access all the textures (probably because if the hidden stuff you found) but I included it and all the DLLs so maybe you can find how they did it. They lost their source code in a burglary but said that the program can be decompiled in Reflector and was done in C++. I hope it helps

http://www.mediafire.com/?mtv89wmrbabatv1


Also, they made their program use the one of the DLLs to make the GR2s for civ5. Maybe you can see what they did so we can recompress? just a thought, nothing urgent. Thank you for your work!

Run the app with admin rights. Ensure you didn't install your Granny Viewer or the app in the \Program Files or \Program Files (x86) folder. The error of failed to retrieve handle to blah blah is Windows imposing security restrictions on you.

I'm not using any outside DLLs with the app to avoid legal problems. I'll use a company's app against them (ala Granny Viewer) though as there are no legal ramifications against injecting code and hooks into a running process.

I can read the whole GR2 file now except for embedded images without using any DLL. Because I can read it I can also write it. I don't need to look at any DLL or RE any DLL to find out how to read a GR2 file anymore. I understand the structure/layout and how to manipulate it :D

There really is no need to recompress a GR2 file unless you are installing it on a tablet or handheld device where the harddrive space is small. You have to understand that a compressed GR2 file still has to be decompressed when loaded. The file is junk unless it's decompressed. This adds in the loading time of whatever app due to having to decompress x GR2 files. Being already decompressed speeds up the loading time :yep: Compressing a GR2 file is just one way to 'hide' the information contained in it.

[Ekmek]

Run the app with admin rights. Ensure you didn't install your Granny Viewer or the app in the \Program Files or \Program Files (x86) folder. The error of failed to retrieve handle to blah blah is Windows imposing security restrictions on you.

I'm not using any outside DLLs with the app to avoid legal problems. I'll use a company's app against them (ala Granny Viewer) though as there are no legal ramifications against injecting code and hooks into a running process.

I can read the whole GR2 file now except for embedded images without using any DLL. Because I can read it I can also write it. I don't need to look at any DLL or RE any DLL to find out how to read a GR2 file anymore. I understand the structure/layout and how to manipulate it :D

There really is no need to recompress a GR2 file unless you are installing it on a tablet or handheld device where the harddrive space is small. You have to understand that a compressed GR2 file still has to be decompressed when loaded. The file is junk unless it's decompressed. This adds in the loading time of whatever app due to having to decompress x GR2 files. Being already decompressed speeds up the loading time :yep: Compressing a GR2 file is just one way to 'hide' the information contained in it.


Thanks. I got the GrannyViewer going but when I tried to open the montezuma.gr2 I can see it/decompress it in grannyviewer but then when I go to your app I get the Unhandled Exception error.

The GR2 in question is with the the last link I posted.

[TheDarkWraith]

Thanks. I got the GrannyViewer going but when I tried to open the montezuma.gr2 I can see it/decompress it in grannyviewer but then when I go to your app I get the Unhandled Exception error.

The GR2 in question is with the the last link I posted.

Excellent. I'll check out that GR2 file to see what's going on :up:

[TheDarkWraith]

That montezuma.GR2 is a doozy :huh: Most of the 'rules' I thought I knew just got shattered by it :shifty: It exposed a new datatype in the datatype definitions - granny_real16 so that's a positive. It'll take me some time to analyze this and make the necessary changes :cool: I've already made a few that were easy to do. This granny_real16 though is something I was hoping I would never see :dead:

[Ekmek]

That montezuma.GR2 is a doozy :huh: Most of the 'rules' I thought I knew just got shattered by it :shifty: It exposed a new datatype in the datatype definitions - granny_real16 so that's a positive. It'll take me some time to analyze this and make the necessary changes :cool: I've already made a few that were easy to do. This granny_real16 though is something I was hoping I would never see :dead:


ouch! I got faith in you man!

[TheDarkWraith]

ouch! I got faith in you man!

It's not that bad. The hardest part was finding a float16 data type. C# doesn't define that value type but DirectX does: Microsoft.DirectX.Single16 :D Since I'm already using DirectX for the rendering it's a no problem :salute:

[TheDarkWraith]

v1.1.371.1 released. See post #1

You need to upgrage to this version if you are using older versions. This version fixes some inconsistencies found in the app while trying to load the montezuma GR2 file (this file exposed some problems I wasn't aware of!)

This version also lets you delete transformtracks from a trackgroup. The transformtrack(s) in conjuction with an animation is what lets animation happen. The animation will define the trackgroup(s) it is tied to.

I still haven't figured out how the transform track(s) cause animation. I'm thinking that they are defining bezier curves but not 100% sure yet :hmmm:

You still won't be able to open any GR2 file that contains granny_real16 values yet (montezuma). I'm still coding that in :)

[TheDarkWraith]

just finished updating the app so that it can handle any granny_real16 value in the vertex data. Was able to read in all the montezuma's vertex data with no issues :D

Now just have to update the app to handle granny_real16 indices :)

[Ekmek]

wow, that was quick!:salute:

[TheDarkWraith]

Coded in the reading of 16 bit indices. App is really coming along now :D

http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=6439

Now there is a wide range of GR2 files it can open. Should only be a limited few it will have problems with.

The granny_real16 is still a little problem. I can read them no problem. The problem is when it comes time to write them. I read the granny_real16 values as 16 bit values but then cast them to 32 bit floats internally (actually I read the 2 bytes that make up the granny_real16 value then pass this to a function that converts the 2 bytes to a float value). This way I didn't have to make tons of internal code changes. It also helped because there would be a big problem with VertexDeclarations because they don't have a type that describes 3 float16 values.

What I'm thinking about doing is converting any granny_real16 values to granny_real32 values. This will increase the file size but it's all I can do until I can find a way to convert a float (4 bytes) into a 16 bit float. Microsoft DirectX's 16 bit float is useless - you can't use a BinaryWriter to write it nor can you cast it to anything. Does anyone know of any code that will convert a float (or single or double) to a 16 bit value :06: Obviously there is a way to do it because the granny_real16 value exists in the GR2 file :hmmm:

Also made a code change in regards to a mesh's visibility. If the mesh has more than 1 bone binding then the app will set the visibility of the mesh to visible. Most of these GR2 files outside of SH5 don't have the same extendeddata for the bones that specifies it's visibility.

[TheDarkWraith]

v1.1.374.1 released. See post #1

The app will now let you load a GR2 file that has 16 bit values

If the app has 16 bit values it is locked out from doing many things. Basically you can view the GR2 file and you can export from it. You cannot import into it or do anything that would change the file structure (you are totally locked out from saving it). Reason is I haven't finished coding that part that deals with writing 16 bit values yet.

:|\\

[TheDarkWraith]

after much searching I finally found a class for C# that works with 16 bit floats :rock:No longer need to convert 16 bit vertex data to 32 bit. I can now write 16 bit floats :D Internally the app uses 32 bit data for vertex data and indices (if they are 16bit in the GR2 file they are read as a 16bit value but then converted to 32bit) but when it comes time to write the data it will convert the necessary data on the fly back to 16 bit before writing.

:|\\

[Ekmek]

Nice! This thing is really coming along. I still need to learn my way around it though.

[TheDarkWraith]

Nice! This thing is really coming along. I still need to learn my way around it though.

It's maturing quite nicely.

Just found a critical error in the app. I removed the download link in post #1.

DO NOT IMPORT ANYTHING USING CURRENT VERSION POSTED AT POST #1 OR ANY OTHER EARLIER VERSIONS

The critical error is if the vertex data contains DiffuseColor0 data I'm presently not accounting for that when I allocate space for additional vertices in the GR2 file. This, of course, will totally corrupt the mesh data in the GR2 file. If the vertex data doesn't contain a DiffuseColor0 component then everything is fine.

I'm working on the error currently.

I've also discovered another critical error in the app that was exposed by the montezuma GR2 file. When I would allocate/deallocate space for indices/vertices the app was not checking to ensure they were properly aligned to the section's alignment value. This will also corrupt the GR2 file.

Live and learn :dead: The more files I try to open with the app the more I learn and the more robust the app becomes.

I will post a new version when the errors have been fixed.

[gap]

I will post a new version when the errors have been fixed.

Looking forward to it :sunny:

[Targor Avelany]

It's maturing quite nicely.

Just found a critical error in the app. I removed the download link in post #1.

DO NOT IMPORT ANYTHING USING CURRENT VERSION POSTED AT POST #1 OR ANY OTHER EARLIER VERSIONS

The critical error is if the vertex data contains DiffuseColor0 data I'm presently not accounting for that when I allocate space for additional vertices in the GR2 file. This, of course, will totally corrupt the mesh data in the GR2 file. If the vertex data doesn't contain a DiffuseColor0 component then everything is fine.

I'm working on the error currently.

I've also discovered another critical error in the app that was exposed by the montezuma GR2 file. When I would allocate/deallocate space for indices/vertices the app was not checking to ensure they were properly aligned to the section's alignment value. This will also corrupt the GR2 file.

Live and learn :dead: The more files I try to open with the app the more I learn and the more robust the app becomes.

I will post a new version when the errors have been fixed.

Hahahahaha!!! Every single time I'm getting close to finishing my lifeboat model and importing it and adjusting the bones, something like this happens :))))))

Glad that the app is maturing pretty well! :yeah: You are doing some amazing job, TDW!

Just funny how it works out :rotfl2:

[TheDarkWraith]

Hahahahaha!!! Every single time I'm getting close to finishing my lifeboat model and importing it and adjusting the bones, something like this happens :))))))

Glad that the app is maturing pretty well! :yeah: You are doing some amazing job, TDW!

Just funny how it works out :rotfl2:

Lifeboat is fine. It doesn't have DiffuseColor0 defined :up: You are safe.

[TheDarkWraith]

Just tested all the new code for ensuring indices and vertices are aligned to the section's alignment value on the lifeboat and all went well. Now to test the montezuma file. If it can make it through it we should be good :yep:

[Targor Avelany]

Just tested all the new code for ensuring indices and vertices are aligned to the section's alignment value on the lifeboat and all went well. Now to test the montezuma file. If it can make it through it we should be good :yep:
:up: :yeah: :rock:

[TheDarkWraith]

Just did a test to see how my code was coming along. Test worked beautifully. What I did was add subsets to the headgear mesh on the montezuma. I added the subsets from the sub's periscope (5 subsets added). You can see the scale of the montezuma compared to SH5's items:
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=6488

This test proved that I can read/write 16bit floats and read/write 16bit indices and that I can add data/remove data from a GR2 file whose alignment value is not 0x4 (this one is 0x20 for each section!). Still more work to do :D

[TheDarkWraith]

well this montezuma GR2 file is a real pain in the neck. It's a good pain though as it shows the weaknesses and problems with my app. I'm still working through all the problems it has exposed. Lots of new 'rules' are defined by this GR2 file in regards to alignment. Some items are always aligned and some are not :-? Still chugging along...

[gap]

Testing the last version of your application with 20mm_C30.GR2, on loading the GR2 I get the usual message that "This GR2 file is missing the following essential embedded strings", but no string is listed below. Is that normal? :hmmm:

[TheDarkWraith]

Testing the last version of your application with 20mm_C30.GR2, on loading the GR2 I get the usual message that "This GR2 file is missing the following essential embedded strings", but no string is listed below. Is that normal? :hmmm:

Yes, it's the blank embedded string. I should update the app so that it encloses each one in 's.

Go into Sentinel (press F1) and type:

dumpsectiondata all

If any of the section's Alignment value doesn't equal 0x4 the app WILL corrupt the file if you try to save it.

[gap]

Yes, it's the blank embedded string. I should update the app so that it encloses each one in 's.

Go into Sentinel (press F1) and type:

dumpsectiondata all

If any of the section's Alignment value doesn't equal 0x4 the app WILL corrupt the file if you try to save it.

Okay :up:

I have been looking into gun animations during the last 30 minutes. I wonder if this (http://www.subsim.com/radioroom/showpost.php?p=2000403&postcount=372) problem (see also following posts for further information) is related with animations/trackgroups :hmmm:

[V13dweller]

Could you post a link for the newest version?
The front page's link is not usable.

[TheDarkWraith]

Could you post a link for the newest version?
The front page's link is not usable.

Still working on it. A GR2 file I tried to load (non-SH5 one) exposed many problems with my app that I'm having to fix :-?

[V13dweller]

What about a link to the previous version?
I can't seem to find any links, and I don't have the patience to scan though all 130 pages...

[V13dweller]

I managed to find an old version on my mac, so Don't worry.

[Targor Avelany]

having trouble with cloning bones in 271. When I attempt to clone a bone it throws an error, after which a secondarry attempts screams with reference of "0" errors.

When I try to make a new bone: nothing happens (no new bone

I will post a screenshot later today.

[Targor Avelany]

Here we go.

So, this is what's happening when I'm trying to clone a bone in the model:


http://img706.imageshack.us/img706/5942/snap025od.th.jpg (http://img706.imageshack.us/i/snap025od.jpg/)

http://img42.imageshack.us/img42/733/snap021.th.jpg (http://img42.imageshack.us/i/snap021.jpg/)


http://img33.imageshack.us/img33/7518/snap022z.th.jpg (http://img33.imageshack.us/i/snap022z.jpg/)

http://img12.imageshack.us/img12/8089/snap023y.th.jpg (http://img12.imageshack.us/i/snap023y.jpg/)

http://img560.imageshack.us/img560/4835/snap024.th.jpg (http://img560.imageshack.us/i/snap024.jpg/)

[TheDarkWraith]

Here we go.

So, this is what's happening when I'm trying to clone a bone in the model:


http://img706.imageshack.us/img706/5942/snap025od.th.jpg (http://img706.imageshack.us/i/snap025od.jpg/)

http://img42.imageshack.us/img42/733/snap021.th.jpg (http://img42.imageshack.us/i/snap021.jpg/)


http://img33.imageshack.us/img33/7518/snap022z.th.jpg (http://img33.imageshack.us/i/snap022z.jpg/)

http://img12.imageshack.us/img12/8089/snap023y.th.jpg (http://img12.imageshack.us/i/snap023y.jpg/)

http://img560.imageshack.us/img560/4835/snap024.th.jpg (http://img560.imageshack.us/i/snap024.jpg/)

I'll check it out this weekend :up:

[Ekmek]

To guys that have been using the tool for awhile: Is there a way to export the gr2 to a different format yet? I thought there was but couldn't find it.

Thanks

[gap]

To guys that have been using the tool for awhile: Is there a way to export the gr2 to a different format yet? I thought there was but couldn't find it.

Thanks

3D meshes can be exported in obj format, and textures can be saved in a bunch of formats, if this is what you meant :hmm2:

[Ekmek]

3D meshes can be exported in obj format, and textures can be saved in a bunch of formats, if this is what you meant :hmm2:


yes it is. thanks.

Can we export skeletons?

[gap]

yes it is. thanks.

My pleasure :)

Can we export skeletons?

If I remember correctly, no.

[Targor Avelany]

yes it is. thanks.

Can we export skeletons?

No, as the animation haven't been figured out yet.

[Targor Avelany]

Well, today I learned, after about 5 hours, that .dat animations does not work in sh5... frack...

Otherwise:

http://img401.imageshack.us/img401/7197/snap026.th.jpg (http://img401.imageshack.us/i/snap026.jpg/)

[gap]

Well, today I learned, after about 5 hours, that .dat animations does not work in sh5... frack...


What animations are you talking about, Targor?

Dat mesh animations should work. Look at the flags, or at the dolphins and whales that have been included in OHII. They are dat objects, and their animations seem to show correctly in game :yep:

[Targor Avelany]

What animations are you talking about, Targor?

Dat mesh animations should work. Look at the flags, or at the dolphins and whales that have been included in OHII. They are dat objects, and their animations seem to show correctly in game :yep:

hmhmhmhmh.... That is good news.

What I was trying to do is to re-do the open-close of the tubes. brrr... heaving major headache atm, lol

[gap]

hmhmhmhmh.... That is good news.

What I was trying to do is to re-do the open-close of the tubes. brrr... heaving major headache atm, lol

I don't quite follow you... aren't the tubes subsets in the same GR2 file as boat's hull 3d model? :hmmm:

Their opening/closing might be controlled by a dedicated controller, like antenna's rotation.

[Targor Avelany]

I don't quite follow you... aren't the tubes subsets in the same GR2 file as boat's hull 3d model? :hmmm:

Their opening/closing might be controlled by a dedicated controller, like antenna's rotation.

nope, they are not. They are in a separate file called Room_EXT - Torp Doors + Anim.GR2 that get's called via .prt file and MergeCtrl controller.

But that is not the problem. I'm being dumb and can't make a new .dat file with keyframes from sh3 dat file copied to animate in Goblin... Messing up in controllers somewhere, somehow

[gap]

nope, they are not. They are in a separate file called Room_EXT - Torp Doors + Anim.GR2 that get's called via .prt file and MergeCtrl controller.

But that is not the problem. I'm being dumb and can't make a new .dat file with keyframes from sh3 dat file copied to animate in Goblin... Messing up in controllers somewhere, somehow

How do you handle the dat file? s3d or hex editor?

[Targor Avelany]

How do you handle the dat file? s3d or hex editor?

atm - s3d. And it works in s3d. Just not in Goblin..

Hope you enjoyed the pic the prev page.

[gap]

atm - s3d. And it works in s3d. Just not in Goblin..

Hope you enjoyed the pic the prev page.

:yep: :Kaleun_Salivating:

[Targor Avelany]

hmm... 1) not sure if MergeCtrl controller works on .dat files, which will suck
2) still need to figure out how to make new animation in 3ds max and put it in .anm and get it into .dat file as it seems that Goblin doesn't like keyframe-blabla controller from sh3 that much (demanding .dlls)

ugh...

[Madox58]

S3D will only import/export keyframe animations.

Doing keyframes in 3d Max is pretty simple with a good instructions.
Many can be found on the web with a quick search.

What you need to do is have a way to export each frame as an obj file.
That takes a plug-in.
Scriptspot.com has that.

Then you need to tell S3D all the timing information after you import those.

Sounds hard but it's not to bad.
:03:

[Targor Avelany]

S3D will only import/export keyframe animations.

Doing keyframes in 3d Max is pretty simple with a good instructions.
Many can be found on the web with a quick search.

What you need to do is have a way to export each frame as an obj file.
That takes a plug-in.
Scriptspot.com has that.

Then you need to tell S3D all the timing information after you import those.

Sounds hard but it's not to bad.
:03:

thank you, privateer! This actually makes sense now!

[gap]

nice to see you here privateer, it has been longe since your last post on SH5 forum :salute:

S3D will only import/export keyframe animations.

....

What you need to do is have a way to export each frame as an obj file.

...

Then you need to tell S3D all the timing information after you import those.


yes Targor, as I told you the other day, look at one of the animated dat objects to better understand how it all works. :yep:


Doing keyframes in 3d Max is pretty simple with a good instructions.
Many can be found on the web with a quick search.

I wonder how good is Blender at that? :hmm2:

[Targor Avelany]

nice to see you here privateer, it has been longe since your last post on SH5 forum :salute:



yes Targor, as I told you the other day, look at one of the animated dat objects to better understand how it all works. :yep:



I wonder how good is Blender at that? :hmm2:

heh, I have looked. But it only confused me more :) :rotfl2:
I pretty much started looking at how to export animation into .anm files, as it seems that s3d can import em (at least it is an option on the list of imports)

[Ekmek]

I wonder how good is Blender at that? :hmm2:


I'v done blender keyframes for export as nif/kf files for civ4.

Blender is pretty good but when I imported a kf it would be missing stuff and export I had to make sure all bones were accounted for.

the set up for blender 2.49 that I used was a bit confusing at first but I found a youtube video showing how to do it and it made sense pretty quick.

[Targor Avelany]

well, it seems that MergeCtrl is not working for .dat files. you can merge the file to gr2, but not with controller. which is very annoying

[TheDarkWraith]

well, it seems that MergeCtrl is not working for .dat files. you can merge the file to gr2, but not with controller. which is very annoying

It should. IIRC I was able to merge a DAT file onto a GR2 file :hmmm: You just have to tell it where to find the file. Look in the folder containg the sub's rooms and waypoints. You'll find the information you are looking for there.

[Targor Avelany]

It should. IIRC I was able to merge a DAT file onto a GR2 file :hmmm: You just have to tell it where to find the file. Look in the folder containg the sub's rooms and waypoints. You'll find the information you are looking for there.

the merging as is - not a problem. but when I try to do it via MergeCtrl and .prt file (have to make new animation for tube doors and have to do in dat for now) - it doesn't show up and binds as it should.

[V13dweller]

IS the latest version ready? because the last version I had, still does not allow me to edit aircraft.

[Targor Avelany]

ok. Here is a question, as I'm getting confused a bit here:

when I import the meshes, they mirror-image in the import... Wth am i missing? :doh:

[TheDarkWraith]

ok. Here is a question, as I'm getting confused a bit here:

when I import the meshes, they mirror-image in the import... Wth am i missing? :doh:

Don't understand :06: Can you post a screenshot?

[V13dweller]

Could you link the latest version please?

[Targor Avelany]

Don't understand :06: Can you post a screenshot?

http://img823.imageshack.us/img823/8839/snap029.th.jpg (http://img823.imageshack.us/i/snap029.jpg/)
http://img96.imageshack.us/img96/4149/snap028b.th.jpg (http://img96.imageshack.us/i/snap028b.jpg/)

[Targor Avelany]

Here is a weird bug when I'm trying to delete a material that is not attached to any of the meshes:

http://img850.imageshack.us/img850/1518/snap031.th.jpg (http://img850.imageshack.us/i/snap031.jpg/)
http://img201.imageshack.us/img201/5987/snap030.th.jpg (http://img201.imageshack.us/i/snap030.jpg/)

[SkyBaron]

Link on first page is not working. Any other place where I can download this editor?

[TheDarkWraith]

Link on first page is not working. Any other place where I can download this editor?

Currently I have the link disabled while some severe errors/bugs are being worked out :up:

[gap]

Currently I have the link disabled while some severe errors/bugs are being worked out :up:

Probably you are already aware of it, but using v1.1.374.1 of the editor bone-cloning doesn't work. With v1.1.320.1 this is still possible, but the cloned bone gets its trasform properties reset (which didn't happen with some of the previous versions). I can provide details if you need for them.

[SkyBaron]

Currently I have the link disabled while some severe errors/bugs are being worked out :up:

oh ok, no problem! I was trying to add new nodes (like the ones to carry bombs, radars, etc) to an airplane's body. Is this possible with Goblin Editor?

[gap]

oh ok, no problem! I was trying to add new nodes (like the ones to carry bombs, radars, etc) to an airplane's body. Is this possible with Goblin Editor?

unfortunately no

[SkyBaron]

unfortunately no

Is there any other way to add a new node to a .GR2 model? :06:

[TheDarkWraith]

Is there any other way to add a new node to a .GR2 model? :06:

No there is not. My app is the only one in existence that can manipulate GR2 files short of RAD Game Tools DLLs.

Unfortunately I am but only one person. Currently I'm developing patches for the game and thus haven't had time to work on the GR2 Editor/Viewer :dead:

[Targor Avelany]

There is (I believe TDW can do it through HEX editor). You will be able to do it with the GR2 Editor (it does not work at this time, you can see my reports in this thread). But I have no clue how to do that...

No there is not. My app is the only one in existence that can manipulate GR2 files short of RAD Game Tools DLLs.

Unfortunately I am but only one person. Currently I'm developing patches for the game and thus haven't had time to work on the GR2 Editor/Viewer :dead:

CLONE YOURSELF! hehehe

Well, that is why I'm sitting quietly and just reporting issues, patiently waiting. Unfortunately at this time my level of knowledge is not allowing me to do anything to assist. :(

[gap]

Is there any other way to add a new node to a .GR2 model? :06:

There is (I believe TDW can do it through HEX editor). You will be able to do it with the GR2 Editor (it does not work at this time, you can see my reports in this thread). But I have no clue how to do that...

...

CLONE YOURSELF! hehehe

Well, that is why I'm sitting quietly and just reporting issues, patiently waiting. Unfortunately at this time my level of knowledge is not allowing me to do anything to assist. :(

You can use some older version of TDW's Editor. As long as the GR2 you are editing doesn't contain animation or other extended data, it shouldn't get corrupted (in any case, make frequent back-up's).

I am currently cloning bones with v1.1.272.1 of the editor, but even more recent versions should still have this ability. :hmm2:

[TheDarkWraith]

CLONE YOURSELF! hehehe

The world would be a very scary place with two of me around, especially if the other one was my arch nemesis :dead:

[Targor Avelany]

You can use some older version of TDW's Editor. As long as the GR2 you are editing doesn't contain animation or other extended data, it shouldn't get corrupted (in any case, make frequent back-up's).

I am currently cloning bones with v1.1.272.1 of the editor, but even more recent versions should still have this ability. :hmm2:
Not for everything I need :)
And yeah, that is what I have been doing :)

The world would be a very scary place with two of me around, especially if the other one was my arch nemesis :dead:

LOL. Yeah, the world would be a scary place, but only if you would have worked together. You would have just been busy cancelling each other out if one was the arch nemesis.

[gap]

Not for everything I need :)
And yeah, that is what I have been doing :)

As long as adding new bones/survivors to your wooden lifeboats is concerned, an old version of the Editor should make the trick. :hmm2:

[V13dweller]

Is there a working download link?
I have been looking for quite a while.
On the old versions, I still get the mixed values error when trying to view aircraft.

[Ekmek]

DarkWraith,

Any chance you could post your latest source code? I might know some people that can contribute to the gr2 decoding of the civ 5 gr2s.

Thanks


EDIT:

Also NexusBuddy which used the civ5 gr2.dll to make granny files (but nothing like what you are doing and I need) was decompiled. It might have code that could help

http://forums.civfanatics.com/showpost.php?p=12426632&postcount=26

[V13dweller]

Still looking for valid download links.
Anyone?

[volodya61]

Still looking for valid download links.
Anyone?

See here - http://www.subsim.com/radioroom/showpost.php?p=2049276&postcount=1977

[V13dweller]

http://i1281.photobucket.com/albums/a507/V13dweller/Capture_zpsaa9650e8.png (http://s1281.photobucket.com/user/V13dweller/media/Capture_zpsaa9650e8.png.html)

I have this to submit.

[V13dweller]

This error occurs when I open the AI_Sensors.Gr2.

[Targor Avelany]

As long as adding new bones/survivors to your wooden lifeboats is concerned, an old version of the Editor should make the trick. :hmm2:

Actually wanted to post in this regard for a while, but rl have been crazy busy:
the rotation of the bones is a bit confusing: whenever I try to change the angle of the bone on any of the parameters, it squishes or blows to ridiculous proportions the model that is on that bone.

[gap]

Actually wanted to post in this regard for a while, but rl have been crazy busy:
the rotation of the bones is a bit confusing: whenever I try to change the angle of the bone on any of the parameters, it squishes or blows to ridiculous proportions the model that is on that bone.

It shouldn't. I have moved bone around many times, and never had any distorted meshes issue. Can you please describe in detail what you did? If I can replicate your problem maybe I can help you :hmmm:

[Jace11]

Bone rotation? It's based on Quarternion rotation. I thought there was a converter in the app, but you can squash or expand them if you get it wrong I think.

[TheDarkWraith]

Bone rotation? It's based on Quarternion rotation. I thought there was a converter in the app, but you can squash or expand them if you get it wrong I think.

Yes it is based on Quaternions. Yes there is a converter in the app. The only way you can 'squash' them is if you have scale capability turned on (lower right corner of the app - S). If only RT (Rotations and Translations) are turned on then it's impossible to 'squash' them.

[Crazyauzzie]

Any idea on when the new version of the program is going to be put up? I've been sticking my head out and waiting for it.

[Targor Avelany]

Yes it is based on Quaternions. Yes there is a converter in the app. The only way you can 'squash' them is if you have scale capability turned on (lower right corner of the app - S). If only RT (Rotations and Translations) are turned on then it's impossible to 'squash' them.

hmm. Awesome, now I know where I was messing up a bit.

[divingbluefrog]

I don't know if it has any value, as I'm not really GR2 format friendly, but I put my hand on a complete GR2_import tool written in C++ (.h, .cpp. makefile and so on).

From the readme included : "Granny2Lib encapsulates tazpn (theo)'s Granny2-reading logic in a single library, isolated from the rest of the projects."

The first lines of GR2format.cpp :
/************************************************** ********************
*<
FILE: GR2Format.h
DESCRIPTION: GR2 File Format
CREATED BY: tazpn (Theo)
HISTORY:
*> Copyright (c) 2006, All Rights Reserved.
************************************************** ********************/
#include "Precomp.h"
#include "GR2Format.h"
//#include "bspline/BSpline.h"

using namespace std;

namespace granny2 {

IMPLVARTYPE(granny2_impl, granny_transform)
IMPLVARTYPE(granny2_impl, ArtToolInfo)
IMPLVARTYPE(granny2_impl, ExporterInfo)
IMPLVARTYPE(granny2_impl, MIPLevels)
IMPLVARTYPE(granny2_impl, Image)
IMPLVARTYPE(granny2_impl, Layout)
IMPLVARTYPE(granny2_impl, Texture)
IMPLVARTYPE(granny2_impl, granny_Map)
IMPLVARTYPE(granny2_impl, granny_Material)
IMPLVARTYPE(granny2_impl, Bone)
IMPLVARTYPE(granny2_impl, Skeleton)
IMPLVARTYPE(granny2_impl, VertexData)
IMPLVARTYPE(granny2_impl, TriTopology)
IMPLVARTYPE(granny2_impl, Mesh)
IMPLVARTYPE(granny2_impl, Model)
IMPLVARTYPE(granny2_impl, TransformTrack)
IMPLVARTYPE(granny2_impl, PropRef)
IMPLVARTYPE(granny2_impl, TrackGroup)
IMPLVARTYPE(granny2_impl, Animation)
IMPLVARTYPE(granny2_impl, GR2Info)
IMPLVARTYPE(granny2_impl, CurveDataHeader_D3K16uC16u)
IMPLVARTYPE(granny2_impl, CurveDataHeader_D3K8uC8u)
IMPLVARTYPE(granny2_impl, CurveDataHeader_D4nK16uC15u)
IMPLVARTYPE(granny2_impl, CurveDataHeader_DaIdentity)
IMPLVARTYPE(granny2_impl, CurveDataHeader_D4nK8uC7u)
IMPLVARTYPE(granny2_impl, CurveDataHeader_D3Constant32f)
IMPLVARTYPE(granny2_impl, CurveDataHeader_DaK32fC32f)
IMPLVARTYPE(granny2_impl, CurveDataHeader_DaKeyframes32f)
//IMPLVARTYPE(granny2_impl, CurveDataHeader_DaConstant32f)
//IMPLVARTYPE(granny2_impl, CurveDataHeader_D4Constant32f)
//IMPLVARTYPE(granny2_impl, CurveDataHeader_DaK16uC16u)
//IMPLVARTYPE(granny2_impl, CurveDataHeader_DaK8uC8u)

and around 900 lines of code more.

If you think it could be useful, I can zip the project and send it to you.