|
|
|
Second Life 1.23.1 (119104) May 4 2009 17:37:40 (Second Life Release Candidate)
Built with GCC version 40001 CPU: Dual PowerPC 970 (2000 MHz) libcurl Version: libcurl/7.13.1 OpenSSL/0.9.7l zlib/1.2.3 Same here. Screnshots attached Upgraded this to "showstopper", cause it is a serious showstopper to everyone who uses a skybox.
Vivienne, Showstopper is reserved for bugs the create the inability for many Residents to login. I am moving this back to Major.
Also happens with the Linux client with a GeForce 9600M GT. I noticed that this only happens when there are other prims rezzed around, as in, rezzed in-world as opposed to worn as attachments, but I didn't check that in depth, YMMV.
Second Life 1.23.1 (119104) May 4 2009 17:57:12 (Second Life Release Candidate) Built with GCC version 40102 You are at 277113.2, 281223.5, 26.8 in Truth Island located at sim5359.agni.lindenlab.com (216.82.49.106:12035) CPU: Intel(R) Core(TM)2 Duo CPU T5900 @ 2.20GHz libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3.3 c-ares/1.4.0 Alexa Linden:
"Vivienne, Showstopper is reserved for bugs the create the inability for many Residents to login. I am moving this back to Major." Alexa, if i were a noob, this would let me log in ONCE. I would not be able to log back because of the pain to my senses it caused for a second time. So this is clearly a Showstopper.
If you read the description for a true "Showstopper," you'll find that it should be on par with something that makes SL actually unusable for many residents (login issues, very frequent crashes, breaking or loss of large amounts of content, and the like). While it's annoying, keep in mind that this is a release candidate, and effectively an "0" release at that, since the real 0 wasn't up long enough to be tested.
If you were a "noob," what would you be doing on a release candidate? The Lindens are definitely aware of this problem, there's no need to play tug-of-war with the severity of the issue to try and get it more attention. "...there's no need to play tug-of-war with the severity of the issue to try and get it more attention."
Right. Everyone using the RC will notice it, anyway. Let´s hope that LL is really aware of it.And a "candidate for release" should not be a "O" which "wasn't up long enough to be tested", but a RELEASE candidate. @Vivienne, I'd imagine LL is aware of it, as a Linden has responded in the comments (and you responded to her), and we have this bit of information visible:
Last Triaged: 30/Apr/09 10:49 AM The Release Candidate cycle goes through many stages, you'll notice the current one ends in "1" (1.23.1), which indicates that this is the second iteration of this RC cycle (beginning with 0). The 1.23 RC0 wasn't available for download for very long, as it was showing false positives on virus scanning programs, causing a bit of a panic. Thus, RC1 is having the normal level of problems as a usual RC0, since not many got to test it. Being a "Release Candidate" doesn't mean this viewer is ready for release, or even close. Just close enough that it can be given out to the general public for testing on the main grid without causing too many problems. Many things are tested for the first time on the early iterations of RC viewers, when they're considered "low risk," so that new features and improvements can get out to the public faster. If errors in the RC interfere with your experience, the simple solution is to switch to the main client. While many of us use RC clients all the time, they're meant for testing the newest features and finding bugs. It's normal for there to be problems this early in an RC cycle, so don't panic, they'll be fixed before this makes it anywhere near the main viewer. Ephyu: "Being a "Release Candidate" doesn't mean this viewer is ready for release, or even close."
Wrong. http://en.wikipedia.org/wiki/Software_release_life_cycle And I still consider this being a showstopper bug. What else is such a bug in a 3D rendering application? The inability to render the BASICAL environment in a sufficient way is worse than "major". Btw., your optimisim here is striking, but for now this bug is still unassigned. No fix in RC 1.23.3
Ups, sorry, in 1.23.2... I hope the error is no self fulfilling prophecy. Unplayable as is. The blog says:
"...we're very close to releasing the official 1.23 viewer..." While I wasn't worried earlier in this RC cycle, I do believe this issue needs some attention before this goes out as the main viewer. Any updates from the front lines? I had some confidence that an issue this glaringly obvious would be fixed, but maybe that confidence was misplaced. I know this issue was triaged more than two months ago, was it imported? Why is nobody assigned? Same for today's released version 1.23.4.123908
Effect starts to become unacceptable above 600m - Water rendering is buggy and results in gaps in the panorama and partially heavy flickering. Starting at about 700m the viewer becomes unusuable due to the massive flickering of the "water panorama". Here's a movie that shows the issue, shot at my sky platform at 700m: http://www.youtube.com/watch?v=gIEDZKAFNPg
 In 1.23.4 this seems to be fixed, at least in an acceptable way. There are still flickering areas on the left and tight side of the viewer screen on a fast turnaround, but no comparison to the original bug. So if the Windows and Linux GPU´s (I think every other 7xxx, 8xxx and the 9600 series, based on in-worl informations ppl gave me) are fine with this fix as well, we can close this here. A lot more major and critical issues with 1.23, anyway.
