Extract GR2 to Blender with mesh AND skeleton and re-export to GR2

S3rgeus · May 11, 2013

snafusmith said:
You don't need to modify any skeleton at all to change effects. It should be easy to change the nuclear bomber to a regular bomber or regular catapult to a flaming one by changing the effects in the fxsxml file and corresponding FX_triggers file. The gr2 files only change the models and animations. The sounds and FX's used are all linked in simple text. Super easy to change. That's how I was able to make a tank sound and shoot like the mech infantry with my recent Russian BMP-2.

I'm not sure but it should also be possible to give mele units a ranged attack. All units have some kind of ranged attack for attacking cities - you could make the swordsman throw a flaming object as their main attack by simply changing which event codes go to which gr2 animation file in the fxsxml file for that unit. I haven't tried this but I know when making my one units I'm able to mix and match animations no problem.

Deliverator said:
As has been said having units generate effects is separate from the 3D modelling side. If you actually want a unit to actively throw a fireball then we would need either need to use a vanilla animation where the unit has a throwing attack. The only throw animation I know of in Civ 5 is the Atlatist. In Civ 4 this Fire Mage uses the Grenadier animation, so another option might be to port those animations.

Ok, I think I need to look more into connecting the animations in the fxsxml, I didn't think the animation would be cross-compatible with skeletons they weren't designed for. (I'm correct in thinking the gr2's that have 'action descriptions' in their names are animation files, rather than meshes and texture references?) I did try using the art defines tables to associate the "FLAMING_BOULDER" combat weapon (used by the trebuchet) but it produced some unusual results. When I tried it with a settler model, there was no animation (except for the defenders, who crouched, shielding against bombardment). Nothing happened until combat timed out and the damage was dealt. When I tried it with a swordsman model, he threw the 'flaming arrow' effect that swordsmen usually used when he attacks cities.

Looks like you've got amazing progress going with the units and possibly leaders too. I would love to help some time, but I've never used a 3D modelling program before, so it'll take me some time to get off the ground with that. But I'm definitely willing to try! I've done a successful unit reskin, which was a nice start (though it doesn't require me to do any 3D model stuff, of course!).

Deliverator · May 11, 2013

S3rgeus said:
Ok, I think I need to look more into connecting the animations in the fxsxml, I didn't think the animation would be cross-compatible with skeletons they weren't designed for. (I'm correct in thinking the gr2's that have 'action descriptions' in their names are animation files, rather than meshes and texture references?) I did try using the art defines tables to associate the "FLAMING_BOULDER" combat weapon (used by the trebuchet) but it produced some unusual results. When I tried it with a settler model, there was no animation (except for the defenders, who crouched, shielding against bombardment). Nothing happened until combat timed out and the damage was dealt. When I tried it with a swordsman model, he threw the 'flaming arrow' effect that swordsmen usually used when he attacks cities.

Yeah, there is more to it. The model needs to have a bone location where the effect will originate from. In the case of the War Chariot I'm working on this is called fx_PROJECTILE:

S3rgeus said:
Looks like you've got amazing progress going with the units and possibly leaders too. I would love to help some time, but I've never used a 3D modelling program before, so it'll take me some time to get off the ground with that. But I'm definitely willing to try!

Cool. I will do an as-simple-as-possible introduction to 3D modelling, Blender and Civ4/Civ5 conversion at some point soon.

Deliverator · May 11, 2013

S3rgeus said:
If it's useful here, I've decompiled a more recent version of NexusBuddy.

Do you think it would be possible to compile a 64-bit version of Nexus Buddy that uses the GrannyExporterFBXx64.dll instead of GrannyExporterFBXWin32.dll. I'd be interested to see if the stability/behaviour was any different seeing as its the conversion from FBX -> GR2 that still causes a lot of headaches.

Ekmek · May 11, 2013

I think the stability issue is in both 32 and 64

Wolfdog · May 12, 2013

Originally Posted by S3rgeus View Post
Ok, I think I need to look more into connecting the animations in the fxsxml, I didn't think the animation would be cross-compatible with skeletons they weren't designed for. (I'm correct in thinking the gr2's that have 'action descriptions' in their names are animation files, rather than meshes and texture references?) I did try using the art defines tables to associate the "FLAMING_BOULDER" combat weapon (used by the trebuchet) but it produced some unusual results. When I tried it with a settler model, there was no animation (except for the defenders, who crouched, shielding against bombardment). Nothing happened until combat timed out and the damage was dealt. When I tried it with a swordsman model, he threw the 'flaming arrow' effect that swordsmen usually used when he attacks cities.

