
|
If you were logged in you would be able to see more operations.
|
|
|
|
Environment:
|
CPU: Intel Core 2 Series Processor (2405 MHz)
Memory: 2048 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8800 GT/PCI/SSE2
OpenGL Version: 2.1.2
CPU: Intel Core 2 Series Processor (2405 MHz)
Memory: 2048 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8800 GT/PCI/SSE2
OpenGL Version: 2.1.2
|
|
| Last Triaged: |
15/Oct/08 10:23 AM
|
| Linden Lab Issue ID: |
DEV-22462
|
Replication:
1) Clear Cashe
2)Log into the Sculptomancy sim.
3) Give adequate time for all sculpts to load.
4) Enable the Sculpt Loading Debug feature by selecting Advanced->Rendering->Info Displays->Sculpt
5) Observe which sculpts have not fully loaded (one or more of the three values zero at high LOD) if any.
6) Repeat 1-5 by teleporting away and coming back some time later, or restarting the client (to enable cashe retrieval).
Expected Results: all sculpts load regardless of image size (eventually) as per the behavior in the client before Windlight.
Actual Results: sometimes, some sculpts that are greater than 16384 pixels plus (for example, 256x256 images) do not fully load unless viewed as a texture or viewed in the object tab of the edit window.
Clarification/History (Why loading of 16384 images is necessary):
Before the lossless bug was fixed, it was an absolute necessity to use 256x256 images for some sculpts, otherwise they would not load under any circumstances. The Windlight client introduced bug VWR-5785. This bug is fixed in RC5, but this new bug has popped up in its place. There is lots of legacy content that uses 256x256 images on the grid, and not fixing this would be unacceptable because it would break lots of existing content.
Efficiency Concerns: there are, at first glance, some issues with 256x256 images: at first glance, they seem as if they would be 16 times the file size as the ideal sculpt size, 64x64. However, due to efficiencies in how jpg2000 lossless compresses information, the file size is only around 3.8 times that of 64x64. I have prepared a sculpt loading test lot at http://slurl.com/secondlife/dearheart/31/227/600 that has a variety of sculpts uploaded in different ways, to compare loading times and file sizes. Finally, almost paradoxically, 256x256 images uploaded using SL Image Upload (which is one of the only ways used because the vanilla client does not allow that size) load faster than any sculpts uploaded via the vanilla client. This is most likely caused by differences in the libraries used (SL uses the commercial JPG2000 client, SL Image Upload uses openjpg.)
|
|
Description
|
Replication:
1) Clear Cashe
2)Log into the Sculptomancy sim.
3) Give adequate time for all sculpts to load.
4) Enable the Sculpt Loading Debug feature by selecting Advanced->Rendering->Info Displays->Sculpt
5) Observe which sculpts have not fully loaded (one or more of the three values zero at high LOD) if any.
6) Repeat 1-5 by teleporting away and coming back some time later, or restarting the client (to enable cashe retrieval).
Expected Results: all sculpts load regardless of image size (eventually) as per the behavior in the client before Windlight.
Actual Results: sometimes, some sculpts that are greater than 16384 pixels plus (for example, 256x256 images) do not fully load unless viewed as a texture or viewed in the object tab of the edit window.
Clarification/History (Why loading of 16384 images is necessary):
Before the lossless bug was fixed, it was an absolute necessity to use 256x256 images for some sculpts, otherwise they would not load under any circumstances. The Windlight client introduced bug VWR-5785. This bug is fixed in RC5, but this new bug has popped up in its place. There is lots of legacy content that uses 256x256 images on the grid, and not fixing this would be unacceptable because it would break lots of existing content.
Efficiency Concerns: there are, at first glance, some issues with 256x256 images: at first glance, they seem as if they would be 16 times the file size as the ideal sculpt size, 64x64. However, due to efficiencies in how jpg2000 lossless compresses information, the file size is only around 3.8 times that of 64x64. I have prepared a sculpt loading test lot at http://slurl.com/secondlife/dearheart/31/227/600 that has a variety of sculpts uploaded in different ways, to compare loading times and file sizes. Finally, almost paradoxically, 256x256 images uploaded using SL Image Upload (which is one of the only ways used because the vanilla client does not allow that size) load faster than any sculpts uploaded via the vanilla client. This is most likely caused by differences in the libraries used (SL uses the commercial JPG2000 client, SL Image Upload uses openjpg.) |
Show » |
made changes - 17/Oct/08 10:06 AM
| Field |
Original Value |
New Value |
|
Assignee
|
|
Qarl Linden
[ Qarl Linden
]
|
made changes - 17/Oct/08 10:23 AM
|
Assignee
|
Qarl Linden
[ Qarl Linden
]
|
WorkingOnIt Linden
[ WorkingOnIt Linden
]
|
made changes - 17/Oct/08 10:23 AM
|
Last Triaged
|
|
15/Oct/08 10:23 AM
|
made changes - 17/Oct/08 10:23 AM
|
Linden Lab Issue ID
|
|
DEV-22462
|
made changes - 17/Oct/08 11:33 AM
|
Description
|
Replication:
1) Clear Cashe
2)Log into the Sculptomancy sim.
3) Give adequate time for all sculpts to load.
4) Enable the Sculpt Loading Debug feature by selecting Advanced->Rendering->Info Displays->Sculpt
5) Observe which sculpts have not fully loaded (one or more of the three values zero at high LOD) if any.
6) Repeat 1-5 by teleporting away and coming back some time later, or restarting the client (to enable cashe retrieval).
Expected Results: all sculpts load regardless of image size (eventually) as per the behavior in the client before Windlight.
Actual Results: sometimes, some sculpts that are greater than 16384 pixels plus (for example, 256x256 images) do not fully load unless viewed as a texture or viewed in the object tab of the edit window.
Clarification/History (Why loading of 16384 images is necessary):
Before the lossless bug was fixed, it was an absolute necessity to use 256x256 images for some sculpts, otherwise they would not load under any circumstances. The Windlight client introduced bug VWR-5785. This bug is fixed in RC5, but this new bug has popped up in its place. There is lots of legacy content that uses 256x256 images on the grid, and not fixing this would be unacceptable because it would break lots of existing content.
Efficiency Concerns: there are, at first glance, some issues with 256x256 images: at first glance, they seem as if they would be 16 times the file size as the ideal sculpt size, 64x64. However, due to efficiencies in how jpg2000 lossless compresses information, the file size is only around 3.8 times that of 64x64. I have prepared a sculpt loading test lot at Dearheart 31,227,600 that has a variety of sculpts uploaded in different ways, to compare loading times and file sizes. Finally, almost paradoxically, 256x256 images uploaded using SL Image Upload (which is one of the only ways used because the vanilla client does not allow that size) load faster than any sculpts uploaded via the vanilla client. This is most likely caused by differences in the libraries used (SL uses the commercial JPG2000 client, SL Image Upload uses openjpg.)
|
Replication:
1) Clear Cashe
2)Log into the Sculptomancy sim.
3) Give adequate time for all sculpts to load.
4) Enable the Sculpt Loading Debug feature by selecting Advanced->Rendering->Info Displays->Sculpt
5) Observe which sculpts have not fully loaded (one or more of the three values zero at high LOD) if any.
6) Repeat 1-5 by teleporting away and coming back some time later, or restarting the client (to enable cashe retrieval).
Expected Results: all sculpts load regardless of image size (eventually) as per the behavior in the client before Windlight.
Actual Results: sometimes, some sculpts that are greater than 16384 pixels plus (for example, 256x256 images) do not fully load unless viewed as a texture or viewed in the object tab of the edit window.
Clarification/History (Why loading of 16384 images is necessary):
Before the lossless bug was fixed, it was an absolute necessity to use 256x256 images for some sculpts, otherwise they would not load under any circumstances. The Windlight client introduced bug VWR-5785. This bug is fixed in RC5, but this new bug has popped up in its place. There is lots of legacy content that uses 256x256 images on the grid, and not fixing this would be unacceptable because it would break lots of existing content.
Efficiency Concerns: there are, at first glance, some issues with 256x256 images: at first glance, they seem as if they would be 16 times the file size as the ideal sculpt size, 64x64. However, due to efficiencies in how jpg2000 lossless compresses information, the file size is only around 3.8 times that of 64x64. I have prepared a sculpt loading test lot at http://slurl.com/secondlife/dearheart/31/227/600 that has a variety of sculpts uploaded in different ways, to compare loading times and file sizes. Finally, almost paradoxically, 256x256 images uploaded using SL Image Upload (which is one of the only ways used because the vanilla client does not allow that size) load faster than any sculpts uploaded via the vanilla client. This is most likely caused by differences in the libraries used (SL uses the commercial JPG2000 client, SL Image Upload uses openjpg.)
|
made changes - 13/Nov/08 11:07 AM
|
Workflow
|
jira-2007-12-22a
[ 60084
]
|
jira-2008-11-14
[ 64348
]
|
made changes - 13/Nov/08 11:28 AM
|
Workflow
|
jira-2007-12-22a
[ 64348
]
|
jira-2008-11-14
[ 71924
]
|
made changes - 13/Nov/08 04:57 PM
|
Workflow
|
jira-2008-11-14
[ 71924
]
|
jira-2008-11-14a
[ 95946
]
|
made changes - 13/Nov/08 05:12 PM
|
Workflow
|
jira-2008-11-14
[ 95946
]
|
jira-2008-11-14a
[ 101425
]
|
made changes - 13/Nov/08 05:20 PM
|
Workflow
|
jira-2008-11-14
[ 101425
]
|
jira-2008-11-14a
[ 104668
]
|
made changes - 13/Nov/08 05:33 PM
|
Workflow
|
jira-2008-11-14
[ 104668
]
|
jira-2008-11-14a
[ 109625
]
|
made changes - 13/Nov/08 06:02 PM
|
Workflow
|
jira-2008-11-14
[ 109625
]
|
jira-2008-11-14a
[ 119759
]
|
made changes - 13/Nov/08 06:27 PM
|
Workflow
|
jira-2008-11-14
[ 119759
]
|
jira-2008-11-14a
[ 129094
]
|
made changes - 13/Nov/08 06:46 PM
|
Workflow
|
jira-2008-11-14
[ 129094
]
|
jira-2008-11-14a
[ 136327
]
|
|