Hi there! You are currently browsing as a guest. Why not create an account? Then you get less ads, can thank creators, post feedback, keep a list of your favourites, and more!
Alchemist
Original Poster
#1 Old 25th Jan 2006 at 4:46 AM
Default Target Indices in the GMDC
This is a really complex item to explain unless you have spent time working with the GMDC, and can read and understand the layout as described in the Wiki section.
A part of the "morph" process (fat/pregnant) depends on sections in the GMDC tagged 0x7C4DEE82, we have been calling "target Indices". These sections are the only parts of the GMDC data entities prior to the first ones actually used in the model(s) that have the vertice and item data parts of the section used.
I have tried numerous times to understand where the data attached to the targets fits into the scheme. The layout is much like other parts of a mesh file, although they are not triangles because they are not always evenly divisible by 3 for an item count; there is some quantity of float data in sets of three, and an equal number of integer data items.
I have tried visualizing the data in numerous ways. The float sets are pretty small values, almost certainly vector data of some sort. If you model them, you get a small cactus looking bush emanating from 0,0,0.
I have tried matching the integers against the triangle list and the vertex list, and have never seen any pattern. I have yet to find and example where the largest index is greater than the number of vertices or triangles that would rule one or the other out. They always seem to be pretty random looking parts, sometimes a lot on one leg, and none on the other, some of one shoulder but not the other... just randomness.
I did find that I can see no problem with GMDC models manufactured without this data, and have been doing so since the BodyChop plugins came out. As long as the target section is there, it appears irrelevant whether there is data in it or not.
Anyway, if anyone else wants to take a crack at trying to see if they do anything, I have a special set of my new MilkShape UniMesh plugins that will stash the data in the models comments on import (yes/no choice) and will restore the data saved on export (yes/no choice, too). It is converted to lines of text laid out in a pattern similar to what you might see in an ascii milkshape or .obj file. On export, they are parsed and the data placed back in the target section.
They have a slightly different name (X) and title than the regular plugins, so they can be installed with the regular ones, rather than overtop of them.
So if you want to experiment, I would be curious if someone finds any appearance or behavioural difference between models with the data copied over and ones with it just left out. So feel free to try them out, but they are just an experimental version.
<* Wes *>
Attached files:
File Type: zip  ExperimentalPlugins.zip (53.7 KB, 19 downloads)

If you like to say what you think, be sure you know which to do first.
Advertisement
Lab Assistant
#2 Old 5th Feb 2006 at 9:23 AM
Do you think this set of data can be the one used for pregnant morph (as the MorphDelta section is used for fat mesh) ??
Alchemist
Original Poster
#3 Old 6th Feb 2006 at 1:05 AM
Quote: Originally posted by skankyboy
Do you think this set of data can be the one used for pregnant morph (as the MorphDelta section is used for fat mesh) ??


The presence of Morph Targets in the set list for a group indicates the presence of morph data sets, which are already interpreted and used. If there is a pregnant morph in the mesh, it will be imported as such (try afBodyNaked_tslocator_gmdc). What is clearly puzzling is that none of the other gmdc sections except the Morph Targets contain any data prior to the first 'real' referenced set of vertices.

And none of the other sections of P1 in the GMDC utilize both of the data item blocks, the rest only use the first one.

This is one of the last remaining mysteries left in the GMDC decoding effort that remains unresolved. Meshes seem to work well enough without any of this data in them, so I have often wondered if it's a production artifact or something added for production purposes, as I can find no purpose for it.

The other mystery is the hair meshes, which have had the P5 subsets rearranged from the way they would be presented as a body, clothing or animated object mesh in order to serve some animation purpose. Hair meshes seem to be the only boned mesh that also contains bone assignments referencing animation targets (specifically the five *_hair targets). If these changes aren't made (which as yet no modding tool knows what to do) and the _hair bone assignments are left in the mesh you get some amusing but unworkable mesh rendering problems in the game (or BodyShop).

<* Wes *>

If you like to say what you think, be sure you know which to do first.
Alchemist
Original Poster
#4 Old 23rd Mar 2006 at 6:29 AM
These appear to be the delta translations to be applied to specific verts that may be modified by the morph.
Part of the game spends a lot of energy ensuring that when you click on an animatible object, that object can be selected.
I don't have any working code (yet) to demonstrate this, but I believe that when a morph is triggered, these values are applied to the translation portion of the quaternion to alter the 'mouse-click' area described in P5.
Given my current thoughts, you would not be able to select a fat Sim until you got close enough to the underlying fit part without these being applied.
<* Wes *>

If you like to say what you think, be sure you know which to do first.
Back to top