Jump to content

Dead or Alive 6 - Modding Thread and Discussion


Recommended Posts

Posted
8 minutes ago, Fiuzo said:

FIRST: THANKS TO ALL MOODER FOR MAKE YOUR WORK AND SHARE IT FOR FREE

Ā 

SECOND:

Too many request.. too many impatient ppl....

make a mod need time, edit mesh need time, for WORK need time...

Ā 

Please STOP annoyng request, study and make mesh and mod yourself OR... be patient and wait for wonderful work make by a talent modder!

Can make this? man make other? How can install? How can fap? How can life??

Guys just read other page there are ALL you needed... and stop quote all post with images....

Ā 

Sorry but there are too many request and very few "thanks"...

Man, its useless. Yes, absolutely. :)Ā 

Ā 

Posted

We desperately need a section dedicated to DoA6 and one topic for modding talk only (this one) and another for general discussion.

Posted

Thanks you guys for your hard work.
I used some mods and it worked fine.
For myself i cant do anything.

Cant realy get a mesh or something and even i got one.
Cant use blender etc iam not good for this.
So i wait and hope we get some good stuff.
But i guess we will see many stuff in the future,

Posted
On 4/11/2019 at 8:25 PM, Monkeygigabuster said:

@ausgeek

does your new update blender plugin allowed for merging meshes into one

if not atm then is there a way to combine meshes without messing vertext weight

I've just pushed up a change to allow this - though it is still a bit half baked and a wee bit glitchy.

Ā 

Edit: Refer to the update here:

Ā 

In the below screenshot you can see the original import on the left with the conflicting vertex groups from different sections of mesh highlighted, and on the right you can see the mesh imported with the pose from frame analysis then merged mapping the costume vertex groups to the body by matching identical bones* removing the conflicts:

Ā 

image.png.1171b5b7d6a01c6b1b72b2aa93e24eaa.png

Ā 

You will need to update the 'costume mod base.ini' to dump the pose constant buffer. The latest version can be found here:
https://raw.githubusercontent.com/DarkStarSword/3d-fixes/master/DOA6/Mods/costume mod base.ini

Ā 

If you wanted to manually update it instead, the important part is adding "dump=vs-cb0 txt buf" in the section responsible for dumping the meshes, i.e.

; Mesh (already exists):
analyse_options = dump_vb dump_ib share_dupes txt buf

; Various transformation matrices (NEW):
dump = vs-cb0 txt buf

If you have the latest blender_3dmigoto.py than you will see a new option in the import dialog. Fill it out like so (EDIT: Also set the new vergex group step option to 3):

Ā 

image.png.4432218254d0169a296b618e22429d20.png

Ā 

If you are wondering where I got these numbers from from, they are the constant buffer indices for mL2W in $Globals, which contains all the bone matrices.Ā All the relevant vertex shaders seem to have this in the same location (thankfully), so you can just blindly use 4-387 without looking it up, but if you did want to know how...

Spoiler

