Helium Loon 24 Posted January 21, 2012 Wearing a mesh item with 100% transparency (to hide it at times) results in the hidden mesh acting like an invisiprim, causing all non-opaque prims and meshes behind it to effectively dissappear.... Is this a known issue? Or expected behavior (I hope not!) I searched through the JIRA's a bit, but couldn't find anything that matched. Quote Share this post Link to post Share on other sites
hibit Spad 19 Posted January 22, 2012 I am going to go out on a limb here but, mesh is just a fancy schmancy prim. so if you set the prim to 100% transparent doesnt it make sense that it would act liek an invisiprim? Now if you wre to set the material (texture) to be nothing but alpha layer then wouldn't it have the desired behaviour? Just guessing here but this makes sense to me. Quote Share this post Link to post Share on other sites
Helium Loon 24 Posted January 22, 2012 No. Take a normal prim, set it to 100% transparent. Take another prim, make it 50% transparent. Put the first in front of part of the second. You'll see right though the 100%, and see the 50% just fine. Now, take a mesh, set it to 100% transparent, and move it in front of the 50% transparent prim. It will completely 'cut away' the 50% transparent prim as if it weren't there. Those areas not viewed 'through' the 100% transparent mesh will look normal (i.e., a 50% transparent prim) but the part viewed through it will simply vanish. That's invisiprim behavior......invisiprims were a special texture, applied to regular prims, to 'cut away' the avatar mesh and hide it (since we didn't have alpha layers back then.) They caused a lot of visual problems when they were used too much, or made larger than needed. Seeing this behavior on a mesh set to 100% transparent seems both odd and unintended. Quote Share this post Link to post Share on other sites
Chosen Few 324 Posted January 22, 2012 Helium Loon wrote: Now, take a mesh, set it to 100% transparent, and move it in front of the 50% transparent prim. It will completely 'cut away' the 50% transparent prim as if it weren't there. Those areas not viewed 'through' the 100% transparent mesh will look normal (i.e., a 50% transparent prim) but the part viewed through it will simply vanish. I'm not able to reproduce your results, Helium. If I set a mesh 100% transparent, everything behind it is visible, whether the other objects are opaque, partially transparent, translucent, or any combination thereof. I've tried with and without deferred rendering enabled, and gotten the same results with both. Graphics driver problem, maybe? Helium Loon wrote: since we didn't have alpha layers back then And we still don't, since there's no such thing as an "alpha layer". Masks are not layers. Channels are not layers. Quote Share this post Link to post Share on other sites
Chosen Few 324 Posted January 22, 2012 hibit Spad wrote: I am going to go out on a limb here but, mesh is just a fancy schmancy prim. More accurately, a prim is a very simplistic mesh. Hence the name, "primitive". hibit Spad wrote: if you set the prim to 100% transparent doesnt it make sense that it would act liek an invisiprim? Sounds like you're unfamiliar with the term "invisiprim". It doesn't just mean a prim that is invisible. It's a prim that turns other objects invisible. Invisiprims were the result of a bug in the old renderer in SL. A very specific texture, which was borked in a very specific way, when applied to any surface in SL would end up causing a reversal in the draw order for any 32-bit textured surfaces placed behind it, effectively turning those surfaces invisible. This bug turned out to be useful, so it was deliberately left unfixed for many years. Nowadays, it's no longer of much use, as it is incompatible with the current deferred rendering engine. Before the advent of alpha masks for avatar outfits, it was common practice to use invispirms to hide body parts. It was very common in shoes, for example, where it's often necessary to hide part or all of the avatar's foot. hibit Spad wrote: Now if you wre to set the material (texture) to be nothing but alpha layer then wouldn't it have the desired behaviour? Not possible, since, once again, there's no such thing as an "alpha layer". It's an alpha CHANNEL. Layers and channels are entirely different things. This forum is the only place in the known universe where people insist on using the two words interchangeably. It's nonsensical, and it makes things very difficult for newbies trying to learn graphics concepts for the first time. Please, everyone, use correct terminology at all times, lest your contributions here become detrimental, rather than helpful. Quote Share this post Link to post Share on other sites
Drongle McMahon 589 Posted January 22, 2012 Like Chosen, I was unable to replicate this effect. That was with LL beta viewer. What viewer/version are you using? Does the effect happen with others? Quote Share this post Link to post Share on other sites
Helium Loon 24 Posted January 23, 2012 *laughs* Sorry, Chosen.....I know that particular terminology is incorrect in reference to 2D graphics and 3D meshes.....I was referring (as I think you know) to the Alpha Masks. But you are correct.....in this forum, considering how layer, channel, and mask are all applicable, I should be more careful to refer to the right one. Quote Share this post Link to post Share on other sites
Helium Loon 24 Posted January 23, 2012 That is very possible. I had to back up to a pretty old driver to avoid a nasty bug on this older machine......OpenGL kept crashing with the newer drivers at the time. I'll update again and see if it's improved any......the card is a 7950 GTKO, so while performance isn't bad, it had some issues with the newer drivers. If that doesn't help, I may have to upgrade my card......if I can afford to. (my other comp has a 560 GT Ti......and runs much more current drivers. I'll see if it happens on that machine too, and will report back here. Quote Share this post Link to post Share on other sites
Helium Loon 24 Posted January 23, 2012 Okay. I updated my drivers.....even went up to the current beta geforce drivers (290.53) I'm still seeing the issue in firestorm-release. Checked my other machine (with the 560GT Ti), same thing. I should probably note something. The mesh with transparency that is demonstrating the issue is an rigged avatar attachment, and has different materials (some of which are transparent, some aren't) and that's what's creating the issue. The mesh has three 'layers' that are turned on and off via script by changing the tranparency of two of the layers (either both 100% transparent, or one or the other 100% transparent.) I'm including a pic to show it: (The red object in front of the mesh figure is actually a spherical red glass xmas ornament.....) I'll have to try the current LL viewer to see if it also happens there, or if it's just Firestorm. Quote Share this post Link to post Share on other sites
Helium Loon 24 Posted January 23, 2012 Just verified in-world with others who are using other viewers (one of which was on a new dev build (Second Life 3.2.8 (248008)), so the mesh render code should be up-to-date) and they all saw the issue. While this is a rather specialized case (mesh with mulitple materials, some faces set with transparency) it isn't THAT unusal......I'm thinking this is buggy behavior. It also masked-out hovertexts, even the name/displayname/viewer blocks, water, and anything with a non-zero transparency setting. Quote Share this post Link to post Share on other sites
hibit Spad 19 Posted January 23, 2012 Chosen Few wrote: hibit Spad wrote: I am going to go out on a limb here but, mesh is just a fancy schmancy prim. More accurately, a prim is a very simplistic mesh. Hence the name, "primitive". hibit Spad wrote: if you set the prim to 100% transparent doesnt it make sense that it would act liek an invisiprim? Sounds like you're unfamiliar with the term "invisiprim". It doesn't just mean a prim that is invisible. It's a prim that turns other objects invisible. Invisiprims were the result of a bug in the old renderer in SL. A very specific texture, which was borked in a very specific way, when applied to any surface in SL would end up causing a reversal in the draw order for any 32-bit textured surfaces placed behind it, effectively turning those surfaces invisible. This bug turned out to be useful, so it was deliberately left unfixed for many years. Nowadays, it's no longer of much use, as it is incompatible with the current deferred rendering engine. Before the advent of alpha masks for avatar outfits, it was common practice to use invispirms to hide body parts. It was very common in shoes, for example, where it's often necessary to hide part or all of the avatar's foot.Guess I shouldn't have crawled out onto that limb. Not possible, since, once again, there's no such thing as an "alpha layer". It's an alpha CHANNEL. Layers and channels are entirely different things. This forum is the only place in the known universe where people insist on using the two words interchangeably. It's nonsensical, and it makes things very difficult for newbies trying to learn graphics concepts for the first time. Please, everyone, use correct terminology at all times, lest your contributions here become detrimental, rather than helpful. Sorry, I keep thinking about how in Photoshop you make a new layer and then put your alpha mask on it. Thank you for correcting me btw. One day I will learn the old wisdom about keeping silent when when you don't know. Quote Share this post Link to post Share on other sites
Siddean Munro 28 Posted January 26, 2012 It's not a problem with rezzed mesh, it's a problem with worn skinned mesh. I logged it in the Jira here which Runitai helpfully closed under the reason duplicate, tho I can't see how the jira it's supposedly a duplicate of is in any way related. Anyway, you're not going mad, it's a real problem and plenty of people are experiencing it. https://jira.secondlife.com/browse/SH-2836 Besides, the duplicate says its resolved. I'll check today and if this is not resolved, I'll reopen that jira :-/ Quote Share this post Link to post Share on other sites
Charlar Linden 25 Posted January 26, 2012 Siddean, I think Runitai may have marked it dup because the core graphics problem was the same - but I'm not sure to be honest. I'll try to check on this and the related items, but please do check the latest shining dev build and let me know Charlar Quote Share this post Link to post Share on other sites
Siddean Munro 28 Posted January 26, 2012 Thanks Charlar, I'll check Quote Share this post Link to post Share on other sites
Charlar Linden 25 Posted January 26, 2012 Are you able to get viwer-development-shining-fixes? I confirmed that both bugs are from the same core issue, and that's where the fix is. Charlar Quote Share this post Link to post Share on other sites
Helium Loon 24 Posted January 27, 2012 Charlar, I tried to download the viewer-development-shining-fixes build to see if the issue persists in it.....but the last good build (284404) under cygwin gets an access denied XML page for me. But I can download the mac and linux clients for that build without problem. Current bulid failed for cygwin, so can't try to DL that one. Unfortunately, I'm a windows user, so the mac & linux builds won't help. Quote Share this post Link to post Share on other sites
Charlar Linden 25 Posted January 27, 2012 I think that build may have failed but not in a way that the system recognized; I noticed that the newest (248445) reports failed for windows. Obviously that happens sometimes with dev builds, but I don't know when today we'd have it fixed. I think the fix should still be in the one from Wednesday (http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-development-shining-fixes/rev/248340/index.html) if you want try that. Charlar Quote Share this post Link to post Share on other sites
Sassy Romano 269 Posted January 27, 2012 I'll happily try this. I have exactly the same issue. (no permission to download that though) Quote Share this post Link to post Share on other sites
Helium Loon 24 Posted January 27, 2012 Sassy, there's a ')' on the end of his link.....delete that from the url, and you should get the right page. I downloaded the client, but won't be able to try it unitl this evening (when I get home from work).... ETA: Just as easy to post the corrected link here: Correct link to shining-fixes build 248340 Quote Share this post Link to post Share on other sites
Sassy Romano 269 Posted January 27, 2012 Thank you, I can try that a little later and will report back. Quote Share this post Link to post Share on other sites
Sassy Romano 269 Posted January 27, 2012 YES!!! That viewer fixes it although the viewer itself needs RLV adding if you want it to work properly I'll just have to wait for this fix to make its way out to the TPV's but this is the results in two viewers:- (ignore the fashion issues, I was trying two things at once for this test) Firestorm: http://gyazo.com/0b17e3182a2dc60a08682bc2bf334025 Fixed LL viewer: http://gyazo.com/c536a6caec5c01b94b4dc5df997043cc This also fixes the HUGE issue of textures with alpha causing the whole object to be rendered invisible when using shadows. Quote Share this post Link to post Share on other sites
Charlar Linden 25 Posted January 30, 2012 great news, thanks for testing it. Sorry, can't help with the RLV... :-) Charlar Quote Share this post Link to post Share on other sites
Tiberious Neruda 1 Posted January 31, 2012 I hope this 'fix' comes in the form of an option. I have a couple avatars that use this 'bug' in certain areas. I'd certainly hate to lose it and have to deal with the alpha sorting glitch again. Quote Share this post Link to post Share on other sites
Charlar Linden 25 Posted January 31, 2012 Siddean, did that fix also correct your issue? Charlar Quote Share this post Link to post Share on other sites
Charlar Linden 25 Posted January 31, 2012 It's not an option, since we considered it a bug. If you consider the way it used to act as a feature, I need you to write a jira that explains what you'd like it to do, so we can triage it and respond as needed. Charlar Quote Share this post Link to post Share on other sites