View Single Post
Old 26-03-20, 21:18   #19749
Krystian
Explorer
 
Join Date: May 2010
Posts: 959
Default

I'll give my 3 cents with a few extra bits of info
Quote:
Originally Posted by Kapu View Post
The coordinates have always confused me, because the WADMerger documentation says the units are based around 1024 being one square, but that's never quite worked for me. I've always had to experiment with changing the numbers little bit by bit to get the desired position. Someone with more experience can probably give you a more detailed explanation of this.
There is a discrepancy between the XYZ offset that wadmerger displays in the "Move" box when you manually move the meshes with the gizmo and how they are actually stored. The way they are actually stored is indeed the 1024 = one square system (and 256 being 1 click). But the way they are displayed in this box is by dividing the actual amount by 1024, so one square is equal to 1.0 (as a floating point decimal), a half block 0.5, one click 0.25. I don't know why this design choice was made and in the end it ends up being confusing rather than helpful.
But the setpositions do indeed follow the 1024 unit system (tried and tested, tracking Lara's XYZ coordinates after applying a test position confirms this).

---

As for why sometimes the offsets for setpositions are different (less or more of what you'd expect) - it's always based on Lara's origin. In WM, the origin is shown where the blue Line ends, at the elevation of the grid plane, while in TE's WadTool it's the intersection of blue lines (again on the grid plane). This means that the origin's location relative to Lara will be different for various animations. For most on land animations it's located at Lara's feet, but for swimming it's approximately located at her hip mesh (0), while for hanging, it's roughly midway between Lara's ankles and her knees.
Anyway, it is from this origin point that Lara's position will offset, and this must be taken into account when you have animations where the origin point changes its position relative to Lara. That's why for the climb up anim 97 there is -735, instead of something like -1024, Lara's origin point changes between the climb up and the default standing stance (indeed, making a block of height 735 upwards in an animating software like 3ds Max and placing it next to Lara's hands replicates what you would see in game).
And as it has been mentioned, calculating this offset is not so trivial, given that we have no way of precisely measuring heights inside WMs animation editor.

---

The third matter is why sometimes animations are split into two parts that apply a set position along one axis then another along another axis. This is due to how the engine works. Lara cannot cross solid room geometry in the process of being moved by a set position. In other words, you can't apply set positions in a way that if Lara were to move to the new location slowly instead of immediately, she would pass through a solid block. Again using the climb up animation as an example, the actual climb up animation (97) displaces Lara along the Y axis, then the animation it leads to (102) displaces Lara along the Z axis, to move her forward. Notice how this animation 102 takes this into account by having Lara moved forward a bit comparing to the normal standing animation 103. This is because the Z displacement will only kick in after the animation has finished.

If you do not follow this rule, then in case you have nothing but solid floor all the way down you won't see anything. But if you have a room below, Lara will fall through the room geometry to the bottom room, because the engine has registered it as Lara being inside a wall (or in this case, ceiling). You obviously don't want this, hence you should follow this two-step setposition rule. The average builder may not ever encounter this, but I have seen a few climb up animations that didn't take this into account and indeed resulted in Lara falling through the floor if there was a room below
The above doesn't apply to the 2-click and 3-click vaulting animations, but I guess the logic here is different, because you aren't changing the pivot between the animations, since both start and end in the standing animation.

I swear I once already made a little visual reference to illustrate it, but I can't find it, so I made it again:



I wrote a wall of text, but perhaps someone will stumble upon it in a few years and find it useful

As a small end note, I'll mention my theory that Core actually forgot to follow this rule correctly for the crawl backwards out of crawlspace move (289), because you can see that in this animation the Y displacement is applied first and in the subsequent (290) the Z displacement, which doesn't go in line with the "no crossing room geometry" rule. I believe they intented for Lara to go to the still hanging animation after this move was performed, but as Lara was ejected outside of the room geometry they couldn't get it to work as intended. So instead they "fixed it in post" by having Lara placed just before the ledge and performed the hard grabbing animation, as if from a forwards jump. It ended up looking jarring and ugly, but oh well. I should put this theory to the test now that I have more spare time, lol

Last edited by Krystian; 26-03-20 at 21:45.
Krystian is offline   Reply With Quote