Small oblongs broken ???

aha.

I always thought there are only two types of sculpties:

- standard (old school) sculpties 32*32 faces
- oblongs with other values of face-counts on x and y.

So since my cubes are not standard sculpties, what are they then ?
Ok, the last one IS a standard sculptie, didn't i mention that ?

I'm guessing that most people will call a sculpty that has different x and y dimensions an oblong. By that definition, some of your samples are oblongs and some aren't. But the changes Qarl made in response to VWR-9384 was intended to define a uniform treatment for all sculpties -- oblong or square. So all your examples are relevent.

I've done some experiments that suggest the biggest flaw is with the compression when done by the Kakadu library.

Background: Under Windows, the client normally uses the Kakadu library (llkdu.dll) as the JPEG2000 codec. But if you rename or remove llkdu.dll, the client will use the Open JPEG library (openjpeg.dll). On the Mac and Linux, I think openjpeg.dll is always used.

If I do a lossless upload of small sculpty bitmaps with Open JPEG, the results are much better, even when viewed using the Kakadu library. I haven't done a careful enough analysis to say that the only flaw is in the Kakadu encoding. But I thought I would go ahead and post this interim observation so that others could experiment.

Closer examination seems to confirm my theory of the previous post. Here's a copy of what I posted at http://jira.secondlife.com/browse/VWR-8551 (lossless compression not lossless on small textures).

"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."

Although there may be a work-around for the knowledgeable (i.e. disable the Kakadu library when uploading), this pretty much makes the gains we got from VWR-9384(Modify the calculation of sculpty mesh size to eliminate bad texture mapping and bad LOD) inaccessible to the average builder. If you cared about VWR-9384, please vote for VWR-8551.

I can verify that for 8*8 sculpties your methods works perfectly.

But for those with size 16*32 and 32*64 the result is complete chaos...

Darn! It sure would have been nice if there were a single issue. I presume you'll add your findings to the JIRA.

sure, done.

I did some more experiments, this time with a 16x32 bitmap. When I both uploaded (lossy or lossless) and displayed the texture while using openjpeg dll, it was totally whacked, as you reported. But if, after uploading with openjpeg.dll, I switched back to llkdu.dll to to view the textures, they looked pretty close to what it should have been. (But saving the "lossless" version to disk and comparing it to the original showed that some loss had creeped in.)

So it seems there is a major bug in the Kakadu compression, a major bug in the OpenJPEG decompression, and probably yet a third bug somewhere.

I can't get 8x8 to look like anything other than a dirty smear once uploaded, so it effects more than just sharp edged models.

To me it looks like they're about halfway through implementing this, with lossless upload for sub 4096 pixel maps still to come. Kind of making it a bit useless, but the groundwork is all in place, so at least we can be thankful for that. Might set the whole thing back a while, seeing as the lossless bug caused headaches all through 1.17 and most of 1.18's cycle.

I would love to see an option in the object tab to reduce the mesh and get around all this, or even an option to select the resolution you want a texture resized to during the upload process. As long as it's a working method, obviously.

Ponk, is that just using the out-of-the-box RC? Or even if you disable the Kakadu library while uploading?

Vanilla RC.

Until I read your posts above I had no idea you could swap it over for another library. I'll have a tinker with that.

I can fully reproduce your described behaviour in my test setup. After i switched back to the plain vanilla rc-candidate, all cubes look pretty close to the expectations. The non lossless image transport of non square image textures damages the edges of course

Ugh! I can't. When I inactivated llkdu.dll, the small (but not the 64x64) lossless maps were completely garbled... no apparent relationship to the original images..., and the sculpts were a tangled mess!!!??? maybe a too-old opengl.

Did you notice my followup at /8/61/320205/2.html#post2424128 It sounds like you are describing what the sculpties look like when _decoded_ by openjpeg.

Yes, you are right ... sort of ... but they are still rubbish when I go back in with llkdu ... worse than before. This is getting uncomfortably confusing. Why should opengl be involved in 2d image (de)compression anyway?

If you have an example image which, when compressed with openjpeg and decompressed with llkdu, gives rubbish, could you post it somewhere? Or give me a full perm copy in-world, so I can save it to disk?

