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

[Monsto Brukes]

I had an idea re: declipping

 

I have to assume at this point that you can detect whether an existing vert is inside or outside. Therefore, the hard part is determining if an outfit edge between verts clips the body at some point. The solutions are relatively simple -- add outfit verts, hide polys from the body, turn edges, etc. -- but my idea is about getting TO that point.

 

Crawl the edge with a temporary or virtual vertice, and then check it's position. 

 

A "detail" setting could determine how many iterations you use to crawl the edge. Once the clipping point is found, send the edge to the "solution" subroutine. This would clearly multiply the time that the converter takes, depending on hardware. It's probably something that you could multi-thread. 1 or 2 iterations would likely be enough for most people and would likely catch 90% of clip instances. 10 (or more) would theoretically get closer to perfect.

 

 

Even so, is declipping a process that's worth it?

it's a static catch is it not? Default position body mesh with a default position outfit. walking could bring on a whole new set of problems. Unless you were willing to crawl edges on frames of animation, there's liable to be relevant clipping somewhere.

 

In other words, there's going to have to be some heavy handed declipping... translating verts by X pixels away from the body, deleting polygons, things like that... so could the entire process be skipped in favor of just allowing the user to implement with a check box?

[Monsto Brukes]

 

The earlier versions of Clothing converter tended to choke if a nif contained multiple meshes with incompatible skinning, or meshes with skinning incompatible with the bones in the nif. Very bad things tended to happen.

 

This latest update should fix those types of issues.

 

Incompatible UV maps will still cause problems if UV Search is enabled, but hopefully that issue will be resolved once I finish work on my automated UV converter.

 

In the meantime, here's

 

Clothing Converter Beta 46

 

ChangeLog:

 

45 to 46

1. New option added to Convert Clothing: 'Don't Cross X-Axis'. When enabled, it will not allow any vertex transforms to cross the x-axis. This eliminates the 'vertex crash' that otherwise occurs when cleavage collides.

2. Vertex Normal Calculation code improved: Re-calculation of vertex normals will now automatically mend seams caused by vertex doubles (i.e. along UV seams).

 

42 to 45

1. Significant Improvements to the back-end vertex matching algorithm. This should result in notable improvements to many former problem areas

2. Significant Improvements to the ability of the tool to work with meshes with unusual bone and/or skin transforms.

3. Elimination of 'wayward vertex' problem when converting meshes with bad or incompatible skinning.

Download:

 

Portable Package (all in one): Convert Clothing b_46.7z

Scripts Only (Requires separate Pyffi and Python 3.x install): Convert Clothing b_46_Light.7z

 

Please let me know how this update does.  If reports are positive, I'll update the front page with the new version.

Latest beta crashes during lattice generation with this error (I know is hard to see the text, but the window closes too quickly to get a proper capture).

 

Edit - Here's a better version

 

Traceback (most recent call last):

  File "C:\Users\User\Desktop\Convert Clothing b_45\Convert Clothing b_46_Light\make_lattice.py", line 180, in <module>

    Main()

  File "C:\Users\User\Desktop\Convert Clothing b_45\Convert Clothing b_46_Light\make_lattice.py", line 113, in Main

    from_nif = file_util.load_nif(cs.get('template'), init_skin = False, init_mesh = True)

  File "C:\Users\User\Desktop\Convert Clothing b_45\Convert Clothing b_46_Light\kg\file_util.py", line 417, in __init__

    self.mergeSkeletonRoots()

  File "C:\Users\User\Desktop\Convert Clothing b_45\Convert Clothing b_46_Light\kg\file_util.py", line 1269, in mergeSkeletonRoots

    r.set_transform(mat_i * r.get_transform())

AttributeError: 'NiBinaryExtraData' object has no attribute 'set_transform'

>>>

 

Capture.JPG

 

 

To catch screens of things like this, grab the title bar with your mouse at some point before the error. WHen the error pops, it'll stick around till you let go giving you time to get a shot.

[gerra6]

Even so, is declipping a process that's worth it?

it's a static catch is it not? Default position body mesh with a default position outfit. walking could bring on a whole new set of problems. Unless you were willing to crawl edges on frames of animation, there's liable to be relevant clipping somewhere.

 

In other words, there's going to have to be some heavy handed declipping... translating verts by X pixels away from the body, deleting polygons, things like that... so could the entire process be skipped in favor of just allowing the user to implement with a check box?

Nah, that's what Mesh Rigger is for.

 

If the rest-pose body has no clipping issues, and the entire nif has been re-rigged using my Mesh Rigger tool and a single high-quality template, animations shouldn't cause any intra-mesh clipping. That is, for example, a bouncing breast won't pass through the shirt due to an animation.

 

