MantisBT - opensim
View Issue Details
0008565opensim[REGION] Physics Enginespublic2019-07-19 15:262019-07-22 14:42
RoyaleMobian 
 
normalminoralways
newopen 
 
 
0.9.1
Grid (1 Region per Sim)
ubODE
Mono / Linux64
5.x
0008565: At high velocities (>200m/s), you can no longer hit objects reliably at close ranges
As above, with the minimum range increasing linearly above that speed, up to around 9000m/s, where you can no longer hit any object in the sim, nor do your bullets render.
Create a testbed object that fires an object at a given speed. Create a target object that reports a collision, with the dimensions of 1x1x1.75, the average avatar hitbox size.

Fire object from a distance of approximately 10m. Increase speed. Observe how the minimum distance becomes >10m at 800m/s, which is the average modern rifle velocity.
This report is forwarded on behalf of one of my users Syrinx
No tags attached.
Issue History
2019-07-19 15:26RoyaleMobianNew Issue
2019-07-22 05:53Total SorbetNote Added: 0035493
2019-07-22 11:52RoyaleMobianNote Added: 0035494
2019-07-22 12:06RoyaleMobianNote Edited: 0035494bug_revision_view_page.php?bugnote_id=35494#r8304
2019-07-22 13:44Total SorbetNote Added: 0035495
2019-07-22 13:53AliciaRavenNote Added: 0035496
2019-07-22 13:57AliciaRavenNote Added: 0035497
2019-07-22 14:03Total SorbetNote Added: 0035498
2019-07-22 14:04Total SorbetNote Edited: 0035498bug_revision_view_page.php?bugnote_id=35498#r8306
2019-07-22 14:10AliciaRavenNote Added: 0035499
2019-07-22 14:15Total SorbetNote Added: 0035500
2019-07-22 14:19AliciaRavenNote Added: 0035501
2019-07-22 14:27Total SorbetNote Added: 0035502
2019-07-22 14:29AliciaRavenNote Added: 0035503
2019-07-22 14:32Total SorbetNote Added: 0035504
2019-07-22 14:42UbitUmarovNote Added: 0035505

Notes
(0035493)
Total Sorbet   
2019-07-22 05:53   
Expected behaviour. Rez max velocity seems to be capped somewhere around 200 to 250m/s but its long time since i've tested. Values beyond this are practically certain to produce what you have reported. Internally physics engine runs at 11 fps.. So even if it were possible to rez an object moving at 9km/sec it would have to jump 818 meters 11 times in one second. Its these huge jumps that makes it miss your 1x1x1.75m object.
(0035494)
RoyaleMobian   
2019-07-22 11:52   
(edited on: 2019-07-22 12:06)
On SL it is maxed out at about 200 to 250m/s and is enforced to that limit, anything set faster then that is forced to the max limit. on ubode however, it has no limit enforced but the physics engine appears to top out at about 9000m/s as Syrinx has discovered. Having a limit in place even if it is configurable in the OpenSim.ini is better then having no limit.

like how osSetOwnerSpeed can be currently configured to change the max speed it can set for example.

(0035495)
Total Sorbet   
2019-07-22 13:44   
I don't understand why you would want to cap this. You already have the ability to set a velocity when rezzing from script.
(0035496)
AliciaRaven   
2019-07-22 13:53   
The reason the speed is often capped is due to a physics effect known as "Tunneling". The physics engine tests for collisions every frame. So the faster an object moves, the more chance there is that that object will pass through another object between frames and therefore not be detected as a collision.

There are methods to fix this, but they are very complex and add extra overhead to the system and slow the physics tests down considerably. There is a trade off between efficiency and accuracy when it comes to mitigating the tunneling effect. Fast moving prims are often considered an outside edge contingency so performance is prioritize. Games that rely on bullets and guns, obviously take the issue more seriously.
(0035497)
AliciaRaven   
2019-07-22 13:57   
One work around I have used in the past when writing Gun scripts, is to make the projectile (ie bullet rocket etc) as LONG as possible. This means that even when its moving fast, it will be inside an object longer so increase the chance of a collision event registering. Or u can make a target larger, deeper. Not a fix, but might help understand and find a possible work around even if its temporary
(0035498)
Total Sorbet   
2019-07-22 14:03   
(edited on: 2019-07-22 14:04)
Another option would be to use llCastRay() and do away with the bullet altogether

(0035499)
AliciaRaven   
2019-07-22 14:10   
That is a well known work around for tunneling. But to perform a ray cast every physics frame comes back to performance again. For what is considered an outside case to most users, ray casting between every frame its a large hit on performance. I think OS needs to handle the tunneling effect better, its just finding that balance between accuracy and performance. A lot of issues come down to a compromise and finding a balance. But again, yes I think OS is too serseptable to this error, both uODE and BulletSim.
(0035500)
Total Sorbet   
2019-07-22 14:15   
There is no requirement to ray cast on every frame. Just once when gun is fired is sufficient.
(0035501)
AliciaRaven   
2019-07-22 14:19   
What if prims move between fire and impact? If its an instant collision, its simple. But you want a moving object, set speed, direction, impact with moving targets? A rocket with a non linear trajectory spiraling or heat seaking? Streat line instant shot is simple, but that cuts out the projectile prim, so just use ray casy in lsl not a prim in motion
(0035502)
Total Sorbet   
2019-07-22 14:27   
I suggested ray casting because the OP was looking at using high speed projectile which would be difficult to see anyway. As an alternative I would consider ray casting valid in this case.
(0035503)
AliciaRaven   
2019-07-22 14:29   
Ah yes, Ray casting as ll script rather than a moving projectile. Not doing raycasting on the server for moving objects in physics as i thought
(0035504)
Total Sorbet   
2019-07-22 14:32   
hehe that would be just.. horrible :p
(0035505)
UbitUmarov   
2019-07-22 14:42   
Physics engines frame time is around 20ms.
ODE engines don't have Continuous Collision Detection Algorithms. Bullet has it off, because those are very heavy.