sl-service-account
commented
8 years ago polysail commented at 2016-08-01T23:41:16Z, updated at 2016-08-01T23:59:54Z
Affixing a little scale swapper script to this ticket.
Adjust the "switch" variable at the top to TRUE or FALSE to flip between obscenely huge and microscropic scale.
Sent a mesh to Kyle Linden with this script in it as well.
Steps to Reproduce
Fiddling with Mesh uploads and trying to pin down why some meshes with absurd polycounts ( 1.8-3.7 million polys ) had fantastically low ARC numbers, while other, beautifully efficient ones had (comparatively) high ARC Costs.
Actual Behavior
Rigged mesh items in are displayed and LOD swap based on the ( to the best of my understanding .. at least for now .. ) Avatar Bounding Boxes. As is referenced here : BUG-11627
However, the ARC Calculation for rigged meshes are still done using the mesh data as if the object was unrigged and worn. Meaning a rigged mesh attachment, let's say a mesh head for example, visually will always be the same size and location ( due to it's rigged nature). However, the numeric values for the mesh ARC cost and Volume data ( which have no actual bearing on it's LOD based visibility or LOD shifting ) are still based on the meshs actual "Scale" parameter. So, even though the mesh does not visually change with scale, numerically the ARC value will be substantially higher (or lower) because the numeric volume ( and thus calculated display distance ) of the mesh is calculated from a completely non-functional value.
To illustrate this, I used a 1.8 million poly object made out of 256 smaller meshes ( incredibly heavy by any standards, but I'm using that number because .. well that's what the polycount is on an average popular mesh head.) If I make each sub-mesh 0.01m x 0.01m x 0.01m scale. The calculated ARC Cost for the entire entity is roughly 1,800. So those 1.8 million polygons will be fully rendered based on the Avatar Bounding box size for a good 13 meters, for the ARC cost of 1800.
Now, via script I changed the size of each sub-mesh from 0.01 m cubes to 64x64x64 meter cubes. Take the item off, and re-attach it to re-calculate the ARC Cost, and it is now ( surprise surprise ) 11,669,580. Which is actually drastically higher than it should be.
When worn as an attachment, both of these meshes are visually identical in scale and LOD changes. Just one is 64x64x64 meters when rezzed to ground, the other is a tiny dot.
Expected Behavior
I was hoping that the ARC Calculation for rigged attachments would use the avatar bounding box for the math (or whatever altered calculation that BUG-11627 will instate), rather than the "mesh asset volume" for the calculation.
Other information
Mildly non-critical issue, but I think normalizing this before Firestorm releases it's Jelly Baby viewer update may help fight some of the later backlash from people getting told (incorrectly) that some items are GOOD, when in reality they're REALLY REALLY REALLY BAD. And conversely ~ have some really good items, slapped with arbitrarily bad ratings.
Attachments
Links
Duplicates
Related
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-37577 | | Summary | ARC Calculation doesn't reflect actual render cost due to ARC Calculation measuring unrigged Bounding Boxes on Rigged Items. | | Type | Bug | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Created at | 2016-07-29T05:06:30Z | | Updated at | 2021-04-19T17:43:50Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2016-08-01T19:47:18.669-0500', "Is there anything you'd like to add?": "Mildly non-critical issue, but I think normalizing this before Firestorm releases it's Jelly Baby viewer update may help fight some of the later backlash from people getting told (incorrectly )that some items are GOOD, when in reality they're REALLY REALLY REALLY BAD.", 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'Rigged mesh items in are displayed and LOD swap based on the ( to the best of my understanding .. at least for now .. ) Avatar Bounding Boxes. As is referenced here : BUG-11627\r\n\r\nHowever, the ARC Calculation for rigged meshes are still done using the mesh data as if the object was unrigged and worn. Meaning a rigged mesh attachment, let\'s say a mesh head for example, visually will always be the same size and location ( due to it\'s rigging data ). However the numeric values for the mesh ( which have no actual bearing on it\'s LOD based visibility or LOD shifting ) are still based on the meshs actual "Scale" parameter, even though it\'s not visually different, numerically the ARC value will be substantially higher because the "visibility" of the mesh is calculated as being much higher.\r\n\r\nTo illustrate this, I used a 1.8 million poly object made out of 256 smaller meshes ( incredibly heavy by any standards, but I\'m using that number because .. well that\'s what the polycount is on an average popular mesh head.) If I make each sub-mesh 0.01m x 0.01m x 0.01m scale. The calculated ARC Cost for the entire entity is roughly 1,800. So those 1.8 million polygons will be fully rendered based on the Avatar Bounding box size for a good 13 meters, for the ARC cost of 1800.\r\n\r\nNow, via script I changed the size of each sub-mesh from 0.01 m cubes to 64x64x64 meter cubes. Take the item off, and re-attach it to re-calculate the ARC Cost, and it is now ( surprise surprise ) 11,669,580. Which is actually drastically higher than it should be.\r\n\r\nBoth of these meshes are visually identical and scale LOD changes, identically. Just one is 64x64x64 meters when rezzed to ground, and the other is a tiny dot.', 'What were you doing when it happened?': 'Fiddling with Mesh ARC Costs.', 'What were you expecting to happen instead?': 'I was hoping that the ARC Calculation for rigged attachments would use the avatar bounding box for the math, rather than the "mesh asset volume." for the calculation.', } ```