Jump to content

Costume Customizer Mod (v2.5.2) - Added Yukino Support, plus skin/shadow fixes and additional menu.ini fixes


Recommended Posts

@Geradness - Straight transfer from body weights should be fine. The only reason to pare down the vertices from the weight source mesh would be if you want to restrict the influence.  The only key part is that the order of the vertex groups matches. Meaning if the first vertex group is for the left nipple in BodyWeights, The first vertex group in the custom mesh will always need to be for the left nipple. How you go about assigning the weight paint to these vertex groups can be done in a number of different ways. The ways I've presented is more of just some of the simpler ways to do it following the original DOAXVV modding video.

 

The most typical reason for removing vertices in the source mesh would be if dealing with bras/croptops that cover only covers up the chest. Because of the A-Pose, the arms are pretty close to the chest, and the way weight transfer works is by determing what the vertex weight should be based on the vertices around it. So, sometimes if the bra/croptop is loose enough, it inherit too much vertex weight from the upper arms making it pull out when they move their arms up. By deleting the vertices in the bodyWeights mesh for the upper arms before doing the weight transfer, it'll prevent that.

 

Another case would be if you had an accessory, like a cat-tail that you wanted to place. Since we don't have any extra vertex groups to make the tail move independently, you probably want it to be static all together. The easiest way to do that is to make the weight paint the same for the entire mesh. The way I've done that is by placing the cat-tail where i wanted it to be on the body. Then Take the bodyWeights mesh (since this is an accessory and all accessories use bodyWeights), clone it then delete all but the vertex that is located right at where the cat tail is. This way, when I transfer weights from that new mesh, it'll use that one vertex's weight paint for the entire cat tail which will make it move exactly the same way that one vertex would w/o any deformity.

Link to comment
On 10/15/2020 at 2:47 PM, KuroKaze78 said:

@Geradness - Straight transfer from body weights should be fine. The only reason to pare down the vertices from the weight source mesh would be if you want to restrict the influence.  The only key part is that the order of the vertex groups matches. Meaning if the first vertex group is for the left nipple in BodyWeights, The first vertex group in the custom mesh will always need to be for the left nipple. How you go about assigning the weight paint to these vertex groups can be done in a number of different ways. The ways I've presented is more of just some of the simpler ways to do it following the original DOAXVV modding video.

 

The most typical reason for removing vertices in the source mesh would be if dealing with bras/croptops that cover only covers up the chest. Because of the A-Pose, the arms are pretty close to the chest, and the way weight transfer works is by determing what the vertex weight should be based on the vertices around it. So, sometimes if the bra/croptop is loose enough, it inherit too much vertex weight from the upper arms making it pull out when they move their arms up. By deleting the vertices in the bodyWeights mesh for the upper arms before doing the weight transfer, it'll prevent that.

 

Another case would be if you had an accessory, like a cat-tail that you wanted to place. Since we don't have any extra vertex groups to make the tail move independently, you probably want it to be static all together. The easiest way to do that is to make the weight paint the same for the entire mesh. The way I've done that is by placing the cat-tail where i wanted it to be on the body. Then Take the bodyWeights mesh (since this is an accessory and all accessories use bodyWeights), clone it then delete all but the vertex that is located right at where the cat tail is. This way, when I transfer weights from that new mesh, it'll use that one vertex's weight paint for the entire cat tail which will make it move exactly the same way that one vertex would w/o any deformity.

 

Wow! Ok lol, I've made two discoveries today about why I've been having trouble. Turna out I've been doing a lot of stuff right but it's been going wrong for unrelated reasons.

 

1) I've been using the CC mod tool to update my mods. I've noticed it will.sometimes  turn a vertex shader file from a 76 to an 80 for no apparent reason, leading to my exploding polygon problem. I now manually go into the .ini file and edit the stride counts there to make sure they come out right. Has anyone else experienced.this issue?

 

2) I've been making pants correctly all.this time only I've been putting them in the skirt slot instead of the socks slot... yeah it never occurred to me that each slot had it's own individual properties... I thought the were just ways to keep clothing organized.

