Talk:M2: Difference between revisions

From wowdev
Jump to navigation Jump to search
No edit summary
Line 82: Line 82:
Thanks for all your work here! :)
Thanks for all your work here! :)


- Auhem
- Wain


* the second table was created by relax by tracing directx stuff in the MoP client, the first one was later created by schlumpf based on reverse engineering the WoD beta client. The first table assumes alpha test to be the same, the second one lists them separate. there might be errors in both, tbh. feel free to fix them if you find them, or come to quakenet#modcraft to discuss them. :) --[[User:Schlumpf|Schlumpf]] ([[User talk:Schlumpf|talk]]) 16:47, 14 October 2015 (UTC)
* the second table was created by relax by tracing directx stuff in the MoP client, the first one was later created by schlumpf based on reverse engineering the WoD beta client. The first table assumes alpha test to be the same, the second one lists them separate. there might be errors in both, tbh. feel free to fix them if you find them, or come to quakenet#modcraft to discuss them. :) --[[User:Schlumpf|Schlumpf]] ([[User talk:Schlumpf|talk]]) 16:47, 14 October 2015 (UTC)

Revision as of 13:57, 14 November 2015

Finished for Build 8820 now. Post changes here first! And please pay attention to the style when you add something.. --schlumpf_ 00:53, 23 August 2008 (CEST)

Animation blocks in WotLK

  • Previously M2s used a single-timeline approach, chaining all animations into one long piece and separating them via begin and end given in animation data. Now, each animation has an own timeline.
  • Animation blocks contain a list of lists of timestamps and a list of lists of values, where the first list is by animation and the second one by timestamp-entry.
 template<typename T>
 struct array_ref
 {
   uint32_t number;
   T* elements;  // in file obviously an offset only
 };
 
 template<typename T>
 struct animation_block
 {
   uint16_t interpolation_type;
   uint16_t global_sequence;
   array_ref<array_ref<uint32_t>> timestamps;
   array_ref<array_ref<T>> values;
 };
  • Thus, as example, with
 struct bone
 {
   int32_t bone_id;
   uint32_t flags;
   int16_t parent_bone;
   uint16_t _1[3];
   animation_block<vec3_float> translation;
   animation_block<quat_short> rotation;
   animation_block<vec3_float> scale;
   vec3_float pivot;
 } b;

one may get the number of animations having translation information with

 b.translation.timestamps.number

and the number of timestamps in the first animation using

 b.translation.timestamps.elements[0].number

and the first timestamp value of the first animation via

 b.translation.timestamps.elements[0].elements[0]

The actual translation vector for animation 0 at timestamp 0 is at

 b.translation.values.elements[0].elements[0]
  • Some timestamps/values.elements entries may have number/elements = 0, if for that animation id no animation is given.
  • .anim files are just a blob of data which may as well be in the main model file, that is pointed to by the first array_ref layer.
  • [model file name][animation id]-[animation sub-id].anim
  • it seems like it is possible to detect if animation data is stored in-m2 or externally via
    • All animations which have flags & 0x20 are stored internally.
    • Animations which do not have flags & 0x20 are not stored internally.
    • Animations which do not have flags & 0x20 AND do not have flags & 0x40 are in .anim files
    • Animations which do not have flags & 0x20 AND DO have flags 0x40 are stored... somewhere. I have no clue.

Deleted Blocks

Block D

  • nD records of (int16, int16) starting at ofsD

Maybe a lookup table for animations? Since the numbers happen to be in fixed positions. The first short seems to increase with the position for models with all animations (like characters), the second seems to be flags or a modifier? Or something.


Contain indices into the texture animations list, or -1 meaning a static texture.


Render Flags

Please forgive any ignorance I show here as I'm not a professional programmer. I'm just trying to help improve Wow Model Viewer, which has very few staff left and these pages have been invaluable for understanding it :) I just wanted to mention something that confused me and I'm not sure if it needs correcting...

The Render Flags section of this page has two different tables for blend modes, with no mention of what the difference is. Is one out of date? The settings they recommend are different for a few modes, but they agree on others. I also tried them out in WMV and found that blend mode 1 is not working right with the settings from the tables (sections are appearing completely invisible when they shouldn't be) so maybe it's out of date in both, or there's something I'm not understanding. Perhaps it's meant to be used in conjunction with GL_ALPHA_TEST or glAlphaFunc() or something.

Thanks for all your work here! :)

