Jump to content

Mesh Rigger (Skyrim, Fallout, Oblivion) Beta.89.f (10-26-2014)


Recommended Posts

@gerra6

 

Here are a few of the nifs that were blowing up. Many other ones are the ones found on modtype and are the newer 7BASE body ones.

 

 

 

 

Some of the bodies blew up some didn't appear in nifskope like the jianling and witch body till after they were ran through the mesh rigger one of the pants works while the other has something wrong with it the suspenders I can't remember if they blew up but I do know that they do not show up in game non converted or converted.

 

Body template

 

 

Link to comment

I have a question I recently converted the spriggan armor to 7BASE TBBP. The body used in the armor is CBBE and I had to use the CBBE body in the armor for the to nif as I am not sure what CBBE body was used to make the armor and since I am not sure what body was being used I just did it this way so that the smooshed/molded/dented parts didn't get popped out. I switched the texture path for the CBBE bodies to match the 7BASE texture path and then when I ran clothing converter I would be able to use the UV map part.

 

The conversion came out pretty good other then a minor hip thing. My main question is that is it possible for the mesh rigger to redo the the bodies textures so that they match the 7BASE body instead of the CBBE body? The only spot that the textures are off are the breast areas. Or would I have to try to manually move the UV vertices so that they match better? This is what they look like ATM the textures for the nipples and side of the breasts are off but everything else is great.

 

 

post-25667-0-50750300-1416205714_thumb.jpgpost-25667-0-71678000-1416205728_thumb.jpgpost-25667-0-86033300-1416205742_thumb.jpgpost-25667-0-97244800-1416205756_thumb.jpg

 

 

 

 

 

 

 

Link to comment

You definitely don't want to use the UV search if the bodies follow different UV map standards.

 

Nothing to be done about that, really.

 

You're pretty much stuck with the default search function (vertex to surface search).

 

There's a chance that I'll have a UV converter built out someday complete with a UV conversion library, but don't hold your breath for it.

 

Although...I've just finished one of the nastiest bits of code surrounding that project..the seam cutter. So I now have the ability to have my framework automatically cut a new UV seam in an existing mesh.

 

So...progress is being made.

Link to comment

Well I tried it without UV map  when converting the spriggan armor and it looked worse then it did when I used UV map.

 

Working on a different one atm. Hermaus armor.

post-25667-0-17654000-1416358790_thumb.jpgpost-25667-0-45940500-1416358903_thumb.jpg

 you are porabably saying other then the stretching armor the body looks good.

post-25667-0-50488400-1416359002_thumb.jpgpost-25667-0-76355000-1416359121_thumb.jpg

 How about now? Not sure what is wrong with them just trying to add TBBP to them and I think I have tried many different combinations. The above happens with 2 of the armor sets in the mod the third not sure on I ran it through the converter fine but haven't thrown it into the mesh rigger yet. I think the smaller ones textures are a bit off so maybe that is the cause of that one but the other one looks fine and not sure if that would be the cause of such weirdness.

 

*edit seems the converted one that I converted also has that flaw as well.

 

herm1pc_0.nifhermskinnyf_0.nif one of each of the nifs femalebody_0UNPB TBBP.nif body nif used.

 

 

Link to comment

took me a while to figure out what you meant by save folder lol. anyway, here's the log and cfg. I bet I did something wrong, I just don't know what...

 

meshrigger.log

 

 

('skin', 'All Materials')
('version', 'b_90')
('Game', 'Auto')
('select_meshes', False)
('delete_partitions', False)
('select_bones', True)
('template_s', 'Mesh Rigger/template/')
('delete_weights', False)
('Tool', 'MESHRIGGER')
('name', 'MeshRigger_Options')
('bone', True)
('flatten_skin', False)
('gender', 'Both')
('subfolder', 0)
('copy_havok', False)
('replace_weights', True)
('update_version', 0)
('target', "('C:/Program Files (x86)/Steam/SteamApps/common/Skyrim/Mod Organizer/mods/Elite Rogue Armour UNP-UNPB All-in-One Retexture/meshes/armor/EliteRogue/er_torso_innerfbl_0.nif',)")
('v_index', False)
('delete_rigging', False)
('override', True)
('Targets', 1)
('destination', 'Mesh Rigger/output/')
('skeleton_links', 0)
('uv_search', True)
('Distance', 20.0)
('template', "('C:/PyFFI-py3k/Mesh Rigger/template/scarletdawn_torso_0.nif',)")
('C:/PyFFI-py3k/Mesh Rigger/template/scarletdawn_torso_0.nif',)
morph_key 0
dirpath ('C:/PyFFI-py3k/Mesh Rigger/template/scarletdawn_torso_0.nif',)
Checking Directory Path for Nifs and Tri files
No valid template found, Exiting
Traceback (most recent call last):
  File "mesh_rigger.py", line 343, in <module>
    input('\nWork done, press enter to close.')
