Heh, Kens evil twin on the loose again I see.
Um, this last comment of PoDs made me think that twin ain't half bad
though. I know I can never get a unknown feature or function of POVs
figured to be buggy or not because I have no experience with those
seldom or never used things. I'm sure people have their own capabilities
with POV whether new to something or not, and perhaps that should be the
focus since we vary on our understanding of each part.


PoD wrote:
> 
> >
> >   Ah come on now Jerry. If you find a function that does not work right
> > just play with something else instead. If it's broke don't use it.
> >
> > Gee wiz !
> >
> 
> Maybe if we all use some feature that we normally don't use, then
> discuss anything we think might be a bug here in povray.general, we
> might get the most bug free new version yet.
> 
> Cheers, PoD.

Post a reply to this message

Bob Hughes <inv### [at] aolcom> wrote:
: Heh, Kens evil twin on the loose again I see.
: Um, this last comment of PoDs made me think that twin ain't half bad
: though. I know I can never get a unknown feature or function of POVs
: figured to be buggy or not because I have no experience with those
: seldom or never used things. I'm sure people have their own capabilities
: with POV whether new to something or not, and perhaps that should be the
: focus since we vary on our understanding of each part.

  This is not always the case.
  When I tried the averaged normal feature of POV-Ray for the first time,
I soonly found the average normal bug. I immediately saw that it didn't
work as it should.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Ken wrote:
> 
>   Now that Pov v3.1g has been made publicaly available I suggest we keep
> those bug reports down to an absolute minimum so the Pov team has a chance
> to concentrate on Pov v3.5 which will actaully add new features to the program.
> 
> How about it people !
> 

That one is food for my boss. I always go up to him with 'you flood me
with WAY too much work' and get back with 'you have a concentration
problem', 'get organized', 'managers are tought to check what they've
been doing every fifteen minutes'.
That last one is his very special favorite.

Not that I recommend any of these.

A bug is a bug and a feature is a feature. It's up to the gods of pov,
which will happen first.

Axel

PS: PovRAY 3.5 : It's not a bug, it's a feature. 
(That one's harsher than that MS one, I DO apologize)

Post a reply to this message

Well said, Ken. During all my years with Pov I've come across a relatively small
number of bugs. They rarely prevent me from obtaining a particular effect and when
they do, there are enough other features in pov to play with. Bugs are annoying and
bug hunting may be fun but it's pov's features that make it great.
Gilles

Ken wrote:

>   Now that Pov v3.1g has been made publicaly available I suggest we keep
> those bug reports down to an absolute minimum so the Pov team has a chance
> to concentrate on Pov v3.5 which will actaully add new features to the program.
>
> How about it people !
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net

Post a reply to this message

Axel Hecht <ah### [at] numerikuni-kielde> wrote:
: PS: PovRAY 3.5 : It's not a bug, it's a feature. 

  People really don't know what is a bug.
  It's very annoying that people keep sending "I don't like the way this
works"-messages as bug reports.
  Bugs are programming mistakes. Something should work this way but it
doesn't because the programmer made a mistake while typing the code. Bugs
cause a behaviour which is completely unintentional and different from
the meant behaviour (like the average normal bug). Sometimes a bug is just
the lack of a feature because somebody just forgot that (like the #local
with same name but different type as the #declare).
  If something doesn't work the way you like, it doesn't mean it's a bug.
If you don't like that planes are solid instead of hollow 2D sheets (and
you keep getting the "camera inside non-hollow object" warning), that does
not mean that it's a bug. (Actually planes _have_ to work that way or they
will not work in CSG anymore.) Sendig a _bug_ report about this is extremely
stupid.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Well said.  Often there are workarounds for bugs in POV.  These can be
used until the POV-team fixes the bugs.

Post a reply to this message

Ken wrote:
> 
>   Now that Pov v3.1g has been made publicaly available I suggest we keep
> those bug reports down to an absolute minimum so the Pov team has a chance
> to concentrate on Pov v3.5 which will actaully add new features to the program.
> 
> How about it people !

	I wonder if some day the "about" file can include the rev
number.

-- 
<blink>-------please--don't-----------------</blink>

http://www.giwersworld.org/artii/
http://www.giwersworld.org/artiii/

Finally up on 99/06/22 updated 06/30

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Nieminen Mika wrote:

>   People really don't know what is a bug.
>   It's very annoying that people keep sending "I don't like the way this
> works"-messages as bug reports.
>   Bugs are programming mistakes. Something should work this way but it
> doesn't because the programmer made a mistake while typing the code. Bugs

Just a question about this topic:
Recently, I found out that the "bumps" feature when scaled 
anisotropically does not behave like real bumps. I wrote this
into povray.bugreports and got a few answers from people
who IMHO were not extremely familiar with the mathematical
aspects involved (which included differential geometry).

What would be the proper action in this case?
Flooding the bugreports group with more text is
probably a bad idea. Since I cannot read the mind of
the authors, I cannot tell wether this is a program bug,
a math error, or simply a problem which nobody cared
about yet.

Ralf

PS: The problem in question is the following: Transformed
bumps are computed by evaluating the bump function at some
other place in space, then using it on the place it is intended
for. Since real bumps on things (or other normal modifications)
involve computing the derivative, we get in trouble if the
transformation does not commute with the derivative, which
becomes relevant in the anisotropic case.

It can be visualized as follows: Make a xy-plane with bumps,
and have the lightsource at the same place as the camera 
(e.g. at <0,0,-10>).
Then the bumpy plane will have a circular region where
bright spots are visible. If the bumps are elongated
(i.e. longer in the x- than in the y-direction), then
this region should be deformed into an ellipse, which is
elongated in the *y*-direction (This can be verified by
making a real 3d-surface, e.g. using a heightfield).
Povray still shows a circular region.

Post a reply to this message

Ralf Muschall <rmu### [at] t-onlinede> wrote:
: What would be the proper action in this case?
: Flooding the bugreports group with more text is
: probably a bad idea. Since I cannot read the mind of
: the authors, I cannot tell wether this is a program bug,
: a math error, or simply a problem which nobody cared
: about yet.

  Although no-one responsible have answered to your report, I'm sure it
has been read and considered. I have experience about this.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 8 Jul 1999 01:32:40 -0400, Nieminen Mika <war### [at] cctutfi> wrote:

>Bob Hughes <inv### [at] aolcom> wrote:
>: Heh, Kens evil twin on the loose again I see.
>: Um, this last comment of PoDs made me think that twin ain't half bad
>: though. I know I can never get a unknown feature or function of POVs
>: figured to be buggy or not because I have no experience with those
>: seldom or never used things. I'm sure people have their own capabilities
>: with POV whether new to something or not, and perhaps that should be the
>: focus since we vary on our understanding of each part.
>
>  This is not always the case.
>  When I tried the averaged normal feature of POV-Ray for the first time,
>I soonly found the average normal bug. I immediately saw that it didn't
>work as it should.
>
Whereas (from experience, though not with POV) those proficient in
specific areas will probably use work-around to acheive their aim and
not even think to mention that there's an "issue" to be dealt with...
*they* can get it to work...


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/
PS change ".duffcom" to ".net" if replying via e-mail

Post a reply to this message