OpenJPEG and OpenGL are independent projects. If I said something about OpenGL, it was a mistake.

The 32x32 example in the picture I posted in the jira....just reduce it from 128x128 to 32x32. But that's not quite it...I had a copy that was uploaded with llkdu and that was rubbish when looked at with openjpeg. I also uploaded it again with openjpeg, and it was the same rubbish. It was ok when looked at again with llkdu. Ah. No. It was my mistake ... reading too fast...loong daays work...just stupid?

Definately stupid. That image is jpegged! here is a png in case any better

Perhaps it's a necessary so they can be applied within an opengl engine. Although wouldn't that just be a tga?

ed: Oh, I see.

Just curious: I have looked at how you have constructed the mesh of this cube. Is there any particular reason why you have done it in that way ?as i can see it has no poles at the surface. Is that better for texturing ?
BTW it seems as if this particular construction breaks down at LOD1 ...

Errm.... It was the first way that came into my head to make a cube. Done in GIMP. Made just to test the bug, so I wasn't concerned with LOD. LOD1 ok if you shift it left 4 pixels. (PS: it's for planar topology)
Depends on what you want. Avoiding poles means you can tile with a simple texture without having to transform it. (Maybe just same as planar texture on a cube with poles?). For an extreme example of that idea, see /53/fd/182727/25.html#post2419908

I've been away from SL for a month, and didn't even know this was implemented.
I'll definitely have fun tomorrow!

Here's my thoughts on what is happening (as noted above, it's the lossless bug):

Whether or not an image loads at all, or how fast it loads, is dependent on the file size of an image for a given pixel count. With lossy this isn't a concern, but with lossless with comparatively larger images per pixel count, it can be. 64x64 sculpts outputted from Domino's scripts aren't affected because, in general, every four pixels have the same value, corresponding to a single vertex. Jpg2000 Lossless compresses images that have adjacent pixel values that are the same a lot better, which results in a smaller relative file size, which gets under the bug. 128x128's almost never seen this because it is 16 pixels all with the exact same values.

However, if adjacent pixel values are very great (for example, RGB noise), it will be less compressible as well. So, with the new small sculpts, they are probably hitting the bug because by virtue of having fewer vertices, the RGB range of the verts is greater.

If this is true, here's a messy fix: reduce the total range of values used. In otherwords, make a nano sculpt. This can be done in an image editor using the color curves tool, or in a baking program that allows configuration of the used range. This is not a true workaround though because for non-nano objects it will push out the apparent LOD distances quite far, whereas the new small sculpts, having more forgiving LOD models (in exchange for fewer total verts) don't need this treatment.

It could also be the case, as formerly, that SL isn't configured to handle images of such sizes yet (this isn't the lossless bug). In this case nothing one can do would give perfect results until this underlying bug is fixed.

fr

Couldn't help myself; had to do a quick test.

It seems that 4x4 sculpts (corresponding to 8x8 pixel images) do not work at all. I don't think this is a problem as the possible uses for 4x4 sculpts are undoubtedly small.

However, 8x8 sculpts (corresponding to 16x16 images) _do_ work in theory, even though they hit the lossless bug. To get around it, I decreased the range in a simple sharp-edged cube from 0-255 to 0-10. Here's the test:

http://img26.imageshack.us/img26/4283/testcube8x8r010.png

(Note this prim can appear rather small, so it would be good to scale the prim up to say 5 meters a side before applying the sculpt)

Not sure if 8 pixels per dimension is the limit, or 64 pixels in total.

Indeed. This would appear to be the case here since (a) in the simpler models I used initially, some were still failing although they had 4 or 8 adjacent pixels identical and (b) the problems affect the highest LOD. (Expanding the relative size of the bounding box will not fix this. It requires too great a sacrifice of vertex accuracy for me anyway.)

I still consider it the lossless but, as it affects only lossless uploads, although it may be a new (aspect of the original) bug. The lossless compression (or more accurately, the retrieval of losslessly compressed images) simply does not work for images less than 64x64. For these small images, it loses more than the lossy does. For 8x8, it gives complete garbage.

Ah cool, I just IMed Aminom about something to do with this, I had an image in my head of him having been here and done it all weeks ago or something.

Is there a jira running where we can collate all this and have a vote?