So are you big bad programmers going to fix the brightness bug in
POV-ray for Windows??  Or do you guys not understand radiosity code?  Or
what?     And did you even know there was a brightness bug?? 

Reply via email by removing X's :)

Steve Horn
hor### [at] osuedu

Post a reply to this message

The person that named itself "?"  wrote in message
<352### [at] popserviceohio-stateedu>...
>So are you big bad programmers going to fix the brightness bug in
>POV-ray for Windows??  Or do you guys not understand radiosity code?  Or
>what?     And did you even know there was a brightness bug??


Very strange how someone "asking" for something can be so rude. Do you
really think to get something going this way?
I guess it was this attitude that made the POV-Ray developers seclude
themselves to their Compuserve forum. And I can't blame them, even if I
canceled my CiS account a few months ago...

Johannes.

Post a reply to this message

On Wed, 08 Apr 1998 17:56:40 -0400, ?
<hor### [at] popserviceohio-stateedu> wrote:

>So are you big bad programmers going to fix the brightness bug in
>POV-ray for Windows??  Or do you guys not understand radiosity code?  Or
>what?     And did you even know there was a brightness bug?? 

Perhaps we just didn't care, since radiosity is an experimental
feature and the POV-Team is likely to change it all in a future
release.  Y'see, the people who hang out here are NOT the POV-Team.
We have even less incentive than they do to take requests, because we
mostly do patches we want for ourselves and then make them available
for other people, but even they are unlikely to respond to such a
rudely phrased question.  In fact, such rudeness is why they don't do
Internet support, and why you rarely see them even posting here, on
their own news server.  

If you can't say something nice...

Post a reply to this message

It was this same (?) that went through and posted to ever group on the
service a few months back. He should be aware that the real pov guys are
very talented programmers and don't need to be reminded about the radiosity
problem.
  Anyone else have a problem with it being broken? I get good enough images
as is. I have no complaints.

- Grim

Post a reply to this message

On Thu, 9 Apr 1998 10:57:11 +0200, "Johannes Hubert" <jhu### [at] algonetse>
wrote:
>Very strange how someone "asking" for something can be so rude. Do you
>really think to get something going this way?
>I guess it was this attitude that made the POV-Ray developers seclude
>themselves to their Compuserve forum. And I can't blame them, even if I
>canceled my CiS account a few months ago...
>
>Johannes.
>

Actually it is a really simple bug to correct, so maybe you didn't understand
the humor in my post.  There is nothing wrong with the developer's approach.
It won't be a major overhaul in any way to get rid of the bug.  I beleive any
programmer could simply look at the code and they would immediately find the
problem.

Steve Horn :)
hor### [at] osuedu

Post a reply to this message

On Thu, 09 Apr 1998 15:30:35 GMT, ron### [at] farmworkscom (Ronald L. Parker) wrote:
>Perhaps we just didn't care, since radiosity is an experimental
>feature and the POV-Team is likely to change it all in a future
>release.  Y'see, the people who hang out here are NOT the POV-Team.
>We have even less incentive than they do to take requests, because we
>mostly do patches we want for ourselves and then make them available

Not at all.  Like I said before, this is no major request.  It's a very simple
bug to find and correct, and so maybe you didn't see the humor in my post.
Don't sweat it. I believe anyone could merely look at the code and find the
problem immiediately.  These ostracizing responses only go to show that you
guys aren't looking at these parts of the code at all! 

Steve :)
hor### [at] osuedu

Post a reply to this message

So fix it.

? wrote:

> On Thu, 09 Apr 1998 15:30:35 GMT, ron### [at] farmworkscom (Ronald L. Parker) wrote:
> >Perhaps we just didn't care, since radiosity is an experimental
> >feature and the POV-Team is likely to change it all in a future
> >release.  Y'see, the people who hang out here are NOT the POV-Team.
> >We have even less incentive than they do to take requests, because we
> >mostly do patches we want for ourselves and then make them available
>
> Not at all.  Like I said before, this is no major request.  It's a very simple
> bug to find and correct, and so maybe you didn't see the humor in my post.
> Don't sweat it. I believe anyone could merely look at the code and find the
> problem immiediately.  These ostracizing responses only go to show that you
> guys aren't looking at these parts of the code at all!
>
> Steve :)
> hor### [at] osuedu

Post a reply to this message

- Snip -
>Don't sweat it. I believe anyone could merely look at the code and find the
>problem immiediately.  These ostracizing responses only go to show that you
>guys aren't looking at these parts of the code at all!
>
>Steve :)
>hor### [at] osuedu


  Put out a patch then, dude! :)
  I code Pov, I code assembler, Fortran, C++,... but I only code Pov for
