It also seems like the LOD is way too aggressive, especially if the vertices are not evenly distributed.

Sometimes a sculpt map will not completely load, period. Even if you stand there and stare at the object for several minutes, it will still have that "crinkly" look.

This is on a prim that's a few meters by a few meters.

It happens I guess for all (sculpt) textures, I have seen this happening to sculpties uploaded lossless and not-lossless.

The sculpty stays like a ball or lowres 8x8x8 model, untill you click on it or open the sculpt-texture and view that or sometimes when you change the camera. Waiting 10minutes for it to load at an almost empty skybox didnt seem to work.

10 rezzed sculpties, all using the same sculpt-texture at different sizes, totally appear random, some show ok, some still as a ball/lowres model untill you click on it.

This one is really killing for the sculpty users and creators in general, a friend showed me this new cave she created some days ago, and i was right-clicking the different sculpties, to see if they were correct/loaded. Somehow you cant have that..

agreed, Cel. it's a very high priority for me.

The underlying texture-loading issue is unavoidable with the current technology since most graphics cards are underpowered, and most of us have much less than the optimal amount of incoming bandwidth. (Although I have seen some improvement over the years in the SL client's handling of those problems.)

Also, recently seen: multiple sculpts of same sclp texture UUID being moved and resized within a link set and one of them appeared low level of detail whilst the others were already at high level of detail for about a second. o.O Does this mean there is redundancy that could be avoided here (I'm guessing because I've not looked at any SL client code)?

(my machine is plenty fast enough, renders SL at 20 to 40+ FPS, bandwidth/latency no issue).

This issue does not only affect sculpties... it affects regular textures, and it has at least for a year or more.

I understand that the sculpty map and texture loading may be separate systems (unless... the sculpty system uses the texture system to load maps?).

But have you ever stood at a small store and clicked a vendor... and watched it take more than a minute to load a simple 512 texture? 10 minutes?

Ever TPed to a sim and had textures 100m away rez just fine while textures right next to you are not rezzed yet?

This isn't a sign of lag. It indicates critical design flaw. Solution: re-examine the entire texture / sculpt map loading system and if necesssary, re-work it from the ground up. It's a mess... and it's a CRITICAL mess. Texture loading affects everything from merchanting to general in-world experience. It is more than top-priority... it should be considered a SHOWSTOPPER. People who get tired of textures not loading, stop shopping... or log off entirely and never come back.

The texture issue has been reported for a very long time and still is not fixed. Considering the importance of basic texture loading to the system, I would have to wonder why some programmer isn't in there with a magnifying glass and a fine-tooth comb... or even more appropriately, why a systems analyst hasn't pulled out the original flowcharts to check for logic bugs.

Basic matrix algorythm concepts: rez the closest textures first. Rez them fully, then move on. I would think the user would be best served with a matrix spiral: take the 9 blocks surrounding the avatar, rez those textures first, then begin spiraling outward. If an avatar touches a texture (or clicks a device which causes a texture to load) give that texture loading top priority, because it's the center of avatar focus.

Plain truth: there is absolutely no reason or excuse for an avatar to have been standing in the middle of a store for 30 minutes, click on a vendor, and have the texture take a full minute to load. That texture should load with all available speed. I have literally been in sims where I'm the only avatar there, stopped at the only store on the sim, clicked on a vendor, and had... the... texture... take... forever... to... load...

That's just wrong. It's detremental to the system in general. It's frustrating to the end user. It's right in there with user crashes and sim crossing as far as levels of irritation goes... which means IMO, it should have top priority in getting fixed. Having this problem continue for more than a year is (forgive my bluntness) inexcusable. It's harmful both to SL and its users (especially merchants, who rely on texture loading to sell their wares-- and it's extremely frustrating to the shoppers who are trying to buy those wares).

To be perfectly frank, It needs fixed... now.

I feel your pain about textures taking ages to load though But that is a separate issue.

