|
|
|
Works fine on:
CPU: Intel Core 2 Series Processor (2400 MHz) Can someone with an ATI card try to reproduce this, see if they have any luck? Weird, Kesseret Steeplechase reported this but her name is invisible to me as Reporter here. Thanks for observing this...
This "alpha textures become opaque at a distance" change was actually intentional ( http://wiki.secondlife.com/wiki/User:Torley_Linden/Project_updates#.5B2007-12-13.5D_.5BWINDLIGHT.5D_Alpha_textures_becoming_opaque_at_a_distance Does this "trick" really increase performance significantly? It makes most alpha objects look terrible, so I have my doubts if it's really a good idea...?
Elevated to Critical for us to resolve pending WindLight Release Candidate status, I know this, even in small amounts on the screen, ruins the overall look of some scenes.
I was thinking the same thing as Nizzy. Do you have some stats on how much performance is gained using this optimisation? Is it worth it?
I'm not implying this should be removed. If we are seeing some nice gains in FPS then it should be used but tweaked a little more so it doesnt make everything look so bad. If we are talking about tiny performance gains then maybe it should be dropped or made optional. Reproducable on nVidia 7900GT, Vista 32.
Also, nice choice of build. >.> Reproduced in XP SP 2 , 8800GT 512.
Since this was apparently done to increase performance, this should be another option in the graphics tab in preferences. Look for a fix for this soon – the transition should be more reliable.
Second Life 1.18.6 (77495) Jan 22 2008 15:30:40 (Second Life WindLight)
CPU: AMD (Unknown model) (3013 MHz) Still happening with this release of Windlight. for me, this is new since 77495
Second Life 1.18.6 (77495) Jan 22 2008 15:30:40 (Second Life WindLight) CPU: Intel Core 2 Series Processor (2394 MHz) (screen attached... cause i made one 0_o ...and heck yeah this looks ridiculous!) For me this is new too
CPU: Intel Core 2 Series Processor (2127 MHz) and its pretty annoying Here was me thinking this problem has just occured with the latest windlight viewer 77495. Up til now I've had no problems with this feature, though now textures are appearing solid at a distance, and transparent objects with blank textures are doing the same. See pic Alpha problem example.jpg
I'm running a Geforce 6600 using nVidia 84.21 drivers (would use the latest drivers if nVidia would fix the full screen video problem). Paula Follow up to my earlier comment.
Using the latest nVidia 169 drivers had no effect. However I have discovered that in my case the problem was solved in part by turning the atmosphere shaders back on. Turning them off again causes the problem to return. Paula hi,
i attached the video where i create a simple cube, set the alpha of it with a script to 0 and use the scroll wheel to come closer and go far to/from the 'alpha' cube. greeting, tx Oh — my environment: Second Life 1.18.6 (77495) Jan 22 2008 15:22:55 (Second Life WindLight) CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ Okay, so Torley, how exactly this has been 'fixed'? To me, it seems the best fix would be to stop trying to cover up these mistakes and dismiss it as a failed attempt to increase performance. I assume the fix HASN'T made it into the last viewer release on Jan. 23, since it's still there and still very much unpleasant to look at someones invisible junk hanging out of their pants, but something tells me I don't want to wait to find out how 'the transition' has been fixed. There's more important things the developers could be working on, like NOT making SL uglier than it already is. It's stuff like this that makes me want to leave SL and not come back.
Attached an image comparing the rendering of the same scene between a non-windlight viewer (top) and Windlight 77495 (bottom). The scene is a series of boxes lined up in a row, all with the same texture. In Windlight, alpha textures at a distance become "simplified"; opacities > 0.5 become 1, opacities < 0.5 become 0.
It seems that the bug has changed recently, possibly due to the fix that Torley mentioned. Older reports mention that the alpha channel was simply being ignored, making the entire texture opaque (even if it was totally transparent before). I suppose that this new behavior is an improvement over the old, but it's still visually displeasing. It would be very useful if this behavior were optional. I'm sure a large number of Residents (myself included) would prefer a slightly lower framerate over an ugly scene. I have noticed that since the new version this only occurs for me, as well as many of my friends, if Atmoshperic Shaders is turned off. Turning Atmoshperic Shaders on seems to fix the problem immediately.
Based on Ethari's comment, I tried disabling Atmospheric Shaders, and all transparent textures became fully opaque as other people have described. With those shaders enabled, I see the behavior as described in my previous comment and shown in the screenshot I attached.
As Jacek has just made aware, we seem to have two different issues related to this:
1 - Textures with alpha channels seem to be rendered weird at fairly far distances, particularly animated textures such as fire. This has been apparent since earlier versions of WindLight. 2 - Alpha channels are completely being ignored on textures when the camera isn't quite close to them - most noticeable with avatar attachments. This seems to be when Atmoshperic Shaders is disabled and has only been apparent since the new version of WindLight. Would it be possible to check for prims that are 100% transparent (or above some threshold) and instead of ignoring the alpha channel, just drop them from the render pipeline? It seems like this would both improve the framerate as well as making this "bug" (which it turns out was an intentional change to improve framerate) less offensive.
It also makes the freeview TV VERY awkward to use unless you're zoomed in (for me the image only started to show when it filled about a quarter of my screen). I'm attaching a screenshot above to show the problem. At first, I thought there was something wrong with the TV, then SL, then I remembered this issue. Must be pretty confusing for people who don't know what's going on, I bet.
Personally, no offense to the lindens who tried to do something good, but I think it was a very stupid change, at least with the settings it is currently on. If someone is wearing "private equipement" I can see it if my cam is more than a few meters away. The smaller the prim, the closer the camera has to be in order to make it disappear. I'm sorry, but I'd rather just do away with this "feature" altogether. It leads to too many awful appearances and embarassing moments. I for one do NOT want to see someone's naughty bits when passing them on the street – at any distance – which is the current state of things. As much as I love windlight, this is by far one of the most annoying things about it. I've even friends who didn't realize it was a feature and thought it was a bug who have sworn not to use Windlight again till the "bug" was fixed. If you ask me, the impact of using this as a means to increase framerate wasn't thought through very well, considering the number of things it affects, especially avatars. One of my friends has a transformer AV, and can't use either vehicle or robot form without being surrounded by a cloud of random small prims which are part of the "invisible" form.
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. @Colin Kiernan
From my understanding, fully transparent prims still must be rendered because the client uses glReadPixels to determine the object you've clicked on. If fully transparent prims/faces weren't passed to opengl then you wouldn't be able to select them due to opengl not being aware of them. Opengl could have optimizations to handle completely transparent polys efficiently, but regardless, I'm not aware of a simple workaround that could be used... You'd be gaining a little bit of saved memory in the vertex buffer, but you'd be also accumulating bloat from the required linden implementation that would have to be created to replicate opengl's likely more optimized preexisting functionality. One thing that LL could do would be to create something similar to the invisiprim textures... an "untouchable transparent" texture... texture with that UUID would have the effect of hiding the prim face using it completely, and not rendering it at all unless you were in edit mode. This would be used for completely hidden surfaces that shouldn't be touchable... not just hidden attachments, but also interior surfaces of walls and other surfaces that will never be rendered.
PLEASE undo this alpha change entirely. It breaks almost all machinima-related uses of the Windlight client; Imagine a shot where you want to smoothly zoom in on a character's aircraft from a distance, and jarringly, his cockpit goes from solidly opaque to BOOMPH, transparent. Or how about a panning shot down a city street, watching all the windows gracefully strobe back to transparency. Maybe sweeping the camera past a hidden, alpha'd out object, only to have it suddenly appear out of nowhere when unwanted. Or how about the newbie wandering on-set with his prim penis standing out in full, non-hidden, alpha-culled glory.
This completely destroys user content - PLEASE undo this change. Recently I have noticed that this "culling" seems to be working as it's described; pan the camera away it goes opaque and have it go back alpha when the camera is close.
However at times it appears to me that all interior surfaces of a hollowed, cut cylinder with an alpha texture go solid no matter where my camera is. The only way I have been able to 'fix' it was to right-click the object. No interaction with the menu, just simply right clicking was enough. That doesn't always work, so that says to me that this feature is still quirky and in my opinion it completely ruins the appearance of my building as it uses many hollowed cylinder windows that stop functioning as a window sometimes at random. There should at least be a toggle for this, like the Object-Object Occlusion has. Seems like this feature's initial glitches have given it an unnecessarily awful reputation among some (this isn't about making every distant thing SOLIDly opaque; only as off-and/or-on opaque as, say, a GIF image would be, or for example, like all the Linden trees). Properly calibrated, I think it will work out just great. Though being able to turn it off, at least in Debug Settings, would still be a courteous thing to include.
& Might I mention (unless this should become a feature request?), this non-analog opacity rendering mode seems devoid of all sorting glitches, and would be a SERIOUS help to builders everywhere if there were any way of getting certain textures to constantly render this way (ideally, on anything with Transparency at exactly 0 and a texture with only 0 and 100% alpha values... EDIT- except that there's bound to be old content that doesn't look QUITE as good with this version of the change... though usually not a lot worse...). That would even get rid of most of the through-the-wall rendering issues brought in by the Glow effect. Instead of having a debug setting for this, how about making it part of the graphics options? As in, under the advanced section add a checkbox and slider for "Alpha optimization." This would make the feature opt-in, which would be nice for people who wanted to use it to help performance at the expense of the visual experience, and would tie it to the graphics settings slider. We can can raise and lower object detail (which similarly borks builds when set too low). We should be able to do the same with alpha optimization.
This has got to change. It's not just machinima that suffers.
We have graphic detail options for a reason. If people are having client performance troubles, they can turn off (or on) any number of features to increase their own performance at the cost of visual quality. Why this has to be an exception to the established practice of having detail options (and established for good and obvious reasons) is a total mystery to me. So if you make this optional, everyone will be happy... or at least as happy as "everyone" gets. Alpha sorting is already pretty broken in Second Life, so maybe it's time to have a look at reprogramming this entirely anyway. @Julia: Were you on the most recent update?
This is supposed to be fixed/greatly improved in WindLight 1.19.0 (79185), but we're listening to community feedback. Can you please download it and let us know: » http://blog.secondlife.com/2008/02/05/new-windlight-viewer-79185-ati-talk/ This issue has not improved at all in Second Life 1.19.0 (79185) Feb 1 2008 16:24:20 (Second Life WindLight). Like many others I suggest you remove this feature which obviously causes more harm than good. :/
Windlight has no way of determining what prims are "ok" to apply it to and which are not, from an aesthetic viewpoint. @Nizzy and others: To really illustrate the point and make a sample list of reference content, can you please provide SLURLs to inworld locations where this effect is particularly problematic, with instructions on how to see the ugliness? (E.g., "stand here and zoom your camera back".)
/me dances round.....well i dunno about the rest of you but all the places i've been to this update worked for me....all attachments are alpha'd again * wiipes brow*.... phew thought i would have to burn out my eyes again......not wanting to see another guys Xcite dangling
thank you very very very much for the release Since there's been no followup info on reproing this bug, I'm closing this.
Heya, guys... It looks to me like this issue (and/or
EDIT: This happens regardless of whether the 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! Pic showing the reason for reopening this issue, 2/13/2008.
Hey Synth, this probably is because prims are displayed more edgy when zooming out, depending on your setting for object's mesh detail, which is set to "Med"(ium) in the (overall) "High" setting.
I strongly agree with Marcus; these patches look little like this glitch and quite a lot like low-LOD prims sticking through each other - a familiar building problem, but not a texture problem.
With this agreement I'm taking the move of closing this issue again. (I wouldn't want the many watching over it to be falsely worried, plus we can re-open it again if we DO find clear evidence of transparency problems.) While those glitches in the picture probably are caused by prim LOD, the bug in this topic is not, I'm 100% certain. You can easily check LOD by using the ctrl-8/9/0 or the graphics preferences, and when LOD changes because of distance or graphical settings, the opaque switching prims still behave exactly as before.
Example: DOLLY your camera away from the troubled object until it goes opaque. Then use ctrl-0 to ZOOM closer again. Prim LOD remains low because the physical distance to camera is unchanged, but the texture flips from opaque to transparent still, once the object begins to fill your screen. Exactly the opposite effect is seen when reversing the steps. It seems to me like objects are turned opaque not by physical distance in-world, but by their size on your monitor's rendered frame. This means that smaller prims used for glasses or hair will appear solid until you zoom really close. @Torley, Sorry for not seeing your post sooner - I can provide you with an example item. CPU: AMD (Unknown model) (2211 MHz) (It's an Athlon 64 3500+)
Memory: 2048 MB OS Version: Microsoft Windows XP Service Pack 2 (Build 2600) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 7800 GT/PCI/SSE2/3DNOW! (Two cards, running SLi) OpenGL Version: 2.1.2 LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000) Packets Lost: 894/775657 (0.1%) Viewer Digest: aa9ea356-dde8-646d-777c-70207f0aac3d I see this constantly. Even if I set my object detail to the highest setting, it still happens. It has made getting screenshots incredibly difficult. This is with the atmospheric shaders on. If I turn the atmospheric shaders off, the problem seems to go away. This particular screenshot was taken at Simply look at any of the many alpha textures, back away far enough and you see it. At least, I do. The number of alpha textures present does not seem to affect it, either. I've noticed it in places featuring many, and in places with only a few. Sveid: which screen shot are you referring to? You need to put the filename in there because there's no indication of which comment each image is associated with.
 Argent: if you mouseover a screenshot, you can see who uploaded it and when.