Link to comment

@Geradness - I'm not sure if you are saying it's user error, application error or just not familiar with what causes the stride to be 76 vs 80. The stride is effectively tied to the number of UV maps present in the mesh which is also related to the pixel shader that is used to render the original mesh. In the game, most clothing related pixel shaders tend to use 3 UV maps however some do use 4 and the body/skin related pixel shaders all use 4. When you load a vb0/ib mesh into blender, Stride is identified in the custom parameters.

Spoiler

RequiredObjectCustomProperties.png.d662d18468a8c1bf3d927881b6b3d474.png

 

It must be at least 76 to include 3 UV maps and must be at least 80 to include 4 UV maps. Technically you can have stride set to 80 while only have 3 UV maps, it just means your exported mesh includes unused bytes. Typically, you wouldn't manually manage the stride, however if you merge 2 meshes together in blender, the mesh you merge into is the one whose stride parameter will persist. Meaning if you merge a stride 76 mesh into a stride 80 mesh, your new merged mesh will have stride 80. Either way, its best just to check the matching fmt files to make sure they match what you list in the CCModPackGenerator tool. Now, if you change/update in the ModPack Generator tool and it doesn't properly reflect the change in the INI let me know and I'll take a look. Also make sure, just to be safe, if you change the stride, go ahead and click inside another text box before hitting save as sometimes it might not have picked up the change before the save because of  how the OnChange event works to persist the adjustment.

 

Regarding #2, There's actually quite a bit of differences/technical details about each category like their draw order but most people don't need to consider too much of it other than the Bra/Panty/Skirt category clothing uses SuitWeights vertex groups while all the other clothing categories use BodyWeights vertex groups. You can find more information in the 3rd post of this topic if you haven't looked into it yet:

 

Link to comment
12 hours ago, KuroKaze78 said:

@Geradness - I'm not sure if you are saying it's user error, application error or just not familiar with what causes the stride to be 76 vs 80. The stride is effectively tied to the number of UV maps present in the mesh which is also related to the pixel shader that is used to render the original mesh. In the game, most clothing related pixel shaders tend to use 3 UV maps however some do use 4 and the body/skin related pixel shaders all use 4. When you load a vb0/ib mesh into blender, Stride is identified in the custom parameters.

  Reveal hidden contents

RequiredObjectCustomProperties.png.d662d18468a8c1bf3d927881b6b3d474.png

 

It must be at least 76 to include 3 UV maps and must be at least 80 to include 4 UV maps. Technically you can have stride set to 80 while only have 3 UV maps, it just means your exported mesh includes unused bytes. Typically, you wouldn't manually manage the stride, however if you merge 2 meshes together in blender, the mesh you merge into is the one whose stride parameter will persist. Meaning if you merge a stride 76 mesh into a stride 80 mesh, your new merged mesh will have stride 80. Either way, its best just to check the matching fmt files to make sure they match what you list in the CCModPackGenerator tool. Now, if you change/update in the ModPack Generator tool and it doesn't properly reflect the change in the INI let me know and I'll take a look. Also make sure, just to be safe, if you change the stride, go ahead and click inside another text box before hitting save as sometimes it might not have picked up the change before the save because of  how the OnChange event works to persist the adjustment.

 

Regarding #2, There's actually quite a bit of differences/technical details about each category like their draw order but most people don't need to consider too much of it other than the Bra/Panty/Skirt category clothing uses SuitWeights vertex groups while all the other clothing categories use BodyWeights vertex groups. You can find more information in the 3rd post of this topic if you haven't looked into it yet:

 

Sorry for my hasty post.  What I was trying to say was the cc mod exe file would, for whatever reason, set one of my clothing items to stride 80 no matter how many times I changed it to 76.  I ended up having to edit the save file to make it stop doing that.

Link to comment

Some bugs that I found.

 

If you update to cc 2.02 from the modmanager or direct download. The tanlines don't work properly. Only the face is affected.

Spoiler

