|
|
|
Previously
See attached picture. Objects and Attachements with alpha textures show as black or white depending on camera zoon when Graphics Quality is set to Low or Mid. Some show as hot pink or hot red, again, based how closely one "looks" at the items. This doesn't seem to affect all alpha textured objects or attachments. Using Ctrl-Alt-T I was able to see someone was wearing a parachte, but only parts of it showed black in "normal" view. A "box" on the avie showed white. No idea what it was. Where? Everywhere. Class 5 sims. Class 4 sims. This is really annoying. ENVIRONMENT ATI Radeon X1600: Chipset Model: ATY,RadeonX1600 Poseballs are bright red at a modest distance, invisible up close, invisiprims like telehub, root prim in Heart trees are white.
Model Name: iMac Chipset Model: ATY,RadeonX1600 "Invisible" (alpha textured) prims become visible with camera further away from said prim. Applies to prims both attacehd and not attached to avatars. Includes full alpha with a colour tint as well as partial alpha textures.
Image 1 of 2 :: Note facelight, prim eyelashes and hug attachment not visible on avatar, and seat positions not visible on boat, with camera at normal/near distance Image 2 of 2:: With camera zoomed out "invisible" prim avatar attachments become opaque (facelight, hug attachment, prim eyelashes) as do invisible seat position markers on boat. (NOTE :: this image has been cropped to show issue better) This has only become an issue for me with Windlight Viewer (77495) My PC Specs:: Intel(R) Dual Core(TM)2 CPU 6420 @ 2.13 GHz Changed priority to Major considering how many builds/avatars/landscapes this affects.
THANK YOU for your reports and to those of you who guided/closed the duplicate bug reports and THANKS to Harleen Gretzky for the heads-up in my email inbox... I've imported this for Team WindLight's investigation soon!
I've also just seen this on the 77495 viewer. However, invisible objects appear visible as soon as 1.6m away from the object, rather than beyond 10m as suggested by others. Most noticeable are the 'invisible' parts of my hair, that can be clearly seen by viewing myself from 1.6m away and further. It looks so bad that I cannot really use Windlight until this is fixed - But as a noobie to SL bug reporting may I just say it's great to see such efforts made to listen to users' issues and actually fix the problems.
 Yeah the smaller the prim the shorter distance the prim becomes opaque. Larger prims turn opaque at further distances.
