GR2 Editor/Viewer/Extractor/Importer

[Sammi79]

Thank you kindly sir, to me each 2 digit hex number is easily recognisable as a number 0-255, In that example I would guess is machine code, though I guess in the .GR2 file which is essentially a data store? the codes are not equivalent to actual CPU opcodes, but to calls from software (game/granny viewer etc.)

warm regards and thanks again for your reply I will go back to my transparent sprite routine for my CPC6128 and stop clogging this game changing thread now!

Correct.
The GR2 format is nothing more then a data file.
Just as dat files do nothing more then provide the information that the Game Engine uses to do what it does.
More complex at first glance, but once you understand them?
You can control them.
Exe's and Dll's are a different story.
Those have your op codes and such.

[Sammi79]

In that case, just looking at the size of the .GR2 files... WOW. that is a massive reverse engineering task you have taken on. I have been learning assembly in a similar fashion, but on a Z80 the task is not so massive. It can only address 64Kb of memory!

don't worry I will not be going near any .exe or .dll files I don't fully understand but am aware of the illegality of such things. (also I suspect the assembly instruction set is significantly different on these modern CPUs) Maybe when I'm totally comfortable with the Z80 I will move on to something more contempory.

Anyway, amazing work folks. Thank you for keeping my dream of an uber U-boat simulation alive.

Regards, Sam.

Most of the GR2 files contain the 3D models.
That's where the size grows as they are not compressed in SH5 files.
Each vert is a 32 bit float.
As some models have massive amounts of verts and faces?
You get a large file size.
Had they compressed the files?
They would be much smaller.
Working on other GR2 files for other Games?
I figured out the compression used also.


Quit a piece of work for the most part those GR2 files.

[tonschk]

Originally Posted by Sammi79

Thank you for keeping my dream of an uber U-boat simulation alive.

Regards, Sam.

[Ekmek]

Originally Posted by TheDarkWraith

I've already downloaded them. I won't get to them until after I finish the current version of the app I'm working on (cloning and changing of materials/textures and possibly the ability to add new bones)

good thing you got it before Megaupload went down!

I also found this (maybe you did to) but it converts gr2 to obj files (and it has the source) but when I do it the model I use loses the rest of the meshes and the rigging (it just has the eye balls)

[TheDarkWraith]

Lost a whole week to that real life work thing Saw some interesting things this time in Portland. Was out on the flight line at North Boeing Field in Seattle, WA and got to speak with Boeing engineers about the new 787 Dreamliner and the new 747-800 airplanes. That 747-800 is a monster! Saw them both power up and do touch-and-goes. Really cool.
Got sent to a private entity north of Boeing that had a Gulfstream jet and a Citation jet. Talked to them about the jets and their ground power unit. Got to sit left seat in both (non-flying)...awesome.
Popped back down to North Boeing Field and found my military liason and toured the projects the Air Force has going on there. Amazing is all I can say about it
Hoping that I'll get some time this upcoming week to work on this app more

[quink99]

TDW,

As an old, retired 747-400 "driver" you can't imagine how I envy your day with the Boeing group. Next time take me along!

"If it ain't Boeing I ain't goin' "

[TheDarkWraith]

Originally Posted by quink99

TDW,

As an old, retired 747-400 "driver" you can't imagine how I envy your day with the Boeing group. Next time take me along!

"If it ain't Boeing I ain't goin' "

Boeing is nice. As a pilot I love anything that deals with aviation. When they (work) asked me if I'd like to take on the project up in Seattle at North Boeing Field I couldn't say yes fast enough

The Boeing engineers showed me some fascinating pictures of the 787 Dreamliner in testing. One was the wing flex test. The picture showed the airplane hanging by it's wings - the wings were bent perfectly 90 degrees up on each side!! Not a single crack or failure. Impressive It's especially impressive since the airplane is made mostly from composite materials.

That 787 is a power hungry monster though. Most airports are going to have to double up their ground power units to feed this monster. I had to use two stingers (cables) to power up the thing from my ground power unit (180kva unit)

I didn't get a chance to visit the Boeing museum there at North Boeing Field. Judging from the aircraft they had outside of it (F-14 Tomcat, The Concorde, and many others) it's probably quite impressive. When I asked about the Concorde it was the last operating Concorde jet and the last landing it made was there at North Boeing Field. How cool is that! They had a ramp setup on it so that you could take a tour of the inside. I have to head back out there soon so I'll make sure I have time to tour the museum

Still the most impressive place I've been for work when it comes to aviation is Lockheed Martin in Colorado Springs, CO. What you see above ground is nothing compared to what's underground