I agree, there are more important issues. But you are wrong, it's still a big pain and if you do a closer check you will find that it depends very much on the camrea angle how bad the problem is. if you watch the above recorded video and look for the scene where it really flickers, then you know what I see most of the time on my screen (like other who I talked to for confirmation of what I experience) ...
So absolutely NO reason to close this issue! True, it is still awful. My oh my.
Fix? What fix? This hasn't even been assigned to anyone yet...
Here is a video demonstrating this is still very much broken in 1.23.4, and hopefully shows where the problem lies (in culling of water patches?)
http://files.getdropbox.com/u/146120/water%20occlusion%20flicker.mp4 Ok I have never felt compeled to post bugs as I felt they were minor. Today I am either posting or adding comment to, count them, six issues with the new viewer.
I know that this grid consolidation was a must do but really please get this fixed ASAP. First time I have had this bug - 1.23.4 update (as RECOMMENDED by LL on the login screen) and I have never been more disgusted with a release viewer.
This water issue is not only visually grotesque with flickering water appearing and disappearing in random blocks when viewed from distance - but it affects fps performance too. I wish I could vote more than once.. this is driving me batty. Between this and the new camera movement thing..
Vivienne, you really need to stop putting the priority of this up to Showstopper. A Linden lowered it, that should have been the end of it.. Read the description:
"ONLY the most severe, confirmed issues which demand immediate attention from Linden Lab. For example, inability for many Residents to login. IMPORTANT: Abusing this setting will cause revocation of Issue Tracker access. If in doubt, mark "Critical" instead."" Firstly, it's not confirmed. Secondly, this has absolutely no characteristics that prevent you actually using SL (it doesn't stop you logging in and it doesn't make you crash; it's purely a visual bug). Thirdly, it tells you not to abuse this setting - using it where it's not appropriate is abusing it by itself, but the fact you insist on continually setting it back up, even after a LINDEN lowered it, is seriously pushing it. To be honest with you, while this issue may seem like a high priority to you, in terms of actual importance, I'd only rate it normal as it's a minor impairment and should hopefully be relatively simple to fix (although I'm not certain). Now, on to the actual matter... This is kind of an annoying issue. It would be nice to have water still visible after 1024 m, however I'll admit I can't really see it anyway from 900m - it's just the horizon being visible that is the issue for me, which I guess would still be nicer to have than ugly repeating pixels. I'm voting for this to be fixed. Edit: I am aware, after making this comment, that my criticisms about the priority are a bit unnecessary now as it was a month ago, which I'll admit I didn't notice, but I believe what I said is important for that time. Ethan, i could not care less about Linden defined "priority". I cannot change their mind, cause they own Second Life, but this does not prove that they are right, or their opinion is more valid than anyone else´s is.
This as well as any other extreme visual bug BREAKS the viewer for most people. No one using a 3D applicaton or 3D game will continue using it when this application refuses to render the BASICAL environment correctly, that´s a matter of fact. Hardcore SL residents may be able to live with such annoying glitches, but who else would spend a single cent on such a piece of obvious trash (from the average computer user point of view)? The viewer makes people SEE and FEEL second life, and if Linden Lab breaks the visual experience, then they harm Second Life the same way as if they would harm it by any major database disfunctionality. This major problem commenced following the latest full viewer release. At elevation (700m) the blue horizon breaks up, there is periodic flickering and looking down the 'blue' is curved ' and distorted.
Vivienne, priorities are there for a reason, and described as they are for a reason, and if someone doesn't care about them it doesn't give them the right to abuse it and do whatever they like. You have to understand that priority level of an issue is not an exact correlation to people's importance for it. Just because an issue may feel like a Showstopper to some (which it obviously does for you, and I understand that - I have issues that annoy the hell out of me too, one that I reported and haven't even had any votes on VWR-11486), even perhaps to hundreds of people, if the issue itself doesn't affect the viewer in that way, then it isn't. Check the most highly voted issues on the JIRA - they are not showstoppers. The majority are major, like this one.
Anyway, that's my last mention on the subject in this issue. I'm not getting into a debate over priorities. The actual issue needs to be concentrated on, not its priority level. Priority doesn't necessarily mean it will be fixed any faster anyway, nor does the amount of votes an issue has. Fly up to 500 m, then fly down straight ahead and see what happens. I added a screenshot. This does affect ANY other nVidia GPU cross-platform. This does NOT affect only "some" people, and it certainly will not help keeping ppl into SL nor does it help attracting any new ones, not to mention convincing any business or educational groups of SL usability, reliability and skills of the people coding this. And it´s NOT acceptable for ANY 3D rendering application. If something equal to THIS would happen at Blizzard, EA or any other company, someone would have to pay the price, believe me. Linden Lab obviously only lets the user pay and refuses even to take notice. Ethari, you can kiss their flipside for whatever reason, i won´t.
Looks like another problem caused by Linden's desire to 'fix' rendering speed performance issues on the cheap by crippling the client and imposing unacceptable rendering limitations. Unless there's a 'debug' setting that can workaround this performance issue, this is a critical priority to get fixed.
This a 2-line patch that seems to prevent "edge water patches" from being occluded bellow 1024 meter height (which looks like missing water at the middle of the screen)
There are two other reasons for flickering I can see, which this patch doesn't solve:
Both of these are very noticeable when rotating the camera fast at heights above 200-250 meters. @LeekAlpha: for a simple workaround, turn off Object-Object Occlusion under Advanced > Rendering. Updated patch that deals with missing water at edges of screen too. This makes missing water only happen when rotating camera fast - no missing water when standing still.
However, on second thought, I'm removing the "patch attached" flag from this, since my patch is probably not the way to solve this. I think water culling needs to be fixed more fundamentally. Oops, didn't see the second part of the comment; I'll just make a note of it in the internal issue then. This problem also exists in Snowglobe 1.0.2.
I notice this only happens for me above 584m and ..
when 'Basic Shaders' is off, the problem goes away. when 'Atmospheric Shaders' are off, its black instead of white patches When I drop my graphics setting 'quality and performance' slider to lowest ( faster) and then back up to maximum (custom) the issue stops completely. I am using.. Snowglobe 1.0.3 (2537) Jul 20 2009 20:48:49 (Snowglobe Release) I suppose I should check Jira entries more closely from now on.
I posted a support question on this same issue and if anyone is interested this is the response I got back; "Hello Richard, Have just spoken to an engineer who has told me it is because of the height you are at. Our graphics are set as a 'Windlight dome' and that dome is flickering because of the height you are at. Unfortunately there is no further help we can give. Hope this at least explains why it is happening. Thank you, Kaylee" Ticket Information: So they are not even able to fix BASICAL rendering. But they seem to be able to mess it up.
Excellent work, Linden geniuses and deceloper aces. Btw., to whom do you want to sell this mess, if not to a few thousand hard core masochists who are willing to live with all these outraging bugs and flaws? This seems to have gotten worse the last week.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Critical
1.23: Water flickers and disappears in patches
http://www.youtube.com/watch?v=F0MeueXWCBw
CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (3833 MHz)
Memory: 8190 MB
OS Version: Microsoft Windows Vista Service Pack 1 (Build 6001)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 260/PCI/SSE2
OpenGL Version: 3.0.0