New Clothing Body Style Converter Beta v0.89f (10-26-2014)

[gerra6]

OK, I've taken a look and generated some test lattices and applied them on the test meshes.

results.7z

The baseline body conversion looks good. It's a more or less flawless conversion of the SUI body to the unpb_awesome.

The cleavage in the robe, however, looks pretty awful, and there's probably not much Clothing Converter can do about it.

Take a look at the original mesh. The original robe has a fold between the breasts, where the two sides meet and wrap around each other. So, what happens when Clothing Converter converts the relatively narrow cleavage to the wider-set bust in the unpb_awesome nif?

Well, for each vertex the tool finds the nearest point on the surface of the lattice and applies an appropriate transform. With this particular conversion, this means that parts of the robe on the right side will get shifted to the right, and parts on the left side will get shifted to the left.

The net effect will be some very nasty stretching and distortion to that part of the robe.

There's not much that can be done to fix it within the tool itself. This is essentially the 'cleavage crash' issue that pops up in this thread from time to time.

About the only thing that you can do is run Convert Clothing with 'customize meshes' enabled and disable x-axis movement for the hakama and make any necessary sculpting adjustments in a 3d modeling program.

Here's what that looks like

suitorso_0.7z

Same lattice, same conversion, just x-axis movement has been disabled for the Hakama, but not the base body.

Is it perfect? Nope. But it is an improvement.
 

Original

 

Converted Outfit

 

Converted Outfit, X-Axis constrained for Hakama

[foreveraloneguy]

Well, the question remains why I get the results I do. And by that, I'm referring to the teleporter accident. And, since you probably need more precision in the description than that, when I create a lattice and do the conversion, I end up with a mesh with spikes sticking out in all directions and the body and armor mixed together. You did not get those results. So something is amiss somewhere. Also, again, if I use a lattice created with a previous version, I get results much as you do. The problem is when I create a lattice with .89f and use that lattice for the conversion.

[Supierce]

Well, the question remains why I get the results I do. And by that, I'm referring to the teleporter accident. And, since you probably need more precision in the description than that, when I create a lattice and do the conversion, I end up with a mesh with spikes sticking out in all directions and the body and armor mixed together. You did not get those results. So something is amiss somewhere. Also, again, if I use a lattice created with a previous version, I get results much as you do. The problem is when I create a lattice with .89f and use that lattice for the conversion.

When making your lattice, uncheck the Vertex Index Search button. I had the same problem.

[gerra6]

 

When making your lattice, uncheck the Vertex Index Search button. I had the same problem.

 

 

Doh!

 

The vertex Index search is a bit less strict than it was in 89.e.  It behaved properly in testing, but it sounds like I should revert it for the next update.

[foreveraloneguy]

 

Well, the question remains why I get the results I do. And by that, I'm referring to the teleporter accident. And, since you probably need more precision in the description than that, when I create a lattice and do the conversion, I end up with a mesh with spikes sticking out in all directions and the body and armor mixed together. You did not get those results. So something is amiss somewhere. Also, again, if I use a lattice created with a previous version, I get results much as you do. The problem is when I create a lattice with .89f and use that lattice for the conversion.

When making your lattice, uncheck the Vertex Index Search button. I had the same problem.

 

 

That was the trick. Much thanks.

[gerra6]

I did a bit of experimentation and I believe I have a partial solution to the cleavage crash issue with that particular mesh.  

 

It's a bit complex, but the final results aren't bad

 

Original

 

Standard Conversion

 

Single Lattice, X-Axis Constrained

 

Multi-Setp, Multi-Lattice Conversion with complex constraints (see instructions)

 

Here's the process:

 

1. First generate a lattice that will convert BodyA into BodyB.  UV Search is Enabled.  Skin Only is Enabled.(Lattice 1)

2. Run Convert Clothing on BodyA with Lattice 1.  Constrain X-Axis should be Enabled on the main page.  This is BodyAX

3. Generate a lattice that will convert BodyAX into BodyB.  UV Search is Disabled.  Skin Only is Enabled.(Lattice 2)

4. Run Convert clothing on BodyA with Lattice 1.  Enable Customize Mesh. This is BodyAB1

4.a. When prompted,  enable Constrain X-Axis on any clothing or equipment meshes but not skin/body meshes.

5. Run convert clothing on BodyAB1 with Lattice 2.  Enable Customize Mesh.

5.b When prompted, enable Constrain X-Axis, Constrain Y-Axis, and Constrain Z-Axis on any skin/body meshes.

 

I know it's weird.  It's a dual lattice conversion with multiple axial constraints.  But the results are pretty good.

 

[foreveraloneguy]

Dude, that's awesome. I'll have to try that. But, uh, I just spent a couple hours dicking around in body studio and was able to mostly fix the few problems left after running through the mesh rigger, then putting the original body in the mesh and adjusting the armor. Still, your way looks better than what came out at the end, so just some minor tweaks and good to go.

 