So...how does Mesh Rigger achieve this? Well, it does a couple of very important things. The first is unified weightpainting. Every vertex on the nif gets re-painted using the same template as a guide. The second is just as important...each mesh is re-skinned to be fully compatible with every other mesh in the nif.

 

Right now, it's possible to find mash-up nifs with multiple pieces of armor and clothing from different artists, each skinned using a different skeleton, and each weightpainted using a different weight-template. In-game, each mesh will respond to a given bone animation in a different fashion, potentially leading to clipping, distortion, and all sorts of ugly.

 

But, run that nif through Mesh Rigger, and each mesh will be re-normalized to respond to animations in a compatible way.

 

As far as the clip mending goes, I'm currently prototyping the new automatic clipping removal tool. So far its performance is a bit hit and miss...at this point, the tool can generally identify vertices from the outer mesh that are stuck on the wrong side of one of the inner meshes. Once they've been identified, The tool simply shifts the nearest inner mesh vertex along the inverse of its normal vector far enough to place it behind the outer mesh vertex.

 

All of that appears to be working well.

 

The problem right now is false positives. Lumpy surfaces are wrecking havok with the current iteration of my side detection algorithm and causing a number of correctly positioned outer mesh vertices to be detected on the wrong side of the inner mesh.

 

But, I think I know what I'm going to do to fix my detection algorithm. Here's the plan.

 

1. Start with a pair of vertices, an outer vertex and the nearest inner vertex.

2. From that, identify the inner face nearest the outer vertex. This also gives me a very useful vector from the center of the face to the outer vertex.

3. Find the projection of that vector onto the normal of the face

4. If the projection is negative, that vector is on the wrong side of the face.

 

So...that's the next bit of code I'm writing. Pretty basic trig compared to all of the linear algebra I've needed to slog through for the more recent updates. But I've had to rebuild my edge and face object code to accomodate the data I'll need from them. Almost ready for the next bit of prototype testing.

[gerra6]

Clothing Converter Beta 48

 

ChangeLog

1. An issue that could result in the Clothing Converter not modifying a mesh has been resolved:  The 'Exclude Edges' option in Clothing Converter's 'Edge Settings' menu had begun excluding all vertices.  This bug has been resolved, and the 'Exclude Edges' option should once again limit the tool only to non-edge seam vertices.

 

Download

 

Portable Package: 

Light Download (Scripts Only): Convert Clothing b_48_Light.7z

[Monsto Brukes]

Couple Tweak Suggestions:

 

1) I have NEVER BEEN A FAN of that modal-style directory chooser.

I have all kinds of windows shortcuts and libraries n shit for my various skyrim directories that are available in the sidebar of the normal file chooser. Most of the time, I don't even have to do that, as Recent Files goes right to it. The dialog you're using ignores all those various niceties and forces the user to drill-down all the way everytime. You've done a convenient thing by saving the last one, but if I need to change it I gotta start over. From the top. 

 

2) the Customize Mesh dialogs that pop during the render.

Can that data be gathered at the beginning then used later so that the render can run unattended?

 

Again, just suggestions. 

 

Additional information for your docs:

7.d. Padding: 1.0 unit is about 1.5 in / 4 cm on a normal sized player model. Clipping avoidance distances should start ~0.1

[gerra6]

Couple Tweak Suggestions:

 

1) I have NEVER BEEN A FAN of that modal-style directory chooser.

I don't like it either. It's a Tkinter thing. My decision to use Tkinter for the UI was driven by my desire to use a standard Python module that was as platform neutral as possible. But honestly, I kind of hate it.

 

It works...it's just...ugly and the file dialog, as you've noted, sucks. I'll see what I can do, but no promises. 

 

One thing that you can do is define a custom settings file. That will store all of your file paths and other settings and then apply them when it is loaded.

 

2) the Customize Mesh dialogs that pop during the render.

Can that data be gathered at the beginning then used later so that the render can run unattended?

Not a bad idea but it's a bit tricky.

 

Per-Mesh, there's not much I can do. I don't have access to the individual blocks until they've been loaded and processed, which takes a bit of time.

 

But I could add some generic options to the main menu, with the ability to set different options for skin and non-skin meshes (automatically detected during mesh processing by material/rendering properties).

 

7.d. Padding: 1.0 unit is about 1.5 in / 4 cm on a normal sized player model. Clipping avoidance distances should start ~0.1

Very handy. One of these days I need to write the help docs and add them to the tool.

[Monsto Brukes]

 

Couple Tweak Suggestions:

 

