[BUG-225482] Mesh Physic changes on resizing

[sl-service-account]

What just happened?

Changing the size of a Mesh may change its physical behaviour.

What were you doing when it happened?

Steps to reproduce:

TEST 1:

1. upload the "passage" mesh modell with the settings:

• All Lods: use LoD above

• Physics: step1: level of detail: High

• Physics: step2 + 3: Don't click anything
  2) rezz the object and switch the physical shape to prim. Activate the physics view: Developer->Render Metadata->Physics Shapes
  3) walk through the passage. All seems to be fine.
  4) Decrease the x-size to 0.49m.

  Actual Behavior:
  You are NOT ABLE to walk through the passage.
  LL Viewer: the physics view is unchanged and does NOT reflect the behaviour.
  Firestorm: the physics view changed and reflects the behaviour.

  TEST 2:

  1. as above but in step 2 of the physics tab use the "analyse" button.
  2. as above
  3. as above
  4. as above

  Actual Behavior: You are still ABLE to walk through the passage.
  LL Viewer: the physics view is unchanged and does reflect the behaviour.
  Firestorm: the physics view changed and does NOT reflect the behaviour.

  What were you expecting to happen instead?

  Changing the size shouldn't have any impact to the physic, neither visible (physics view) nor functional.

  Other information

Attachments

• passage.dae 2018-09-17 06:56:36

Links

Duplicates

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

Original Jira Fields

Field	Value
Issue	BUG-225482
Summary	Mesh Physic changes on resizing
Type	Bug
Priority	Unset
Status	Needs More Info
Resolution	Unresolved
Reporter	slmember1 (slmember1)
Created at	2018-09-17T11:00:31Z
Updated at	2018-09-25T15:05:38Z

{
  'Build Id': 'unset',
  'Business Unit': ['Platform'],
  'Date of First Response': '2018-09-17T09:46:40.217-0500',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'Changing the size of a Mesh may change its physical behaviour.',
  'What were you doing when it happened?': 'Steps to reproduce:\r\n\r\nTEST 1:\r\n1) upload the "passage" mesh modell with the settings:\r\n- All Lods: use LoD above\r\n- Physics: step1: level of detail: High\r\n- Physics: step2 + 3: Don\'t click anything\r\n2) rezz the object and switch the physical shape to prim. Activate the physics view: Developer->Render Metadata->Physics Shapes\r\n3) walk through the passage. All seems to be fine.\r\n4) Decrease the x-size to 0.49m.\r\n\r\nActual Behavior:\r\nYou are NOT ABLE to walk through the passage.\r\nLL Viewer: the physics view is unchanged and does NOT reflect the behaviour.\r\nFirestorm: the physics view changed and reflects the behaviour.\r\n\r\n\r\nTEST 2:\r\n1) as above but in step 2 of the physics tab use the "analyse" button.\r\n2) as above\r\n3) as above\r\n4) as above\r\n\r\nActual Behavior: You are still ABLE to walk through the passage.\r\nLL Viewer: the physics view is unchanged and does reflect the behaviour.\r\nFirestorm: the physics view changed and does NOT reflect the behaviour.\r\n',
  'What were you expecting to happen instead?': "Changing the size shouldn't have any impact to the physic, neither visible (physics view) nor functional.",
}

[sl-service-account]

Whirly Fizzle commented at 2018-09-17T14:46:40Z

This behaviour is explained really well in these blog posts by Beq Janus.

• http://beqsother.blogspot.com/2016/07/when-is-door-not-door-and-other-things.html
• http://beqsother.blogspot.com/2017/07/a-convexing-problem-fixing-doors.html
• http://beqsother.blogspot.com/2017/10/blue-sky-thinking-physics-view-explained.html

[sl-service-account]

slmember1 commented at 2018-09-17T15:21:54Z

Thank you, Whirly.

after reading the blog post I noticed that this bug is a duplicate of BUG-134006.
(Please notice that the Firestorm viewer shows a different physical shape than the LL Viewer, but i guess this should be placed inside the firestorm jira)

[sl-service-account]

Beq Janus commented at 2018-09-17T15:39:08Z, updated at 2018-09-17T15:40:18Z

The response here is in two parts:

1. The effective behaviour itself is expected, as the blogs whirly kindly listed, explain; as you reduce the scale the physics cost ramps up and the "convexification cap" is intended as a safety valve. 

2. The visual behaviour is a viewer bug that I fixed in Firestorm and raised as a bug here https://jira.secondlife.com/browse/BUG-134006. Where the LL viewer displays a physics shape that does not correspond with that imposed by the server is dealt with in the "convexing problem post". Even though I fixed it in Firestorm so that the viewer display is correct/consistent with the server (and thus different to the LL viewer), it is still my belief that the 0.5m limit imposed on meshes is too strict and I would prefer the server side to be re-evaluated to see  whether it is possible to allow thinner mesh walls and reduce the number of times this problem impacts users. Let's face it few people live in houses where the thinnest doorway/wall is 500mm deep.

Workaround

If it is important for you to have a consistent physics shape irrespective of the inworld scaling then you must use the "analyse" function to create a hull based physics shape. Hull-based physics does not change relative to the scale, ensuring a fixed physics cost and behaviour, it does however often carry a slightly higher LI cost than a minimal mesh triangle physics shape.

 

[sl-service-account]

slmember1 commented at 2018-09-17T15:58:40Z, updated at 2018-09-17T16:01:21Z

May I ask in which firestorm version the inconcistent view is fixed? Is there an jira entry in the firestorm jira?
I ask because in the current FS version (Firestorm 5.1.7 (55786) Jul 13 2018 20:00:04 (64bit)) the physical shape view is different to the LL Viewer but still inconcistent (see TEST 2).

 

BTW: I would also prefer the server side to be re-evaluated.

[sl-service-account]

Beq Janus commented at 2018-09-17T20:09:21Z

That's interesting. I can repro that, thank you. 

So we have two scenarios, for test #1 LL behaviour is wrong, test #2 FS behaviour is wrong 

I will take a close look and see if I can work out what is happening on FS, it seems likely that my fix for non-analysed mesh visuals has messed up the the analysed. We shall see.

 

[sl-service-account]

Kyle Linden commented at 2018-09-17T20:20:04Z

Hi Slmember,

This report looks like it has Beq helping you diagnose it. I'm eager to see what Beq discovers.

Thanks!

[sl-service-account]

Beq Janus commented at 2018-09-17T21:02:12Z

Ugh, OK I see why...

In fixing case #1 it breaks case #2 which happens to work by luck on LL as it drops through to the default case.

The problem is that the function that identifies the physics shape type, does not have access to the underlying physics details, it is passed the scale of the object and the user selected physics type. 

Looks like I need to do a little more digging to get this to work in all cases.

[sl-service-account]

Kyle Linden commented at 2018-09-24T15:40:17Z

Thanks for the update Beq. Leaving this issue open so you may continue to comment.