Building Precision problems

Hi there!
First of all, let me apologize for my crappy English, not my mother or father language

I build some buildings and I don't use any of the "helpers" available in world.
I'm an experienced AutoCad user and that is the only help I use on my projects.
I model all my buildings in 3D and then I just use the values from AutoCad and paste them into SL prims.

Now my problem is... when prims are aligned with Y, X or Z at an 0 angle, everything goes just fine but if for some reason (you know... a lot of reasons lol) I need rotate some prims, SL looses all precision... is there any secret related to this problem?

I know the X Y Z values of a prim is the absolute center of it and when we are dealing with, mainly, boxes this shouldn't be an issue at all, so... why they don't get the correct location?

Thank you in advance for your answers.

Rockas

exactly what prims are you using when you lose all angles?

and when you refer to losing angles are you reffering to the texture that is not correct or the position and angle of the prim?

@Larrie Lane
Sorry if I didn't made myself clear.

I don't loose angles... the prims I use are mostly boxes as I'm talking about Buildings.

Let me try to give you an example... random numbers, I'm no inworld at the moment.

imagine two box with the following values:

x = 10.00
y = 00.50
z = 05.00


One has all angles with 0 value.
the Second has a rotation in Z of 90º

now... the 1st box (0 rotation) is located in X0 and Y0 -- the second box should be X8.359 and Y-3.462 so the the outside side of the wall gets perfectly aligned... well... usually they don't

Hope this is more clear... i may post some images as soon as possible if you can't reproduce it.

edit: I hope I'm not saying any mistake 'cause I just remembered that those issues happens mostly with "cuted boxes" i don't remember exactly if the same happens with full boxes

Rockas

Okay, here is my answer which I use cause maths here do not work with positioning, size's and the X,Y,Z co-ords, there are too many numbers to remember or write down.

Example:

take 2 cubes, one on top of each other both 10x10x10. to make sure they are all aligned the X,Y co-ords should be the same, the Z should be 10.000 more than the bottom one.

now for bothcubes the Y position is 205.400 and you change its size to 0.500 it will now be centred on top of the other box and its Y co-ord will be the same.

To align it you would have to move it 4.75 metre in SL terms to Y: 210.150
If its size was 1.000 mtre in SL terms you would have to move 4.5 metres to Y:209.900

So heres a qucik list of number examples

Length Position
10.000 Y: 205.407
9.500 Y: 205.657 0.250 mtres
9.000 Y: 205.907 0.500 mtres
8.500 Y: 206.157 0.750 mtres
8.000 Y: 206.407 1.000 mtre

As you can see every half metre is equal to quarter metre movement.

The way I align prims is to use the arrows for quick movement and position as near as possible, take a quick look at the co-ordinates and the last number should be the same as the piece you are aligning it too. Then change the 2nd number accordingly.

Some people do use various builders tools for this and scripts, but that's personal preferencel. There is however another thread related to which builders tool people are using and since I last looked most people use the SL built in tools from what I gather.

The other point to note:

Is that if the 0.500 mtre top prim was aligned to the left edge of the bottom prim, to align it to the right you would have to move it 9.500 metres

example:

10x10x10 Y: 205.400
10x0.500x100 Y: 200.650 this would be left aligned

to right align position would be:

Y: 210.150

The complication comes when you don't have prims of round numbers, its easy to understand that if something is 0.500 wide and to make it align with the other which is 10 metre wide you would have to move it 9.5 metre or the same position as the 10 metre to centre it or 4.75 meter from the centre to either side.

one other thing.. prims arnt exactly square.. there is a slight differnce on sides.. even when the values at 10x10x10 they arnt exactly the same .. ive seen it when ive tried to stack prims on top of eachother in long rows.. you notice at the end that the prims are messed up its wierd.. but its there.

Accuracy is a relative term in SL.

First on using rotations in SL.
SL uses normalized quaternions internally and 'translates' these to an X,Y,Z angle for the interface/client. Basically, this translation often causes errors in the actual angle calculations. Make sure to check your 'angles' after manipulating the number boxes, by reselecting the object again. And especially after manual rotations and linking/delinking, as these all cause a recalculation (including the rounding errors) on the rotations used.

And even then, realize that the X,Y,Z angles are basically an approximation of the internal quaternion values, which causes things that 'should be' ok to not align perfectly.

On positions and the user interface.
Prim positions accuracy (how many decimals are stored), seems different in UI, actual sim and what's stored on the asset servers. So weird as it may sound, it's possible to 'wiggle' a prim on high zoom using the edit tools, while its position stays the same according to the edit window. So the accuracy of the edit window is less high as the actual visible accuracy in world. This means that the rounding you maybe do when converting from AutoCad to SL can possibly cause errors in display.

Another facet to take into account is SL LOD (level of distance) approximations. Basically objects are simplified (polygon count is reduced), the further away you are. This shouldn't be a big issue on your average box prim, but with other prims it can cause sudden gaps which weren't there when you saw the objects from a different distance.

Exactly what Damanios said - the build tool is only accurate to +/- .001 but actually, precision is +/- .00001 but you must argue with server. There are scripts to do that with. But, if you zoom in extremely close, you are beyond the +/- .001 accuaracy anyway.

Don't forget that SL uses "floats" for all measurements. With a mantissa of 24 bits, they are good for about 7 significant digits (2 to the 24th is a range of about -8,000,000 to +8,000,000). So on the north west part of the sim you will only have about four decimal digits of accuracy.