1. I think the power-of-two requirement, that disallows 33x33 etc, for bitmap dimensions is a function of the SL image upload system, not of the sculptmap rendering per se. (That having been said, it may be that the rendering routines then assume they are receiving a power-of-two-only bitmap, I can't remember and don't have the source code here.)
2. The number of faces depends on the level of detail, which depends on how near you are to the sculpty. It goes 1024, 256, 64, 36 (36 for strange historical and backward compatability reasons, where you might expect 16). For the purposes of this dicussion, I think we are only concerned with the highest LOD, so 1024 rectangles (2048 triangles).
3. 1024 rectangles, as a plane, can be 32x32, 16x64, 8x128 etc. However, that requires 33x33, 17x65, 9x129 vertices....
4 ....unless some of the vertices are implicit by the stitching together of the edges of the plane (one for cylinder and sphere topologies, both for torus) or gathering together in a pole (sphere only).
5.For the stitching, the 33rd (etc) pixel is necessarily identical to the corresponding pixel at the other end of the row/column, and these are generated by replicating the rgb values for the identical row/column. Thus the relevant dimensions of the stuitched topologies don't really need the extra pixels, while unstitched ones do.
6. So does the poles of the sphere, where the middle pixel of the 1st/33rd (etc) row is replicated across the whole row so that the vertices are all in the same place, the pole.
7. Since upload is restricted to powers-of-two dimensions, to get 33 (17 and 65, etc) vertices, you have to use 64x64 (32x128, etc) for all except the torus, which has two stitched edges. The rendering code uses alternate pixels starting at row/column 0, and gets the additional pixel from the extreme end (so using , eg 0, 2, 4 ......, 58, 60, 62, 63). If you try a 33x33 bitmap (or any other non-power-of-two) it will be resized by the client before uploading, which will ruin everything (I think - never tred!).
Next bits not quite so certain, but I think the situation with 32x32, 16x64, 8,128 etc is as follows....
8. Presently, the sculpty rendering code will interpolate whatever size bitmap it is given to get the expected number of pixels. I can't remember whether it will make a 32x32 to 33x33 or to 64x64 (and even less with the oblongs). This is probably why the smaller bitmaps don't work as expected.
9. Supposedly after viewer 1.23 comes, the rendering of smaller bitmaps will be changed to allow the generation of sculpties with fewer triangles (and thus faster rendering, and maybe eventually animated vertices). These changes will not affect the rendering of the presently optimal sized bitmaps (64x64, 32x128, 16x256, 8x512). So these should be used for all sculpties being made now.
10. Bitmaps bigger than the optimal sizes do not provide any extra control. As Gaia said, they are just sampled at a subset of pixels. Bitmaps that are not exact powers-of-two domensioned will be resampled in the client before upload, and the consequences are unpredictable (by me, at least).
There are a number of threads in this forum where all this was discussed (look up "oblong" maybe), and the final discussions are documented in Domino's Jira mentioned by Omei
http://jira.secondlife.com/browse/VWR-9384. The old threads contain details of eaxctly what happens to non-optimal bitmaps, and the jira cointains some tables with details of how small oblongs should work in viewer 1.23.
Ii is all rather complicated, but I hope that helps a bit.
PS. I should add that there are other sizes I have not mentioned that are still powers-or-two in both dimensions, but not exactly 4096/4^n pixels, such as 64x128, 32x256 which behave a bit differently. These remain suitable for "organic" sculpties, but have horrible LOD switching problems for "geometric" sculpties with sharp edges (details in the jira tables).
:
