The current stable and official release is OpenSim 0.8.2.1, which Kitely uses albeit with its own additional modules that optimise performance. [Note: This is NOT a fork of standard OpenSim; Kitely's proprietary modules are external to it.]
The development branch of OpenSim is 0.9.0; the OpenSimulator Wiki download page says: "This candidate is made available for testing -- if you require more tested code then please download the current release instead."
In his DreamWorld installer (a worthy successor to Sim-on-a-Stick), Ferd offers a choice of OpenSim 0.8.2.1 or OpenSim 0.9. In a post on Google+ he says 5% of DreamWorld users choose 0.9, and 95% keep to 0.8.2.1.
There may be reasons for this disparity. OpenSim 0.9 introduces a new physics engine, ubODE, which can cause problems for existing content and builds (see for example the earlier discussion on this forum Opensim 0.9 dev version is breaking things). This was brought out again in the chatlog from the community meeting on 30 July 2017 (see below). Content creators have long been expressing concerns about this, only to be told (in effect): "The current system is WRONG. This is the right way. You have to change to it -- re-upload your mesh creations to match the new system."
What about existing mesh objects? To quote from Sunday's chatlog...
The current draft release notes for OpenSim 0.9.0 list the following Known issues:[13:29] Dot Matrix: As a non-techie, may I ask about how this affects existing mesh?
[13:29] Ubit.Umarov @hg.osgrid.org: some will not work on ubOde at least; houses are a typical example all over ... it will have a CONVEX collision, i.e. no openings etc. In some parts you may see the avatar in air
[13:44] Dot Matrix: What should we do with older meshes?
[13:44] Ubit.Umarov @hg.osgrid.org: try to re-upload them correctly
[13:44] Dot Matrix: What if that is not an option? If they were made by someone else, for example, but are still part of an overall build
[13:45] Ubit.Umarov @hg.osgrid.org: then it’s a nice opportunity for you to get a new house :p
Here are a few "Changes and fixes" from the release notes:
- Mega Regions are no longer supported. Please save your mega regions in OAR files before upgrading. ...
- Mesh creators can upload a mesh that will only collide with the default convex hull (physics type PRIM is not available, only NONE or CONVEX). The new physics engine ubOde will honor this option. ODE and Bullet will keep using a visual LOD with this option, so still show the PRIM type, but physics shape type may not work correctly. Please fix the meshes uploaded with this option by mistake, ... If that is still impossible, then keep using Bullet. But note then we will also change Bullet in future.
- ubOde like the older ODE only does single side mesh collisions while Bullet, like SL, does double sided collisions in some cases. Creators doing specialized colliders for physics should take this in consideration. Since in this respect ubOde is the more restricted engine, a collider working on ubOde should also work on Bullet. This version includes some changes also to the external ode library for avatar/mesh collision, but it still displays some instabilities in same corner cases.
- ubOde (RC3) supports CONVEX on normal prims and sculpts. You may have that set by mistake, and may need to fix it.
- Using a viewer's physics upload Step2 and Step3 changes the uploaded mesh format. The mesh is simplified and split into a collection of convex parts. This can deform your shape on the viewer side. Uploading without these steps avoids these problems.
- The Physics engine ODE (the original one) is maintained for compatibility purposes only. Please avoid creating new content for it. Use it only if your region has a lot of content you can't upgrade now.
Now, I can see that the improved performance of llCastRay and vehicle crossings would be of use to a few, and no doubt some of the bug fixes listed. But is that really worth the pain and grief that will be inflicted on ordinary users by breaking their existing content so thoroughly by changing to OpenSim 0.9?
- BulletSim is the default physics engine with updates to support better vehicle crossings and different default collisions sounds intensity introduced with ubOde.
- ODE Now supports variable-sized regions.
- New ODE-based physics module: ubODE. This came from the Avination grid and is designed to support more advanced physics features.
- llCastRay: with ubODE, this function is performed by it with improved performance and more accurate results. according the to physical representation of the objects.
Here's the tidied-up chatlog from Sunday's Kitely Community meeting.
Code: Select all
[13:04] Selby Evans: Re: previous discussion on BulletSim: Comments from Mister Blue: TL;DR: there are no plans to change how BulletSim uses meshes. Long form: ubODE is doing it the way SL handles the mesh settings. BulletSim, which was developed before LL finalized the SL mesh settings, is more 'friendly' as it uses the display mesh if the physical mesh is not in the mesh file. This seems to happen a lot in OS meshes and thus BulletSim is not changing as changing to SL compatibility breaks some existing content [13:06] Ubit.Umarov @hg.osgrid.org: well that comment is not correct. that meshes issue is not only SL compatibility. [It] is in world usability, especially if you want to do vehicles etc. It’s not about making life easy... [it] was making it wrong [13:08] Selby Evans: I think Bulletsim is the default physics for 0.9 [13:09] Ubit.Umarov @hg.osgrid.org: well possible that will need to change Bullet is has no active support for a lot of time so bullet is still the default, but possible that will need to change.. [13:08] Dot Matrix: Ubit, what is your understanding of the situation, please? It would be very helpful to hear -- thanks. [13:11] Ubit.Umarov @hg.osgrid.org: issue bullets with meshes is incomplete or wrong handling on Physics Shape Type. The (incorrect) use of the visual mesh is only a detail so that handling of physics shape type, will need to be fixed. The impact of that on the (incorrect) use of the visual mesh, is something to see then [13:15] Ubit.Umarov @hg.osgrid.org: when we speak about ODE or Bullet we mainly speak about opensim’s use of the external physics libraries and at this point opensim is the actually quality defining part. ubOde and Old Ode basically use the same external library [but] with very different results [13:16] Mike Lorrey: ODE isn't native to Opensim. It’s an industrial physics engine people coopted for OS with incomplete implementation. For instance, ODE has hierarchies for mechanical linkages, hinges, robotics, but OS doesn't implement hierarchies in linksets. [13:17] Ubit.Umarov @hg.osgrid.org: ubOde is basically a redesign of the old ODE opensim side code. only recently ubOde started using a modified external library. We now did fork ODE library also because ubOde did reach the point where that does make a difference. [13:20] Rosa Alekseev: which difference Ubit? [13:20] Ubit.Umarov @hg.osgrid.org: well the meshes issue.. just meshes are not simple things like MIke can tell you, so some "simplifications" do not work and end up creating the issue we now have [13:20] Dot Matrix: So does that mean that the OpenSim version is diverging from the basic ODE? [13:20] Ubit.Umarov @hg.osgrid.org: Yes Dot. no longer the same code as original ODE [13:21] Ubit.Umarov @hg.osgrid.org: well for now on some details.. thing is that [the external] ODE [library] dev also stopped and some basic bugs are still there, like that old one that made avatars fall on terrain you remember? [13:23] Selby Evans: Yes -- avatars fell though the ground [13:23] Ubit.Umarov @hg.osgrid.org: well that capsule/heightmap bug is still not fixed in ODE. I just worked around it in ubOde. This just to say that yes at this point 0.9 is using also a fork of external ODE. [13:25] Dot Matrix: Right, by working around that bug, and others, at a guess? [13:25] Ubit.Umarov @hg.osgrid.org: yes and other little issues [13:27] Ubit.Umarov @hg.osgrid.org: when uploading a new mesh, if you want it to have high resolution collisions, DO select a Physics mesh. That way it will work on any physics engine [13:29] Dot Matrix: As a non-techie, may I ask about how this affects existing mesh? [13:29] Ubit.Umarov @hg.osgrid.org: some will not work on ubOde at least; houses are a typical example all over [13:30] Selby Evans: Will not have collision? [13:30] Ubit.Umarov @hg.osgrid.org: worse, it will have a CONVEX collision, i.e. no openings etc. In some parts you may see the avatar in air [13:31] Ubit.Umarov @hg.osgrid.org: you can check it here: edit the object.. go to features, Physics Shape Type. Those meshes will not show PRIM here, and of course ubODE will not do PRIM, since it is not there [13:33] Dot Matrix: What should show there, Ubit? For meshes that will continue to work? [13:33] Ubit.Umarov @hg.osgrid.org: meshes that do show PRIM will work fine on any engine. Problem is that Bullet decide to to PRIM when it is not there, so everyone never noticed that the upload was not correct [13:35] Dot Matrix: What about meshes done in the old ODE system? [13:36] Ubit.Umarov @hg.osgrid.org: err understand.. this are upload options. Does not matter the engine you have selected, only the options you select on the upload [13:36] Nathan Adored: so, prims, convex hull, and physics-model are what we SHOULD have as mesh upload options, but don't? [13:37] Ubit.Umarov @hg.osgrid.org: to have PRIM you need to select a mesh on step 1 of the physics tab on upload and for a house, PRIM is needed, for example. while for a car.. it’s better now not have it.. and add prims later because a car should be very light on physics so a lot better to do its collisions using boxes and spheres. you need to understand that uploaded meshes are not generic anymore [13:40] Mike Lorrey: yes the only part of the car that should be prim is the invisible root that the script is in and which contacts the ground. [13:40] Nathan Adored: okay, so what happens if you want to make, say, a large space vehicle that you want to be able to walk around in like a house, but occasionally want to be able to fly it around? [13:40] Mike Lorrey: flying vehicles shouldn't be a problem since they only contact things on takeoff or landing [13:41] Nathan Adored: okay, so what if its a large sandcrawler thingy you sometimes want to use as a house, but sometimes want to drive it around the sim? [13:41] Ubit.Umarov @hg.osgrid.org: [Parts with] the shape type None is not sent to physics at all [13:42] Mike Lorrey: since many of us are creators who sell across the hypergrid, it is an issue of some importance, not to mention the debate over upgrading Kitely's OS when 0.9 finally becomes an official release [13:43] Nathan Adored: assuming it does. anyway [13:43] Ubit.Umarov @hg.osgrid.org: review some mesh tutorials made for SL; ignore old ones made for opensim [13:44] Nathan Adored: yeah, the old OS ones got scrapped when they started moving towards 0.9 dev [13:52] Ada Radius: I had no clue, was reading the wrong advice - I knew something was wrong with the thing and gave up. [13:44] Dot Matrix: Question: What should we do with older meshes? [13:44] Ubit.Umarov @hg.osgrid.org: try to re-upload them correctly [13:44] Dot Matrix: What if that is not an option? If they were made by someone else, for example, but are still part of an overall build [13:45] Ubit.Umarov @hg.osgrid.org: then it’s a nice opportunity for you to get a new house :p [13:45] Nathan Adored: Yeah, is there some means of implementing an optional item-by-item conversion thingy on them in the DB like was done with some of the sit-positions stuff after that changed? [13:46] Ubit.Umarov @hg.osgrid.org: well possible.. but not nice to keep bad stuff around because ppl meshes are a bit complex things [13:46] Dot Matrix: Is it not possible to adjust things inworld, Ubit? It's not nice having to scrap favourite models either [13:46] Mike Lorrey: make your house phantom and use invisible prims for floors and walls [13:47] Dot Matrix: Thanks, Mike -- is that what we need to do? Turn the things to phantom, then add invisible prims? [13:47] Ubit.Umarov @hg.osgrid.org: need a bit more learning.. remember how we did need to learn about prims? all those torture etc ? well meshes are a bit more complex like mike is teaching. upload a mesh and tell physics to use a mesh equal to a LOD is not a good option especially if you plan to sell it !! to have a product worth paying for, you need to have a bit more work like providing a proper mesh for physics (as proper LODs... viewers not always make them nice) [13:50] Nathan Adored: and yeah, the LOD/prims-count goes UP when you add prims to a mesh [in Opensim], while on SL it will often absorb that land impact into the LOD of the mesh. at least it did that on ONE of my projects there [13:51] Mike Lorrey: we may not have upload costs when we upload a mesh, but there is still an impact on region stability from having too much high streaming cost high-poly-physics meshes in a region [13:51] Dot Matrix: OK... that is what creators need to do. What about those of us who have meshes made by others? How can we sort those out in our own builds where we DON'T want to get new things? [13:52] Nathan Adored: yeah, ultimately there DOES need to be some way to "reform" old meshes that you can't get re-uploaded by the maker.... but that break with the new system. [13:52] Mike Lorrey: ah well any old meshes that are not structures that need to be walked on, used as walls, you should set them to NONE; that way the physics engine ignores those anyways [13:52] Ubit.Umarov @hg.osgrid.org: yes many of those meshes are actually ok, for example avatar ones need no physics or as i said for cars.. etc. that is why i can't add a magic automatic fix tool [13:52] Ada Radius: Obsolete stuff meh. I just got rid of the last of the VHS tapes in my library. [13:53] Dot Matrix: Ada, in "classic" builds it is a big issue. [13:54] Ada Radius: @Dot - I know it's a big issue. None of us are going to like the answers but we need to deal with it. Selby, for example, has a gorgeous Greek theater iSL that was built for him in around 2010 I think. All sculpt maps. Should he just delete it? probably. [13:56] Nathan Adored: but he doesn’t wanna delete it because he has such a strong ties to it? [13:57] Ada Radius: I just meant that we all have a lot of wonderful builds in obsolete formats. There are hacks and workarounds, sure, and some good reasons to keep legacy artwork. [13:55] Ubit.Umarov @hg.osgrid.org: well I’m open to suggestions.. I’m not changing things to make ppl unhappy of course [13:55] Nathan Adored: well, obviously a generic across the board fix won't work, but it would be interesting if there was some way to select a specific asset in the DB, and have some under the hood conversion done on THAT and all identical copies of it that have spread thru that system [13:56] Mike Lorrey: it’s tough due to the permissions system, for content whose creators are no longer active. Dragging them back in kicking and screaming to fix stuff isn't likely going to happen. [13:56] Mike Lorrey: I have a trick for exporting sculpt maps to blender. You can use a script function to grab the UUID of a sculpt map, apply it to your own created prim, and export that to blender. [14:00] Ada Radius: @Mike: another way to get sculpt maps into Blender is to hack the map out of cache, run it through a sculpt generator (I have a freeby) and save it as dae. [13:56] Ubit.Umarov @hg.osgrid.org: sculpt maps are a different thing. actually i never tested them on bullet. they work on on ubOde and now that the 3 options including full convex as all prims [13:58] Ubit.Umarov @hg.osgrid.org: if you have prims select as convex, that does nothing here or on bullet and it will work on ubOde, so another thing to watch out [14:00] Ubit.Umarov @hg.osgrid.org: think sculpts are still a nice option. the fact we have meshes does not mean they are the best option always [14:01] Ada Radius: Right - sculpts are limited. We can do more with fewer vertices in mesh. That said, I learned a lot about texturing mesh by looking at Aley's sculpts and her use of them for things like moving parts on creatures and such is harder to do with mesh [14:03] Nathan Adored: I've mostly just used Mesh Studio over on SL to convert linksets to mesh.... tho most of the linksets are from my build platform on one of the opensim worlds ...with me then bringing the resulting mesh back to that opensim world [14:03] Ubit.Umarov @hg.osgrid.org: not sure that is good in lots of cases [14:05] Nathan Adored: Mesh Studio is a scripted thingy where you drop it into the root of the linkset you want to convert, and it sends a message to their server describing the object, and it then gives you a mesh based on that linkset as a zip file to download [14:05] Ubit.Umarov @hg.osgrid.org: you can do the analyse steps [for the physics upload on the viewer’s physics TAB].. but that may fail more because of the viewer’s code and that does deform the mesh. SL likes the analyse options on physics mesh upload.. not so good for us, at least now [14:09] Nathan Adored: yeah, I usually just give it a simplified model instead.... or try to, anyway, sometimes it’s simpler to just feed it another copy of the regular mesh, if it’s a fairly simple object.. Say, a table or something [14:09] Ubit.Umarov @hg.osgrid.org: well analyse is also a format change. it also does convex decomposition havok needs [14:11] Dot Matrix: Yes -- thank you very much, Ubit, for patiently answering questions and explaining things. I bet you weren't expecting all that! [14:13] Nathan Adored: these meetings get really interesting.... all sorts of different sometimes-meaty subjects. It’s one of the things that keeps me coming back every week. :D [14:14] Dot Matrix: Well, it's past the hour so time to bring the discussion to a close.