Small oblongs broken ???

Hi;

i tried to make cubes with small oblongs with 4*4 faces, 6*6 faces and 8*8 faces. I tried with sculptmaps of size 16*16 pixels.

But they all get massively distorted, although the sculptmap looks correct. and yes i use lossless

I did another test by creating a sculptmap of 8*8 pixels from a 4*4 faces sculptie. The map does not get loaded correctly. It renders dark grey although the preview window has shown the expected object shape.

Has anybody encoutered similar effects ? Is it a bug in the SL (rc-candidate-) viewer or a limitation of sculpties?

try 16 x 16.. That's the smallest pixel square my scripts use.. Must have done that for a reason.. I think smallest ratio is a 8 x 16 image. I remember not being able to upload a 8 x 8

when i started my trial i used the settings as they where generated by the scripts:

4*4 faces map-size 16*16
6*6 faces map-size 16*16
8*8 faces map-size 16*16

all 3 work when i keep the caps of the cube open
all 3 fail when i close the caps

From what i saw in the new LOD-calculator all 3 sculpties should be possible and LOD should be completely disabled for them. Also when i reimport the sculpt-maps to blender, everything is 100% precise and correct.

But my cap closing must trigger something in the SL-viewer so that the rendering is broken... i will check it again later and make some screen shots...

I just tested a simple cube. Same vertices in 16x16, 32x32 and 64x64 maps....doubled up and quadrupled up in the larger maps. The result was a disaster, and very strange. Will add a picture if I can. The 64x64 was perfect, but 32x32 and 16x16 were terrible. There is some serious messing about with the vertices. Have to see what actually went into the source code! This is 1.23.1 RC. I'm going to look at the same things in 1.22.

Is this what you're trying to do?



It's just resized in PS.

(courtesy of artoo)

That looks pretty good. For a torus, you don't need to worry about the extra edge pixel, so simple resizing should be ok. Also looks like it preserved the shape ok (in detail?). It didn't with my test map. which has sharp edges and so can't tolerate any interpolation, whereas a smooth thing like your torus can.

It does seem that using a torus is the only way to get around it at the moment.

Here is my picture. I think we see the same ? Unfortunately i started my tests only this afternoon after the new rc-viewer was released. I can not tell, if it was different before.



the sculptmap sizes where:

facecounts -> image size
4x, 4y -> 16*16 bit
6x, 6y -> 16*16 bit
8x, 8y -> 16*16 bit
8x, 16y -> 16*32 bit
16x, 32y -> 32 * 64 bit
32x, 32y -> 64*64 bit

Qarl completely rewrote the vwr-9384 patch, and as I'm on 64 bit linux where builds were tough to do, his version never got tested. He never seemed to understand why the points we raised about supporting undersized sculpties and sticking with the 2 pixels per vertex was important. So, sadly, I wouldn't be surprised if the implementation doesn't meet expectations.

With my health problems I can't give this the attention I did last time. I hope someone can check it out and see what's going on.

Well. Basically it doesn't work at all, as far as I can see. It does use the smaller numbers of pixels, but it completely ruins the vertex coordinates. I will see if I can find time for the source. here are some wierframes in 1.22 and 1.23. This is a simple cube, with the expected tow-pixels-per vertex at the 16x16 map, giving 2x2 quads per face. It is just upsized without interpolation for the other two - so the vertices are duplicated and the then quadrupled in each dimension. (the endeg pixels adjusted correctkly). The 64x64 map works fine. The others are completely useless. [...bad reasoning removed....] Seems to be something in the lossless upload pipeline (see below).



This is unbelievably depressing.

It'll come.

I'm just a bit shocked that nothing at all seems to be tested before it's implemented, they should go back to calling the RC viewers previews because there's nothing releasable about them for the first few iterations.

Oh dear, this is going to take for ever .... does anyone know a diff for windows? Omei, Domino, what do we do ... back to the old jira, or atart another one? I'm afraid Qarl will say there's nothing wrong because we shouldn't be using sharp edges!

Okay, nailed it.

Turn off lossless.

Doesn't work for 8x8, but was it meant to?

well, it makes my cubes better, but not good. There is still something totally wrong with all of them except with the 64*64 version.

But can you explain, why turning OFF lossless improves the quality, while we learned for ever since sculpties came along, that turning ON lossless is essential for keeping them precise ? I would have expected everything but not that ...

Read up about the original lossless bug, it applies here in more or less the same way.

Looked at the source, and the changes to sculpt_calc_mesh_resolution are right, and the wireframes do show the correct numbers of vertices being used. Then, thinking for a bit, the vertices in the distorted guys are certainly using values that are not present in the map before upload. Therefore it must be, as Ponk suggests, a corruption of the map between the upload source and what ends up in the sculpty. That is to say it is in the image processing stuff.....whether it's in the lossless upload and/or any other components of that, I can only guess. But anyway, attaention has to shidt there rather than to the sculpty code, I think. Apologies to Qarl!

Tried Ponk's suggestion. Indeed there is a huge improvement, but there is still some distortion, presumably from the lossy compression. Good enough for smooth sculpts, I expect, but not for edges. I think this confirms that the problem is with the lossless upload of small bitmaps. This still needs to be fixed for the small maps to be properly useable.

How could a lossless upload corrupt the data? Bizarre. Could be in the viewer or server! Even in the asset server?

I have just verified, that "standard sculpties" with bitmaps 64*64 get uploaded and displayed correctly when lossless mode is checked! And they get distorted when i upload them with lossless unchecked. SOmehow the opposite seems true for all other sculptmap types...

Maybe that helps to isolate the problem ? Maybe its just a wrong if then else clause somewhere where a decision is taken between "old sculpties" and oblongs ?
Just a guess, probably wrong ...

Hmm. Flat XY planes are perfect in lossless, slightly wobbly in lossy, for 64x64, 32x32, 16x16, but absolutely terrible for 8x8 lossless.

Have you confirmed that it is something in the upload process? If not, it could also be in the JPEG2000 image decoding, or the texture caching, or who knows what else. Bugs have been found in all of these before.

I think a new one is most appropriate.

When I say upload process, I really mean the whole pipeline including all those things - everything from when the viewer reads the file to when it gets used to make the vertex list. This involves the viewer at both ends, but also the server and asset server. It needs someone to look at the numbers at every stage to even know exactly where it's happening.

However, if (a big one) the relatively small distortion of the lossy ones is just that to be expected from the lossy compression, and no more is introduced with these, and the fact that the lossless compression gives much greater distortion, does point to a part of the pipeline that is only executed for lossless upload. Whether this is the lossless compression (not just raw data?) itself, or something consequential down the line, I would have no idea.

Lots of information in http://jira.secondlife.com/browse/VWR-2404 which seems was never fixed for sizes less than 64x64. It's all to do with truncation of the data streams. Smaller than 64x64 was not supported at that time. It does mention the (imperfect) work-around by using lossy compression for smaller images.

This is reopened in http://jira.secondlife.com/browse/VWR-8551 Maybe we should add comments concerning the explicit sculpty effects to that, vote for it, and bring it to Qarl's attention at Office Hours. I am sure he will be delighted (not).

Assuming this is it, it's nothing to do with upload, just with retrieval!

i placed a comment into that issue and voted for it.

Has anyone tried an alternative upload like slimageupload or the new one? I haven't used them for a while, indeed I'm not sure what it's called anymore.

BTW, the prims in Gaia's pic aren't oblongs.