1) I have NEVER BEEN A FAN of that modal-style directory chooser.

I don't like it either. It's a Tkinter thing. My decision to use Tkinter for the UI was driven by my desire to use a standard Python module that was as platform neutral as possible. But honestly, I kind of hate it.

 

It works...it's just...ugly and the file dialog, as you've noted, sucks. I'll see what I can do, but no promises.

 

One thing that you can do is define a custom settings file. That will store all of your file paths and other settings and then apply them when it is loaded.

 

 

 

isn't that an abstracted call from the script/library to the os to show a file dialog? Or are you saying that the call is embedded in the library? I would think (hope) that there's a config change someplace where, even tho the library and script are platform agnostic, you could set some specifics for windows that would be ignored on other OS.

 

As a kinda philosophical argument,

 

 

I've never understood the desire for such a BROAD level of cross-platform development. 99.99% of people are running one of 3 OS. Anyone thats running Irix or plain-ole unix+xwindows or whatever else that can fit in that .01% are likely not going to be wanting to run your (rhetorical "your", not you specifically) program.

 

 

 

 

2) the Customize Mesh dialogs that pop during the render.

Can that data be gathered at the beginning then used later so that the render can run unattended?

Not a bad idea but it's a bit tricky.

 

Per-Mesh, there's not much I can do. I don't have access to the individual blocks until they've been loaded and processed, which takes a bit of time.

 

But I could add some generic options to the main menu, with the ability to set different options for skin and non-skin meshes (automatically detected during mesh processing by material/rendering properties).

 

"Advanced" and "Custom"

• "Advanced" allows entry of those parameters 1 time, and extrapolated those values to all uses.
• "Custom" pops for each mesh like it does now.

 

7.d. Padding: 1.0 unit is about 1.5 in / 4 cm on a normal sized player model. Clipping avoidance distances should start ~0.1

Very handy. One of these days I need to write the help docs and add them to the tool.

 

I wouldn't have a problem helping with it. When the time comes, I'd have to ask a bunch of questions and get at least a basic walkthru from you. Then i could write/format the docs.

 

As I'd said in the first post of the original HDT Support thread . . . bad docs are completely inexcusable. I mean seriously... people spend thousands of hours researching, designing and building version 1.0 of... whatever, and then can't be bothered to spend another 10hrs so that other people can actually use the tool and so they can avoid hundreds of hours of typing the same responses.

 

Pfft... more philosophy from monsto.

 

You've done a great job. I'll work on testing it on different kinds of outfits to see what shakes out. The couple I've tried it on so far have amounted to an average of probably 4.2/5 . . . but I need to do more with it

[gerra6]

I've now written some code into my test framework that allows me to fairly inexpensively calculate the nearest point on a face to a given vertex. I'm working on integrating it into the back-end framework, but if it works the way I think it will, it should eliminate the need for the 'High Resolution Search' or vertex search counts greater than 1.

 

No guarantees...but I believe that it will significantly improve the quality of the clothing conversion lattices.

 

Unfortunately I've hit a bit of a wall on my code for the declipping tool. I think the only real answer is going to be to directly detect triangle collisions.

 

I think I'll probably implement a variation of this approach: http://fileadmin.cs.lth.se/cs/Personal/Tomas_Akenine-Moller/pubs/tritri.pdf

 

It has some very nice clean and efficient checks to eliminate candidates. I'm thinking I'll use my existing vertex search engine to gather a list of vertices near a given target and then test the associated faces on one mesh for collisions with the associated faces on the other mesh.

 

Work work work.

[ger4]

I've now written some code into my test framework that allows me to fairly inexpensively calculate the nearest point on a face to a given vertex. I'm working on integrating it into the back-end framework, but if it works the way I think it will, it should eliminate the need for the 'High Resolution Search' or vertex search counts greater than 1.

 

No guarantees...but I believe that it will significantly improve the quality of the clothing conversion lattices.

 

Unfortunately I've hit a bit of a wall on my code for the declipping tool. I think the only real answer is going to be to directly detect triangle collisions.

 

I think I'll probably implement a variation of this approach: http://fileadmin.cs.lth.se/cs/Personal/Tomas_Akenine-Moller/pubs/tritri.pdf

 

It has some very nice clean and efficient checks to eliminate candidates. I'm thinking I'll use my existing vertex search engine to gather a list of vertices near a given target and then test the associated faces on one mesh for collisions with the associated faces on the other mesh.

 

Work work work.

The tool works now, but for some reason, some of the converted meshes have gaps around the arms like this.

 

shirt.zip

[gerra6]

The tool works now, but for some reason, some of the converted meshes have gaps around the arms like this.

 

