| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| |
| | |
allocate memory, and therefore the unmanaged wrapper call fails or worse.. there's some unmanaged resource accounting in the ODEPlugin for ODECharacter that isn't being done properly now.
* The broken avatar may not be able to move, but it won't stop simulate from pressing on now. And, the simulator will try to destroy the avatar's physics proxy and recreate it again... but if this is what I think it is, it may not help.
|
|\ \
| |/ |
|
| |
| |
| |
| | |
enabled, the first Heartbeat loop call to UpdatePhysics takes 20 minutes. 75% of that time is spent in this sleep. (100k prims * 10ms)
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| | |
ScenePresence.AddToPhysicalScene.
* This causes time to be counted in ODECharacter and, when a collision occurs, the physics scene will report the collisions only if the the difference of last time it reported the collisions from now was more then the set ms.
* This is cool because the time accrues while collisions are not taking place and when they do take place again, you get an immediate update.
|
| |
| |
| |
| | |
* Set the Scene collision update time to 500 ms
|
| | |
|
|\ \
| |/ |
|
| | |
|
|\ \
| |/ |
|
| |
| |
| |
| | |
allocated on the unmanaged heap. This prevents fragmentation of the managed heap and the resulting stress on GC. A region with ~150,000 prims using ODE and Meshmerizer saw memory remain flat around 1.2GB as opposed to 1.5GB and continually growing due to pinned memory. This patch complements the unique mesh dictionary patch applied to Meshmerizer but is independent. The net effect is a 60-75% reduction in memory for our largest regions.
|
|\ \
| |/ |
|
| | |
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| | |
parameters. CreateMesh() returns a Mesh from the dictionary or creates a new Mesh if it has not been created before. Meshes are never purged from the dictionary. The raw Mesh data is discarded once the memory is pinned for ODE use. All copies of the same prim/mesh use the same pinned memory. ONLY IMPLEMENTED AND TESTED WITH MESHMERIZER AND ODE
Signed-off-by: dahlia <dahliaTrimble@gmailDotCom>
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eliminate dynamic capsule wobble. Instead introduce a small, fixed
tilt, and allow the tilt to rotate with the avatar while moving; the
tilt always faces away from the direction of avatar movement. The
rotation while moving should eliminate direction-dependent behavior
(e.g. only being able to climb on top of prims from certain directions).
Falling animation is still too frequently invoked.
Ideally the tilt should be completely eliminated, but doing so
currently causes the avatar to fall through the terrain.
|
|
|
|
|
|
| |
for the creators
Disable generation of temporary profiles for now, instead record loading user as creator
|
|
|
|
| |
Constants.RegionSize isn't 256
|
| |
|
|
|
|
|
|
| |
right in the new border framework.
* This also contains some inactive preliminary code for disconnecting combined regions that will be used to make one root region a virtual region of a new root region.
|
|
|
|
| |
and idle performance.
|
|\ |
|
| | |
|
| |
| |
| |
| | |
memory in _heightmap and using multiple heightmaps caused them all to overwrite each other and the last one was the heightmap for all of the regions. This fixes that. It also reduces the terrain resolution to half.
|
| | |
|
|\ \
| |/ |
|
| |
| |
| |
| | |
gone in.
|
| | |
|
| | |
|
| | |
|
|\ \
| |/ |
|
| | |
|
|/ |
|
| |
|
|
|
|
| |
lets you configure region sizes to be smaller without crashing the region. I remind you that regions are still square, must be a multiple of 4, and the Linden client doesn't like anything other then 256. If you set it bigger or smaller, the terrain doesn't load in the client, the map has issues, and god forbid you connect it to a grid that expects 256m regions.
|
|
|
|
| |
256m limitation within the OpenSimulator framework, however, the LLClient ClientView does not support regions larger then 256 meters so, if you try and make your region larger by setting Constants.RegionSize = 512; in OpenSim.Framework.Constants.cs, the terrain will not display on clients using the LLUDP protocol
|
| |
|
| |
|
| |
|
|
|
|
|
| |
* Fixes mantis #3922
|
| |
|
|
|
|
|
|
| |
* Commented logic that wasn't being used.
* This should fix the errors in OdeScene.near
|
|
|
|
|
|
|
|
|
| |
a raycast test safely.
* Test for prim obstructions between the avatar and camera. If there are obstructions, inform the client to move the camera closer. This makes it so that walls and objects don't obstruct your view while you're moving around. Try walking inside a hollowed tori. You'll see how much easier it is now because your camera automatically moves closer so you can still see.
* Created a way to know if the user's camera is alt + cammed or just following the avatar.
* Changes IClientAPI interface by adding SendCameraConstraint(Vector4 CameraConstraint)
|
| |
|
|
|
|
| |
if the collisions will affect health if the avatar is invulnerable. (saves 3 loops)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
#2905
This fix re-introduces a small tilt into the capsule to prevent
avatar falling through terrain. Re-introduction of the tilt means
that some direction-dependent behavior when walking over prims, but
I have tried to minimize this.
Additionally this commit allows the capsule to wobble slightly when
being pushed around the terrain. This should make walking over prims
easier, as the capsule can wobble and glide diagonally over the prim's
edge, instead of rigidly being stopped vertically against the prim's
face.
|
|
|
|
|
|
| |
Fixes Mantis #3888
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Set av_capsule_tilted to false in opensim.ini. Default is true, so there is
no change in avatar behavior (and no breaking of existing content which
relies on the tilted capsule).
This commit straightens up the avatar capsule so it behaves consistently
(e.g. same collision behavior against prims regardless of which direction
the avatar is coming from; ability to fit through narrow doorways).
Please note this introduces other side effects which have not been fixed.
In particular:
* The avatar frequently falls through the terrain if it is not flat, though
the avatar behaves pretty well on flat terrain. This requires investigation
of the ode terrain collider.
* The apparent foot position of the avatar with respect to the ground
is changed. This requires investigation of the avatar height/capsule height.
Please consider this as work in progress.
|
|
|
|
|
|
|
| |
engine, caused by an "avatar infinite position" occurring under
heavy load.
- fixes "value too small" exception in ChatModule
|