www.tombraiderforums.com

Go Back   www.tombraiderforums.com > Tomb Raider Modding > Tomb Raider Level Editor > Software Development

Reply
 
Thread Tools
Old 15-06-15, 00:34   #1521
Lwmte
Explorer
 
Lwmte's Avatar
 
Join Date: Aug 2010
Posts: 987
Default

Actually, setting up limits and softness for joints is the most tricky part with ragdolls, and that's why ragdolls may look too unnatural in contemporary games. I also have problems setting limits, because I can't understand Euler angles properly.

Still, I believe ragdoll deaths are much more natural than pre-rendered animations - because it doesn't rely on collisional geometry. The best way (and the way we're implementing it) is to play normal death animation up to a certain frame, and then switch to ragdoll mode. This looks much better than LAU-styled ragdolls.
Lwmte is offline   Reply With Quote
Old 15-06-15, 00:54   #1522
Boobandie
Professor
 
Join Date: Jul 2012
Posts: 3,837
Default

What about playing the full animation but if a bodypart collides with something just that part is switched to ragdoll? Or inverse kinematics?

Last edited by Boobandie; 15-06-15 at 00:59.
Boobandie is offline   Reply With Quote
Old 15-06-15, 07:50   #1523
Titak
Moderator
 
Titak's Avatar
 
Join Date: Jul 2003
Location: Drenthe, The Netherlands
Posts: 32,304
Default

Quote:
Originally Posted by Lwmte View Post
Actually, setting up limits and softness for joints is the most tricky part with ragdolls, and that's why ragdolls may look too unnatural in contemporary games. I also have problems setting limits, because I can't understand Euler angles properly.

Still, I believe ragdoll deaths are much more natural than pre-rendered animations - because it doesn't rely on collisional geometry. The best way (and the way we're implementing it) is to play normal death animation up to a certain frame, and then switch to ragdoll mode. This looks much better than LAU-styled ragdolls.
Ah, I sort of figured it wasn't easy to make realistic ragdoll effects.
Oh well.

And yes, ragdoll deaths are indeed much more natural.
I like the idea of starting out with the regular death animation(s) and then switch to ragdoll during those animations.
__________________
If it walks like a duck and if it quacks like a duck, it is a duck.
Titak is offline   Reply With Quote
Old 15-06-15, 08:37   #1524
Uzi master
Relic Hunter
 
Uzi master's Avatar
 
Join Date: Jul 2009
Location: Canada
Posts: 6,586
Default

Definitely the better solution, instant-ragdoll deaths look more ridiculous than fixed animations honestly.

There are some animations that probably shouldn't rag-doll at all though, like the impaled on spikes animation.

Hope this is implemented for enemies too, or at least the human ones considering just how often they end up floating over pits or embedded in walls in the first three games.
Uzi master is offline   Reply With Quote
Old 15-06-15, 21:28   #1525
Mokono
Relic Hunter
 
Mokono's Avatar
 
Join Date: Apr 2009
Location: Perķ
Posts: 8,742
Default

Quote:
Originally Posted by Lwmte View Post
Still, I believe ragdoll deaths are much more natural than pre-rendered animations - because it doesn't rely on collisional geometry. The best way (and the way we're implementing it) is to play normal death animation up to a certain frame, and then switch to ragdoll mode. This looks much better than LAU-styled ragdolls.
That's how Core implemented ragdolls in AoD and i still think they look fantastic (albeit funny in certain contexts where the animation play is interrupted by a 'force' such as traps and baddies).



I remember LAU on the 360 playing animations before triggering ragdoll though (she ducks, grabs her knee and then collapses).
Mokono is offline   Reply With Quote
Old 16-06-15, 12:54   #1526
Joey79100
Professor
 
Joey79100's Avatar
 
Join Date: Mar 2012
Location: France
Posts: 2,886
Default

^
1:07, 1:22, 2:10, 3:46... Oh ****. Indeed, they're a lot better than LAU's deaths.

I like ragdoll deaths, when they are made correctly they can add a lot of realism... But the only thing I don't like is the fact that the body seems to be completely dead (well, it's meant to), but like if Lara's soul instantly disappeared from her body. So yeah, playing a part of the death animation first semms like the best solution. And maybe some meshes animating?
I mean, for the spikes death for example, her arms and her head could be free (ragdoll) but the rest (or only her torso) would be stuck with the animation, so she really looks impaled? Or stick the torso in some way on a spike so it doesn't move at all (or slides down slowly) and every other mesh moves freely... I don't know.
Anyway, it's already impressing, I wasn't actually excepting ragdoll in OpenTomb so soon.
Joey79100 is offline   Reply With Quote
Old 16-06-15, 18:09   #1527
TR-Freak
Professor
 
TR-Freak's Avatar
 
Join Date: Jan 2008
Location: Deutschland
Posts: 4,591
Default

AoD made the best ragdoll deaths in regards of friction.
Her Body doesn't slide around like for example in TRA and TRL, she stays in place after she hits the ground.
(And yeah, bending all her bodyparts doesn't look healthy, but they're funny )
__________________
"Your perception of good timing is...bad!"
TR-Freak is online now   Reply With Quote
Old 16-06-15, 20:47   #1528
Cochrane
Gold Contributor
 
Cochrane's Avatar
 
Join Date: Apr 2006
Location: Germany
Posts: 16,104
Default

Skinning with rag dolls works as expected now. I think I may have done something wrong with the merge in regards to hair. Could someone check whether the results are as expected (which is not the same as "results are good", I still expect a gap between Lara's head and the start of the hair, but still).

Actually, I think I did hair skinning all wrong. Made it too easy on myself there, and as a result the hair is subtly incorrect and too short. No, this is something that will require some real matrix maths (which I plan to copy from GLLara).
__________________
GŁter auf die Bahn!
Cochrane is offline   Reply With Quote
Old 17-06-15, 01:47   #1529
Lwmte
Explorer
 
Lwmte's Avatar
 
Join Date: Aug 2010
Posts: 987
Default

Quote:
Originally Posted by Boobandie View Post
What about playing the full animation but if a bodypart collides with something just that part is switched to ragdoll? Or inverse kinematics?
Per-body ragdoll will make everything much more complicated, because it will require to keep track on already existing constraints, so I think it doesn't worth trying... Inverse kinematics... can't think of any possible application to old-styled TR models here... But anyway, it should be too complex to be done as well!
Quote:
Originally Posted by Titak View Post
Ah, I sort of figured it wasn't easy to make realistic ragdoll effects.
It's not so bad though, you just should tune up parameters by trial and error - recently I made some updates to ragdoll code, which made it much more stable and realistic. Only thing to solve is that Lara still tends to put her hands back in ragdoll state!
Quote:
Originally Posted by Titak View Post
I like the idea of starting out with the regular death animation(s) and then switch to ragdoll during those animations.
Yes, it already works in current revision - with falling death and break-neck (swandive) death - I've set up ragdoll to turn on somewhere in the middle of the animation, and this is how it looks like (by the way, note that hair in TR3 is now skinned - thanks to Cochrane - albeit a bit buggy)


Quote:
Originally Posted by Uzi master View Post
There are some animations that probably shouldn't rag-doll at all though, like the impaled on spikes animation.
For this purpose, Bullet has special type of constraint, called slider, which allows body to move along only one specified axis. We can use that to "attach" Lara body to spike body on spike death. Only problem I see is each spike is not independent mesh, so Lara will be pushed right to the center of the spike object while switching to ragdoll.
Quote:
Originally Posted by Uzi master View Post
Hope this is implemented for enemies too, or at least the human ones considering just how often they end up floating over pits or embedded in walls in the first three games.
Oh yes!!! My dream is to make T-Rex ragdoll! Or Torso Boss! Or... Good news is that TeslaRus currently made AUTOMATIC generation of ragdolls WITHOUT using of predefined offsets, so you can create ragdolls for ANY multi-mesh animated models literally in no time! Only parameters you should pass are joint orientation and limits! I will experiment with that tomorrow.
Quote:
Originally Posted by Mokono View Post
I remember LAU on the 360 playing animations before triggering ragdoll though (she ducks, grabs her knee and then collapses).
Yes, now I remember that too, but they still looked unrealistic, because they set up "dynamic" speed before animation was ended, which resulted in Lara sliding somewhere while playing that animation. Another "unrealistic" factor was her grunts - actually, human in "ragdoll" state won't be able to scream anymore, cause "ragdoll" means brain death.
Quote:
Originally Posted by Joey79100 View Post
I mean, for the spikes death for example, her arms and her head could be free (ragdoll) but the rest (or only her torso) would be stuck with the animation, so she really looks impaled? Or stick the torso in some way on a spike so it doesn't move at all (or slides down slowly) and every other mesh moves freely... I don't know.
Both of these solutions are theoretically possible (see above), but again - much more difficult to implement. Classic ragdoll is not so difficult to implement, you just create constraints and specify its limits and angles, and physics engine does everything else for you. But surely it looks SO refreshing with classic Lara model and levels!
Quote:
Originally Posted by TR-Freak View Post
Her Body doesn't slide around like for example in TRA and TRL, she stays in place after she hits the ground.
I think it's just a matter of developer's taste - Crystal guys thought Lara should slide off slopes in ragdoll states, like if she was dipped in oil before, while Core thought she should stuck with her skin or outfit friction - both ways are valid, but one may prefer first or second.
Quote:
Originally Posted by Cochrane View Post
Skinning with rag dolls works as expected now. I think I may have done something wrong with the merge in regards to hair. Could someone check whether the results are as expected (which is not the same as "results are good", I still expect a gap between Lara's head and the start of the hair, but still).
There was some mess with your merge (actually, it happened before one time, but I fixed it before anybody noticed! ) - I don't know if it's related, but now I have "pointy hair" bug (similar to classic TR4-5 corner vertex bug), which you can clearly see in video above.
Also, before your recent commit, I noticed that last hair mesh lacked its lower geometry, being completely flat. Maybe "pointy hair" is also related to this problem.
Gap between head and hair could be fixed, if you find a way to link first four hairmesh vertices to head vertices specified in hair.lua script.
Quote:
Actually, I think I did hair skinning all wrong. Made it too easy on myself there, and as a result the hair is subtly incorrect and too short. No, this is something that will require some real matrix maths (which I plan to copy from GLLara).
OK then, I think that hair looks pretty already (especially in TR2-3, where we never seen skinned hair before), but if you think it can be better...
Lwmte is offline   Reply With Quote
Old 17-06-15, 04:11   #1530
Cochrane
Gold Contributor
 
Cochrane's Avatar
 
Join Date: Apr 2006
Location: Germany
Posts: 16,104
Default

The missing lower geometry is part of why I want to rewrite things; I did some simplifications there that aren't really valid.

That pointy hair is weird. It's definitely not intended, but I have no idea where it's coming from.

Edit to add: Spiky hair is resolved. Turns out I wasn't sending the final matrix for the hair to the driver (because I was missing a +1 in there). Apparently my driver picked a different default here than yours, so I just didn't see the final piece (and didn't notice that), while for you, it got skinned into the origin, resulting in this rather fascinating effect.

Second edit to add:

Fixed all the things I wanted to fix in terms of hair. That required a lot of matrix maths, and if you don't mind I'm just going to write it all down here so I remember it in the future (and in case you're interested. If you have any questions, please ask!)

Basic background: The vertices of the hair pieces have some original position in the level file. I'm going to call that x_o. I combine them into one single hair mesh. In them, I change the vertices so they have new positions which I call x_h. Once I’m done, by default, the hair will render as one long straight line. This change can be described by a matrix M_ho: x_h = M_ho * x_o.

This step sounds weird but is important. In general, for skinning, I need two different matrices for each end of a hair piece: One for the near end and one for the far end. What I’m doing here is making sure that vertices that stick together through skinning (far vertices of piece n, near vertices of piece n+1) actually have the same position prior to skinning. That’s the only way they can use the same matrix. This matrix will be the average of the center matrices for n and n+1 (we could also do a weighted average of more matrices. Keeping that possibility open is why I calculate the matrix in the shader instead of in render.cpp).

The final global position of each piece, before we get to the (boring) model-view matrix, is x_g. For the hair, we get the matrix M_og delivered from Bullet. x_g = M_go * x_o. We can’t use it directly because the vertex is at x_h, though. We need M_hg so that x_g = M_gh * x_h.

After all this text the solution should be obvious:

x_h = M_ho * x_o
M_ho^-1 * x_h = x_o
x_g = M_go * x_o = M_go * M_ho^-1 * x_h
=> M_gh = M_go * M_ho^-1

(If you note that M_ho^-1 = M_oh, then M_gh = M_go * M_oh. There's a reason I used these weird indices.)

We then get a total per-piece transform in eye space M_eh = M_eg * M_gh, where M_eg is otherwise known as the Model-View-matrix from the camera.

(Edited to make the indices actually make sense.)

It’s all very simple when you write it down like that, but it took me half an hour to get it, and that was even though I had written something very similar before actually.



This scheme can be applied to all animated models, and I plan to do so. Even if they don’t use skinning, it still saves time because I need only one draw call, not one per mesh. For rendering a dynamic entity, I just use exactly the same maths as above (TODO: Would it make sense to just make the hair a dynamic entity?). If it's done via animation, I need to calculate M_og first, but that code exists already because right now animated models (excluding skin parts) are rendered with that matrix anyway.

----

Another edit to add: Everything is on VAOs now. We can, in theory, switch to OpenGL 3.2 whenever we feel like it, just a bit of configuration work left to do. Which raises the question: Do we want to do that? It will make it impossible to run the app on GPUs that don't support DirectX 10, and at least at first, give us no real benefit. My suggestion is to delay that step until we know who would be hurt by it and what we could need it for.
__________________
GŁter auf die Bahn!

Last edited by Cochrane; 18-06-15 at 20:58.
Cochrane is offline   Reply With Quote
Reply

Bookmarks

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 06:48.


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