shirt.zip

It looks like the vertices on different sides of a seam are finding different lattice node targets. Weird. Try increasing the number of vertex targets and the search distance.

 

Could you send me the before nif. I'd like to see if I can replicate those results.

[Symon]

Quick question. If you need to run mesh-rigger to correct weight-painting and clothing converter on the same meshes (e.g. a male->female outfit conversion), is there a preferred order of operations or does it not matter? I've not seen it mentioned.

[gerra6]

That's a tricky question to answer. It depends a bit on whether or not the meshes you are working with have rigging flaws.

 

Why is rigging important?

 

 

Well for skinned meshes, the actual worldspace coordinates of a given vertex depends on the skin transform, the skinned bone transform, the bone transform, the geometry block transform, the vertex weights, and finally any differences in the bone transform matrices between the two meshes being compared. Any significant issues with any of those elements can lead to evil.

 

Note: The newest versions of Clothing Converter (Beta 48) *should* be able to automatically compensate for bad rigging, but the code changes that allow this are still a bit experimental.

 

 

 

In general, here's what I'd recommend:

 

Scenario 1

 

Assuming that you are using the same body nif for both the 'To' body style in Make Lattice and the 'Template Mesh' in Mesh Rigger.

 

1. Run Clothing Converter to convert a given nif to match the new body style

2. Run Mesh Rigger on the converted nif

 

Scenario 2

 

Let's say you have a nif that's just a mess. This can take many forms, but the most common is a mash-up that ended up with multiple incompatibly skinned geometry blocks. If that's the case, you may want to run Mesh Rigger first to clean the bad rigging and normalize all of the bad skinning.

 

For that, ideally you want to start with a Mesh Rigger 'Template Mesh' that matches the body style of the 'From' nif.

 

1. Run Mesh Rigger using the 'From' body nif as the 'Template Mesh' to re-rig the nif and repair any rigging errors

2. Run Clothing Converter to convert the nif to the 'To' body style.

3. (Optional) Run Mesh Rigger using the 'To' Body nif as the 'Template Mesh' to ensure that the weighting matches the 'To' body style

 

Note: step 3 can be eliminated if the 'From' and 'To' body styles have identical weight painting.

[Symon]

Thanks. In most cases I hope to be working with, Scenario 1. should hold.

[ger4]

When I looked at the normal .nif file, it seems that it had the bug it in originally.

[gerra6]

Ah. Thanks, that makes sense.

 

I was having a tough time coming up with scenarios that would generate that bug with v.48.

 

Pre .46, it was possible to get results like that if the target nif contained multiple mutually incompatibly skinned geometry blocks (i.e. a buggy mash-up). But that sort of bug *should* be resolved with the recent updates.

[orgs1n]

I'm not managing to create a lattice from UNP Skinny to UNP Topmodel. The Make Lattice step reports a MemoryError, and the .lat file is left empty. I've attached an archive of the Clothing Converter/ and save/ folders in case you'd care to take a look. Any tips?

[gerra6]

The Memory error can sometimes occur if you are using the Portable version of the tool and High Resolution for either the Search Resolution or Lattice Resolution.

 

There are two solutions available with the current version of the tool.

 

Select either Medium or Minimal resolution for both Search Resolution and Lattice Resolution

 

Or

 

Do a full install of a 64 bit version of Python 3.x (any of them should be fine), Install Pyffi 3k, and download the 'Light' version of the clothing converter tool.

 

Now, I am currently developing and testing a back-end rebuild of the Clothing Conversion system that should improve both quality and performance with a much lower memory footprint. Once it's ready for public testing, it should largely eliminate the memory problems, and provide a significant reduction in the time it takes to generate a lattice.

 

With a great deal of luck, I may have a version ready for testing later on today.

[orgs1n]

Thanks for the quick response! I ran a quick test at Minimal resolution and a lattice file was now generated.

 

I converted a few pieces of Northgirl armor from UNP Skinny to UNP Topmodel, replaced the meshes in the mod, and could load them into Skyrim successfully.

 

 

Issues to note:

 

1) I had to convert the .nif files one by one; Convert Clothing stopped after the first. Isn't it supposed to continue?

2) There's some distortion below at the breasts. (Second picture)

3) The armor makes the body snap to normal UNP; one can tell from the leg straps in the second picture. Is there a way to avoid this?

4) The trousers don't seem converted at all? (Third picture)

 

I suppose my simple file replacing doesn't quite cut it. Will look further into it tomorrow, and try that 64-bit Python as well.

[Deedlit]

@gerra6 , sorry if already got answered, but that will works also with dreamgirl body ( www.nexusmods.com/skyrim/mods/41443/? ) ?

