 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It's the same type of confusion as caused by functions taking radians and
rotate taking degrees...
> /*- Warp -*/
All the trig functions use radians, but rotate, and camera angle are degrees.
Sometimes I have to convert angles five times in one macro. Any idea why they
didn't keep things consistent?
--
Dan Johnson
http://www.geocities.com/zapob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A959B66.9B14E1DA@hotmail.com>, Dan Johnson
<zap### [at] hotmail com> wrote:
> All the trig functions use radians, but rotate, and camera angle are
> degrees.
> Sometimes I have to convert angles five times in one macro. Any idea
> why they didn't keep things consistent?
They did...they kept the functions consistent with their C equivalents,
except for vrotate, which they kept consistent with the rotate
transformation, which they used degrees for because most people use
degrees for that kind of angular measurement, and they probably used
degrees in the camera angle for the same reason...see? ;-)
My guess is that the transformations were added first, and used degrees
because they are the angle usually used. The camera angle probably just
went along with these. But later, when trig functions were added, they
were kept consistent with the C functions, so people coming from C
wouldn't get confused.
It would be nice to just use revolutions as the standard measurement,
and provide a radians() function that takes radians, and a degrees()
function for degrees. Probably not going to happen, though...there are
few scenes it wouldn't break.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bob H." wrote:
>
> "Francois Labreque" <fla### [at] videotronca> wrote in message
> news:3A952F9F.43B9E767@videotron.ca...
> >
> > Geoff Wedig wrote:
> > >
> > > Speaking of manual bugs, can anyone confirm that the #range feature for
> > > #switch is actually lower < value <= upper and not lower <= value <=
> upper
> > > like it says in the manual?
> >
> > The doc is correct.
> >
> > #switch( var)
> > #range (1, 10)
> > box{ 0, 1 pigment{ color rgb 1 }}
> > #else
> > sphere{ 0, 1 pigment { color rgb <1,0,0> }}
> > #end
> >
> > creates a white box when var=1, not a red sphere as you think it would.
>
> Nope, sorry. Not so it would seem. It is 1 to 10 inclusive but you need a
> #break ahead of the #else otherwise you actually get both objects. In
> MegaPov anyway.
I forgot to type the #break statement, so sue me!
[Note to self: Never post before your morning coffee]
--
Francois Labreque | //\\ Wear an ASCII ribbon!
flabreque | || ||
@ | \\// Support the campain
videotron.ca \\ against HTML e-mail
//\\ and news!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Geoff Wedig <wed### [at] darwinepbicwruedu> wrote:
:> Are you sure clock is an integer?
: Well, initial_clock and final clock are both integers, and equal to initial
: frame and final frame respectively. And in the log they're all .00000, so
: yeah, pretty sure. ;)
It may (seem to) have an integer value, but that doesn't mean that it's
an integer type.
As all values in povray, it's a floating point value. It shouldn't be
necessary to say more...
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23 Feb 2001 07:23:32 -0500, Warp wrote:
>Geoff Wedig <wed### [at] darwinepbicwruedu> wrote:
>:> Are you sure clock is an integer?
>
>: Well, initial_clock and final clock are both integers, and equal to initial
>: frame and final frame respectively. And in the log they're all .00000, so
>: yeah, pretty sure. ;)
>
> It may (seem to) have an integer value, but that doesn't mean that it's
>an integer type.
> As all values in povray, it's a floating point value. It shouldn't be
>necessary to say more...
It shouldn't be, but I will anyway. If when we calculate the clock value
we divide before we multiply, we can get roundoff error. I'm pretty sure
that if we multiply before we divide, we won't, so that's why I wanted the
original values Geoff used: so I can have a test case.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Francois Labreque" <fla### [at] videotronca> wrote in message
news:3A95C73E.8AE8DD82@videotron.ca...
>
> I forgot to type the #break statement, so sue me!
>
> [Note to self: Never post before your morning coffee]
;-) Applies to me more often than not, morning noon or night (less the
coffee part).
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Geoff Wedig <wed### [at] darwinepbicwruedu> wrote:
> :> Are you sure clock is an integer?
> : Well, initial_clock and final clock are both integers, and equal to initial
> : frame and final frame respectively. And in the log they're all .00000, so
> : yeah, pretty sure. ;)
> It may (seem to) have an integer value, but that doesn't mean that it's
> an integer type.
> As all values in povray, it's a floating point value. It shouldn't be
> necessary to say more...
Except for the slight problem that floats can represent integers, the
initializers and additions are integers. There's absolutely no reason why
these wouldn't be integers too. Or are you saying that Pov gets numerical
error when adding 1 succesively to 0 for values < 100? If so, then POv has
far worse problems than the range statement.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a9690a0@news.povray.org> , Geoff Wedig
<wed### [at] darwinepbicwruedu> wrote:
> Except for the slight problem that floats can represent integers
The problem is not that they can't represent integers if rounded at for
example the tenth digit, but if you take the whole floating-point number
you may well have a case like this (the error is just a _very_ simple
example, the real error will be more complicated and may appear in
different operations because of the way floating-point numbers are
represented internally).
Imagine: integer 4 = floating-point 4.00000000001
integer 2 = floating-point 2.0000000001
2.00000000001 + 2.00000000001 = 4.00000000002 != 4.00000000001
Get the idea?
Thorsten
PS: In some cases POV-Ray tries to compensate for this with a little
threshold when comparing for equality.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> In article <3a9690a0@news.povray.org> , Geoff Wedig
> <wed### [at] darwinepbicwruedu> wrote:
>> Except for the slight problem that floats can represent integers
> The problem is not that they can't represent integers if rounded at for
> example the tenth digit, but if you take the whole floating-point number
> you may well have a case like this (the error is just a _very_ simple
> example, the real error will be more complicated and may appear in
> different operations because of the way floating-point numbers are
> represented internally).
> Imagine: integer 4 = floating-point 4.00000000001
> integer 2 = floating-point 2.0000000001
> 2.00000000001 + 2.00000000001 = 4.00000000002 != 4.00000000001
> Get the idea?
I deal with float and integer problems every day. My work is in
mathematical computation, so yeah, I've heard of the idea.
And it's completely irrelevant. It may be true in many cases, but in *this*
case, we're dealing with a float that was *initialized* to an integer, and
with integral values small enough to fit in the storage bits, they're stored
as integers (basically). It's only when you have to use the shift bits that
funky things happen. This has *long* been a standard. If I were doing
dividing, where a small roundoff could have occured, then there might've
been some question, but in this case, we're dealing with integers added to
integers, albeit stored as floats. I can't see why they'd conflict in this
fashion. Or is POV doing something extremely funky with the clock? I
suppose it's possible that rather than use the settings I gave it for
initial and final clock, it still does 0-1, but then multiplies it by the
difference and adds the initial_clock, to get the clock setting given to the
scene file, but that seems like a lot of work when the true values are right
there.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23 Feb 2001 14:36:47 -0500, Geoff Wedig wrote:
>funky things happen. This has *long* been a standard. If I were doing
>dividing, where a small roundoff could have occured, then there might've
>been some question, but in this case, we're dealing with integers added to
>integers, albeit stored as floats. I can't see why they'd conflict in this
>fashion. Or is POV doing something extremely funky with the clock? I
>suppose it's possible that rather than use the settings I gave it for
>initial and final clock, it still does 0-1, but then multiplies it by the
>difference and adds the initial_clock, to get the clock setting given to the
>scene file, but that seems like a lot of work when the true values are right
>there.
That's what I thought it must be doing, too, at first, but I see now that
it computes the clock delta and adds it for each frame. The clock delta is
given by (final_clock-initial_clock)/(final_frame-initial_frame), which
should be exactly 1 unless you're using an old Pentium, but perhaps there's
something funky about division that I don't understand.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
