MantisBT - opensim
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008842opensim[REGION] Physics Enginespublic2020-12-30 19:032021-01-02 00:37
ReporterDatapanic 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformOperating SystemOperating System Version
Product Version0.9.1.0 
Target VersionFixed in Version 
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineubODE
Script EngineXEngine
EnvironmentUnknown
Mono Version5.x
ViewerFirestormOS 6x
Summary0008842: Collision Geometry off on Box prim with hollow set and rotated 45 degrees in ubODE Engine
DescriptionIn a ubODE Physics world, a hollow box prim rotated 45 degrees seems to not rotate the collision geometry with it and causes a collision event that is far from the actual face of the prim.
Steps To ReproduceIn OpenSim.ini, enable ubODE Physics and ubODEMeshmerizer meshing.
Create a box, make it 3.5 x 3.5 x 0.7 and hollow. The box can be on another prim or on the ground.

Rotate the box on Z-axis to 45 degrees.

Drop this script in it:

default
{
    collision_start(integer num)
    {
        llSay(0,"Collision detected.");
    }
}

Walk your avatar into sides 3 or 4 and you will see the collision event occurs way before contacting the prim. On the other sides, collision occurs as expected.

Make the prim's hollow = 0 and the collisions occur as expected.

Rotate the prim back to 0 degrees on the z-axis and the collisions occur as expected.

Lower the prim into the ground or the prim it's sitting on and the collisions occur as expected.


 
Additional InformationThis only happens with ubODE physics.

Running mono 5.20.1.34 on FreeBSD 11.4. I build my own ODE physics engine using opensim-libs/trunk/unmanaged/ODE-OpenSim-Current. The only change I make to the source is for ou/src/ou/malloc.cpp to use stdlib.h instead of malloc.h.

I've been running OpenSim / Robust on FreeBSD since version 9.0 without any issues. Current setup is 20 OpenSim servers hosting 500 regions, Robust and Percona SQL. Not sure when this problem started. Path cut cubes made for doors seem to have this issue too.

I tried to duplicate it on Debian 9 but couldn't get OpenSim to finish startup without lots of crashes.
   
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2020-12-30 19:03DatapanicNew Issue
2020-12-30 19:22UbitUmarovNote Added: 0037433
2020-12-30 19:24djphilNote Added: 0037434
2020-12-30 19:25UbitUmarovNote Added: 0037435
2020-12-30 19:26djphilNote Added: 0037436
2020-12-30 19:37DatapanicNote Added: 0037438
2021-01-01 15:36DatapanicNote Added: 0037440
2021-01-02 00:37UbitUmarovNote Added: 0037441

Notes
(0037433)
UbitUmarov   
2020-12-30 19:22   
could not repo on 0.9.2 (osgrid sandbox plaza III)
(0037434)
djphil   
2020-12-30 19:24   
I cannot reproduce this bug on windows but I discovered another bug.
With the same prim, placing your avatar against the prim will produce a collision over and over again (as if it was collision (intereg n))
Change the hollow to 0 and the collisions occur as expected.
Change the hollow again and the collsion start over and over again.
(0037435)
UbitUmarov   
2020-12-30 19:25   
some movement jitter may cause that
(0037436)
djphil   
2020-12-30 19:26   
My avatar is not moving, his feet are not moving either.
And when I change the hollow to 0 it stops.
(0037438)
Datapanic   
2020-12-30 19:37   
Is 0.9.2 in Release now?
(0037440)
Datapanic   
2021-01-01 15:36   
I found the source of my problem - when building opensim-libs/trunk/unmanaged/ODE-OpenSim-Current, I was using the following for ./configure:

./configure --enable-shared --enable-release --disable-demos --without-x --with-trimesh=gimpact

After NOT including triMesh=gimpact and using old-trimesh, the behavior came back to normal:

./configure --enable-shared --enable-release --disable-demos --without-x --enable-old-trimesh

I am not sure why I used trimesh=gimpact, but I started to use it when 0.9.1 came out.

This issue can be closed. Thank you so much for your time!
(0037441)
UbitUmarov   
2021-01-02 00:37   
on our fork of ODE, gimpact is not considered, so may be bad