104 réponses à ce sujet

[rjshae]

Thanks. Unfortunately I'm not familiar with Gmax so I don't know the answer to that. At present, the Blender plugin mostly applies the same flags across all the model parts.

 

Blender has a section in the Material properties that allow Custom settings to be stored for each material. I'm starting to think it would make sense to add all of the Texture flags as a list of Custom settings for each model part. That would allow fine-grained control of the models. First I'll have to see if this can be implemented with the Python scripts.

 

If nothing else, you could then import the model into Blender, tweak the individual Texture properties, and export again.

[-Semper-]

A very good find.  I'd like to set that flag on certain floor placeables I've made, but I don't know if I can do it in Gmax.

 

dunno if gmax supports it but tazpn's tools have those flag integrated. it's either checked within the nwn2 mdb utilities or manually written in the mesh properties "projtexture = 1". at least the latter should work in gmax too.

[rjshae]

Hmm, well the Projected Texture flag works in some cases (left) ... but not others (right). I'm not sure why there is a difference.

 

[kamal_]

Well I learned something new today. In order for the mouse target circle to show up on a walkable surface (other than the tile floor), the 'Projected Textures' flag has to be set in the material's texture settings of the MDB file. Yeah, its kind of obvious in retrospect, but it had me stumped.

 

I've modified my code so that if a model component (such as a tile part) has a '_TP' suffix in the material name, the 'Projected Textures' flag is set on export. The pic below shows the result after applying the setting on the raised platform. (It wasn't working before.) So... yay!

 

 

 

Now I have some tile fixing to do.

If I provide the full retexturable versions of the tiles, could you set that for them so the target behavior is uniform for the two versions?

[rjshae]

If I provide the full retexturable versions of the tiles, could you set that for them so the target behavior is uniform for the two versions?

 

Yes, I've got the Blender code modified so its pretty easy to change--I just import, modify the material name, then export. But half the time it doesn't work (even though feedback shows the texture flags are getting set correctly), so I'll need to figure out why.

[rjshae]

Okay, problem solved: the InterfacePT field in the 'placeables.2da' file must be set to 1 in order to show the Projected Texture on a walkable placeable.

[Tchos]

With that info, my floor placeables now show the circle.  Thank you.

[rjshae]

I found a way to make objects semi-transparent while in object mode, so I've implemented this feature for the walk mesh and collision meshes. This allows you to see through to the model parts that are normally visible in-game. I think it looks kind of slick, and hopefully this change will be agreeable. It'll be out in the next update.

 

[rjshae]

The plug-in has been updated to version 2.6.2.3. It includes the following revisions:

• Extraneous characters following the null character in a string field could cause an import to fail. These characters are now trimmed before use.
• On export, an individual component's 'Alpha_Test' material flag is enabled if the Transparency is enabled and Alpha is less than 1.0 in an object's material settings. This behavior now correctly mirrors the import settings.
• If the material name of a model part ends with "_PT", it is exported with the Projected Textures flag set to true.
• On import, if a model part has the Projected Textures flag set, "_PT" is appended to the material name of the part.
• The walk mesh and both collision meshes are now set to display as semi-transparent while in object mode. This allows you to see through to the RIGD objects that are visible in the game.
• Made several updates to the mdl import to fix occasional hangs, incorrect color settings, and problems with keyword comparisons.

The Projected Textures flag allows the mouse target to appear on a walkable model part. To enable this flag on an individual model part, rename the part's material accordingly. (A walkable placeable also needs to have its 'InterfacePT' field set to '1' in the 'placeables.2da' file.)

[rjshae]

The one known issue that I gave up trying to fix (for now) is the application of the transform matrix prior to export. Cloning the meshes for this purpose resulted in some badly mangled models, so I had to work with the original data. Unfortunately, this can cause a double application of the transform.

 

Thanks to the helpful folks at the Blender Artists web site, I finally have a fix for this annoyance. It seems to be working very nicely now, so I'm quite pleased about that. It will be in the next update.

[rjshae]

The plug-in has been updated to version 2.6.3. It includes the following revisions:

• The issue of previously rotated or translated objects undergoing a duplicate operation following an export has finally been resolved.
• If a part has its Alpha set below 0.51 in the material properties, then on export the Alpha Blend texture flag is set to true. On import, the Alpha value is set to 0.5 if the Alpha Blend texture flag is set.
• Rather than aborting an export because there was no normal texture, set the normal texture file to the name of the diffuse texture file with a "_n" appended.
• Added an option to the import panel named, 'Remove Doubles'. Disabling this pick causes the import script to skip calls to the routine that merges adjacent vertices in a mesh. Removing doubles may cause the normals of some faces to reverse, among other issues. If you are having problems with your import, then I'd suggest trying the same import with this option turned off.
• Set Min. WALK mesh Z to -20, rather than 5, and shorten the display string. Equivalent export parameter default set to -19.9.

