[BUG-40629] Mesh assets have unusual legacy prim attributes associated with them upon upload.

[sl-service-account]

Steps to Reproduce

This fact has been highlighted in bugs previously but is confirmed absolutely by the fix for https://jira.secondlife.com/browse/BUG-40626

While debugging the above issue, it became clear that while the manifestation is on the viewer (the early LOD decay of certain meshes) the cause is already baked into the object definition when it is streamed from the asset server.

There is no mechanism for this to be uploaded, the entire parent object construct is applied server side upon upload completion and thus this must be a bug or feature of the server processing of Meshes.

Actual Behavior

When a mesh asset is uploaded it becomes the child of a parent object. The parent object contains numerous legacy settings such as the PROFILE and PATH param blocks which in legacy prims define the basic geometrical shape.

For reasons that are impossible to determine from the existing documentation or viewer code, the parent of a mesh is assigned different "shape"definitions seemingly by the count of material faces.It seems likely that these are set intentionally because they are consistently applied. The best "guess" is that the full parameters define a prim of a similar number of faces to that of the mesh or at least that was the intention.

There is no simple way to show this inworld, however there are two ways that the bug can be demonstrated without resorting to debugging the viewer.

1) Find a large permanent Mesh object and then examine the secondlife map tile for that location. You wil typically find a basic geometric shape or the profile of a cut/hollowed cube etc. examples This image shows three different mesh buildings viewed from above inworld and their "map view" https://i.gyazo.com/a98ed11529e37979760a120e8a6630b8.jpg The red highlighted one is represented as a hexagon. The Blue highlighted one as an equalateral triangle and the amber highlighted one as a path cut cube. In no case do they bear the slightest resemblance to the geometry on the ground.

Expected Behavior

It is hard to be certain what the correct action should be. The fact that the server does this with some level of deliberation and logic implies that it was once (and perhaps still) required. The fact that it has some significant visual side effects both in the map, but more importantly in the rendering of the objects suggests that the impact of the parameters was not fully realised at the time (or was considered acceptable).

Other information

I am not really expecting this to be fixed. This is something in the heart of the asset server and given that I have a viewer side fix for the troublesome visual side effects it can be ignored.

The primary reason for raising this is to check that the server encoding of the mesh parameters does not have any significance that could undermine the fix being applied in the viewer.

Having spent a considerable amount of time debugging this issue from the client side it would be great to get a little understanding of why the server does this, even if there is no hope of correcting it.

Links

Related

• [ ] https://github.com/secondlife/jira-archive/issues/14987
• [ ] https://github.com/secondlife/jira-archive/issues/1732

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-40629 | | Summary | Mesh assets have unusual legacy prim attributes associated with them upon upload. | | Type | Bug | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Beq Janus (beq.janus) | | Created at | 2016-10-02T17:50:20Z | | Updated at | 2016-10-20T17:30:11Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2016-10-03T12:13:28.608-0500', "Is there anything you'd like to add?": 'I am not really expecting this to be fixed. This is something in the heart of the asset server and given that I have a viewer side fix for the troublesome visual side effects it can be ignored. \r\n\r\nThe primary reason for raising this is to check that the server encoding of the mesh parameters does not have any significance that could undermine the fix being applied in the viewer.\r\n\r\nHaving spent a considerable amount of time debugging this issue from the client side it would be great to get a little understanding of why the server does this, even if there is no hope of correcting it.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Simulator', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'When a mesh asset is uploaded it becomes the child of a parent object. The parent object contains numerous legacy settings such as the PROFILE and PATH param blocks which in legacy prims define the basic geometrical shape.\r\n\r\nFor reasons that are impossible to determine from the existing documentation or viewer code, the parent of a mesh is assigned different "shape"definitions seemingly by the count of material faces.It seems likely that these are set intentionally because they are consistently applied. The best "guess" is that the full parameters define a prim of a similar number of faces to that of the mesh or at least that was the intention.\r\n\r\nThere is no simple way to show this inworld, however there are two ways that the bug can be demonstrated without resorting to debugging the viewer.\r\n\r\n1) Find a large permanent Mesh object and then examine the secondlife map tile for that location. You wil typically find a basic geometric shape or the profile of a cut/hollowed cube etc.\r\nexamples\r\nThis image shows three different mesh buildings viewed from above inworld and their "map view"\r\nhttps://i.gyazo.com/a98ed11529e37979760a120e8a6630b8.jpg\r\nThe red highlighted one is represented as a hexagon. The Blue highlighted one as an equalateral triangle and the amber highlighted one as a path cut cube.\r\nIn no case do they bear the slightest resemblance to the geometry on the ground. \r\n', 'What were you doing when it happened?': 'This fact has been highlighted in bugs previously but is confirmed absolutely by the fix for https://jira.secondlife.com/browse/BUG-40626\r\n\r\nWhile debugging the above issue, it became clear that while the manifestation is on the viewer (the early LOD decay of certain meshes) the cause is already baked into the object definition when it is streamed from the asset server. \r\n\r\nThere is no mechanism for this to be uploaded, the entire parent object construct is applied server side upon upload completion and thus this must be a bug or feature of the server processing of Meshes.', 'What were you expecting to happen instead?': 'It is hard to be certain what the correct action should be. The fact that the server does this with some level of deliberation and logic implies that it was once (and perhaps still) required. The fact that it has some significant visual side effects both in the map, but more importantly in the rendering of the objects suggests that the impact of the parameters was not fully realised at the time (or was considered acceptable).\r\n', 'Where': 'http://maps.secondlife.com/secondlife/New%20Babbage/146/73/103\r\nThis is the location of the example.', } ```

