3dsMax 2013/2014 (64 Bit) Full Plugin - Updated!

[Groovtama]

The autoload fix for textures when you import a mesh would be nice, I am seriously sick of going through 10 shapes again and again just to reload the textures when I veiw meshes, blabbas plugin finds them automatic which is far more convinient.

 

Sidenote: XPMS 1.93c+ and XPMSE should not have unnamed or duplicate named nodes in the nifs so they are save for import, XPMS 1.92b and lower have that issue, as well as some other messy older skeletons.

[Vioxsis]

The autoload fix for textures when you import a mesh would be nice, I am seriously sick of going through 10 shapes again and again just to reload the textures when I veiw meshes, blabbas plugin finds them automatic which is far more convinient.

It did load the textures on import for me, without editing the path in the config.

And my skyrim is installed on my D drive, so It must take the path from the registry.

[Groovtama]

 

The autoload fix for textures when you import a mesh would be nice, I am seriously sick of going through 10 shapes again and again just to reload the textures when I veiw meshes, blabbas plugin finds them automatic which is far more convinient.

It did load the textures on import for me, without editing the path in the config.

And my skyrim is installed on my D drive, so It must take the path from the registry.

 

yeah blabba also takes it relative to the mesh also. you can have a mesh and a texture folder next to each other anywhere on your drive with the imported mesh in the mesh folder and and the plugin finds it. it is nicer like this when working with MO or in a seperate folder.

[Vioxsis]

yeah blabba also takes it relative to the mesh also. you can have a mesh and a texture folder next to each other anywhere on your drive with the imported mesh in the mesh folder and and the plugin finds it. it is nicer like this when working with MO or in a seperate folder.

I never knew that, but had it happen a few times, every time it did i thought how the hell it know where the textures were.

I just set up multiple alt paths of where i unpack bsa and to my download folders to try and catch them all.

[tfigment]

The MaxNifTools.INI is holds all of the plugin configuration.   It is typically installed at "%USERPROFILE%\AppData\Local\Autodesk\3dsMax\<version>\enu\plugcfg".  This folder is chosen because it is guaranteed to be writable.  If this is missing then %Install%\Autodesk\3ds Max <version>\plugcfg is searched and used.  If you install to default C:\Program Files then this folder is readonly and cannot be changed unless you are administrator.

 

The Game MaxNifTools.INI file looks something like the following:

[Skyrim]
NiVersion=20.2.0.7
NiUserVersion=12
NiUserVersion2=83
; Installation Folder
InstallPath=[HKLM\SOFTWARE\Bethesda Softworks\Skyrim]=@"Installed Path"
RootPath=${InstallPath}Data
ExtractFolder=$(RootPath)
MeshRootPath=${ExtractFolder}
TextureRootPath=${ExtractFolder}
UseSkeleton=1
Skeleton=${MeshRootPath}\Meshes\actors\character\character assets\skeleton.nif
RootPaths=${RootPath};${MeshRootPath};${TextureRootPath}
TextureRootPaths=${RootPath};${TextureRootPath}
TextureExtensions=.dds;
TextureSearchPaths=${RootPath}\Textures;${TextureRootPath}\Textures;${TextureRootPath}
SupportPrnStrings=1
Rotate90Degrees=NPC Head
SkeletonCheck=NPC*
DummyNodeMatches=* NonAccum;_;NPC COM
bhkScaleFactor=69.99124908

The key values here are the TextureSearchPaths and Skeleton.   Skeleton is where it defaults to searching for the skeleton if not in current import folder.  The texture search paths are recursively searched to get a list of files.  If the name in the nif matches exactly then it will import correctly.  Typically, I would replace ExtractFolder with the location I dumped the BSA files.  I now just dump them all to same root.  So the MeshRootPath and TextureRootPath are same.  if you dump to seperate folders then you need to set right of the equals of MeshRootPath and TextureRootPath manually in the INI file.   You can also see that RootPath is derived from the Game installation folder in the registry so it will also search the Data folder of the game so loose files are found if they are there.

 

 

 

 

