mtasa-blue
mtasa-blue copied to clipboard
multitheftauto
Bullet physics
Adds bullet physics engine to mta.
Plan changed. Initial pr ( this pr ) will contain:
physicsCreateBoxShape, physicsCreateRigidBody, physicsCreateStaticCollision, physicsGetDebugLines + destroyElement, setElementPosition, setElementRotation support for rigid body and static collision
More details at mta development discord
More info
= SHERED = physics-box-shape physicsCreateBoxShape( Dimensions size ) - creates box, cube shape. Minimum size of each dimension: 0.0001, maximum: 8196 physics-rigid-body physicsCreateRigidBody( physics-shape shape, RigidBodyOptions options ) - spawns a rigid body with given options, when spawned in air, it will immidently starts falling. Shape must be convex ( see below ). In future: eg.: some types of triangle mesh will not accepted, but compound-shape will even technically is not convex physics-static-collision physicsCreateStaticCollision( physics-shape, Vector3 position, Vector3 rotation ) - spawns static collision, it will not affected by gravity, always stay in one place (like a platform) table physicsGetDebugLines( Vector3 position, float radius ) - returns table {{fromX, fromY, fromZ, toX, toY, toZ, color}, ...} with collision wireframe at given position and radius. Send to client and loop to see current state of simulation. Color indicate current state of rigid body.
= CLIENT ONLY = void physicsDrawDebug() - renders all debug lines, use in onClientRender
= Types = RigidBodyOptions - table with accepted keys: {["mass"] = float, ["localInertia"] = Vector3, ["centerOfMass"] = Vector3, ["position"] = Vector3, ["rotation"] = Vector3} Dimensions- can be x,y,z, or one number with all dimensions
= Hierarchy, type description: physics-element - base of any physics element physics-world-element : physics-element - element that has position and rotation physics-shape : physics-element - base of all physics shape physics-convex-shape : physics-shape - base of all convex shape physics-box-shape : physics-convex-shape - box shape physics-rigid-body : physics-world-element - shape affected by gravity ( eg: car, player, ball, some gta models ) physics-static-collision : physics-world-element - non moving collision ( eg: terrains, buildings, roads :D )
=== Extras: physics-rigid-body and physics-static-collisions is always made of single physics-shape treat physics-shape as a instance, can be used in multiple collisions and compound shape ( in future )
=== extended functionality of already existing functions: set/getElementPosition, set/getElementRotation, destroyElement, now accept physics-world-element getUserdataType - returns physics element type set/getElementVelocity accept physics-rigid-body
=== important: destroyElement side effect: due to hierarchy style of physics elements, if you destroy shape, all references ( rigid-bodies and static-collisions ) get destroyed too, see example below
=== nice to know:
- gta sa collision has precision 1/128m and maximum size 256x256x256, bp has float precision, and maximum size of float max number ( 3 + 38 zeros )
- spawning a lot of rigid bodies at same position may cause high ram usage ( eg spawn 1000 bodies at same time at same position ) - it can also crash due ran out of ram
- rigid bodies can sleep, it means when nothing hit them they will behave like static collision what increase performance
samples:
local box = physicsCreateBoxShape(1)
local rb1 = physicsCreateRigidBody(box, { position = {0,0,5} })
local rb2 = physicsCreateRigidBody(box, { position = {0,0,6} })
local rb3 = physicsCreateRigidBody(box, { position = {0,0,7} })
local floor = physicsCreateStaticCollision(box, 0,0,0)
destroyElement(box) -- rb1, rb2, rb3, floor and box get destroyed
i'm waiting for quick, general review of code then i'll continue work on it
anyone has anything to say about this project? What should be added/changed to marge it?
I've given your changes a very quick skim.
API stuff:
- is it possible for some stuff that might take some time (and not required to be ready immediately) to be asynchronous? Such as physicsCreateShapeFromModel and physicsBuildCollisionFromGTA? I have not looked into whether this is even feasible.
- Does setElementPosition/Rotation work on these physics objects?
- When you do physicsAddChildShape, is child.position @ (0,0,0) == parent.position?
- Would it be possible to use setElementParent, setElementPosition, and setElementRotation here?
- It looks like all the physics element kinds share the element type as
physics-element. And that physicsGetElementType returns the 'inner type'. Not sure how I feel about this. I think getElementType should return the inner type, and people can use physicsIsElement to determine if an element is a physics element (which is better than checking that the element type begins with"physics-"). - physicsIsElement is weirdly named
However, for the code itself, here are some recommendations for basic improvements:
- use smart pointers
- use
enum classinstead ofenum - use the new Lua arg parser. you might need to extend the lua arg parser to have extra features. Send those as separate pull requests to master, so that those can be merged before this is merged.
- Client/mods/deathmatch/logic/CClientPhysics.cpp imports
../Client/game_sa/CCameraSA.h. Not allowed!
Generally:
- I don't know if we're approving this feature. It's big and scary. We need to ask ourselves if this is in scope for MTA.
IMHO, first fixing the other PR would be nice(the gtasa collision customization), because that also fixes setScale to resize the collision which is neat.
Someone smart, we need idea how to sync this!!!! even simple simulations may flood server with packets, batching will necessary.
I have few solution for it:
- make option to create physics serverside too, and if something get created serverside it will synced.
- make function like "setSyncId( element, number )" and if two or more players set same id, it will synced across that players. Server get function to set who is a syncer.
Depends on distance from element to rigid body, frequency of synchronization should change with option to change behaviour.
I've given your changes a very quick skim.
API stuff:
is it possible for some stuff that might take some time (and not required to be ready immediately) to be asynchronous? Such as physicsCreateShapeFromModel and physicsBuildCollisionFromGTA? I have not looked into whether this is even feasible.
Does setElementPosition/Rotation work on these physics objects?
- When you do physicsAddChildShape, is child.position @ (0,0,0) == parent.position?
- Would it be possible to use setElementParent, setElementPosition, and setElementRotation here?
It looks like all the physics element kinds share the element type as
physics-element. And that physicsGetElementType returns the 'inner type'. Not sure how I feel about this. I think getElementType should return the inner type, and people can use physicsIsElement to determine if an element is a physics element (which is better than checking that the element type begins with"physics-").physicsIsElement is weirdly named
However, for the code itself, here are some recommendations for basic improvements:
- use smart pointers
- use
enum classinstead ofenum- use the new Lua arg parser. you might need to extend the lua arg parser to have extra features. Send those as separate pull requests to master, so that those can be merged before this is merged.
- Client/mods/deathmatch/logic/CClientPhysics.cpp imports
../Client/game_sa/CCameraSA.h. Not allowed!Generally:
- I don't know if we're approving this feature. It's big and scary. We need to ask ourselves if this is in scope for MTA.
Why it's "It's big and scary"? I think it opens a new door for the developer especially for those who wants to do some real simulations.
Could someone do a review? after that ill apply changes
Maybe it's best to address the previous review first, before someone does another review, as they are all valid points.
Could someone do a review? after that ill apply changes
Maybe it's best to address the previous review first, before someone does another review, as they are all valid points.
ready
Waiting for review! bp3 dependency got reworked and sources are no longer a part of this pull request! Heavy testing is in progress, sources has been cleaned, unused code removed.
Updated branch, added "setElementRotation" test, pr keep waiting for review! :)
Can you show real usage for this feature?
don't have any more realistic examples yet, but i'm since few days working on feature branch to be able later to just create prs out of it.
Example real examples that don't need to completly revamp gtasa collisions ere for example:
- ragdolls
- Einheit-101 said his gamemode lacking of precise physics tests using rays
- fps/dayz servers as above, you can make very precise players hitboxes, make for example shotgun shoots multiple bullets that drops over time
- there is a rocket league like server, they made ball physics themself. Seems to work but how more convinient it is to just spawn a ball? you can attach bp collision to vehicles and noone notice there's something wrong
- survival servers: if you drop an item currently it stay in place, what if an item if affected by physics? if you drop your item near cliff so item can drop into the water?
following examples are not that hard to implement, maybe i will try make some of them as a demo using feature branch i'm working on
Today there was a discussion on dev discord, that i think is valuable for putting a few things into perspective, should CrosRoad95's large PR's like this and V8 engine turn out to not get merged. I can very well relate to devs that are hestitant, and dont want to, as they say, burn their fingers on it
The discussion: https://imgur.com/a/seD0hqQ
