• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-12987
Type: Bug Bug
Status: Fix Pending Fix Pending
Priority: Critical Critical
Assignee: Unassigned
Reporter: Dirk Talamasca
Votes: 77
Watchers: 23
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

Primitives and changes made to primitives are not visible until camera is zoomed.

Created: 25/Apr/09 03:34 AM   Updated: 19/Oct/09 08:57 PM
Component/s: Graphics
Affects Version/s: Snowglobe test build, 1.23 Release Candidate, 1.23 Public Nightly
Fix Version/s: None

File Attachments: 1. File FadeInBroken_converted.avi (3.60 MB)
2. File FadeInNormal_converted.avi (2.47 MB)
3. File FadeOutBroken_converted.avi (2.77 MB)
4. File FadeOutNormal_converted.avi (2.54 MB)

Image Attachments:

1. JIRA_MissingPrims.jpg
(130 kB)

2. MissingPrims.jpg
(55 kB)

3. SL-bug05jun2009.jpg
(2.69 MB)
Environment:
Second Life 1.23.0 (117724) Apr 17 2009 21:19:23 (Second Life Public Nightly)
Release Notes

Built with MSVC version 1400

You are at 253409.5, 299557.6, 22.4 in Desperado located at sim4721.agni.lindenlab.com (216.82.55.117:13000)
Second Life Server 1.26.2.117266
Release Notes

CPU: Intel Core 2 Series Processor (2600 MHz)
Memory: 3325 MB
OS Version: Microsoft Windows Vista Service Pack 1 (Build 6001)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8800 GT/PCI/SSE2
OpenGL Version: 3.0.0

libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.23436 (Mozilla GRE version 1.8.1.21_0000000000)
Packets Lost: 206/62216 (0.3%)
Issue Links:
Duplicate
 
Relates
 

Last Triaged: 07/May/09 08:30 AM
Linden Lab Issue ID: DEV-31956
Linden Lab Internal Branch: viewer/viewer_1-23


 Description  « Hide
These issues are quite possibly related so I will post on both at once.

When poseballs are sat upon, the poseballs do not immediately hide themselves and their visibility will persist unless a drastic change in camera angle is made, generally by using Alt+Zoom. This is best evidenced in couples poseballs (dances, kisses, hugs etc).

On a similar note, and this is intermittent but certainly reproducible with a fair amount of consistency. A change to texture mapping on a prim from Planar to Default or vice-versa on a prim that is being edited by another resident is not visible by the observer until the prim is clicked upon or until the camera angle is altered by the observer, once again, generally via the use of ALT+ZOOM.

Steps to Reproduce:(Poseballs)

You will need a helper

1. Toss out a couples set of poseballs (dance, kiss, hug etc)
2. You and your helper sit on poseballs.

Observe, poseballs do not always vanish immediately but will do so if you zoom in and out or place focus on a distant object and zoom in on that.

Steps to Reproduce: (Objects)

1. Park your avatar so that you may observe your helper as they build.
2. Have your helper rez a prim, stretch it into a nice size for observation and have them make changes to texture mapping from default to planar.
3. Have them tell you when that task has been completed.

Observe, no noticeable changes have taken effect on the edited prim until you click on the prim or zoom your camera away from it and back again.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Harleen Gretzky added a comment - 25/Apr/09 08:56 AM
Both reproduce for me.

Maya Remblai added a comment - 30/Apr/09 03:21 PM
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.

Sebastean Steamweaver added a comment - 08/May/09 01:55 AM
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)


Sebastean Steamweaver added a comment - 09/May/09 06:08 AM
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.

Susan Koltai added a comment - 10/May/09 06:45 AM
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 - 15/May/09 11:54 AM
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.

Spritely Pixel added a comment - 15/May/09 02:22 PM
When will this be assigned to someone to fix!!

Ann Otoole added a comment - 20/May/09 10:29 PM
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.

Ann Otoole added a comment - 20/May/09 10:31 PM
Linked set rezzed in world camera must be focused on other object for prims to be visible

Ann Otoole added a comment - 20/May/09 10:32 PM
This is what the linked set looks like with default camera or cam focused on linked set.

Ann Otoole added a comment - 20/May/09 10:33 PM
This is what the same linked set looks like when worn with no camera focus

Ann Otoole added a comment - 20/May/09 10:34 PM
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.

Ann Otoole added a comment - 20/May/09 11:04 PM
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.

Ann Otoole added a comment - 21/May/09 12:36 AM
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.
Perhaps LL could simply remove the defective code that was installed and put back the code that works and leave it alone.


Ann Otoole added a comment - 21/May/09 12:39 AM
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.

Sebastean Steamweaver added a comment - 21/May/09 12:49 AM - edited
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.


Dirk Talamasca added a comment - 21/May/09 12:51 AM
Summary updated to better reflect overall description of the bug.
Affected versions updated.

Sebastean Steamweaver added a comment - 21/May/09 01:05 AM
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
FadeInNormal

FadeOutBroken
FadeInBroken

I have tested this several times, and the videos represent a consistent behavior in how the viewer is failing to update the changes properly.


Sebastean Steamweaver added a comment - 21/May/09 01:09 AM
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.

Sebastean Steamweaver added a comment - 21/May/09 01:15 AM
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.

Ann Otoole added a comment - 21/May/09 01:23 AM
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.


Sebastean Steamweaver added a comment - 21/May/09 01:27 AM
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.

Ann Otoole added a comment - 21/May/09 01:34 AM
2:30 am when and where?

Sebastean Steamweaver added a comment - 21/May/09 01:37 AM
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

Ann Otoole added a comment - 21/May/09 01:37 AM
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)
Release Notes

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)
Second Life Server 1.26.4.120562
Release Notes