I actually have some questions for you over the BSDismemberment stuff, I've been in the middle of a huge rewrite of that modifier code (mostly because the original was absolutely broken and not following proper API standards.)

 

Also, do you have any idea about ehamloptiran's work with niflibs? All his collision fixes in the plugin reference changes that I assume he made to niflibs but didn't share publicly.

 

edit: I don't mind you posting here for feedback/changes. If it makes it easier for you to sort that stuff out in your own thread (so you can control/edit OP) that also would work fine.

 

 

Go ahead and ask. I'm not sure what you mean absolutely broken. Have you looked at the sample code its absolute sh*t itself to start with? With about 4 ways to do the same thing and each very different. Anyway, the WIN64 define caused most of my problems with it.  The modifier is basically meshsel sample verbatum with edge and vertex selection removed because they dont make sense.   The only real changes is the introduction of an additional level to handle multiple layers.  Maybe scripting doesn't work but thats rather advanced usage and more than what ever I used it for.  Anyway, I wont stop you from rewriting if you want but hacking meshsel seems far easier that writing from scratch.

 

Or perhaps you are using a more sophisticated testing technique.  I'm not much of a modeller so have used most of the Bethesda samples for most of my testing so I'm sure I dont see the way the real models look with 12 modifiers layered on top.

 

Most of the niflib stuff is not too hard but then I've not tried to go through all of the code changes that you posted so I dont know all of the gaps.  Was doing one feature at a time and started with particles since it looked easy to port.   Will find out the rest of the fun later but thanks for the warning.

 

I didn't look at Eham's collision code yet.  I did my own updates before I saw either of the other changes.  I'm starting to incorporate those now.  Maybe will have time this weekend.

 

 

 

[blabba]

 

Go ahead and ask. I'm not sure what you mean absolutely broken. Have you looked at the sample code its absolute sh*t itself to start with? With about 4 ways to do the same thing and each very different. Anyway, the WIN64 define caused most of my problems with it.  The modifier is basically meshsel sample verbatum with edge and vertex selection removed because they dont make sense.   The only real changes is the introduction of an additional level to handle multiple layers.  Maybe scripting doesn't work but thats rather advanced usage and more than what ever I used it for.  Anyway, I wont stop you from rewriting if you want but hacking meshsel seems far easier that writing from scratch.

 

The BSDismemberments code was absolutely terrible, it was the cause of like 90% of the crashes for me, especially when modelling.

 

This is because several things are broken:

The save/load feature doesn't actually function (Saving modifer data to .max file and loading from it) (Or it least in the version I was editing it didn't)

It tried to do dynamic updating of the modifier UI sub-options and base them on part names instead of the sub-object selection types, however it wasn't done right and thus lead to crashes in certain circumstances.

The biggest, and buggiest part about the entire thing was that it would create new instances of the derived object and add them to each other in the mod stack instead of adding the modifier itself to an existing derived object (if it existed).

