|
|
|
[
Permlink
| « Hide
]
Harleen Gretzky added a comment - 25/Apr/09 08:56 AM
Both reproduce for me.
This happens to attached objects too, causing things like pets to not function correctly. I'd call it "major" at least, as any content with scripted alpha swapping is effectively broken by this bug.
This also happens for me, and it seriously breaks one of my main products. It is a room scripted to lighten and darken gradually, but in the RC viewer, the transparency change is not shown until the room is right-clicked, forcing a client update. When the change is shown, it is very sudden and all at once.
Second Life 1.23.1 (119104) May 4 2009 17:53:10 (Second Life Release Candidate) I should also note, that particles in this viewer also seem to hang around much, much longer than before. I mention this here, because the particles in question are supposed to be transitioning alpha, and are not. They are either never appearing, or they are never disappearing (until they die) due to the alpha on them not changing. It appears to be directly related to the same issue.
Reproduces for me with attached weapons (Draw/sheath). When sheathing, some of the weapons prims remain visible for a while (20-40s)?
Looks to me as if they are rather "garbage collected" than really set to invisible. Also NVIDIA and Core2 Duo, btw. Viewer Version 1.23.1 Arishia Nishi added a comment - 11/May/09 06:07 AM
This happens with all my Combat Samurai Island swords, too. When you sheath the sword the blade remains visible when it should become transparent. Work around is to dettach and reattach while sheathed, or don't use the RC. When will this be assigned to someone to fix!!
Not fixed in RC2. This is a showstopper. Alexia Linden closed other jiras unrelated to this one and declaring them to be related. This appears to be another episode of Linden Lab arguing with customers that report glaring defects.
Linked set rezzed in world camera must be focused on other object for prims to be visible
This is what the linked set looks like with default camera or cam focused on linked set.
This is what the same linked set looks like when worn with no camera focus
This is worn with view transparent to demonstrate it is not related to alha at all. There are missing prims. They have no alpha texture.
This is how the same linked set looks in the current production release version 1.22.11 (113941). Normal camera. Not focused on attachment. Works fine. This is what it is supposed to look like.
By adjusting RenderVolumeLODFactor up and down with the value scroller you can see prims turn on and turn off. Seems to be connected to that part of the code.
Note this issue does not exist in the current productiuon release. Note this defect is unrelated to pose balls as it happens when prims are rezzed in world or simply worn. Nor is this issue related to alpha or transparency in any form or fashion. The examples I gave do not use transparency or alpha in any way shape or form.
I have to agree that this is important, and it is still not working. Again, I'll not that this is not only true for attachments, but is also broken for regular objects that transition alpha. My example can't be conveyed with screenshots, so I'll be uploading video examples shortly.
For those who want to see it for themselves, you can try it in the current release or previous release (1.21 is what I used for the "working" videos) and then in the RC viewers at http://slurl.com/secondlife/Wetheral/241/28/2515 Edit#2: For those of you that visit the SLURL, that is the location of my demo product, so there will be a sign floating over it that doesn't appear in the videos - you can just ignore that. Edit: Ann, just read your additional comment. I would actually disagree with you, as I believe the two are related. I think my videos will demonstrate why: What is occuring, is the client is failing to update, both in the cases where edits are not appearing until zooming, or transparency is changed, the root cause is the same. Zooming in, or right-clicking, forces a client update, and that is why as you'll see, it "fixes" both problems ~ unless I'mmisunderstanding the issue you're referencing. Summary updated to better reflect overall description of the bug.
Affected versions updated. Attached three at once, but it won't let me upload more than 3 at a time. I'll attach the fourth. In order, they will be:
FadeOutNormal FadeOutBroken I have tested this several times, and the videos represent a consistent behavior in how the viewer is failing to update the changes properly. Notice at the end of this video, (FadeInBroken) how I have to right-click the build in order to force the client to update. The same result would occur if I had alt-zoomed instead.
It's interesting to note, although a slight rabbit trail, that even though the viewer is being updated fewer times in RC2, I actually have much better framerates and ease of camera movement in the 1.21 client.
My point is that by adjusting RenderVolumeLODFactor up and down with the value scroller you can see prims turn on and turn off. Seems to be connected to that part of the code.
Definite issue with the render code. All we need now is an acknowledgment by LL that they actually care and will fix this. The code worked before and was not defective. There was no reason to change it. they need to revert the code. And perhaps the CEO needs to address the constant introduction of blatantly defective code at the root level. I was told that there was going to be an RC TRiage meeting held at 2:30AM (yep, AM). I plan on attending it to bring up this very JIRA so that it can get some attention.
Had to find the email I was sent:
(Louise Linden) Triage will be held at my office: http://slurl.com/secondlife/Cirano/208/169/25 and the agenda can be found here: http://wiki.secondlife.com/wiki/Bug_triage/Thursday_Agenda Adding sysinfo as I updated to latest nVidia drivers to retest with same/similar results:
Second Life 1.23.2 (120719) May 18 2009 09:43:42 (Second Life Release Candidate) Built with MSVC version 1400 You are at 267757.8, 279264.3, 4001.5 in Kali Isle located at sim4728.agni.lindenlab.com (216.82.55.124:12035) CPU: Intel Core 2 Series Processor (2399 MHz) libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3 This is a problem for HUDs as well - the change to transparent isn't seen until it is right-clicked.
This defect is present in Second Life 1.23.3 (121709) May 26 2009 21:57:56 (Second Life Public Nightly). When you zoom in some sculpty prims vanish.
This defect is present in Second Life 1.23.3 (122255) May 30 2009 13:13:41 (Second Life Release Candidate) therefore it does not appear to be fix pending.
Repeat this defect is NOT fixed. This defect is going to become a showstopper if not corrected and this release is pushed onto the community. I suppose it is possible an unqualified person closed other issues as duplicate that are not duplicate. Should I open a new Render Volume LOD Factor defect since Linden Lab thinks this consolidated alpha defect is fixed? The images I provided above for this defect show exactly what I see in the viewer. If the assigned dev wants I will send samples to work with so they can see the actual defect for themselves. Just tell me who is actually working on it. This issue is not listed as fixed in the Release Notes for the Release Candidate yet. It is only listed as fixed in the Public Nightly Release Notes.
Not fixed here...
Second Life 1.23.3 (122084) May 28 2009 21:01:25 (Second Life Public Nightly) Built with MSVC version 1400 CPU: Intel Core 2 Series Processor (2135 MHz) libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3 Hrm - for those who are very familiar with this JIRA, was this a partial fix, or do you see any difference at all? Is the texture mapping mode the only change that needs a camera move?
Can you lay out specific repro steps for what's still failing? Keep the steps as simple and brief as possible. JIRAs stand the best chance of being fixed if they can be demonstrated and understood by a project manager in under a minute. We think that we fixed all instances of this issue except for the texgen mode (Defau/tPlanar mapping), which we missed.
The alpha HUD issue is a separate problem. I would appreciate hearing information about the impact of the texgen issue – is there a use case for changing it and not changing other texture parameters at the same time? Is there content that depends on being able to do it? I'd also appreciate hearing about any other instances of this problem – with, as Soft suggests, a detailed repro case. Now we have a fix for the texgen issue too. Thanks for your testing.
If you're wondering where some of the screenshots went, it looks like what Ann was describing was different, and that's now in being tracked in
According to the release note of 1.23.4 this is supposed to have been fixed. Looking more closely at what i have just observed with 1.23.4, I created this issue: https://jira.secondlife.com/browse/VWR-13982
Well the issue is still present for flexible prims.
So for example the change in Alpha for a flexible prim is not visible until the camera is zoomed away and the prim no more directly visible. Prims in both attachments as well as in rezzed items vanish when camera is moved in close. As described before, they are back only when I move the camera far enough away and then zoom in with ctrl-0 to see the details.
I have noticed the following: My Details: Second Life 1.23.4 (123523) Jun 9 2009 08:32:14 (Second Life Release Candidate) Built with MSVC version 1400 You are at 159839.5, 248544.0, 28.2 in deviousMind located at sim8306.agni.lindenlab.com (216.82.38.119:13002) CPU: Intel Pentium M Series Processor (1700 MHz) libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3 Happening to me too, details below, screenshot attached above.
Second Life 1.23.4 (123908) Jun 11 2009 15:16:56 (Second Life Release) Built with MSVC version 1400 You are at 249120.1, 279465.8, 673.7 in SomTek located at sim2176.agni.lindenlab.com (216.82.16.181:12035) CPU: Intel Core 2 Series Processor (2400 MHz) libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3 Update at least on the part of prims vanishing and a workaround for that:
------ By default the above mentioned viewer now caps "vertices" at 4096 for any scene that is shown on your screen (and it seems to happen a lot more often when zooming in on small prims), which can result in random prims that simply won't be rendered by your viewer, even though they are actually there. The 4096 limit has just been set too low for most people's purposes, especially if you like items, attachments & scenes with a lot of detail - but here's a very simple fix! 1. Show the "Advanced" menu with Ctrl-Alt-D, or Opt-Ctrl-D on a Mac. rendermaxNodeSize 4. Replace the default value of 4096 with a higher numer - a number between 6000 - 8000 will work fine for most people's needs (you can just experience with the numbers until you are satisfied) 5. After replacing the number, close the window and wait for a couple of seconds - you should then see all prims after zooming in and out again. Even low end computers can handle a lot more than the default 4096 vertices and you should not feel any decrease in perfomance Feel free to pass this notecard on to let your friends know as well! --------------- The defect seems to only affect flexible prims in Snowglobe 1.1.2 (2584) Aug 1 2009 09:40:23 (Snowglobe Release)
rendermaxNodeSize does not fix this for me. I have to click on the prims. I can click on them and make visible then if i change camera to another view and return to the items (jewelry mostly) the will have disappeared again and i will have to click again. You can imagine what a PITA this is shooting models in a fashion show. This problem seems to be worse with 1.23.5. I would love to use Snowglobe, but it is important to me that prims and avatars be textured eventually. Texture loading problems make snowglobe unusable for me. I am curious what "broke". This jira issue was not a problem 6 months ago, but then neither were most of the snapshot bugs problems 6 months ago. It seems logical to me that things that used to work ok and then don't in new releases would get the highest priority. I don't get it... if you break it, fix it, new features and wizz bang doodle stuff can wait till you fix what you broke making the new stuff.
Second Life 1.23.5 (136262) Oct 14 2009 12:08:26 (Second Life Release) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||