Ron Parker <ron### [at] povrayorg> wrote:

> On 22 Feb 2001 13:10:38 -0500, Geoff Wedig wrote:
>>> roundoff error?
>>
>>Not in this case.  I'm dealing strictly with integers.

> 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. ;)

Geoff

Post a reply to this message

On 22 Feb 2001 13:41:49 -0500, Geoff Wedig wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>
>> On 22 Feb 2001 13:10:38 -0500, Geoff Wedig wrote:
>>>> roundoff error?
>>>
>>>Not in this case.  I'm dealing strictly with integers.
>
>> 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. ;)

Can you tell me what initial and final clock/frame are, so I can try to 
duplicate the problem?

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On 22 Feb 2001 13:10:38 -0500, Geoff Wedig wrote:
> >> roundoff error?
> >
> >Not in this case.  I'm dealing strictly with integers.
>
> Are you sure clock is an integer?

Always a good idea to make the variable in question readable in order to be
sure; via a text object, file output, or message stream.  Example:

#debug concat("Clock value is ", str(clock,0,-1))

But from what I can tell a clock done by frame number instead of the typical
0 to 1 is pretty much an integer.
Of course another good question might be what version of POV is being used,
just in case, eh?

Bob H.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:

> On 22 Feb 2001 13:41:49 -0500, Geoff Wedig wrote:
>>Ron Parker <ron### [at] povrayorg> wrote:
>>
>>> On 22 Feb 2001 13:10:38 -0500, Geoff Wedig wrote:
>>>>> roundoff error?
>>>>
>>>>Not in this case.  I'm dealing strictly with integers.
>>
>>> 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. ;)

> Can you tell me what initial and final clock/frame are, so I can try to 
> duplicate the problem?

Not easily.  I've revised the code to get rid of the problem frames.  I
believe they were 0 and 90 or 0 and 70 (one of the two).

Here's the switch I was using.  There were default parameters (essentially
case 0) defined before the #switch.  I found that frames 13, 20, 25, etc
were using these defaults rather than the range, and assumed it to be dues
to that be a < rather than <=.  I changed them to .5 less and everything
worked fine.


#switch (clock)

  #case(0)
    $attack_percentage = 0;
    $window_opening    = 1;
    $engine_glow       = 1;
  #break
  #range(1,12)
    $attack_percentage = 0;
    $window_opening    = (25-clock)/25;
    $engine_glow       = 1;
  #break
  #range(13,19)
    $attack_percentage = 0;
    $window_opening    = (25-clock)/25;
    $engine_glow       = (37-clock)/25;
  #break
  #range(20,24)
    $attack_percentage = (clock-19)/50;
    $window_opening    = (25-clock)/25;
    $engine_glow       = (37-clock)/25;
  #break
  #range(25,37)
    $attack_percentage = (clock-19)/50;
    $window_opening    = 0;
    $engine_glow       = (37-clock)/25;
  #break
  #range(38,59)
    $attack_percentage = (clock-19)/50;
    $window_opening    = 0;
    $engine_glow       = 0;
  #break
  #range(60, 69)
    $attack_percentage = (clock-19)/50;
    $window_opening    = 0;
    $engine_glow       = 0;
    $shield_on       = (clock - 60)/20;
  #break
  #range(70,90)
    $shield_on       = min((clock - 60)/20,1);
  #break
#end  

Geoff

Post a reply to this message

Bob H. <omn### [at] msncom> wrote:

> "Ron Parker" <ron### [at] povrayorg> wrote in message
> news:slr### [at] fwicom...
>> On 22 Feb 2001 13:10:38 -0500, Geoff Wedig wrote:
>> >> roundoff error?
>> >
>> >Not in this case.  I'm dealing strictly with integers.
>>
>> Are you sure clock is an integer?

> Always a good idea to make the variable in question readable in order to be
> sure; via a text object, file output, or message stream.  Example:

> #debug concat("Clock value is ", str(clock,0,-1))

> But from what I can tell a clock done by frame number instead of the typical
> 0 to 1 is pretty much an integer.
> Of course another good question might be what version of POV is being used,
> just in case, eh?

This was Megapov 0.6;

Geoff

Post a reply to this message

> 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] hotmailcom> 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