Inhibit JPEG compression for scuplty textures

I'm about to open a JIRA. I'd appreciate your feedback.


Please provide a means to inhibit JPEG compression for sculpty textures.

The new sculpty primitives would allow dramatic reduction in the number of primitives required for many common content objects such as jewelry and furniture. However, JPEG compression makes it impossible to create geometric shapes with smooth surfaces. Collapsing vertices doesn't work because adjacent surfaces don't appear contiguous. Spreading out vertices on a facet doesn't work because the surfaces appear uneven.

One possibility is to inhibit compression for textures of size 32x32 or smaller. These images take a little over 3K to store without compression, and they are probably relatively rarely used for normal SL content due to low resolution.

64x64 take 12K and reduce considerably with compression, and they are probably quite popular in building. Inhibiting compression by default on these would probably impact SL performance. An option to inhibit compression would be great, but might be open to abuse. Perhaps a higher upload fee for uncompressed images would discourage unnecessary use.

Are there varying levels of compression? If so, maybe decreasing the compression for big sculptie textures would be a decent compromise.

Yes, JPEG supports varying levels of compression. For sculpties, we want 100% (no compression) because we don't want the system to change the shape of our objects, and the space savings would be minimal.

Ah so that's why my supposedly straight edge was all dented. Yes you can't have any sort of compression on a sculpty map!

I know the Lindens are aware of this, if you read the Wiki at http://wiki.secondlife.com/wiki/Sculpted_Prims:_FAQ , Down the page Qarl states:

"One issue here is the 8 bit precision on images, and the other issue is the jpeg compression applied to the data (all textures are converted into jpeg2000 format). The name "sculpted prim" was chosen to convey the idea of "approximate" shapes — but as you can see from the plate in the image above, "approximate" is pretty close to "exact". Furthermore, it wouldn't be hard to support 16bit images and higher precision/lossless compression in Second Life — but let's first see whether we need it."

So I think if enough people see this as an issue, They are likely to do something about it.

Yes, Darien, I read that. However, "approximate" is nowhere close to "exact" in the case of relatively simple geometric shapes, if one wants smooth surfaces and abutting faces.

I'm aware that they're aware of this. This is my way of saying "JPEG compression is an issue; it makes sculpties unusable for my purposes."

Four your purposes. I think I have read that sculpted prims were intended to model organic shapes, thus taking imperfections into account. And as far as I see, JPEG compression goes easier on the sculpt textures representing those shapes.

Perhaps LL will think about that, but don't hold your breath.

128 x 128 textures aren't THAT huge if you absolutely, positively, definitely need the extra detail. 64 x 64 should suffice for most things though, I think it just means we won't be using 32 x 32 except for objects where glitches aren't major.

I'm not convinced that JPEG is an appropriate format to compress sculptie textures. JPEG compresses the image in the spactial frequency domain and is a lossy compression system that takes advantage of the shortcomings of human vision.

I can't see any reason why you would want to use a lossy compression system at all for compressing a sculptie texture. This really needs a lossless compression system. You can probably use the close proximity of the vertices as part of the compression system and store differences in some way. That said, the sculptie texture are quite small anyway as compared to a visual texture, and can probably be best stored in an uncompressed format - the 64x64 ones I've created come out as 13Kbytes when stored as an (uncompressed) .bmp file - this is quite a bit smaller than most image textures.

The other big problem is the use of 8-bit to store the position of the vertices. For many curved surfaces, this can give a lot of quantisation noise. I've tried generating some of these sculpties in software, and then visualising a 2D cross section of the object before and after the quantisation (changing from float - to an int in the range 0-255). Whereas the unquantised images look quite neat, the quantised version looks very messy - I found that it is often better to 'tweak' the position of the vertices slightly by hand (in the quantised version) to try to remove some of the worst step changes. This problem gets even worse after JPEG compression !!

I would suggest going for an individual x,y or z value of 12-bits (so 36 bits per vertex) and then to store the data uncompressed. This would give a file size of about 20Kbytes. The only downside is that this would not be able to be carried around (with one pixel/vertex) in a standard graphics file format - although you could use 2 graphics pixels per vertex as a simple fix (albeit with a bit more overhead).

