Jolt doesn't support this and requires you to recreate the shape. Since
the shape -> collider relationship is 1:N, we can't really create a new
shape because we'd have to figure out which colliders/compoundshapes to
assign it to, which isn't feasible.
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.
refs are cumbersome because they require storing an int and they require
manual cleanup when the object is destroyed.
Instead, we'll go with a pure Lua solution using a table in the
registry. The table has weak keys containing the LÖVR object, and the
values are the userdata. This doesn't require any manual cleanup,
reduces the size of objects by 8 bytes, and is about 25% faster.
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.
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..
bjorn
xiejiangzhi
Josip Miskovic
bjorn