25-03-20, 22:26 | #19741 |
Member
Joined: Nov 2009
Posts: 1,734
|
Thanks so much for that offer, Kapu!
I Messaged you. |
26-03-20, 13:42 | #19742 |
Member
Joined: May 2019
Posts: 348
|
@Joey79100 & TR-Freak
Wow, both you guys' post are amazing. I never thought about the engine this way. I'm still trying to wrap my head around this concept entirely. Although, I do kinda understand. Was this the first time this method was used in the TR series? |
26-03-20, 19:26 | #19743 |
Member
Joined: Jul 2010
Posts: 256
|
Quick question: How does the SET POSITION command work in the Animation Editor? (WadMerger, WadTool, you name it).
At first I thought that you needed to put Lara's pivot position of the next animation to teleport her there, but inspecting other animations (like the 2 click climb up) it looks like you need to put the offset to add\remove to Lara's current pivot position. However, the actual numbers inserted by CORE don't seem to line up precisely... I'm not sure how to use the command... |
26-03-20, 19:44 | #19744 |
Unverified
Joined: Jan 2008
Posts: 5,140
|
you exactly put the offset into it.
Most transition animations consist of two parts. One has the Y component and the end animation has the Z component. |
26-03-20, 19:49 | #19745 | |
Member
Joined: Feb 2009
Posts: 3,852
|
I can remember finding an overlapping room in TR1! When I was playing I had this moment of...wait a minute, this room is so long it would be cutting into the adjourning room...and then I realized they were overlapping. I'm pretty sure it wasn't deliberate, though. It was in one of the Cistern levels...if I have some time I'll look and see if I can find the exact spot.
Quote:
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. |
|
26-03-20, 19:53 | #19746 | |
Member
Joined: Mar 2012
Posts: 3,741
|
Deliberately? Maybe. Accidentally? I don't remember (this was discussed somewhere on TRF already), but I think they might have. And they definitely did too in TR4 (I remember Karnak), and I don't know about TR5.
Quote:
Where it is confusing is that there are some edge cases where the position you want her to move isn't really intuitive... mostly the animations where she's hanging to a ledge, because her vertical position is not fixed but calculated in real-time based on her collision box (why they did it like that I'm not really sure). So to climb up, she actually goes 735 units up (-735, because negative is upwards), assuming you're using regular animations (animation 96 frame 21 is what matters here, because that's the "animation" for her hanging still on a ledge). But the animation is split, so she only goes up, and then on the next animation she goes forward. Your best bet is just use original values as a basis, and then use trial and error for these annoying cases. But other cases should be easy to figure. |
|
26-03-20, 19:54 | #19747 |
Member
Joined: Nov 2004
Posts: 1,531
|
There is a caveat to this. I remember working with titak on a new climbing animation and ended up using trial and error to get the correct set position coordinates. For some reason there was an additional hardcoded change that threw off the numbers. There’s probably very few times this happens though.
|
26-03-20, 21:39 | #19748 |
Member
Joined: Jul 2010
Posts: 256
|
Thank you Joey! So I was right after all.
|
26-03-20, 22:18 | #19749 | |
Member
Joined: May 2010
Posts: 1,187
|
I'll give my 3 cents with a few extra bits of info
Quote:
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 22:45. |
|
27-03-20, 00:05 | #19750 |
Unverified
Joined: Jan 2008
Posts: 5,140
|
Did you know that you can have the "Classic Pickup" without TRNG script?
For some reason, Lara's "Next StateID" doesnt change from adjusting to pickup. You need to add an Anim Change with the 4 walk animations (0,1, 22,21) and link it to the second part of the animation. |
Thread Tools | |
|
|