You would find these numbers you can dump one of the relevant vertex shaders (either add "regex asm" to marking_actions and hunt them, or enable export_shaders=1 if you don't mind the longer loading times that option incurs) and look at the reflection information at the top of the file. The names will differ in other games, but one big clue is the large number of components:


// cbuffer $Globals
// {
//   row_major float4x4 mW2P;           // Index:    0 1 2 3          Components:    16
//   float4 mL2W[384];                  // Index:    4-387            Components:  1536
//   bool bSkin[3];                     // Index:  388-390.x          Components:     9
//   row_major float4x4 mW2Pt;          // Index:  391 392 393 394    Components:    16
//   row_major float4x4 mW2S[4];        // Index:  395-410            Components:    64
// }
...
// $Globals                          cbuffer      NA          NA    0        1

For games that strip the reflection information out of their shaders you would have to examine the assembly and spot the offset used in code - it's usually fairly obvious.

Ā 

When you import it you will note that it is... a wee bit... glitchy: EDIT: This is fixed in the latest version of the script.

Ā 

image.png.0f73bb13977979c2666b481b7abce4b2.png

Ā 

DON'T WORRY!

Ā 

I'll try to work out why that's happening (I guess the matrices aren't in quite the same form as they were for DOAXVV) and see if I can fix it, but the merge procedure will still work despite this - just remember you typically want the body mesh active (whichever is active is the mesh that the vertex groups are going to map on to) and the rest selected, so take your best guess at which the body mesh is (switch to edit mode and see if you guessed right) and make sure it is active.

Ā 

Then just like the tutorial video hit Space and type in 'Merge 3DMigoto Poses', and once that is done you probably will want to delete the armature or at least unparent the meshes.

Ā 

I've also added a convenience operator to remove all non-numeric vertex groups from selected objects to save some mouse buttons:

Ā 

image.png.74eaf7ba3bce2aa2ba52ec1bdc9c2da2.png

Ā 

* one issue I noticed in this particular mesh (Leifang Deluxe) was that the left boot bone 12 happened to exactly match the body hip bone 0 at the same location & orientation and it was therefore incorrectly mapped to vertex group 0. I'm not positive if there is anything I can do to avoid this happening in the script, so for now just keep an eye out for it. EDIT: This is fixed in the latest version of the script.

Posted
13 minutes ago, JoeMesh said:

This game is really drawing in a lot of people with zero reading comprehension or patience.

It's not great. I wish we had a subforum already so discussion could be moved elsewhere and developers could have a little less nonsense to dig through to see what we need to see. Who has to be contacted for something like that to happen?

Posted

Wow, lots of progress has been made it seems, and it looks like my Saafie's angry dick is still raging on.Ā Ā  @SaafRats :DĀ  Good work as always.

Posted
3 hours ago, JoeMesh said:

This game is really drawing in a lot of people with zero reading comprehension or patience.

Lots of new accounts posting for the first three times in this thread by quoting some random post and adding a short generic thankyou or similar message.

I suspect most of them would fail the https://en.wikipedia.org/wiki/Turing_test.

Posted
16 minutes ago, ausgeek said:

Lots of new accounts posting for the first three times in this thread by quoting some random post and adding a short generic thankyou or similar message.

I suspect most of them would fail the https://en.wikipedia.org/wiki/Turing_test.

Fair enough - I'm not super up on the etiquette of this forum - is it preferable for the plebes like me who are unable to really contribute anymore than as a guinea pig for testing out other people's creations to not add any further unnecessary noise to the thread?

Ā 

Please don't take this as a shitty pouting post, I really do just want to support the modders here and not cause undue irritation in the future.

Thanks y'all!

Posted
On 4/11/2019 at 12:09 PM, ausgeek said:
Spoiler

Ā 

Ā 

I've just pushed up a change to allow this - though it is still a bit half baked and a wee bit glitchy.

Ā 

In the below screenshot you can see the original import on the left with the conflicting vertex groups from different sections of mesh highlighted, and on the right you can see the mesh imported with the pose from frame analysis then merged mapping the costume vertex groups to the body by matching identical bones* removing the conflicts:

Ā 

image.png.1171b5b7d6a01c6b1b72b2aa93e24eaa.png

Ā 

You will need to update the 'costume mod base.ini' to dump the pose constant buffer. The latest version can be found here:
https://raw.githubusercontent.com/DarkStarSword/3d-fixes/master/DOA6/Mods/costume mod base.ini

Ā 

If you wanted to manually update it instead, the important part is adding "dump=vs-cb0 txt buf" in the section responsible for dumping the meshes, i.e.



; Mesh (already exists):
analyse_options = dump_vb dump_ib share_dupes txt buf

; Various transformation matrices (NEW):
dump = vs-cb0 txt buf

If you have the latest blender_3dmigoto.py than you will see a new option in the import dialog. Fill it out like so:

Ā 

image.png.4432218254d0169a296b618e22429d20.png

Ā 

If you are wondering where I got these numbers from from, they are the constant buffer indices for mL2W in $Globals, which contains all the bone matrices.Ā All the relevant vertex shaders seem to have this in the same location (thankfully), so you can just blindly use 4-387 without looking it up, but if you did want to know how...

Ā  Reveal hidden contents

You would find these numbers you can dump one of the relevant vertex shaders (either add "regex asm" to marking_actions and hunt them, or enable export_shaders=1 if you don't mind the longer loading times that option incurs) and look at the reflection information at the top of the file. The names will differ in other games, but one big clue is the large number of components:




// cbuffer $Globals
// {
//   row_major float4x4 mW2P;           // Index:    0 1 2 3          Components:    16
//   float4 mL2W[384];                  // Index:    4-387            Components:  1536
//   bool bSkin[3];                     // Index:  388-390.x          Components:     9
//   row_major float4x4 mW2Pt;          // Index:  391 392 393 394    Components:    16
//   row_major float4x4 mW2S[4];        // Index:  395-410            Components:    64
// }
...
// $Globals                          cbuffer      NA          NA    0        1

For games that strip the reflection information out of their shaders you would have to examine the assembly and spot the offset used in code - it's usually fairly obvious.

Ā 

When you import it you will note that it is... a wee bit... glitchy:

Ā 

image.png.0f73bb13977979c2666b481b7abce4b2.png

Ā 

DON'T WORRY!

Ā 

I'll try to work out why that's happening (I guess the matrices aren't in quite the same form as they were for DOAXVV) and see if I can fix it, but the merge procedure will still work despite this - just remember you typically want the body mesh active (whichever is active is the mesh that the vertex groups are going to map on to) and the rest selected, so take your best guess at which the body mesh is (switch to edit mode and see if you guessed right) and make sure it is active.

Ā 

Then just like the tutorial video hit Space and type in 'Merge 3DMigoto Poses', and once that is done you probably will want to delete the armature or at least unparent the meshes.

Ā 

I've also added a convenience operator to remove all non-numeric vertex groups from selected objects to save some mouse buttons:

Ā 

image.png.74eaf7ba3bce2aa2ba52ec1bdc9c2da2.png

Ā 

* one issue I noticed in this particular mesh (Leifang Deluxe) was that the left boot bone 12 happened to exactly match the body hip bone 0 at the same location & orientation and it was therefore incorrectly mapped to vertex group 0. I'm not positive if there is anything I can do to avoid this happening in the script, so for now just keep an eye out for it.

Ā 

Ā 

I've made a testĀ following carefully every step , and even if a got the message "source bone matched multiple bones in the destination", the vertex groups remained the same.Ā I tried with a 2nd one and I got this when I tried to import: "Only draw calls using a single vertex buffer and a single index buffer are supported for now". Maybe could be related to some specific models...Ā but you've warned that this could be glitchy in any case.

However, I can confirm that exporting soft body meshes is working flawlessly by I quick test I've just made, great work there.

On 4/11/2019 at 3:36 PM, timmyc said:

Wow, lots of progress has been made it seems, and it looks like my Saafie's angry dick is still raging on.Ā Ā  @SaafRats :DĀ  Good work as always.

Thanks man, let's hope you'll appear with some interesting stuff as well!

Posted
6 minutes ago, SaafRats said:

I've made a testĀ following carefully every step , and even if a got the message "sorce bone matched multiple bones in the destination", the vertex grups remained the same.Ā I tried with a 2nd one and I got this when I tried to import: "Only draw calls using a single vertex buffer and a single index buffer are supported for now". Maybe could be related to some specific models...Ā but you've warned that this could be glitchy in any case.

However, I can confirm that exporting soft body meshes is working flawlessly by I quick test I've just made, great work there.

Thanks man, let's hope you'll appear with some interesting stuff as well!

Real Fapper, when will the mod be ready?

Posted
1 hour ago, SaafRats said:

I tried with a 2nd one and I got this when I tried to import: "Only draw calls using a single vertex buffer and a single index buffer are supported for now".

Which mesh was giving that error? I have a work in progress to add support for meshes split over multiple vertex buffers, but I didn't see any in this game so it was on the backburner - but if there is a mesh here affected by it I'll step it up a bit on the priority list.

Posted
9 hours ago, timmyc said:

Wow, lots of progress has been made it seems, and it looks like my Saafie's angry dick is still raging on.Ā Ā  @SaafRats :DĀ  Good work as always.

Hope to see your fantastic works!Ā 

(like the piercings)

Posted
On 4/11/2019 at 7:35 PM, ausgeek said:

Which mesh was giving that error? I have a work in progress to add support for meshes split over multiple vertex buffers, but I didn't see any in this game so it was on the backburner - but if there is a mesh here affected by it I'll step it up a bit on the priority list.

Helena's "goddess" costume (COS03 If I'm not wrong). And just in case, the one that also wasn't working was Nico "deluxe". Im particularly interested on get some missing vertex groups forĀ her feet. Here you can notice the issue (basically, her toes are static):

Spoiler

static toes.jpg

Now I'm wondering; even if the original body mesh was missing some (visible) feet vertex groups... It's possible that they can still exist inside that model? For be more clear, if the model keepsĀ those "unused" bones (or if they're just cropped).

Posted
3 hours ago, mortanios said:

I ll ask again,iĀ dont understand, what i need to do to use the mods?...anyone can help me please?

if you can't figure it out by going back through the thread, which is not that long, i suggest waiting until people have all-in-one packs along with instructions. different mods require different installation methods right now. i don't like to be rude, but all of the information you are asking for is elsewhere in this thread already. it does not need to be repeated over and over in multiple posts every time somebody asks.

Posted
2 hours ago, SagoSFM said:

if you can't figure it out by going back through the thread, which is not that long, i suggest waiting until people have all-in-one packs along with instructions. different mods require different installation methods right now. i don't like to be rude, but all of the information you are asking for is elsewhere in this thread already. it does not need to be repeated over and over in multiple posts every time somebody asks.

These pages can be read all day. Not many have so much time.

Posted
3 hours ago, SaafRats said:

Helena's "goddess" costume (COS03 If I'm not wrong). And just in case, the one that wasn't working was Nico "deluxe".

I'm not encountering the multiple vertex buffer error on either of these costumes at the moment - can I just double check which method you are using to import these - are you doing a 3DMigoto frame analysis dump or using @vagonumero13's tools?

Ā 

2 hours ago, SaafRats said:

Now I'm wondering; even if the original body mesh was missing some (visible) feet vertex groups... It's possible that they can still exist inside that model? For be more clear, if the model keepsĀ those "unused" bones (or if they're just cropped).

This was the case in DOAXVV - the body mesh had a set of bones that were shared with all clothing (clothing might have extra bones in addition to the ones in the body), but the vertex groups didn't match up. The merge poses function would locate identical bones and remap the vertex groups to match the active object (e.g. renumber the vertex groups in the boots to match the feet), even if the active mesh didn't have any geometry in the area of interest. From there we could then do a weight transfer from all tight fitting clothing onto a body mesh without any holes. From the merges I've done so far it seems like the clothes in DOA6 tend to have their own bones more often than not, so the merge workflow might not be as succesfull as it was in DOAXVV, but I'm betting the bones we need are likely to still be present.

Ā 

Ā 

Ā 

For those who were asking about the 4D problem - I've spent most of the day hitting my head against a wall for this. The positions are indeed 4D and I can see the vertex shader treat them as such, but the game also lies about pretty much all the other semantics in these meshes as well, so just about everything gets damaged on import to Blender. The only way I can import & export these is by disabling almost all semantic processing and treating everything as unknown values. Editing these 4D meshes is somewhat challenging - if you are just trying to delete parts of the mesh you might find it easier to use the UV editor to select vertices (tick the 'Keep UV and edit mode mesh selection in sync' button) and a bit of trial and error to find the right parts of the mesh to delete (if you aren't using 3DMigoto for mesh swaps you should be since it can reload live saving you a tonne of time when doing any trial and error). I'm not going to merge support for this into the main script (at least not all of it), but you can use this significantly dumbed down version for these meshes:

https://raw.githubusercontent.com/DarkStarSword/3d-fixes/blender_dumbed_down/blender_3dmigoto.py

Ā 

image.png.93450ac9faa7ad829e73eb756d89fbc8.png

Posted

@ausgeek

@SaafRats

Ā 

It is possible that the multiple vertex buffers is related with the parts that share same vertex buffer in the .g1m.

In these case, my tools will dump same vertex buffers for those parts (obviously the index buffer is different).

It is worth to mention here, that in these cases, although the related .g1m structure references a sub-section of the vertex buffer, I found out, that some indexes from the IB would still reference vertices out of range (e.g. it can share vertex with other part), that's why I decided to dump the whole vb.

Ā 

Even if they share same VB, they can technically reference a different bones group or a different material, which is why my tool exports them separated (that and the fact that at reimporting, my tool needs to know the number of vertex of each of those part).

Ā 

I think that from the @ausgeek dumps perspective, these parts that share same vertex buffer don't exist, and instead they are just a single VB/IB entity. But in the .g1m they are splitted.

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...