Anyone know for sure how sculpty map loading is tied in / not tied in to the texture loading system? If it's tied in, it could very well be a related incident.

As far as this happening only since Windlight, sorry, but I noticed sculpties failing to load properly long before that. It's not a new "just since Windlight" issue. Been a problem ever since sculpties were introduced... which means it could very possibly be tied in to the very-similar textures failing to load issue. Dunno. Only LL would know for sure.

It doesnt seem to do with loading time at all, since my sculpt-image is already fully loaded and show correct for most of my sculpties, but some of them are rendered 'wrong' like a ball or lowres shape, untill I (right) click on them, and they instant show correct. It happens faster for megaprims, but seen it happen for the larger/almost 10m sculpties as well.

Selecting them does nothing unless I select the object tab, and then it immediately shows at proper quality. I am not sure if this also happens for other people's sculpted prims, but it does for ones I have access to on the object tab.

This is really bad.

1. Sculpties do seem to take longer to load, but this has been explained since its caused by the fix for the lossless bug

2. Rightclicking a sculpty going into edit mode and clicking on the sculptmap seems to make the sculpt load fully much quicker.

3. Sometimes two or more sculpties which have the same sculptmap applied, rezz differently, one rezzes good, other stays in half loaded state, or doesnt load at all till you click it. And clicking one will make all the other sculpties that have the same sculptmap rezz good instantly too.

4. Once all the sculpties have loaded fully they sometimes get borked after falling back in lod, that is they dont take on there normal shape until step 2 is repeated

Second Life 1.20.15 (92456) Jul 18 2008 10:58:42 (Second Life Release)

You are at 282088.0, 266056.6, 595.6 in Helmudhoe located at sim2771.agni.lindenlab.com (216.82.19.14:12035)
Second Life Server 1.23.4.93100

CPU: AMD (Unknown model) (2407 MHz)
Memory: 4095 MB
OS Version: Microsoft Windows Vista Service Pack 1 (Build 6001)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8800 GTS/PCI/SSE2
OpenGL Version: 2.1.2
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.16883 (Mozilla GRE version 1.8.1.13_0000000000)

This occurs so regularly that it is an everyday, recurring problem. Especially for me, my builds and my home both contain sculpts which make them use fewer prims and tax system resources less than primitive-only builds.

If sculpted prims are going to properly mature and contribute to SL the underlying infrastructure for them needs to be designed to perform more acceptably. Given that many of the sculpt maps I see failing to load, or loading extremely slowly, are quite small in size compared to visible textures, it's a severely bad indicator that they might take several minutes longer to load than a 512 or even 1024 square-pixel texture which is in the the same proximity to one's avatar. A 512x512 texture on the surface of a sculpt might load for me acceptably fast, and leave me waiting around for a bizarre period of time with the 128x128 sculptmap loads, taking longer to load on its own than the visible texture took to load in parallel with other things competing for bandwidth. I don't think anyone could argue against that being a clear indicator of an issue, it's downright bizarre and illogical.

Having to wait for an illogically long period for raw shapes to load, long after much of the other nearby content has loaded, artificially disrupts the flow of things to enough of an extent to take it seriously. It also makes some content-makers (such as myself) have concerns about using sculpts in situations where they would otherwise be inarguably the best option to use.

Not to look good news sideways, but is there any chance that the sculpty bug was related to whatever it is that's causing textures to rez so slowly (such as 20+ seconds for a single photo to rez?). Have been kinda hoping thats a related issue and you could kill 2 birds with one stone. If not... that is one of them I'd love to see Qarls skills applied to... because you seem to be the one knocking down the JIRAs one by one. Woot! : )

Now if we could only just be able to have other features with sculpties like to be able to make them hollow and solid to where the physical edges match the scuplties surfaces. Also flexi scupties would revolutionize the hair industry.

