square 32x32 0-248.tga (= flat square plane sculptie 32x32.tga)
square 64x64 odd-even-equal 0-248.tga
square 64x64 sequential 0-252.tga

Then I edited the above textures by applying an auto-level to the red- and green channel individually:
(full color range)

square 32x32 0-255.tga
square 64x64 odd-even-equal 0-255.tga
square 64x64 sequential 0-255.tga

Observations:

Switching between partial and full color range alters the object's size, but not its UV-mapping, on all LOD's.

-Switching between 32x32 and 64x64-odd-even-equal looks exactly the same, on all LOD's.

-Switching between 64x64-sequential and odd-even-equal alters the UV-mapping, and only for the partial color range, it changes size too. Both on all LOD's.

-The bug this report is about is present on all of these textures, but...

-On the 64x64 sequential textures the top row and right column are not compressed but stretched a little (this is hard to see, try ALT-zooming around the LOD threshold)

======

I also generated a cillinder with filterfactory. The UV-mapping wraps nicely around the cillinder, the 32nd row falls off the end of the cilinder on high LOD. On lower LOD the UV-mapping error appears again.

So the error seems consistent.

SQ01 to SQ06 are the same as the old square textures, but flipped vertically, so the vertices with the lowest coordinates are in the bottom-left corner, where the sculptie starts counting. The observations in my previous post are unchanged.

SQ07 is the same as SQ05, except for the last 2 horizontal and vertical lines, which are the same as in SQ03.

SQ08 is the same as SQ03, except for 3 white pixels somewhere in the middle.

SQ09 is the same as SQ03, except for the last horizontal and vertical line, containing 255 in the blue channel (Z-coordinate).

======

New observations:

-switching between SQ03 and SQ07 makes no difference.
-switching between SQ03 and SQ08 makes no difference.
-applying SQ09 makes the 32nd row and column of the checkered grid appear, on the faces that are standing up. The UV-mapping error DOES NOT occur.

======

Conclusions:

-The 32x32 textures load correctly because the data is so simple it can be (de)compressed at a 1:8 ratio (VWR-2404)

SQ08 shows that only 1 in 4 pixels is actually used for vertex-coordinates in 64x64 sculpties. The lower-left pixel of each block is used. (except at the top and right-edges!)

-SQ09 shows that in 64x64 sculpties, the 64th horizontal and vertical lines are actually used as 33rd lines of vertices!

======

So, this bug is explained. For the LOD system to work well on open-stitched sculpties (planes and cylinders), a 33rd line of vertices is needed. That way there is a highest LOD-priority line at both ends, and the object won't change its outer shape at lower LOD's.

But 32x32 sculpties don't have room for a 33rd line. At high LOD, the 32nd line acts as 32nd line of vertices. However, at lower LOD the 32nd line acts as if it were the 33rd line of vertices, causing the UV-mapping to change at the edges.

64x64 sculpties offer a possible workaround for this bug, but if ever we are allowed meshes with 64x64 vertices, this remedy will turn into the same problem (only reversed). Apart from that, it seems silly to send 73% of totally unnecessary data.

I doubt if any of the existing software for making sculpties takes into account this behaviour. The best solution is, while fixing VWR-2404, to look for a way to allow 33x33 and 32x33 sculpties. That would take care of all present and future problems.

Type Points being used from sculpt-texture
____ ____________________________

Rows x Points per Row

Torus 32 x 32
Sphere 33 x 32
Cylinder 33 x 32
Plane 33 x 33

With the appropriate stitching they all end up at 33 x 33

Yes that means 64x64 Pixels are needed to get the full mesh (for Torus 32x32 is enough)
This will result in some unneccessay data being sent ... but not 73% because (even lossless) compression reduces the overhead.

I suggest closing this issue because it is not a bug. This is the way Sculpt-textures were design to be.

I agree using a 64x64 is a solution. But it doesn't take away the UV-mapping error on the 32x32, which can be fixed easily.

The advice is this: Don't use 32x32 sculpties, except for torus-type objects. For the others use 64x64 sculpties.(if VWR-2404 allows)
I'll leave it up to Qarl to close this report.

When you read this report from top to bottom you can see me reinventing the wheel. I don't mind reinventing the wheel at all, in fact, i enjoy it!
What I do mind is taking up your time at this issue tracker for something that's not a bug at all. It's a total lack of documentation.
The page commenting about how sketchy the documentation is, is almost as long as the technical description itself.

Yesterday at the office hour I was pleased to see how Qarl spent over an hour answering questions about how sculpties work, with a lot of patience, and attention for everyone. Excellent!

But is Qarl's office hour a tutorial class? Is the JIRA a tutorial forum? Preferably not.

All we need is documentation.

Thank you for your attention, and if there is any way I can help, let me know