150988761_DEADORALIVEXtremeVenusVacationScreenshot2020_10.20-12_23_30_25.png.82e05d23d1921e9d518b66a7cc76a192.png

In that case, the beach paradise mod works as intended.

Spoiler

758315124_DEADORALIVEXtremeVenusVacationScreenshot2020_10.20-12_24_05_96.png.914c731fd24976e153f910c4ae67609d.png

 

If you use the update from this comment. 

On 9/13/2020 at 12:54 AM, KuroKaze78 said:

@ForYourInformation - Ya looking at it, i forgot that by doing the change i did for 2.0.2 i needed to make an adjustment there too. I should have yet another patch before the end of the day.

 

Give this a try, drop these in your main CC Folder, you need all 3 since in 2.0.0-2.0.2 I accidentally used the common hash previously in all 3 files causing them to override each other (in addition to the other issue i introduced in 2.0.2)

 

Marie.ini 469.82 kB · 154 downloads Honoka.ini 476.04 kB · 152 downloads Common.ini 508.89 kB · 154 downloads                 

 

Custom tanlines start working again. But the beach paradise mod breaks.

Spoiler

726652593_DEADORALIVEXtremeVenusVacationScreenshot2020_10.20-12_24_58_80.png.880e34eabece556ee1e9777b5e3cf4cf.png

 

One last thing. Custom tanlines only work when you use a custom mesh as base. But it doesn't if you only active the slot in cc.

Using default body with a custom tanline.

Spoiler

tan.png.ff1a745e13b417726e99bcc28c40c82a.png

 

Exporting the default mesh as a custom body with the custom tanline.

Spoiler

tanfine.png.b7e59ac4edc35952457043bc9109775a.png

 

Link to comment

@SavageMoonBoy - So, yes, I'm aware I've been lazy and the v2.0.2 released still has broken tanlines w/o the separate INIs provided. I'll push out a release tomorrow w/ the patches formally implemented.

 

Quote

"Custom tanlines start working again. But the beach paradise mod breaks.:"

That shouldn't be the case, as its the same set-up I have and it works fine. There might be something else occurring thats causing that issue. Make sure all your mod-packs are up to date(update.bat, or regen all INI logic), otherwise one of the mod-packs could still be replacing the textures with a full copy rather than a ref copy which could replace the textures of one mod-pack with texture from another mod-pack and they will carry over until you reload all mods (F10) or restart the game. 

 

Quote

One last thing. Custom tanlines only work when you use a custom mesh as base.

This looks to be an oversight in the INI Generator. Previously, I think i had it restricted to where you couldn't define a custom ps-t3 for body meshes unless it was custom. I think I relaxed that restriction, but didn't notice the INI Generation routine only added the INI logic still if the mesh was custom. I'll have to fix the INI  genator and include the updated dll in the v2.0.3 version as well.

Spoiler