[rjshae]

The MDB Format wiki page has a description of the COLS packets found in the MDB files for a body model. I did a little experimenting to see if I could match up the packets in a body model (P_HHM_CL_Body25) with the bone dictionary that comes with the scripts. Unfortunately, the results aren't making sense.

 

Here are the COLS entries in the file and the corresponding bone index names:

• 0 -> Pelvis, has radius 0.25 (torso?)
• 2 -> Leg2.l, has radius 0.25 (torso?)
• 8 -> Toe.r, has radius 0.25 (torso?)
• 19 -> H_pk.l, has radius 0.21 (head?)
• 21 -> H_rk.l, has radius 0.12 (limb?)
• 23 -> H_mk.l, has radius 0.12 (limb?)
• 24 -> H_md.l, has radius 0.12 (limb?)
• 38 -> H_mk.l, has radius 0.12 (limb?)
• 40 -> H_ik.r, has radius 0.12 (limb?)
• 41 -> H_id.r, has radius 0.12 (limb?)

Most of these are on the hand (H) bones, rather than being spread evenly across the body (to detect collisions). It looks more like indices to a different array altogether.

 

I guess I could try various different model types and see if some patterns show up...

[rjshae]

<running away...>



There's a bit Here, and There and other There...
And even some bits hidden in the mysterious vanishing hull bit Here...
Edit: Holy Moly! Almost forgot the Magic Block! (search for it on This page ;-)

<...from hostile grannys>

 

I took another swing at this last weekend, but I'm still not making a lot of progress. Thus far I've determined the purpose of exactly one field in the data file--a file length field. There's another field nearby that may be a CRC32 check sum based on general randomness. I looked for fields that may be data offsets, but they just don't match up despite being similar to certain data ranges. The remaining fields don't fit with the above sources, which leads me to believe they are different versions. There are ranges of data that suggest certain purposes--like integer sets and floating point-like data, plus a number of fields in the header portion that are constant between .gr2 files so they are safe to ignore, but thus far no major breakthroughs.

 

Frustrated, alas.

 

Well another thing I can try is to do data listings by reading from certain offsets from my test files and see if the values make sense. I.e. finding floating point values between, say, -5.0 and 5.0, rather than 1.239x10^-302. That didn't work the first time, but maybe I need to try various different offsets and look for one that works. I might get lucky. Hmm, maybe my hex editor will let me do that....

[TheOneBlackRider]

By now, I've made a few im- and exports with rjshae's updated tool (version 2.6.3) and all exports behave well, it seems.

 

I also noticed, that Blender seems to import the COLS, but they are not visualized. Now, that you talk about it: I ask myself, if they are exported properly. Well, the Blender-export-PC does have some collision check, because it can't walk into walls, if it hits a NPC, the NPC moves aside, encounters do hit, ... But still, those collision could also be recognized through the non Blender model parts (eg. head, boots, ..).

 

