ieryo0922 / gtaivtools

Automatically exported from code.google.com/p/gtaivtools
GNU General Public License v3.0
0 stars 0 forks source link

Bone Weight Indices on DrawableDictonary Type Files is wrong #20

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
- Open any .wdd and extract one or more Components.

What is the expected output? What do you see instead?
- Expected is that BlendWeight Indices on .wdd type models corresponds to 
correct bone like with e.g. Simple Drawable Type models .wdr or Fragment Type 
Models (Vehicles) .wft where it seems to work ok.

What version of the product are you using? On what operating system?
- SparkIV 0.7.0 Beta 1 on Windows 7, 64bit and Windows XP 32bit with custom 
modification on the smd exporter (see note below)

Please provide any additional information below.
I originally noticed problems with the Blend Weights when the .smd was imported 
to Blender 2.59.0 via the "SMD\DMX Tools" v.1.1.3 by Tom Edwards (under GPL).  
Then I saw that the smds had fix-coded the blend weights to 100% Node 0 (root). 
 So I updated the the Export Routine (ExportVertex in Studiomdlexport.cs) to 
use actual BlendIndices and BlendWeights.  (If anybody is interested I will 
give my modifications).

That worked exactly as expected (Blend Weights are Represented as 
Weight-Painted VertexGroups in Blender).  Then I noticed that while everything 
is fine for wft, that while the data gets imported for .wdds the vertex-weight 
to bone associations did not make sense (see attached screenshot).

From there I tried to track down the reason:  First I checked if the Import 
Script for Blender by Tom Edwards is faulty or if there is anything with the 
smd itself - both seem ok (again: .smds from wft work fine).

With a custom modified SparkIV 0.7.0 Beta 1 (working exactly the same as the 
precompiled from here, just with added heavy debug reporting, I checked both 
smds from your precompiled and my version - appart the dynamic blendweights its 
the same) I was able to track down the problem to what I think has to the way 
that Blend Indices are stored in wdd files other than like in wfts.  Thats 
where my search ends so far and my report opens.

My Idea:
- Maybe there is a "translation table" or something additional for wdds to 
translate the vertex data indices to the bone-model indices?  Maybe the indices 
in wdd dictionaries are not directly stored as in wfts - I noticed that the 
weightinidices in wdd smds are continous in a low range (fictional: 0-5) while 
the parts it would logically correspond to would be something like 
(0,2,8,13,22,32) - suggesting that they are an index to an array which will 
contain the actual bone indices. (a more complex real example - GTAIV 
f_m_bussines_01.wdd pedestrian - has the weightindices 0-43 while the bone tree 
actually has 0-79 and from a logical point of view some of them low-mapped 
indices should be up in the high numbers..)

- Another idea, which would be an easier option bu not as likely - maybe no 
"translation table" but a common offset to add to these indices?  (as far as I 
can tell this is highly unlikely as there is no common offset betwen the index 
found and the index it should be in one smd!).

Thank you very much for reading through here.  I hope this isn't a silly 
question.  I thank you very much for your effort and I'd be happy if I could 
contribute a little by pointing tout this problem and offering ideas for 
solution.

Kind regards, Jakob Klein

p.s. in the attached picture you can see the imported smd to blender on the 
left in weight-paint mode - blue = 0.0, red = 1.0, yellow ~ 0.8.  You can also 
see the bone-structure with names.  I have selected the weightmap for 
Char_R_Foot (as you can see in the panel on the far right) bbut the weight 
actually shows up on the left elbow.  On the right workspace half I have opened 
the raw smd where I have highlighted what the assignment is (Char_R_Foot, ID 9) 
while I think it should actually be something of Char_L_UpperArm ID43 or 
Char_L_ForeTwist ID 58.

I hope the picture is described that way, If anything is unclear about my 
question, anybody is free to contact me: kleinjakob@gmail.com

I hope somebody is fam

Original issue reported on code.google.com by kleinja...@gmail.com on 15 Sep 2011 at 11:16

Attachments:

GoogleCodeExporter commented 8 years ago
I figured I should add an wft example too to show that it works perfectly on 
non-wdd smds.

Jakob

Original comment by kleinja...@gmail.com on 15 Sep 2011 at 11:32

Attachments: