tag:blogger.com,1999:blog-1994130783874175266.post5833776953059147097..comments2020-05-27T11:38:35.467+02:00Comments on bitsquid: development blog: Inheriting Velocity in RagdollsNiklashttp://www.blogger.com/profile/10055379994557504977noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-1994130783874175266.post-61287653541221455582012-10-19T16:03:01.539+02:002012-10-19T16:03:01.539+02:00Yes you are correct, you should use the position o...Yes you are correct, you should use the position of the center of mass to compute the velocity.Niklashttps://www.blogger.com/profile/10055379994557504977noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-53840946036245326102012-10-18T02:35:50.906+02:002012-10-18T02:35:50.906+02:00Two comments:
1) In your formula you compute the l...Two comments:<br />1) In your formula you compute the linear velocity as the delta of the positions. I think this is only correct if the position and the center of mass are coincident (which is not necessarily the case). <br /><br />I think the correct formula should be:<br />Vector3 velocity = ( tm_1 * pBody->GetLocalMassCenter() - tm_0 * pBody->GetLocalMassCenter() ) / dt<br /><br />2) While animating forwards is a nice idea I think we can miss some other effects like e.g. from IK. It is just a minor detail though. <br /><br /><br />Dirkhttps://www.blogger.com/profile/16163171860761476111noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-87135174967664237772012-04-24T12:04:59.479+02:002012-04-24T12:04:59.479+02:00You are absolutely right, animating forwards to ge...You are absolutely right, animating forwards to get delta movement is a lot easier and simpler than animating backwards.Niklashttps://www.blogger.com/profile/10055379994557504977noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-35195093407389298112012-04-21T19:00:45.855+02:002012-04-21T19:00:45.855+02:00Instead of calculating backwards one frame, couldn...Instead of calculating backwards one frame, couldn't you animate forward one frame and calculate the velocity that way?<br /><br />Presumably, moving the animation forward is a lot easier than going backwards and both of them are just an estimate of the velocity at time t. I would expect the resulting velocity to be in roughly the same neighborhood.<br /><br />Of course keeping the transforms is probably the easiest solution and you may need it for rendering out your velocity buffer for per-object motion blur anyways.Phil Teschnerhttps://www.blogger.com/profile/07688687352136934369noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-29164885710090953822012-04-21T07:41:32.711+02:002012-04-21T07:41:32.711+02:00Thanks.
- A pointer swap would be fast, but it do...Thanks.<br /><br />- A pointer swap would be fast, but it doesn't work because the scene graph transform does not transform all nodes, only the ones that are "dirty" (local matrix or parent has changed). The transform is more expensive than memcpy, so it is cheaper to memcpy and transform a subset than to pointer swap and transform all.<br /><br />- Yes, that is what I hinted at when I talked about possible optimizations in the last paragraph.<br /><br />- Thanks for the angular velocity formula, I'll try it.Niklashttps://www.blogger.com/profile/10055379994557504977noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-47357812826361891242012-04-21T02:48:46.916+02:002012-04-21T02:48:46.916+02:00Nice post Niklas. Here are a couple ideas:
- last_...Nice post Niklas. Here are a couple ideas:<br />- last_world and world transforms could be exchanged with a pointer swap<br />- you could have the ragdoll store the last transforms just for the rigid bodies (small sub-set of all transforms)<br />- you can compute angular_velocity cheaply as 2 * (q1 - q0) * conjugate(q0) / dtErin Cattohttps://www.blogger.com/profile/15390725375367643273noreply@blogger.com