I am experiencing similar problems with animations. The Marder I made animates properly in Nexus Viewer and the Marder appears in the game and moves around normally and the turret moves separate from the hull as well. The problem comes when I attack or fortify there are no animations in the game like there is in the nexus viewer just a long period of nothing then moves into the next square. I have attached files if someone wants to have a look.

Deliverator · May 13, 2013

OK, another update. I've improved the Blender TXT import so that separate meshes in the Milkshape3D TXT are imported as separate meshes in Blender rather than lumping everything into one mesh (which is what happens in the current version).

I've also been working on helpful new functions for Nexus Buddy (now that we have the source thanks to S3rgeus

). I've added a Split function which exports each mesh in the currently loaded GR2 as a separate GR2. This is helpful because quite a few of the vanilla units have multiple Meshes with the same name. For example the War Chariot has 5 meshes but 3 have the same name, U_Egyptian_WarChariot.

The SMD process will group these based on name so that you lose the split. This Split function allowed me to produce the Blender file you see in the first image with exactly the same five mesh split as the vanilla unit, by doing the GR2>SMD>TXT>.blend process once for each part.

To get around the instability of the FBX Import to GR2 I also added an Append method which will append the first mesh from a selected FBX or (preferably) GR2 to the currently open GR2:

If you export your separate Blender meshes as separate FBX files, each including the skeleton you can use Append to build up your model again piece by piece in Nexus Buddy. My process was:
1. Export all meshes as separate FBXs so I had 5 FBX files for the War Chariot.
2. Open each FBX in turn and save the GR2. Repeat if the mesh looks broken in GrannyViewer.
3. Open the first ported GR2. Append the second GR2. Save as a new merged GR2. GrannyViewer check. Append the third GR2. Save. GrannyViewer check. And so on...

Following this process I'm able to get all my five meshes from Blender into a GR2 file without any corruption (the horns were deliberate to show I have actually modded the mesh!):

This GR2 also has the same five part mesh structure as the vanilla unit:

All good it might seem. But here we hit another wall.

The Granny GR2 file maintain two separate lists of meshes:
1) the Meshes list is what you see in the Mesh List tab shown in the above screenshots.
2) the Model's MeshBindings list (viewable in GrannyViewer if you right-click the Model in Model List and select View in Detail).

If you look at the vanilla War Chariot you can see that these two lists are in sync, but for my horned War Chariot, made using Nexus Buddy Append, the model MeshBindings list only has one Mesh whereas the Mesh List has five:

The MeshBindings drive what actually displays in Nexus 3D Viewer. The four Meshes that are not referenced in the Model will not display.

The good news is that the GR2s created before the append are each rigged properly and animate perfectly so if we could just update the damn MeshBindings list from code then I think we'd have a complete multi-mesh import process which can then be automated further.

To understand why the .NET/C# code fix for this isn't simple you need to look at the available methods in Firaxis.Framework.Granny.dll and the Firaxis.Framework.Granny.ImplWin32.dll implementation. Specifically the problem is with how locked-down the IGrannyModel interface is.

These are the available properties/methods for IGrannyFile, IGrannyModel and IGrannyMesh in Firaxis.Framework.Granny:

Notice that IGrannyMesh has both AddMaterialBinding and RemoveMaterialBinding methods. IGrannyModel has a RemoveMeshBinding method but does NOT have a AddMeshBinding method - because that would be far too helpful :crazyeye:

. So I can RemoveMeshBindings but I can't add new ones. :undecide:

In the Append function in my updated Nexus Buddy was able to add the GrannyMesh from another file to the currently open one using IGrannyFile.AddMeshReference like so:

Code:

Form1.loadedFile.AddMeshReference(tempFile.Meshes[0]);

If could write the next line:

Code:

Form1.loadedFile.Models[0].AddMeshBinding(tempFile.Meshes[0]);

...then I'm fairly sure everything would work, but I can't as no method of that name exists. This is the final barrier as far as I can see and a breakthrough here would be fantastic.

I've gone as far as decompiling the DLL source using dotPeek/Reflector to look at the GrannyModel implementation code under the hood. I've highlighted a section of the generated source that is adding mesh bindings:

Spoiler :

Code:

internal class GrannyModel : GrannyBaseObjectContext, IGrannyModel, IDisposable
{
    // Fields
    private IGrannyTransform m_kInitialPlacement;
    private List<IGrannyMesh> m_lstMeshBindings;
    private List<string> m_pkBoneNames;
    private unsafe granny_model* m_pkModel;
    private IGrannySkeleton m_pkSkeleton;

...

