Grimrock

ok just to be clear, where does the error occur in the pipeline ?

I load a .model with the GMT
I export it to obj
I edit it in blender
I import it as a obj with GMT
I save it as .model <<<< was this the broken step ????

so in order to fix my assets I just need to load the edited obj again with the new version of GMT and save them as .model ?

Skuggasveinn.

@Skuggasveinn: Yup, that's correct. At the moment, there is a bug in step 2 (export to obj) with complex meshes (but not simple ones), but that will be fixed this evening (and was introduced today). To fix the big problem, you just need to import the OBJ and re-save the .model file again. The .model file will have the correct segment triangle count.

Updated version *should* now export meshes with multiple mesh segments and re-import them ok. New models are fixed and should render fine in the game also. Apologies for using you guys like alpha testers - as I just pop development in as and when I can, it means some updates might not be great. I tend to leave a number of previous versions online, unless I know I've fixed something significant (as with this update).

GMT Home Page Direct Download

@Wolfrug: Have you checked that the material name assigned in the GMT is correct for the material you have made in the game? If you open your coin pouch model and click "Tools -> Material Find / Replace" then that will list the names of the materials you have on the model. For models exported from blender, this will often be something completely different, say '_coin_pouch_dif.dds' and it should read 'coin_pouch' to match the material you made in lua.

@Leki: Sorry, I forgot to mention - there are 2 fewer vertex streams in the exported and imported models as those are the 'tangents' and 'bi-tangents' which are required for normal textures. Unfortunately, the OBJ file format does not support those properties, so I will have to create them again (I'll add a button to do so).

Hey, I'm glad you do. You've done a great job with this importer/exporter and thanks to you I hope I manage to churn out a little idea I've had in the back of my head since I first got my hands on the editor

Actually the naming convention that appears to come from the obj export of Blender is quite nice. If you name your materials nicely ( material name = descriptive name of the mesh) then someone else that does the texture assignment will have an easier time to know which texture goes to which segment/mesh.

It is nice workaround since the GMT (or Blender) does not take over the mesh names when the file is imported from obj (or exported to obj from Blender).

By the way, thanks John for the export settings in Blender. It worked like a charm.

I've not had any problems with the import/export. I have imported and exported multiple mesh objects ~not animated objects, but meshes that have distinctly separate parts.

** Ah... I did not see that this is a problem with the update; I need to try it first, and see if I still can do as I have before.

Isaac wrote:Did you notice that the Ogre is mirrored on the X?

Most of the monsters have mirrored uvs. It's a great way to save texture space.

juho wrote:

Isaac wrote:Did you notice that the Ogre is mirrored on the X?

Most of the monsters have mirrored uvs. It's a great way to save texture space.

But it was mirrored mesh data... The Ogre had his hammer in his left hand.

Bug: The 0.2.1.1 editor reliably crashes if you launch the LoG Dungeon editor.
(This happens after you select 'Dungeon Editor', but before the editor displays it's splash screen.)

** This could perhaps be some sort of file access conflict? The new editor [when set up, has the path for the current dungeon.]

@Juho: There was unfortunately an issue with the older GMT in that it also rendered the model in the wrong co-ordinate space. It's fine now though .

@Isaac: Ahh, that's only when you run Grimrock full screen, so I hadn't noticed that before (I run it windowed when in modding mode). Workaround for now is to run Grimrock in a window. I'll try to fix this for the next release, I expect it's that the app loses it's DirectX Device when Grimrock goes full screen.

What makes slimes green?

The reason I am asking here, is that that part is lost for some reason whenever I change the slime model's material using the Toolkit. It always turns into an ugly whitish texture, like the actual default texture is. I have no clue how the greenness is achieved in the end. I can get reasonable results by retexturing the whitish default texture to something I need, though, so the issue is not critical. It is also possible I've just messed up elsewhere and failed at isolating the problem.