FreshLook

The binaries are statically linked to the Visual C++ runtime, so no need for redistributable. They are dynamically linked to libfbxsdk.dll, which should be included in the release. Is log.txt generated if you double-click nw2fbx.exe? Have you modified config.yml or are you using the original?

If you run nw2fbx.exe from cmd without any arguments, is anything printed to the console? Have you downloaded the last version (0.5)?

Yes I have set in config.yml the directory where NWn 2 is installed What files are you passing? Is log.txt generated? If you execute from the command line, is anything printed?

I'm not into NWN and I don't understand very well, but what you say about the way a NWN creature is composed reminds me of a multipart animated placeable. Maybe, if you parent the root part of the creature to a .PIVOT, export to FBX and convert to GR2 you will have a skeleton for free that you can convert to FBX and import into Blender.

I think it's easier to select an animated object to see the keyframes and update the timeline. For a looping animation set the final frame to the penultimate keyframe, since the last keyframe is equal to the first. Anyway, next version I will print animation duration to the log.

Blender doesn't update the timeline when importing a FBX. Maya, for example, has an import option to update the timeline. Maybe this is a feature that could be asked to the Blender developers.

I have released version 0.5. You can download it here: https://github.com/A...wn2mdk/releases Changes: You can drag&drop directly to nw2fbx.exe or fbx2nw.exe and the log will be redirected to log.txt. When they are executed from the command line, the log is printed to the console as always.Added a bunch of validations when converting FBX to NWN2. Search for "ERROR" in log.txt to see if there is any error.

It has occurred to me a less tedious workaround: Clone PLC_DP_JAIL1, name it PLC_MC_TDOOR. Convert to FBX the standard way: PLC_MC_TDOOR.MDB + a TDOOR animation (don't pass skeleton).

The algorithm that my tool is using to automatically match a placeable with an animation is failing in this case. The tool expects the main part to have same name as the animation. I conceived this algorithm because some animated placeables have more than one animation in the same GR2 and I needed a way to match each model to its corresponding animation. This worked with all the cases I encountered until the one you have found. The NWN2 engine knows how to match because it's configured in doortypes.2da. I would have to think a new algorithm. There is a workaround, though: Convert PLC_DP_JAIL1.MDB + PLC_MC_TDOOR.GR2 (the skeleton) + a TDOOR animation. The skeleton will be matched to the animation, but the placeable won't. Import the FBX in Blender. Link the placeable to the bone: select the jail object, go to the Constraints tab of the Properties area, add object constraint Child Of, set Target to PLC_MC_TDOOR, and set Bone to PLC_MC_TDOOR.

This is not documented. The easiest way to see how to set the flags is to convert an MDB to FBX, import it into Blender and look at Custom Properties in the Object tab of the Properties area. If the value of a property is 0 or the property doesn't exists, the flag is not set. If the value of a property is not 0, the flag is set.

You can pass a body MDB + a head MDB + just one skeleton (e.g. P_HHM_skel.GR2). Both MDB will be skinned to the same skeleton. This serves you?Not all body MDB's and head MDB's have same collision balls. For example, P_HHM_Head01.MDB only has collision ball for the head and P_HHM_NK_Body01 only has collision balls for body. I think this is usual and the case of c_skel_* is an anomaly.Anyway, you can easily remove the duplicated collision balls in Blender. In Object Mode, go to Select > Select Pattern.. and type *.001 to select objects ending in ".001", then press X to delete them.

What exactly are you trying to do? Maybe there is an easy solution. To convert animated placeables to FBX don't drag&drop the GR2 skeleton. I passed plc_bc_shiprow1.mdb and plc_bc_shiprow1_idle.gr2 and there was animation. Maybe you didn't see keyframes in the timeline and you thought there was no animation? You have to select an animated object to see the keyframes. Or maybe you didn't see any motion, since the animation is subtle. I had to look at very near to see it.

Duplicate collision balls: The reason is that both MBD's have the same collision balls.Duplicate skeleton: Both P_HHM_skel.gr2 and c_skel_skel01.gr2 have the same bones.Bones not aligned: You have to check Automatic Bone Orientation in the Armatures tab of the import FBX options. That's correct. PLC_DC_CWATCH_IDLE.GR2 animation has two track groups, one to animate the main and attached parts and another to animate C2. You can see this in log.txt. I suppose you aren't looking at it because you are dropping directly to nw2fbx.exe (next version will generate log.txt). A track group matches a skeleton/.PIVOT. Whether the NWN2 engine supports animating C2 or not is unknown to me.

1) I haven't tried LoD. Looking at a few vanilla animated placeables with LoD, the pattern I see is this: Only the main part has LoD.Only the full-detail main part together with the attached parts are animated. So only one .PIVOT.2) I'll answer this week. I'm very busy.

Well then the geometry origin is in the right location. Hmm. Yes I started over, importing the three parts into an FBX file, joining them under a .PIVOT as before with the doors as children. I tried the same thing using the 'Object (keep transform)' option to join the doors, but that made no difference. It's curious though that when I'm shifting the doors into position, the geometric origin stays at the same x-axis location (0.0) rather than moving with the doors while the y and z coordinates move. https://www.dropbox.com/s/27jsb8uezipo934/plc_md_cabinet05_r4.7z?dl=0 I have looked at the FBX's. You have the geometry origin of the doors at the opposite side where it should be. The hinge is the joint thant links the door to the cabinet but you have the geometry origin of the door at the handle side.

