Prim physics secretly changing to convex hull
tracked
LRRiven Resident
I have built a full mesh airship that occasionally, for no reason I can define, secretly changes from Prim Physics to Convex Hull.
I am seeking a resolution to this as it is a product I am selling and I want to give my clients the best possible experience.
I have reuploaded parts of the build and detached parts I had given the Physics of 'None' from the main ship. I have even detached the doors thinking maybe the door script was doing it somehow. Even after all of this, the build will still randomly go into convex hull.
There are many pieces in the build. This is what the physics looks like:
Any suggestions for what I might try to resolve this issue?
Log In
Maestro Linden
Merged in a post:
Objects getting “stuck” with a convex version of their physics.
Drau Resident
This is in response to the bug being mentioned in the 2025 week #13: SL SUG meeting regarding "there have been reports of objects getting “stuck” with a convex version of their physics mesh".
This is also possibly related to: https://feedback.secondlife.com/server-bugs/p/prim-physics-secretly-changing-to-convex-hull
This bug has been around for a very long time (since at least 2013) and I have seen this happen several times, especially when a large amount of items are rezzed close to an avatar.
This seem to be triggered by attachments worn by avatars, when it intersects the convex hull physics when rezzed. Videos can be found below reproducing the bug.
- The object has a convex hull that is at an angle. I set it to prim physics before picking it up.
- Wearing no attachments and a basic skin, I stand right where that angle of the convex hull is, which result in me being bump away and for a moment. I can walk on the convex hull shape before it fixes itself to prim.
- Wearing a mesh body, head, clothing etc, I try it again. This time, the physics never change to prim. The way I fix it toward the end is simply right clicking it and clicking off again.
Please let me know if you need any more info or want the objects in world for further testing. ♥
Journey Bunny
Ahhh, interesting. I have a tracked issue on this as well, where the problem occurs even with a default Avatar-- in my case, objects are switching to convex Hull when the Avatar is "physically" interacting (The objects don't have physical turned on, it's just when an avatar interacts with the object's physics shape, like walking on it) while performing an action that causes an object property update. For me it happens when clicking on a door that is supposed to slide.
Same fix in my case, right clicking usually fixes or sometimes I have to right click and choose edit linked and then everything goes back to normal. Basically I'm manually triggering an object update. Unsure if it's part of the same issue, since mine is not happening with attachments, but all of the other aspects of the behavior you describe are happening to me too.
Maestro Linden
tracked
Maestro Linden
Ah, I see now from the instructions in the notecard that the repro steps involve llSetKeyframedMotion. This is a known issue, tracked in https://github.com/secondlife/jira-archive/issues/11360
Maeve Balfour
I think this has possibly been an issue ever since mesh was officially released back around 2011.
Years back (roughly 2012) I had a floor mesh object which was essentially an L-shape, with a custom physics hull to suit (part of a larger linkset). The physics was set to prim and the floor mesh would work as expected. However it would randomly seem to change to convex hull for unknown reasons (making the gap in the floor mesh "solid" in regards to physics). I could never nail down how long it would take for the weirdness to happen after being rezzed; just that the object would become convex hull for some strange reason (possibly sim restarts were breaking it?)
Not really a fix per-se, but I discovered that if I went into build mode / select linked and simply selected the affected object (no actual edits required), it seemed to jolt it back to its correct physics type.
Unfortunately I no longer have the aforementioned mesh, having purged it years ago (I assumed it was cursed and deleted it LOL). I ended up cheating around it and used hidden prim cubes to fake the physics hull in lieu.
I will be curious to see what the eventual findings are of this issue.
Eren Padar
I have wondered what is going on. Last night we had a dance platform surface change to "phantom" and the avatars sink half a meter... and nothing we could find or do would fix it. The "phantom" box was not checked in the edit window, and checking / unchecking it didn't change the phantom nature of the surface. We had to put an 'invisible floor' over the top just to be able to use it.
This didn't happen during use, but rather happened when we rezzed the item. The surface was "broke" when we rezzed it (or shortly thereafter). This platform had been used before without problems.
The physics changing form would certainly explain what we experienced. As a note, we have experienced such things before... for years. I've always called it "broke prim"... a prim that suddenly doesn't work, for no explainable reason. Sometimes the prim contained a script (and the script wouldn't work, for no understandable reason). Sometimes the prim was empty and as describe in the OP, "turned phantom".
There was no fixing it, no correcting it. We've always had to simply duplicate the prim and delete the original. This has been happening as long as I can remember. As this behavior is very erratic it will be nigh impossible to track down why this happens... but prims do "break". There's no doubt of this; it's been witnessed many, many times.
Maestro Linden
needs info
Maestro Linden
LRRiven, are there any scripts in the build which either enable physics on the linkset or cause any of the prims (such as the propeller) to spin with llTargetOmega or similar?
If the object were set to physical, than any meshes set to shape type 'prim' would be expected to switch to a convex shape.
If some child prims in the linkset are spinning with llTargetOmega(), the physics shape ideally shouldn't be affected (as the spinning effect is visual-only). However, there's a known bug that in such cases this can cause "prim" type physics to incorrectly switch to convex hull on certain events such as region restart.
Cain Maven
Maestro Linden Unfortunately, it's not limited to llTargetOmega(). Moving the object via script oftentimes has the same effect -- the physics shape type is internally set to Convex Hull. The only known workaround is to manually edit the object and hit Esc without making any changes; that is enough to return the object to its previous and proper physics state. Note that querying the object's physics shape type while this is in effect will NOT yield Convex Hull.
Maestro Linden
Cain Maven: Okay, this might be a new issue, then. We need specific steps to reproduce it in order to fix this issue, however.
Cain Maven
Maestro Linden Do you need more info to fix the issue I described or the original post? I'm happy to provide a test object for the issue I outlined (which may be a superset of the llTargetOmega() case, etc.)
Maestro Linden
Cain Maven: Sure, but I'll want a scrubbed copy with minimal scripts, and some tips for how to trigger the bug. LSL scripts can legitimately change the physics shape type of prims via the PRIM_PHYSICS_SHAPE_TYPE parameter or (if it's a mesh) by enabling PRIM_PHYSICS, so we'll want to rule that out.
Cain Maven
Maestro Linden I have sent you a folder with the necessary description, test object and test scripts in-world.