Maybe this method will also finally let me get a good conversion of the Nighthawk 7B Cleavage version over to my body. Been trying that one for a couple weeks, and the corset section always comes out very distorted. I did find that constraining both x and y axes prevent the distortion, but what comes out is basically the 7B  body with smaller boobs. But I'll keep working with it.

[gerra6]

OK...late night, trying to sleep, can't stop the brain from thinking, planning, etc.

 

Dumb brain.

 

Anyways, I think I've figured out a way to generate a lattice that will automatically incorporate the cleavage clash solution I utilized in the above post.

 

On the end-user side, it will be available as a toggleable option when running clothing converter.

 

I'll see if I can bash it out tomorrow.

[Monsto Brukes]

thanks for coming back to this, gerra.

 

 

[foreveraloneguy]

Hmmm... I'm pretty much at my wits end on this one. Have tried every variation I can think of to create a lattice, but all I'm getting out of the converter is transporter accidents. I've even tried reverting back to 89e to see if that made any difference. Didn't seem to make things better, or even much different. Here's the meshes. I did notice one thing in the log for the lattice though.

 

Main Search

search_targets 1

Template Vertices: 3634

search_resolution 1

Building Vertex Dictionary

Target Mesh Vertices 3580

 

The thing is, both these bodies have 6850 verts. It's sevenbase to unpb, more or less.

 

temp.7z

[Monsto Brukes]

 

Hmmm... I'm pretty much at my wits end on this one. Have tried every variation I can think of to create a lattice, but all I'm getting out of the converter is transporter accidents. I've even tried reverting back to 89e to see if that made any difference. Didn't seem to make things better, or even much different. Here's the meshes. I did notice one thing in the log for the lattice though.

 

Main Search

search_targets 1

Template Vertices: 3634

search_resolution 1

Building Vertex Dictionary

Target Mesh Vertices 3580

 

The thing is, both these bodies have 6850 verts. It's sevenbase to unpb, more or less.

 

temp.7z

 

 

The big problem I had was was with trying to do more than one lattice at a time. once i made 1 lattice each for _0 and _1, everything was golden.

 

 

Here's a super high poly mesh that is about 98% . . . it's like 17k verts and it came out better than I expected.

 