AttributeError: 'Logger' object has no attribute 'errors'

 
meshrigger.cfg

version=b_90
name=MeshRigger_Options
Distance=20.0
Game=Auto
Targets=1
Tool=MESHRIGGER
bone=True
copy_havok=False
delete_partitions=False
delete_rigging=False
delete_weights=False
destination=Mesh Rigger/output/
flatten_skin=False
gender=Both
name=MeshRigger_Options
override=True
replace_weights=True
select_bones=True
select_meshes=False
skeleton_links=0
skin=All Materials
subfolder=0
target=('C:/Program Files (x86)/Steam/SteamApps/common/Skyrim/Mod Organizer/mods/Elite Rogue Armour UNP-UNPB All-in-One Retexture/meshes/armor/EliteRogue/er_torso_innerfbl_0.nif',)
template=('C:/PyFFI-py3k/Mesh Rigger/template/scarletdawn_torso_0.nif',)
template_s=Mesh Rigger/template/
update_version=0
uv_search=True
v_index=False
version=b_90

 

Link to comment

It doesn't like the template file you selected.

 

Generally that means that either the specified file was not found at that location, or that pyffi spat out the specified file as inedible. That is, for one reason or other, the selected template file could not be parsed. This generally means that the file is corrupted in some way that causes the pyffi parser to error out.

Link to comment

It doesn't seem to want to work with any mesh. Maybe it has something to do with the difficulty I had installing it, or the fact that I use mod organizer.

 

I used to use an older version to just convert armors/clothes to have bbp, do you have any other programs that would be capable of doing that as easily?

Link to comment

Send me the files you were working with (template and target). I'll see if I can get them working.

 

Anyways, if the installation did not go smoothly, there is a chance that your install of pyffi is not fully functional, which could certainly cause that problem.

 

Try the portable version of the tool. That comes fully loaded with everything needed to make it run properly. The only drawback is that it will run in 32 bit mode. For the most part, this won't make any difference. However, some meshes with lots and lots of geometry blocks with very high vertex counts may cause the 32 bit version of my tool to crash with an out of memory error.

Link to comment

How do people usually convert clothing from Skyrim to Oblivion?

 

I usually pose convert >

Import+export as obj (to get rid of new nifskope structure and skyrim mesh information) >

copy relatively similar skin instance to block details >

run through mesh rigger using template that most mirrors the way I want the mesh to act (uv search off, select bones, select meshes to weigh, remove bones , remove wieghts)

 

^this method is hit and miss, but it has helped me and it's my best non blender option.

 

 

...also, what's the rigid option in the mesh select window for?

Does it connect the mesh to the bone, but not cause it to warp  with the bones movement? or does it simply ignore that mesh?

Link to comment

Rigid is for if you don't want something to move like say you have a chest plate you set it to rigid so it doesn't bounce.

Pretty much.

 

Rigid is still a bit of an experimental algorithm. Basically, when a given mesh is selected to be 'rigid' it divides the mesh into 'islands' of mutually reachable vertices. That is, if a given mesh is a single unbroken breastplate, it will be treated as a single island. If the mesh is instead made up of several separable elements, say armor plates that are not connected on a vertex level, each 'island' will be weightpainted separately.

 

Here's where things get fun. When 'rigid' is selected, every vertex in a given island receives identical weightpainting. In-game, this means that any given island won't deform. It can move, but every vertex in that island should move in an identical way.

 

This is good and bad. Chances are that the rigid mesh will be covering a non-rigid body. So...if that non-rigid body gets enough deformation, it can clip through the rigid mesh.

 

It's experimental, more the product of a thought experiment with very little in-game testing on my end (like much of my stuff, I tend to have enough time to either code or test this stuff in-game, but rarely both)

Link to comment

Do those improper rotation errors also affect body placement after running through them mesh rigger? I converted a armor I saw the rotation errors but waited to see how it would look some come out great while others get destroyed. It can out nice very minor clipping that can be fixed easily in nifskope. I then threw it into mesh rigger the first time I tried it with override vertice index and UV  copy and delete select and replace bones and havoc on 2nd time I tried it with UV off in nifskope it looks fine but when you put the armor on the armor is shifted forwards almost to where the head and body are not touching. 

Link to comment

That's extremely likely.

 

Basically, when pyffi throws an 'improper rotation error' it's generally warning you that either the NiNode or the skinned bone (the bone transform record in the skin data block) has a bone that will not properly deform a skin.

 