Now, the data doesn't even download at all; selecting the sculpt doesn't do anything. Only opening the object tab to display the sculpt map (or having the sculpt map load as an image) resolves.

Quick replication/testing of this bug is to log into the sim Sculptomancy. Stand-alone testing would involve using the sizes of the sculpts shown below (viewable at sculptomancy) and testing loading.
Sculpts that this bug affects almost always: all the trees (32x32x40), fins of airship (20x20x.5), airship motors (3.455x10x1.908), yellow spiral stair railings (9.900x9.900x10), brown spiral stair railings (6.000x5.980x10). Based on this trend, it seems highly likely that this bug is triggered most often when one of the axis of the sculpt is 10 meters or higher, though I've also heard that some other sizes are affected, especially small sculpts.

Edit: forgot to mention Im using 1.21 RC0, and this happens to different/random sculpty attachments after each cache clear

the problem was 128x128 sculptmaps. we did a little optimization which caused them not to load fully. make sure to verify that it's fixed in RC1 and let me know.

I have a hotel built for me by my estate manager that uses sculpted prims and it has the same problems. The windows, doors, stairs, and other sculpties are messed up. Will this ever get fixed or should i ban sculpties from use on my land (a drastic action i know considering how advantageous they would be to use).

Richh

but be warned - we do get a lot of comments like "this is easy to fix, you're stupid" followed by NO suggestions for how to make things better. most times i personally ignore those as hot air. as Linus Torvalds says, "put up or shut up."

I spent my life coding. I never, ever, left a bug unchecked (not even once) for any period of time, no matter how complex. I worked on it and traced it down until it was fixed. No excuses, no complaints... and I most surely did not ask other people to do my work for me. I was the coder, I fixed it. That's what I was being paid to do. A coder who says he can't fix a bug is a coder asking to be replaced by someone more competent.

We don't have access to Linden Lab's internal structure. Having the source code is only PART of the issue. It tells us little or nothing about how the hardware, network and asset side is set up. And even if we did...

We are not being paid by Linden Lab, Linden Lab's customers or anyone else to do your work for you. It's your job-- and the job of other coders at SL. It is not mine, nor anyone else's responsibility to do Linden Lab's debugging and recoding for it. Linden Lab charges $295 a month to rent a piece of virtual land. At those prices, the company has no room for making excuses... nor for asking customers to do their work for them. Again please don't take this personal... but you issued the challenge. I'm issuing a demand right back at you and all other Linden Lab system designers / coders: do what you're being paid to do.

The reason we say these things aren't all that hard is because of several reasons: Other companies do this regularly, without the years-long bugs. They aren't whining or making excuses to their customers. They get it done.

As a PRIME EXAMPLE: the case of TEXTURE TRANSFERS. Linden Lab already (supposedly) knows the cause of the problem: using UDP to transfer textures (I think there's something else going on that LL isn't telling us about, but there ya go. At least changing the protocol should have some kind of significant benefit).

You folks wrote a whole blog on the problem. That blog stated that yoru company was aware of the issue, and it was on your "top priority list". Well... where's the fix? Just how hard can it be to change a simple transfer protocol? One day job? Two days max? How about two hours? You find the texture transfer routine (which should be well-documented), you delete it and replace it with the new transfer routine, you test and release. It's not rocket science.

Now I admit getting the sculpties to finish loading might be a bit more complex than fixing the texture transfer routine, but that's not the point. The point is the attitude that has allowed the texture transfer problem (and other major glitches... group chat... group notice delivery... teleports between regions) to go on for YEARS unchecked and uncorrected. If Linden Lab can't manage to fix a simple texture transfer bug... how can it hope to solve the sculpty problem?

Sorry folks, I ran a corporation and my own business for years. I don't mess around when it comes to employees telling me they "can't" do something or telling me how difficult it is. "No excuses" is the policy of most successful businesses. If something really is legitimately hard, I'll give folks all the time and assistance they need. But when it gets way past the time to expect results... then way past THAT time... that's when the bam hammer comes out. I've replaced more than one person for incompetence and I've chewed more than one manager for company-destructive attitude.

