|
|
|
[
Permlink
| « Hide
]
Elbereth Witte added a comment - 27/May/07 04:40 AM
This sculptmap is 32x32, I believe recommended is 64x64. Not that I know if this is related or not. That and the heavily dithered screen capture, is heavily dithered.
 Please attempt to repro with 64x64 – should not be as bad.
Note:
lindenrobot made changes - 30/May/07 03:22 PM
Imported into Linden Lab issue and assigned.
Thanks for the attachments and steps for easy repro of artifacting.
Periapse Linden made changes - 30/May/07 03:24 PM
JPG artifacts have particularly ugly effects when attempting to make symmetrical sculpties (octagonal section etc) that would save prim counts (and thus, as yet, unusable for this purpose). These artifacts are most pronounced at, though not confined to, the color boundaries, i.e.in the worst possible position for such artifacts to appear.
The simplest demo is a sculptie cube: 1) upload and apply the 64x64 tga file Comparative images attached: The visual disruption of these artifacts become ever more pronounced with increasing vertices and sculpted prim texture map complexity.
Escort DeFarge made changes - 02/Jun/07 09:27 AM
Escort DeFarge made changes - 02/Jun/07 09:27 AM
It's also notable that the original TGA (using RLE) is far smaller than the downloaded version... so much for saving bandwidth hunh?
Escort DeFarge made changes - 03/Jun/07 09:08 PM
Escort DeFarge made changes - 03/Jun/07 09:45 PM
Also see https://jira.secondlife.com/browse/MISC-259
 for discussion of larger size sculpt textures and effect on jpeg artifacts.
