[Discussion] Reskinning dead in wotlk.

[schlumpf]

Message me on MSN or ICQ, chuanhsing. You seem to be the first intelligent being here. Have you started to document the changed M2s? I did.

[chuanhsing]

Yes, I had made a WotLK version of wowmodelviewer.

There still has some problems, but it work for most items now.

[schlumpf]

So does mine.

[chuanhsing]

I had post the WotLK version of wowmodelviewer in it's forum.

The modified version works on most items without Animation and Particle System effects.

NPC Model also failed too.

forum url:
Wotlk model viewer

[schlumpf]

So you figured out the .skins. Have you looked in the .anims too? As far as I can see, you just use the old animated.h and the old structure without ranges. Or?

[TyroneBiggums85]

Good stuff!!

[TyroneBiggums85]

Good Stuff!!

[chuanhsing]

So you figured out the .skins. Have you looked in the .anims too? As far as I can see, you just use the old animated.h and the old structure without ranges. Or?

Yes, I use the old structure without ranges. So the animations will not work. Do you know how to make animation work again ?

I will take a look at .anims these days.

[Mclovin252]

I agree, find another hobby? Haha

[Gawdlaw]

Beh! school started and i havent seen anything epic in the me section /bored :wiggle: I geus blizzard doent even haves to do anything anymore agains ME :lmao:

My mmowned Cheerup!


Need to get used to the pen, first creation =)

[chuanhsing]

I got some problems about ModelAnimation.

[morten11]

cool(filler)

[kitteh]

- .skin files basically only contain the LOD mesh data for the .m2. The .m2 header decreased to 304 byte and the content chunk of the .m2 is almost only a long list of vertices. The LOD bone data is found in FILE_00.skin to FILE_03.skin, depending on nViews.

This is the WotLK model header:

struct ModelHeader {
char id[4];
uint8 version[4];
uint32 nameLength;
uint32 nameOfs;
uint32 type;

uint32 nGlobalSequences;
uint32 ofsGlobalSequences;
uint32 nAnimations;
uint32 ofsAnimations;
uint32 nAnimationLookup;
uint32 ofsAnimationLookup;
//uint32 nD;
//uint32 ofsD;
uint32 nBones;
uint32 ofsBones;
uint32 nBoneLookup;
uint32 ofsBoneLookup;

uint32 nVertices;
uint32 ofsVertices;
uint32 nViews;
//uint32 ofsViews;

uint32 nColors;
uint32 ofsColors;

uint32 nTextures;
uint32 ofsTextures;

uint32 nTransparency; // H
uint32 ofsTransparency;
//uint32 nI; // always unused ?
//uint32 ofsI;
uint32 nTexAnims; // J
uint32 ofsTexAnims;
uint32 nTexReplace;
uint32 ofsTexReplace;

uint32 nTexFlags;
uint32 ofsTexFlags;
uint32 nY;
uint32 ofsY;

uint32 nTexLookup;
uint32 ofsTexLookup;

uint32 nTexUnitLookup; // L
uint32 ofsTexUnitLookup;
uint32 nTransparencyLookup; // M
uint32 ofsTransparencyLookup;
uint32 nTexAnimLookup;
uint32 ofsTexAnimLookup;

float floats[14];

uint32 nBoundingTriangles;
uint32 ofsBoundingTriangles;
uint32 nBoundingVertices;
uint32 ofsBoundingVertices;
uint32 nBoundingNormals;
uint32 ofsBoundingNormals;

uint32 nAttachments; // O
uint32 ofsAttachments;
uint32 nAttachLookup; // P
uint32 ofsAttachLookup;
uint32 nAttachments_2; // Q
uint32 ofsAttachments_2;
uint32 nLights; // R
uint32 ofsLights;
uint32 nCameras; // S
uint32 ofsCameras;
uint32 nCameraLookup;
uint32 ofsCameraLookup;
uint32 nRibbonEmitters; // U
uint32 ofsRibbonEmitters;
uint32 nParticleEmitters; // V
uint32 ofsParticleEmitters;
};

- .anim files are only used for animations like dances or emotes which are seldom used in-game. Probably to speed up loading. On the m2 files they have gone from a long animation timeline (with every single animation covering only a slice of this timeline, based on their start and end times) to a multi-timeline approach where each animation has its own timeline, starting
at 0 with the length as defined in the animation sequence data structure.

They also dumped the interpolation ranges (as those aren't necessary anymore if each animation has its own timeline), and they have added another layer of references for the timestamp and value information. This means instead of the number of timestamps followed by the offset to said timestamps there's now the number of timelines followed by an offset to the timeline data. This offset leads to a structure of 8 bytes per timeline, with the first 4 bytes making up the actual number of timestamps for one specific timeline and the next 4 being an offset to the actual timestamp data. The keyframe values are stored in a similar fashion.

[Gawdlaw]

This explains alot.
Thanks Kitteh

Thread closed i guess

[Yamachi]

... the LOD mesh data ...

LODs are for bones, not meshes. Anyways, thanks for sharing this info with the rest of the community.