March 29, 2024, 06:14
bigger smaller reset     1020px Wide width Full width Reset   * *

Gildor's Forums

  Homepage Facebook Read news on Twitter Youtube channel Github page
Welcome, Guest. Please login or register.
Did you miss your activation email?

« previous next »
Print
Author Topic: Skeletal Mesh problem  (Read 29114 times)
Praedor
Newbie
*
Posts: 11


View Profile
« Reply #15 on: May 24, 2013, 13:40 »

I refer in this case to the full mesh object named HMF_ARM_ASHa_MDL, the actual name of the mesh object and called "skeletalmesh" only and not one of those items called "skeletalmeshobject" in the me3exp window. I assume the large object w the entire   m#sh name is the ultimate mesh escription?
Logged
Alcatraz
Newbie
*
Posts: 17


View Profile
« Reply #16 on: May 24, 2013, 15:16 »

So the psk's exported from Blender are different from psk's exported from 3DS max?
That's strange, maybe someone could export the same model from both programs and upload psk's here so I can compare them?
Logged
Praedor
Newbie
*
Posts: 11


View Profile
« Reply #17 on: May 24, 2013, 17:11 »

It is sad but true.  The psk support in Blender is weaker than the support in 3ds  Embarrassed and (supposedly and HOPEFULLY) is a work in progress. 

My puzzle at the moment is this:

I take a pcc from the game ME3.  I decompress the pcc and then make a copy of it.  With the copy, I pull out a psk of a character mesh and edit it in 3ds or Blender or Milkshape by merely grabbing ONE vertex and pulling it out to form a prominent spike on the character mesh.  I then import that mesh back into the copy of the pcc and do a bit-by-bit comparison in a hex editor.  I fully expected to find differences due to variations in how 3ds or Blender produce a psk vs what Bioware created.  Fine.  But I also FULLY expect to find differences in the actual skeletal mesh component itself, the code in the pcc that specifies the mesh (supposedly) as a result of one vertex being moved.  Thing is, when I do a bit-by-bit compare THERE'S NO DIFFERENCE BETWEEN THE ORIGINAL UNTOUCHED MESH AND THE EDITED IMPORT MESH.  But if I use the copy pcc in the game the spike is clearly there.
Logged
Praedor
Newbie
*
Posts: 11


View Profile
« Reply #18 on: May 24, 2013, 17:51 »

Here's an illustration of what is a mystery to me:

I've taken BioH_Ashley_00_NC.pcc, a file that contains Ashley's default uniform, head, hair and is used at the very beginning of the game when she first makes an appearance and open it in ME3explorer -> Meshplorer:



You see her mesh is normal.  I export it as a psk and edit it in 3ds Max 2010 to produce a single spike on her right shoulder and then import that psk back into the file:



The spike is clearly visible and shows up in the game (with incorrect mesh lighting).

I then opened up the original pcc (unchanged but decompressed) in PCC editor 2.0 to locate THE skeletal mesh portion of the pcc:



I opened up both the original, unchanged pcc and the new pcc with the mesh with a spike, in a hex editor and did a comparison of the same portion (the actual skeletal mesh):



There is NO difference whatsoever between the two files, yet one contains a mesh with a spike and the other is unchanged.  WHY?!  HOW?! Huh?

Logged
Praedor
Newbie
*
Posts: 11


View Profile
« Reply #19 on: May 24, 2013, 18:32 »

OK...new information.  And it is new info I do not understand either.  It turns out that there are TWO copies of the skeletal mesh in the pcc file that receives the new mesh.  I thought the original was being overwritten by the new/imported mesh but it is being tacked onto the end of the pcc.  I had NO idea this was how importing meshes was working in ME3exp but it explains all of what I considered oddities: the increase in size of the pcc after doing so and the incremental and continual increase in size every time you import a new mesh...each previous version remains while the new one gets stuck onto the end of the file. 

 Undecided
Logged
Alcatraz
Newbie
*
Posts: 17


View Profile
« Reply #20 on: May 24, 2013, 22:04 »