fun. I almost don't code scripts within pov, because it's too much like
programming. When Pov starts to hit me like programming, I go play Quake.
  So, I'll understand if you feel the same way. BUT, I won't place demands,
or arrogate, to guys that are offering a great program for free.
  Think about it. :)

- Grim

Post a reply to this message

Hi Steve!

>Actually it is a really simple bug to correct, so maybe you didn't
understand
>the humor in my post.

No, I certainly didn't, and after reading it again, I still don't! This
"didn't see the humour" response seems to be more like a typical "Rude
post" -> "Angry reply" -> "Hey man, didn't mean it..." follow up.

>I beleive any
>programmer could simply look at the code and they would immediately find
the
>problem.

You may be perfectly right with that and nobody would dispute you the right
to post here, to mention a bug you (may) have found and ask if anyone has
fixed it or plans to.
It was you choice of words (and the attitude they let shine through) that we
didn't appreciate.

Now - I don't want to make a flame-war out of this (after all, among the
thing I like so much about news.povray.org is "almost no spam" and "no
flames" - raytracers are very polite people, really :-) , so I hope you
don't see the responses you got as personal attacks but more as hints what
you did wrong. And hopefully next time you wont get the same problems...

Johannes.

Post a reply to this message

On Thu, 09 Apr 1998 22:24:14 GMT, hor### [at] osuedu (?) wrote:

>On Thu, 09 Apr 1998 15:30:35 GMT, ron### [at] farmworkscom (Ronald L. Parker) wrote:
>>Perhaps we just didn't care, since radiosity is an experimental
>>feature and the POV-Team is likely to change it all in a future
>>release.  

>Don't sweat it. I believe anyone could merely look at the code and find the
>problem immiediately.  These ostracizing responses only go to show that you
>guys aren't looking at these parts of the code at all! 

You must have missed it the first time: radiosity is an experimental
feature and the POV-Team is likely to change it all in a future
release.  Why would we want to build functionality on top of a
temporary feature?  Of course we haven't looked at that part of the
code, because it's not really there.  It's just a placeholder for the
real code, when it comes along.

Okay, for those who missed it, here's the bug in radiosity:  it allows
people who don't understand its status as an experimental feature to
use it and then complain because it doesn't do what they expect it to.
To fix it, I suggest that all images rendered with radiosity should
automatically add

text {
  ttf "times.ttf", "Experimental" .01,  0
  texture {pigment {colour red 1 transmit .9}}
  }

to the image, then transform it so it'll be right in front of the
camera.  This could be disabled by adding an appropriate #declare to
the scene to acknowledge that you understand the caveats and are
prepared to live with them, as with GUI Extensions on Windows.

Either that, or Mr. Horn could grace us with a description of the
error in the program, rather than wasting our time and his telling us
about the error of our ways.

Post a reply to this message

? (hor### [at] osuedu) wrote:
: Not at all.  Like I said before, this is no major request.  It's a very simple
: bug to find and correct

  Then why don't you go and find and correct it yourself?
  Are you sure it's a simple bug? Have youi studied the code?

--
                                                              - Warp. -

Post a reply to this message

? <hor### [at] osuedu> wrote:

> These ostracizing responses only go to show that you
> guys aren't looking at these parts of the code at all! 

Or perhaps we don't use bugy PC's.

/ Mathias

Post a reply to this message

Hi there, not enough guts to put even a nickname up ?

Number one, humour can be nice.
Number two, if it's easy to fix why not give the answer ?
Number three, it is always easy once you found the answer.
Number four, POV-Ray is quite big as a program, I know, there is much bigger than that
and I personally worked on much bigger programs (8MB of source code), yet I will never
dare look down on someone because they did not find something 'easy'. Have you ever
found a pin in a hay stack, well maybe you have : this radiosity bug.
Number five, how many bugs in POV-Ray did you find, and how many did you not find ?
Number six, team work is about helping each other and complementing each other, not
replicating the work.

Got that ?
No I do not intend to be moralistic, just taking sorta distorted mirror image to your
own tone.
I hope you get the message positively,
Cheers (I like to be nice in the end)
Al.


? wrote:

> On Thu, 09 Apr 1998 15:30:35 GMT, ron### [at] farmworkscom (Ronald L. Parker) wrote:
> >Perhaps we just didn't care, since radiosity is an experimental
> >feature and the POV-Team is likely to change it all in a future
> >release.  Y'see, the people who hang out here are NOT the POV-Team.
> >We have even less incentive than they do to take requests, because we
> >mostly do patches we want for ourselves and then make them available
>
> Not at all.  Like I said before, this is no major request.  It's a very simple
> bug to find and correct, and so maybe you didn't see the humor in my post.
> Don't sweat it. I believe anyone could merely look at the code and find the
> problem immiediately.  These ostracizing responses only go to show that you
> guys aren't looking at these parts of the code at all!
>
> Steve :)
> hor### [at] osuedu