Math Time

 

 

 

OK there are three basic methods used to handle rotation transformations in 3D modeling. Eulers, Quaternions, and Rotation Matrices.

 

Eulers are by far the easiest for humans to understand, but are super mega crappy from a computational point of view. It's just three angles defining a rotation along the X, Y, and Z axis. Note: the order of rotation is *extremely* important. And Eulers can suffer from Gimbal lock, which is also annoying.

 

Quaternions are the most computationally robust and stable, but are a bit difficult for humans to intuitively understand. In essence, they are a 4 dimensional vector describing a rotation along the X, Y, Z, W axes, where the W axis defines the axis of rotation used by the X, Y, and Z rotations.

 

Rotation Matrices are the most convenient from a programming point of view. They are 3x3 matrices that, when multiplied by a vector, effectively rotate that vector. They can also be easily combined with scale and location transforms to form a nifty 4x4 matrix which makes calculating transformations on a given vertex extremely simple. Since they are matrices, you can also do lots of useful linear algebra transformations with them. And they're relatively fast.

 

*However* although all rotation matrices are 3x3 matrices, not all 3x3 matrices are rotation matrices.

 

Any rotation matrix must have two very important characteristics. The first is that it must be fully invertible. This simply means that, given matrix A, there is another matrix B such that A * B = Identity Matrix ((1,0,0)(0,1,0)(0,0,1))

 

Why is this important? Well, it means that any transformation performed by that matrix is fully reversible. It is also *extremely* important for skinning. I'll explain why in a bit.

 

Any rotation matrix must also have a determinant equal to exactly 1.0 (within Epsilon error bands, at least).

 

Why? A determinant of 1.0 means that the matrix won't modify the magnitude of any vector that it is rotating in any way. Any other determinant can lead to all manner of unpleasantness.

 

