[DONE] Grimrock Model Tookit

[Phitt]

-scratching head-
Wow... that's a lot of hoop jumping haha. I do export as ase since the new import tool was put into GMT (3ds max here as well). It seems to me where the problem is, is all these extra rotations I am seeing you doing. When I import into GMT, the model of course looks right, but as soon as I see it with an animation preview it just disappears. Anyways, Ill give your notes a try sometime this weekend. Thanks for the input!

Usually you only need to rotate the model by -90° before export (since the game has a different coordinate system than max - x is x (doh...), y is z and z is y), then rotate the root node by 90° in the toolkit, then rotate the root animation node by -90° in the toolkit, all along the x axis. For gates for example, really simply once you've done it for the first time. The pressure plate behaves a bit weirdly, but in the end it's the same export process, only slightly different in the toolkit. For secret buttons it's again a bit different, the pivot of the button node needs to match the pivot of an existing animation.

[Skuggasveinn]

What happened to the ability to go to scene and choose "load background model" ?
In some cases it was a really nice to have feature.
Will it be making a comeback ?

Skuggasveinn.

[Wolfen]

What happened to the ability to go to scene and choose "load background model" ?
In some cases it was a really nice to have feature.
Will it be making a comeback ?

Skuggasveinn.

Its on the tabs on the right now isn't it? Next to animation.

[JohnWordsworth]

@phitt: Great to hear @petri's suggestion worked.

@wolfen (and everyone): I'm going to try to think of a better way to handle model imports so that you can tick a few boxes (and leave them ticked) to import models from a given source. Infact, we could even add a drop-down 'which software are you importing from' and then it could auto-rotate the imported model so that it's suitable 90% of the time. You'll still be able to fix any that import incorrectly using the tabs on the right, but it would be nice if it had a better stab at correcting different axis configurations.

@Skuggasveinn: Yup, you can just go to the 'Scene' tab on the right hand side to do that now. You can also move items around (manually, by typing values in the boxes), or load a whole 3x3 room in as background models (without a ceiling) if you have the asset pack linked in correctly.

[Wolfen]

@wolfen (and everyone): I'm going to try to think of a better way to handle model imports so that you can tick a few boxes (and leave them ticked) to import models from a given source. Infact, we could even add a drop-down 'which software are you importing from' and then it could auto-rotate the imported model so that it's suitable 90% of the time. You'll still be able to fix any that import incorrectly using the tabs on the right, but it would be nice if it had a better stab at correcting different axis configurations.

That would incredibly help my sanity. There are a lot of games / programs where I call the "programmer axis" exists. Where it is flipped just like this. Now, I don't know which is "right", but it's funny to me how the axis isn't actually used in a standard way across the board still.

Anyhow, yes, this would be awesome if you could do it.

Having node editing has been nice. Got rid of a lot of node errors haha.

[Skuggasveinn]

wow !!! I don't know how I didn't see that scene tab on the right
This is far greater then before, nice work

[JohnWordsworth]

Just a quick update really to keep everyone in the loop. No new build yet, but working hard regardless!

1. Documentation is almost finished. Next build will come with a .chm file to explain the main features of the app. I might have gone a bit OTT (not sure anyone will ever read all of it), but it should help new people who come to the app.

2. I've got a basic Grim2Fbx converter working in C++ using the FBX SDK. I expect I will start by releasing a command line tool to convert from Grimrock models / animations to FBX and vice-versa. The goal is to then build this as a DLL that I can use from the C# app to do the conversion in memory live through import / export buttons. Wish I had just started in C++ now, even though C++ MFC does my head in!

[Starnick]

+1 for using AssimpNet . Be sure to post any feedback you have on using the library, I'd be interested in hearing any thoughts/criticisms after using it in an app like this.

Regarding FBX, it may be possible to utilize the XNA Content Pipeline for this as they have a nice FBX importer. Potentially the biggest problem would be the dependency to have the XNA GameStudio installed on the user's machine, so that alone may kill that dream. It's a real pity Assimp doesn't have support yet. Although, a general purpose FBX SDK .NET wrapper sounds like a fun task

[pferguso]

I had a cool idea where I wanted to export one of the Grimrock Monsters into an obj, and then re-work his UV maps altogether(like create new ones), and then re-import him using the GMT. I didn't know it, but once you export a monster OBJ, if you import that OBJ back in GMT, all of the nodes are gone! I was so discouraged. Is there a way to import mesh data from an OBJ while I am looking at a.model file? then allow me to delete the original mesh, leaving my mesh (and the precious animation nodes) intact?

I tried re-inserting nodes according to the data on the original model, but there was no way to change the order of my newly inserted nodes, so the mesh node remained the second node, no matter what, whereas on the original mode, it was the 40th. I'm not sure if it would have worked if I had re-entered all of that node data or not.

[pferguso]

A feature I'd like to see is the saving and loading of Bone Nodes and other node data. This way, I can export a .model into an OBJ, and when I bring it back in, I can load the node data back onto it, so that the animations will still work.

Even if you save them to your own format, that would work. The problem I'm currently seeing is that Node data is lost with an OBJ export.