--
ANTI SPAM / ANTI ARROSAGE COMMERCIAL :
Pour me répondre, veuillez enlever le Z de mon adresse.
To answer me, please take out the Z from my address.

Post a reply to this message

Ronald L. Parker wrote:
> 
> Either that, or Mr. Horn could grace us with a description of the
> error in the program, rather than wasting our time and his telling us
> about the error of our ways.
>

POV-Ray 3.02 running under Win95 has an ability to trace an image in
several passes, with increasing resolution on each pass; the "mosaic
preview" feature.   When using radiosity, POV-Ray will automatically use
mosaic previews during rendering to help the radiosity adapt to the
particulars of the scene.  

There is a user variable in the radiosity settings called "brightness."
This controls how bright diffused light will be.  The default is 3.3 
Generally, I found it to be too low of a number to simulate sunlight
correctly, so I tried higher values.  Another way is to try brighter
light sources, or sources with components much greater than 1.0 say
sunlight would be rgb<4.0,3.7,3.4>  This helped to some degree but makes
washed out patches where the light shines directly.

If you set brightness to any value other than 3.3 it will render
correctly during the mosaic passes, but when the scene is traced at
original resolution (1x1) the brightness will default back to 3.3

To see this bug in action, make a scene in which diffused light is
pertinent, such as a scene where light shines in through a window.  Then
take brightness way up around 40.  Notice how awashed with light your
scene will be during mosaic passes, and how mysteriously dark it becomes
when you reach the final pass.  In fact, this darkness is not a mystery,
you would have had _exactly the same render_ if you had kept brightness
at 3.3.  The value is actually "defaulting" back during the final pass.

I posted this before, but noone took any interest in it, marginalizing
the problem by blaming my "buggy PC" or telling me how "experimental"
radiosity is in POV-Ray.  Experimental or not, a bug is a bug is a bug! 
Other people were posting ways to fix it that did not help.  All in all,
people who replyed (the few) did not understand the problem and could
not account for brightness WORKING in one instance and not the next.  

People told me to play around with my global ambient light, even when I
knew exactly how ambient light plays in the calculation. (My fav value
is <.21,.21,.21> for ambient light. It really brings out the diffused
light!)  I also understand about local texture values of ambience
overwriting global ambience and vice-versa.  All of my scenes account
for that.  

It seems as if I posted on a legitimate bug in the program only to be
met by responses telling me "I don't know what I'm talking about" or
that I should just "shut up and use the UNIX version."  Or basically
that none of my posts would be taken seriously until I had "gained
respect in this newsgroup."

It is sad that I had to take on a rude tone to get any responses,
because I know what I have found, and I know it is for real, and I was
frustrated to get apathetic responses from a group of people that are
supposed to know the stuff inside and out.  I'm not another 15-year-old
that doesn't understand ray-tracing and hasn't read the documentation,
but I'm being treated like one.

Steve Horn
hor### [at] osuedu

Post a reply to this message