Probably the nastiest bad determinant are a pair of bones in the X-32 (or whatever it's called) skeleton that have determinants of -1.0. This means that any vertex rotated by those bone are first flipped and then rotated. Not fun.

 

OK...so let's say you have a bad rotation matrix, which means that it is not properly invertible. 'So What' you may ask.

 

Well, if the bone is not invertible, you can't skin with it. Simple as that.

 

Basically, when you skin a mesh, one of the first steps is to generate a bind position for every bone that you are adding to the skin. The bind position can be thought of as the bone's home...when the bone is home, it shouldn't be deforming or animating the mesh in any way. When the bone is animated, you need to ensure that any deformations caused by that bone are strictly relative to that bone's home.

 

So how do you tell the mesh what a bone's home is? Well, in the simplest and most common case, you invert the NiNode's transformation matrix and set that as the transform of the bone record in the Skin Data Block. This is the Skinned Bone Transform

 

Later, when my or some other tool attempts to calculate that bone's contribution to any current skin deformation, it muultiplies the Skinned Bone's transform by the NiNode's (bone block) transform.

 

If the bone is not currently animated, then that bone's contribution to any current skin deformation is an identity matrix. If the bone is currently animated, then you end up with a matrix that transforms any weighted vertices in some way, given by the difference between the bind and animated transforms of the bone.

 

If a bone has a bad rotation matrix, then none of that works properly.

 

 

 

 

Bad skinning can cause all sorts of nasty problems that can show up in all sorts of ways and cause all sorts of different problems.

 

The next version of Mesh Rigger will have the ability to ignore all pre-existing skin deformation. It will also have a mode to detect any ni-wide seam offsets compared to a template (compare wrist, neck, ankle, etc seams) and automatically move the mesh into proper position.

 

The next version is a bit delayed, I'm adding a mountain of seam-mender related code that is slowing things down a bit, and I don't have as much coding time as I usually do, but hopefully we should get something soon.

Link to comment

That is what I thought at least it has really good boob jiggle I only tried it on the armor because I changed out my players body files and replaced them with the armor nifs and last night I removed them and put my players body back in and found out my player was pregnant and I was like WTH I thought it had a belly node so I checked and it didn't and I knew it had errors when I converted it but was hoping for the best.

 

Cool take your time no hurry.

Link to comment

I'm having a little problem with mesh rigger.

 

I'm trying to run mesh_rigger.py on 64bit python and Win7 64bit. The meshes I want to add weights to are Skyrim UNP .nifs. To be precise, I want to copy breast and belly properties from the Pregnant-Scaled UNPB mesh to the UNP 1dot2 mesh, and then copy the parameters of the output mesh to entire batches of UNP clothing.

 

I had decided to make a few test runs before having my rig work with numbers throughout the night, and I had soon found out that the tool won't work on my setup. No matter what combination of templates, targets and settings I use, regardless of body type family (I even tried copying stuff between identical meshes), the program always ends up in a cycle of doom, grabbing an extra 0.02 GB of RAM each second until it consumes all system resources. The stage at which it always fails this way is when the line reads "searching for Targets"

 

Any thoughts on how to fix this before I get mad and resolve to manually weightpanting gigabytes of meshes during the holidays?

Link to comment

Send me the files. I'll take a look.

 

***edit***

 

Please also send me the .log and .cfg file. I'd like to see what's happening when the tool chokes.

 

If you haven't tried this yet, test the 32 bit portable version of the tools. If that works, and the stand-alone version does not, then something may potentially have gone wrong in your pyffi installation.

Link to comment

I know this may be a stupid question to those more familiar with the programs but how am I supposed to get the pyffi 2.2.2 to install with python 3.4 as is stated on the first page. The only version of python I can get to work with the mesh rigger is python 3.2 with the pyffi 2.2.2. I've also tried to get the portable version to work but installation instructions on the main page seem to be leaving out some requirements or something. Any help would be appreaciated.

Link to comment

I know this may be a stupid question to those more familiar with the programs but how am I supposed to get the pyffi 2.2.2 to install with python 3.4 as is stated on the first page. The only version of python I can get to work with the mesh rigger is python 3.2 with the pyffi 2.2.2. I've also tried to get the portable version to work but installation instructions on the main page seem to be leaving out some requirements or something. Any help would be appreaciated.

First, don't use the python version unless you really need it for some reason - the portable version works fine for everything.

 

Be sure you start with V.0.89.e - anything more recent is an update. Extract V.0.89.e into an empty folder (I use one named KGTools) and then extract the most recent update into the same folder.

 

From there, running any of the batch files will launch the python app, which will then create any needed sub-folders.

 

Let us know if you have any trouble with it.

Link to comment

 

I know this may be a stupid question to those more familiar with the programs but how am I supposed to get the pyffi 2.2.2 to install with python 3.4 as is stated on the first page. The only version of python I can get to work with the mesh rigger is python 3.2 with the pyffi 2.2.2. I've also tried to get the portable version to work but installation instructions on the main page seem to be leaving out some requirements or something. Any help would be appreaciated.

First, don't use the python version unless you really need it for some reason - the portable version works fine for almost all purposes. Just extract it into an empty folder. (I use one named KGTools) From there, running any of the batch files will launch the python app, which will then create any needed sub-folders.

 

Let us know if you have any trouble with it.

 

 

After going through everything again and again, I finally realized what was wrong. I was trying to use the latest version of Mesh rigger from the download page but failing to realize that all but the very bottom ones are simply update files for the one at the very bottom of the list. Didn't click with me to keep checking further down the list when the files were only getting older. Now I feel stupid. Thanks for the help though.

Link to comment

 

Send me the files. I'll take a look.

 

***edit***

 

Please also send me the .log and .cfg file. I'd like to see what's happening when the tool chokes.

 

If you haven't tried this yet, test the 32 bit portable version of the tools. If that works, and the stand-alone version does not, then something may potentially have gone wrong in your pyffi installation.

 

 

My intent is to copy the BBB weighting from UNPB pregnant-scaled to base UNP 1dot2 (both at weight 0), test it in-game, make some adjustments if nescessary, and then copy the weighting from the output UNP body to a few hundred UNP meshes. Tried to do it both on python 3.2.5 and on the portable version, but both end up doing nothing and completely using up my system, if I let them run for an hour, they even go as far as making the keyboard and mouse unusable.

 

 

 

 

**edit**

the lattice tool works completely fine, by the way.

Link to comment

Thanks.

 

OK, here's what's going on and how to fix it.

 

1. Override Distance is enabled. For some crazy reason, I have this defaulting to on. This is a *slightly* dangerous setting and is the one causing problems in this instance. Basically, Override Distance tells the tool to ignore search distance limitations and find a target *no matter what*. This would be fine, except the tool is optimized for relatively short distance searches. When the search distance gets too great, things get *ugly*.

 

2. The target meshes include hands and feet, but the template meshes do not.

 

To fix your issue, simply include appropriate hands and feet nifs in your template folder and be sure to select them among your template nifs when you run the tool.

 

Also, disable 'override distance'.

 

Now, I may be updating the search engine with something that will do a better job with medium and long distance searches in the future. I haven't decided how I want to implement it yet. In the meantime, disabling override distance and ensuring that any body parts you are weightpainting are represented in the selected templates should avoid the out of memory problem.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use