- Add World:getColliderCount
- Add World:getJointCount
- Add World:getJoints
- Add Joint:isDestroyed
- Destroy joints when either of their colliders are destroyed (Jolt
seems to require this).
- Fix joint memory leak.
- Change joints to be stored in some crazy graph thing.
- Reduces allocations, allows constant time insertion/removal.
They still work on ODE, and Jolt makes a best-effort attempt to support
them, but they will be removed in a future version.
- Damping should be set explicitly on colliders.
- Tightness and response time will be supported via spring forces, and
also some global settings in newWorld will affect joints too.
- Step count will be added to :update soon. Since the correct value is
dt-dependent in Jolt, a persistent accessor doesn't make sense.
- Sleeping allowed will be an immutable setting in newWorld soon, but
otherwise should be changed per-collider.
These are methods that implement some common raycast behaviors without
creating a closure. They also take tag filters. The tag filters could
be optimized to use tag numbers instead of string comparison, and the
default raycast method could take a tag filter, but I didn't want to
modify the C API while Jolt is in progress.
The "vec3 is 4 floats" thing was consistently confusing to people. It's
reverted everywhere except for Curve.
maf now has full sets of methods for vec2/vec3/vec4, for consistency.
Vector bindings now use luax_readvec* helper functions for the
number/vector variants, and use maf for most functionality, which cleans
things up a lot.
- Add helper functions for creating shapes to avoid duplication between
newShape and newShapeCollider.
- Add lovr.physics.newMeshShape and lovr.physics.newTerrainShape
- Register TerrainShape so it has all the base Shape methods
- Smooth out a few TerrainShape warnings
Physics world's "quick step" is executed in multiple iteration steps.
The getter and setter for this value is now made available as two new
methods in the World object.
This is allows user to balance between the less accurate but quick
simulations, and more stable behavior of physics.
Something similar was already possible, by reducing the delta time and
running the sim multiple times per frame. However, any force user applies
to collider is zeroed after each step. User would thus have to keep track
of applied forces, and re-apply them inside the physics iteration loop.
By default ODE uses 20 iterations in quick step.
Zero as default makes more sense. Colliders can come to full stop which
allows them to go to sleep for CPU optimization. Also in zero gravity
colliders crawling through air with 0.01 velocity are infuriating.
Tightness parameter is amount of force is exerted on collider to resolve
collisions and enforce joint operation. Low values make joints loose,
high values make it tight and can cause collider to overshot the joint
target. With tightness set to 0 the joint loses its function. Going
above 1 puts even more energy into joint oscillations. Tightness
parameter is called ERP in ODE manual.
The responseTime affects the time constant of physics simulation, both
for collisions and for joint inertia. Low responseTime values make
simulation tight and fast, higher values make it sluggish. For
collisions it affects how fast penetration is resolved, with higher
values resulting in spongy objects with more surface penetration and
slower collision resolving. For joints the responseTime is similar to
inertia, with higher responseTime values resulting in slow oscillations.
The oscillation frequency is also affected by collider mass, so
responseTime can be used to tweak the joint to get desired frequency
with specific collider mass. Values higher than 1 are often desirable,
especially for very light objects. Unlike tightness, responseTime is
tweaked in orders of magnitude with useful values (depending on mass)
being between 10^-8 and 10^8.
Both parameters can be applied to World for simulation-wide usage, or
specified per-joint in case of distance and ball joints. Other joints
don't allow customizing these parameters, and will use World settings
instead..
When creating colliders, setting gravity or casting rays on world,
arguments accept either coordinate numbers as before, or vec3 objects.
For functions that receive more than one set of coordinates, any
combination of coordinates and vectors is accepted.
bjorn
xiejiangzhi
Josip Miskovic
bjorn