Fred Charles

Fred, they use that because that's what they're already using for everything else... This thread is about changing this process for sculpt textures. Before it didn't matter too much - now it matters a bit more.

I thought 64x64 was the maximum size...
Can we use 128x128?
Does that mean that we can use prims with more polys in the modelling programs?

I agree that we need a better format for sculptie textures. The only thing they really have in common with the image textures is that they are both two dimensional data objects.

I believe the precision requirements depend on what you are building. For compact smooth shapes, the existing system is probably fine. However, I believe that with more precision it should be possible build some quite complex shapes that currently require multiple prims. Given the precision, we should be able to create sharp edges and corners by folding multiple vertices at that point - or edge.

I spent a while yesterday puzzling out how to make a sculptie coffee table. Given the right precision, its probably do-able, but working out how to get the image texture for the wood grain right is a nightmare . Perhaps I might try this with the existing system - but I have a feeling it would probably look like a squashed wooden horse !

Fred

Haravikk, going to 128x128 doesn't buy you anything with sculpties -- just wastes asset server space and bandwidth. I tested it, and it does not reduce the problems associated with jpeg compression -- it only changes them. The result is different, but not necessarily better or worse.

Fred, internally they use JPEG2000 format, which supports uncompressed as well as lossless compression formats (according to LL, if I interpreted what they said correctly). Yes, they ARE considering this change and I want to encourage it and make it clear why its in their best interest, and possibly to suggest good alternatives that achieve the result without adverse impact.

You are correct that lossy image-related compression is inappropriate for sculpties. For curved shapes or shapes with inherent noise, jpeg compression doesn't affect the results enough to matter. But for more pure shapes, it wreaks havoc.

IMHO, for images at 32x32 or smaller, compression doesn't save enough bandwidth to matter, for the reasons mentioned above. Therefore, I don't think we should even bother with lossless compression for those sizes. However, it might be good to apply it by default to 64x64. We might even find that many lossless-compressed 64x64 images look better than compressed 128x128 while taking the same or less space, in which case it would be a win-win situation for content creators and SL performance.

Alderic, LL says that they did not intend sculpties for a particular application like organic shapes, but due to the known issues with compression, they tend to be best for that.

No, I won't hold my breath. But LL says that they are thinking about this and "waiting to see" how things develop as content creators work with sculpties. Thus this thread, and the JIRA entry I plan to create.

Anyone have any good suggestions for the ideal solution? It should have these properties, in no particular order:

1) Simple for LL to implement
2) Minimal change to current processes and GUI
3) Permits lossless representation of images for sculpties
4) Minimal impact on performance

Would anyone object to paying $15 or $20 to upload an uncompressed image? IMHO, it would be the nontypical case even for sculpties; for polygon-based shapes rather than curved ones.

Thanks
Jeff

The maximum detail is 32 x 32 vertices, so 1024 in total. So if you use 128 x 128 it won't make it any more detailed, it just reduces the effects of any harmful compression.

Thing I don't get though is that JPEG-2000 (which is what SL uses internally) is capable of lossless compression, which is what I thought it used for any .tga images you import, however I've never really experimented with anything where the difference would be noticeable so I can't say if this is the case or not.
It should however mean that we could have an upload option 'Use lossless compression' which will upload without losing data, but could only be used on images no larger than 128 x 128, therefore intended for scult-maps or maybe HUD images and the like.

'k. Groovy.

Here's another Q, for those more in the know.

I'm using Wings as my interim between SL and zBrush.
As the forum thread instructed, I made a 64x63 sphere and exported as OBJ, then imported into zBrush to work on, then exporting as OBJ, importing into Wings and exporting as a sculpty. I'm loving it.