here's some shots of before, proof of needless high poly, and after.  I'm not concerned about fixing it (i can live without it tho it's pretty slick) I just wanted to show it off.

[foreveraloneguy]

I always make separate lattices for _0 and _1. I'm starting to think it's something to do with the mesh itself, though I haven't a clue what that would be. What I put in the zip file was the best result I got after about 5 hours of trying to get a decent conversion. I even tried older lattices but got equally bad results.

[gerra6]

I always make separate lattices for _0 and _1. I'm starting to think it's something to do with the mesh itself, though I haven't a clue what that would be. What I put in the zip file was the best result I got after about 5 hours of trying to get a decent conversion. I even tried older lattices but got equally bad results.

Well. There's something seriously jacked in that Beltgirl nif.

 

It looks like my tools are having an extremely tough time calculating a common worldspace between the nifs, which can make things get extremely ugly very quickly.

 

It looks like the skinning on the Beltgirl nif is probably the problem.

 

In particular, the skinning shows a bonelist with 216 bones, on a nif rigged with a total of 24 bones.

 

That's a pretty big issue. You could try deleting the BSDismemberSkinInstances in nifskope and then re-rigging the nif in Mesh Rigger. I wouldn't try re-rigging it without manually deleting the BSDismemberSkinInstance first, however, as my tool does not appear to be playing nicely with the very jacked skinning in that nif.

[foreveraloneguy]

Yeah, that mesh is on crack, as are all of them, since they all do exactly the same thing. I did a rerigging through mesh rigger, and the body exploded. So definitely something very whack. But for whatever reason, after I just pull the mesh into outfit studio then export the nif again, it looks fine.

 

And since that was the case, I went ahead and made a new lattice and did another conversion. The output needs some work, but it's a usable starting point.

[gerra6]

I'm going to take a look at what's happening on the back end as my framework processes that mesh soon as I get the chance.

 

It's probably related to that bone list. My tool makes the assumption that there is a 1:1 relationship between the bone list and the skinned bones.

 

The fact that some tool, somewhere managed to tack on a bunch of extra bones (easy to do, but very much under the why the hell would they do that category) is not something that I had factored into the design of the tool.

[Symon]

I might be able to shed some light on 'redundant unrigged bones'. I see them in many, many Oblivion meshes and removing them is excellent practice whatever you intend doing with the mesh..

One of the sources would appear to be one of the 3DSMax exporters.

Another might seem to be the Modder's chosen workflow.

 

In any event, it is easy to deal with in NifSkope. Just apply the 'spell' remove bogus nodes and save.

 

Might be worth a try with your troublesome meshes here?

[gerra6]

This is a little bit trickier.

 

These aren't orphan NiNode bones. They're not even extra Skinned Bone References.

 

These are additional records referencing non-existent bone transforms in the skinning record itself.

 

Ordinarily, these records are used to apply an inverse transform that, when combined with the skin transform and the NiNode transform, determines the bind transform applied to any vertices weighted by that bone.

 

So, since my tool expects the skinn bone transform record list to match the skinned bone record list, it appears to be bugging out in a fairly ugly way when the two lists fail to match.

[Symon]

I understand the problem now. I seem to remember you saying once how....strange... it was the way Skyrim meshes were handled. My fault, I've never been tempted by the game.

 

So if I understand correctly, they do nothing(?), make no sense but are difficult to cull?

[gerra6]

They should be fairly simple to cull.

 

Just a matter of rebuilding the skinning should do it.

 

Warning: Programming Sausage Making Ahead

 

 

 

 

The reason it is a problem for my tools is that they do a ton of work to convert the vertex space local coordinates of each vertex into the world-space coordinates.

 

So, for each skinned bone, the tool first needs to calculate the bind transform, that is, what transform will be applied to any vertex weightpainted with 100% with that bone.

 

That is given by (Linear Algebra Matrix Multiplication, Order is *important*):

 

[skinned Bone Transform] * [NiNode (bone) Transform] * [skin transform] * [geometry object transform]

 

If a given vertex is weightpainted by more than one bone, the bind transform applied to that vertex will be relative percentages of the transforms of each bone that affects the vertex.

 

Now, one of the things that my tool needs to do is calculate the vertex positions as if the mesh was rigged with the template mesh skeleton instead of the target mesh skeleton.

 

That looks like this

 

[skinned Bone Transform] * [NiNode (template bone) Transform] * [skin transform] * [geometry object transform]

 

Almost identical. Only the bind transform of the NiNode needs to be changed. In fact, this is also what happens when the mesh gets animated. That second transform is the only one of the four transform matrices that is changed.

 

OK, so what is going wrong when my tool attempts to do these calculations in a mesh where the number of skinned bone transforms does not match the number of skinned bones. Well, that is probably due to this line in my code here.

 

for bone, b_data in zip(self.skin.bones, self.skin.data.bone_list): 

This is a handy little bit of code that just takes the two arrays and iterates through them sequentially and in order.

 

OK...So, what happens if the self.skin.bones array is shorter than the self.skin.data.bone_list array? Well, once it gets to the end of the self.skin.bones array, the zip function keeps pairing the last entry in the self.skin.bones array with every subsequent entry in the self.skin.data.bone_list array.

 

This means that one of the bones in the mesh is ending up with the incorrect [skinned Bone Transform], in the case of that mesh, it ends up with an identity transformation matrix. Why is this relevant?

 

Well, when you skin a mesh with a NiNode (bone), if you don't want the vertex to be deformed or moved in any way, it is standard practice to set the transform of the skinned bone to the inverse of the transform of the NiNode so that when [skinned Bone Transform] * [NiNode Transform] is calculated, you end up with an identity matrix.

 

If instead, the [skinned Bone Transform] is the identity matrix, you end up with [NiNode Transform] * weighting applied to every vertex weighted to that NiNode.

 

 

Didn't sleep last night...was baking lots and lots of San Francisco Sourdough. So that's probably why I am boring you with this very long winded, very technical explanation of the sausage making.

[Monsto Brukes]

OH I forgot to mention . . . when running converter on the black widow up there, python peaked at over 6gb ram usage . . . and nothing fell apart.

 

While you might not be getting the output you want, at least it's stable under stress. (=

 

Thought I'd mention.

[gerra6]

OK. I've uploaded a new version of Clothing Converter to my development site

 

The tool no longer turns stupid if the number of skinned bones doesn't match the length of the skinned bonelist. Tested on the Beltgirl nif. Looks like solid results.

 

http://kgtools.org/

 

v.0.89.f to v.0.89.g

1. Improved error handling. Crashes should now be properly recorded in log file.

2. Console pause added. Console should now wait for user input before closing at completion of tool or during error out. (Thanks Movomo for the implementation)

3. Excess skinned bones on a single skin instance will no longer cause distortion or other problems.

4. Vertex Index search reset to 'strict' mode.

[ger4]

I'm getting this bug when launching the latest version of clothing converter (64 bit version)

 

http://s8.postimg.org/p8x973nw5/bugs.png

[movomo]

Ger4, do you have any python 2.x installed? for example for blender 2.49b?

If so, it's possible that your system is trying to run them with python 2.x. In this case open up the script and insert this on the top of the codes:

#!python3

[ger4]

Ger4, do you have any python 2.x installed? for example for blender 2.49b?

If so, it's possible that your system is trying to run them with python 2.x. In this case open up the script and insert this on the top of the codes:

#!python3

Yep, that worked.

 

Thanks Movomo

[gerra6]

Ger4, do you have any python 2.x installed? for example for blender 2.49b?

If so, it's possible that your system is trying to run them with python 2.x. In this case open up the script and insert this on the top of the codes:

#!python3

 

Ooh. I'll add that to the next revision of the package.