The last few days I spent getting a simple candle holder working (see
this discussion with Koniption about multiple material collision). With the latest Nifscope and Max niftools plugin, today I made new attempts to export a proper clutter mesh. Until now to no avail.
In Nifscope everything works. The NiStrips meshes show up well and the newly created convex collision (instead of the mopp collision I used before) is just fine.
I have no problem getting it into the CS. No crashes and such. However, when I try to place it in the CS I'm getting the first indication that the havok doesn't work. When I turn on havok and add the candle holder, it doesn't fal down, but floats in the air. I have to hit the F button to get it down onto the ground or another object like a crate.
When I start the game things get really weird. I can see the candle holder standing somewhere (I placed some on top of some crates in the Market District) and I can grab it and put it in my inventory. I can also throw it out of my inventory. When I do that I hear the sound of a metal object falling down onto the ground (I set the collision material to metal). However, the visible part of the object remains floating in the air. I can walk through it. If I walk around the place where I threw away the candle holder, I can hear my feet touch it and I can even grab an invisible candle holder from the ground.
When I shoot arrows at some other candle holders on the crates, I can hear them being flung away, but their form stays in place right on top of the crates. When I walk to the crates I can no longer pick them up. They are lying on the ground behind the crates, but are invisible. I can hear them when I step on them and grab them when I see a grabbing-hand appear to grab what seems to be nothing but thin air.
In addition I did some other tests with a simple cone with a simple cone-shaped convex collision. The bhk modifier was (just like the candle holder above) set according to
Saidenstorm's tutorial. The collision mesh is in any instance added to the bhk helper. When I link the bhk helper to the original mesh or do not link them at all, I get the same problem as above. When I link the original mesh to the bhk helper, I get only the collision and no model.
I hope this extensive description was helpful for any of you to help me solve the problem.
I hope anyone can help.
Thanks, Phaerus
Yo Phaerus,
We keep bumping into each other, don't we? heheh
From your description of the candle behavior in the game, it sounds to me like you placed the bhkCollisionObject (and everything that goes under it - the other collision data) under a different and also separate NiNode from where the candle's visible meshes are attached.
All the collision data should be under the same NiNode that the candle's visible meshes are under. By putting them under the same node, it's like telling the game engine, "Ok, the visible mesh(s) goes with this collision, and they are joined as one in Holy Matrimony, etc". By being "joined as one", the collision takes the candle mesh(s) with it wherever it happens to physically go, - like when on the honeymoon. :bananarock:
It's also why you need to try to fit all the collision shapes for the candle under one bhkCollisionObject, because only one bhkCollisionObject can go under a single NiNode at any given time. If you had used two different bhkCollisionObjects under two different NiNodes, to collision the candle, one of the bhkCollisionObjects would have fallen separate from the other one when interacted with in the game. Technically, you can use more than one bhkCollisionObjects, for havoked and clutter items, but then you'd need to use "constraints" for them, to "constrain" the multiple collisions together (which is used for bendable armor/clothing world objects, creatures, certain props like ropes/etc).
It's actually an interesting experiment to think about: you can actually make a single nif with multiple "peas" (as in the veggie), each pea under a separate NiNode with their own bhkCollisinObject to go with each pea. When you drop the peas from inventory, they will roll around on their own. When you click on only one pea, all peas are picked back up into inventory. Thing is, I've yet to find a way to make such nifs have their pieces interact and push off the other piece - right now, each pea would clip right through the other pea as if it were a ghost, yet they'd have proper collision when it came to other objects, the land, etc.
Koniption
I was secretly hoping for another of your valuable posts, which is why I placed the link in my last post in the other topic.
I checked the nifs, both the one of the simple cone and the candle holder itself. In both cases the NiStrips and the bhkCollisionObject are direct children of the root NiNode (Scene Root). Under the bhkCollisionObject is a bhkRigidBodyT and a NiNode, with the same number and name as the root node (0) (scene root). I have not yet gone with those transform blocks you mentioned in the other topic, but decided to first get it working and then optimize its performance, since all of this is very new to me (until recently Nifscope was for me mostly a retexturing application even though I knew it encompassed far more than that)
Edit: A difference between mu meshes and a Bethesda mesh (I compared it with uppersilvergoblet01.nif) is that the latter contains a block of extra data with all kinds of info about the mesh: mass, elasticity, friction, etc.
Hmm, if the collision data and NiTriStrips/Shapes of the meshes are all under the same Scene Root node, then something else must be going on.
You said that Bethesda mesh had a NiStringExtraData block, while yours doesn't....
Copy and paste the NiStringExtraData block from the Bethesda mesh into your own mesh. Copy the NiStringExtraData block into the same NiNode that the collision/mesh data is under, in your original nif.
I've heard people say that the NiStringExtraData block is not needed - and they may be right. But I could almost have sworn that it made a difference in some nifs of mine in the past. Couldn't hurt to try adding one.
Lastly, make all the flags of all NiNodes and NiTriStrips/Shapes a "14", under Block Details. At least try it. I've also heard that it doesn't make a difference whether the flags are 14 or what have you, but I typically change all the flags of those blocks to 14, anyway. I feel, at the very least, that the 14 flag value might be an optimization setting, though I have no proof of this (except for the fact that Bethesda used same flag value in most, if not all, of their nifs).
If the above does nothing, send me a download linky to the candle nif(s) in question. I'll take a personal and closer look at them.
Koniption
I SOLVED IT! It's got to do with the BSX flag. When I was checking out the flags like you suggested, I saw there were more flags than just the ones on the NiNode and NiTriStrips. I used two Beth clutter items as reference and compared mine with those. In the integer data line of the BSXFlags block, clutter items have a value of 3 while mine was set at 2. I discovered it pretty fast after I first checked the things you mentioned.
I can also say that the presence or absence of a NiStringExtraData block has no impact on whether the visible model goes with the collision model, or at least not an influence I have noticed. The same is true for the flags of the NiNode and the NiTriStrips block. Also it doesn't seem to matter if the flag of the NiNode has another value than the flag of the NiTrIStrips block, whathever those values are.
So now my candle holders fall to the ground and can be smashed away just like any other piece of clutter.
Doh!! I almost was gonna mention the BSX flags thing to you, but thought it might already be set at three in your nif, because you said the invisible collision "fell" and could be "grabbed".
Regardless, it's good to hear you figured it out.
Koniption
What I found out was that every kind of object in the game has a different integer data value in the BSXFlags block. These values must correspond to the right collision settings. For instance, to have an object get a flame in the game, it must have a BSXFlags value of 19 (for candles and torches) or 17 for wallsconces and lamps. Iron hanging lamps have yet another value, I believe it was 27, while chandeliers are just ordinary static objects and have no flames. Hence the latter have a BSXFlags value of 2, which seems the default value for static objects.
Candles have the default collision settings of a static object. It is possible to create an object that has a flame yet has the collision characteristics of clutter, but it causes the game to behave weird. Such an object has collision settings of clutter, but a BSXFlag value of 19. It is possible to throw or smash such an object away and the visible mesh is then joined by the collision mesh, but when it would collide with another object, say the ground or a crate, iit then falls through such objects, but not necessarily entirely. In other words, the collision becomes partly dysfunctional. NPCs and the player also start to fall through the ground until about their ankles or knees around the area where the object fell through the ground. The game does not crash or anything and it is perfectly possible to continue playing, although it doesn't seem very healthy for a savegame to me. The player and NPCs just have to go through that spot as if they were wading through water and then resume walking normally on the ground instead of in or through the ground when they are some distance away from the spot.
Edit: after looking around a bit, here is the grand enlightenment on this topic:
http://niftools.sourceforge.net/forum/vi...=10&t=2595. By adding up the numbers it is possible to combine different characteristics.
Clutter is a combination of two characteristics: the object has collision (2) and uses havok (1). Together this makes 3. The characteristic that it is possible to grab the object comes from the collision characteristic. Objects that have a BSXFlags vlaue of 2 but are still set as clutter in the BSXCollisionBodifier will have the collision function as such, but not the mesh funcion as clutter. This is the part havok seems responsible for.
It's quite interesting to try out different BSXFlag values. All objects with flames need to have at least a BSXFlags of 16. 17 allows the use of havok, but without collision enabled in the BSXFlags, the object does not react to impacts such as an arrow shot right at it. Instead the arrow just pierces the object. When setting the BSXflags to 18, the object has collision, it is possible to grab it and cast it away, but it doesn't fall to the ground and can't be smashed away. However, when shooting an arrow at it, the arrow can't pierce it anymore as if it were a cloud. Setting the BSXFlags to 19 would theoretically allow a clutter object to be grabbable, have a flamenode and, react to impacts, forces and gravity, however this is not so. It is possible to grab such an object, but the moment you do this, the collision becomes partly dysfunctional and objects and characters start to sinkthrough the ground at that spot. Sometimes they appear to be hindered by the terrain however.
So it appears that clutter can't have a flame because the game can't handle that. This might have to do with the fact that I entered the object in the CS as clutter. However, what would happen if I'd enter the object as a 'light'. Perhaps I can then get a light to act like clutter.
Yes, it is most likely because you entered the light as "Clutter", and not under CS in the "Lights" section.
I PM'ed you something interesting, that you will find useful. Check your inbox.
Koniption
Thanks for the things you sent me. You are right. To get it all working, what I need to do is not to enter a clutter object as a 'light', but set the candle holder's collision as a weapon and enter it in the CS like a light. I tested it with a test version of a candleholder I turned in 3dsmax like the torch. The player can now hold it by its ear with his finger through the ear. I can drop it just fine, pick it up, etc. So that's completely solved now.
What's left, apart from making new meshes that are turned 90 degrees like a weapon is to write some scripting. I think it can be fairly simple.
I will create two sets of weapon-like candle holders: one set lit and one set off. This will also allow modders to spread unlit candles on candle holders in the gameworld. This creates a problem: the unlit and lit candles each require a separate entry in the CS and will thus become separate objects. Equip one and there is no flame and lightsource and equip the other and there is light and a flame. So what I need to do (I think) is to write a script that replaces the unlit candle with the lit candle when the player adds it to his inventory. To keep things no too complicated, I'll stick to a single dropable object and not allow for the player to decide whether to blow out his candle on dropping it or not. That could be a future step though, and might not be too difficult with a messagebox. The tricky part, however, would be to replace the lit candle by the unlit one the moment it is dropped. I have as of now no clue how to do that (I have only little experience with scripting) and, as I said, I will leave that for later.
Above I spoke of 'sets' because I will make the candle holder for different candle heights and one version with just a puddle of wax in it. Perhaps it will be possible to replace the candle with different versions to have it gradually burn away over time while the player is using it.
Perhaps it is even possible to create the candle holder in such a way that it can be re-loaded with a new candle. I could then also create candles that could be sold by vendors. That is also an idea for the future.
My current focus will on getting it to work first.
One more thing I want to test is the possibility of multiple material collision. I have tested this on the latest clutter versions of the candle holder. The method of grouping the other collision and then adding it doesn't work as I would like to see when using a lit candle. The lit candle is different from the unlit candle because it has to use an extra node under the root node in which the collision, flamenode, visible meshes, etc. are stored. Simply adding a Bhklistshape and listing the collision meshes under that one causes the candle holder (the pewter part) to be turned sideways. What I have done to solve this is create an extra Ninode under the rootnode (so that the root node has 2 children, the one with the candle, flame and stuff and the other with the holder) in which the holder's collision is stored in a second Bhkcollisionobject. I'm not sure this works, but it seems plausible.