Snoots Dwagon wrote: ↑Sun Jan 31, 2021 2:43 am
NOTICE: Long-ol' Dwagon comment follows. This is personal opinion, based on a tad bit of experience. Nothing here is etched in granite. It's just a comment. Daring adventurers are fore-warned.
As Dot noted above, we conducted some major physics engine tests on Wellspring-- using all three engines.
The unfortunate
reality of things is that there are
three physics engines on Opensim... and none of them are ideal. Each has problems. Here is why:
1) ODE is a reliable physics engine, but as Ilan pointed out above it
can cause some physics issues
if not used correctly. However, if used correctly these physics issues are minor. The functional existence of our MegaWorld proves that fact.
2) BULLET was meant to improve vehicle creation and handling... but instead just created new problems. While the physics work well (vehicles, boats, ships, planes)... there were major issues with cut or "tortured" prims. Example: a block that was hollowed to make a doorway would not allow someone to pass through the doorway. Although it looked hollow, Bullet still recognized it as solid. This was widely known from the outset... but never corrected. Instead...
3) UBODE. This could have been
the solution, except for one major issue: failure to maintain backward compatibility. Ilan described this above:
Ilan wrote:"The reason ODE is used with older content is that it is able to handle meshes that are missing a collision mesh by using those meshes themselves as their collision mesh. This results in a lot of avoidable load on the server, so the OpenSim developer who developed UbODE decided to no longer allow non-phantom meshes that are missing proper collision meshes in UbODE.
That is the issue: one person decided to no longer allow non-phantom meshes that are missing collision meshes... despite the impact this would have on an already-existing wide base of ODE-compatible creations.
The alternative could have been to encourage proper mesh development while maintaining backward-compatibility with ODE. Instead, Ubode rendered hundreds (thousands?) of already-existing mesh creations non-functional, in which owners could no longer walk through doorways, cave entrances, etc. If the mesh was no-mod, it was now useless under Ubode.
We tried
all three physics engines in Wellspring. In the end we decided to go with ODE, since between the three it was the
least problematic (for our needs). Sure,
in some instances the mesh physics surfaces in ODE can impact server performance. But this is not a constant, lag-inducing situation... especially if those meshes are employed in a proper manner. The "server impact" issue proved to be over-stated. How do we know this? Because Wellspring is absolutely full of such meshes, it's a MegaWorld (64 regions)... and it runs just fine.
Why ODE for Wellspring? Because experiencing some very-minor supposed "lag" issues is far less-impacting to visitors than not being able to walk through doorways.
Are there fixes to these issues? Yes, there are. Builders and world-owners have long learned "work-arounds"... pains that they are. For example if one wants to use an ODE building on Ubode, turn any difficult buildings phantom, then use invisible solid prims to provide walkable platforms and walls. This of course results in a marked increase in prim-use (which is a server-impact issue, especially for lower-prim worlds), it takes far more time and effort to implement, and the phantom/prim trick isn't always feasible. (Ever tried to "phantom/prim" an entire mesh cavern / cave system?)
There are those who say to "re-create the mesh so that it conforms to Ubode". But is that a realistic recommendation? The end-user (who purchased the creation) usually does not have the mesh maps necessary to re-create a build. They likely don't know how to use Blender to perform such a complex re-creation. And the original builder may not wish to mess with totally re-designing a mesh creation, may no longer engage with virtual worlds and may not even answer messages. This is reality.
Many have heard it stated, "Creators should make meshes properly in the first place". Well, Linden Lab should have implemented meshes properly when they first introduced them to virtual worlds. What does that have to do with today's reality? With respect,
things are what they are and saying people "should have done" this or that doesn't change the facts of how things exist
now. The "should have" sentiment doesn't help a world owner who is trying to make his/her several-hundred mesh builds work with whichever physics engine is currently driving their world. "Should have done" won't make a Bullet vehicle work on an ODE world, won't make an ODE structure work with a Ubode world, won't make Ubode compatible with uncounted existing ODE mesh creations.
This is the reality of virtual worlds as they exist today. Forgive me for being blunt here: this is mainly because people are diverse and have their personal ideas of "how things should be"... and sometimes are in position to force that opinion on all of virtual worlds regardless of what the majority of people think or need. That's why we have
three different physics engines, all with their individual problems, instead of one really good one that solves those problems.
I give paws-up to improving physics and world operation. But such improvements should take into strong consideration already-existing needs. We can't expect creators and scripters to change thousands of vehicles to meet some new spec designed by one person. So the physics engine would do well to recognize older meshes and vehicles and enable them to function as intended. That is a lot more workable. That is the Gold Ring, so all of Opensim can switch to one, centralized physics engine, everywhere. No more confusion.
As Gregg states above: a
good mesh should work with any physics engine. But that's not the reality of virtual worlds. Conversely, perhaps the physics engine should be able to handle existing creations as well as "good meshes". To handle one and not the other really doesn't meet the needs of the users of Opensim.
We currently have an Opensim that is riddled with
three different physics engines that are not compatible with one another. That is the prime issue being discussed in this forum thread... and why that $15 building isn't working. Ideally, one physics engine would pull ODE, Bullet and Ubode together into one compatible package-- and still encourage future mesh-makers and scripters to work smarter.
While we at Wellspring would have loved to use Bullet or Ubode vehicles, after significant testing-- the Board at Wellspring
unanimously voted to go with ODE... and as a builder / scripter I have to say we have far less trouble with ODE than the other physics engines. We have to build / script wisely and sanely, but we have working vehicles, working boats and ships, working airships... and most importantly of all we can actually walk through the doorways in our homes.
If someone buys an ODE-compatible building and has Ubode land and finds the two aren't compatible, the choice is to try to get your $$$ back from the merchant and promise to delete the creation from your inventory... or (as mentioned prior) turn the building phantom and build invisible physical floors and walls in the building. That may be fairly easy or really difficult, but those are the types of choices we have to make under the current circumstance.
It's my opinion that if a creator knows his product will not work with a certain physics engine, proper notice should be given in the product description, such as "This product is designed to work with ODE and Bullet. Ubode users will need to modify the item for compatibility." Or... the creator might include two versions: one that is ODE compatible and one that is already Ubode-modified so the buyer doesn't have to mess with all that.
Okay, I done now.