I wonder if this is an easy thing to do for LL. perhaps they should just load textures from small size to big size. Most sculptmaps would automaticly get loaded first then.

I don't think they should have first priority, though. geometry, and terrain should always be first. But sculpt maps should load before all "normal" textures.

Also, why are 128x128 lossless images getting screwed out of the deal in the fix proposed for this? That resolution was the original threshold decided upon when implementing lossless, and so any new rules regarding it should cover up to 128x128. Or maybe I just misunderstood and the fix applies to 128x128 and under AS WELL as 64x64. Hope so! =)

Shall we rename this Issue to "Sculpt textures load as if they would have a WAY too low a priority in the interest list." ?
or open a new entry for that ?

Because the effects described are actually visible by everyone who wants to see them.

quoting McCabe Maxsted:
"I hate sitting in a build full of textured spheres wondering when the sculpt maps will load"

Is there a follow-up VWR already ?

Possibly there is something unexpected going on with the interest list, or possibly there was something else going on preventing the sculpt textures from being displayed even thought they had actually loaded. Any thoughts there?

Perhaps the problem is that sculpts in attachments are not being loaded with other sculpts?

During triage, Gigs suggested decoding/downloading shape textures before render textures, for example. This would lessen the time those sphere are visible. Or there's the icosphere suggestion above, which I assume means an intentionally low-poly icosphere for coarse faces. If any of these appeal - make child issues?

"During triage, Gigs suggested decoding/downloading shape textures before render textures, for example"

This is exactly why this issue is here. Because as far as we were seeing, other textures were being downloaded first. And we were told this

Bridie Linden - 13/Mar/08 04:00 PM
Steve Linden explained that sculpted textures are already prioritized above everything except terrain, selected items, hud items, UI images, and avatar images.

So am I misunderstanding, or is one of you (soft or steve) mistaken?

The icosphere is for the seperate matter, of spheres showing while sculpts are loading, and I would not say it's relevant to this particular issue. This issue is about the TIME taken for sculpts to load. And I do frequently observe sculpts being textured while they're still balls.

If it's possible, prioritising them farther is definitely the solution. that's what this issue suggested in the first place, so I don't think there's a need for a child issue from it.

if someone can create a nice reproducible example which clearly demonstrates the problem - that'll go a long way to get LL to investigate the problem.

