So I made a building, and with it I made a door. Nearly everything works great. The building automatically spawns the doors. The problem is that clicking on the doors doesn't actually animate them opening. Is this a 2da problem, a toolset problem, or a model problem? In exporting other doors to blender I haven't been able to find bones in them. Is that weird?
Oooh, I figured it out. It was my own dumb fault. I didn't have the proper skeleton in doortypes.2da. It seems to work fine with the default one.
Now I just need to figure out why the C2 data and walkmesh aren't properly going into the building MDB (though weirdly C3 is fine). Små framsteg är också bra!
I finally got the walkmesh working, but the collision data and bounding box have me baffled.
As you can see, the bounding box is way too small for some reason, the C2 data isn't present at all, and the C3 data seems limited to the windows (and the doors, which are a different model).
Yes that's weird. After looking at various examples of models where it does and doesn't work, my first guess is it has something to do with the walk mesh. Can you try moving the lowered part of your walk mesh up to height zero and see if that fixes it?
Ed.: I tried that and it didn't completely solve the problem. It did restore more of the C3 mesh lines though. Hmm....
Some of the models I've exported from Blender (the Tudor house for example) show the C2/C3 mesh in the toolset whereas others do not. At least part of it seems to relate to how the walk mesh is positioned relative to the collision meshes. Does making the unwalkable part of the walk mesh wider than the collision mesh cause the issue? I need to do some more experimenting to see what causes the difference.
I'll play around with it for a bit and see if I can figure anything out. If I reimport the MDB to Blender I get the same thing back, so at least I know it isn't a problem with the import/export script.
I'll try playing around with it and see what I can figure out. I've been basing what I've done off of tupoun's stuff, but I don't really know if he worked in Blender or not. Rearranging the walkmesh as follows didn't seem to do the trick (although it is lower poly so I might keep this).
As it stands the walkmesh is contained (vertically) within the C2 and C3 boxes, and the C3 box is contained within the C2 box (this is not consistent with tupoun's models, where the relative sizes of these three vary from model to model). The C2 box is all enclosing, while the C3 box has an open floor, again following tupoun's example.
I've gotta say, what -really- baffles me is that I do get C3 data, but -just- on those illuminated windows, which are one whole part of the model.
EDIT: Woooo, I finally got this working! I have no idea why, but I did it by copying everything into a new blend file. Blender was doing something odd and I have no idea what.
At the moment I'm stumped. It seems to work okay on some models exported from Blender but not others:
I tried copying the collision meshes from a model where it worked to one where it doesn't... but it still doesn't show. Changes to the walk mesh didn't help. Crud. Could it be a bug in the toolset? I don't know.
That arched shrub model (lower right) sure went bat sh*t crazy with the C3 mesh. It's got a little more complex collision mesh than the others, but it's sure not that detailed.
Okay, I have a working hypothesis. The models where the C2/C3 mesh display properly have the non-LoD RIGD components positioned before the COL2 and COL3 components in the mdb file. Where the C2/C3 doesn't display, the COL2 and COL3 components are placed in front of the non-LoD RIGD components. Hence there seems to be an order dependency. I checked a bunch of models and this seems to be the case.
Rekov, this would explain why it worked for you after you copied it to a new Blend file; the export likely read them in a different, positionally-correct order.
What I need to do is modify the Blender mdb export script code to place the parts in the order: RIGD, SKIN, HOOK, HELM, HAIR, COLS, WALK, COL2, COL3. Once I've done that I can check if it fixes the problem.
So the alphabetical order Blender uses is just for display, then? That could be what's doing it. I don't know if this helps, but here is one thing I'm sure of: When the C3 fails, it uses the last packet in the file instead, which is why it kept using the illuminated windows on mine.
Is it the C2 and C3 boxes which block the camera in game? They look right in the toolset, but I'm still able to swivel the camera into the model when testing in game. Though for whatever reason, the doors still block it.
So the alphabetical order Blender uses is just for display, then?
Yes. The export just cycles through the internal list used to store the data, which doesn't have any particular order AFAIK.
Is it the C2 and C3 boxes which block the camera in game? They look right in the toolset, but I'm still able to swivel the camera into the model when testing in game. Though for whatever reason, the doors still block it.
I think it's the C3 mesh; my guess is the simpler C2 mesh is for making initial determination of an intersection, then the C3 is employed for more precise calculation.
The camera can behave pretty squirrely near some collision mesh shapes. I ran into a problem like that with the Imperial Wayshrine, for example. There's a few tricks I use for trying to avoid the problem, but they don't always work.
Well, I have no idea what's doing it, and I've spent enough of my day pulling out my hair out over this one. I'm gonna churn out a few more buildings and worry about the collision **** at the end. Here's the MDB for the one I have so far, if anyone feels like giving it a shot.
Exporting in the new order appears to resolve the issue. Here is an example I tried, showing the meshes before (left) and after (right):
I put a copy of the modified export script here if you want to try it.
Unfortunately this means I'll need to go back and check/fix this in every mdb file I've ever exported. 
Thanks, man! I don't know if I can properly express how much help you've been. The new script seems to be correctly exporting the MDB, but then, I'd had it working before hand, so I guess I'll need to watch it for a while to see if it breaks. I'm still getting that issue where the collision boxes don't actually block the camera in game, but that's starting to look like a separate problem.
Unfortunately this means I'll need to go back and check/fix this in every mdb file I've ever exported.
Fortunately they don't all have col boxes, heh. I don't envy you though.
EDIT: My problem was a 2da problem. Script's golden, baby!
I'm still getting that issue where the collision boxes don't actually block the camera in game, but that's starting to look like a separate problem.
I haven't been able to figure that out, myself. I've tried to make an invisible placeable that I can use to block the camera without affecting the walkmesh, or at least being a very simple shape that doesn't affect it too much. I've had to settle for just leaving my wall placeables as placeables instead of environmental objects.
Mine were set to placeables, were affecting the walkmesh, but still weren't clipping the camera. The problem was that I had Fade set to 1 instead of 0 in the 2da.
I'll play around with what you're trying there, because I agree that it'd be useful. There are invisible placeables (called collision boxes actually, I think). Here's what I would try: Make an invisible placeable with no walkmesh, set it to non-fade in placeables.2da, and use it in game as a placeable with dynamic collision turned off. I -think- this should make it stop the camera but not affect the walkmesh. I'll give it a shot in a bit.
I haven't been able to figure that out, myself. I've tried to make an invisible placeable that I can use to block the camera without affecting the walkmesh, or at least being a very simple shape that doesn't affect it too much. I've had to settle for just leaving my wall placeables as placeables instead of environmental objects.
Yep! Here's how you create the exact effect you want. Open up placeables.2da and set the Fade from 1 to 0 for CityMCollBox.
In the toolset, plant a {Collision Box}, set it to static and walkable, and keep it as a placeable.
This should give you exactly the effect you want: Something that's invisible, blocks the camera, but doesn't affect the walkmesh or have collisions.
I checked it between your last two messages, and I found that indeed my own attempt had left Fade at 1. I had thought that BlockLOS being set to 1 was the way to go, but now I'll try it with Fade at 0 as well. Thanks!
Does it also block the map as a closed door might?
PJ
I found one of the standard models where the collision mesh display problem also occurs: the smithing cauldron.
This happens even with the model parts placed in their usual order.
I'm not even sure now if there is a problem; it may just be a bug in the way the toolset displays the collision mesh.
I should have remembered this earlier, but from debug mode you can activate the display of C2 and C3 data. As you can see below, the C2/C3 data is there for the Cauldron, even though it doesn't show in the Toolset.
Well that pretty much proves it's just a toolset thing. :V
When a model has a single RIGD part (the textured component), then the re-ordering seems to fix it. (I tried that on a few models and they displayed the collision meshes properly after the number of parts was collapsed.) The display problems arise when a model has multiple parts (such as the Cauldron above), which is usually the case when separate texture files are used for the different parts. Ah well.
Retour en haut