    internal unsafe void Attach(granny_model* pkModel)
    {
        GrannyMesh item = null;
        GrannyTransform transform = null;
        GrannySkeleton skeleton = null;
        this.m_pkModel = pkModel;
        skeleton = new GrannySkeleton(this);
        skeleton.Attach(*((granny_skeleton**) (this.m_pkModel + 4)));
        this.m_pkSkeleton = skeleton;
        transform = new GrannyTransform(this);
        transform.Attach((granny_transform*) (this.m_pkModel + 8));
        this.m_kInitialPlacement = transform;
        this.m_lstMeshBindings.Clear();
[COLOR="red"]        for (int i = 0; i < *(((int*) (this.m_pkModel + 0x4c))); i++)
        {
            item = new GrannyMesh(this);
            item.Attach(*((granny_mesh**) (*(((int*) (this.m_pkModel + 80))) + (i * 4))));
            this.m_lstMeshBindings.Add(item);
        }[/COLOR]
    }
...

    public virtual unsafe void RemoveMeshBinding(IGrannyMesh kMesh)
    {
        granny_mesh* mesh = ((GrannyMesh) kMesh).GetMesh();
        int index = 0;
    Label_0013:
        if (index < *(((int*) (this.m_pkModel + 0x4c))))
        {
            if (*(((int*) (this.m_pkModel + 80)))[index * 4] != mesh)
            {
                index++;
                goto Label_0013;
            }
            this.m_lstMeshBindings.RemoveAt(index);
            *(((int*) (this.m_pkModel + 0x4c)))--;
            if (*(((int*) (this.m_pkModel + 0x4c))) == 0)
            {
                *((int*) (this.m_pkModel + 80)) = 0;
            }
            else
            {
                granny_model_mesh_binding* _bindingPtr = *((granny_model_mesh_binding**) (this.m_pkModel + 80));
                *((int*) (this.m_pkModel + 80)) = GrannyMemoryArenaPush(base.m_pkMemoryArena, *(((int*) (this.m_pkModel + 0x4c))) * 4);
                memcpy(*((void**) (this.m_pkModel + 80)), (void modopt(IsConst)*) _bindingPtr, (uint) (index * 4));
                memcpy((void*) (*(((int*) (this.m_pkModel + 80))) + (index * 4)), (void modopt(IsConst)*) (_bindingPtr + ((index + 1) * 4)), (uint) ((*(((int*) (this.m_pkModel + 0x4c))) - index) * 4));
            }
        }
    }

Unfortunately I think this issue can't be resolved without updated Firaxis.Framework.Granny.dll and Firaxis.Framework.Granny.ImplWin32.dll libraries. I presume the code for these is Firaxis code rather than code from RAD Game Tools, owners of the Granny format.

So either:
1) Firaxis add a IGrannyModel.AddMeshBinding to Firaxis.Framework.Granny and Firaxis.Framework.Granny.ImplWin32.dll and release. Ideal solution, but probably unlikely - unless they feel like supporting 3D graphic modders!
2) Someone manages to decompile Firaxis.Framework.Granny.dll and Firaxis.Framework.Granny.ImplWin32.dll, fix code so that it recompiles, add the required AddMeshBinding function that can be called from Nexus Buddy, and releases to the community. Extremely hard as far as I can see and therefore unlikely.
3) We find some other work around. Possible.

Sorry this has been so technical. I've probably lost everyone a while back.

But it would be awesome to overcome this final hurdle so that we can actually create modding tools that allow multi-mesh objects (which a lot of Civ4 models are) to be flawlessly imported to Civ 5 without merging meshes. But for now I'm stuck...

I've attached my blend files and a couple of output GR2s here.

In other news, I've added Warrior.blend and Persian Immortal.blend to the spreadsheet. With my updated scripts the entire GR2->.blend->GR2 round-trip process can be done in 5 minutes. I'll do another batch of templates soon, now that I've got it so quick. I'll release a new version of the import/export scripts and update the tutorial soon as well.

S3rgeus · May 13, 2013

Deliverator said:
Do you think it would be possible to compile a 64-bit version of Nexus Buddy that uses the GrannyExporterFBXx64.dll instead of GrannyExporterFBXWin32.dll. I'd be interested to see if the stability/behaviour was any different seeing as its the conversion from FBX -> GR2 that still causes a lot of headaches.

I just tried switching the referenced dlls out (using Firaxis.Framework.Granny.Implx64 instead of Firaxis.Framework.Granny.ImplWin32) and after switching the target platform to x64 in Visual Studio, Nexus Buddy compiles again. Is this what you're looking for?