CPU: Intel Core 2 Series Processor (2399 MHz)
Memory: 4095 MB
OS Version: Microsoft Windows Vista Service Pack 1 (Build 6001)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8500 GT/PCI/SSE2
Windows Graphics Driver Version: 8.15.0011.8585
OpenGL Version: 3.0.0

libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24058 (Mozilla GRE version 1.8.1.21_0000000000)
Packets Lost: 0/1638 (0.0%)


jez ember added a comment - 24/May/09 03:53 PM
This horribly breaks a lot of my content, especially an in world game I was about to release.. was hoping for an RC2 fix, hope this will be taken seriously for RC3.

Obi Woebegone added a comment - 26/May/09 11:17 AM
This is a problem for HUDs as well - the change to transparent isn't seen until it is right-clicked.

Ann Otoole added a comment - 27/May/09 07:18 PM
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.

Moon Metty added a comment - 31/May/09 01:59 PM
Second Life 1.23.3 (121709) May 26 2009 21:57:56 (Second Life Public Nightly)
Second Life 1.23.3 (122084) May 28 2009 21:01:25 (Second Life Public Nightly)

I can't reproduce this using the tests from VWR-13097 and VWR-13471.


Ann Otoole added a comment - 04/Jun/09 09:53 PM - edited
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.


Harleen Gretzky added a comment - 04/Jun/09 10:34 PM - edited
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.

Ana Lutetia added a comment - 05/Jun/09 03:09 PM
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)
Memory: 3008 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 9800 GTX+/PCI/SSE2
Windows Graphics Driver Version: 6.14.0011.7813
OpenGL Version: 2.1.2

libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24432 (Mozilla GRE version 1.8.1.21_0000000000)
Packets Lost: 109/58535 (0.2%)


Soft Linden added a comment - 08/Jun/09 07:52 AM - edited
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.


Q Linden added a comment - 08/Jun/09 08:47 AM
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.


Tofu Linden added a comment - 09/Jun/09 03:19 AM
Now we have a fix for the texgen issue too. Thanks for your testing.

Celierra Darling added a comment - 09/Jun/09 08:38 PM
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 VWR-13868 .

Sharron Schuman added a comment - 11/Jun/09 07:18 PM - edited
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,

Kailrim Garrigus added a comment - 12/Jun/09 12:25 PM
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.

Chandra Meehan added a comment - 21/Jun/09 02:51 PM
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:
• Detaching attachments and re-attaching seems to fix it to the extend of OTHERS prims vanish then.. I managed to get rid of the problem by simply going through this process 4-5 times with hair. It seems very random though as always different prims are vanishing.
• The above described back to inventory and re-rezzing seems to be the same when caming in close at rezzed objects in world. I noticed it must be related to the number of linked prims maybe, as I had immense problems with one item I created (about 140 prims) - and when I down-primmed it to approx. 80prims in the linkset the vanishing stopped. (In case this is of interest: it was the same object with same root prim that had created the major problems before and not gone into inventory in between; as well, I delinked only selected prims with ctrl-shift-L and not one complete delinking/relinking)
• It effects all types of prims: regular with alpha textures, regular non-alpha prims, as well as sculpted prims

My Details:
--------------

Second Life 1.23.4 (123523) Jun 9 2009 08:32:14 (Second Life Release Candidate)
Release Notes

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)
Second Life Server 1.26.4.120562
Release Notes

CPU: Intel Pentium M Series Processor (1700 MHz)
Memory: 1024 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce Go 6800/PCI/SSE2
Windows Graphics Driver Version: 6.14.0010.7911
OpenGL Version: 2.0.0

libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24815 (Mozilla GRE version 1.8.1.21_0000000000)
Packets Lost: 12/1775 (0.7%)


jacolyn mathy added a comment - 21/Jun/09 04:14 PM
Happening to me too, details below, screenshot attached above.

Second Life 1.23.4 (123908) Jun 11 2009 15:16:56 (Second Life Release)
Release Notes

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)
Second Life Server 1.26.4.120562
Release Notes

CPU: Intel Core 2 Series Processor (2400 MHz)
Memory: 3326 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8800 GT/PCI/SSE2
Windows Graphics Driver Version: 6.14.0011.8585
OpenGL Version: 3.0.0

libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24817 (Mozilla GRE version 1.8.1.21_0000000000)
Packets Lost: 76/124388 (0.1%)


Chandra Meehan added a comment - 21/Jul/09 01:36 AM
Update at least on the part of prims vanishing and a workaround for that:

------
This notecard will let you know what to do if you happen to experience the "missing prims bug", which was introduced in the 1.23 viewer (but according to LL's JIRA will hopefully be fixed in one of the upcoming releases).

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.
2. Select "Debug Settings" near the bottom.
3. In the blank space, type or copy and paste the word:

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!

---------------
Thanks to Minke Bailey for adding that info to one of her products in world. — it's been as well discussed at http://jira.secondlife.com/browse/VWR-13868


Ann Otoole added a comment - 01/Aug/09 03:52 PM
The defect seems to only affect flexible prims in Snowglobe 1.1.2 (2584) Aug 1 2009 09:40:23 (Snowglobe Release)

Sharron Schuman added a comment - 19/Oct/09 08:57 PM
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)
Built with MSVC version 1400
You are at 161389.4, 251290.5, 501.1 in Piazza Fibonacci located at sim3852.agni.lindenlab.com (216.82.52.10:13002)
Second Life Server 1.30.2.135876
CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (3807 MHz)
Memory: 3327 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 260/PCI/SSE2
Windows Graphics Driver Version: 6.14.0011.9107
OpenGL Version: 3.2.0
libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3
J2C Decoder Version: KDU