www.tombraiderforums.com  

Go Back   www.tombraiderforums.com > Tomb Raider Modding > Tomb Raider Level Editor > Tutorials and Resources

Closed Thread
 
Thread Tools
Old 04-05-20, 11:12   #1
Krystian
Explorer
 
Join Date: May 2010
Posts: 965
Default Set positions - everything you need to know

Hello, in this guide/tutorial I'll be sharing a couple of tips regarding set positions and getting the proper offsets when you are designing new moves which require Lara to move to a different position. After many years of working on custom animations, and also knowing about some of the internal workings of the TR engine, I’ve gained some experience which I will share now and hope will be of use to other people in the community

Set positions seem very basic on the surface level, but as it turns out, they can be quite elusive once you take a closer look at them or try to do something specific with them. I will start with the most basic aspects of this particular animation command and I’ll gradually move to more complex topics.
Krystian is offline  
Old 04-05-20, 11:19   #2
Krystian
Explorer
 
Join Date: May 2010
Posts: 965
Default First off, the basics - what are set positions?

Set positions are a type of animation command (or anim command for short) that can be included in animations. They are defined by three values - the X displacement, the Y displacement and the Z displacement. These displacement values will be added to Lara's current in-game coordinates.

When are set positions used? When there is an animation that moves Lara from position A to position B in a non-continuous way. What do I mean by non-continuous? Well, a continuous movement is done e.g. in animation #0, the running animation. Here Lara’s movement is taken care of via the “speed” field, which indicates how many “game units” Lara will be moved per frame, but that’s beyond this topic. An example of non-continuous movement are the anims for vaulting 2-click and 3-click high blocks (animations #50 and #42, respectively). Another example is the pull-up animation (#97), though this is a more interesting case that will be covered later.


The units for this displacement are equal to in-game units, where 1 sector (square) is 1024 units and 1 click is 256 units. The offsets are applied only after the animation is finished (so once Lara begins the animation set in the “Next Animation” field). It doesn't matter how long or how short the animation is, it’s always after the current animation has ended and once the next one has started.
The axes are set up the following way: negative X values will move Lara to her left, positive X values will move her to her right. Negative Y values will move Lara upwards, positive values will move her downwards. Negative Z values will move Lara backwards, positive values will move her forwards.


Examples of set positions could be:
Code:
X	Y	Z
0	-1024	0
128	0	256
-256	768	-256
The first one will move Lara 1 sector (4 clicks) upwards. The second will move Lara 0.5 click to the right and 1 click forwards. The third will move Lara 1 click to the left, 3 clicks downwards and 1 click backwards. Of course, the values can be any number of units, from 0 to just 1 to several thousands, covering several sectors of distance (though using huge displacements can be buggy, so beware of that).