S3rgeus · May 13, 2013

Deliverator said:
So either:
1) Firaxis add a IGrannyModel.AddMeshBinding to Firaxis.Framework.Granny and Firaxis.Framework.Granny.ImplWin32.dll and release. Ideal solution, but probably unlikely - unless they feel like supporting 3D graphic modders!
2) Someone manages to decompile Firaxis.Framework.Granny.dll and Firaxis.Framework.Granny.ImplWin32.dll, fix code so that it recompiles, add the required AddMeshBinding function that can be called from Nexus Buddy, and releases to the community. Extremely hard as far as I can see and therefore unlikely.
3) We find some other work around. Possible.

With regards to #2, Firaxis.Framework.Granny.dll appears to have originally been written in C++ so doesn't decompile well. Firaxis.Framework.Granny.ImplWin32 has dependencies on some Telerik (makers of Granny, right?) dlls which don't appear to be packed with the game, so while that dll can be decompiled (it's reasonably simple C#) it can't be recompiled again. It's a real shame because all of the methods are there, they just aren't exposed.

Deliverator · May 13, 2013

S3rgeus said:
With regards to #2, Firaxis.Framework.Granny.dll appears to have originally been written in C++ so doesn't decompile well. Firaxis.Framework.Granny.ImplWin32 has dependencies on some Telerik (makers of Granny, right?) dlls which don't appear to be packed with the game, so while that dll can be decompiled (it's reasonably simple C#) it can't be recompiled again.

Telerik make the decompiler JustDecompile and other dev tools. RAD Game Tools are the owners of Granny. When I tried decompiling Granny.ImplWin32 the code wasn't 100% anyway. It would take a lot of fixing up even if we had the mystery DLLs.

I just tried switching the referenced dlls out (using Firaxis.Framework.Granny.Implx64 instead of Firaxis.Framework.Granny.ImplWin32) and after switching the target platform to x64 in Visual Studio, Nexus Buddy compiles again. Is this what you're looking for?

I tested it but unfortunately, GrannyExporterFBXx64.dll suffers from exactly the same problems as the other version.

Deliverator · May 13, 2013

Edit: Sadly this workaround didn't work in game.

The solution is to have the Append function add both the Model and the Mesh from the temp file like this:

Code:

                Form1.loadedFile.AddModelReference(tempFile.Models[0]);
                Form1.loadedFile.AddMeshReference(tempFile.Meshes[0]);

Despite the fact that each mesh is in its own separate model the five meshes all appear and are properly animated in 3D Viewer. Hurrah! I'll test in game next.

Deliverator · May 13, 2013

Unfortunately that model hack doesn't work in the game - it ignores everything but the first model which is not too surprising.

I switched to my modified GR2 with just the Archer mesh and you can see the animations work so if we could add the MeshBindings to a single model I still think everything would work nicely.

Ekmek has contacted Firaxis to see if they can help us with us with a IGrannyModel.AddMeshBinding DLL so we'll have to wait until then for the really complex stuff - until then anything with a single mesh works fine. Sometimes two meshes can work too as Bernie found with the Machine Gunner.

Ekmek · May 13, 2013

Any chance we can fix allocating Leader Material to a leadermodel? For some reaon when I copy over a leader material over from a firaxis leader to an nexusbuddy made gr2 (using MaterialHacker v2) then that mesh will show in game. But if I try to assign the texture files to the material using NexusBuddy it will not show in game. I noticed something with submaps being assigned by the MaterialHacker but not with NexusBuddy when I looked in granny viewer.

you can see my test here:

http://forums.civfanatics.com/showthread.php?t=488092

-------------

On another note my multi-skeleton test with the Pantheon Wonder went weird. It showed in Nexus but in game it made the city and wonder turn invisible (like you test). It could be related to the art defines change but then I saw your chariot test and it seems like the results were similar.

Deliverator · May 17, 2013

I've discovered something that might well be causing the pinching issue we've seen when joining meshes into one. Blender seems to be doing something weird to vertex groups when you join meshes.

I took each separate mesh in the War Chariot, deleted all current vertex groups and assign all of each mesh to a single vertex group - one called Driver for the Driver, Archer for the Archer, etc. When I merge the meshes I would expect the assignments I made to be intact but strangely parts of the other meshes that I did not manually assign have ended up assigned by the Blender Join. Here you see that parts of the Driver and Archer have ended up in my horse group:

The good news is that this is in the Blender domain so I might be able to fix it. If I can write a script that merges meshes into one while properly preserving vertex group data, then that could help a lot.

