precision issues

It's not precisely what you'll see in SL, but I'm not sure if it's a fixable bug. I'm planning yet another rewrite of the baker code so that the buffer maps are seam aware and store the 3D value rather than the RGB. This will allow the bounding box to be created just from the values for a particular map rather than the entire mesh, so the joined mesh stuff won't be limited to 255 steps. I'll see if it can be fixed in the baker rather than the importer then.

git diff c9c34e639 c9c34e639^ is the command to show the changes of that particular commit. With so much changed since, it's probably best to manually edit sculpty.py rather than using a patch file. When referring to git commit IDs, you just need to specify enough to uniquely identify it. By adding ^ on the end it means the one before it.

You can use tags too. git diff 0.9.0 0.9.1 shows what changed between those versions, just switch the order to get a reversal patch.

If there is a difference between different versions of Python then we need to identify why.

The baker / import issue I believe is due to floating point precision errors. In other words, it's too accurate :) By scaling up and converting to integers you are introducing an imprecision, which is basically what we need to do, I'm just not sure that's the right way to go about it. I have something more like this in mind:

adjust = 1.0 / 510
r = floor((x + adjust) * 255)
g = floor((y + adjust) * 255)
b = floor((z + adjust) * 255)

So basically add half a step to each direction before converting to the RGB integers by rounding down. Using an object scale of 255.0 for ease of explanation, the 0.0 to 255.0 is converted to (0.0 to 1.0) x, y and z values to feed the above code. So tracing a few values through we see:

0.0 to 0.499999 becomes 0

0.5 to 1.499999 becomes 1

122.5 to 123.499999 becomes 123

123.5 to 124.499999 becomes 124

254.5 to 255.0 becomes 255.

In other words, a pretty much ideal way for the baker to convert the mesh dimensions to integers. We just need to remove all the earlier hacks to precision and use accurate floats to this point, which is what the new bake map code will do. Any precision errors then can be tuned out just by setting the adjust value to say 1.0 / 508 or 1.0 / 512 depending on which direction the precision errors affect things.

I've committed the new baker code and it fixes this issue. It's pretty much a complete rewrite of the bake code, and I've only put it through basic tests. This is even more flexible than the 0.5.x baker as it combines edge rendering with a sculpt map aware fill. The baker no longer gives up if the UV map is outside the image area too, it'll just bake the parts that are inside the image.

Just change this back to active if you can still find a problem Gaia, but hopefully it's fine across every case now.

Sorry, the code excerpt got all messed up. Let me try again:

sculpty.py:

line 119 from:

        self.scale = self.range / 255.0

        self.center = (self.min + self.max * 0.5) / 255.0 - XYZ(0.5, 0.5, 0.5)

to

        self.scale = self.range / 256.0

        self.center = (self.min + self.max * 0.5) / 256.0 - XYZ(0.5, 0.5, 0.5)

line 1303 from:

                    x = p[0] - 0.5

                    y = p[1] - 0.5

                    z = p[2] - 0.5

to

                    x = (255. / 256.) * p[0] - 0.5

                    y = (255. / 256.) * p[1] - 0.5

                    z = (255. / 256.) * p[2] - 0.5

Hi Domino, thanks for the enlightenment. I still had doubts because one can't put too much trust on a wiki, or any documentation for that matter. The evidence you presented removes any doubt, so I stand corrected.

I had the impression it improved due to the change I made but obviously it was something else I changed in the mesh, probably.

Dividing by 255 makes a lot more sense and it's much more useful so I'm glad the actual implementation diverges from the documentation in the wiki.

Thanks!