Grimrock

Just wanted to post a quick update. Have been away from my PC more than expected for the last few days - both from general man-flu illness and somethings popping up unexpected! Some responses and an update, before I hope to get some hours of development tomorrow night (unless Halo 4 lands in my Xbox, then it might be one more day...).

1. I've written the grim3d classes in C++ now so that I can write a DLL (and command line app) for converting .model to/from .fbx using the C++ only fbx library. This DLL will then be integrated in the C# app, or you can feel free just to use the command line tool as part of a fixed tool chain / from a bat file say!

@Isaac / @Hannamarin: I must put some of these things into some docs. Hope Isaac's suggestion is what you were looking for HannaMarin!

@Komag: I don't think it's possible to turn nodes on/off during the game with any methods we have at our disposal. Other than just switching models out with variants. As you say, you could animate parts of the model away (the slime actually has blobs hidden inside the main mesh, until it uses them as part of the attack anim). However, I don't think we can switch out anims either - so you could have a part disappear during an attack anim, but not for an extended period of time. Sorry I couldn't help - I think this is in the hands of the devs!

@Wolfen: Erm, a 'node' in a model is kind of a part of the model tree. In reality, the nodes that make up a model are generally either a way of representing where a bone is or where a mesh should be drawn (in relation to the (0,0,0) point in the mesh model space) for a static mesh. During animation, each bone maps to a node, so some of the nodes then become the animated bones and the hierarchy of the nodes (each has a parent) then creates the tree structure that makes up the skeleton. Hope that makes some sense!

Hey, I noticed something strange.
The default load path is the current dungeon, models folder
and the default save path is the assets, model folder

No real sense in saving asset pack.

I'm using version 0.4.0.1
Maybe it's not like that in the new one.

Komag wrote:Any idea how we might control node visibility in-game?

Nodes can be hidden by setting their scale to zero. The only way to change the scale is with animations.

Hmm, that's a clue, thanks

JohnWordsworth wrote: @Wolfen: Erm, a 'node' in a model is kind of a part of the model tree. In reality, the nodes that make up a model are generally either a way of representing where a bone is or where a mesh should be drawn (in relation to the (0,0,0) point in the mesh model space) for a static mesh. During animation, each bone maps to a node, so some of the nodes then become the animated bones and the hierarchy of the nodes (each has a parent) then creates the tree structure that makes up the skeleton. Hope that makes some sense!

Yeah, I went read up on some of it in the modding section of the site. It makes sense to some extent. I guess I am just missing some kind of detail on how to use them exactly. Like I am really confused on how I would create a empty node. I was experimenting and couldn't find anything. I am assuming at this point the toolkit you develop so far doesn't support making empty nodes? I really wish some one would write up a tutorial on this. It's driving me bananas haha.

JohnWordsworth wrote: Either way - it is possible now to shift animations using GMT - so you can take an animation and shift all of the elements by +0.5X for instance to move it half a unit in the x-axis. Exactly how this maps to the game, I'm afraid I don't know off the top of my head - but I'm almost certain it is now possible to move button animations to different positions on a wall using just the GMT.
!

Yes, it is, I just managed to get my secret buttons working. Only problem is that the 'bounding box' center of the secret buttons is the node (and not defined in a lua script), so if the secret button is too far away from the original button you can't click on it anymore. Works fine with my large button (as it is almost exactly in the same location as the temple set large button I'm using), barely acceptable with my small button (click a bit left and nothing will happen since the small button of the temple set is positioned a good bit to the right).

Now the only thing I couldn't get to work yet are the pit trapdoors, which behave weirdly. It's not that easy to understand for me how it needs to be set up with all the strange axis and rotation mess going on (y is z, z is y, a positive z value turns into a negative value and vice versa, and all that only for node positions, the models itself export like they should). But I hope I can figure out this one as well.

Hi John, reporting an issue with 4.1.1.1

I opened the chest I found here : viewtopic.php?f=14&t=4011
and exported as obj.

In 3dsmax 2013 I see no object (seems to be an object all collapsed in a single vertex). In Blender I see a cylinder (although it's the first time ever I open Blender, so I may have done something wrong ).

Update: now it opens in 3dsmax too, after I edited the file - I have Italian settings on my PC and it got exported with "," as a decimal separator.
Still it's similar to a cylinder, but probably it's the correct thing, as the model has a very weird custom matrix in the GMT

Grimrock Model Toolkit Release 0.4.3.0



Features

• You can now turn on/off rendering of Bounding Boxes, Bounding Spheres, Node Locations (Black Boxes).
• Rendering option to highlight the selected node and associated mesh/bones/nodes/bounding boxes.
• You can edit Bounding Centre, Bounding Radius and the Bounding Box of all mesh-nodes.
• Ability to add/remove nodes to a model (although, you can't add a mesh to a node yet - that's coming soon!).
• Add/Remove lights - if you feel the need!

@Xanathar: Thanks for the bug report, I think I've fixed the problem with OBJ files on machines in a culture that uses commas in floating point strings.

@Phitt: I'm hoping that the new features will help you sort out your bounding box issues.

@Neikun: I think I made the defaults more sensible. I think (I'm sure I did, but I can't remember fully!).

JohnWordsworth wrote: @Phitt: I'm hoping that the new features will help you sort out your bounding box issues.

Gladly my problem was related to light sources, the bounding boxes are ok. Phew!

I'd like to get back to the normals problem I was having earlier. It's not a problem with the toolkit! But I wonder whether the normal maps really behave correctly in Grimrock as I get strange results, both during my test runs and on my regular textures. Look at this screenshot:
The normal map is just a dot facing outwards. My party is standing on the square with the light source, which is positioned directly in the center of the square (at 1.5 height). Now look at the shadows on the dots. When you look at the outer right side of the image the dots look like I imagine they should look - the shadow is behind the dots. But the closer the dots get to the left side of the image, the more the shadow behaves weirdly. Until it finally is facing the light source. I'm not sure that is the way a normal map should work. Why would the shadow face the light source? It makes it look as if the dots face inwards. Do I understand something wrong? Or is this a bug? That's the way the default assets behave as well.

Hi Phitt, just to confirm - in the screenshot it looks like you are using the Mines tileset. Do you get the same effect if you re-texture one of the default wallsets with the same map? I just want to 100% rule out the possibility that the import process isn't messing with any UV coordinates or anything.