foreach (BodyMesh bodyMesh in currentOption.BodyMeshes)
{
    if (!bodyMesh.IsDefault)
    {
        if (bodyMesh.IsNull)
        {
            sb.AppendLine(@"    Resource\" + resourceHeader + @"\" + curCostumeSlot + bodyMeshTypeResName[bodyMesh.MeshType] + "IB = null");
            sb.AppendLine(@"    Resource\" + resourceHeader + @"\" + curCostumeSlot + bodyMeshTypeResName[bodyMesh.MeshType] + "VB = null");
        }
        else
        {
            if (FilenameToResource.ContainsKey(bodyMesh.IndexBuffer))
            {
                sb.AppendLine(@"    Resource\" + resourceHeader + @"\" + curCostumeSlot + bodyMeshTypeResName[bodyMesh.MeshType] + "IB = ref " + FilenameToResource[bodyMesh.IndexBuffer]);
            }

            if (FilenameToResource.ContainsKey(bodyMesh.VertexBuffer))
            {
                sb.AppendLine(@"    Resource\" + resourceHeader + @"\" + curCostumeSlot + bodyMeshTypeResName[bodyMesh.MeshType] + "VB = ref " + FilenameToResource[bodyMesh.VertexBuffer]);
            }

            // This should probably be moved outside of the !IsDefault() check.

            if (!String.IsNullOrEmpty(bodyMesh.TanTexture) && FilenameToResource.ContainsKey(bodyMesh.TanTexture))
            {
                sb.AppendLine(@"    Resource\" + resourceHeader + @"\" + curCostumeSlot + bodyMeshTypeResName[bodyMesh.MeshType] + "PS3 = ref " + FilenameToResource[bodyMesh.TanTexture]);
            }

            if (bodyMesh.SkinTextures != null)
            {
                foreach (SkinTexture aSkinTexture in bodyMesh.SkinTextures)
                {
                    if (!String.IsNullOrEmpty(aSkinTexture.Filename) && FilenameToResource.ContainsKey(aSkinTexture.Filename))
                    {
                        sb.AppendLine(@"    Resource\" + resourceHeader + @"\" + curCostumeSlot + aSkinTexture.SkinSlot + bodyMeshTypeResName[bodyMesh.MeshType] + "PS0 = ref " + FilenameToResource[aSkinTexture.Filename]);
                    }
                }
            }

        }
    }
}

 

Also, just to make things clear, the UV mapping for custom tans really shouldn't ever change, and they should be essentially essentially have the same intended UV mapping for all custom body meshes, otherwise the resulting tan overlay wont' carry over properly to other suits since the game will use the same tan texture overlay on the newer suit's body mesh which if it doesn't match could look really weird.

Link to comment

Yes, but it's up to the modder to make sure they separate the tan textures used in the Chest and Groin categories. Each of the custom tan textures are combined and the tanlines are all merged.

 

Example (Kirishima):

Spoiler

Original Tan Texture (Red Channel only):

image.png.eed7d121e03ffb0c789e78269f128626.png

 

Rather than the above with both the top and the bottom applied to both body the chest and groin body meshes. Do the following:

 

Breast custom Tan Texture:

image.png.8e0dde126428a66693f821da8c0f507e.png

 

and Groin custom Tan Texture:

image.png.676f9f745f741f824e4af95da22ba9a4.png

 

Link to comment
On 10/20/2020 at 11:24 PM, KuroKaze78 said:

That shouldn't be the case, as its the same set-up I have and it works fine. There might be something else occurring thats causing that issue. Make sure all your mod-packs are up to date(update.bat, or regen all INI logic), otherwise one of the mod-packs could still be replacing the textures with a full copy rather than a ref copy which could replace the textures of one mod-pack with texture from another mod-pack and they will carry over until you reload all mods (F10) or restart the game. 

I did a clean installation for cc and bp mod. I ran the update.bat just in case. The problem still persist.

 

I thought it was related with the custom tanlines because of this.

 

First, here it's the cc using an empty slot and the skin without any tan.

Spoiler

2110733949_DEADORALIVEXtremeVenusVacationScreenshot2020_10.22-21_31_25_45.jpg.da1c9a2f7415030874deb0f3b864a5ec.jpg

 

Then I maxed out the tan while still using an empty slot.

Spoiler

447751874_DEADORALIVEXtremeVenusVacationScreenshot2020_10.22-21_31_50_46.jpg.66755a7dd74228ab9d8252a269e2902b.jpg

 

Then I changed to a cc mod that use a custom tan and then I decreased the tan by 1. The custom tanline is applied.

Spoiler

85994282_DEADORALIVEXtremeVenusVacationScreenshot2020_10.22-21_32_32_12.jpg.adab964ba674819806612abf8c2602cf.jpg

 

If I don't modify the tan. The custom tan persist even when changing to another cc mod (just as expected).

Spoiler

1576553611_DEADORALIVEXtremeVenusVacationScreenshot2020_10.22-21_32_49_41.jpg.a0d0299103ed4cf1e7ef5ebeac86e748.jpg

 

Even with the bp mod. So, because I didn't change the tan, I deduce the bp mod is still using the skin from the last mod. Causing the bug.

Spoiler

1592470242_DEADORALIVEXtremeVenusVacationScreenshot2020_10.22-21_33_05_65.jpg.857240462efdbfed29aecc0fda836c2a.jpg

 

But even when increasing or decreasing the tan again and then pressing F10 (or alt+F10) or restarting the game. The bug still persist. The tan is removed, but looks like the skin from another mod is still being used.

Spoiler

1258728433_DEADORALIVEXtremeVenusVacationScreenshot2020_10.22-21_33_26_80.jpg.7bbfb1e15c5ff534e39860db1b0cc10c.jpg

 

Link to comment

@SavageMoonBoy I think this is where I was getting that the UV mapping on the custom meshes has to still line up with the original UV map in that it still has to use the same region of the tan texture for equivalent parts of the custom mesh. Because BP boobs effectively is a splice of custom DOA5LR meshes + DOAXVV, they modified UV mapping for the meshes for the first 3 UV maps and probably also has a modified tan mesh meaning its not really compatible with tan-lines to begin with, even if you gave it tan lines using other non-modded suits.

 

It may have been fixed in newer versions of BP boobs since the version you have shown is one of the older ones but I'm not really sure.

I'm positive my game shouldn't have any additional changes related to this and it seems like it works fine w/ the BP boobs v0.9 beta.

image.png.e4b321900b65e4d18c8e4679e3cd7bda.png

 

Just to be on the safe side, make sure you are using v2.0.3 (there may have still been a bug in the loose ini files i provided where they only utilized slot 1's tan textures). Also, after you get the tan-lines you want, change suits (normally in game) so that it saves the set-up and then switch back to Dewa/Takao. You may want to also try disabling any global tanning mods if you have it active if they could be causing a problem. Another thing to check, make sure if you by chance modified your copy of BP boobs, it still has its custom skin textures properly set-up because like I mentioned they use custom UV maps, so w/o the proper skin textures properly assigned, they won't look right at all. Actually, now that I think about it, i think the older version that you have had some other atypical way of providing the custom skin textures which also could be your problem?

 

Edit: Doesn't appear to be a problem with the original old version (BP Boobs 0.6 according to the ModConfig.xml) so it seems like the UV maps were fine back then. Note, that my Steam installation is extremely clean and only has the base mod and configs, CC + mod-packs and one other mod. DMM is in maintenance ATM. I'm now leaning toward another mod you have is having a weird interaction with it.

Link to comment

@SavageMoonBoy, @ADayDreaming, @Amytheone - Only thing I can think of is to isolate which mod is causing the problem if you want to help solve your problem and help others out to find what weird cross-impact is occurring. I would start by disabling all mods other than CC and Skins folders. If the problem still persists then maybe post your d3dx.ini here so I can try reproducing it using it and see if something in there was changed from expectations. If the problem goes away, then that would likely point to there is a spill-over from another one of your installed mods. At that point, add them back in (rename to remove disabled or however you choose to do this) half at a time and reload to figure out if the spill-over is from that half of the mods or the half you left out. Continue this process ideally until its just one (hopefully) mod that's causing it, the assuming its public let me know which one so I can look into how to de-conflict them or if private see if you could DM me at least the INI files so I can check out what its doing.

 

@Amytheone - Regarding nipples poking out, normally that occurs when you also have Knight77's RedHip Mod installed since it replaces the same Takao suit and its being drawn at the same time as CC. Check for that and if you have it, just disable/remove it.

Link to comment
2 hours ago, KuroKaze78 said:

@SavageMoonBoy, @ADayDreaming, @Amytheone - Only thing I can think of is to isolate which mod is causing the problem if you want to help solve your problem and help others out to find what weird cross-impact is occurring. I would start by disabling all mods other than CC and Skins folders. If the problem still persists then maybe post your d3dx.ini here so I can try reproducing it using it and see if something in there was changed from expectations. If the problem goes away, then that would likely point to there is a spill-over from another one of your installed mods. At that point, add them back in (rename to remove disabled or however you choose to do this) half at a time and reload to figure out if the spill-over is from that half of the mods or the half you left out. Continue this process ideally until its just one (hopefully) mod that's causing it, the assuming its public let me know which one so I can look into how to de-conflict them or if private see if you could DM me at least the INI files so I can check out what its doing.

 

@Amytheone - Regarding nipples poking out, normally that occurs when you also have Knight77's RedHip Mod installed since it replaces the same Takao suit and its being drawn at the same time as CC. Check for that and if you have it, just disable/remove it.


Thanks, it was the RedHip causing the nipple poke issue.


I'll fiddle with the mods a bit later, but just to illustrate my issue, the BP Boobs and Basic Boobs both have these strange texture issues on the nipples and underboobs.
 

Spoiler

BP Boobs:
image.png.c1d153a4c7924e811665dcbde1a38d37.png

 

Basic Boobs:
Strangely enough, the nipples here are clearly placed underneath on the sides of the upper torso

image.png.d54714dbdeae20baa21c7285caf0b8d0.png



EDIT: Just tried with ONLY Costume Customizer and HI-METAL v4 skins active.
It's sadly still severely messed up.

Spoiler

image.png.062199d8f0980fba812571f6cb248303.png

 

Link to comment

@Amytheone - Can you DM your d3dx.ini, I'll take a look and I'll try using the v4 HI RES Skins as I still just have v3 installed but maybe there is an interaction there. BP Boobs and Basic Boobs both provide their own skin textures which should override those anyways and that is what is not happening on your system but I don't yet understand why. I just tried using ModManager to install BP Boobs from the online archive and it appeared to work fine on my system. Also, do you get any error pop-ups when launching or when loading BP Boobs for the first time each session? Do me a favor and also post one of the INI files (Common, Honoka or Marie) from the BP Boobs's mod-pack folder in your Costume Customizer directory as maybe there is a problem when it regenerates the INI file and is excluding the skins logic for some reason.

 

@switch0000 - Like most other mods that have persistent settings, the easiest way to ensure your settings get saved is to reload once its set-up how you like it by pressing "F10" as the default key binding.

Link to comment

Ok, finally figured out what went wrong. For all those having issues with BP Boobs, Basic Boobs or any other mod-pack that uses custom skin textures. The problem was identified that the "CostumeCustomizer_v2.0.3.zip" package was missing one of the updated ini (Menu.ini) files that was properly included in the v2.0.3 PATCH zip and the mod-manager compatible zip packages. During the investigation, I also found I didn't fully get custom skins working w/ default meshes in the INI generation logic so I released v2.0.4 anyways.

 

 

Sorry for the issues, I'll try and incorporate a better packaging methodology to ensure each installation method match each other moving forward.

Link to comment

Nice to meet you, let me ask you a question.
I'm trying to port it to CC so that I can use it in combination with costumes.

There is a problem there.
The valley part of the brassiere is pulled by the movement of the chest and it collapses

The upper part of the thread is the same as the movement of the chest, but the lower part is fixed, so it will shift when moving.

Probably a weight issue
The brassiere was transferred from SuitWeights_ChestOnly.

The thread was transferred from BodyWeights_Common_HighRes.

I would like to know if there is a way to fix it.

I look forward to working with you.

Thank you

Captcha.PNG

Link to comment
14 hours ago, KuroKaze78 said:

Ok, finally figured out what went wrong. For all those having issues with BP Boobs, Basic Boobs or any other mod-pack that uses custom skin textures. The problem was identified that the "CostumeCustomizer_v2.0.3.zip" package was missing one of the updated ini (Menu.ini) files that was properly included in the v2.0.3 PATCH zip and the mod-manager compatible zip packages. During the investigation, I also found I didn't fully get custom skins working w/ default meshes in the INI generation logic so I released v2.0.4 anyways.

 

Sorry for the issues, I'll try and incorporate a better packaging methodology to ensure each installation method match each other moving forward.


Sorry I never got back to you with those INI files, been away from my PC for a spell.

You're a god amongst men, thank you for your hard work and never apologize for making mistakes. Especially with a project of this scope with no reward in return.

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
×
×
  • 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