any eta on cut bug yet?

Been waiting for months now, is this ever going to get fixed?

Path Cut Begin and End
0.300 ends up as 0.299 ,
0.600 > 0.599
ectectect,

this is major bug for those who use cut, yes this make cracks/overlapping prims as SL refuse to set it correct.

type in 0.3 0.6 or something... leave edit, go back sometimes its 0.299 , cant do anything for months on months, this is very annoying.

Yes there was a time this actually set correct , now pff... x99999 something

I just tried it. 0.300 is 0.300 and 0.600 is 0.600. Actually it's always been that way.


What you have is really really strange. That's a kind of bug that should be universal. A long time ago I would have said it's a defective coprocessor chip. But that technology is very stable right now so I'm not even sure where to start.

There are some numbers that get rounded and sometimes the rounding is inconsistent. But 0.3 and 0.6 are normally not among those numbers.

It's normal rounding error, but it should be handled by SL one way or the other.

Binary fractions can never be exact to the decimal digit, they're always a little off. Some decimal values (0.5, 0.75, ...) can always be exactly represented, but others (0.3, for example) are inherently approximate.

For path cut they seem to try and adjust to the nearest digit in the UI, so what value you get may actually depend on whether you approach it from below or above. This also effects certain cuts that should be exact (try the progression 1/8th, 1/16th, 1/32nd...), they seem to get tweaked up or down... and this makes some effects almost impossible.

They should either abandon some of the cut range and assign exact decimal values to each bit pattern, or make and represent the cuts as an exact fraction so they're always as precise as possible.

I've seen this problem, too. You CAN set the cut to something else, and it'll even adjust the prim to fit what you've typed, but next time you get a full prim update from the sim, it's flipped back to 0.299 or something similar. You can even watch it form a crack as the prim goes from 0.3 to 0.299. You can be fooled that it worked as you expected if you type 0.300 and wander off, but you can force an update by changing the hollow or somesuch.

Ok, got it replicated. It may be related to how the prim handles path cuts.

I was able to reproduce it using the box (as shown). It also happens with the cylinder and the cone (which is also a cylinder).

It doesn't happen with the sphere, torus, and tube.

In conclusion the rounding issue or un-rounding issue applies to prims that are classified as extrusions.
Cube, pyramid, prism, cylinder, cone

The prims that are objects of revolution are not affected.
Sphere, hemisphere, torus, tube, ring

Now if you think of the objects of revolution as extrusions in a circle, the profile cut should suffer the same problem. It doesn't.

That means, there's a chance it can be fixed.

Sounds like the object editor is allowing people to enter values that can't be represented by the object download format (which uses very small integers to represent fractions) and the code that unpacks the downloads in the client is making different rounding decisions than the editor.

I have seen this problem in profile cut for toruses and cylinders, but there it goes the other way. I can't make a profile cut of a torus to an exact power of two fraction beyond a certain point... it rounds up or down to a decimal even though internally and in the download format the data is actually the value I want.

i sent a bug report on that matter like ...... almost one year ago and got told it was going to be fixed soon.
make your own conclusions.

Interesting... I thought it had to be storing as integers internally. What's the precision? Integer fractions of 360, 240, or what? I suspect that the path cut value on cylinders and tori actually is stored differently, because I seem to remember having trouble getting 1/8th path cuts to work with a torus.

Given that this is stored internally as an integer, it might be nice if it wasn't displayed as a floating point AT ALL. The floating point just gives us the impression that we have more precision than we actually do, and I hate how the interface always wants to scroll part of the value off the left end of the box, giving me no clue what's actually entered into the box until I hold down my left arrow key.

I wonder if some kind of slider system could be used. Something like a slider bar with two sliders, one as the begin cut and one as the end. As we drag it along, the exact fraction (1/8, 1/16, 31/240, whatever it is) could display above each slider. That last could be an option for power users, where the default is not to display and just to show a percentage or something. I wonder if this idea would make for better usability? Then again, I suppose power users might STILL want to be able to edit the numbers by hand.

That's what it seems to be doing: storing the data as an integer representation of a fraction of a complete circle.

And, yes, I've had problems getting path and profile cuts to an exact power of two. I've played around with this a bunch, and I beieve that this is what happens:

The client is capable of rendering the cut as precisely as you like... it uses floating point numbers or high precision fractions internally. We know they do use floats for some values based on comments by Lindens and the behaviour of avatars at very high altitudes.

The editor attempts to restrict you to a number that can be represented in the editor window, AND to a number that can be represented in the packed format.

When you make a change, the editor doesn't actually pack, upload, download, and unpack the object. It just keeps the version of the object displayed in sync with the last change it sent up to the server.

So the result is that there's two limits on cuts (and other settings):

1. The number of decimal digits displayed by the editor. That's why 1/8th cuts get shifted from 0.125 to 0.13.
2. The number of bits in the packed format. That's why cuts to 0.4 get converted to 0.399.

It's really frustrating. I can see the programmers making "reasonable" decisions at each stage, but the end result is just counterintuitive.