[gerra6]

Issues to note:

 

1) I had to convert the .nif files one by one; Convert Clothing stopped after the first. Isn't it supposed to continue?

It depends a bit on your settings. If you select multiple files, it should convert each file. If you select a folder, it should convert every nif in the folder. If you set it to check subfolders, it should convert every nif in the directory structure.

 

However, settings like 'Gender' will cause the tool to skin any meshes that have an incorrect gender. Unfortunately, there aren't too many ways to detect the gender of a given nif (typically file and texture paths/names), so it's very easy for the tool to miscategorize the gender of a given nif.

 

For why it's quitting after one. I have no idea. I'll see if I can come up with any ideas. Could you send me the log file and settings next time it quits like that?

 

2) There's some distortion below at the breasts. (Second picture)

yeah, that's one of the reasons the current version of the tool includes the higher resolution options. Hopefully the next update will remove the need for high resolution searches (the update basically trades a fast vertex nearest neighbor search for a slower nearest point on face search).

 

3) The armor makes the body snap to normal UNP; one can tell from the leg straps in the second picture. Is there a way to avoid this?

Are you referring to the clipping issue?

 

With the current revision of the tool, your best bet is probably to enable the 'customize meshes' option and modify the 'padding' setting for the meshes that are experiencing clipping.

 

4) The trousers don't seem converted at all? (Third picture)

No idea there. I'd have to take a look at the files to see if I can spot the issue.

 

*Edit* Wait...I think I might have an idea. Was 'Edge Settings' set to 'Exclude Edges'? That would cause the issue you're seeing. Basically, if 'Exclude Edges' is enabled, the tool won't transform any 'non-manifold' vertices, which include pretty much any vertices on an open edge of a mesh.

[gerra6]

@gerra6 , sorry if already got answered, but that will works also with dreamgirl body ( ) ?

Yes and No.

 

The tool will happily attempt to create a conversion lattice that will convert any given body into any other.

 

However, if the two meshes do not have compatible UV maps, the quality of the conversion will depend entirely on the physical similarity of the bodies.

 

So, to convert between bodies with different UV maps:

 

1. Disable 'UV Search'. If the UV maps are incompatible and this is left on, you'll get spaghetti

 

Now, the quality might not be great. It really will depend on the two nifs you're working with. I am poking away at a project to automatically convert one UV map to another, but that's going to be a while.

[Deedlit]

still cool, better of doing whole thing at 3ds max, if just goes a minor fixes.

[gerra6]

As Promised

 

Convert Clothing Beta 50 ***Experimental Update***

 

This update marks a major change in the way that the tool works on the back-end.

 

The Good:

 

1. Lattice size is now substantially smaller, generally no more than double the size of the 'from' nif used to generate it.

2. The 'Make Lattice' tool no longer requires high resolution settings to generate high quality clothing conversion lattices

3. Conversion quality, overall, appears to be equivalent to or slightly better than the quality from using a resource intensive 'High Resolution' lattice

4. Memory usage should be dramatically reduced.  The 64 bit version of Python should no longer be necessary for High Quality conversions.

 

The Bad:

 

1. You'll need to re-make your lattices to take advantage of this update

 

Downloads:

 

Complete Portable Package (Python, Pyffi, Clothing Converter): See http://www.loverslab.com/topic/27557-new-clothing-body-type-converter-beta42-3-17-2014/?p=730339 for latest version

 

Light Download (Clothing Converter scripts only): See http://www.loverslab.com/topic/27557-new-clothing-body-type-converter-beta42-3-17-2014/?p=730339 for latest version

 

ChangeLog:

 

1. Fast nearest vertex search has been supplemented with a find closest point on nearby faces search. This allows for greater quality and accuracy with lower resolution lattices and searches. The cost is an increase in the per vertex search overhead.

2. Medium Resolution and High Resolution settings have been removed from Make Lattice tool.

3. Lattices now store face data in addition to node data.

[mem4ob4]

Updated to v50beta from a way earlier release.

Trying zkec to dmra. Used troubleshooting to capture the error.

I have no clue.

erroroutputWnifs.7z

 

Thanks,

Mem

[gerra6]

Whoops.

 

This update should resolve that nasty crash bug.

 

Full Download (Scripts, Python, Pyffi): Convert Clothing b_51.7z

 

Upgrade Download (Updates Full v.50 to v.51): Convert Clothing b_51_Upgrade.7z

 

Light Download (Scripts Only): Convert Clothing b_51_Light.7z

 

Change Log

 

1. Resolves v.50 crash bug that might occur during searches