These kinds of problems have gone on for years. I don't expect every problem to be fixed overnight, but I do expect major problems to be fixed with all expected haste and determination. Linden Lab introduced sculpties into the Second Life platform. Your problem, not ours.

So as the founder of a group with eight sims, a group paying Linden Lab over $1,200 a month for computer servers, I think I (and thousands of others) have a right to make this demand: FIX THESE THINGS NOW.

It's not an unreasonable demand.

I'm a coder, aswell, fixing a bug is very easy, if you know exactly what is causing it, Qarl has lots of other things he does, rather then one little bug, so he can't be like you, and spend 100% of all of your time to fix something, when there is more important things to do

>> "The point is the attitude that has allowed the texture transfer problem (and other major glitches... group chat... group notice delivery... teleports between regions) to go on for YEARS unchecked and uncorrected. If Linden Lab can't manage to fix a simple texture transfer bug... how can it hope to solve the sculpty problem?"

Texture transferring isn't broken, not by far, it's worked for me for all of the years that I've played, as far as your 'glitches' that are not acctualy bugs, just load issues, If your wearing 500 prims, and 200 scripts, your never going to be able to teleport, never had a problem with group notices (I am not a part of a group that sends them), and only time group IMs ever get bad, is when there is 100+ people inside of the group, all talking at once, for a skilled programmer, you sure are ignorant mr wishbringer...

Furthermore, the broad issue with image load times has to do with the way SL deals with images, and assets in general, which is a huge issue. To make this better, it will require an entire rewrite of how SL stores, saves, and transmits images. If I recall correctly, this is something that is going to be worked on very soon, as well as the way SL works with assets. More information can be found in this blog entry, which details the basic problems SL has and the focus upon them: http://blog.secondlife.com/2008/09/12/frank-ambrose-updates-on-the-second-life-grid/

SORRY FOR OFF TOPIC but I feel strongly about this: Wayfinder, this is a place for people to communicate aspects of bugs so that they can be addressed. I would expect nothing less than a concise and professional tone (especially from someone who says they're a coder!). If I wanted to read full-page rants I'll call you. Qarl is not being unreasonable by getting any developers/testers watching this to help look into it. It's called teamwork and that is a commendable attitude. If you wish to continue this line of discussion about your "bam hammer", take it elsewhere please.

https://wiki.secondlife.com/wiki/Issue_tracker

Note: The Second Life Community Standards apply to all areas of Second Life, including the Second Life Public Issue Tracker. Any Resident who disregards these guidelines may be banned from future use of the issue tracker.

Examples of specific behavior or actions which may result in removal from the Issue Tracker:

• Flaming - The act of posting a message that is intended to incite anger or directly attack a person or persons is called "Flaming" and it not appropriate for the Issue Tracker. Please keep to the facts of the issue at hand. Posts that disregard this may be deleted.
• Private Discussions - Blogging your personal opinions or off-topic rants. Pjira is about finding solutions to issues. We love productive feedback. Please stick to the technical details of the matter at hand.

Linden Lab's new Senior VP realizes that both positive and negative comments are assets to the company. We are finding more and more people on this JIRA that are voicing extreme dissatisfaction with the way Second Life is operating at this time. A lot more people are voting with their feet (as I'm sure you folks are aware). FACT: LL recently lost 7% of your paying user base. Another 8% of the total residency ceased using Second Life over the past 4 months. There are reasons that is happening. Issues such as the one posted in this JIRA are part of it. It's not that people are going to leave SL because sculpties aren't loading correctly. But it just adds to the overall negative experience that IS responsible for so many people leaving the platform. That should be of concern to us all.