If I were to do a 128x127 (I'm assuming) sphere in Wings, export, import into zBrush, etc., I'm assuming it would still export from Wings as a sculpy tex.
Yes/no?

Thoughts?

No it doesn't, it just changes the harmful effect of compression. Whether it's better or worse depends on the particular case. In my case, the bigger file produced worse results.

Mickey, try asking that in another thread. Thanks. I don't know the answer.

In any case, there's no point in using images larger than 64x64. That's according to LL. The sculpty itself is calculated from 32x32, and 64x64 provides extra resolution to avoid downsampling artifacts when using a lower LOD (level of detail) -- if I understand correctly what LL says on this subject.

According to LL, 64x64 is the highest resolution you should use for a sculpty. Any more than that is a waste of bandwidth. According to my tests it doesn't lead to better resolution, but I'm testing corner cases and my results may not hold for more typical sculpties.

No need to get snippy, I'm supporting you! My post was to indicate that this is probably one of the few proposals LL might actually listen to. God knows they pretty much ignore most of them. Next time read the fulll post before you blast someone.

You can use any size texture. I've been using 512x512, as it reduces the effect of the jpeg compression artifacts. Sadly this is exactly why compression should be disabled. If there was no compression, such large textures wouldn't be required to get accuracy.

Thank you! I am glad someone else brougt this issue up. I have mentioned it (and a few other issues with sculpted prims) here:

/111/16/186418/1.html#post1524588

If people want an easier program to use to create sculpted prims than Blender, please download the "Moment of Inspiration" (MoI) application from here: http://moi3d.com/


We need to be frank about this with the Lindes: we need:

1) NO LOSSY (JPEG 2000) COMPRESSION OR PIXMAP CLIPPING *AT ALL* FOR SCUPTED PRIM UPLOADS. When an image is uploaded, we should be asked how we want it resized (if we want to round UP or DOWN to a multiple of 32 or if we want the image to specifically be, say, 1024x512 if it was originally 766x411), and if we want information about the original image size included for proper display), as well as asked if we want to:

a) use lossy compression
b) use lossless compression
c) use the exact lossy or lossless compression that already exists in the *.jpg, *.TGA or other format image before it is uploaded, so there is NO net loss of data even if lossy (jpeg 2000) compression is used: it shoudl simply be the exact duplicate of the already compressed data, and use the same jpeg 2000 scheme and compression level. Batch uploads should do Batch Processing on each file automatically once the first set of answers about how files are to be treated is given.

2) We need support for 16-BIT PRECISION FOR SCULPTED PRIMS.

Period. We need this implimented ASAP, otherwise sculpted prims are just a hollow tease... a titilation, as it were, but not useful for anything practical besides fruit, random spikey blobs, and sex organs.

We have been seduced by the promise of potential possibilities... now we need the real thing.

A 24-bit image, 64x64 I tried is 12KB as bmp. As png (lossless compression), it's about 1.98KB.
I tried IrfanView's jpeg2000 support to save losslessly, and that was 3.33KB.
If I decrease to 256 colors, 8-bit, there is visible change.

If nothing else is done, it would be nice to be able to see how our sculpted prim will look after the texture's uploaded and compressed, not before... without having to upload first.
I'd prefer lossless compression vs lossy, for something that may need to be precise, like these sculpted prims. I've wasted space, myself, and reuploaded some sculpt textures as 256x256 to try to get around compression artifacts. Even then it's not perfect. Some things work fine at lower sizes, some don't. Sometimes there's noticable noise even in 256x256, sometimes not.

I'd be happier without compression for some things, but I can't complain too much. Some of the things I've made are fine, even with a little randomness. At the normal texture size without scaling it up.

There is now info about Sculpted Prims on Wikipedia. Please make updates to the entry as you see fit, folks:

http://en.wikipedia.org/wiki/Sculpted_Prim

I just learned some days back about a 3 major limitation to Sculpties, in addition to the data being limited to 8 bits (and not 16), and the JPEG2000 compression upon uploading of the textures... in Second Life, the client has the Level Of Detail (LOD) for sculpties set to the integer 3. It could be higher than this if some way to compensate for the loss of speed (lag) could be accomplished.

....what does "LOD 3" mean?