Select the door and where the manipulator (three colored arrows) is located, there is the geometry origin. After having changed the geometry origin, are you reconverting the animations?

The opening motion is odd because the geometry origin of the attached parts should be the hinge. Look at the armoire attached parts for an example. With the proper geometry origin, you should achieve exactly the same animation than the armoire. For animating placeables you don't need a rig at all. And anyway, if the blending between animations doesn't result in the desired animation, you can always create X_PLC_OPEN.GR2 and X_PLC_CLOSE.GR2 animations.

By trial&error I got it working. I think I found the problem. It seems that the blending between IDLE and OPENIDLE only works if IDLE has only one keyframe. Before exporting IDLE to FBX, in the Timeline area, set Start: 1 and End: 1. It works if OPENIDLE has more than one keyframe, but since it's an idle animation, why having more than one keyframe? I have tried having all attached parts in the same MDB as the main part as well as having each attached part in its own MDB and it has worked both ways. However, it seems all vanilla placeables have each attached part in its own MDB. I wonder if there is any reason for this. If each attached part is in its own MDB, you must set column AttachedModelName of placeables.2da to plc_md_cabinet05_??. I think the texture flickering is because you aren't exporting binormal and tangent vectors. In the FBX export options, you must check Tangent Space in the Geometries Tab. Next version of my tool will validate that there is tangent space info in the FBX and give an error if it's missing.

plc_md_cabinet05 should be the main part and the only child of plc_md_cabinet05.PIVOT. plc_md_cabinet05_01 and plc_md_cabinet05_02 should be the attached parts and children of plc_md_cabinet05.

They don't because of the issue I explained in post #182, last paragraph. Then I had the idea of simplifying working with animated placeables by not needing a skeleton when converting, what at the same time resolves the issue. Do you need the parts attached to the bones for any reason?

You aren't doing anything wrong. X_PLC_OPENIDLE.GR2 is the idle animation when the placeable is open. The opening animation X_PLC_OPEN.GR2 is optional. NWN2 blends between animations when transitioning from one state to another.

Does this free up any bones on the HHM / HHF skeletons? Or are we at max there without dipping into cloaktail skeleton? I'd really really like to have like an additional 2 - 4 bones .. *sigh* P_HHM_skel.GR2 has 54 standard bones: 0: P_HHM_skel 1: LLeg1 2: LLeg2 3: LLegAnkle 4: LLegAnkleDigit011 5: RLeg1 6: RLeg2 7: RLegAnkle 8: RLegAnkleDigit011 9: BHip110: FHip111: LHip112: RHip113: Spine14: LArm0CollarBone15: LArm01016: LArm01117: LArm0218: LArm0Palm19: h_LArm0PalmDigit45120: h_LArm0PalmDigit45221: h_LArm0PalmDigit34122: h_LArm0PalmDigit34223: LArm0PalmDigit23124: LArm0PalmDigit23225: LArm0PalmDigit12126: LArm0PalmDigit12227: LArm0PalmDigit01128: LArm0PalmDigit01229: RArm1CollarBone30: RArm11031: RArm11132: RArm1233: RArm1Palm34: h_RArm1PalmDigit45135: h_RArm1PalmDigit45236: h_RArm1PalmDigit34137: h_RArm1PalmDigit34238: RArm1PalmDigit23139: RArm1PalmDigit23240: RArm1PalmDigit12141: RArm1PalmDigit12242: RArm1PalmDigit01143: RArm1PalmDigit01244: Neck45: Head46: ponytail147: ponytail248: ponytail349: eyeRlid50: eyeLlid51: eyeL52: eyeR53: Ribcage I think P_HHF_skel.GR2 has same bones.

I have been playing with it I got it working. The proper names for the placeable animations are: plc_du_secret_door_idle.gr2: idle animation. Used also for idle animation when closed.plc_du_secret_door_plc_open.gr2: opening animation.There are more, but I don't know if you are going to need them.X_idle.gr2 is required and the others are optional. For On Used Script I have used vanilla x2_plc_used_opn.

@Semp3r, @rjshae: I'm reading the original official Obsidian Expotron guides (in particular, "Exporting Animated Creatures") and it says: ... 4) If a vertex is getting an error, check to see if there are more than 4 bones assigned to it. 5) Cinematic head skin can have no more than 3 bone weights per vertex. 6) Cinematic head vertexes must be weighted at least .026 to one non-face bone (f_bone) ... There is nothing more said about bone weight rules in the document. @rjshae: Inspecting plc_du_secret_door_orig.fbx I think the problem is in the export FBX options, in particular the animation options. Make sure Baked Animation is the only checked option. Look at Step 5 of the banner tutorial. When converting an animated placeable to FBX, only drop the MDB's and the animation file. Since version 0.4, don't drop the skeleton anymore. I have done plc_du_secret_door.blend -> FBX -> MDB, GR2 -> FBX -> Blender and it worked. @4760: reading the Obsidian Expotron guides I have discovered that attachment points bones (ap_*) don't count to the bone count limit either.

The tutorial about animating the banner of Tyr only explains the animation of one packet and there is one thing you need to know in order to animate a placeable with multiple packets. One packet must be the main part and the other packets must be the attached parts. The main part must be the only child of the animation pivot and the attached parts must be children of the main part. The animation pivot can have no more than one child. Lower-level technical information: for animated placeables, NWN2 needs a skeleton where the root bone corresponds to the main part and the children of the root bone correspond to the attached parts. This is the skeleton that fbx2nw generates under the hood. Since a skeleton in NWN2 can have no more that one root bone, there can only be one main part.