? (hor### [at] popserviceohio-stateedu) wrote:
: POV-Ray 3.02 running under Win95 has an ability to trace an image in
: several passes

  Only under win95?

  (I'm not trying to offend anyone, honestly, but every time when someone
seems to speak like he is supposing everyone is using win95 and there's no
any other system than that, I go mad. Win95 is very used and is tolerably
good, but hey, don't suppose everyone is using it!)
  Sorry for this totally useless article.

--
                                                              - Warp. -

Post a reply to this message

On Mon, 20 Apr 1998 16:39:01 -0400, ?
<hor### [at] popserviceohio-stateedu> wrote:

>When using radiosity, POV-Ray will automatically use
>mosaic previews during rendering to help the radiosity adapt to the
>particulars of the scene.  

Correction: it automatically uses one mosaic preview, at 8x8.  This is
important.

>If you set brightness to any value other than 3.3 it will render
>correctly during the mosaic passes, but when the scene is traced at
>original resolution (1x1) the brightness will default back to 3.3

Mosaic passes?  By default, as I said, it only does one.  If you
specify more than one, does the brightness bug happen in the second
pass, or only in the last (1x1) pass?  Make sure you specify a
start/end of 8/4, or POV will second-guess you.

Here's what I think it is:  after the first pass (by default, the only
mosaic pass) POV takes the average gray from all of the passes and
uses it to scale the brightness value.  Problem is, the statement it
scales the brightness with is this: (from render.c)

opts.Radiosity_Brightness = 3. / gather_gray;

See that 3?  What does the 3 mean?  I don't know either.  It should
probably read

opts.Radiosity_Brightness /= gather_gray;

Unfortunately, I'm in the midst of a job change, so I had to give up
my compiling/rendering machine for a while.  If someone could test
this, I'd appreciate it.

>I posted this before, but noone took any interest in it, marginalizing
>the problem by blaming my "buggy PC" or telling me how "experimental"
>radiosity is in POV-Ray.  Experimental or not, a bug is a bug is a bug! 

I'm not sure whether you're talking about me or not.  Let me stress
that my bringing up the "experimentalness" of radiosity was to justify
the fact that nobody here has spent much time trying to work on it,
not to justify a bug.  Bugs should be fixed, even in experimental
features.

>It seems as if I posted on a legitimate bug in the program only to be
>met by responses telling me "I don't know what I'm talking about" or
>that I should just "shut up and use the UNIX version."  Or basically
>that none of my posts would be taken seriously until I had "gained
>respect in this newsgroup."

I assume the newsgroup you're talking about is cgrr.  This is a
different newsgroup, with different rules.  Please don't color us with
the same brush you use for them, and don't assume that we saw the
earlier exchange.

>It is sad that I had to take on a rude tone to get any responses,
>because I know what I have found, and I know it is for real, and I was
>frustrated to get apathetic responses from a group of people that are
>supposed to know the stuff inside and out.  I'm not another 15-year-old
>that doesn't understand ray-tracing and hasn't read the documentation,
>but I'm being treated like one.

It _is_ kinda hard to find a bug without knowing what you're looking
for.  Note, too, that this bug isn't even in the radiosity code per
se.  It's in one of the main render loops.  See how easy it got when
we had a description to go on?

Post a reply to this message

Ronald L. Parker wrote:

>
> specify more than one, does the brightness bug happen in the second
> pass, or only in the last (1x1) pass?  Make sure you specify a
> start/end of 8/4, or POV will second-guess you.
>

Only in the last 1x1 pass, in all cases.



> 
> opts.Radiosity_Brightness = 3. / gather_gray;
> 
> See that 3?  What does the 3 mean?  I don't know either.  It should
> probably read
> 
> opts.Radiosity_Brightness /= gather_gray;
> 

They thought that the 3. was a prime brightness and that better values,
depending on the scene, were LESS than 3!!  This was a sweeping
assumption indeed!   I would actually remove this line altogethor, and
let the user decide brightness.  Or better yet, have the user toggle
whether POV uses an adaptive method for the setting or not.

 
> se.  It's in one of the main render loops.  See how easy it got when
> we had a description to go on?
>

Where can I get the source for the WIN95 v3.02 ??  The DOS version code
is on the www,  but I can't find the win95 version.  Help! :p

Steve Horn

Post a reply to this message

On Fri, 24 Apr 1998 22:41:54 -0400, ?
<hor### [at] popserviceohio-stateedu> wrote:

>Only in the last 1x1 pass, in all cases.

If that's the case, then this isn't the line that's causing the
problem, as it is executed at the end of the first pass and never
again.

I agree that if I specify brightness, it should probably keep the one
I specified, and that certainly doesn't look like what it's doing
here, but if your problem is in the last pass, it's something else.

>Where can I get the source for the WIN95 v3.02 ??  The DOS version code
>is on the www,  but I can't find the win95 version.  Help! :p

The win95 source is also available online, on ftp.povray.org.  Look
where you find the executable.  I think it's povwin_s.zip.
Unfortunately, it's not the 3.02 source, it's the 3.01.  3.02 doesn't
seem to be available online, but you can make a credible imitation by
dropping the 3.02 Unix source into your Windows source directory.

Post a reply to this message

Hi Steve,

Eventually you give yourself a name or an alias at least. Whether it is the real one
has little relevance, but I appreciate saying 'Hi Steve' rather than 'Hi ?'.

You seem to be giving a bit into 'paranoia', please notice I said 'a bit'.
Some people may have replied as if you were 15, does that mean everybody thought you
were ? Besides, some 15 y olds behave more adult like than you did so far and some of
them are well able to find out bugs.

People who behave more like adults and did not have time to study the bug in question
or did not know how to solve it just did not bother replying, I guess, to avoid saying
something for nothing.

People here do not necessarily know the thing inside out otherwise what use would it
be to share problems in a newsgroup ? The point is to help complete each other's
knowledge isn't it ?

You are still so proud you have found the bug and the correction, you still keep it to
yourself. Lots of very nice lads gave you POV-Ray for free and 'this simple bug' (your
own words) shall be kept a secret to the community, I do not believe this is an adult
behaviour. You maybe 30 but you still behave as some 15 years old.

You are free not to share your findings, but in that case don't expect people to be
willing to share theirs with you - even if this is not adult behaviour either. Yet you
will find a lot who are ready to share evrything they find about POV-Ray and more.

Make up your mind, being in this newsgroup really is about sharing, when you can do
so.

Sorry for the 'lesson of moral', I hope I have been mild enough not to hurt and firm
enough so that you understand how to grow up a bit from your present position.

With all due respect,
Cheers,
Al.


[?] alias [Steve Horn] alias ? wrote:

> Ronald L. Parker wrote:
> >
> > Either that, or Mr. Horn could grace us with a description of the
> > error in the program, rather than wasting our time and his telling us
> > about the error of our ways.
> >
>
> POV-Ray 3.02 running under Win95 has an ability to trace an image in
> several passes, with increasing resolution on each pass; the "mosaic
> preview" feature.   When using radiosity, POV-Ray will automatically use
> mosaic previews during rendering to help the radiosity adapt to the
> particulars of the scene.
>
<Snip>
>
> It seems as if I posted on a legitimate bug in the program only to be
> met by responses telling me "I don't know what I'm talking about" or
> that I should just "shut up and use the UNIX version."  Or basically
> that none of my posts would be taken seriously until I had "gained
> respect in this newsgroup."
>
> It is sad that I had to take on a rude tone to get any responses,
> because I know what I have found, and I know it is for real, and I was
> frustrated to get apathetic responses from a group of people that are
> supposed to know the stuff inside and out.  I'm not another 15-year-old
> that doesn't understand ray-tracing and hasn't read the documentation,
> but I'm being treated like one.
>
> Steve Horn
> hor### [at] osuedu

--
ANTI SPAM / ANTI ARROSAGE COMMERCIAL :
Pour me répondre, veuillez enlever le Z de mon adresse.
To answer me, please take out the Z from my address.

Post a reply to this message

I know, you were all hoping this would go away quietly.  Well, I just
finally got my compiler reinstalled, so...

On Wed, 22 Apr 1998 23:14:30 GMT, par### [at] mailfwicom (Ronald L.
Parker) wrote:

