False error report when failed rez on mesh
tracked
Eren Padar
Sometimes when rezzing on a mesh object, not only does the item fail to rez, we get a false error message which states "The object failed to rez because the owner of the land does not permit..." etc etc. This gives the false impression it is a land setting issue, when in reality it is a rez-on-mesh problem. When the item is rezzed on bare ground or a standard prim, it rezzes first time every time, with no error message.
Log In
Leviathan Linden
I visited the FS Jira issue 15429, downloaded the bugged mesh Quad.dae, uploaded into SL, rezzed the mesh, and tried to rez a box on top of it --> the failure to rez reproduced. Upon deeper investigation I discovered: the collision mesh in the Quad.dae is being loaded on the server with only three points: <1,1,-1>, <1,-1,-1>, and <-1,-1,-1>. It collides like a triangle displaced below the center of the visible quad by 1 meter. When I move the quad up to eye-level I can collide my avatar against the object, including standing on top of it, to verify the offset of the collision shape.
Meanwhile, when the viewer submits the request for rezzing the second object on top the mesh it provides the ID of the target mesh object and a line segment -- the server is supposed to do a ray-trace along the line-segment, hit the target object, and use that hit to compute a rez position of the new object. Unfortunately, the ray-trace doesn't hit the collision shape of the target object (offset by 1 meter below the visible shape) and thus cannot determine a position for the rez --> it fails.
There isn't much the simulator can do about bad mesh collision shape supplied during upload except to overhaul the mesh-asset-upload system to assert more correct collision shape at time of upload.
The correct short-term fix is to change the failure message from the simulator to provide a more helpful message: something about how the "final rez position could not be computed".
Eren Padar
Leviathan Linden That's quite a bit of work you did. It's appreciated. However in my observation, this action happens on just about any mesh, not just "bad mesh collision shapes". I'm impressed at the depth you went to in order to observe this. But either every mesh on SL is a 'bad mesh"... or something else may be going on.
Mesh behaves oddly on SL. For example: ever tried to alt-look a mesh object? The camera goes right through it as if it isn't there. Ever tried to zoom in on a mesh object? Same effect. You zoom in on whatever is behind the mesh. Ever tried to zoom or look at a mesh avatar? Classic avatars, no problem. Mesh avatars, problem.
I'm not a mesh tech at all; I know almost nothing about mesh... except how it behaves from a user standpoint. I believe mesh behavior on SL needs revisited.
Leviathan Linden
Eren Padar that may very well be the case that most rez-object raycasts against mesh objects fail. I realize now that the collision shape of the Quad mesh is based on its lowest LOD which is a triangle, however there is a -0.5m offset along the local Z-axis which must be caused by a bug somewhere in the LOD submission pipeline. We can expect that other meshes suffer from a similar problem: the collision shape is different from the visible one used to produce the hypothetical line segment "ray_start + ray_end" data supplied by the viewer, which can cause the line segment to "not quite reach" the collision surface.
I have submitted some changes to the simulator that will hopefully be included in late February or early March (which will be called 2026.02-Loganberry) update: when the initial ray cast fails against mesh then a simpler "cast against the objects local bounding box" strategy will be attempted and the rez failure will only happen if both casts fail. Also, the simulator will supply a more correct alert message in the event of failure.
Eren Padar
Leviathan Linden Awesome. Thanks Leviathan!
Jellyfish
marked this post as
tracked
Jellyfish
Issue tracked. We have no estimate when it may be implemented. Please see future updates here. https://github.com/secondlife/viewer/issues/5334
Anastasia Horngold
Just to add some confirmation, this is a very old issue that is well known to us in Firestorm support. I've always assumed it is a system message, not a viewer message (although I could be wrong). It would be helpful if there were a clearer message such as "The object failed to rez because the destination surface could not be calculated. Try rezzing on Linden ground or on a prim."
steph Arnott
It is not a false message, the issue is caused by out-dated rezzer scripts which had no throttle.
Eren Padar
steph Arnott I disagree. Pulling an item from inventory to rez it has nothing to do with scripts, or throttle. The description in the OP states, "Sometimes when rezzing on a mesh object." That indicates manual rezzing from inventory, not script rezzing.
Furious Soup
I mean, I don't think this is gonna be news to anyone, but a more correct failure message would be nice all the same.
AlettaMondragon Resident
I think the source of this problem is that the viewer cannot calculate the mesh surface on top of which it must rez the new object, but maybe it isn't just that but the same thing happens as when you try to rez on water. You point at the water surface to rez the object, but you're at an angle between your camera and the water surface, and get the same error. In fact the target will be on the terrain, ignoring the water, and it will be a different parcel. So if the viewer ignores a mesh object, the target for rezzing might indeed be on a different parcel and the error might be real.
Lisle Rossini
AlettaMondragon Resident I can certainly imagine what you describe happening, however I see the same message on my private region where I own everything.
AlettaMondragon Resident
Lisle Rossini Thank you for mentioning that, I want to do some tests to see how much of my theory is right and how much isn't. They will mark this ticket "needs more info" anyway if we don't provide details.
Eren Padar
Lisle Rossini Agreed Lisle. Same here. Our region is single and isolated.
Eren Padar
AlettaMondragon Resident I do believe what you describe may be the case in some instances. But when I'm in the middle of our sandbox working on a mesh item, and try to rez a prim or object on top of that mesh item, it's not going to another region. At the worst, it should go through the mesh and rez on the ground beneath. And since I'm an Estate Manager with full privileges, I should never receive that particular message. Is definitely a bug.
AlettaMondragon Resident
Eren Padar I know, I was just speculating on the reason behind this bug. For example you cannot drop mesh objects, there must be a reason for that as well, but that's unclear too.
I found this from 2015, more details on this issue:
Eren Padar
AlettaMondragon Resident Thanks Aletta. Yup, that's the same error, reported on Firestorm. : )
AlettaMondragon Resident
Eren Padar Yes I looked there on purpose because I can't search the SL Jira archive on GitHub. It is referenced in the FS Jira bug report, though, so LL can look into it. I started doing tests now (using Firestorm 7.1.13.78266) with different mesh objects of various sizes and shapes, even vehicles on top of vehicles, and all of them rezzed properly and without any error message, so I'm not getting anywhere with this yet. I do get the errors though when I'm in a hurry and can't stop to play with it and see why it's happening.
Eren Padar
AlettaMondragon Resident This is known as "Murphy's Auto Rule":
The bad noise vanishes whenever the mechanic is listening. ;D