However, the attached "rings2.bmp" uploads fine through the SecondLife client; I am not sure what triggers the failure in the SecondLife uploading. This would lead me to believe there is in fact an issue with uploading. If it was just a downloading issue, I would not expect to be able to remedy the problem with SLImageUpload.

THE FIX? - Clearing my cache and starting SL over again.

Then, they are fine. But only temporarily. So, is image data not being cached correctly?

And of course, this 'fix' doesn't apply to ALL sculptmaps, just a few that for mysterious reasons look good initially, then later appear distorted. ARGH!

1. uploaded a 64x64 tga using lossless compression
2. Save the image back to your HD (save image as...)
3. Load your original image and the newly saved tga into photoshop.
4. Copy and paste the newly saved image into a new layer on top of your original sculp map and set its blending mode to DIFFERENCE

This should produce a pure black image. You can take the color picker and swipe over pixels, while looking at the RGB values in the INFO panel. It should always be 0,0,0

Now the interesting part. If I save the tga from opensim, everything works. The color picker shows pure black on every pixel of the 64x64 image.

If I use the image saved from LL's server, the color picker shows some small differences using the color picker (eg, 0,1,0 or 1,0,0 etc etc). It's not pure black

So, according to this test, the SL client is actually uploading the image losslessly to the server (otherwise opensim's test would fail), but something is going wrong on LL's server side. Either the image data is not being stored correctly, or the sim is corrupting the data when it's sending it back to the client.

1. As I said, opensim displays the sculpt map correctly after uploaded then applied to the prim.
2. BUT... once I relog and view the mesh its lumpier (looks just like the version on LL's grid)
3. If I clear my cache and relog, the sculpt map is fine again.
4. If I relog again WITHOUT clearing cache the sculpt map is lumpy again.

So at least on opensim, clearing cache and relogging fixes it. On main grid a cache clear doesnt fix it.

Now its starting to look like there is (also??) a client/cache bug, since opensim will display it correctly after a cache clear/relog.

I'd be interested to know whether the textures people have uploaded are gradually losing bits :-P

The first image is my 3d model. The second shows you how the sculptie looks in open sim when you first upload it (this is the way it also looks after you relog and clear your cache).

The next 2 images display the buggy sculptie in both opensim and SL.

Clearing the cache fixes opensim but not SL as far as my testing goes.

This is starting to look more and more like a client side bug to me, since a cache clear will refetch the correct sculptie in opensim.

So, if you want your sculpties to look consistent, stick to LOSSY compression right now.

our SL clients and servers assume that all of our images are encoded the same way - and use this to optimize image transfer over the network. (it thinks to itself - "i need a 64x64 image - that should be about 64x64x3 bytes, compressed at 8:1, so i only need to download 1536 bytes.") this sort of heuristic occurs in the sim code, the viewer code, and the cache code, in different ways, which causes a variety of failure modes.

the assets on the server are in-fact intact and not degrading over time. you just can't see them.

short answer - listen to Funk: "So, if you want your sculpties to look consistent, stick to LOSSY compression right now."

I have heard some reports about slimageupload not displaying this problem. I havent run any tests yet but will try to soon. (ugh... now Im spending time beta testing instead of working and running my business)

Id like to narrow down why some of your tests come up perfectly lossless. It must have something to do with file sizes?

I'm thinking "nearest neighbor" upsampling in PS would be best for this so we arent introducing additional color info into the sculpt map.

If this works, using upsampled 128x128 images will be a good work around. Considering we are usually using bigger images for our prim textures, I guess it doesnt really matter about having a bigger sculpt map. Can't be any worse than the guy applying a 1024x1024 on his 0.01m prim jewelry

yes, exactly so.

meanwhile, one of the other lindens here suggested a good way to fix the problem - perhaps we'll have a full solution soon.

1. render a 64x64 sculpt map
2. copy the top row of pixels into the clipboard (the top pole - I actually clean it up as a solid color too so my pole is nice and centered)
3. downsample (nearest neighbour) to 32x32 (I clean up the bottom pole here too as a solid color).. youll also notice your top line/pole went missing. Thats why I copied it to clipboard
4. upsample (nearest neighbour) to 64x64 and paste back the top row of pixels
5. upsample to (nearest neighbour) to 128x128
6. I add a black alpha mask just so my sculpt maps dont show up in the object panel (this is optional)

I havent downloaded the file back from sl to do a difference test in PS though because sl renders the sculptie without those huge jaggies seen in my screenshots. It renders the same in sl and opensim regardless of a cache clear.

Thanks for that final little clue which helped me work this out

You could even make this a photoshop action quite easily (except for the pole fixing?) so it's automated

You are at 256323.1, 264102.6, 247.0 in Phasma located at sim391.agni.lindenlab.com (69.25.104.77:13006)
Second Life Server 1.18.3.71877

No fix appears to be present, problem still occurs.

this patch got hung-up in QA (due to issues unrelated to sculpties) and WILL NOT be apart of the 1.18.4 RC. we'll have to wait for 1.18.5.

very VERY sorry to get you all excited about it.

hands Qarl some extra-strength epoxy glue, hoping maybe that'll help hold the patch in place better

i have it on good authority that this patch has already been merged into 1.18.6, which is scheduled for an RC0 release on nov-29.

Thanks a millions tons for getting back to us, Qarl - glad to hear things are improving over there. :3

And regarding sculpties, I know people argue that 32x32 resolution textures won't work due to some 33rd-line issue, but considering I upscale my sculpty textures FROM 32x32 to something higher, and things work FLAWLESSLY, it leaves me a bit skeptical that that's true. It's impossible to know without trying.

16x16 seems okay.

I uploaded one 8x8 and it turned out a disaster. I uploaded it again, and while still bad, it wasn't a mess of garbage. I wasn't able to reproduce the error, but I was only willing to spend so much L. The UUID of that one is caaf3366-a3bc-e983-1ed8-fbd7f4c2a6ce

given that the majority of complaints have been addressed (i.e. sculpties can now be created with lossless precision) i humbly suggest we close this ticket and re-open as a new, much lower priority ticket.

Oh well.

Since the issue now seems to be migrating from one component to another, the most appropriate action would be to create a sub task for each component of the Viewer code that is affecting the issue.

It seems possible to repro the not-fully-loaded sculpty texture effect by going somewhere else very texture heavy, to the point that when one returns to the sculpty it needs to reload. Then it seems to fail.

Clearing cache and relogging at the location of the sculpty seems to make it load properly. Going to visit lots of large textures and returning makes it fail again.

I repeated the test with RC 1.18.6.2: Same results - texture looks perfect, I can edit the sculptie, rotate my
camera around it, etc. But when I zoom out far enough to activate LOD, the texture gets broken and never
returns to its correct state.

So, the questions are: Where they got so distorted, when it will be fixed, and most important - I know for sure,
that people are uploading perfectly sharp sculpties. How?

Im still using buckle-004-003.bmp for testing, which is attached to this jira

A relog fixes it though.

Refer to Lossless_Comparison_63RC.jpg

[On a side note, the 128x128 one always rez'd correctly before the 64x64 one did, due to progressive sculpt rendering, making me wonder if 128x128 is still preferable to use over 64x64 in practice despite the larger data size? Or is it that much larger in practice really, due to data compression on transmit, or while resident in memory? Your thoughts, Qarl?]

In the last months/viewer versions, clearing the cache solved it...but currently this seems not to be a working workaround anymore !?

Well, is there already a jira entry for this "sculptmaps are not correctly DOWN-loaded" issue ? Since this VWR-2404 is the "sculpties are not correctly UP-loaded"

These images are of the same sculpty, created by uploading the "buckle-004-003.bmp" provided above.

In one image the edge of the buckle that is under the buckle pin is bent inwards, and in the other image the same edge is bent outwards.

The only difference between these screenshots is that the camera was rotated around the object. Rotating the camera back and forth is enough to reproduce the inward or outward distortion.

The image distortion shown in these images is unlikely to be related to the texture cache or to re-logging, since the image always remained in view.

These distortions are likely unrelated to lossless compression.

(BTW, Sorry for adding three comments when one was clearly enough. This is my first time responding to a JIRA issue, so I hadn't realized that each time I upload an image the comment would appear as a separate entry.)

the vertices of the pin (due to the compression errors) have been rearranged so as to "reverse the surface orientation." this causes their frontsides to be invisible and their backsides to become visible (which is the opposite of what's desired, although it makes for neat hacks when done intentionally (i.e. cell shading.))

Personally, until it is reliable I cannot consider the lossless compression a viable feature at all. This is not merely a bug that crept in sometime after the feature was implemented. It has never really worked properly.

Tracking down the problem was not easy; it's taken numerous days of debugging.

The problem is in the LLTextureFetch::createRequest method, where it calls the LLImageJ2C::calcDataSizeJ2C method to estimate the "desired_size". The LLImageJ2C::calcDataSizeJ2C method includes the incorrect assumption that the file will be one-eighth it's original size.

I validated the cause by hacking the source code to force the correct file size of 2,185 bytes for the converted "buckle-004-003.bmp" texture. The sculpty now shows up as smooth as silk; no bumpies and no jaggies.

(This is a gross over simplification of the hack. I also had to dump a valid JPEG2000 copy of the image to disk and jiggle the file that was stored in my cache.)

I'm unable to offer a suggested fix; I don't know how to estimate the size of a JPEG2000 file.

I hope locating the problem allows you to identify the solution. I would not expect the solution to be trivial.

The JPEG2000 lossless compression is indeed lossless. Encoding a raw BMP image into the internal JPEG2000 format and then decoding it back to a raw image produces the identical image. There is no loss of image quality.

The server does indeed store the correct, lossless image.

The problem occurs when the client retrieves the image from the server or from the local cache on your hard drive.

The source code makes an incorrect assumption that the compressed JPEG2000 image will be one-eighth the size of the original image. The client stops downloading the image when it has read one-eighth the number of bytes that were in the original image. In some cases the JPEG2000 image is larger than one-eighth of the original image.

For example, the "buckle-004-003.bmp" image has 64x64x3 = 12,288 bytes in the original image. One-eighth of this number is 12,288/8 = 1,536 bytes. The client only retrieves the first 1,536 bytes of the texture. In this case, the actual compressed JPEG2000 image is 2,185 bytes. The last portion of the image is never downloaded from the server.

The image created by the client is distorted because the client has not retrieved the entire image from the server.

you are officially my new best friend. thank you for delving into the guts of our code.

but now i'm confused. the bug you found should already be fixed - there should be a special case in LLTextureFetch which checks for discard level 0. (this is a request for the full-rez version of the texture.) in this case, instead of using the broken calcDataSize(), it overrides with the filesize of the texture.

but if you don't see such a case - that means my fix never reached the light of day. (which would be supremely annoying.) let me check things on this end.

again - THANK YOU. THANKYOUTHANKYOUTHANKYOUTHANKYOUTHANKYOU.

K.

Server-side works correctly.

Main viewer 1.18.5.3 has the bug in its full uglyness (lossless on small textures always results in incomplete loading)

WL and RC viewers 1.18.6 and 1.19 based have the bug partially fixed (works alright when getting the texture from server ... )

Problem remaining in all Viewers: Loading lossless from cache

All props to Sheet Spotter !
Or is it Sheep Linden already ?

The source code for the 1.19.0 RC Viewer includes a fix for this problem, but as "Theblack Box" has already stated it's only a partial fix.

The steps to reproduce the remaining problem in the 1.19.0 RC Viewer are outlined below.
1. Create a sculpted prim based on the "buckle-004-003.bmp" attached to this JIRA. Leave the sculpted prim rez'ed.
2. Clear cache and log out.
3. Log in with the 1.19.0 RC Viewer. The sculpted prim will be displayed correctly. [Texture was downloaded from server.]
4. Log off, without clearing the cache.
5. Log in with the 1.19.0 RC Viewer. The sculpted prim is now distorted. [Texture was loaded from local cache.]

With the 1.18.5.3 Viewer the sculpted prim was also distorted after steps 1 and 3.

I recognize this as a tough issue. Qarl has already applied one great fix to ensure the whole texture was downloaded from the server. I hope solving the second part (loading the whole texture from local cache) will be easier.

I ran out of time tonight, but I will keep looking at the issue over the next few evenings.

New WindLight Viewer (79674)

It appears to me like the bug has either been fixed or the effects have been reduced dramatically.
Nothing enlightening to be found in the update-note thou ... can anybody confirm or contradict that ?

After some testing with Aminom Marvin and Cel Edman we are having mixed results.
Lossless images smaller than 64x64 still have the cache-problem everywhere. I didnt notice that because i always use 64x64.

But for some reason .... something changed in the effects this bug is causing since Windlight-79674.
On my computer (Linux amd64 Nvidia8600GS) i am no longer able to reproduce this error on lossless 64x64 sculpt images. They always load sooner or later fully for me now.

Other tests (on Aminoms and Cels computers) give different results. So we exchanged test-sculpties and i tried a 64x64 sculptie which causes trouble when loaded from cache (on Animons Computer) ..... for me this 64x64 lossless sculptie always loads sooner or later fully ... i am living with this sculptie for a few days now and didnt see it distorted for more than a couple of seconds while loading ever since.

Since Windlight-79674 release i am around these test-sculpties a lot ... all lossless 64x64 and all easy to see if fully loaded or not (all are made with degenerated surfaces, sharp & hard lighted edges ... etc ...)
And all of them ALWAYS load fully soon after login/arrival ... no matter if i have a cleared cache or not ...

My Setup:
Ubuntu Linux on an AMD64 with a NVidia 8600GS (512MB)
Using Windlight SL-viewer 79674

One possibility is that i am loosing it and am on my way to insanity (Which i cant exclude when it comes to this vwr-2404).

The other possibility would be that there have been some changes with "positive side-effects" on the impact of this bug.

Or is there a mechanism that checks if a texture matches a check-sum the server offers, AFTER loading the texture from cache ?
And reloads it from the server if it doesnt match ?

Just fishing in the dark here ... to sum it up:

I dont see the effects of this bug on my sculpties anymore since WL-79674 (all lossless 64x64 ... all easy to distinguish if loaded fully or not)

about textures smaller than 64x64 for sculpties - they are unsupported. i know some residents insist on using them - however they are on their own.

I can still repro by visiting the sculpties then going and flying around the mainland for 15 minutes then coming back. This is with both 64x64 and 128x128 lossless sculpties.

Second Life 1.19.0 (79674) Feb 8 2008 16:51:12 (Second Life WindLight)

You are at 189547.5, 240485.3, 63.2 in xyz located at sim3668.agni.lindenlab.com (64.129.46.179:13005)
Second Life Server 1.19.0.79368

CPU: AMD (Unknown model) (2400 MHz)
Memory: 2047 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce Go 7950 GTX/PCI/SSE2/3DNOW!
OpenGL Version: 2.0.1

so now we go back to Sheet's investigations. he's found the culprit in the cache loading code - now we need to think of a way to fix it.

If you create a lossless texture and convert it to a JPEG2000 file, you can put this image into your skins/textures/ directory with the naming convention <texture key>.j2c. I've attached such a file to this thread, a very precise stairway that ideally should have perfectly sharp edges, which makes it a good test subject since any little errors show up as rounded corners and other obvious artifacts. Once you put that file in the textures/skins directory, SL will load this texture from your disk instead of asking the server for it, much like it does with your land permission icons, and it won't delete it when you clear the cache. Since you know you have the whole texture on your disk, you know that you ultimately have all the data for it, which makes it an interesting counterpoint to the regular cache loads.

Since there's apparently a strong random element for whether a texture loads correctly or not, my assistant and I ran a number of relogs in a controlled, high-altitude, low-texture environment, loading twelve lossless sculpted textures per trial, clearing the cache each time (and loading very few other textures). Five of the 12 textures were saved in my skins/textures folder, and therefore did not go in the normal cache; I was trying to load 7 textures per trial over the network. My assistant did not use the skins/textures folder, and attempted 12 textures over the network per trial. Each login we would note the textures that loaded fully and those that did not load fully. The restults:

RC 1.19.0.2:
81/91 network loads were successful (89%)
17/65 "skins/textures" loads were successful (26%)

WL 1.19.1.80044:
43/120 network loads were successful (36%)

Notes:

• It seems like there has been an improvement between WL and RC, but not a complete fix.
• Lossless textures transported over the network, even when they load successfully, take an extremely long time to download, particularly when you consider their relatively small size. It was commonplace during these trials to wait for 90 or 120 seconds for the last couple tiny textures to load completely.
• When a texture fails to download completely over the network, it's also low-rez in the cache – in other words, the loss of detail isn't just a rendering problem.
• In our controlled, low-texture environment, when we stopped clearing cache to reboot, the textures invariably loaded correctly after they had been cached, although this is definately not the case when you load them in a more complicated environment. It's our theory that the failures in loading from cache have something to do with loading a number of textures all at the same time – if the overall load is low it's easier to get successes.
• It's also interesting that "skins/textures" loads try their best to load from the hard drive and decode simultaneously, in one giant chunk. Maybe this is a similar problem to the previous point: trying to push through a large number of textures at once causes failures?

In WL 1.19.0.79674 this error could not be reproduced as easily as in earlier versions.
WL 1.19.1.80044 is horrible in this matter.

If there is any meaning and consequence behind the priority given to a bug in this JIRA, I would beg for giving this Issue a higher priority.

Very glad to see a few other people here having faith in Sculpties

I'd also like to second the suggestion to raise the priority of this issue, particularly since it's been open so long. Sculpties have gained a lot of traction in-world, particularly in shoes and other character attachments, and these continuing irregularities make it very difficult to design products that look okay from release to release, especially objects that combine more than one sculpty, or a sculpty and a regular prim. It's unfortunate from the consumer's point of view that the shoes they buy today might be unwearable in the next release, and of course that's disastrous from a designer's perspective. Until this issue is resolved it won't be possible to realize anything like the full potential of sculpted prims, transcending their early "organic-approximate-only" design goals.

To confirm some information: My test results are similar to Ariel Erlanger's. Though there may be something to the cache loading, even a first-time load directly over the network can fail, suggesting that it's a deeper problem than that too. Testing this with friends, in the same world situation with the same sculpt maps, there seems to be no real pattern to who correctly loads a particular sculpt map or when, even with a clear cache. This has failed in both the RC (1.19.0 RC2) and Windlight (1.19.0.80044). Additionally, the sculpt map loading seems to fail at different points for different people, though most commonly it nears completion before completely halting.

It's also my experience that these transfers take an exceptionally long time. It can take several minutes before a full stall or complete and proper load for a simple 128x128 lossless texture, while a 512x512 lossy version of the same map loads in seconds. It's worth noting, however, that a fully loaded 128 lossless is far more accurate than a 512 lossy.

The problem I discovered occurs in LLImageJ2COJ::decodeImpl (in the file "linden/indra/llimagej2coj/llimagej2coj.cpp"). What happens is that when a decode is requested on a lossless texture with a desired discard level of 0 (meaning a full image), the OpenJPEG library sometimes messes up the decoding, and returns less-detailed layers in the raw, uncompressed image. Since the level that was actually received is never checked against the requested level, the image is assumed to have decoded correctly, the texture is considered completed, and the data that did decode is thus a lower quality than it should be, and no attempt is made to reload it unless the texture is removed from the viewer's list and subsequently reloaded (by teleporting away and coming back, for example).

Unfortunately I don't have access to the KDU library or the corresponding LLImageJ2CKDU class source, so I can't verify that the same problem is occurs there, and indeed the failure modes are a little different. If you compile your own viewer from source, using the open-source OpenJPEG libraries, you'll find that when textures fail to load completely they will often show up as smaller versions of themselves in the upper left-hand corner of an otherwise blank image, but that doesn't seem to happen in the commonly-available binary downloads (they just have a degraded quality without any geometry issues). I'm assuming that this is some cosmetic difference between the way the LLImageJ2CKDU and LLImageJ2COJ classes move the data from the library to the native LLImageRaw format or the way they resize the raw image. Also, though I'll describe my fix in detail, I'm not attaching a patch since the code will have to be rewritten for the KDU class anyway.

To fix this error, I basically just compare the discard level that OpenJPEG returns (one for each component) with the discard level that was requested. If any level is different (and one symptom of this decoding error is that sometimes you get back components with different discard factors in the same image) then I mark the decode as having failed and let SL re-request the texture. Eventually it does load correctly and fully. If the texture happens to be in your cache this doesn't take very much time. Conceivably this could create a situation where you keep trying to load the same texture over and over, only to have it fail each time, but I haven't actually seen that happen yet.

To implement my workaround, in the file "linden/indra/llimagej2coj/llimagej2coj.cpp", in the method "LLImageJ2COJ::decodeImpl()" I replace:

.
.
.
S32 f=image->comps[0].factor;
S32 width = ceildivpow2(image->x1 - image->x0, f);
S32 height = ceildivpow2(image->y1 - image->y0, f);
.
.
.

...with...

.
.
.
S32 f=image->comps[0].factor;
bool wrong = false;
for(S32 i = 0; i < img_components; i++) {
if(image->comps[i].factor != base.getRawDiscardLevel()) { wrong = true; }
}

if(wrong) { opj_image_destroy(image); base.mDecoding = FALSE; return TRUE; }

S32 width = ceildivpow2(image->x1 - image->x0, f);
S32 height = ceildivpow2(image->y1 - image->y0, f);
.
.
.

"base.getRawDiscardLevel()" is the requested discard level, and "image->comps[i].factor" is the discard level for component (that is, layer) #i that the decoder returned.
Changing base.mDecoding to FALSE and returning TRUE lets the calling function ("LLImageJ2C::decode", in "llimage/llimagej2c.cpp") know that the decode has failed and it takes care of invalidating it and so on.

Some additional notes:

• This is not really a fix, since the real root of the problem is that the JPEG2000 library, at random, is incorrectly decoding lossless textures. Why that is I don't know; I'm tempted to look into the source of OpenJPEG, but since that doesn't have any apparent relevance to the KDU libraries actually being used for releases it seems like a waste of time.
• Also, this might not really fix the problem in the release viewers, because of the different libraries. However I think that something very similar must be happening since the error modes are so similar, and also since I implemented my work around above, I have not seen any lossless sculptie textures fail to load – I haven't noticed any other failure modes, which would be expected if there were additional problems unrelated to this decoding issue.
• These textures still load incredibly slowly considering their size, as mentioned by Julia Faulkland and myself above, and this fix does nothing to address that. It seems likely that whatever's causing that is in the host or the asset server.
• The failure I found has nothing to do with the texture not being transported across the network, or being saved or recovered incompletely saved in the cache.
• This fix seems to work for both the FL and the RC; I used the 1.19.0.79209 RC and the 1.19.0.80079 WL builds.

I would love to have someone re-implement my workaround and post if it was successful or not, so please give it a try! My machine specs follow in case that proves significant.

CPU: Intel(R) Pentium(R) 4 CPU 3.06GHz
Memory: 1009 MB
OS Version: Linux 2.6.23.15-80.fc7 #1 SMP Sun Feb 10 17:29:10 EST 2008 i686
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 7600 GS/AGP/SSE2
OpenGL Version: 2.1.2 NVIDIA 169.09
LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000)

Also, Qarl, I would REALLY like to make another request for a sculpt texture animation. The dolphin is an 8 frame animation, and will never be able to be animated with a stream because, well, it's attached to an avatar and can't be restricted to a parcel and, in addition, I don't think it could be salable as a product if it depended on a streaming server to be up to make it work. We NEED a way to get short sculpted animation loops without continually reloading textures, and using the same model as texture animation would make it possible to get the surface and texture animations to automatically sync.

if my understanding of this issue is correct - what happens is that the jpeg library doesn't get all of the file data out of the cache - which may result in the incorrect discard level being returned. you code detects this and throws-out the data, thereby triggering a reload from the server.

i think your code is a good idea - but isn't a perfect fix in-that we want the cache to work.

i'll know more next time i get a chance to dig into this work.

https://wiki.secondlife.com/wiki/Release_Notes#Release_Notes_for_Second_Life_1.19.0.284.29_February_28th.2C_2008

Also, thank you for the response Qarl. If what you're saying is correct that would certainly explain why similar errors were being experienced using two different decoder versions. When I have time, if there isn't a fix in place by then, I'll explore what data exactly the decoder is trying to decode and maybe try to zero in on what's going wrong between the cache and the decoder. However I would like to see my workaround implemented anyway for the following two reasons:

1) It might take a good long time to get that perfect cache fix in, if that indeed turns out to be the problem. Since my workaround does in fact give the user the experience of correctly decoded sculpted textures, albeit not the optimum solution one would like to see, and also since this item has been outstanding for so long, having any kind of fix in place, even a suboptimal one, seems like a good idea and would definitely improve the end-user's experience.

2) My workaround does something useful beyond just sculpties – it rejects incompletely decoded textures, instead of cheerfully approving of them. This is probably a good idea in its own right, lossless sculpty textures aside. So this isn't just a hack or a band-aid explicitly for VWR-2404 and with no other purpose, and when the real fix is implemented there won't be any need to remove my workaround.

>>> This is not really a fix, since the real root of the problem is that the JPEG2000 library, at random, is incorrectly decoding lossless textures. Why that is I don't know; I'm tempted to look into the source of OpenJPEG, but since that doesn't have any apparent relevance to the KDU libraries actually being used for releases it seems like a waste of time.

No, there is no random bug in OpenJPEG. As I explain in VWR-1815, I have confirmed for 100% certain that the root of the problem is OpenJPEG is being given a truncated codestream, it is not being given the data it needs to decode the resolution level that has been requested. It is impossible for it to accomplish what the viewer wants from it. Arguably it is a bug that it doesn't recover more gracefully from this error condition, but the fact remains the viewer is asking for something that is impossible.

This bug is in common code. KDU is in the exact same situation. The difference is, KDU seems to be able to recover from this error condition more gracefully. I'm guessing it's probably just dropping down to the next lowest resolution level that's available in the codestream. Thus the "lossy lossless textures" seen in this bug.

In my experience with above, the bug seems unchanged since initially reported. :|

-------------------------------------------------------------
Second Life 1.19.0 (80044) Feb 15 2008 16:46:46 (Second Life WindLight)

You are at 256175.7, 288564.9, 31.2 in Bagoombah located at sim4176.agni.lindenlab.com (63.210.157.80:12035)
Second Life Server 1.19.1.81132

CPU: Intel Pentium 4 (Unknown model) (3192 MHz)
Memory: 2046 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 7800 GTX/PCI/SSE2
OpenGL Version: 2.0.3
LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000)
Packets Lost: 29/537352 (0.0%)

Second Life 1.19.1 (0) Mar 5 2008 17:51:19 (Second Life Release)

You are at 238812.3, 290583.7, 701.2 in Envy located at sim5624.agni.lindenlab.com (8.2.34.180:12035)
Havok4 Beta Server 1.19.0.80517

CPU: Intel Pentium 4 Northwood (3006 MHz)
Memory: 1535 MB
OS Version: Microsoft Windows Vista (Build 6000)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 7900 GS/AGP/SSE2
OpenGL Version: 2.1.2
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.13510 (Mozilla GRE version 1.8.1.11_0000000000)
Packets Lost: 942/113391 (0.8%)

This and the low loading priority ( http://jira.secondlife.com/browse/VWR-3798 ?)
are the most urgent issues around Sculpties.

Just having lossless 64x64 sculpt-textures loading correctly and fast would lessen our pain very very much.
Please, please, please consider giving these 2 issues a higher importance than implementing new features.
I dont want to be a pain, I just want to make sure it is understood that these 2 issues make Sculpties a pain for all who seriously attempt to create or use them.

Am i being a cry-baby ? I hope not.

Cheers

Also, I'd like to re-stress that, at least for me, the bug is always only visible in the highest LOD level (the fact has been mentioned in the former comments, but it seems a bit "hidden" to me). The effect is illustrated in a screenshot here:

http://forums.secondlife.com/attachment.php?attachmentid=47064

I think I'm seeing this now. Some things just refuse to load after loading once on initial upload.

bad news: Ariel's patch doesn't work with our kdu jpeg library. it does work with openjpeg - but kdu must not return proper results when decompression fails.

good news: Sheet's patch does work. after a bit of testing - it seems that lossless textures load from the cache perfectly well. (there is an infrequent case where they might not - but the good news is Ariel's patch above nicely covers that case.)

so - good work all around. kudos. i've checked these patches into our maint-render-2 branch. i'll post here again when i know the timeframe for its merge to release.

Another thing that might need your attention, and another hydra-bug which has been marked as resolved and reopened again in the meantime, is http://jira.secondlife.com/browse/VWR-3798

Let me be blunt.
The comment given when that VWR got prematurely closed leads me to the conclusion that atm there is no "Sculptie Department" in LL.
Am I correct to assume that the "Sculptie Department" basically is .... Qarl Linden ?

Qarl does good work and i am sure he does his best to help us sculptors and sculpt-tools makers, but wouldnt you say that Sculpties are important enough for assigning some more WoMan-Power ?

I would love to see Qarl as the head of a 3-5 Person Sculptie Team.
I am aware of my narrow point of view on Linden Labs, and i am sure it isnt just as easy as i make it here ... but i hope you catch the drift whatsoever.

More here: http://jira.secondlife.com/browse/VWR-5647

So the bug remains. The only effective workaround I know of is this one:

— linden.orig/indra/llimage/llimagej2c.cpp 2007-11-07 20:18:06.000000000 -0600
+++ linden.patched/indra/llimage/llimagej2c.cpp 2007-12-05 13:14:53.000000000 -0600
@@ -310,7 +310,7 @@
//static
S32 LLImageJ2C::calcDataSizeJ2C(S32 w, S32 h, S32 comp, S32 discard_level, F32 rate)
{

• if (rate <= 0.f) rate = .125f;
  + if (rate <= 0.f) rate = 0.5f;
  while (discard_level > 0)
  {
  if (w < 1 || h < 1)

It's a hack but it works.

Afterwards, I needed to apply this patch:

Index: lltexturefetch.cpp
===================================================================
— lltexturefetch.cpp (revision 386)
+++ lltexturefetch.cpp (working copy)
@@ -609,7 +609,7 @@
{
mCachedSize = mFormattedImage.notNull() ? mFormattedImage->getDataSize() : 0;
// Successfully loaded

• if ((mCachedSize >= mDesiredSize) || mHaveAllData)
  + if ((mDesiredSize && mCachedSize && (mCachedSize >= mDesiredSize)) || mHaveAllData)
  {
  // we have enough data, decode it
  llassert_always(mFormattedImage->getDataSize() > 0);

or else a texture that is already in the cache but too small to fit the requested discard level will lead to a permanent loop since the texture fetch worker will simply try to decode the cached image over and over, stalling the whole texture download process.

A more thorough explanation: mDesiredSize will become 0 if the "sentinel" value is sent, thus the condition is triggered and the DECODE_IMAGE-state is reached. The voodoo calculation which discard level can actually be reached with the amount of data present will only happen later but at that point we are already decoding the image so the reached discard level is simply returned to the texture fetch worker which subsequently goes to INIT state again.

I wonder if this has already been fixed internally since you can hardly miss it (especially if you use the debug version as it segfaults in one of the "llassert_always"-conditions in this case.

I am not sure if this applies to other branches as well.

I am also not sure if my patch has side effects since there are a lot of assumptions made in the code by checking magic values.

I also did only test it on the Linux x86_64 platform with OpenJPEG1.3.

happily, Steve Linden, our texture pipeline guru, found a nice fix. again - no promises, but i'm betting we have this finally fixed.

the bug is still present in the new 1.19.1.4 (Main Viewer)

When will this fix be found in a RC Viewer ?
When will this fix be found in a Main Viewer ?

Fix-deployment seems to be scheduled for 1.20 RC2 !
Lets all fold our hands and prey to all gods there might be.

Almighty random chance, let this be the last time we ever see a vwr-2404 in an update-notice and have mercy on those who want precise complex sculpties.

Amen.

http://blog.secondlife.com/2008/04/23/new-release-candidate-viewer-120-rc3-available/#comment-601348

Fix APPARENTLY deployed in the new 1.20.0 RC3 .

Can all you guys confirm if this is really fixed?

It is extremely simple to reproduce.

This is getting slightly rediculous isnt it ?

With limited testing (3 logins and viewing 4 different sculpties) it seemed to be fixed for me. No instance of the lossless bug in this testing, which is significantly better than before.

I did notice that some sculpties took a while to load however, during which time the LOD was a notch or two low, but they eventually popped into a clean form. (Within a minute).

So for some scenarios there seems to be some improvement at least. I am not happy to hear that it doesn't seem to be 100% fixed, though.

Edit:

More testing. 3 more logins, 6 different sculpties, different computer (lower end laptop). Saw one instance of lossless bug. Before this RC, I would have seen several instances for sure. So it is statistically less likely, but still there. Argh.

> This is getting slightly ridiculous isnt it ?

slightly? no. extremely.

i'm sorry guys. i understand your patience is wearing thin. so is mine. let me see what i can do, and i'll get back to you as soon as i know more.

Many problems could be avoided if sculpties weren't uploaded as textures. A sculptie may have the format of a texturefile, but all similarities end there. If a sculptie would have its own in-world type, it could load with a higher priority, and with a different compression/encryption algorithm. Existing texture-type sculpties would still be valid (and oversized).

All it takes is an extra menu option and a new icon ... and to code it all

Repro is the same: go and fly around the mainland for 10 minutes or so, come back and the sculpty (sometimes) doesn't load up properly again.

CPU: Dual i386 (Unknown) (2600 MHz)
Memory: 4096 MB
OS Version: Darwin 9.2.2 Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008; root:xnu-1228.4.31~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8600M GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.26
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14669 (Mozilla GRE version 1.8.1.13_0000000000)

Currently this VWR-2404 is about lossless textures not being loaded correctly FROM CACHE, due to a wrong filesize assumption.

But the problem you describe I have noticed too. Small textures in some cases wont load fully at all, specially with lots of other bigger textures being around. A good place to see that in effect is the Sculpt Studio display at CMP 4 (60,130,24)

It is currently a bit difficult to point the finger onto something specific due to this VWR-2404 and VWR-3798.

I personally think that behind VWR-3798 is a nasty bug in the texture-pipeline which also causes small textures not to load fully at all in some cases, no matter how long you wait for it.

Edit:

(just in case vwr-2404 is aound much longer)

The workaround for vwr-2404 is to resize the Sculpt-Texture.
Resizing to 128x128 (in some cases 256x256 uploaded with SLImageUpload) using the resize-method Nearest Neighbor (Photoshop), No Interpolation (GIMP) or Pixel Resize (Paintshop Pro) will make a small, hard to compress lossless texture into a bigger one that is easier to compress lossless.
This way you can make a texture where the (wrong) filesize assumption can be satisfied.
This also seems to give the sculpt-texture a higher priority for loading which will make it rez/load faster.

This workaround is of cause NOT good practise because you end up having rediculously large textures for transporting only a little information.

When Sculptie-bugs are fixed 64x64 Sculpt textures are supposed to be optimal to the best of my understanding.

Is there hope for support for 32x33 and 16x17 and 8x9?

Repro by relogging (whithout clearing cache) does not work for me anymore. (Whenever i relog everything loads alright it seems)

Repro by flying around the mainland for 10 minutes (or just any Sculpty-rich place) and then coming back to the sculpty, still works. (As Seifert describes it above)

Edit: relogging doesnt fix wrongly loaded sculpties ... but if they were ok before relogging, they also seem to be ok after.

Please fix. SL is about creative people adding to the content and richness of the world. This bug is draining the enthusiasm of many of its most creative contributors.

Comment deleted, SLImageUpload appears to be allowed to log into SL again.

Note: While 3rd party should never be necessary for something to work properly, SLIU produces the desired results that everyone has been desiring out of the LL client software...that is, proper LOD, fast loading. Uploaded with RC5, LOD in uploaded lossless sculpts @ 128x128 is still low upon relog and it still takes a significant and unacceptable amount of time to load the sculpt map in comparison to things uploaded with SLIU. Im not in the position to hypothesize what the differences are, but the results are there.

The lack of a working fix in the latest RC is disappointing. Understandably this is a very complex and difficult bug... however I think part of the frustration many of us feel is due to the fact that we appear to have one person, however dedicated, working on this bug part-time... which suggests that despite Qarl taking it very seriously, it's not much of a priority for LL. This is a very tricky bug that's been with us for many months, and if anything can be done to raise the priority and get extra resources on this fix, I'm sure it would be much appreciated by SL's sculpt developers.

The great thing about this would mean that sculpties could have 16 bit precision and there still wouldn't be any need for a new asset type.

We could still have the option to use compressed images to store sculpties too.

Instead of having a lossless option in the upload image preview panel, we could click on the sculpty edit window and have it display image and sound assets within our inventory for sculpty usage.

A new primitive type may need to be added. Or perhaps it would be possible to let the client determine the asset type specified in the map field.

Is this a crazy idea?

Or maybe just a little-too-late idea?

Sigh, do I have to fix this bug myself?

How bad is this bug? Getting lossless to work AT ALL requires a huge effort, using numerous hacks and tweaks. It is so bad that many sculpts actually require 256x256 lossless images, which are only able to be uploaded by SL Image Upload, a resident-created client. Using 256x256 images, files can be 8-20 TIMES larger than they should be. That is more bandwidth wasted for both users and LL, and needless use of texture memory. Aggrivating this is VWR-3798, the loading priority bug, and the two combine together to make sculpts take ages to load where it should be only a couple of seconds, if that. Until these things are fixed, sculpts will be little more than a novelty, instead of the most powerful building tool in SL, which it has shown itself to have the potential to be.

There's many people in SL that make livings working with sculpted prims. So, I think it is far to ask questions: what resources is LL allocating to fixing the three major sculpt bugs (this JIRA, VWR-3798 and VWR-5785)? When can we actually expect fixes for these issues?

This bug is becoming very depressing

Anyone want to add to the pot?

My part of the pot can be earned by either an individual person who develops the fix or by a group working on it as a team.

And i fully agree with Aminom that "something" got worse.
The assumption that this bug only appears when loading fom cache is no longer true it seems.

http://nicholaz-beresford.blogspot.com/2008/04/moment-of-truth.html

/me loves Qarl for giving us sculpties in the first place, but his comment above is more vague about whether a patch would be accepted than I'd like, and could even be taken as a snarky reply by some (text is a poor medium for communication, isn't it?)

But okay... I'll throw in 50USD worth of L$ to any third party that successfully implements a fix, gets the fix approved by The Lab and integrated into a release viewer, and can demonstrate credit for it. I'd certainly be willing to offer more under normal circumstances, but with all of the in-world problems that we've seen lately my sales are abysmal and that's the most I can confidently say I'll have available.

Sculpties are an awesome hack in the system; Kudos to Qarl for introducing the idea and then implementing it. It's a great way to get UV-mapped vertex objects without having to introduce a whole new kind of prim. I knew sculpties would be big when I was tipped off to the idea a while ago.

However, shame on you for letting this slide as long as it has! As it is now, sculpties don't work in the client. RC or regular. And "sometimes works" is not good enough.

Fenrir - you'll get no argument for me. i feel very ashamed we've let this bug persist for as long as it has.

i believe we have a fix for it. rather than let the fix go through the QA and release cycle (taking up to a month sometimes) i'm attaching it here as a patch. (lossless.patch). i'd very much appreciate it if someone from the open-source community could test it and make sure we've gotten a good fix (rather than the bad fixes we're provided thus far.)

FINGERS CROSSED.

Can someone compile and distrivute a viewer with this patch, so those of us who don't know how to compile can test the fix ?

http://wiki.secondlife.com/wiki/Texture_Pipeline_Improvements

I haven't tried this latest patch, but everyone here has seen that simple patching has failed to fix this so far. Quite frankly, the entire texture download/cache/decode pipeline is total crackrock. The entire thing needs to be ruthlessly rewritten from top to bottom. This is not simple, or even fun work, but I'm convinced this is the only way this is going to get truly fixed. Unfortunately the crackrock-ery seems to extend through the client-sim protocol and into the simulator code, both of which are currently out of the hands of open source developers. So at best us open source people are still stuck hacking around the brokenness in that part of the system, until Linden Lab opens the sim source, or fixes it themselves. Michelle2 Zenovka is apparently way ahead of me on this, over on VWR-1815 there's some patches if anyone's feeling adventurous. I haven't gotten around to trying them, for now I'm just happy to no longer have a mangled map thanks to the recent OpenJPEG fix.

Hopefully this "Texture Pipeline Improvement" project is exactly this needed rewrite. But we're all already pretty sick of waiting on Linden Lab to fix this, aren't we?

> Quite frankly, the entire texture download/cache/decode pipeline is total crackrock.

you'll get no argument from me there - that's certainly the main reason this bug has so-far resisted all attempts to fix it.

on the brighter side - we have a plan to switch our texture pipeline to use http instead of the existing oddness. last i heard, it's considered extremely high priority - to be executed sometime in the next two quarters.

Long story short, I think it works. Thank you very much, Qarl!

Arrrrgh!!

I've been monitoring this problem for quite some time now because I was hoping the solution would also fix the issue of lossless sculpties taking far too long to appear on their initial download.

I can now rest knowing that the issue is a totally seperate one.

• Ponders over waiting another 6 months for a fix *

Bye cruel (virtual) world!

• Shoots myself *

On line 1357 of lltexturefetch.cpp, I changed desired_size = LLImageJ2C::calcDataSizeJ2C(w, h, c, desired_discard) to = MAX_IMAGE_DATA_SIZE instead, and THAT worked, but was obviously wrong as every single texture took a lifetime to load then. Without that though, no luck.

I don't know why the patch works for Ariel but not I.

She's using Linux, but... that shouldn't matter.

AAARRRGHHHH!

ok - couple things before we give-up all hope:

1) 32x32 isn't really supported. in my initial work on this issue, i discovered that both the openjpeg and our commercial kdu libraries won't correctly compress all 32x32 images.

2) make SURE you have your cache cleared before trying the test. (textures that were downloaded before this fix might be corrupt in the cache.) clearing the cache is extra difficult in the latest viewers, which have a BROKEN "clear cache" button. (you'll need to remove the cache directory by hand.)

• Download priority?
• Buffer allocation?
• Cache allocation?
• Determining when the download is complete?

Shouldn't the real size be known to the server and provided to the client? I don't understand why an approximation woudl even come into the picture.

so to answer your question: i have no idea all the places/ways that desired_size influences the download.

i can give some historical context that helps understand why things are the way they are - but honestly, that's probably not very useful.

the idea here is to get some kind of temporary hack in place that'll address the immediate problem, until the whole thing can be refactored. (which will happen in part when we implement http as the texture protocol, sometime in the next two quarters, likely.)

The real issue here is knowing where these divisions occur, this can only be determined by parsing the j2k codestream and looking for termination markers. If this was used to hand off to decode we would always have the correct amount of data for a given discard level.

You also have to fudge the cache to ensure that loads 100% of the data and thats not so easy, i attempt that on my patch by forcing the state machine back into NET which should then fetch the missing data from the server, this should not happen often if Quarl's patch is also applied.

I'm actually interested if my patch and quarl's patch together help that 32x32 case described by Uchi.

Though when it comes to lossless, at the "small" image sizes used in SL, j2k compression seems to be less than optimal. Much like "JPEG 1991" before it, its designed for photographic imagery. PNG is much better designed to deal with small contrast-y icons, constrained color palettes, and flat colored areas. I seem to remember PNG texture support was listed in a roadmap for 1.20... It would be easy enough to make the client automatically try both j2k and PNG before uploading and pick the one that ends up smallest. Though I don't know how PNG is going to fit in to the broken image download pipeline...

(j2k is used a lot for geographical data measuring in the gigabyte+ range, and used by Cinema 4k. A 64x64 sculpty is tiny by j2k standards.

What's curious is that in 1.19.1.4, the current release, my 32x32 textures would atleast load some of the time, while in RC they absolutely never would.

• They take forever to download;
• 32x32 textures are unsupported; and,
• The texture pipeline is a labyrinth of pain.

But these problems seem to me to be beyond the scope of VWR-2404 itself, which is focused on lossless texture compression and decompression. I don't think it's unreasonable to think about closing it soon, perhaps when Qarl's fix makes it over to the release viewer, regardless of the status of these other regrettable problems.

So for me, lossless sculpties are still unusable and it makes me cringe to think of people continuing to use them. To fully appreciate what can happen when many lossless sculpties get together I suggest people go visit Timmi Allen's place. You can find it through his Picks. The guy makes lovely sculpties but I'm not so sure he fully realizes just how long his area takes to rez. You could be there for an hour and still see a half rezzed animals.

We could download a high res mesh of Michelangelo's David in the time it takes for a single sculpty pillow to arrive.

If I was Qarl I'd be seriously considering giving up on SL and it's spahghetti code. Please don't leave us, Qarl!!

Just went to Timmi Allen's place and its quite a good testing ground. Now i didn't notice anything "usually" slow, the textures all appeared in the general texture download mele that occurs.

I would say any slowness to download is server issues either loading, network OR the good old assumption about how much data to send for a given discard or a combination of all.

May be it is time to focus on specific issues that are closely coupled to this, such as the speed of download and failure to load some 32x32 textures and create seperate JIRA;s for each of them to keep focused and not let everything get piled up in the confusion.

Please keep in mind:

1. 32x32 Textures are officially not supported (Read Qarls comment above that)
2. VWR-2404 is not about loading speed (There are other VWRs for that)

"Fix Pending" is the correct Status for a bug that has been fixed (or lets call it patched) in a Viewer-version that is not yet the Main Sl-Viewer.