|
|
Re: rounding vs EXACTNESS (was Re: proof!) (Community)
Re: rounding vs EXACTNESS (was Re: proof!) // Community
Feb 5, 2001, 3:24am
Well, whatever. How about talking to Roland and HamFon about it since they don't seem to think this is a big enough issue to actually fix it. And I suggest other people confront Roland and HamFon about these bugs too.
[View Quote]
[View Quote]> "eep" <eep at tnlc.com> wrote in message news:3A7D8B7F.9FAC4D3 at tnlc.com...
> just rather have object placement done RIGHT instead of trying some
> half-assed, inexact method. Try looking around with the mouse REALLY slowly
> and you should see everything shake slightly (get real close to things).
> This seems to be related to avatar movement/rotation jerkiness, gaps, and
> seams too.
> maybe I should add that avatar position and the positioning of the points
> inside the objects and stuff like that should have the highest precision
> available. An object itself, however, should snap to the grid. Since you
> can't place objects any finer than the width of the grid anyway, since the
> smallest move is as large as the grid spacing itself, this should make no
> difference in building. However, it will be impossible for the floating
> point errors to move an object with an amount that is smaller than what you
> can correct manually if you round the place of the object itself to the
> nearest grid point. This is what in my opinion is causing the gaps.
>
> An example: you have a wall which is exactly 300cm wide. You place one,
> clone it and move it around. When you put it next to your first wall, it's
> origin is not 300cm away from the origin of the first wall, but 300.01cm due
> to floating point errors. This causes a 0.01cm gap, and since you can only
> move objects 1cm at a time (iirc) you can't correct it. Now, if the object
> placing code would have rounded the wall's new place to the nearest cm, the
> object would have been put at exactly 300cm, with no gap, and everything
> would have been fine. This actually is the right method, it's not inexact
> despite the rounding. You'll always have errors, no matter how much bytes
> you use for the numbers. You can, however, anihilate those errors by
> rounding them out. Leaving them in is the inexact way.
>
> them to Roland, which hopefully means he'll actually fix it.
> the
> movement
> able
> finer
> iirc,
> object
> perform
> cell
|
|