- Wain

  • the second table was created by relax by tracing directx stuff in the MoP client, the first one was later created by schlumpf based on reverse engineering the WoD beta client. The first table assumes alpha test to be the same, the second one lists them separate. there might be errors in both, tbh. feel free to fix them if you find them, or come to quakenet#modcraft to discuss them. :) --Schlumpf (talk) 16:47, 14 October 2015 (UTC)
  • Aha! Thanks very much :) I'll experiment with the modes more and see what I can find.

-- Wain


Particle Emitters

I'm not yet sure what to do with the new parameters: MultiTexParamX (2 values), and MultiTexParam0 and MultiTexParam1 (each two pairs of x and y values).

Below I've included values for a sample of models that use multitextured particles, along with some other parameters from the same particle emitter structure. You'll note that some of the texture tile rotation values are also unusual, as they are expected to be -1, 0 or 1.

Only particles that have multitexturing flagged are included, as the rest always seem to have zero for these parameters.


Blend Emitter Texture MultitexParamX MultitexParam0 MultitexParam1
Type Type Tile Rotat [0] [1] [0].x [0].y [1].x [1].y [0].x [0].y [1].x [1].y
moosemount.m2
7 2 7 0.1875 0.09375 0.0234375 0.0234375 -0.0136719 -0.0136719 0.00585938 0.00585938 0.00585938 0.00585938
2 2 4 0.5 0.6875 0 0.138438 0 0.138438 0.0488281 0.0488281 0.0234375 0.0234375
2 1 4 0.5 0.6875 0 0.0996094 0 0.0488281 0.00976562 0.00976562 0.00390625 0.00390625
saber2mount.m2
4 1 0 0.78125 1 0 0.0996094 0 0 0 0 0 0.0996094
4 1 0 0.375 0.28125 0 0.0996094 0 0 0 0 0 0.0996094
ironhordeclefthoof.m2
7 1 1 0.25 0.4375 0 0.298828 0 0.199219 0.0585938 0.0585938 0.0488281 0.0488281
ironhordeelekk.m2
7 1 1 0.25 0.4375 0 0.298828 0 0.199219 0.0585938 0.0585938 0.0488281 0.0488281
ironhordewolf.m2
2 1 0 0.09375 0.1875 0.0292969 0.0292969 -0.0292969 0.0292969 0.00390625 0.00390625 0.00390625 0.00390625
7 1 1 0.25 0.4375 0 0.298828 0 0.199219 0.0585938 0.0585938 0.0488281 0.0488281
archimonde3.m2
7 1 5 0.5 0.25 0 0.199219 0 0.199219 0 0.138438 0 0.138438
voidcaller_v2.m2
2 2 -3 1 1.375 0 -0.199219 0 -0.298828 0.0996094 0.0234375 0.138438 0.0488281
2 2 -1 0.5 0.6875 0 0.0488281 0 0.0742188 0.0234375 0.0234375 0.00390625 0.00390625
7 2 2 1 0.5 0 0 0 0 0 0 0 0
7 2 0 0.5 0.1875 0 0 0 0 0 0 0 0
7 1 0 0.5 0.1875 0 0 0 0 0 0 0 0
lavahorse.m2
7 1 5 0.5 0.25 0 0.199219 0 0.199219 0 0.138438 0 0.138438
4 1 0 0.25 0.5 0 0.00976562 0 0.0195312 0.00195312 0.00195312 0.00195312 0.00195312
corehound2.m2
7 1 0 0.25 0.4375 0 0.298828 0 0.199219 0 0.0488281 0 0.0488281
4 1 0 0.25 0.5 0 0.00976562 0 0.0195312 0.00195312 0.00195312 0.00195312 0.00195312
dreadravenwarbirdfel.m2
4 1 0 0.25 0.5 0 0.00976562 0 0.0195312 0.00195312 0.00195312 0.00195312 0.00195312
7 1 0 0.25 0.4375 0 0.298828 0 0.199219 0 0.0488281 0 0.0488281
dreadravenwarbirdsun.m2
4 1 0 0.25 0.5 0 0.00976562 0 0.0195312 0.00195312 0.00195312 0.00195312 0.00195312
7 1 0 0.25 0.4375 0 0.298828 0 0.199219 0 0.0488281 0 0.0488281

-- Wain (talk) 14:57, 4 November 2015 (UTC)