Skip to content
This repository has been archived by the owner on Feb 28, 2024. It is now read-only.

[BUG-134006] Viewer code is not aligned to server code when calculating physics shape for thin objects. #2079

Closed
1 task
sl-service-account opened this issue Jul 13, 2017 · 0 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Jul 13, 2017

Steps to Reproduce

resizing a mesh to one dimension <0.5m

Actual Behavior

This bug has been present a long time but I finally realised why.
In order to stop the physics cost of non-analysed (triangle based) physics going asymptotic as it scales down the physics shape gets forced to a single box hull under certain conditions.
The conditions for this are enforced differently on the server than on the viewer.

With a Mesh, if any single dimension is reduced to less than the threshold (0.5m) then the server will force it to be a default box hull physics. This causes many many problems for the uninitiated builder and despite it being mentioned widely people still come up against it time and again.

Those who are a little more experienced will use the Develop->render metadata->physics shapes option.
They will unfortunately then be led to believe that their physics shape is absolutely fine and often waste Linden dollars uploading different ways until they stumble upon a workaround.

The linked gyazo video demonstrates the problem.
https://gyazo.com/454eb1dc6c304cceb7ae97c2946b7294

A mesh doorway is shown as working correctly when it is 1m deep. (it is approx 5x3x1)
making it 0.01 deep does not change the displayed physics shape, it still appears that the door is open.
All attempts to pass through the doorway will fail, this is because the server has relegated it to a box hull.

Towards the end of the video clip I deliberately force the X dimension to <0.25, this qualifies for the "any two dimensions less than 0.25m" constraint and though it is very hard to see, you can just about make out that the doorway is now blocked (blue). This is because the viewer code for box hull rendering is now triggered correctly.

Expected Behavior

There are two possible solutions. Number 2 is actually preferred, though I offer one potential patch as a solution to option 1.

  1. align the viewer to the server.
    This is simply a case of making sure that the logic used by the viewer (llphysicsshapebuilderutil.cpp)
    void LLPhysicsShapeBuilderUtil::determinePhysicsShape(...)
    corresponds to that used on the server.

  2. Align the server to the viewer.
    This would actually save a lot of headaches for builders. The current limitation means that any house with walls less than 0.5m (who wants a wall that thick?) must use hull based physics (more expensive) or artificially bad the bounding box with hidden geometry (hacky and hard to explain to new builders).

If the server could be changed to force box physics only when two dimensions go below 0.25 for Mesh as well as for prims then that problem could be consigned to history.

Other information

It will be argued that by moving to a constraint of two small dimensions before the physics cap is applied leaves the possibility of extreme LI from tall thin meshes. This is true, however, the risk exists today using prims alone and is easily demonstrated (for an example 9000LI "prim" see http://beqsother.blogspot.co.uk/2016/07/when-is-door-not-door-and-other-things.html).

Eliminating one source of confusion and frustration for the uninitiated builder would seem to outweigh risks.

Links

Duplicates

Original Jira Fields
Field Value
Issue BUG-134006
Summary Viewer code is not aligned to server code when calculating physics shape for thin objects.
Type Bug
Priority Unset
Status Closed
Resolution Accepted
Reporter Beq Janus (beq.janus)
Created at 2017-07-13T23:47:24Z
Updated at 2022-10-20T18:09:57Z
{
  'Business Unit': ['Platform'],
  "Is there anything you'd like to add?": 'It will be argued that by moving to a constraint of two small dimensions before the physics cap is applied leaves the possibility of extreme LI from tall thin meshes. This is true, however, the risk exists today using prims alone and is easily demonstrated (for an example 9000LI "prim" see http://beqsother.blogspot.co.uk/2016/07/when-is-door-not-door-and-other-things.html).\r\n\r\nEliminating one source of confusion and frustration for the uninitiated builder would seem to outweigh risks.\r\n',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'This bug has been present a long time but I finally realised why.\r\nIn order to stop the physics cost of non-analysed (triangle based) physics going asymptotic as it scales down the physics shape gets forced to a single box hull under certain conditions.\r\nThe conditions for this are enforced differently on the server than on the viewer.\r\n\r\nWith a Mesh, if any single dimension is reduced to less than the threshold (0.5m) then the server will force it to be a default box hull physics. This causes many many problems for the uninitiated builder and despite it being mentioned widely people still come up against it time and again. \r\n\r\nThose who are a little more experienced will use the Develop->render metadata->physics shapes option.\r\nThey will unfortunately then be led to believe that their physics shape is absolutely fine and often waste Linden dollars uploading different ways until they stumble upon a workaround. \r\n\r\nThe linked gyazo video demonstrates the problem. \r\nhttps://gyazo.com/454eb1dc6c304cceb7ae97c2946b7294\r\n\r\nA mesh doorway is shown as working correctly when it is 1m deep. (it is approx 5x3x1)\r\nmaking it 0.01 deep does not change the displayed physics shape, it still appears that the door is open.\r\nAll attempts to pass through the doorway will fail, this is because the server has relegated it to a box hull.\r\n\r\nTowards the end of the video clip I deliberately force the X dimension to <0.25, this qualifies for the "any two dimensions less than 0.25m" constraint and though it is very hard to see, you can just about make out that the doorway is now blocked (blue). This is because the viewer code for box hull rendering is now triggered correctly.\r\n\r\n\r\n\r\n',
  'What were you doing when it happened?': 'resizing a mesh to one dimension <0.5m',
  'What were you expecting to happen instead?': 'There are two possible solutions. Number 2 is actually preferred, though I offer one potential patch as a solution to option 1.\r\n\r\n1) align the viewer to the server. \r\nThis is simply a case of making sure that the logic used by the viewer (llphysicsshapebuilderutil.cpp) \r\nvoid LLPhysicsShapeBuilderUtil::determinePhysicsShape(...)\r\ncorresponds to that used on the server. \r\n\r\n2) Align the server to the viewer.\r\nThis would actually save a lot of headaches for builders. The current limitation means that any house with walls less than 0.5m (who wants a wall that thick?) must use hull based physics (more expensive) or artificially bad the bounding box with hidden geometry (hacky and hard to explain to new builders).\r\n\r\nIf the server could be changed to force box physics only when two dimensions go below 0.25 for Mesh as well as for prims then that problem could be consigned to history.\r\n',
  'Where': '\r\nYou are at 12.2, 129.3, 23.0 in Mesh Sandbox 1 located at sim10003.aditi.lindenlab.com (216.82.48.81:13002)\r\nSLURL: secondlife://Aditi/secondlife/Mesh%20Sandbox%201/12/129/23\r\n(global coordinates 205,324.0, 178,817.0, 23.0)\r\nDRTSIM-354 17.07.06.327491',
}
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant