Finally finished an introductory overview of physics in UE: http://www.recursiveblueprints.fun/i…nreal-physics/
Any feedback/suggestions welcomed.
This is part of a @RecursiveBP UE4 development blog I am starting with @jeff_lamarche.
http://www.recursiveblueprints.fun
Thanks! Reading it right now. In the second paragraph, just wanted to mention that some of the Nvidia Gameworks Branches can work on any GPU. For example Flex now works on AMD GPUs.
Good point - just updated post to mention that!
I was just looking for more stuff on physics. I’ll have to keep an eye on this for sure.
This is a great write up, excellent work…
Really,Really Great Questions @franktech - I will update the post but in the meantime:
#1 The overall performance implications of use ComplexAsSimple vary per project and mesh size. This causes the entire mesh to be added to the collision scene so high density meshes will have higher memory cost. It is always best to test scene for performance impact. “Complex shapes cannot be simulated” means you cant use that mesh for a rigid body that is currently being simulated in the scene - only for static and kinematic bodies. E.g. You cant have a bouncing ball that is made up of a 1M vert soccer mesh. I assume this is done because updating the position of the trimesh in the collision scene would be too costly.
#2 Kinematic == moved by specifically setting the position. Things that never ever move are Static. These are added and “cooked” into the collision scene differently than bodies that can be moved. Bodies that are moved by the simulation (eg they have velocity, are affected by gravity, updated in the substep by the solver) are Simulated. Bodies that are moved “by-hand” are Kinematic. Kinematic bodies have simulate-physics off, and are moved by the game code.
#3 Inverse Kinematics in the context of animation is unrelated. Forward Kinematics in that context refers to explicitly setting the position of each bone eg. UpperArm, then LowerArm, then Hand. Inverse Kinematics refers to only setting the hand position, and using a solver to determine the other bone positions. It is sometimes easier to animate keyframes using one approach or the other. In games, it is often useful to use InverseKinematics to set a target for a limb - eg grab a door handle.
#4) Totally agree - need to do a better job enumerating this and giving examples of when to use it. Lots of different combinations here…
#5) The object types are primarily used to determine collision filtering - e.g. whether 2 bodies that are in contact should generate a collision. The PhysX docs have a good write up on this. This code is particularly performance sensitive. In general, the types can be used to define which objects collide. See the Collision Filtering section on this page: Rigid Body Collision — NVIDIA PhysX SDK 3.4.0 Documentation
Thanks again for your feedback! I will update the post and incorporate this…