For the record to all that replied: Qarl is a decent guy. And I like he way he personally responds to customers. That's why I told him this was not a personal issue against him... but rather the entire corporate performance and the operation of Second Life. However, challenging customers will do one of two things: they'll either step up to the challenge and cause the company to lose face. (I mean.. what if someone did step in and solve the problem? How would that make Linden Lab look after all these months of not being able to solve the problem?). Alternately those customers start mentioning business responsibilities and facts... which is what I did. Qarl challenged us to put our money where our mouth is. Frankly, I believe at $1200+ a month, we ARE putting our money where our mouth is. It's not our job to to fix LL's problems. We pay LL to fix the problems.

Moy, you call me ignorant. Sorry you feel that way. However, before you start flaming and labeling other people, I recommend you fully understand what you yourself are talking about. You state that texture loading is not broken, that it's just "load issues". Dan Linden provided statistics in another JIRA post that only 5% of the texture loads on SL perform in less than 20 seconds. 80% of all texture loads take 30 seconds or longer. Some textures NEVER load. I'd call that broken.

You further state, "If your [sic] wearing 500 prims, and 200 scripts, your [sic] never going to be able to teleport." Of course we are Moy. People do so every day... just not conistently. I myself have an avatar with 401 prims and a 227 button hud that succeeds in teleports regularly. But just as regularly the teleports fail. Teleporting from one region to another as a concept is not complex; it follows any standard data transfer protocol. You store contents. You transfer the identity. Then you transfer the contents, which are then implemented by the new server. It should be a simple data transfer. Yet teleports have been failing and people have been crashing on teleporting for five years... and after five years it's still not fixed.

"only time group IMs ever get bad, is when there is 100+ people inside of the group, all talking at once". LOL Moy, the larger the group, the more it needs chat. What, we're supposed to limit our groups to 100 members so that chat will work? As a point: I don't think I have ever seen more than 30 people chatting at one time in a group chat. I've seen chat break down when only 2 or 3 people are chatting. So what does the number of people in a group have to do with anything?

Chat rooms have successfully handled chat from all over the world for over a decade now. There's no reason it shouldn't work on SL, no matter how large the group. So next time you decide to flame someone and call them ignorant on JIRA, perhaps you'd best first remove the rafter from thine own eye... and then just don't.

Aminom, I agree with you that Qarl is a dedicated an open person. Like Dan and Prospero, he has the guts to get on this website and talk to people. That doesn't mean that as customers, we have no right to point out that SL is borked an to demand better performance. I know he's trying. I know he's probably got more on his plate than any coder should have. That's why I'm not blaming Qarl. He's likely caught in the middle between customers and corporate policy. I am stating however, that BUGS ARE NOT GETTING FIXED WITHIN REASONABLE TIME. That fact should be pretty flippin' obvious. Whatever it is that is getting in the way of SL bugs getting fixed and getting fixed withing respectable time, needs to be changed.

You stated, " the broad issue with image load times has to do with the way SL deals with images, and assets in general, which is a huge issue. To make this better, it will require an entire rewrite of how SL stores, saves, and transmits images". I'm sorry, but this is factually incorrect. Linden Lab themselves have stated they know exactly what the texture problem is and it is known how to correct it. It doesn't require an entire rewrite; it requires replacing a UDP transfer protocol, as I factually stated above. Now, how SL stores textures and accesses those textures is another matter entirely and may also be part of the problem (I suspect it is). But as for textures taking 20, 30, 40 seconds to load... Dan states that could likely be reduced to under 4 seconds by replacing the UDP protocol with more effective and very standard HTTP. That protocol is already written (the world wide web is largely based on it) and in use for years now. Thus, we have the question of why this hasn't already been implemented. Changing a simple protocol is NOT all that difficult. Usually a proficient coder can do that kind of thing in his sleep.

