|
|
|
Updated to Critical and more general with added information
It looks like all oblong sculpties are affected with image sizes where either width or height is < 64.
Standard sculpties (64*64 image size) work without problems. See for a comprehensive discussion and some more screenshot about that in the forums at http://forums.secondlife.com/showthread.php?t=320205 The screen shot added above shows perfect cube sculpties with varying sculptmap sizes. they have been uploaded with lossless compression and the image sizes are: facecounts -> image size My experiments suggest that the "lossless" JPEG2000 compression done by the Kakadu library is the main, if not the sole, cause of this problem. I used the attachment "8x8 pixel sphere.bmp" as a test case. Enlarged, it looks like "8x8 pixel sphere (enlarged).bmp". If I upload the 8x8 version with the RC 1.23.1 and then save the results to disk, the saved result looks like "8x8 pixel sphere, as uploaded by llkdu.dll (enlarged).bmp". Obviously, something has gone seriously wrong.
However, if I remove llkdu.dll from the RC directory and repeat the process using openjpeg.dll, the upload/save round trip results in a perfect match to the original. If I revert to using llkdu.dll and save the version I uploaded with openjpeg.dll, the result still matches the original exactly. I tried Omei's workaround with the sculpties from my earlier screenshot (see above). I found that the sculpties with image sizes of 16*16 pixels now create perfect cubes. But the images of size 16*32 and 32*64 create total chaotic results. I tried with lossless compression turned on and off, but the results where equaly bogus.
This problem has become very prominent with the advent of small sculpt maps, oblong or square, in client 1.23. The image data used to generate the sculpt vertices is incorrect for square sizes less than 64x64. The distortion is extreme with lossless compression upload. Lossy compressed uploads of the same files give less distortion, but is still not usable for sculpts where vertex accuracy is essential - mainly those with sharp edges and hidden/degenerate triangles. This precludes the use of small maps for a large number of possible sculpties, and thus prevents the potential triangle and data transmission saving advantages.
The attached picture shows solid and wireframe examples of 8x8, 16x16, 32x32 and 64x64 simple interpolated vertex cubes. The 64x64 lossless upload is perfect. The 8x8 is distorted beyond recognition. Added a picture of some plain textures uploaded lossy/lossless, in case there are some clues there. Note the kdu exception for lossy 16x8 (and 8x16, not for lossless) ?! Is that general?
For quite a while all the sculptie images that have less than 4096pixelx have always look distorted. At first I thought that they never load fully. But now, it seems that images that have less than 4096 pixels are NOT uploaded as lossless
 In the past I have been unsuccessful in convincing Qarl that there is something wrong with the uploading. Lets hope that now this will finally be fixed. Qarl suggested the workaround uploading with openjpeg and then viewing with llkdu. So I repeated that test using my four cubes. The picture cubetest20090606 shows, left-to-right, 64x64, 32x32, 16x16 and 8x8 maps (33x33, 17x17, 9x9, 5x5 vertices), uploaded losslessly with llkdu active (front) or inactive (back) so that opengl gets used. Well - it worked for the 8x8, but the 16x16 and 32x32 are still distorted. The distortions are very similar but not identical. Could it be a combination of upload and retrieval problems? Also uploading the test maps, "tstx*x*.tga" so anyone can play with them and/or see if I made any mistakes with them . They look right imported into Blender. PS. the 32x32 and 64x64 have to be inside-out; all are for planar topology.
I do not understand why it is so complicated to track this error. Apparently something is wrong. ok, so can't someone just take a look at the viewer, find where the sculptmaps are exported/imported and check if they are sent out broken or not and if they are received broken or not ? (I can't do this. I tried to compile the viewer once, but gave up quickly.)
If the sculptmaps are ok at the exitpoint(export to LL) but not ok on the entrypoint(import from LL), then the problem is on the server side and clearly it is LL who should do something (for instance put the the server side into open source so that this problem can be solved quikly, or allow some clever enthusiasts to look at the server side code and find the bug for them ...). If the sculptmaps are broken when exporting or are intact right after getting from the Server, then it is is on the client side. And then it should not be such a big problem to create a patch ? and send it to LL so they can add it at least to the RC-viewer... Probably this is very naive thinking ;-( Otherwise i can not understand, why this approach has never been taken up till now. Or is it just so complicated that nobody understands what goes on ? That would be fatal... Why wasn't
Uchi. By way of explanation, rather than justification: As far as I understand it, the original bug applied to sizes greater than the 64x64 which was the minimum supported sculpt map at that time. The fix applied worked down to 4096 pixels, which was all that was needed then. Only with the introduction of support for smaller maps did the issue reappear. I guess we don't know in advance whether it is the same bug and the fix was partial, or this is a new bug arising only with less than 4096 pixels. Thus the safest thing was a new jira. However, you are very correct in pointing out the link to
I'd just like to point out that this issue is related to
Fixing this issue (VWR-8551) would allow residents to create sculpties with fewer vertices which would potentially lessen the need for the vertex limit. I'd also like to pass along that several users have discovered this bug (VWR-8851) independently and reported it in the Prim Composer forums. The ability to create sculpties with less than 1024 faces is a killer feature if it worked. Unfortunately, all of the work that went into implementing low res sculpties is wasted if we can't get this this texture compression problem fixed.
The slowest parts of avatars to load are usually the sculpts... this would allow sculpts to load faster, since the files sizes would be smaller.
I see no downsides to this! |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Sub-task
Open
Critical
The in-world UUID of the uploaded texture is 3852607c-46bf-761c-4d76-5912256e0553
Other information Linden may want to read:
Second Life 1.22.11 (113976) Mar 6 2009 15:21:09 (Second Life Release Candidate)
Second Life Server 1.25.6.113484
CPU: Dual i386 (Unknown) (2500 MHz)
Memory: 4096 MB
OS Version: Darwin 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8600M GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.36