In this case, it'd be "Alpha Texture Opacity Glitch.jpg" Mmm, I do apologize for the confusion. Additionally, I suspect I should point out that this is not something I've always seen in Windlight. I could not say exactly when it began, however I've been using Windlight since it first became available (prior to it's too-long absence and more recent return), and yet this problem only began several iterations after it's return. Until recently I'd suspected this was some attempt at LOD, only recently have I tied it to the shaders.
After some more experimentation, I've found that the problem disappears if I disable either the Basic Shaders, or the Atmospheric Shaders. It is only when both are enabled that I see this. However, I have grown very much accustomed to having both enabled The problem seems to particularly affect prims that have less than 50% transparency but rather have alpha assigned by a texture map, or uses a mix of the two but still totals less than 50% transparent in any minor part, by the combination of the two. Changing transparency to 51% on my test object (which also has alpha in its texture) and then lower the strength of the alpha map made the problem vanish. However, this limits what you can build since you're forced to set atleast 51% and go from there.
It probably goes without saying, but I've updated to the latest Release Candidate client ((Second Life 1.19.1 (0) Mar 5 2008 17:51:19)) and still see this issue. Actually, and it may just be my imagination but, it seems to be even more apparent.
This issue was resolved as "Needs More Info" during our batch cleanup because it was set as affecting First Look: WindLight. On the Issue Tracker, we've noticed many duplicate issues and issues that lacked actionable info or were already fixed.
WindLight recently "graduated" from a "First Look" technology preview to Release Candidate status – nearing inclusion in the main viewer with your help! So, "First Look: WindLight" does not exist anymore. More info and how to download the RC viewer: http://blog.secondlife.com/2008/03/06/new-release-candidate-viewer-1191-rc0-available/ If you've verified that this issue is still a problem in the newest Release Candidate, here's what to do next: (1) Search the Issue Tracker to make sure it isn't a duplicate of an existing issue we know about. If it is, link it as a duplicate using the "Link this issue..." link on the left. You can learn more about searching by watching this video tutorial: http://www.youtube.com/watch?v=SAlXK5hSVMc (2) Reopen the issue and BE SURE to update the "Affects Version/s" to the correct one, most likely ONLY "1.19.1 Release Candidate". However, if this bug affects the main viewer (1.19.0 as of this writing), then DO NOT set it to an RC version. Only set it to 1.19.0 instead. Be as specific with versions as possible – there's generally no need to set multiple versions, as it tends to dilute and confuse where a bug originated. (3) Add any other relevant details that would help us fix it. We can't stress the importance of a "solid repro" enough – a reliable series of steps to make a bug happen reliably. (4) Come and attend our inworld bug triages, where you can meet with Linden Lab employees to look at, verify, and expedite bugs for fixing. More info @ http://wiki.secondlife.com/wiki/Bug_triage Thank-you for helping us improve Second Life! I must assume the comment mentioning the closure of this issue was automated across several versions, as my own comment directly above it indicates that this bug is still occurring as of the 1.19.1 Release Candidate.
I am not certain what steps to reproduce this bug I can offer that have not already been supplied, if either the Basic Shaders, or the Atmospheric Shaders are active, then any texture with an alpha channel appears to turn into a broken block of opaque pixels as shown in the screenshots already provided. This, of course, seems directly related to the Atmospheric Shaders themselves, as disabling Basic Shaders also disables atmospheric shaders. Log in using 1.19.1 Release Candidate, enable Atmospheric Shaders. Move avatar, or camera, towards and away from prim with an alpha-texture. This is visible in all presets, including the defaults. Occasionally the textures will change back and forth from this state to how they should look without the avatar or camera moving at all. I am including my current system/software information, again, and an updated screenshot titled "Persisting_Alpha_Glitch.jpg". Here, also, is an updated SLURL of the very location I am taking this screenshot from. http://slurl.com/secondlife/Desperation%20Vivienne/99/88/416/ Second Life 1.19.1 (0) Mar 5 2008 17:51:19 (Second Life Release Candidate) You are at 233315.7, 277592.7, 416.5 in Desperation Vivienne located at sim3649.agni.lindenlab.com (216.82.22.130:12035) CPU: AMD (Unknown model) (2211 MHz) I cannot think of any information I could possibly be leaving out, however if there is any information necessary I will be happy to provide it as this truly is a critical issue for anyone who needs to take environment and product screenshots, or machinima. Just in case it is not obvious what the issue that I'm illustrating is, here in the screenshot "alpha_textures_correct.jpg" is the same scene from "Persisting_Alpha_Glitch.jpg" zoomed in close until the alpha textures appear correctly.
The textures in this particular example are animated, however I have seen the same issue occuring in non-animated alpha textures. If this is a performance tweak, why is it we still see it even if we ramp our Preferences up to "Ultra"? If I declare I want maximum visual appeal regardless of the performance hit, but this STILL shows up, then at the very least there's a bug in that this performance enhancement is utterly ignoring my preferences. For that matter, where's the preference to disable this, like the checkmarks for Shiny and such? If I unclick Atmospheric Shaders, the problem goes away, but a bunch of other stuff does, too. There ought to be a checkmark for this, and it should uncheck if I take the slider to Ultra.
Incidentally, for people who were wondering how big of a performance benefit this provides, I did a quick test. I found a vantage point below my sky building platform where 1600 sq.m. of alpha-textured prims are between me and all the visible objects, and backed the camera up to the furtherest away I could while the client still rendered the alpha textured prims properly. At that point I was getting an average of 82 FPS. Then I backed up a little further, so that all those prims went into the "high performance" mode where they became alternately fully opaque or fully transparent (depending on the part of the texture). At this point, I did see a performance gain: it went up to 84 FPS on average.
If anyone feels like screaming bloody murder over a performance tweak that only gives you 2.4% performance increase at the cost of incredibly badly rendered scenes when it kicks in and with NO option to turn it off even if you're willing to take the massive 2.4% performance hit, join the bloody club... D:< What gets me is that this issue seems to have been closed several times, with messages from such as, "provide steps to reproduce this", and "Needs more info, is this still happening in the Release Candidate?", when if it's intentional the people working on Windlight and the Release Candidate should know better than us, and certainly should not be closing the issue, leaving it unresolved. Especially when it is, quite justifiably, rated as critical.
I'd say this most certainly should not be lumped into the object mesh detail (As suggested in Torley's Project Updates page), it should be it's own, independent setting that we can all turn off and forget about if we're quite fine in foregoing the small performance boost it provides. Honestly, the distance at which avatar imposters kick in should have its own setting as well. Some of us do like to fiddle with our settings, and pick and choose where we care to sacrifice visuals for performance. Things like this really make that impossible, and really just defy reason. I mean, avatar imposters. If you drop your av mesh detail, that means avatars in general are taking less of a toll on your hardware, so maybe you can spare to have av imposters kick in at a higher distance. But you currently cannot choose to do that, because the two are mapped together. If this alpha opacity idea is lumped in with object detail, then I have to crank object detail to make alpha textures in SL not look horrible, so I wind up losing performance, because of this performance booster. This alpha-opacity boost is something I would really see only those with very low end computers even considering. Personally, I'm willing to suffer the performance loss of one or two frames per second to have the remaining 30+FPS look nice. The only impact this feature has on my experience is that I have to think more limited when making transparent builds, because anything less than 50% transparent is useless. It'll look awful. So instead I make things too see-through, to work around this limitation, and the performance gain will be lost anyway.
Since Windlight / RC is experimental, how about disabling this feature for one update and see if any users complain that it's missing? If more than 10 people want it back into SL, then consider adding it back, but in a way that actually works? It's certainly worth trying these sorts of performance boosters, it's just that the users need a way to turn them on and off, and to adjust it when it's on. It would be exactly as if LOD kicked in, dropping everything more than a few feet from the camera to the lowest setting, so you had to be literally right on top of anything before it looked decent, and then not allowing people to adjust when LOD kicks in.
I think I suggested this before
Make it an optional performance boost, turned off by default, except for the lowest graphical settings which can have it turned on by default. In the example picture, the plants textures don't have proper transparency and are also too dark. If this is an intentional change it'd be a pity, it certainly takes away from the natural look of the area.
in DebugSetting set RenderFastAlpha to FALSE will turn this behavior off. This was added a long time ago to help increase frame rates. At a far distance small faces with alpha textures on them are converted to something like a one bit masked image. the pixel is either there or not. 50% transparent and above are convert to 100% while 49% and lower are convert 0% transparent. This reduces the number of rendering passes a video card has to take. Now this could be useful if a user had more control over it. attached is an image "one bit mask texture.jpg" on a very slow system if you zoom in quickly you can see this change occur. as you see this is two lines one red and the other blue on two plane intersection each other. normally the alpha images would pop in front of one another before it change to a normal alpha you can see there the two plane intersect not to mention hard crisp edges. If used with plants and such they would not only render faster but the planes on which the textures are applied would not pop in front of another solving a second big grip of SL users. Many Linden plants use this type of texture which is why most of them don;t have alpha sorting issues. not sure why we have not gotten this texture type yet.
Oh, this issue hasn't been re-resolved? I believe it should be, as,
Regarding 1-bit alpha masking, where we're "not sure why we have not gotten this texture type yet," I finally located and voted on the issue for that new feature: VWR-6713. yes fix this.. my hair is a little transparant... sometimes a part becomes invisible when im close to another transparant object..
I have this problem with ALL versions now including SnowGlobe. I design a shirt with an alpha texture, and glitch pants, and none of them come out clean. They rezz are 'bits', as if a mad competitor has taken to the fabric with scissors
 Amusing as that may be, it's not amusing when trying to get a collection ready for showing. Standard viewer, the lates RC and now SnowGlobe as well!!!!!! Up till now I could at least get most uploaded safely on SnowGlobe, but for some reason glitch pants that have been hand drawn and textured would not fully rezz ... being alpha.I'd love to hear this was fixed, pleeeeeeeeeeeease IF YOU STILL HAVE THIS ISSUE:
Ensure Advanced > Rendering > Render Fast Alpha is UNCHECKED. This is a performance setting intended to speed rendering, and is not intended to render the environment correctly.
If you get the above bug when Fast Alpha is NOT enabled, feel free to reopen this issue. :)
Cannot reproduce on any viewers unless Render Fast alpha is checked, which gives the above results. Resolving as expected behavior. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Critical
Alpha textures are opaque at a distance and the transition is ugly and unreliable
VWR-3197