Timeless... sorry you don't agree with me. If you believe that customers have no right to bring issues regarding SL both to Linden Lab and the public... ESPECIALLY on this JIRA (which after all, IS where issues and problems are supposed to be discussed) then we'll just have to disagree. Some may disagree with me, but it's my belief that JIRA is a place not only to state technical problems, but the DEGREE to which those technical problems are affecting the grid. Sometimes that degree is manifested in customer outrage... as is very apparent all through the JIRA. I am not the only person that has posted such things on the JIRA. In fact, such are pretty easy to find. In fact, when I presented a recommendation to place an "abuse report" button on JIRA messages, 100% of the users responded that "heated discussions" often occur, and thus they were against such an option. JIRA discussions get heated on quite a regular basis. Why? Because SL isn't a game; it affects people's lives.

Linden Lab themselves have stated this is not a game. Thousands of people are HEAVILY vested in Second Life. When it doesn't work properly, it can actually affect people's financial welfare; ask the hundreds (thousands?) of merchants who have been ruined by Second Life problems. Ask the real estate people who have lost their shirt on land investments. Since Second Life ISN'T a game... Linden Lab is responsible to their customers to see to it that the system operates with an expected degree of proficiency. That means fixing bugs in a timely manner and not making excuses.

I haven't attacked Qarl in any of this: I answered his challenge directly, in a business manner. I stated WHY I answered in such a manner. Everything I said is factual and true and to the point. You folks may not like that it's being said... but that's what freedom of speech is all about... and that is the way Corporate business is handled throughout this country. If someone isn't doing the job, you don't stand around and say, 'Awwww... that's all right. We understand it's not easy." And you don't give them infinite time to get the job done. No, you tell them what's expected, what they're not doing right, you give them a time frame and then you leave it in their hands. If they fail to get it done within that time frame, that's when the axe comes out. That's how business works: get the job done or else. Welcome to the real world.

Linden Lab should be glad that I and others are pointing these things out without beating around the bush, because if we don't and these things go unanswered, the future of Second Life will be endangered (in fact imo, they may be already too late getting on the ball). We've been the ones that help keep Linden Lab on its toes. You think bugs aren't getting fixed properly now... what do you think would happen if the wheel stopped squeaking?

Btw, since someone did quote Senior VP Frank Ambrose in a previous message, I will be contacting him and referring him to this specifric JIRA post. He seems like a sharp person who is interested in getting SL up to snuff... and I think this particular JIRA points out some major issues that should be brought to his attention. Maybe he can get down to the root of what's causing simple bugs to go for years without being fixed and put an end to that serious problem.

The texture issue has been going on as long as I've been a member of SL and prior to that (since SL was implemented, actually). It's gotten worse, not better. Just how long are customers supposed to wait, how long do we tolerate "this is a tough bug"... before patience runs out and we start getting tough? If it had been 2 or 3 weeks I'd say sure... some things take time. But 6 months? (Over four years in the case of the texture issue).

I think that is a bit beyond what most people would consider acceptable for a major bug to continue. It's messing with people's SL lives and it's messing with their investments... and that's why people are upset.

1) you'd mentioned another sim where you see the problem - can you send me a landmark to the position?

2) in the new 1.21 RC2 client is a debugging setting. under the Advanced menu, look for Rendering->Info Displays->Sculpt. turn that on and you should see a bunch of numbers above each sculptie. take a picture of a broken sculptie (with its numbers) and send that to me.

3) in the Preferences window, in the Graphics Tab, with the Custom box checked, set your Mesh Detail for Objects to "High". with this setting, take a picture of a broken sculptie and send it to me.

muchas.

JIRA isn't an opinion feedback forum, guys. JIRA is purely technical and task-oriented. This is where you're just supposed to go "hey, I encountered a bug, this is the info I can give to help you fix it", or "hey, I think SL would benefit if we improved/added this feature, here's my suggestion", as well as a place for people to voice how much they care about certain bugs (by voting).

