Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007420opensim[REGION] Physics Enginespublic2015-01-20 10:042015-03-21 10:43
Reporteralecia ashbourne 
Assigned To 
PlatformMono / LinuxOSOpenSimOS Version0.8.0.3
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0007420: Extreme loading of server with Bulletsim
DescriptionI have tested this on all bulletsim capable opensim versions to version
on Ubuntu 12.10 to 14.04.1 and on a variety of hardware – remote and Local, all configurations give the same result – that being extreme loading of single and multiple cores demonstrating erratic, inconsistent behaviour and excessive loading on an otherwise unloaded system. The tests were carried out on a fresh install of a standard 256 x 256 region with no scripts running except for the vehicle and no in-world assets (clean and empty). I have reconfigured each instance to the nth degree including running separate threads, finely tuning of MinFrameTime etc. all to no avail.

To save entering an essay length analysis in this mantis, I have created a real-time back to back test of ODE physics vs Bulletsim physics and uploaded it to you-tube to demonstrate this issue – having read many issues regarding Bulletsim Physics and finding little to no data on real-time in-world exploitation of Bulletsim – this test is 'real-time' with 'HTOP' and webstats. The webstats say very little except to indicate a drop in physics/sim fps, whereas 'HTOP' is all telling. I believe this test demonstrates a backward step in the implementation of vehicle physics with respect to Bulletsim over ODE and has rendered OpenSimulator virtually unusable in this respect (excuse the pun) I hope You-Tube url's are acceptable for a mantis entry as a picture saves a thousand words – and makes evident this issue. Please read the video description for info on the test.

This test was carried out on an unloaded remote server:

Intel(R) Xeon(R) CPU
E3-1270 V2 @ 3.50GH

2GB Ram
SSD storage

1GB connection node.

Ubuntu 14.04.1 LTS x86

Mono JIT compiler version 3.2.8 (Debian 3.2.8+dfsg-4ubuntu1)

Kernel 2.6.32-042stab093.5

Accesed via Singularity Viewer (64 bit) 1.8.6 (6156)
Mint Cinnemon 64-bit
Cinnemon Version 2.0.14
Linux kernel 3.11.0-12-generic
Intel Core i7
8GB ram
NVIDIA G92M on Dell Alienware Laptop.

