Bullet vs ODE vs Ubode

[Alexina Proctor]

I am totally lost when it comes to picking the right physics engjne. I was on ODE, but with the upgrade to Opensim 9.1.x, some things stopped working. I tried switching to Ubode this morning, but then many older MESH things, like houses, cannot be used. I know the marketplace sandbox is now running Ubode.

What do I do? Ubode won't work. No time right now to replace a lot of houses since the kind of houses we need are not available on Kitely Marketplace. We want the quality of houses we see in SL....please, builders?

The question: Do I go back to ODE, which wasn't perfect, or do I go to Bullet? Isn't Bullet very old or is it under active development and improvements for the previous resource hogging?

Thank you,

[Alexina Proctor]

Hi Alexina,

Please see: viewtopic.php?f=8&t=5498

If ODE worked for you and some things break with your content when you switch to UbODE then I recommend you stick with ODE.

[Tess Juel]

Isn't Bullet very old or is it under active development and improvements for the previous resource hogging?

It isn't as old as ODE and it shouldn't be nearly as resource heavy as ubODE. Bullet and ubODE are two independent forks from the original ODE and for most practical purposes, Bullet is essentially an intermediate step between the other two.

[Wayfinder Wishbringer]

This is to the best of my knowledge. I am not a deep-core tech and reserve the right to be mistaken.

ODE is the physics engine that started out with OpenSim. Generally speaking ODE is fairly stable, but slow. Think of a Model T Ford that still runs very well.

BULLETsim was a replacement for ODE. It was much faster and for things like vehicles, allowed better performance. It also made regions in general run better as it was less "laggy". However there was a major issue or two: Bullet didn't always recognize prim shapes as it should. When a prim was cut to make a doorway, Bullet would often still recognize it as solid (as if the prim were not cut). Try to drop a sphere down a hollow tube and it may stick at the top of the tube or even be repulsed away as if a force were acting on it. Bullet had problems.

UBODE was brought in as a solution to those problems and for the most part it did so. But it had problems of its own. While it was hoped to be backward-compatible with Bullet, it became evident that Bullet vehicles didn't work so well under Ubode.

In addition, Ubode by definition recognizes meshes differently than Bullet, so quite a lot of mesh homes now have doorways one can't pass through, repeating the Bullet cut-prim problem, but with meshes. This problem seemed to increase dramatically with the advent of Opensim 9.0+. It was not uncommon to see a mesh race track (which had worked fine prior) now showing both avatars and cars 2m above the track surface, held there by some invisible bounding box surface.

The generally-recognized solution to this was to re-do the mesh (if one was the original mesh creator and knew how; if not, bummer). The other, more often-used, is to turn the entire building, ship or other creation phantom and then add solid transparent prims to form floors, decks and (if desired) walls (one has the choice to build invisible walls or let people walk right through the house). Many found this difficult as they had dozens or even hundreds of mesh buildings and landscaping items covering their lands. Doorways were no longer passable, roads could not be driven on, caves could no longer be explored.

If someone is an expert mesh-maker and doesn't buy other people's stuff, Ubode will work just fine... but that's maybe .01% of the population.

So now rather than a single fairly-stable physics engine-- we have three, each with its issues. Whereas Bullet and Ubode both solved some problems... both caused other problems for the majority of people. It is probably safe to say that had Bulletsim worked well, Ubode would not have been required. If Ubode worked well, people wouldn't be switching back to ODE (As we read above, Ilan himself has in some forum threads recommended such for someone who has tried to switch to Bullet or Ubode and experienced severe problems).

Generally speaking, stability beats speed. Users would rather have a home that works than fast cars that can't use their race track.

