Bullet vs ODE vs Ubode

[Ada Radius]

It's also fairly easy to set an old mesh building, or a sim-full of them, bridges, roadways, ships, space stations, all of it, to phantom. Use area search with whatever search terms you need to find everything - you don't need to fly around. Then use one transparent six-vert mesh cube or a 4-vert plane, that has physics set correctly, copy and resize as many times as you need, to insert into walls, walkways. There's a free set of full perm simple mesh objects - cubes, cylinders etc., at the Cookie II sandbox and I think Oz Wayfarer has some at his sims as well. Takes less time than struggling with old physics engines.

[Tess Juel]

Then use one transparent six-vert mesh cube or a 4-vert plane, that has physics set correctly, copy and resize as many times as you need, to insert into walls, walkways.

No, please don't!

The old rule if it can be made from a single prim, make it from a single prim, still applies. Avi Bar-Zeev did a thorough test of this when he developed the prim system and the conclusion was clear: The reduction in streaming cost of prims vs mesh more than compensates for the few extra triangles the render engine may have to handle.

The difference is even bigger when it comes to physics. Simple prim shapes like cubes use convex polytopes for physics and those are much easier for the physics engine to handle than the triangle lists it has to resort to for meshes.

[Ada Radius]

I think there's a difference of opinion on which is easier on servers and viewers, fewer verts in a mesh cube or plane or the ubiquitous prim. Ilan?
Either way, turning all your old buildings phantom and fixing them with the same physics object copies throughout, is one solution to the problem of dealing with large builds no longer compatible with newer physics engines. And doesn't take that long.
I've done it, speeding up the process by partnering with another builder. While we were at it, we also swapped out stuff that would not save to an OAR and whatever other cleanup generally needed.

[Alexina Proctor]

Loading a mesh takes longer but handling a collision mesh with a lower triangle count is preferable. Kitely loads meshes quickly but reusing assets is always a good idea.

[Tess Juel]

Loading a mesh takes longer but handling a collision mesh with a lower triangle count is preferable.

Are you saying opensim 0.9 uses triangle physics for prims too? That's a bit strange and rather inefficient. Both Bullet and ODE support the same geometrical bodies as HAVOK and these are always mode efficient than triangles lists. (Bullet even has an extra one, the cone, that is not supported by the others.) I don't know for sure about ubODE but Ubit told me it was an upgrade of ODE and surely he wouldn't have missed one of its most basic and important functions.

I think there's a difference of opinion on which is easier on servers and viewers,

It's not a matter of opinion, the performance difference between geometric bodies and triangle lists is well known and documented. One question, however, is if opensim somehow managed to miss that trick. If it did, it's a bug that should be fixed. (Or maybe opensim somehow managed to find a way to implement geometric bodies for meshes too? If so, that's seriously impressive. But I doubt it.)


Edit:
I'm not sure how much I should go into detail about how physics engines work but basically, it operates with two different kinds of physics: geometric bodies (aka volumes, aka polytopes) and surfaces. The most important difference in this context is that a cube prim is treated (or at least suppposed to be treated) as one single physical body. For a mesh cube each triangle is treated as a separate physical surface. Physics calculation for surfaces is also a little bit more comples than those for gaometric bodies but the main difference here is the sheer number of calculations the physics engine has to perform: one for a prim cube, at least twelve for a mesh cube.

[Ilan Tochner]

Hi Tess,

I haven't worked with the physics code, so I may be mistaken about this, but while I agree that finding whether a point is inside a simple geometrical shape can be done using a simple equation, I doubt there are such simple equations for calculating collisions with sufficiently tortured prims. Whether or not OpenSim differentiates between the two and handles them differently is a question I'd address to someone who has worked on that code.

[Tess Juel]

I doubt there are such simple equations for calculating collisions with sufficiently tortured prims.

Oh, you're absolutely right there. I was talking about the simple prim shapes that matches the standard geometrical bodies. In other words, untortured cubes, spheres and cylinders. The discussion here was about prim physics and that means cubes, I can't imagine anybody would want to use tortured prims for that.

[Wayfinder Wishbringer]

As I've stated before I'm by no means a deep tech. That doesn't mean however I can't chat with deep techs... and over the years have done so several times in regard to the dread lag monster. We've also run some rather incredible tests to see what lags and what doesn't.

I know this is an old debate, but I still strongly hold that regular prims don't lag. Admittedly, everything on a virtual world lags to some extent. But when one rezzes 80,000+ various-shape prims and it has absolutely no viewer-perceivable or measurement-perceivable effect on the system... one has to conclude that prims don't lag. (One experimenter did a legendary 140,000 prim count. Zero measurable lag.)

Mesh... can't say the same. Sculpties, can't say the same (why do sculpties take so extremely long to load, anyway? Or often fail to load). Speaking to a tech Linden several years ago I was told (for whatever it's worth) that standard prim shapes are part of some kind of internal automatic library that the system recognizes more quickly than anything else on the grid. (He was talking to a layman and simplified it). His statement: These are basic shapes that are instantly recognized by the system, so in his words: prims don't lag.

To prove this I set up a test on OSgrid that I managed to get one person to attend (sigh). 80,000 prims of various shapes set up in a circular wall within a 30m radius. Invited people to the center of the circle to take whatever measurements they wanted to take. As expected, zero lag.

If we're talking physics, make the floor out of 80,000 prims. Make sure they're all exactly the same height-- because edges cause collisions. Walk across it, try to measure any kind of lag at all. (Of course it goes without saying that a large, single-prim floor is better.)

So the bottom line: if making invisible floors, I recommend prims. Of course if the original floors are uneven and one is a mesh master, at times invisible physics meshes are warranted. I'm not a mesh master, so the question is moot: I use prims.

What I am unaware of is why meshes (to my knowledge) mostly worked before OpenSim 9.0+.... and then suddenly broke with the release of 9.0 (or so I've been told / noticed / experienced etc). But bottom line doesn't matter why. What matters is the best way to fix this without having to totally rebuild or replace or phantom & floor every mesh creation of hundreds of meshes on a large VAR / World. I spent ten years creating one of my worlds. I don't look forward to having to go through and weed / phantom / refloor all the "bad meshes" just so folks can walk through a doorway.

[Tess Juel]

I know this is an old debate, but I still strongly hold that regular prims don't lag.
...
Mesh... can't say the same. Sculpties, can't say the same

It's not quite as simple as that. Different building materials load the system in different ways. I posted an article about it at my "tech-for-the-not-tech-savvy blog a while ago: https://chinrey.blogspot.com/2019/03/la ... ulpts.html

(why do sculpties take so extremely long to load, anyway? Or often fail to load).

Mainly because the code handling it a crude hack. Sculpties are a very good idea in principle with a number of advantages over both prims and mesh. But rather than write software specifically for handling sculpts, LL decided to patch together bits and pieces from the prim and texture codes and that never really worked well. I'm not sure why they did it that way. It may be because they didn't have the capacity to write brand new code from scratch at that time or it may be because they fired the Linden who invented sculpts in the middle of the developing process and his successors weren't too keen on the project.

(Edit: just fixing typos)