Url for Video 'ODE vs Bulletsim': [^]
Steps To ReproduceCan be replicated on all Opensim versions to date. With real time analysis.
Additional Information [^]
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (1 Region per Sim)
Physics EngineBulletSim
Script Engine
EnvironmentMono / Linux32
Mono VersionOther
ViewerSingularity Viewer (64 bi
Attached Files

- Relationships

-  Notes
alecia ashbourne (reporter)
2015-03-19 22:57

OK. a little more positive than my last post I hope.

I've finally managed to get some decent performance from Bulletsim. I haven’t fixed Bulletsim, but I have managed to script and build around the most major performance issues as well as address a major memory problem, so hopefully I'll have some good information for those still struggling with large memory allocations.

I've made another little video showing one of my vehicles performing with these fixes, it was made for fun so probably not the best representation, but it demonstrates well how the server can be given some breathing space. I haven’t shown the stats in this video, but this vehicle barely registers, and the difference is visually obvious.

My previous test was on an unloaded (empty) server. This session was carried out on a busier set up with 10,000 + prims and 400+ active scripts

This vehicle has 40 prims 7 Euler rotating and 26 active scripts 3 of which have timers.
and was scripted from scratch for Bulletsim along with a new combat system. All function very well.

The servers running OpenSim Dev

Ubuntu 14.04.2 LTS (GNU/Linux 2.6.32-042stab093.5 i686)

I'm very pleased with the results and almost tempted to say please don’t fix bulletsim in case it breaks more - however working around these issues only highlights them all the more for me as needing some 'careful' attention or tweaking. Hopefully my solutions will help identify these problems better. Or perhaps its just time for us all to think a little different as to how we approach bulletsim as opposed OpenDynamics or even sl's Havock for that matter as Bulletsim is neither.

I'm going to put together a scripting, building and server set-up tutorial especifically for Bulletsim vehicle physics which will hopefully help to get all those interested back up and running under Bulletsim.

OK here’s the video url [^]

I wont clutter up the mantis here any more than necessary so I'll post a tutorial link here sometime early next week for those that are interested.
alecia ashbourne (reporter)
2015-03-20 16:15

OK so here is a link to a tutorial I wrote on building/scripting physics vehicles specifically for BulletSim. [^]
kenvc (reporter)
2015-03-20 20:52

I have found is that setting AppDomainLoading=false as suggested in the link above does NOT work well at all running under windows if there are many scripts in the region. My experience is that it caused the sim to become unstable very quickly and scripts often stop working until a restart is done... So Windows users be aware of this if you experiement with this setting. Its probably fine to set this to false if there are very few scripts on the sim.
alecia ashbourne (reporter)
2015-03-21 00:02
edited on: 2015-03-21 00:06

Yes, thank you - I should have been more specific, non of this has been tested under windows, the system this was tested on is the system that I listed in my report. I can only state conditions as stated under Linux and so I would make no recommendations for windows. This does not affect the script build tutorial, only the setup. I'll leave a footnote.

Robert Adams (administrator)
2015-03-21 08:24

Creating a simple physical shape 'under' a phantomed, complex visual shape is best for any physics engine. BulletSim handles rectangles and spheres best (lowest compute for collisions, etc) while mesh shapes of any complexity can use up a lot of CPU. Putting a prim in phantom state causes the simulator to not even tell the physics engine about that prim so others have built vehicles as linksets where all the prims are set phantom except for a few transparent simple prims which are made physical (rectangle for the body and spheres for wheels, for instance).

Making most of a linkset phantom is the scripting version of meshes having both visual and physical representations. Most authored mesh objects for games and such have both representations and BulletSim will use a meshes physical form if it is authored into the mesh (using Blender, etc).

The convex hull mentioned is that BulletSim converts the prim mesh to a different representation (a set of shapes that are convex) for better inter-mesh overlap calculations. The conversion happens when the prim is first made physical and can take a while -- you might notice the region freeze when you first ride a vehicle that's made up of many complex meshes and prims. This problem is mitigated by the above mentioned phantoming of most of the prims in the linkset (phantom means not physical at all).
Robert Adams (administrator)
2015-03-21 08:44

What is the problem you see with scripting? There are two 'problem' areas with BulletSim and scripting -- one is the vehicle physics functions themselves (complains that banking doesn't happen like SL, for instance) and the other is scripts in prims in a linkset. The latter is about reports that that a scripted vehicle with lots of scripts in each prim in the linkset (doing collision sensing, ...) causes high CPU usage. I haven't been able to reliably duplicate and debug this latter problem. Is this the problem you're seeing?
alecia ashbourne (reporter)
2015-03-21 10:43

Thank you Robert for clarifying the convex hull thing, I knew I’d read about it somewhere I just couldn't remember where, or the detail of it.

I do understand the phantom thing, perhaps I did a bad job of explaining why I chose to do exactly what you describe in your comments.

As for your last note - “The latter is about reports that that a scripted vehicle with lots of scripts in each prim in the linkset (doing collision sensing, ...) causes high CPU usage”

You hit the nail right on the head, this is exactly the problem, I would go as far as to say a physical link set full stop, regardless of many scripts or not. Anyhow, your point is better made than mine. I wasn’t so much trying to offer a solution as a workaround and perhaps give a little focus. But I do believe a proper solution is needed.

As for using prims for the root of the vehicle, of course this was my first port of call, but they didn’t behave quite as I wanted and I'm able to offset the centre of a mesh as I like it, this is just for aeroplanes, cars and boats I use a single standard prim, but the aeroplane needs to sit down after it lands to taxi and without a reference frame you cant torture a prim to give the correct shape at the correct angle, I'm dependant on gravity and the physics shape for it to sit on the ground correctly.

As for the functionality you refer to, such as banking etc. I have no issues with this or much else for that matter, Just having some rotational references finally is a god send, its just a matter of working out what works and what doesn’t and I'm enjoying that process.

So yes, the focus is really this physical link set thing, everything else is just everything else :).

- Issue History
Date Modified Username Field Change
2015-01-20 10:04 alecia ashbourne New Issue
2015-03-19 22:57 alecia ashbourne Note Added: 0027905
2015-03-20 16:15 alecia ashbourne Note Added: 0027909
2015-03-20 20:52 kenvc Note Added: 0027911
2015-03-21 00:02 alecia ashbourne Note Added: 0027912
2015-03-21 00:06 alecia ashbourne Note Edited: 0027912 View Revisions
2015-03-21 08:24 Robert Adams Note Added: 0027918
2015-03-21 08:44 Robert Adams Note Added: 0027920
2015-03-21 10:43 alecia ashbourne Note Added: 0027922

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker