The annoying physics mesh issue

[Nutria2016]

This has been a common occurrence. Whenever I create a thin mesh with a gap in it, the physics mesh will change and fill in the hole that avatars need to able to go through. When it's stretched, the physics mesh changes to its intended shape.

Example below. Left is the stretched mesh, and right is the original.

Physics mesh.

Is creating a larger mesh the only solution? How do walls with doorways handle this issue?

 

Edited December 11, 2018 by Nutria2016

[Nutria2016]

Think I figured out the problem. I filled in the faces at the bottom of the physics mesh, and used the Analyze tool. I'm able to go through it now, but oddly enough the viewer still shows the hole covered up. Doesn't matter now I suppose.

 

[Chic Aeon]

4 hours ago, Nutria2016 said:

Think I figured out the problem. I filled in the faces at the bottom of the physics mesh, and used the Analyze tool. I'm able to go through it now, but oddly enough the viewer still shows the hole covered up. Doesn't matter now I suppose.

 

A "bug" in Firestorm which was supposed to be fixed in the last version (I didn't install that one so can't say) so the "view" doesn't match up with the reality. 

Edited December 11, 2018 by Chic Aeon

[Beq Janus]

2 hours ago, Chic Aeon said:

A "bug" in Firestorm which was supposed to be fixed in the last version (I didn't install that one so can't say) so the "view" doesn't match up with the reality. 

It was fixed for one case but broke another. Both are now fixed in the next release. (please test and confirm/deny if you have examples) the latest version can be found by joining the Firestorm preview group.

As for the original issue, that is totally expected behaviour. (long explanation: http://beqsother.blogspot.com/2017/07/a-convexing-problem-fixing-doors.html) the short version of which is any mesh with less than 0.5m in ANY dimension using a user-defined mesh physics (i.e. not an analysed physics) will be treated as convex hull by the server.

Two ways to fix this are to (artificially) pad the bounding box to a minimum 0.5m (the download/streaming will increase as a result) or use analyse (your physics cost will most likely increase), which of thee is best depends entirely on what you are doing.

What is shown in the viewer (SL or FS etc) for physics is "faked" the viewer is not given the physics shape of an object and therefore we work it out and display what we believe is the physics in use on the server based on a set of rules. The logic to display this defined by those rules in the viewer was broken and I fixed it for the general case and missed another case, that 

The new uploader will tell you up front what the actual inworld physics cost of analysed or user mesh will be, which at least takes out the guess-work involved today.

Beq

[Nutria2016]

Thanks for the info. By the way, this is unrelated to the issue and I'm not even sure if you're the right person for this but I got a virus warning from the recent 64 bit beta. Never happened with the previous versions. Just thought you should know.

[Whirly Fizzle]

5 hours ago, Nutria2016 said:

Thanks for the info. By the way, this is unrelated to the issue and I'm not even sure if you're the right person for this but I got a virus warning from the recent 64 bit beta. Never happened with the previous versions. Just thought you should know.

Unfortunately false positives from antivirus are not uncommon, especially with a new release.
Which antivirus are you using?

[Nutria2016]

It's just Windows Defender. Just found it odd that this one time it thinks it's a problem.

[animats]

8 hours ago, Nutria2016 said:

It's just Windows Defender. Just found it odd that this one time it thinks it's a problem.

For me, Windows Defender is complaining only about Vivox, as usual. Vivox is making a connection to an external server and using the microphone, which is something the user ought to know about.

On the physics mesh front, a few notes. I've been building escalator steps for my working escalator. The steps move using keyframe animation, as I've described previously. I've been working to get the land impact down without loss of visual quality. It can be done, but it's a lot of work.

Steps, "high" level of detail. Created in Blender, using an array modifier. Land impact: 2.

This is a moving part which fits into an escalator frame. The sides are hidden when in the frame, so they don't have their own texture. Making this is straightforward.

Steps, all lower levels of detail. 35 triangles. It's also the physics model. For physics purposes, it's a ramp, with additional top and bottom pieces. Three convex hulls; one for the top, one for the bottom, and one for the main center piece. The physics model on this object carries the avatar up by friction as the steps smoothly keyframe up one step length, then jerk back one step instantaneously. The infinitely fast jerk doesn't move the avatar. This trick needs a specific physics model to work, so the custom physics model is essential.

This is tricky to texture. Each level of detail model gets its own UV map. But it doesn't get its own set of UV parameters. Blender lets you set UV parameters - texture repeat, texture angle, etc. - for each model, but SL seems to use only the ones from the high level of detail.  So the UV map has to be stretched instead.

Blender screenshot. Note tiny step texture on right, stretched to 32x the step size because there are 32 steps. (Should be -32; the texture is reversed.)

Entering that scale: cursor in UV pane, A (select all), SY=nnn where nnn is the desired scale factor.

A detailed high level model plus a simple textured low detail model often looks good and has low LI, but it's time consuming to do this.