>On Mon, 20 Apr 1998 16:39:01 -0400, ?
><hor### [at] popserviceohio-stateedu> wrote:
>
>>When using radiosity, POV-Ray will automatically use
>>mosaic previews during rendering to help the radiosity adapt to the
>>particulars of the scene.  
>>If you set brightness to any value other than 3.3 it will render
>>correctly during the mosaic passes, but when the scene is traced at
>>original resolution (1x1) the brightness will default back to 3.3
>
>Mosaic passes?  By default, as I said, it only does one.  If you
>specify more than one, does the brightness bug happen in the second
>pass, or only in the last (1x1) pass?  Make sure you specify a
>start/end of 8/4, or POV will second-guess you.

Despite what was later reported, what I suspected is true: the
brightness shift happens after the first pass, not before the last
pass.  Making the change I mentioned fixes the problem.

Replace the line that says

opts.Radiosity_Brightness = 3. / gather_gray;

with 

opts.Radiosity_Brightness /= gather_gray;

Interestingly enough, this "bug" is documented in rad_def.inc:

radiosity {
 count 200                // Calculate reasonable accurate samples
 error_bound 0.3          // Main quality/time adjustment = ...
 gray_threshold 0.5       // Try 0.33-0.50. Just a matter of taste
 distance_maximum 10      // Scene-dependent!  Leave 0 if unsure...
 low_error_factor 0.75
 nearest_count 7
 minimum_reuse 0.017      // reasonable number of samples in corners
 brightness 3.3   // doesn't really matter.  Not used in final output.
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 recursion_limit 1        // can be 1 (usual) or 2 (for patient...
 }

Post a reply to this message