Feedback here should just be to-the-point and focus solely on helping to fix or improve things. Opinions don't really fit in here, they don't help people progress toward a solution, and there are other places where opinions are meant to be discussed. Please don't do too much of it here? If anything it really just gets in the way. It's that much more text to have to skim through, looking for information that helps with the tasks at hand.

Please think of your actions on JIRA as being volunteer work, that's exactly what it is. We're volunteering our efforts to help LL by being here. We're here to help, not to editorialize. Please focus on the work that needs doing. We all know there's plenty, and never too many helping hands.

So I can see both sides of the issue, but presenting "just the technical aspects" doesn't really fully address the state of SL-- which not only includes the bugs, but how those bugs are affecting the community.

Nevertheless, I'll give thought to what you've said and WILL try to keep such to a required minimum. ; )

Qarl Linden has asked for additional information if the problem has reoccurred. At that time please reopen or open a new bug issue with that information. Thanks all!

i think what's happening is this: the fins of the airship have 256x256 sculpt maps. and when only 128x128 of that map is loaded, you get the distorted look.

but i honestly don't think i can recommend we load all of all 256x256 maps. that's almost 20x as inefficient as it should be (64x64.)

regardless - i agree with Ramzi and think the discussion should occur on a new jira - the original topic of this jira has long long expired.

the original problem (6 months ago, which was caused by sculpts not forming until LOD change) was long ago fixed.

this is a different bug which doesn't even match the description of the original bug (selecting has no effect, etc.)

a more accurate description of the bug being discussed here is:

"sculpts which use a sculpt map of size greater than 128 experience distortion. sometimes."

The actual issue... sculpt textures not being applied until they are selected... is not fixed. It is certainly possible that one possible trigger for the problem has been fixed, but it's clear that there are other situations (which may well include cache or network problems) that can trigger the same underlying problem.

My network speed slider is generally set to minimum, to keep my DSL from having a hissy-cow. I have changed it to match my DSL's nominal rate (256k) and slid it up to maximum (which my DSL allows for a short period) and the result is the same. I have not seen this after clearing cache, but I have only tried that a couple of times and since relogging can change the behavior that's not particularly useful information. It does seem to happen more often when there are a lot of avatars around, though I don't know whether that's due to the avatars themselves or the fact that they often have many sculpted attachments.

I'm not saying that the main trigger for this problem has not been fixed. I'm saying that this specific problem, as described in this JIRA, still happens.

I understand Qarl's point regarding this new manifestation possibly being another JIRA issue, but know what my solution to that is? Qarl himself might need to file that JIRA rather than leaving it to the customers. Anything in the TOS that says a Linden can't file a JIRA report? If LL is aware a bug exists... that bug should exist on the JIRA.

But if as Argent says, he's tried the new release candidate and is still observing scultpy finish issues... then that may need to be researched. He's provided the locations and I'm sure, as much as he's online, he can be contacted by interested parties. Argent's been on SL some time and uses it a lot, and I'm sure he's willing to make himself available to anyone who wishes to observe this matter. All someone has to do is care enough to do so and go that little extra step necessary to insure this bug has (or will be) corrected. In RL that's called "going the extra mile" (or alternately, "putting in 110%") and it's what makes or breaks corporations.

If Argent is reporting these things still going on, then by all means someone should get with him and check that out. He's not a noob.

Anyway, I didn't mean it wasn't fixed in the RC, just that it wasn't fixed "a long time ago": if it was fixed in RC2 then it's only been fixed for a few weeks.

And if it's only fixed in the RC it should stay in "fix pending" state, not "closed".

unless anyone sees this exact same bug in the 1.21 or later viewers, please don't reopen this task.