Oddly enough, I'm
-------------------- CPU: Intel Core 2 Series Processor (2393 MHz) Memory: 2031 MB OS Version: Microsoft Windows XP Service Pack 2 (Build 2600) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 8600M GT/PCI/SSE2 OpenGL Version: 2.1.1 LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000) Packets Lost: 195/68950 (0.3%) -------------------- CPU: Intel Core 2 Series Processor (3000MHz) Memory: 2048 MB OS Version: Microsoft Windows XP Service Pack 2 (Build 2600) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 7900 GTX/PCI/SSE2 OpenGL Version: 2.1.1 LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000) All options on. (atmospheric shaders, etc.) Seen the screenshots of it, have been trying to replicate it, running 77495, it just isnt there... but I do believe others are seeing it! I'll try back on an ATI, and see if it shows up.... but it certainly seems to be non-universal, and related to drivers/video cards/etc. ... Will try back on OSX vs Windows, and ATI vs Nvidia to see if i can provide any narrowdown information. I do have an ATI card Michi, if that helps. I've just upgraded to Catalyst 8.1 but had the problem on 7.11 also. These are my specs..
CPU: Intel Core 2 Series Processor (2000 MHz) I do not believe it's at all driver related. Turn OFF atmospheric shaders (skies) and it will be there. Many of us turn off atmos shaders because frame rates are hit significantly with them on
Same to me... had to remove my attachments... annoying... problem is, happens to others as well. For sure Atmospheric Shaders on removes that, but my config can`t handle that option - machine`s performance drops drastically. I`m using a MacBook, Intel Core 2 Duo series (the 13.3" model)... not sure why machine got identified like that in the below Help | About. Running MacOS X Leopard.
My config: Second Life 1.18.6 (77495) Jan 22 2008 15:22:55 (Second Life WindLight) You are at 219880.7, 296727.3, 24.0 in SkyBeam FirstLand located at sim2100.agni.lindenlab.com (64.129.40.104:13004) CPU: Dual i386 (Unknown) (2000 MHz) Wow - OK, definitely confirmed repro, turning OFF Atmospheric shaders makes this problem evident, turning them on makes it go away. God, I love it when you get good solid repros - makes me hot. ('scuse)
Second Life 1.18.6 (77495) Jan 22 2008 15:30:40 (Second Life WindLight) Added a note in the description that atmos shaders should be off to observe this.
Yep. I have this problem as well.
also see red semi opaque textures on some scripted objects, not all. but this has been going on for about the last 4 or 5 WindLight versions and hasn't changed. CPU: Intel Core2 DUO T7500 2.2gig Pilot McBride: What you're describing with the red semi-transparent textures on some scripted objects sounds an awful lot like a beacon (indicating that a prim is a sound or particle source, or possibly is scripted with touch). If you go into the View menu on your viewer and uncheck "beacons always on", those red highlights should go away.
I didn't see this at all with atmospheric shaders on. Turn them off, and sure enough: a fully transparent texture shows opaque at a distance (Texture "totallyclear", or from Torley's texture pack, "Totally Transparent"); my partial-transparent tail stripe texture shows up that way; a 90% transparent cube shows as fully opaque at a distance.
For me it seems to be a big distance.. and dependant on the size of the prim I'm viewing. The larger it is, the further the camera must be. Second Life 1.18.6 (77495) Jan 22 2008 15:30:40 (Second Life WindLight) CPU: AMD (Unknown model) (1808 MHz) NVidia drivers: ForceWare 163.75 As mentioned in https://jira.secondlife.com/browse/VWR-3101
 apparently this was intentional - That's right, they intentionally made it so that full-alpha items become opaque at a distance. Torley Linden has mentioned this http://wiki.secondlife.com/wiki/User:Torley_Linden/Project_updates#.5B2007-12-13.5D_.5BWINDLIGHT.5D_Alpha_textures_becoming_opaque_at_a_distance here-ish, stating that it was to increase performance, but given all of the objects that use alpha to hide themselves when not in use, I can't even begin to fathom how "Render Alpha useless if it's more than half a meter away from the camera" was a good idea. Logically, if the object is set to alpha, then the creator likely, uh... Doesn't want it to be seen. I have a typing HUD that is visible from the default camera position. People with large wings (And god knows that half the people on SL are angels, demons, or vampires, so they have to have wings) will likely be displeased to hear that all states of their wings are visible regardless of what they're doing, and that on top of that, the wings now look like reprocessed sewage due to completely removing alpha from the wing texture as a side-effect.The... It can't be called a bug because it's intentional, so I'll go with "debilitating feature," is extremely noticeable, anything that uses alpha or alpha textures is victim to this. Torley's example of , "Walls with windows in the texture," is a good example here. Seriously. Go into SL and turn on "Show Transparent Objects." If you can see more than five objects at any given time that are using a basic function (Alpha can't be considered a feature), you may want to reconsider completely breaking it. IF it was done purposefully, I'd call it the most awful idea ever! Invisible prims are used all over for invisible walls, but if they were visible from a distance the builds would be totally covered with ugly. They're used often to transform or show/hide objects or parts of objects, especially attachments. I hope we can vote this fixed. But if not, at least make it an option :O
Agree with Day. Very poor decision. I keep atmos shaders OFF 99% of the time because I have to take snaps of my avatar without it being harshly lit - with this "feature" I cannot wear more than half of the attachments I am supposed to be showing. That and performance is about 10 FPS worse with skies on.
This change is completely inexplicable and unacceptable.
If they want to optimize alpha, then they would actually be better off hiding alpha prims than making them completely opaque. Turning on atmos shaders does not remove this problem for me, as it seems to have done for others. I am still able to see small transparent attachments people are wearing when more than about 1.6m away.
Got it here too. Even at a fairly close range!
Second Life 1.18.6 (77495) Jan 22 2008 15:25:08 (Second Life WindLight) You are at 172881.9, 293077.9, 26.9 in Livingtree located at sim4143.agni.lindenlab.com (63.210.157.47:13004) CPU: PowerPC 7450 (999 MHz) First I must point out that this bug ALSO appears with atmospheric shaders ON (with NVidia Geforce 6600). Same comments as previously - texture transparency appears white at a distance - as shown in my upload "Proudhon Visibility of Trans Textures at Distance".
*NOTE* This bug does NOT appear to affect ACTUAL invisiprims - those with no texture, but the invisiprim script. It affects only alpha-channel textures. Note comparison images (not to scale) - top left, a holoprim spider chair in my vendor. The holobuild has a transparent prim to centre the object on rez. This shows up as a flaw (white square on left) whereas close view (right) shows no prim. Bottom left, two chairs with transparent poseballs which show up at distance (left) but not close (right). Right, my garden flowers particle rezzer - top, the rezzer prims are visible at distance. Bottom (expanded view, actually closer) no prims anywhere in sight. This also affects the transparent parts of alpha textures, giving prims an ugly white border, transparent prims attached to avatars, etc. etc. In short, it shows up just about everywhere and on everything and is a major fault. ETA: Also affects prims scripted to change from opaque (1.0) to transparent (0.0) with state change, e.g. furry tails switching from an up to a down position - can see both tails at distance (see two-tails upload). There has to be better way to increase performance, please consider adding it as a setting for the quality / quality slider menu instead.
But why do these even go opaque? Surely the better solution would be to not render the surface at all if it's alpha? It would make a lot more sense seeing as I'd happily wager that 99% of alpha textures are completely transparent, or mostly transparent. I haven't seen many places where there are slightly transparent textures.
Especially for very distant alpha textures it would be more excusable just to make them disappear completely. But I suppose the hope is that this change causes occlusion culling to work better. Another alternative, how about rendering objects behind an alpha texture INTO the texture? For example, I have a window, and through it you can see into my house. However, when distant you can't really make out much anyway, so what you could do is take the window, render the objects behind it into the texture (thus making it opaque anyway) and then use that texture, update it infrequently and after sudden camera movements and it would look a lot better. At the very least make it an option that is OFF by default, and people with low performance can turn it on. Im using xp media center
I have a 9600 ATI AGP, I upgraded to CCC drivers from 7.7 to 8.1(with the 8.1 agp hotfix installed afterwards) I am running the newest version of windlight. In 7.7 ccc(my driver version) I didnt have this issue. in 8.1, i Had significant FPS issues, FPS drops, My viewer would Stall momentarly when I tried to turn around. And I had the same issues of invisible texture would become opaque. After updating my drivers, SL basically become unplayable. *SIDE NOTE- After reverting my ati drivers back to 7.7, i had none of these issues anymore recommend a meta issue be created by whomever performed the due diligence to identify all the duplicate reports.
this would group all transparency issues together to ease the troubleshooting effort. such areas include alpha textures as well as llSetAlpha(0.0, ALL_SIDES); type scripting. Note that it is critical that the sl viewer perform as well as the non windlight viewer when atmospheric shaders are disabled as this mode is likely to become the defacto default mode of operation since so many people do not want windlight at all. sometimes you have to reassess decisions and make hard choices. Making windlight an "option" for use when taking pictures or filming seems to be more logical than making windlight mandatory given it's consistent problematic nature. Have to second that. For many having WL off will be de facto because of the hit. The basics should be set to mirror the old viewer. That way nothing will change, and no one has to redo any textures. Anything else is just absurd and very badly thought out.
For me, basic shaders drops my frame rate in half, atmospheric causes a drop from 20fps to 0.4fps. That is a massive hit for a few pretty clouds. The lighting is a nightmare, and is going to cause massive colour matching problems, for instance when yo have part prim clothing. Maybe not a problem for all the geeky guys on here, but critical to just about every prim skirt. This transparency seems crazy. Surely, if it's invis, it should stay that way. Would it not be easier, and less processor intensive, to not bother drawing it at all over a certain distance? I have to admit to scratching my head an awful lot with some of your decisions. Adding a snapshot of what something as simple (and important to some people) as prim eyelashes now look like with this "feature." (and ps, you can also see an invisible avatar in this screeenshot lol).
A FIX for this is PENDING... edits issue to reflect current status
"Alpha opacity optimazation should only take affect when atmospheric shaders are on." Thanks all who helped! Edited: missed Torley's response, so nevermind...
I'm confused, why was the name of this issue changed? Partial invisibility doesn't seem to have anything to do with the problem, I thought we were talking about opaque objects that should be invisible/transparent?
Also, if this feature is only around when atmospheric shaders are on, then surely invisible things in the distance will look WORSE with atmospheric shaders turned on? A bit odd for a flag-ship new rendering system isn't it? How hard would it be for the client to analyse textures with an alpha layer, and store a note of how transparent it is beside the texture's key? The more transparent it is, the further away it has to be before it becomes opaque, or disappears, to save on rendering. The more opaque it is then the closer you can get away with making it opaque to reduce work. i.e. - a texture that is 0% transparent would have its alpha channel ignored (it shouldn't have one), a texture which is 10% transparent can become opaque maybe 20m away (dependant on size) without any noticeable ugliness, a 50% transparent texture should never be culled until it goes beyond draw distance or is removed via LOD (since opaque or cease rendering are both wrong), a texture that is 90% transparent can be ignored when rendering if it is beyond 20m (size dependant) since you won't really see it, a 100% transparent texture would never be rendered ever. This would be a far more intelligent system that if properly balanced would ensure we'd never notice any of this culling, and would also get culling of actually invisible prims to boot. The whole point of alpha textures is that they could make a single pixel invisible, or all the pixels invisible, what's needed is a solution that recognises this, not a system that is a hard on/off for something which does not have a boolean case. You can get away with occlusion culling because an item is either visible, or invisible, and it works great, but this kind of culling makes no sense. Torley, please explain what "Alpha opacity optimazation should only take affect when atmospheric shaders are on." means? Is this something that involves the alpha some effect on the shader program, such as the alpha layer being applied redundantly in separate code paths?
The reason for this optimization makes sense really, but the "fix" they implemented is pretty bad. It'd be better off the other way around, with alpha polygons just not being part of the render. It'd still solve the problem of slowdown from multiple alphas overlapping, while not forcing alpha bits to be visible.
Also, the tolerance for how far to show alpha correctly should be further out, and possibly a setting in the Advanced Graphics preferences. EDIT: I see both these suggestions were already raised in previous comments. So, I concur. Torley's comment doesn't make sense in the context of the "obvious" reason for the fix. If Alpha opacity optimization takes place anyway when atmospheric shaders are on, and is just inappropriately being applied when they are off, you would expect to see this all the time and not just when shaders were off. Therefore it sounds like this is some optimization that involves using the shaders to apply the transparency channel that we're only seeing because of a glitch that left it in use when shaders weren't being applied.
@Argent: Bingo
I commented on this in one of the (many) dupes of this issue ( http://jira.secondlife.com/browse/VWR-3101?focusedCommentId=43636#action_43636 Text here for convenience: The version in your hands now does contain a stupid mistake (made by me) that leaves the alpha optimization on when atmospheric shaders are off. This is what's causing most of the artifacts you're seeing. We're getting ready to drop a new version that has much different behavior, but still helps the frame rate. The new version will only apply the optimization to prims that are small and are less than 50% transparent or more than 85% transparent. The very transparent prims will disappear, and the very opaque prims will become solid. There might be some noticeable sorting artifacts on moderately transparent prims that are far away, but nothing as jarring as what's out there right now. Thanks much. Based on that comment from Runitai, I'll bring up small prims such as prim eyelashes. They are one example of alpha textured prims that are both small and less than 50% transparent. Not sure what will happen with items like those, but will have to look and see when the new version is available. See "alpha prims" as an example snapshot attached to this issue.
Included Windlight_transp1.jpg as an example of that.
Please, please make this optimization optional? I have my doubts it has any impact on performance save for the lowest end computers. How about making it optional, and only active by default in the Low Quality graphics settings? Thanx again for your reports and helping us to make progress! This bug is fixed – see Runitai Linden's detailed explanation above – in the newest WindLight version – Second Life 1.19.0 (79185). Download link and more info here:
» http://blog.secondlife.com/2008/02/05/new-windlight-viewer-79185-ati-talk/ Keep watching the Official Linden Blog and check out http://wiki.secondlife.com/wiki/Windlight Heya, guys... It looks to me like this issue (and/or This happens regardless of whether atmospheric shaders are turned on or off. Also, the Graphics Quality & Performance settings are the default "High" values; this was set automatically the first time I started the viewer after installing it. When I use the latest WL viewer and the latest driver for my graphics card, I'm seeing "dropouts" in some personal attachments (hair, shoes). That is, when I zoom out from my avatar, little irregularly-shaped patches of the skin underneath these attachments show through; it looks like the attachments aren't aligned properly on my avatar, or like there are small holes in the attachments. But when I zoom closer, these "holes" magically close up, and everything looks like it should. I haven't tested this with the regular default (non-WL) viewer. Here are my system stats (I've edited them a little to add info from non-viewer sources): Second Life 1.19.0 (79674) Feb 8 2008 16:51:12 (Second Life WindLight) CPU: Intel Pentium 4 (Family 15, Model 3) (3192 MHz) Adapter Information: Video Driver: Display Settings: OpenGL Version: 2.1.2 Thanks! OK, I've read the comments following my reopen of
), and I agree with them. So I'm going to close this one as well.
Thanks, guys – sorry for the false alarm! |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Critical
WindLight: Fallback shiny is partially invisible
VWR-4341('duplicate' of this ticket), there's a also a lot of general ugliness for textures that aren't 100% invisible, but have both opaque and invisible sections.All of the palm trees in this attached photo are identical objects. The ones in the foreground render correctly; the ones in the back render as hideous toruses. I think the alpha-culling in the newest Windlight viewer might break a lot more in-world content than initially expected.