All three physics engines have their pros and cons, with people who like or dislike each one (or can't use one or two on their world because of major resulting issues).

In the new Weefolk Township in Wellspring world, both Bulletsim and Ubode were brought online to run tests and see if the experience could be improved (there was a desire to be able to use Bullet vehicles). Bullet broke the games in the Township (which wasn't at all acceptable. Tinies without games look for other mischief). Ubode broke almost every home on the land (they were all mesh). So in the end, the township decided to go back to ODE. ODE vehicles, while not the best at least would function. The homes worked perfectly, as did the games. It would have been nice to have the speed of Bullet or Ubode, but not at the expense of everything else.

Okay, that's probably more than anyone wanted to read with their morning coffee... but that's the gist of what we were able to determine in our research and experiments. Fortunately Kitely gives world owners the choice of which physics engine to use.

[Dot Matrix]

Thanks, Wayfinder, for an excellent summary of the issues and choices many of us face.

And thanks, Ilan and Oren, for keeping open the options for each of us to choose whichever physics engine offers the best compromise of features or stability for our particular regions.

[Tess Juel]

So now rather than a single fairly-stable physics engine-- we have three, each with its issues. Whereas Bullet and Ubode both solved some problems... both caused other problems for the majority of people.

It's mainly about backwards compatibility. A mesh with well made physics works well with all three physics engines. I've added a quick basic tutorial here: viewtopic.php?f=25&t=5691

This doesn't mean it isn't a problem though since there is a lot of mesh with less than ideal physics around and replacing/upgrading all of it isn't a realistic option but hopefully the problem will diminish as we get more and more mesh with well made physics.

[Wayfinder Wishbringer]

Yes Tess, I agree in ideal situations. Unfortunately, most people don't have the ability to update their meshes short of purchasing new compatible items. On another grid I had God powers and even tried saving a mesh item and re-uploading it. That not only took a great deal of time, but the upload failed to act any differently, no matter what "tricks" I tried.

I admittedly am not a deep core tech and know almost nothing (well, nothing actually) about the back end of virtual worlds. But from a user standpoint yes, backward-compatibility would seem key. It's odd that Bullet doesn't properly recognize cut prims-- a very basic physics concept. Ubode not recognizing open-hole meshes or mesh surfaces (while Bullet does)... well, hopefully there would be some way to fix that on the back end.

As you mentioned, if one has a world full of meshes, updating them all to be compatible with Ubode isn't even a possibility. Re-purchasing new buildings would not only be expensive, but in many cases not possible (no "new mesh" building is the same as what's there already). Even merchants are finding it daunting to re-do their meshes to match Ubode settings.

So it would seem altering Ubode to be compatible with what's there (i.e. "Is this a bullet-type mesh?" if that's even possible to determine) would be an ideal solution. Would also be nice if Ubode could determine if a vehicle is a Bullet or ODE vehicle rather than a Ubode vehicle. But as I am not a Ubode coder... I have no idea what (undoubtedly significant) amount of work would be required in doing so.

All I can state for a certainty is the impact this has on the user base... and they're the ones that keep the lights on so to speak. As a user, I'm all for stuff working on the user end. ;D

[Chris Namaste]

the only thing i so sincerly dream off is that, for exemple, could devide sandbox in two?

so everyone can (who cant afford a sim etc) upload their creations-art & sell on marketplace,
just my 50cent, since i donno anything techy neither

its just such a huuuge problem that 'normal mesh', that worked for 13years in different worlds (and still does in two that i work in),
isnt possible anymore to upload in kitely :'(
also buildings that are cool & good in dynamic,digiworlds,neverworld, are super & in kitely its such a 'phantom-cant go in the build' problem,
i cant xplain it better i'm afraid, since thats what we experience

not complaining, i got loads of respect for ilan & owen,
just expressing how it feels & it scares me alot
thankyou
christa

[Chris Namaste]

Hi Chris,

A world is a single VarRegion, it can't be split to run two different physics engines. In addition, the Kitely Merchants Sandbox is designed to enable merchants to test their goods before they upload them into Kitely Market. Many regions on the Hypergrid use UbODE so it's important merchants ensure their meshes will work properly on them. In addition, non-phantom meshes that aren't uploaded with collision (physics) meshes often create a lot more load on the region they are rezzed on. It is therefor in everyone's best interest that all newly uploaded meshes are uploaded with collision meshes regardless of what physics engine the region they are rezzed on uses.

Finally, Kitely enables world owners to select which physics engine their world uses so people can still easily import old content into Kitely without forcing it to become phantom on Kitely worlds and regions on other grids that use ODE or BulletSim.

[Tess Juel]

its just such a huuuge problem that 'normal mesh', that worked for 13years in different worlds (and still does in two that i work in),
isnt possible anymore to upload in kitely :'(

The real problem is that so many mesh makers on opensim and in SL don't make specific physics models but use the visual model as a makeshift one or even don't specify any at all. No physics engine is happy about that and I'm sure we all remember the time when Kitely had to have a function to automatically set items to pahntom to be able to handle the load.

But of course, we always have a last resort in prim physics; set the mesh to phantom and build a separate physics model with prims. It's far from ideal but it always works.