if Aminom feels strongly that his new bug should be considered (but honestly, i think it's a hard sell considering the efficiency question) i hope he'll create a new jira.

I would be glad then
(i just do stuff i want.)

the problem is that it's exorbitantly inefficient to load these things. and for the record - they've never worked - we've always historically only guaranteed 128x128 maps.

AND - this is only to support legacy content, right? nowadays you better be using 64x64 maps.

if you guys really feel strongly about it - we can certainly call for the wider community to weigh-in and vote and whatnot. but i'll warn you - there are a LOT of people who are upset at how much lag sculpties already induce - they'll definitely poo-poo this extension.

But I would like to ask a question since you're the guy in the know.

How much lag do sculpties actually create? For example, let's say I make a standard prim sphere and a sculpty prim sphere. How much of a difference would it be for say a 64, 128 and 256 sculpty over a standard prim. Not my area of expertise, so naturally I'm curious. Thanks. : )

(And not to be rotten at all, but if sculpties ARE lag hounds, why did LL introduce them in the first place, considering how lag-ridden the platform already was? IMO that's kinda like punching another hole in the boat. I don't really expect an answer to this one of course, but just throwing it out there).

Once it was possible to upload sculpties lossless, and for complex sculpties, to bypass the lossless bug from happening; for months uploading them at 256x256 made them work and render always ok, it was the only work-around sculpt creators like me had.

I did a test today, I dropped 'the same' '256 and 64' sculpty onto 2 apples. The 256 takes about 2-3 seconds to render correct, the 64 one, took me almost a minute to load, render and show correct.

I know the 256 can take compressed like 5KB or more compared to the 64 ones, and currently converting and adding 64x64 versions for most of my sculpt work, I sell now.

It's more; a lot of 256x256 are on the market, have been sold, used in all kinds of builds, and I never had really problems with these, always rendered correct, untill the recent rc-releases it seems. I really would love to see the support for the 256 as well, untill everything works flawless.

again - if you (or anyone) feels strongly about this - do open a new jira for it. i'm not saying we won't do it - i'm saying we need to talk about it before doing it.

(but FWIW - the behavior of 256 sculpts has never changed - they work as well as they ever did.)

Sporadic Loading Problems with Lossless Sculpt Maps Greater than 16384 Pixels in Area

http://jira.secondlife.com/browse/VWR-9583

The reason why sculpts appear to cause a lot of lag is because in lots of things they are used very inefficiently. In objects that uses numerous sculpts, most often the 3D modeling rule of not modeling what is not seen is broken, with good numbers of polygons placed "inside" the object. For a lot, the idea is "take one sculpt sphere, deform it into this piece," rinse, repeat, and stack them together. Moreover, because a lot of people do not manage LOD properly, they use many more polygons than would be optimal to create a shape. You will always have people who will use sculpts to get around the 255 prims per attachment limit to add as much detail as possible, but you will also have those who use it to create things with good detail and less resource usage.

Sculpts, used at their best, will actually cause far less lag than similar creations made using prims. The efficiency isn't quite as much as meshes- but it approaches it for some applications, and the best practices for game mesh design are shared with sculpts. One example is repeated geometry. If the same mesh is used multiple times in the view, the graphics card will only need to build the mesh one time, and then it will instance it for every repetition. What this means is that all else being equal, two sculpts with the same sculpt map will be a bit more render light than two sculpts with different sculpt maps. Of course an added boost would be only one sculpt map taking up texture memory and downloading time.

Another factor in efficiency is how the polygons are used; ideally, one would only use the minimum polygons necessary to form a shape given the desired amount of detail; areas with tight curves would use more polygons, whereas flat areas would use little. With sculpts this is difficult to do because stretching polygons irregularly results in irregularly stretched texturing. However, there are ways of dealing with this, such as uniformly stretching all polygons by a certain amount and using matching rectangular textures, or compensating for the texture stretching by the way the texture is painted- ie working with stretching and polar (where the sculpt comes to points) distortion rather than against it.

With any user-created content, you will have a wide range of efficiencies in content. Sculpts not just allow for more shape variety, but also for greater efficiency if one seeks it. The new oblong sculpts allow for greater efficiency in sculpts, and when meshes are added, they will make it easier to create efficient content.