Difference between revisions of ".animinstances file - M2TW"
m (Removed category "Battle Map Modification - M2TW"; Quick-adding category "M2TW Battle Map Modding" (using HotCat)) |
(watermark template) |
||
(4 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | + | {{M2TW Modding Logo}} | |
− | '''The .animinstances file is one of the [[Battle Map Buildings - M2TW|M2TW battlemap building]] world files. The .animinstances file used is specified inside the [[.world]] file.''' | + | '''The .animinstances file is one of the [[Battle Map Buildings - M2TW|M2TW battlemap building]] world files. The .animinstances file used, and the path to it, is specified inside the [[.world]] file.''' |
− | + | '''See [[Building Animations - M2TW]] for more general information about building animations and how to modify them.''' | |
− | + | The function of the .animistances file is to provide some of the information for the animated transitions that occur when some objects switch from undamaged to damaged group, or in the case of gates, open or close. | |
==File Contents== | ==File Contents== | ||
The .animinstances file contains a count of the total number of objects in the .world - if the .animinstances / [[.worldcollision]] and/or [[.world]] files have become mismatched and contain different numbers of objects that can cause a battle loading CTD. | The .animinstances file contains a count of the total number of objects in the .world - if the .animinstances / [[.worldcollision]] and/or [[.world]] files have become mismatched and contain different numbers of objects that can cause a battle loading CTD. | ||
− | The file then contains an entry for each object in order - that will either be a '0' for objects without an animation or will contain a binary segment for each transition for objects with an animation. The binary segments start with the name of the transition, followed by vertex coordinates for the starting position of the animation, and shading and effect illumination information for those vertexes at various stages of the animation. The binary segments are in compressed form, and need to be 'un-packed' to produce recognisable data. | + | The file then contains an entry for each object in order - that will either be a '0' for objects without an animation or will contain a binary segment for each transition for objects with an animation. The binary segments start with the name of the transition, followed by vertex coordinates for the starting position of the animation, and shading and effect illumination information for those vertexes at various stages of the animation. The binary segments are in compressed form, and need to be 'un-packed' to produce recognisable data. The compression used is the LZO system as used for other in-game packed files. |
The file does not contain rotation or bone assignment data, or texture or uv mapping data. | The file does not contain rotation or bone assignment data, or texture or uv mapping data. | ||
Line 21: | Line 21: | ||
The .mesh files, located in data/blockset/culture/animations/etc contain the bone assignments for each vertex involved in the animated model, the texture name/path to be used, and the UV mapping used. | The .mesh files, located in data/blockset/culture/animations/etc contain the bone assignments for each vertex involved in the animated model, the texture name/path to be used, and the UV mapping used. | ||
− | |||
− | |||
− | + | ==Relationship to .worldcollision volume== | |
+ | The coordinates contained in the animinstances file are related to a 0,0,0 position, the file does not contain the coordinate data for the animation in relation to the settlement plan. | ||
− | + | The animation appears in-game aligned with the object's collision volume as defined by the[[.worldcollision]] file, the .worldcollision file provides the displacement for the collision (and hence also the animation) from 0,0,0 and 0 rotation, to the object's position in the .world. | |
− | + | Animations appearing in the 'wrong' location will usually be because the collision volume doesn't align with the visible object. Loading a new animation that didn't start centered properly on 0,0,0 will also cause a mismatch. | |
− | + | ==Shading and Effect Lighting== | |
+ | Vanilla .animinstances entries also include, in the packed section, texture shading information and intensity of adjacent effect information recorded against each vertex. This contains values for both shading and effect information at the start of the animation and at the end of the animation, this appears to be why some swing gates gradually go black when held in the open position, it also explains why transplanting an .animinstances chunk from a vanilla file to one with fewer effects causes the "disco lighting" problem. If an effect number is referenced, and the .world file does not have an entry for that many effects, the game gets confused and applies some multi-coloured lighting! | ||
− | + | These aspects of the .animinstance chunks are unique to each object - if re-using an existing chunk is causing problems you may find copying a chunk from another object using the same animation (ideally one far away from effect light sources) works better. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
[[Category:M2TW Battle Map Modding]] | [[Category:M2TW Battle Map Modding]] |
Latest revision as of 10:13, 25 May 2020
The .animinstances file is one of the M2TW battlemap building world files. The .animinstances file used, and the path to it, is specified inside the .world file.
See Building Animations - M2TW for more general information about building animations and how to modify them.
The function of the .animistances file is to provide some of the information for the animated transitions that occur when some objects switch from undamaged to damaged group, or in the case of gates, open or close.
Contents
File Contents
The .animinstances file contains a count of the total number of objects in the .world - if the .animinstances / .worldcollision and/or .world files have become mismatched and contain different numbers of objects that can cause a battle loading CTD.
The file then contains an entry for each object in order - that will either be a '0' for objects without an animation or will contain a binary segment for each transition for objects with an animation. The binary segments start with the name of the transition, followed by vertex coordinates for the starting position of the animation, and shading and effect illumination information for those vertexes at various stages of the animation. The binary segments are in compressed form, and need to be 'un-packed' to produce recognisable data. The compression used is the LZO system as used for other in-game packed files.
The file does not contain rotation or bone assignment data, or texture or uv mapping data.
Related Files
.anim Files
The .anim files, located in data/blockset/culture/animations/etc contain the key frames for the animation, its rotations and movements. The .anim file used is specified inside the .world file.
.mesh Files
The .mesh files, located in data/blockset/culture/animations/etc contain the bone assignments for each vertex involved in the animated model, the texture name/path to be used, and the UV mapping used.
Relationship to .worldcollision volume
The coordinates contained in the animinstances file are related to a 0,0,0 position, the file does not contain the coordinate data for the animation in relation to the settlement plan.
The animation appears in-game aligned with the object's collision volume as defined by the.worldcollision file, the .worldcollision file provides the displacement for the collision (and hence also the animation) from 0,0,0 and 0 rotation, to the object's position in the .world.
Animations appearing in the 'wrong' location will usually be because the collision volume doesn't align with the visible object. Loading a new animation that didn't start centered properly on 0,0,0 will also cause a mismatch.
Shading and Effect Lighting
Vanilla .animinstances entries also include, in the packed section, texture shading information and intensity of adjacent effect information recorded against each vertex. This contains values for both shading and effect information at the start of the animation and at the end of the animation, this appears to be why some swing gates gradually go black when held in the open position, it also explains why transplanting an .animinstances chunk from a vanilla file to one with fewer effects causes the "disco lighting" problem. If an effect number is referenced, and the .world file does not have an entry for that many effects, the game gets confused and applies some multi-coloured lighting!
These aspects of the .animinstance chunks are unique to each object - if re-using an existing chunk is causing problems you may find copying a chunk from another object using the same animation (ideally one far away from effect light sources) works better.