[sl-service-account]

Dan Linden commented at 2016-10-03T17:13:29Z

Is the problem you are reporting that the true shape of mesh objects do not appear on the map?

[sl-service-account]

ChinRey commented at 2016-10-03T23:02:03Z, updated at 2016-10-03T23:06:58Z

The issue with misshaped mesh on the map is annoying enough but there is a far more serious side to this. Mesh assets also inherit LoD settings from different legacy prim shapes with very different LoD. This is especially critical for 3 and 4 face meshes since they are based on cylinders and cylinders have much lower LoD than other prim shapes (see BUG-11561 and BUG-6287).

I don't know the server code of course but the map issue should be fairly easy to solve simply by ceating a small independent program creating the Object tiles by scanning the actual content of the sim but the LoD issue is more difficult to handle. Beq Janus has made a viewer patch that fixes the issue by overriding the incorrect data from the assets server. It's not an ideal solution of course but if fixing the root of the problem is too difficult, I strongly urge you to implement her workaround patch.

[sl-service-account]

Whirly Fizzle commented at 2016-10-04T00:04:47Z

@Chinrey There is a fix pending for BUG-11561 and BUG-6287 at STORM-2138.

[sl-service-account]

Beq Janus commented at 2016-10-04T15:04:24Z

@Dan Linden The map visualisation is simply a side effect of the problem. The problem is that Meshes are being assigned legacy prim attributes and that these have at least two identified impacts on the SL experience. 1) the map shapes, no big deal in the scheme of things though the "random" shapes are puzzling to people as opposed to all meshes being, say, a square on the map 2) breaking the LOD change calculation on the viewer because the calcLOD routine uses legacy prim parameters which have no relation whatsoever to the mesh geometry.

As noted. I have a PATCH pending submission that will fix the viewer behaviour, but the mystery of why all meshes are assigned legacy profiles is at the heart of this. We would not need the patch if the mesh uploader (which is presumably where the changes are applied) was altered to apply sensible defaults. It may be that there is a good reason why these are set as they are; if so it would be good to have these documented and shared so that I can ensure that my patch does not have unexpected side effects.

[sl-service-account]

Beq Janus commented at 2016-10-04T15:05:40Z

Comment added in response to the question from Dan Linden

[sl-service-account]

Beq Janus commented at 2016-10-08T00:30:22Z

The initial fix for STORM-2138 has been pulled due to side effects. This appears to be because the parameters I am overriding are in fact used deep in the render pipeline to account for the texturable faces. This is consistent with the "map view" bug.I am testing an alternate fix that ought to have no side effects but the fact that the change had significant side effects is further reason why we should have some documentation on the premise of these parameters. As soon as I have finished the alternate fix I will dig deeper into the cause of the rollback and if I am correct I believe that I should be able to provide at least an external document on what is happening. I will update here as and when I have useful info.

[sl-service-account]

Grumpity Linden commented at 2016-10-18T19:01:09Z, updated at 2016-10-20T17:29:56Z

Importing based on DaveP's feedback.

DaveP says:

There are a couple of issues there:

Meshes use prim parameters to create a prim that has the same number of faces as the incoming mesh so the viewer and server can allocate an appropriate number of texture entries for that mesh before the mesh asset is fetched from the asset server. The map rendering bug has always been there for all meshes – the map renderer uses a completely different renderer, and that renderer doesn't know about meshes.

The LoD scale bias for cylinders ignores the z-axis because, in the case of actual cylinders stretched along the z-axis, it saves a ton of triangles with no visual degradation (silhouette edges are preserved). At any rate, it would be appropriate for all meshes to have the same LoD scale bias as spheres.