| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
when avatar enters the new region.
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.
|
|
|
|
|
|
|
|
| |
thread and run work in the jobengine from Watchdog to a WorkManager class.
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
|
|
|
|
|
|
|
|
|
| |
avatars collide. This is true by default.
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.
|
|
|
|
|
|
|
| |
rather than a sleep.
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.
|
|
|
|
|
| |
Will only effect Windows or mono with a patch such as https://gist.github.com/justincc/31e52218d098529b4696 applied
For test purposes
|
|
|
|
| |
Need to do this for a test. Final implementation will be properly controlled through a property.
|
|
|
|
|
|
|
| |
unnecessary object update if the prim was not moving to target.
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.
|
|\ |
|
| |
| |
| |
| |
| |
| | |
method is only run for an indepndent thread anyway.
Also remove bulletsim monitored thread from watchdog on shutdown.
|
| |
| |
| |
| | |
The cost is minimal (also done for scene loop) at the benefit of telling us if this thread simply stops for some reason.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
watchdog.
This allows us to see the presence of the permanent thread via the "show threads" console comand.
Also adds the region name to the thread name.
|
|/
|
|
| |
BulletSim fixed constraint to not be confused with the native version.
|
|
|
|
| |
Fix for 7284 which is an enumeration exception when starting up a region.
|
|
|
|
|
|
| |
bulletsim physics is running in a separate thread.
This will also allow the "disable physics" setting in the region debug viewer dialog to work in this circumstance.
|
|
|
|
|
|
| |
constructed.
Add routine to check for failed and use that method rather than
checking individual state.
|
|
|
|
|
|
| |
complete with use of the Limit Roll Only Flag.
Signed-off-by: Robert Adams <misterblue@misterblue.com>
|
|
|
|
| |
child mesh is not available when building a linkset.
|
|
|
|
| |
has. Before this falling from really high caused the avatar to fall faster then the veiwer can handle and cause camera issues.
|
|
|
|
| |
from locking up when running BulletSim on a separate thread.
|
|
|
|
| |
child doesn't have a physical shape. Another attempt at fixing Mantis 7191.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
(swimming)
Signed-off-by: Michael Cerquoni <nebadon2025@gmail.com>
|
|
|
|
|
|
| |
flop to the floor when flying with bullet physics and acts more like ODE and SL flight.
Signed-off-by: Michael Cerquoni <nebadon2025@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
RawVelocity update threshold for now in BSCharacter.UpdateProperties().
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.
|
|
|
|
|
| |
step updates and collisions. This is an attempt to fix a crash reported
by Justin when doing high velocity teleports.
|
|
|
|
|
| |
staircases. This change is required because of the change in the
avatar default shape from the capsule to the rectangle.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This adjustment makes a default, shoeless avatar stand properly on a prim
for the various heights (0% to 100% in the appearance adjustment).
|
|
|
|
| |
Signed-off-by: Michael Cerquoni <nebadon2025@gmail.com>
|
|
|
|
|
|
|
|
| |
a capsule. Set the default to be the rectangle shape and adjust the
parameters in OpenSimDefaults.ini for the new shape.
The rectangle shape will perform better and avatar height can be
computed more accurately.
|
|
|
|
|
|
|
| |
linear motion.
The code was limiting linear motion to be only in the positive direction
for any axis that was constrained.
|
|
|
|
|
|
| |
upward target motion for avatar when running.
Signed-off-by: Michael Cerquoni <nebadon2025@gmail.com>
|
|
|
|
| |
was getting zeroed too easily. Added VehicleMinVelocity parameter.
|
|
|
|
|
|
|
|
| |
It originally looked like mesh terrain would perform better for vehicles
but, after much use, heightmap is the clear winner.
Force terrain implementation to heightmap if the physics region is
larger than legacy region size. This solves running out of memory for
very large regions.
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
OpenSim/Region/CoreModules/Framework/EntityTransfer/EntityTransferModule.cs
OpenSim/Region/Framework/Scenes/SceneBase.cs
OpenSim/Services/Interfaces/IGridService.cs
OpenSim/Services/LLLoginService/LLLoginResponse.cs
(conflicts were debug statements that are commented out in master branch)
|
| |
| |
| |
| |
| |
| | |
(like sitting on and activating a vehicle) and crossing borders.
This keeps better bookkeeping on compound shapes so BulletSim can
identify them when being freed.
|
| |
| |
| |
| | |
with a passed region size. This time in the map code and grid services code.
|
| |
| |
| |
| |
| |
| | |
physics engine.
Older physics engines will default to the legacy region size.
Update BulletSim to use the new region size information.
|
|/
|
|
| |
to check for border crossings based on the size of the region.
|
| |
|
|
|
|
|
|
| |
static objects.
Reorder collision flag setting code for terrain to fit pattern used elsewhere.
|
|
|
|
|
|
|
|
|
|
|
| |
the vehicle buoyancy if the vehicle is above its hover height.
This is a known misfeature of this vehicle flag which has been accepted
since it would break too many implementations. The problem is noticed
when creating a jetski-like vehicle that jumps over sand bars. A boat
normally is configured with neutral buoyancy and hovering at water
height. When it jumps the sandbar, it needs to have gravity applied
to get back to water level.
|
| |
|
| |
|