(Source: http://me3explorer.wikispaces.com/PCC+File+Format )
The duplication of date seems to be obvious drawback of pcc editing method of WV

The old mesh is still in "old datablobs"
but the new mesh is inside "new datablobs".
« Last Edit: May 24, 2013, 22:06 by Alcatraz » Logged
Praedor
Newbie
*
Posts: 11


View Profile
« Reply #21 on: May 25, 2013, 06:18 »

I conducted a little (painful) experiment today with a hex editor and ME3explorer.  I had 3 copies of a pcc.  With pcc 1 I exported the Ashley body mesh as a psk, imported it into Milkshape, then exported it again without changing it, then imported it back into pcc 1.  With pcc 2 I did the same thing but in Milkshape, I selected a single vertex on top of her right shoulder and pull it upward to produce a prominent spike.  I exported it as a psk and imported it back into pcc 2.  I used exactly the same import options for both.  With pcc 3 I did nothing but decompress it.

I opened up pcc 1, 2, and 3 in a hex editor, copied the mesh data of the imported mesh in pcc 1 and 2 and saved them into independent hex files (they contain only the mesh).  With pcc 3 I copied the unaltered, decompressed mesh and saved it into its own independent hex file.  They were all now directly comparable - same offsets, same addresses.  I opened up the hex file of mesh 1 (unaltered, exported, opened in Milkshape and exported again, then re-imported into its pcc in Meshplorer) and did a direct bit-by bit comparison with mesh 2 (Single vertex spike produced in Milkshape, reimported into pcc 2).  There were 53 points of difference between the two mesh files.  Because all else was equal, these points of difference had to contain only the data representing the single vertex pulled into a spike in mesh 2.  Tangents, bitangents, etc, were identical in both (except perhaps those ONLY associated with the single vertex spike).  

I then manually entered the 53 data points from the edited (spike) mesh into their equivalent offsets in mesh 3 (decompressed original mesh) and saved it.  I copied the entire file contents and pasted it over the same mesh data in pcc 3.  A bit-for-bit swap of an identical mesh except for 53 points of difference from the original due to the vertex being pulled into a spike.  I started the game an took a look.  What I expected to see was a perfectly lighted Ashley with a spike sticking up out of her right shoulder (the lighting aspects of the spike I expected to be off but only that).  Instead, I got a perfectly rendered Ashley but with a spike NOT sticking up out of her right shoulder, but instead a long (indefinite length) spike projecting from the upper portion of her right breast and extending FAR away.  


 






So why did the spike project forward and very very far from her breast instead of vertically a bit from her right shoulder?  Does Milkshape screw up coordinates somehow?  Is the import process in Meshplorer screwing up vertex coordinates?  

A comparison between the original mesh (decompressed) and either import naturally produces COUNTLESS points of difference because virtually every tangent, bitangent, etc, diverges but in the above experiment, it should have isolated any such surface/lighting effects to the spike alone and also NOT affected the direction and physical size of the spike.  
« Last Edit: May 25, 2013, 06:38 by Praedor » Logged
Alcatraz
Newbie
*
Posts: 17


View Profile
« Reply #22 on: May 25, 2013, 12:28 »

Those are skeletal models.
If you've edited the vertex weight offset, it might not have been in absolute space. It might have been relative to vertex weight bone parent.
EDIT: After looking into SkeletalMesh format it seems vertex pos is in absolute space, but strangely enough structure is named Edge
Code:
        public struct Edge
        {
            public int Unk1;
            public int Unk2;
            public List<Influence> Influences;
            public Vector3 Position;
            public Vector2 UV;
            public bool _updated;
            public bool _imported;
        }
I'd rather call this "Vertex".

EDIT:
Milkshape allows only one bone per vertex, am I right? Milshape is not a recommended software for editing skeletal meshes, because in skeletal meshes there are usually more than 1 bone influencing a vertex.
« Last Edit: May 25, 2013, 14:43 by Alcatraz » Logged
Praedor
Newbie
*
Posts: 11


View Profile
« Reply #23 on: May 25, 2013, 17:48 »

I intend to do the same thing via 3ds  and Blender. Milkshape seems to have the most robust psk support. 3ds is a close second or equal while Blender sadly lags.  This is why I much prefer open source. No requirement to keep reinventing the same wheel, just build on previous work.  Undecided  I need all influences from all software passages to be identical across the board so the only possible src of difference is restricted to one veryex chgng position, I just started with Milkshape.
« Last Edit: May 25, 2013, 17:55 by Praedor » Logged
Praedor
Newbie
*
Posts: 11


View Profile
« Reply #24 on: May 26, 2013, 03:27 »

I have now conducted the same experiment but using 3ds Max 2010 as the editor to place a spike on Ashley's left shoulder.  I moved one vertex vertically about the equivalent of half the height of her head.  I applied 50 hex bits of data that differed between the original, unchanged Ashley mesh and the version containing the single vertex spike to the original pcc file.  I started the game and ran it and got a bit of a different result from before.  

The spike on her left shoulder, instead of forming a simple spike runs off the top of the screen (but is properly lighted Smiley) AND there is a second spike firing off to the right off the screen AND there is a third spike, harder to see, that is 180 degrees off the original spike driving downwards to a point near the floor.







Better, in that the main shoulder spike is in the correct direction, but worse in that there are two more spikes...some sort of weighting issue?  I suppose I could start tweaking, one by one, each hex value of the 50 that changed vs the original (most were in triplets which I am assuming means something...are vertex coordinates in sets of consecutive 3 (x, y, z)?

Next I'll try with Blender to see which of the 3 editing software packages, if any, produces the least screwed up result.
« Last Edit: May 26, 2013, 03:29 by Praedor » Logged
Print 
« previous next »
Jump to:  

Powered by SMF | SMF © 2006-2009, Simple Machines LLC
Leviathan design by Bloc | XHTML | CSS