Prim begin/end -- editing text boxes

If this is well known, forgive the repetition.

First, the text boxes used for prim editing are too small to hold all the digits. This makes for confusion when you think you have an accurate measure but the last digit of the fraction is invisible.

Second, the begin/end measurements for different shapes are not the same. It appears that it measures percentage of the perimiter/circumference instead of the angle of the cuts. This is a shame because it means all kinds of cool combinations of trimmed prims of different types won't work properly. Please use percentage of angle.

While you're at it, please add another (any) decimal place to both the begin/end.

Finally, please convert hollowness from a percentage to a fixed measure. Please please please!!! Percentages are very clumsy and force all kinds of re-calculations if you want to change the size of the prim.

Much of this can't be changed due to the fact that the description of a prim as sent over the internet is VERY tightly packed. Adding even one more decimal place to a value would increase the size of the data for each and every prim in the world.

I, for one, would love to have more accuracy in many of the measurements. Top Size in particular would be wonderful if it was more precise.

As for changing hollow to something other than a percentage, what would you suggest?

Tiger,

Have you actually seen the prim format? I haven't, but I would love to.

Right now, the begin/end percentages can be any of twenty-one values (including zero). As this is not a power of two (which every bit field or fixed-size bit stream has to be), they are seemingly not utilizing all the space they have for those values. However, as begin and end are related (i.e.: begin is always less than end), there may be more to it. (I calculate 210 possible begin/end combinations -- also not a power of 2.)

But the main thing that bugs me about begin/end is that, if you use the same values for a rectangle and a circle and they are not multiples of 25%, then the angles do not match. This is highly annoying, and seems unrelated to the prim structure format.

Instead of a percentage for hollow, I would want the same kind of value as the size in X or Y. (Of course that would,as you say, require enlargement of the prim data structure.)

Fixing the U.I. is certainly possible, and, I think, I high priority. Technically it is a bug. There is certainly room to enlarge the text boxes.

I agree with you about making the text fields match the max length of the values they can hold.

As for the packing of the data, I have not, of course seen it. But there are tighter methods of packing than mere bitfields. I'm sure they are using such methods.

Interesting. Can you point me to any relevant references? (I'm in computer science, so make it as technical as you want.)

There is only one reference in computer science. It is Knuth

An internet reference would be preferable. I'll pick up the Knuth books one day, but not today.

Well, gee, it's not like I didn't think they were using compression. But the data has to be decompressed to be useful. Once it's decompressed on a client computer, the data fields have to be a fixed number of bits. This is what I was talking about: the data structures used when not in the data stream.

Oh...

Well, those could be 128-bit bools for all I know.