closer to SL. This change should address small floor edges acting like
walls, approaching a step at any angle (other than walking backwards)
will allow walking up, and reducing the avatar pop-up when going up
stairs.
Change how physics engine is created in unit tests to resolve a lib reference problem.
Add ShapeInfoInfo class to collect info about the created physical shape
for debugging and unit test testing.
This commit addresses the following issues were causing velocity to be set to 0 on the new region, disrupting flight in particular
* Full avatar updates contained no velocity information, which does appear to have some effect in testing.
* BulletSim was always setting the velocity to 0 for the new BSCharacter. Now, physics engines take a velocity parameter when setting up characters so we can avoid this.
This patch applies to both Bullet and ODE.
This is to achieve a clean separation of concerns - the watchdog is an inappropriate place for work management.
Also adds a WorkManager.RunInThreadPool() class which feeds through to Util.FireAndForget.
Also switches around the name and obj arguments to the new RunInThread() and RunJob() methods so that the callback obj comes after the callback as seen in the SDK and elsewhere
This is implemented with a new collision type (PhantomToOthersAvatar) to potentially allow colliding and non-colliding avatars to be present in the same scene.
So there is no provision yet for giving avatars different collision types.
This commit replaces the temporary change in commit f3eaa6d8 where avatars would never collide when using BulletSim
This is equivalent to the av_av_collisions_off option in ODE.
In theory, there should be no difference between these mechanisms.
However, on at least Mono 3.2.8 waiting via an event appears to be much more accurate.
This involves making PhysicsActor.PIDActive get as well as set.
On physics components that don't implement this (all characters and some phys engines) we return false.
AvatarFlyingGroundMargin and AvatarFlyingGroundUpForce set to 5.0 and
2.0 respectively which seems to give about the same action as in SL.
Also moved force addition to before the velocity to force computation
so the upward velocity is properly applied to the avatar mass.
This should get around the exception reported in Mantis 7191 and 7204
by checking for the unbuilt child and rebuilding the linkset the next tick.
A warning message is output when this rebuild happens and this message is
clamped to 10 times in case there is a problem with a loop.
For some reason as yet unidentified (feedback?) a threshold above 0.4 here causes the RawVelocity to move between a lower and upper bound rather than remaining constant.
The RawVelocity increased until it triggered the threshold update, at which point it started to decrease until it again triggered the threshhold update.
This delta-v was enough to exceed the checks in ScenePresence.SendTerseUpdateToAllClients() and produce jittery avatar flight because of the fluctuating velocity.
With a threshold of 0.4 (or 0, as with ODE), the RawVelocity remains constant in BulletSim and so avatar flight becomes mostly smooth - remaining occasional glitches appear to be a result of errors in distance extraploation.
There are no obvious problems with commenting out the threshold.
Misterblue, if this is wrong or I've missed some subtlety here, please feel free to revert and/or correct.
The same considerations may or may not apply to object velocity updates.
parameter 'TerrainGroundPlane' which defaults to -500.
BulletSim had assumed altitudes never went negative but that is not true. The
ground plane is just a safety net so things wouldn't fall to infinity.
objects in the world.
This was originally changed in an attempt to make vehicles work better
but the effect was not that large and it causes avatars to float
above the terrain.