You'd probably like to see E-3 and E-4 at Offutt AFB in Nebraska. In case you don't know E-3 and E-4 are the vice president's airplanes (both HUGE 747s). I have the ground power units that power these aircraft when they are in alert status. I have made the Wing Commander pull one of these aircraft from the hanger and place it on the flight line because they said my ground power unit was causing problems with the aircraft. The only way I could see what was going on was to 'play' with the aircraft with the ground power unit powering it. The word 'play' came from the Wing Commander. He was not happy that a civilian was telling him what to do. I LOVED IT!!!!

[Stormfly]

...iam shure they blindfolded and earplugged you before you was allowed to "play" with all those secret big and little gizmos, creating and indexing all possible power load character`s for that state

[TheDarkWraith]

The last two days I've been able to work on the app. Have the linked list working correctly for non-special (pointers come after data) GR2 files. Still have to work on the special GR2 files linked list.

Here you can see Sentinel in action. I asked for the breakdown of the linked list for section 0 using pointers:



As you can see the chain is complete This is a good thing

Now adding/removing/inserting/deleting/editing items from the chain is a piece of cake

[pedrobas]

[TheDarkWraith]

the linked list is working correctly for the special GR2 files now also

Now the daunting task of writing the code to write the file from what the app knows about the file begins. I have a writer already but it only modifies what the app has in memory (the app keeps the whole file in memory). Thus it's really simple to change a byte here or there, change the position of something, etc. This new writer will write a new GR2 file from start to finish by asking each class to write 'what it knows'. The new writer wrote the fileheader, infoheader, fileinfoheader, arttoolinfo, exporterinfo, textures, materials, skeletons, and bones sections (and all their extendeddata) of the GR2 file without problems So far so good. There is one small problem that I have to figure out: the bones inverse world transform didn't write correctly (things that were supposed to be negative in value weren't) so have to figure this out before moving on.

I took the new GR2 file the writer wrote and compared it to the stock GR2 file. Everything was identical (barring CRC value and the bone's inverse world transform) so that means it's working like it should. The real test will be when it can write the complete file and I insert data in the file at arbitrary places whether it writes the file correctly or not

[rocker_lx]

Exciting News.

[TheDarkWraith]

More good news:

new writer wrote primary vertex data (along with everything associated with it - vertex component names and verticies) without problems to a new file All I have left is PrimaryTopology, Meshes, and Models (and everything associated with them).

Here's the real kicker: when I first coded the app the classes were using hard-coded offsets for their data (they got the offset from a pointer). I then changed to a pointer style where a pointer was stored with each class that told them where their data was and where it was to be written. As you know I then changed to a linked-list for all the classes. As items are being written to the new file by the new writer it asks each class to write it's data to the file. Since the class is part of the linked list it refers to it's previous object and asks it for it's offset and size. The class takes the offset and adds the size to it to determine where it needs to write it's data in the file. This happens for every class (fileheader, infoheader, exporterinfo, sections, textures, materials, skeletons, bones, extendeddata for a class, etc.). Since everything is relative to everything this makes for adding, removing, changing an item's size, etc. a snap I couldn't be happier with the results of this linked-list change. For testing I made no changes to anything and asked Sentinel to write a new file based on the classes data. The new file written is an EXACT copy of the original

It gets even better! I was adding some error checking to each class's WriteData function when I came across something I totally forgot about. The data right before the ArtToolInfo section in the GR2 file tells you how many textures, materials, models, skeletons, trackgroups, animations, etc. the file has. The next 4 bytes after the number of each item is a pointer. This pointer is the root pointer for that type. The root type pointer points to a list of pointers for that type. I totally forgot about these root pointers! Why are they significant? Let me explain. The app originally reads data from the file quazi-demand style. This means it only reads data when it needs it. For instance: I would read the model pointer and the model class would read in everything needed to make the model: skeleton, bones, materials, etc. There was no way to use parallelism with this as everything was done in sequential order (read model data, read skeleton data, read in all the skeleton's bones, read in all the materials, etc.) With these root pointers I can spawn worker threads for each type. Then I can have each type worker thread spawn more worker threads if the type is more than 1 (number of materials > 1 or number of bones > 1 or number of meshes > 1 etc. etc.) This allows for parallelism which will drastically decrease loading times Granny Viewer may kick my you-know-what in loading times but I'm not going to be too far behind

I hope to have a new test version available here real soon so you all can load GR2 files and ask sentinel to write a new file. I'll also have you ask Sentinal to getchainforsection x to see if the linked-list is complete or broken for each section. If a GR2 file's section has a broken chain I need to know so I can figure out why. Then you can load the new file in Granny Viewer to see if it's broke or not. Then you can further compare the original to the copy to see if the new writer has any problems with that GR2 file. If the new writer passes with flying colors then I'm in the home stretch. I can then write the remaining code to add new bones, materials, textures, meshes, etc. I can then also write the remaining code to modify (increase/decrease size) of items in the file (i.e. change geometry of meshes in GR2 file for instance)