Open sl-service-account opened 6 years ago
Beq Janus commented at 2018-09-11T18:25:50Z
Added cube_phys.dae
The tiny triangles that comprise this mesh do not work well with the obnoxious uploader. When trying to upload the example mesh go to the physics tab and specify 'From file...' for the physics model, then browse to where you have saved the cube_phys.dae and select it. Then just check the include weights on the final tab and you should be clear to upload.
Whirly Fizzle commented at 2018-09-11T18:37:26Z
Note that you can only upload the attached dae with rigging on a LL viewer that has Animesh support because legacy LL viewers do not allow attachment point rigging. However this bug is not specific to Animesh. This bug reproduces when uploading the repro dae on legacy Firestorm (no Animesh support) which has allowed attach point rigging for a long time.
Beq Janus commented at 2018-09-11T18:41:34Z
Worth noting also, that this is not Mesh specific in any way. Two basic cubes overlapping, one yellow, one blue. The blue one has glow, the yellow does not.
(object can be grabbed as b2bedda6-deb8-9aa6-d488-079ac2ea9ba3)
Kyle Linden commented at 2018-09-13T15:47:19Z
Confirmed its an easy repro with just 2 boxes. Repro's prior to Love Me Render 515811 https://prnt.sc/ku0wko
What just happened?
When the vertices of two meshes overlap, if one mesh is set to have some glow, then the other mesh will also exhibit glow
What were you doing when it happened?
While testing rigging in the Animesh viewer I overlaid two identical meshes (one uploaded using the LL viewer the other using FS to confirm that they were equivalent. Setting one to red and one to green to spot any differences, I could not see any issues, I set the green instance which was being masked by the red to have some glow and immediately the red one glowed.
This second video shows two meshes (rezzed inworld with no animesh setting applied and thus static). For simplicity they are a linkset but they can be unlinked without affecting the results.
one mesh is moved horizontally and stops glowing as soon as it is no longer sharing the same space is its peer. It can also be shown that overlapping vertices do not need to be the same vertices, the mesh is slid horizontally until one node overlaps another unrelated node and they inherit glow. Finally, due to the nature of the renderer the mesh is finally returned to the original overlapping position where the Red (non-glow) mesh is now shown as the dominant glowing effect.
What were you expecting to happen instead?
The two meshes ought to behave fully independently. The second mesh has no shine or other attribute that might explain the inherited glow
Other information
It seems likely that this is picked up from the shaders, two vertices are sharing the same world coordinates and thus the same fragments so it seems plausible that the shader is unable to distinguish the two.
The meshes tested happen to both be rigged and to have been uploaded using the animesh viewers, however the problem manifests on all current viewers (I have tested with and without ALM the effect is identical in both)
The attached Collada file is the mesh being used. It is an old collada previously used for Jira's related to rigging to attachment points. I have no reason to beleive that the mesh itself has any special properties
While it is easiest to test with two identical worn meshes, simple rezzing two meshes statically inworld and ensuring that they have the same location is enough
Attachments
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-225437 | | Summary | Glow is incorrectly applied to overlapping vertices | | Type | Bug | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Beq Janus (beq.janus) | | Created at | 2018-09-11T11:04:26Z | | Updated at | 2018-09-14T15:55:02Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2018-09-11T13:37:26.173-0500', "Is there anything you'd like to add?": "It seems likely that this is picked up from the shaders, two vertices are sharing the same world coordinates and thus the same fragments so it seems plausible that the shader is unable to distinguish the two.\r\n\r\nThe meshes tested happen to both be rigged and to have been uploaded using the animesh viewers, however the problem manifests on all current viewers (I have tested with and without ALM the effect is identical in both) \r\n\r\nThe attached Collada file is the mesh being used. It is an old collada previously used for Jira's related to rigging to attachment points. I have no reason to beleive that the mesh itself has any special properties\r\n\r\nWhile it is easiest to test with two identical worn meshes, simple rezzing two meshes statically inworld and ensuring that they have the same location is enough\r\n\r\n", 'Original Reporter': 'Beq Janus (beq.janus)', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'When the vertices of two meshes overlap, if one mesh is set to have some glow, then the other mesh will also exhibit glow ', 'What were you doing when it happened?': 'While testing rigging in the Animesh viewer I overlaid two identical meshes (one uploaded using the LL viewer the other using FS to confirm that they were equivalent. Setting one to red and one to green to spot any differences, I could not see any issues, I set the green instance which was being masked by the red to have some glow and immediately the red one glowed. \r\n!https://i.gyazo.com/00bf2c3288eba2b90188e9bd25615d17.gif!\r\n\r\nThis second video shows two meshes (rezzed inworld with no animesh setting applied and thus static). For simplicity they are a linkset but they can be unlinked without affecting the results. \r\n\r\none mesh is moved horizontally and stops glowing as soon as it is no longer sharing the same space is its peer. It can also be shown that overlapping vertices do not need to be the same vertices, the mesh is slid horizontally until one node overlaps another unrelated node and they inherit glow.\r\nFinally, due to the nature of the renderer the mesh is finally returned to the original overlapping position where the Red (non-glow) mesh is now shown as the dominant glowing effect.\r\n!https://i.gyazo.com/edf84d3ea47f6e7d4feaff1630938df0.gif!', 'What were you expecting to happen instead?': 'The two meshes ought to behave fully independently. The second mesh has no shine or other attribute that might explain the inherited glow', 'Where': 'tested on Aditi animesh3', } ```