• Cear your cache.
• Visit Botanical (http://slurl.com/secondlife/Straylight/182/53/25)

• Expected: apparently sculpt maps have a high priority, so should load early.
  = Observe: you're surrounded by a field of fully textured spheres, as the textures on the spheres (and most everything else) appear to load before the sculpt maps do.

by way of example - i'm thinking of a large area with equally spaced sculpted prims - where each prim has a unique sculpt-map and surface texture. if we see surface textures loading before sculpt maps - then it's a done deal.

if the textures are used elsewhere in the sim, the sculpts should surely still load first, if they're prioritised.

when i TPed into straylight, i saw several tree trucks which had their bark texture - but not their sculpt texture.

what happened was that the bark texture is used repeatedly throughout the sim - it's possible it was on the very first prim my viewer downloaded. in this case, i understand why the bark loaded before the sculpt maps.

so we need a controlled experiment.

No, I'm not sure that there's a priority problem.

I am sure that there's a problem, because I see sculpties remaining simple spheres for long after everything else has loaded and been textured.

It could be an interest list problem - the sim seems to have a unique monotonically increasing internal ID for the prims in the sim, and pumps them out in that order rather than (for example) in order of distance from the agent or camera (again, this is supposition). This would tend to defer prims in attachments because they're continually recreated as far as the sim is concerned.

It could be a problem with the sculpties not being rendered even though the textures have loaded, as someone suggested above. I've seen that problem too, but there right-clicking on the prim triggers a refresh somehow and the prim "collapses" to the sculpt mesh. That doesn't explain the cases where right-clicking doesn't work.

It could be unique to sculpties in attachments. I have seen other problems with sculpt textures loading for attachments - for example my sculpted animated dolphin avatar has more problems being rendered than the same sculpt textures and scripts running in an unattached prim.

That's why I changed the subject of this Jira when I reopened it.

It is not unique to attachments.

Try CMP4 where the Sculptie Displays of this Springs Life2.0 Sculpty Day are.

Aminom Marvin, Anjin Meili, Cel Edman, Crash Prefect, Xenius Revere, Yuzuru Jewell and me have set up stuff there.

One observation:
Small Sculpt-textures suffer most !

My Sculpties there are all lossless 64x64 (which to my understanding should be optimal)
Most other sculptors there tried to work against the current issues and use larger sculpt-textures.

But at Cel Edmans Display you can also see the black-red ziggy-zack column suffering the same problem like my sculpties.

Go there ... see if / how sculpties load .... clear cache .... and try again.

I just retested it with 1.19.1 RC2

• Rez a build platform up in the air away from all sources of lag.
• Rez a series of sculpted apples each 5M away from a box.
• Texture each apple something different. Don't use any textures that can be found in the sim itself.
• Sit on the box, clear cache, and log out.
• Login.

• Observe: along the row, the prim textures each sequentially load. Once all the textures load (i.e. you have a long row of different textured spheres), the sculpt map loads, and all the textured spheres turn to textured apples.

This is definitely not unique to attachments.

http://slurl.com/secondlife/Areumdeuli/122/81/189

There is a globe made out of hundreds of sculpted prims, each with its own model and visual texture. With 1.19.1.2 I'm seeing most visual textures load before the model textures.

"I hate sitting in a build full of textured spheres wondering when the sculpt maps will load"

and

"128x128 Sculpt Textures load faster than 64x64 Sculpt Textures"

have a common cause here.

Would it be possible to organize a special Sculptie-Fixing office hour with:

Qarl Linden (Sculptie Guru),
Steve Linden (Texture Pipeline Guru)
and other Lindens working around sculptie-rendering or GUI integration for sculptie-support (Upload preview for example) ?

In http://jira.secondlife.com/browse/VWR-5647 a Meta-Issue has been opened to summarize current Sculptie-Problems.

One observation that is depressing many Sculptors, is the fact that the current state of investigation, fixing or when to expect the deploy of a fix is totally unclear in most cases.

Anyone who is a bit familiar with the Sculptie-community in SL will see that the list of voters on these Issues reads like a who is who of Sculptie tool developers and Sculpt Savants.

We are all willing to help in any way possible to get some progress on these Issues !

Please take into account that you have access to a group of people (look through the voter-lists) that are willing to help you on this for free
and actually know more about Sculpties than most Lindens (no offense).
Some of us are enthusiasts that have been spending most of their SL-time, which in some cases is RL work-time, with Sculpties since they hit the grid.

The goal of the suggested special office hour would be to improve communication between relevant Lindens and the community around Sculpties as well as communication between Lindens that are normally working in different departments (it seems ... no offense) to come together to focus on Sculpties for a second.

Please at least think about it ... it is only a suggestion ... but i think i have a valid point here that needs to be addressed in some way.

I could justify saying the same in more angry words, due to the time this has been going on by now. But would it help ?

Previously, with max render and draw distance settings, a sculpt mesh would have a high LOD at reasonable distances that were tens of meters away, which was more effective and realistic. Having the LOD reduce at these low distances looks very unattractive and needs to be remedied.

http://jira.secondlife.com/browse/VWR-1815?focusedCommentId=60343#action_60343

There's also some patches that may fix this. I haven't had a chance to really test them out yet.

the fix for VWR-5785 is going a LONG way toward fixing this bug. i just dropped my net-speed to 50 and teleported to straylight. it took a good 15 minutes for the sim to rez. as it was doing so, i NEVER saw a spherical sculptie covered with a loaded texture - the sculpt texture always loaded before the surface texture.

i don't want to say this issue is completely fixed - but now i need more repros to test against.

It might be irrelevant at this point, but did you try out Michelle2's patch in VWR-1815? That works really swell for making them load fast. Been using it for a while.

i did talk to Michelle about her patch - it had two parts. one part is already in the fix for vwr-2404, and the other we agreed would be best put into the server side. i'll be doing that work tomorrow.

When selecting a sculpt texture to create a sculptie prim, it takes close to 5 minutes for it to load. Looking at the texture loading menu (CTRL+Shift+3 ) the download bar slowly creeps to completion.

I also notice after being logged in for a long duration 3 hour, sculpties that rendered properly before get out of wack. Panning the cam around it, zooming in and out seems to make a
I've done the standard clear cache and relog numerous times with no effect.

Second Life 1.21.2 (95596) Sep 3 2008 14:52:15 (Second Life Public Nightly)
Release Notes

You are at 156616.8, 279348.0, 23.8 in Moirae located at sim4690.agni.lindenlab.com (63.210.159.86:13005)
Second Life Server 1.24.4.95600
Release Notes

CPU: AMD (Unknown model) (2210 MHz)
Memory: 2559 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8600 GT/PCI/SSE2/3DNOW!
OpenGL Version: 2.1.2

libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3
J2C Decoder Version: KDU
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.17883 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 135/246363 (0.1%)

Sculpt priority: Low [ =======> ____ ] High

Second Life 1.22.11 (113976) Mar 6 2009 16:05:03 (Second Life Release Candidate)
Release Notes

You are at 241049.5, 273941.1, 22.1 in Sunbeam located at sim2102.agni.lindenlab.com (216.82.16.107:13002)
Second Life Server 1.25.6.113484
Release Notes

CPU: Intel Pentium 4 (Unknown model) (2800 MHz)
Memory: 1022 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 6600/PCI/SSE2
OpenGL Version: 2.1.2

libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.22982 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 0/123985 (0.0%)

Second Script code:

list maps= ["8d14c42f-ce96-2c58-dc12-b7a9e9b45027","98a1f0ff-26b3-9374-6efc-76108b39ddf6","e6d61de2-9315-ca9f-9267-de2dc53fdd0e"];
integer count = -1;
default
{
state_entry()

on_rez(integer x)

// touch_start(integer x)
// { // llResetScript(); // }
touch_start(integer x)
{
count = count+1;
if (count>(llGetListLength(maps)-1))

llSetText((string)count,<1,1,1>,1);
llSetPrimitiveParams([ PRIM_TYPE, PRIM_TYPE_SCULPT,llList2String(maps,count),PRIM_SCULPT_TYPE_SPHERE]);
llSleep(5);
llSetTexture(llList2String(maps,count), 0);
}
}

On the above stated system with the with the above listed script i am able to readily repro this as the script is cycled through the maps( yes these are 'vortex vomit' maps except one is normal, because you need the 'high' detail to easly see the problem) you will see that some of the maps appear to 'snap' when the map is loaded to the texture of the prim. also you will notice on the 'normal' sculpt map that there are some 'odd' cuts on the coner spheres and those were not there when i first uploaded the map as a loss less image.

This problem occurs for me using the official SLV, Cool Viewer, and GreenLife Emerald Viewer. However, the Snowglobe Viewer works okay.