Ekmek · May 17, 2013

I think you can get around it by having the same vertex group created (but not assigned) for each mesh i.e. the horse mesh should hav an archer vertex but not assigned to any horse parts. I think this is why we never saw pinching in civ4lhs because they usually had al the vertices assigned to each mesh

Wolfdog · May 18, 2013

You guys are doing a great job at nutting this out. :goodjob:

I was wondering if you are able to modify the fbx export script to remove the extra bone that gets created after converting to gr2. I am not sure if it makes any difference but I always seem to get am extra bone named after the mesh object exactly where the point_WORLD bone is. It may be the nexus buddy conversion process causing this also or it may not matter that its there.

I switched to my modified GR2 with just the Archer mesh and you can see the animations work so if we could add the MeshBindings to a single model I still think everything would work nicely.

I noticed you got animations working was there any special trick you did to get animations to work?

Ekmek · May 18, 2013

on naother note. my DOS skills are rusty but why am I getting a <null> response when I run my bat

Code:

:: Make me an SMD file by Ekmek
@echo off
grnreader98 *.gr2 -a -t
pause

it *should* be reading any gr2 file that I put in the same directory but its not. it just gives me a null.

Its a pain to have to add the file name in there every time.

Deliverator · May 18, 2013

Wolfdog said:
I noticed you got animations working was there any special trick you did to get animations to work?

The animations work for me, at least in Nexus 3D Viewer - try EventCode 1700:

There's an issue in that the Marder turret is much smaller and it hasn't been centred over the turret bone so it spins around in an unconnected way.

I was wondering if you are able to modify the fbx export script to remove the extra bone that gets created after converting to gr2. I am not sure if it makes any difference but I always seem to get am extra bone named after the mesh object exactly where the point_WORLD bone is. It may be the nexus buddy conversion process causing this also or it may not matter that its there.

I managed to get a two-mesh calvary unit, the Conquistador, from Blender back into the game:

Still up against two limiting factors with the more complex units like Chariots and Elephants:

1) Exporting a multi-mesh FBX to GR2 often corrupts the meshes for 2 mesh models and almost always corrupts the meshes for 3 meshes models. 2 mesh sometimes works OK which is how I was able to get the Conquistador through.

The function GrannyExporterFBX.ExportFBXFile called by Nexus Buddy is incredibly unstable - it seems to have some low level memory type problem. A program that produces different output for the same input is not much fun to work with! See how the bytes vary while repeating the same thing here:

Spoiler :

2) If you join all meshes into one to get around the FBX->GR2 corruption issue then in some cases the mesh bone deformations seem to screw up somehow so that parts of the unit are 'pinched' into the Scene root location - like this. Haven't been able to figure this one out despite a lot of investigation.

SO, we'll need to either crack the pinching issue or get a AddMeshBinding DLL to be able to mod the most complex units, but there's still a lot of units we can now mod/use animations for.

Ekmek · May 18, 2013

Anyone else getting a crash when you try to convert the marine.gr2?

Wolfdog · May 18, 2013

Thanks Deliverator I will try those new scripts and try and get the Marder to fit better.

on naother note. my DOS skills are rusty but why am I getting a <null> response when I run my bat

I get the same result with * as well, but works fine when I put the name in. Which means we cant do a batch of every gr2 in a folder

Anyone else getting a crash when you try to convert the marine.gr2?

I know this is a stupid question as your skills are a lot greater than mine but you did run it through material hacker first? I will try latter when I get the chance and see if it crashes for me.

Gedemon · May 18, 2013

Ekmek said:
on naother note. my DOS skills are rusty but why am I getting a <null> response when I run my bat

Code:

:: Make me an SMD file by Ekmek @echo off grnreader98 *.gr2 -a -t pause

it *should* be reading any gr2 file that I put in the same directory but its not. it just gives me a null.

Its a pain to have to add the file name in there every time.

try

Code:

for %%i in (*.gr2) do grnreader98 %%i -a -t

Extract GR2 to Blender with mesh AND skeleton and re-export to GR2

Emperor

Graphical Hackificator

Attachments

Graphical Hackificator

on steam: ekmek_e

Unit Butcher

Attachments

Graphical Hackificator

Attachments

Emperor

Emperor

Graphical Hackificator

Graphical Hackificator

Attachments

Graphical Hackificator

Attachments

on steam: ekmek_e

Graphical Hackificator

Attachments

on steam: ekmek_e

Unit Butcher

on steam: ekmek_e

Graphical Hackificator

Attachments

on steam: ekmek_e

Unit Butcher

Modder

Similar threads