? (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 :

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 :

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