So, here is a call for help out to Max owners: Could you testwise import eg. p_hhm_cl_body25 (because that model has a head/hood, hands and feet on the body model - it's in "NWN2_Models_X1.zip" - it uses "N_Kelemvor_CL_Body01.dds" as texture) into Blender, do an export and import that exported version into Max? I believe, that Max does show the collision spheres. If they are all still in place, we would know, that the Blender export tool does export those collision spheres correctly (correct size + positions),

 

If s.o. could do that, that would be great!

 

For the models, I used Blender 2.69. You can get all versions here:

http://download.blender.org/release/

Note: There are 7z-versions, which don't need an installation (sort of "portable" versions). Just execute from within the directory.

 

Here is RJShae's tool (2.6.3):

http://neverwinterva...rtexport-plugin

[rjshae]

Might I suggest saving your testers a step and just provide the model as exported from Blender?

 

Or I can do that tonight...

[TheOneBlackRider]

Good suggestion!

 

Hope, this works:

 

https://www.dropbox....er269Export.zip

[rjshae]

I wonder, would they show up if you turn on the C3 display in the toolset?

 

Nope, I was remembering it incorrectly. Sorry.

[rjshae]

Well, if it helps any, I looked at the COLS data in a hex editor for the imported (top) and exported (bottom) mdb model files. They look the same, after taking into account some re-ordering of the data. For example, there are six "b4 ee f0 d3" combinations in each.

 

[TheOneBlackRider]

Semper checked the Blender export and said, that the Collision Spheres are there. So the Blender im/ex-tool does a good job, it seems!

[rjshae]

Okay, thanks. Well its good to know that part is working properly.

 

I've just about got the final few (rare) import error bugs hammered out for the next revision, plus a few appearance changes to the import/export panels just for style points. After that, it'll hopefully be stable for a good while. Unless I finally get the gr2 skel file figured out, in which case I can add some more functionality. Or somebody suggests an addition.

[TheOneBlackRider]

Blender Collision Spheres (COLS):

 

Semper is aiding me on how to create Collision Spheres within Gmax (which seem to be exported correctly - but we are still testing). So I took the oportunity to create just one sphere on a certain bone and do an export, which I imported into Blender.

No matter, if eg. the head sphere in Gmax is named COLS12 or COLS00, in Blender it gets the same number (56)!
Since the Collision Spheres are linked to a certain bone, I'm pretty sure, that the bones are identified by numbers in Blender.

I just had the time to check a few, but will complete this list!

This is for a p_hhm_cl-mesh:

0 = Pelvis
2 = Leg2.l
3 = Ankle.l

19 = Ribs

56 = Head


BTW: The spheres are simple mesh creations (so "just" a sphere) = not converted to "Editable Mesh/Poly". Maybe that's clue to why they don't show up in Blender.

 

EDIT: They do show up as circles (well, they are spheres, which can be observed, when rotating the body model), but they are all centered at X 0, Y 0, Z 0 and not on the position of the linked bone.
 

[rjshae]

Thanks. The numbers seemed odd to me as they did not seem to be located symmetrically, for one thing.

 

 

Blender Collision Spheres (COLS):

EDIT: They do show up as circles (well, they are spheres, which can be observed, when rotating the body model), but they are all centered at X 0, Y 0, Z 0 and not on the position of the linked bone.

 

Yes, the COLS entries don't contain any position information, so the script just puts them at the origin. Ideally, I'd like to read in the skeleton data in the gr2 file for the SKIN object, find the coordinates of the corresponding bones, then put the circles at those locations. Using the centroid of the mesh weights was my attempt at an imperfect work-around.

[TheOneBlackRider]

Here is the complete list:

This is for a p_hhm_cl-mesh:

0 = Pelvis
2 = Leg2.l
3 = Ankle.l

8 = Leg2.r
9 = Ankle.r


19 = Ribs

21 = Arm1.l

23 = Arm3.l
24 = Wrist.l

38 = Arm1.r

40 = Arm3.r
41 = Wrist.r

56 = Head

Note:
Ankle-spheres are normaly included in foot models (boots).
Head-spheres are normally included in head models.
-> I just added them here to have a reference!

According to Semper, Collision Spheres don't have a certain "must/set" size and not a certain "must/set" position. They are handeled via the link to a certain bone.


Semper sent me an export of the Collision Spheres as mesh and I recreated them in Gmax. Here are the sizes and positions:

 

!!! NOTE:Non scaled model positions !!!

R= radius

Pelvis            R 0,25        X 0,0        Y -0,085    Z 1,139

Leg2.l = knee L        R 0,211        X -0,116    Y -0,112    Z 0,615
Ankle.l = foot L    R 0,215        X -0,116    Y -0,18        Z 0,151

Leg2.r = knee R        R 0,211        X 0,116        Y -0,112    Z 0,615
Ankle.r = foot R    R 0,206        X 0,117        Y -0,181    Z 0,151

Ribs            R 0,21        X 0,0        Y -0,115    Z 1,567

Arm1.l = shoulder L    R 0,116        X -0,199    Y -0,107    Z 1,633
Arm3.l = elbow L    R 0,115        X -0,309    Y -0,11        Z 1,344
Wrist.l = palm L    R 0,115        X -0,444    Y -0,08        Z 1,075

Arm1.r = shoulder  R    R 0,116        X 0,198        Y -0,107    Z 1,633
Arm3.r = elbow R    R 0,115        X 0,309        Y -0,11        Z 1,344
Wrist.r = palm R    R 0,115        X 0,444        Y -0,08        Z 1,075

Head            R 0,21        X 0,0        Y -0,77        Z 1,83
 

[rjshae]

Thank you, TOBR. That's a more sensible list of collision ball locations.

[TheOneBlackRider]

While trying to get a visual skeleton reference into Gmax, I stumbled apon this:

 

  newBone = Blender.Armature.Editbone()
    newBone.name = 'RLeg2.8'
    newBone.parent = newArmature.bones['RLeg1.7']
    newBone.options = [Blender.Armature.CONNECTED]
    boneMatrix = Blender.Mathutils.Matrix((-0.999989, 0.0037443, -0.00299102, 0),(0.0041625, 0.987917, -0.15493, 0),(0.00237478, -0.154941, -0.987921, 0),(11.5616, 23.7229, 55.0029, 1)).invert()
    newBone.matrix = boneMatrix
    newArmature.bones['RLeg2.8'] = newBone

 

I directly opened the Blender_Armature.blend and this explains the counting of the bones for the COLS:

newBone.name = 'RLeg2.8' -> That bone is no. 8 for the according collision sphere. Maybe those "Matrix" values help to get those spheres to the right position.

 

This is my current Gmax scene (p_hhm_cl...):