Escort DeFarge made changes - 06/Jun/07 07:33 PM
Escort - regarding size of jpeg2000 vs. tga:
size is not all that matters. jpeg2000 allows for image streams where image approximations become available for partially transfered files. PNG also does progressive, though I haven't tested compression in this case.
re compression, yes I do understand BUT in the case of sculpties the artifacts produced massively reduce their usability. Any chance of requiring 32x32 tiny textures for scultpies (since that is the max points we can define anyhow) and just turn off compression entirely?
64x64 is probably recommended not only because it somewhat reduces JPEG artifacts (though not enough), but also because a 33rd row/column of verts is needed for axes which don't wrap, as is the case with the vertical axis of the current sphere topology, and both axes of the yet to be implemented plane topology.
Aminom Marvin made changes - 15/Jun/07 02:27 PM
Please fix this problem as soon as possible. I am on the verge of trying to figure out how to "reverse compress" an image manually before uploading to try to negate artifacting. This issue is the one thing holding many back from truly using the potential of sculpties.
This is a HUGE problem for me. My business is based on creating sharp, inorganic sculpties; things like stairs, diamonds, geometric shapes, etc. My method for creating these uses photoshop entirely. However, my method cannot achieve perfection because of the compression; at the edges of shapes there is overlap. If uncompressed 32x32 and 16x16 images were added, it would instantly allow people to make complex, inorganic, 1-prim shapes that are extremely efficient and completely precise. Just this small feature could usher in an entire new era of object creation using sculpties. I have uploaded a sample image (compression_errors.jpg) showing how the problem severely degrades my product.
McCabe Maxsted made changes - 15/Jun/07 07:15 PM
I'm finding that, in order to have a decent degree of control over my vertices, I have to pixel-resize my original 32x32 map to at least 128x128 and then offset it so that SL's sample coordinates coincide with the center of each "megapixel" (otherwise, the sampling occurs right at the horribly-artifacted borders of said megapixels). This is a cumbersome and inefficient workaround that goes against LL's original intention of conserving bandwidth, but I currently have no other choice unless I'm willing to have a very significant amount of vertex offset and noise present in my models (which I'm not).
Please eliminate JPEG compression from sculpt maps of size 64x64 and smaller. JPEG compression was not designed with this kind of application in mind, and it really, really shows. Thanks again for all your hard work, LL. jeepers - you guys are really chompin at the bit for this one, eh? per the spec, sculpties are targeted for "approximate organic" shapes, right?
but yes, i feel your pain. let's try this as a first step: improve the existing jpeg2000 compression level for small textures by these amounts: for 32x32, 4 times the data. for 64x64, 2 times the data. for 128x128, 1.5 times the data. and if that STILL doesn't get you the precision you need, we can explore further options. (these numbers are the result of internal LL dev negotiations. Qarl, can you share with us why you haven't just switched to lossless compression for small textures? I'm sure there must be some problem, or you would have done it by now. If it is a technical issue, and I knew what I was up against, I might write the patch.
Qarl, isn't the compression done within llkdu for which we don't have the source? I don't have the impression that we are enough in control of compression to do this. Maybe we can do it using parameters but it's far from clear how these influence the compression.
As an alternative to the above. How fast does OpenJPEG need to become to make KDU obsolete? This would obviously be beneficial:
a) we get rid of a proprietary library b) we get back control of JPEG2000 encoding allowing better tweaking If somebody has a test application that would allow for benchmarking between the 2 libraries I'd be interested as that would allow focus on speeding up OpenJPEG. Fun fact: slviewer does not adjust the OpenJPEG encoder settings at all, it leaves them at default. And OpenJPEG defaults to lossless encoding! Try uploading your sculpt maps with OpenJPEG.
I sort of expected that possibility ever since it became clear that they relied solely on client compression. Obviously this leaves room for exploiting this as you can upload whatever you want uncompressed. I still hope some sort of checking is done at LL's side. Off course only a minority of people are in a position to run a client different than the one provided by LL so we need to solve this for everyone.
Yes, Quarl, we are champing at the bit for this one. Reason is the potential for reducing prim count. While there are artifacts the potential for reducing prim count by replacing compound objects with scultpies is essentially zero.
It may help you to understand when you see the effect on a one-prim sculptie column. I have some 500 columns on my sim, and could make huge savings in prims if i could replace these with a sculpted column (also it would be just one image for the entire sim). The image i have attached is of a column that would take 14 prims to create using standard prims, and would if the map were accurate reduce this to just one. The more you stretch the sculptie in size, the worse the inaccuracies show up especially at the squared off top. PLEASE remove the upload inaccuracies!!!!!
Escort DeFarge made changes - 26/Jun/07 10:59 AM
Omei - no good reason, no. i believe it should be easy - i've just been SWAMPED lately...
Blakar - ah, yes, possibly yes. i hadn't looked at it at all. isn't it merely a parameter to llkdu? if you sent me a patch to invoke llkdu differently, i could test it and check-it-in.
Escort - i feel the sculpties are still perfectly useful for their intended (and originally stated) goal of enabling "rough organic shapes".
i understand that residents want to use them for more geometric shapes, and we'll remove the compression soon, but let's have a bit of patience here. Qarl, it might be something we can set using parameters but they are undocumented and not all that many are passed to kdu so I've my doubts. I still wonder what would tip the balance in favor of openjpeg. Having 1 less proprietary library wouldn't hurt. I took a quick look at OpenJPEG and it has not reached the end of optimisation yet. There's plenty open doors that can be kicked in to get quicker code (notably on IA32 which suffers from the fact it has few general purpose registers).
Blakar - my understanding is that if you can make openJPEG as fast as KDU - we'd be happy to ditch KDU. i've heard that Soft Linden has some metrics on this... ?
Hi Quarl, all too often we residents forget to say "thank you so much for this capability!", and I am guilty of that too. The scultpie capability is awesome, and has so much potential for us that we want to use them to the full. What caused me to all caps the "please" was that the response up to that point seemed to be leading down the path of reduced compression, but really for good models we need zero compression. I was concerned that you'd consider reduced compression would be enough to allow full usage. I hope that by offering concrete examples here and in related threads I have showed why the ability to be absolutely exact is vital for the full blossoming of the sculptie era!
Escort, take in mind that there's lossless and lossy compression. Hence if a lossless compressed (read: without inaccuracies) 64x64 is only twice as large as the current lossy compressed one then we're fine. It's hence not entirely the same as turning off compression.
Yes Blakar, lossless, similar to TGA's RLE, which I mentioned previously. While I do understand the issue I still think resolving it has enormous benefits
Sculpted textures need to be in a format which allows many many colors. jpegs do not.
The size of the of the texture isn't really the issue (e.g 512x512 vs 1024x1024) although that is a factor. The issue seems to be the number of colors. The colors used in a sculpted texture determine the xyz coordinates. jpeg compression changes the colors of the original file to use fewer colors. Since the human eye doesn't consciously distinguish between very similar colors, this isn't a big deal for pictures. However, this compression changes the xyz coordinates of the sculpted texture, so when the scuplty is blown up to from .5mX.5mX.5m to 10mX10mX10m, the differences between the original texture and the jpeg are multiplied by 20 and then they are painfully obvious. If we have fewer colors, we have fewer distances, and therefore jagged sculptures. The compression still bites off some fine complex detail. I'm already using 1024x1024 for my car design and it still dented.
I highly suggest making your own format data, a 32x32 matrix data for SL's sculpty... upload them as texture... converted into a Sculpty Data format to avoid any compression crap. We all know that 32 texture vs non-compressed data would favor texture a smaller size...but try seeing 128 to 1024 texture vs non-compressed data that only need 32x32 grid data. As far it goes for SL's format naming.... maybe SPD (Scuplted Prim Data), SLS (Second Life's Sculpture), or SLM (Second Life's Model) ? Ironton - yes - this has been discussed under the heading of "increase sculptie bit depth from 8 to 16." thus far there's been little support for the idea.
Vincent - i disagree strongly. if we're going to invent our own file format, importers, exporters, streamers, animators, procedural generators - we might as well have gone with progressive meshes. I mean when uploading the texture, the server converts it into a new format. No need for more importer and exporter outside of SL. Still using texture to render them in the first place. However, still able to use streaming media for animation and normal texture. Just allowing more form of formats to use for sculpty, not a total replacement.
Qarl - thanks for the quick response. I can't seem to find anything under the heading of "increase sculptie bit depth from 8 to 16." May I have a link, so that I can lend some support to the idea?
It seems that everyone who is commenting here is ignoring the fact that it doesn't really matter how many points are being used to define the sculptie if the points are being rendered inaccurately. Ironton Furse: You should be aware that another problem seems to be that JPEG introduces "artifacts". The color depth is not the only problem. If I'm reading the others correctly, bigger resolutions help here because the JPEG artifacts can end up being a relatively smaller impact on control points.
Qarl, I doubt many SL builders know how to distinguish between compression artifacts and quantization errors. I wouldn't put too much weight on the fact that you are hearing lots about compression but little about pixel depth. What most people who are posting here really want is increased spacial accuracy for their sculpties. I think compression is probably the more significant of the two issues, but people who ask for help in the builder's forum have troubles with both. Once you have made JPEG comprerssion of small textures lossless, and there are stll errors, a second groundswell will build for increasing the pixel depth.
Here's what I really want: I want what I make in blender to look like what I get out of SL. Even if I make a rough organic shape, I still want it to look like the same rough organic shape in SL, not some other rough organic shape. I would be perfectly happy if the number of vertices were reduced in favor of higher precision and losslessness.
The actual mesh is 32x32, isn't it? If we get lossless working, will that make maps larger than 32x32 unnecessary?
i think that watermelon hit the nail on the head - accuracy for either organic or inorganic shapes is more important than higher resolution.
Ima Mechanique made changes - 06/Jul/07 03:43 AM
Okay, as a test I took sculptie-cube.tga, scaled it down to 32x32 and uploaded it losslessly with OpenJPEG. It makes a perfect cube. Not the greatest of tests, but I don't have Maya handy at the moment...
Well that's great Seg - are you saying that the solution is to teach the other 7 million people in SL how to use OpenJPEG to upload sculptie textures?
I deal with more complex structure and would like to see not only increased accuracy, but depth as well. I have been able to work around any weird looking objects. I agree with Omei, but I think both issues should be addressed before it has to be somewhere down the road. I glad to see that the field of Sculptors is growing.
The main problems seem to be the following... someone correct me if I am wrong:
Can't we just allow higher settings, but have them set on the client side, so the client could see a 128x128, 256x256, or 512x512 or even 1024x1024 uncompressed sculptie but everyone else with lower settings would see it at reduced resolution (64x64 or 32x32)? And isn't there a way to pass the drawing of complex 3D shapes inside the Second Life application window over almost entirely to the graphics co-processor in our faster video cards? Ok, now I'm not sure what LL is using for their jpeg2000 compression, but I did alittle research on the math behind this and how to create lossless jpeg 200 compression.
http://www.bearcave.com/misl/misl_tech/wavelets/index.html Heres what I gather from everything I've read. I'm not an expert in the subject, just doing alittle homework and seeing if it can help any of the programmers in charge of this project. Lossless coding is already implemented in the OpenJPEG library.
Torley Linden made changes - 09/Aug/07 12:38 PM
Qarl implemented a checkbox on image uploads. It allows small textures (<= 128 x 128) to upload lossless.
This is being checked internally and prepped for release
Periapse Linden made changes - 15/Aug/07 02:03 PM
/me hears thunderous applause!
Qarl is a very good av!!
As a side comment, I can work around the fact that the axes only encode 8 bits. This is completely deterministic, and easy to grasp. I can encode each axes with it's own scaling, and acheive a resolution of better than 0.5%, and then scale the axes up independently when the thing is imported. I can't easily work around an opaque compression algorithm. Lossless textures are much more important than textures with 16 bits of resolution in each dimension. OK, We still have 3 flaws in sculpties now even though one(most serious) flaw was partially fixed:
1) Number of vertices for a prim is capped a 1000. (Qarl really should add a number indicating the number of vertices in a prim or linked set of prims to the Object Information Dialog/Window, since increasingly this number is going to now become more relevant than the number of prims in an object for some builders who build primarily with programs like Blender, Moment of Inspiration, Wings 3D, Maya, or SculptPaint). 2) The Level of Detail (LoD) number is set to integer 3 for the display client. So that's 64x64, when if the user could change it to any of these: 3) Sculptie UV maps use only 8 bits of data for each X, Y, and Z point. We could have a new object, known as a "Super Sculptie", that could be made up of either two single-layer sculpt map image files, or a single dual-layer image file, for a total of 16 bits per X, Y, Z (R, G, B) point. Seem impossible? Well, according to this web page: hey Miller -
chalk this one up to "probably someday". right now, our "average user" has enough trouble rendering what we have... Im a newbie to sculpties, but in attempting to create molding with some flat faces (an "inorganic" shape) I was badly disappointed. Thru experimentation, I realized it was the JPEG compression that rendering my attempts useless, and was about to give up until I read this page. GOOD GOOD GOOD!!!!! When will lossless sculptie textures be implemented?
Torley Linden made changes - 29/Aug/07 04:20 PM
FIXED in 1.18.3 Release Candidate viewer, an optional download. More info about what this means:
» http://blog.secondlife.com/2007/08/29/new-update-process-introducing-release-candidate-viewers
Torley Linden made changes - 29/Aug/07 04:26 PM
The release notes for this really should clarify that the fix was to enable lossless encoding on small textures... Perhaps list it as a new feature rather than the generic bug's title?
Qarl et al, thanks for hearing our pleas and coming through on this with the Release Candidate v1.18.3(2).
I'm seeing problems with lossless uploads, however. Using the "sculptie-cube.tga" provided above, I can get perfect edges with the lossless upload. But when I upload a more complex sculpt map using the lossless option, i see even worse results than when using normal compressed sculpt maps. In some ways it almost seems like lossless is compressing even more aggressively? For comparision, a sculpt map uploaded via SLImageUpload from the same .bmp displays no artifacts whatsoever and is completely true to the original model. See images linked below for more details. http://jamma.files.wordpress.com/2007/08/20070830-lossless-issues01.jpg Yes, same issue here.
A map that includes 'smooth,organic' AND 'sharp' areas gets heavily blurred on looseless upload. On the image you see the differences-pay attention to the lowest line of pixels:
basic image: sharp line
Salid Sewell made changes - 31/Aug/07 01:03 AM
(In regards to image #5 - "an examination of lossless")
This image displays a sculptmap in it's "Original" state, "Lossless" state, and then a comparison of the two and all the resulting noise that's introduced in using "Lossless" compression. It's broken down so the individual color channels can be examined as well.
uchi desmoulins made changes - 31/Aug/07 04:24 PM
Oh, make that image #1. I didn't realize these things were numbered in alphabetical order.
uchi desmoulins made changes - 31/Aug/07 06:17 PM
Someone make sure to ping Qarl on this, Lindens don't always notice when bugs are "Reopened" right now, there is no notification or anything. In the future when something like this happens (a fix is still buggy) it may be better to open a new bug.
hey all -
yes, i'm looking into the problem. at first glance - it seems to be a problem DOWNLOADING the new images. if you download them directly (out-of-band) from the asset server, they retain their perfect form. will give you all a heads-up when i know more. Closing this issue as it has been resolved, yet buggy. The new issue of lossless not working correctly within the RC is posted here:
Delerium Hannibal made changes - 13/Sep/07 07:20 PM
What do you mean "resolved, yet buggy"? There was a problem. The problem has not been fixed. It remains a problem as it was before. That is not "resolved." "Resolved" means they fixed it.
This issue was originally closed when the lossless option came out on the RC Viewer. It was Re-opened because at times it wouldn't work properly. In addition, there is already an issue that addresses the same problem:
Miller Rust made changes - 26/Sep/07 04:28 AM
Rob Linden made changes - 22/Dec/07 03:22 AM
Rob Linden made changes - 22/Dec/07 03:33 AM
Rob Linden made changes - 22/Dec/07 04:00 PM
Rob Linden made changes - 22/Dec/07 10:58 PM
Ann Otoole made changes - 03/Jun/08 05:29 AM
Ann Otoole made changes - 03/Jun/08 05:43 AM
Sue Linden made changes - 13/Nov/08 11:37 AM
Sue Linden made changes - 13/Nov/08 06:30 PM
Sue Linden made changes - 13/Nov/08 07:03 PM
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Sculpties suffer HORRIBLY from JPEG artifacts