This meant that anytime you used a modifier on top of the bsdismember modifier, you crashed. AFAIK this was a problem in every version (easy enough fix though, it's on the niftools github page now as well)

 

Their were some other things but I've forgotten, haven't had time to work on this recently. I hope to get some time this weekend, but in the meanwhile I'll keep an eye on your repo to see if you already answered my question

 

 

The key values here are the TextureSearchPaths and Skeleton.   Skeleton is where it defaults to searching for the skeleton if not in current import folder.  The texture search paths are recursively searched to get a list of files.  If the name in the nif matches exactly then it will import correctly.  Typically, I would replace ExtractFolder with the location I dumped the BSA files.  I now just dump them all to same root.  So the MeshRootPath and TextureRootPath are same.  if you dump to seperate folders then you need to set right of the equals of MeshRootPath and TextureRootPath manually in the INI file.   You can also see that RootPath is derived from the Game installation folder in the registry so it will also search the Data folder of the game so loose files are found if they are there.

 

 

Unfortunately the textureSearchPaths wasn't actually used anywhere in the import code IIRC. It's why I had to hack in my own .ini setting for it. I forget why but there was a reason why I couldn't use the existing line. Oh and the import code itself had a mistake in it somewhere for the paths (2010 codebase from niftools)

 

Edit:

I remember my question! Figment did you not have BSdismemberment selections showing up correctly or at all when you made x64 bit version?

Mines was completely broken when I straight ported it.

[tfigment]

TextureSearchPaths is used in AppSettings.cpp (~ line 65) and has been there since 2006 according to git logs.  What I think there was an issue with case sensivity in a comparison function that may have been fixed in my recent changes.  That was a folder comparer and may have caused it to not work correctly in picking up files if the case did not match exactly.

 

Regarding the 64 bit build 4 years ago, I could not tell you really. Recently I pulled up the same code and it worked fine in 2016 as is. Turns out they made subtle changes in the bitarray.h file that probably makes it work in 2016 due to the compiler itself.  I probably was using the 32-bit build of max 2012 most of the time though which is probably why it was delivered that way and my test cases were probably simple.  It never would have occurred to me that this specific feature had a 64-bit dependency and the only one in the sdk I think.  Even recently when I noticed the mismatched selection and crashes it took a lot of research to find that code.  I assumed it was a compiler version mismatch w.r.t inline functions instead.

 

I did see your derived object changes and wondered about them.  Thanks for the explanation though I think I still do not fully understand and will need to research some now. Anyway, the modifier works for me now in the ways I expect it to work (save/load works, undo/redo works, sel unused works). If you are going to edit a mesh (add/remove verts), I wouldn't even consider having it on the mesh.  I always viewed Dismember as the last thing to be done much like collision.  Not trying to really defend it but to me it seems to work fine for the job which is allowing the user to select specific faces and tag them with the body part type for the final export.

 

 

 

 

Edit: Released a new build 3.8.0-a2. This was due to serious bug in the 2012 and earlier builds where string conversion was not done correctly when converting versions (needed A2W instead of A2T). This caused immediate failure so I release the current changes. I'm not really done with it thus the a2 designation but I think its improved from previous release.

[blabba]

Huge thanks to @tfigment

 

He caught my novice mistake for the broken BSDismember modifier that people were getting.

 

New version updated, change log speaks for itself on OP.

 

long term plans:

I'm still sticking to Skyrim as I have no interest in the Fallout series. (If you care about fallout, I highly suggest looking at figments builds that he posts on nexus or on his git!)

I'll still be sticking to 3dsmax 2014, I'll build for 3dsmax 2017 when it comes out in March 2017 . I may or may not go ahead and build for all the max versions 2013 and up. Depends on if people need/use it.

Most forthcoming changes will be fixes/optimizations and features that I require for advancement of my personal citrus project.

 

If I have time way way into the future it'd be nice to consolidate my plugin features/fixes with figments and ehamloptirans work and put it all together into the niftools git.

[Farmthat]

Hey, I just getting into modding and found this by accident. 

 

Early on, you mentioned NiGeomMorpherController. I know it crashes Skyrim, but is there any conceivable fix for this? can NiTransformController handle the same information, or are morph animations an entirely lost cause?

[blabba]

No idea, there probably is a way to make vertex animations do-able in skyrim.

 

Just nobody has figured it out yet.

 

[bobstersser]

Caw Caw.

 

Would bump for a 3DS Max 2016 version.

 

Back in 2014, I gave up on ever trying to actually animate for Skyrim/Fallout cause of the horrible complex and brainswirling Havok system. I have tried the .nif plugin with 2012, but also trying to keep up with the times (I love new and updated software, even if it breaks everything cause NEW AND SHINY :DD:D:D)

 

Gotta go install 3ds max this weekend. Fugg where is animation motivation when you want it!

[AlluringAnkh]

long term plans:

I'm still sticking to Skyrim as I have no interest in the Fallout series. (If you care about fallout, I highly suggest looking at figments builds that he posts on nexus or on his git!)

I'll still be sticking to 3dsmax 2014, I'll build for 3dsmax 2017 when it comes out in March 2017 .

 

Why not the 2016? its the one with the most radical updates since max 2013. I do not think 2017 will reinvent the wheel like 2016 did.