Here is a real example of a set position taken from the ladder pull up anim (#174), as a screenshot from WadMerger and WadTool, respectively:





It moves Lara 50 units to her left and 512 units upwards.


Another important thing to note is that the movement that gets applied to Lara is always relative to Lara’s current facing, i.e. the direction where she’s looking at, not the global X Y Z axes. So when Lara is turned e.g. 45 degrees and has a set position (0, 0, 1024) applied, Lara will be moved on both the X and Z global axes, so that the distance which Lara moves by is 1024 game units (according to the Pythagorean theorem). In this case the absolute (abs) value of the real x and z offsets will be between 0 and 1024, depending on the facing (angle).



Code:
d^2 = dx^2 + dz^2
0 <= abs(dx) <= 1024
0 <= abs(dz) <= 1024

Last edited by Krystian; 05-05-20 at 08:36.
Krystian is offline  
Old 04-05-20, 11:38   #3
Krystian
Explorer
 
Join Date: May 2010
Posts: 965
Default Set positions are also relative to Lara’s origin

As we’ve learned in the section above, the set positions get applied relative to Lara’s current facing. But how do we know from which part of Lara these offsets are calculated and applied? A good guess would be Lara’s hip mesh (#0) or from Lara’s feet, for instance. But the real answer is – it depends. It depends on where the origin is located, relative to Lara. How can you check where this origin is located? It’s impossible to check in game, but it is possible to see in a “first-party” animation editor like WadMerger’s Animation Editor or WadTool’s Animation Editor. In case of WM’s Anim Editor, it’s where the blue line on the grid ends. In WT’s Anim Editor, it’s where the two perpendicular blue lines cross each other. It is always this point that is used as reference for calculating Lara’s new position. Below are screenshots with the origin point marked in WadMerger and WadTool, respectively.







Why is this important? If you skim through Lara’s various animations, you’ll see that the origin point changes its position relative to Lara in different animations. And thus for the majority of on-land animations it’s located at Lara’s feet, but for the hanging animation (#96) it’s roughly midway between Lara’s ankles and her knees, for surface swimming animations (#116) it’s about at Lara’s neck, while for underwater swimming animations (#108) it’s at Lara’s hip mesh. When the origin point doesn't change between animations, you can just calculate difference in coordinates between the ending frame of the previous animation and the starting frame of the next animation*. But when the relative location of the origin point changes between animations, you need to take it into account when calculating the set position offsets between those animations.


Unfortunately there is no easy way to measure distances in WadMerger Animation Editor (not sure about WadTool), so when the origin changes, it's hard to estimate needed offsets for the set position. When you export the animations into a third-party animating software like 3ds Max, the origin should stay the same as in the Wad and the distances should be equivalent, so creating a block of 1024x1024x1024 dimensions should be identical to a TRLE block. You can use this to measure and approximate the changes in position and get the right offsets for the set position.
Of course, for many animations you already have a basis for what the proper set-positions should be. Let’s take the pull-up anim (#97) as an example, where there is a change between the hanging origin (Lara’s calves) and the standing origin (beneath Lara’s feet). You may at first glance expect a set position of -1024 units on the Y axis to move Lara a sector upwards. But actually it’s -735, due to the change between the relative origin positions. And we can confirm this in e.g. 3ds Max. Making a 735 units high block and moving it to Lara’s hands closely replicates what you would see with in-game ledges.


You may also notice that in fact the set position in the pull up anim isn’t applied in one go, but is split into two parts, first the vertical offset (in #97), then the horizontal one (in #102). I’ll go over the significance of this in the next section.


*A small note regarding WadMerger’s Animation Editor – the position values that are displayed in the “Move” box are really divided by 1024. 1.0 is one sector, 0.25 is one click and so on. So if you have Animation Editor coordinates you want to convert to units for usage in set positions, multiply these fractional values by 1024 and round them to nearest integer (whole-number) value. BUT, in the "fixed" WadMerger by Paolone, you have a second box with coordinates in the bottom right of the window that displays regular "unit" values, however they only display once you start moving Lara (thanks Joey79100!). WadTool on the other hand always displays proper “unit” values, so no multiplication is necessary.

Last edited by Krystian; 05-05-20 at 08:39.
Krystian is offline  
Old 04-05-20, 11:45   #4
Krystian
Explorer
 
Join Date: May 2010
Posts: 965
Default Why some animations have split set positions

You may have observed that actually the set position for anim 97 (moving Lara upwards and forwards) isn’t applied in one go, but only the vertical offset (-735) is applied in #97, then there is single-frame follow up animation (#102) that applies the forwards offset (200). Notice how this animation takes this into account by having Lara moved slightly forward. This is because the horizontal offset wasn’t applied yet and it will only get applied once anim 102 finishes (if Lara wasn’t moved forward, in game she would be appear to be moved back after anim 97 ends). Only after this second offset is applied, it goes to #11, which is a single-frame transition to #103, the standing animation loop.
Whew, what a complicated mess! But why such redundancy? Wouldn’t it be easier to just apply the set-position once, with combined offsets (0, -735, 200), so you could go directly from #97 to #11? It would be easier, but this splitting of set positions into two separate steps isn’t as “redundant” as it may seem initially.


Admittedly this is not very well known, but there is a concrete reason for this splitting. What happens when you apply a set position? Lara is moved immediately from position A to B. Now picture that instead of instant movement, Lara moves gradually, in some time. Now, imagine this gradual movement occurs where there is solid room geometry involved, like in the case of the ledge pull-up anim #97. In this case, in the process of being moved, Lara intersects with solid room geometry. This is bad. It’s bad because the engine sees it as Lara being inside a wall. And when that happens, the engine will do whatever it can to get her out of there.

As a side-example, take the well-known corner bug, it relies on this very phenomenon. In the process of going into the wall corner, Lara will suddenly get shifted to the top of the block, because of the engine functions of getting Lara out of walls. Something similar happens when this occurs through improper set positions – Lara is “inside a wall” and the engine moves her out, whatever way possible. If the floor below Lara is solid all the way down – you’re in luck and you won’t see anything out of the ordinary, since Lara will end up on top. The real weirdness occurs if there is a room below the ledge Lara has climbed – in this case Lara will fall through the room geometry, dropping through the ceiling to the room below! There are a few custom ledge animations that have this unfortunate bug, all because of the set position being done in “one go” instead of the separated two-step approach. Or if you still don’t believe me, try it out yourself! Change the set position of anim #97 so that both offsets are applied at once (0, -735, 200) and set #11 as next animation. If Lara climbs on a ledge with a room below it, Lara will fall down to the bottom room!
Here is a small graphic that shows the incorrect and correct ways of applying set positions:




It’s not only the normal pull up animation that has this splitting, but also the ladder pull-up (#174, going to #102 again) and crawlspace pull-up (anims #287 and #288). You should also follow this rule whenever you’re designing new moves that require Lara to move around room geometry. Like I did in my Monkey to Overhead Ladder move, which you are welcome to inspect. Here I needed to first apply the horizontal offset, then the vertical one to meet the “no crossing room geometry” requirement.
And even though the 2-click (#50) and 3-click (#42) vaulting animation don’t follow this two-step rule with their set positions, as noticed by Joey79100, having some hollow space underneath the ledge which is vaulted will cause Lara to snap back to her original position (and to fix this, you should split the set positions as described, to avoid crossing room geometry).


So to reiterate – whenever there is a situation where Lara must cross between room geometry, the set positions must always be applied in an order where Lara curves around the ledge, wall corner or whatever, and never goes inside it or moves diagonally across it, else you will get strange and unwanted behaviour as described above.
Krystian is offline  
Old 04-05-20, 11:56   #5
Krystian
Explorer
 
Join Date: May 2010
Posts: 965
Default Set position anim commands as exported TRNG triggers

This section is only relevant to TRNG, if you’re not using it, you can skip to the next section.

I’ll briefly cover the topic of using set positions to execute various TRNG triggers (flipeffects, action triggers, technically conditions are also possible). Paolone added the ability to export almost all of the new TRNG triggers to a “set position” form, that will be executed at a particular frame of the animation that contains that special set position. They won’t actually perform any movement, they will only activate the trigger which they express, at a particular frame. These special set positions can be immediately recognized by a “huge” negative X offset. Something in the area of -24575 or -32767.
A bug note about this and fixed WadMerger version: When you have any negative X offset in a SetPosition, it will be displayed in the Anim Command panel as if it was an exported trigger. This is not the case, it's just a regular set position that will move Lara. As I've said, actual exported triggers have hugely negative X values, at least in the -24575 range.

If you suspect the set position could be an exported trigger, it’s possible to trace back in NGLE what are the parameters of this exported TRNG trigger to learn what it does. You press “Find Trigger” button and type the 3 values of the setposition, enclosing them in square brackets, so you get:



And then you press OK to locate the trigger, its parameters and what is the frame of execution.


And to export such a trigger, it’s just as easy – just select the trigger parameters you want and press the “Export AnimCommand” button in the NGLE trigger panel:



You will be asked at which frame the animcommand should get executed (you may get another prompt asking for something else, depending on the type of trigger).



Enter your desired frame number (make sure the animation actually has such a frame number!) and click 'OK'. You will get txt window which will contain the set position offsets you need to add to the animation.




If you need to execute multiple triggers in the same frame (or use a condition before the trigger itself), it’s better to export an anim command for a triggergroup with particular ID (like Flipeffect 371), and then make a TriggerGroup script with that ID, having your desired trigger sequence.
I won’t go over each trigger, you’ll have to use your own creativity to find various ways how you could use them in anim commands. But I can tell you about two I use frequently:
  • Flipeffect 102, which is similar to the “Flip Orient” flipeffect 0 (it can be added directly by the “Add Effect” anim command), rotating the object owning the animation by 180° angle. Except this new flipeffect 102 can do also angles 45°, 90°, 135° and 180°, in the clockwise and anti-clockwise direction. This is very convenient if you want to make Lara turn by 90° in your animation, since there is no way to traditionally do this in TRLE, the various 90° turns were always hardcoded to specific stateIDs.
  • Another one I use often is Flipeffect 214, which allows to execute a Parameters= PARAM_SET_CAMERA command from script, and I use this to customize the camera with some animations. Remember also to use Flipeffect 215 to cancel any PARAM_SET_CAMERAs that were activated “forever” with F214.

Last edited by Krystian; 05-05-20 at 07:35.
Krystian is offline  
Old 04-05-20, 13:11   #6
Krystian
Explorer
 
Join Date: May 2010
Posts: 965
Default Set positions and orient-changing flipeffects

You may make a new animation at the end of which Lara changes her facing compared to what she started with. And this animation may also require a set position to move Lara to the new destination. The way these animations are constructed is quite strange, the part of the animation that follows the frame with the rotation effect (and including that frame) must be rotated about the origin by the opposite angle as the rotation effect (except 180°, it's the same both directions ;). It is not enough to just rotate Lara by her hip mesh (#0), you must rotate the entire animation about the origin (luckily my Animation Utilities can seamlessly do the job for you! Okay, this was the last self-advertisement, I promise!). And because the rotation actually occurs during the animation, you must also re-adjust the set position offsets so they take this rotation into account.

When it comes to orient-changing flipeffects, there’s the traditional flipeffect 0, which can be added as an “Add effect” anim command and rotates by 180°, as well as the new F102 which can do any angles of 45° increments, in both directions. These changes get executed immediately at a particular frame, unlike the set positions, which are applied after the anim ends.
To get the new offsets after the rotation, you could try to measure the distances from the origin and try to eyeball the new offsets from there, but that’s unnecessarily complicated and unreliable, there are easier ways that will give you accurate results. Bottom line is that the Y displacement always stays constant, no matter how you turn the animation. What will change is the X and Z displacements.

Classic 180° turn

If you apply the classic flipeffect 0 that turns by 180°, then the matter is simple, you just change the sign of the X and Z displacements. If the non-adjusted setposition was (-256, -1024, 512), after the adjusting it will become (256, -1024, -512). We changed the +/- signs for the X value and Z value, and didn’t touch the Y value. This exhausts the capabilities of classic TRLE, but with TRNG more follows:

TRNG 90° turns

Things get a bit more complicated with 90° turns. You should rotate the animation in the opposite direction of the turn flipeffect, so when the turn occurs, Lara is at the same spot as before (it may seem counter-intuitive at first, but if you think about it, it makes sense. For Lara to "arrive" at the same location as before the turn, she must be moved 90° the opposite direction, so it "cancels out" after the turn). Keep in mind the distinction between the turn in the added flipeffect and the actual turn in the animation, as it can get confusing quite quickly (I actually got pretty confused myself while writing this). When speaking about the set position adjustments, I'll be referring to the animation turns, not the flipeffect turns!

For the set position you have to swap the displacement values between X and Z, and also change the sign of one or the other. We can divide it into two cases:
  • When it’s a clockwise (right) animation turn, you swap values between X and Z and change +/- sign of the swapped Z value. In a right turn (-256, -1024, 512) becomes (512, -1024, 256).
  • When it’s an anti-clockwise (left) animation turn, you swap values between X and Z, but this time change +/- sign of swapped X value. (-256, -1024, 512) becomes (-512, -1024, -256).

It's tricky to get it correct, but I’ll say it again:
When you want to rotate left, you add a left rotation flipeffect, you rotate the animation right and swap X with Z and flip (+/-) Z.
When you want to rotate right, you add a right rotation flipeffect, rotate the animation left and swap X with Z and flip (+/-) X.

I know it may still be confusing, see my Sideways Dismounting animations (oh no, I self-advertised again!) as an example of these 90° turns. The turning flipeffect is applied in the penultimate frame of the animations, so the last two frames are rotated accordingly (opposite to the flipeffect direction). Initially, before the adjustment the set position was (-100, 256, -63) for the left variant, so I applied a left turn flipeffect and right animation turn, giving (-63, 256, 100) for the final offsets. For the right variant it was (100, 256, -87) pre-adjustment, so I applied a right flipeffect turn and a left animation turn, giving final offsets (87, 256, 100) for the right variant.

TRNG 45°/135° turns

The most difficult case is when you have a 45° or 135° turn in either direction. I personally never used such angles before, but nonetheless it’s a possibility and you could find some use for it. Of course you have to rotate the animation in the opposite direction as the flipeffect to do it correctly. To calculate the offsets changes in this case, there is no easy way and we’ll have to use the scary thing that haunts many school students around the globe – TRIGONOMETRY. But relax, it’s not that complicated, it’s just a simple formula you can enter in a calculator, excel or whatever
To get the offset changes, we will use the formulas below:
  • For clockwise (right) animation turn (i.e. left flipeffect turn):
Code:
NewX = OldX * cos(angle) + OldZ * sin(angle)
NewZ = OldZ * cos(angle) - OldX * sin(angle)
  • For anti-clockwise (left) animation turn (i.e. right flipeffect turn):
Code:
NewX = OldX * cos(angle) - OldZ * sin(angle)
NewZ = OldZ * cos(angle) + OldX * sin(angle)

As you see, not scary! OldX and OldZ are the non-adjusted X and Z offsets, angle is the rotation angle (45° or 135°, just be sure your calculator/program is set to degrees and not radians). And cos and sin are the cosine and sine trigonometric functions, of course. These formulas will still work for the other angles (90°, 180°), but in those cases you don’t need to use them if you just remember what you need to change and swap.


This above formula also explains what actually happens in game with the set positions and Lara’s facing, which is plugged into the formula as the angle. The X and Z offsets from the set position get trigonometrically altered in-game, so you get the proper X and Z offsets according to Lara’s facing, even though there was just a single, concrete set position specified in the animation.

Last edited by Krystian; 05-05-20 at 08:45.
Krystian is offline  
Old 04-05-20, 13:12   #7
Krystian
Explorer
 
Join Date: May 2010
Posts: 965
Default The end!

We’ve reached the end of this tutorial/guide. Hopefully you’ve found above insights useful – if you made it this far (especially after the last section), now you know practically everything there is to know about set positions, so congratulations!
Krystian is offline  
Closed Thread

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT. The time now is 04:17.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.