Hi,

might be I discovered A NEW BUG! :-D

I did a partial (+sc0.248406 +sr0.444099 +ec0.441055 +er0.635475) render
of a scene with +q12 and radiosity, but because it took too long, I had
to stop it, using my computer for other things.

Later, I wanted to continue: I now added the +c to the command line, and
started the render.

But the result was strange: at the end, there was a little distance
between where the old render stopped and the new continued render was
beginning, please see the attached image. I believe, this could be a
small bug (or let's say, un-exactness in programming).

Post a reply to this message

Attachments:
Download 'untitled-4.jpg' (249 KB)

Preview of image 'untitled-4.jpg'

Am 28.01.2016 um 05:37 schrieb Sven Littkowski:

> might be I discovered A NEW BUG! :-D

You seem pretty happy about it. For some inexplicable reason I'm not.

> I did a partial (+sc0.248406 +sr0.444099 +ec0.441055 +er0.635475) render
> of a scene with +q12 and radiosity, but because it took too long, I had
> to stop it, using my computer for other things.
> 
> Later, I wanted to continue: I now added the +c to the command line, and
> started the render.
> 
> But the result was strange: at the end, there was a little distance
> between where the old render stopped and the new continued render was
> beginning, please see the attached image. I believe, this could be a
> small bug (or let's say, un-exactness in programming).

Oh, please stop that crap talking -- trying to come across as humble,
are you? I don't buy it.

Sorry, I'm in a really bad mood; I've just broken the Unix build and
can't seem to figure out how, so anyone please forgive me if I come
across as rude... then again, at the moment I guess I am.

Never mind -- back to the issue you're seeing: Does this affect the
preview window only, or the rendered image as well?

Also, can you tell which of the two parts is out of place -- the old one
or the new one?

Post a reply to this message

Sven Littkowski <jam### [at] yahoocom> wrote:
> Hi,
>
> might be I discovered A NEW BUG! :-D
>
> I did a partial (+sc0.248406 +sr0.444099 +ec0.441055 +er0.635475) render
> of a scene with +q12 and radiosity...

It's probably because of the Quality=12 setting (hee hee.) Last time I checked,
there were only 11 settings.

Sorry, I'm in a lighthearted mood ;-)

Post a reply to this message

Kenneth, that means, I might have a bug on my own, inside my quality
settings. This is really a buggy world in which we live...

CLipka, my apologies. I know how that feels. Remember, I am a software
programmer, too. I know how it is, not to be able to see the forest
because of all these trees. Happened to me soo many times. Often needed
others to find that forest for me.

With "un-exactness in programming" I meant actually that maybe something
similar to my "blob problem" has occurred here: that the programming
code somehow does not make use of very exact mathematics - remember that
...-E2 and ...-E3 problem with my blob. I use a large image resolution,
maybe that makes things visible. Not sure.

Tried already to load again the previous work version of that UNIX
POV-Ray? Maybe you didn't make too many changes to that UNIX version, so
you don't lose too many new changes. I wished I could tell you better
ideas. But I don't program in C++, nor do I have deep insight to UNIX. I
only worked here and there with LINUX (Ubuntu). But Windows is my home,
otherwise.

But I can tell you something else: that we all who use POV-Ray, are
happy that there are you and the other POV-Ray developers. It is your
hard work, that makes our dreams becoming (at least: looking) real.

Well, at the moment I have no means to find out, which of the two parts
is displaced. You're right - it could be even the upper (first) part! I
can't find out, because I don't have that partial render anymore. And
what you saw, was just a screen shot. Even worse - at the moment I am
rendering another partial scene, since three days now - and cannot
afford to stop rendering again until it is finish. So, at this moment,
my own possibilities to reproduce that error and give you that
information, are not existing. I believe, the render will still take
another week before finish. (My next computer will be a Cray Super
Computer, I hope.)

Post a reply to this message

Sven Littkowski <jam### [at] yahoocom> wrote:

>
> I did a partial (+sc0.248406 +sr0.444099 +ec0.441055 +er0.635475) render
> of a scene...
>
> Later, I wanted to continue: I now added the +c to the command line, and
> started the render.
>

I've been re-reading the POV-Ray v3.7 documentation at "3.2.2.5 Resuming
Options", and I found a clue that *might* relate to your problem. It says...

"The Continue_Trace option may not work if the Start_Row option has been set to
anything but the top of the file, depending on the output format being used..."

("file" means your rendered image.)

And...
"POV-Ray tries to figure out where to resume an interrupted trace by reading any
previously generated data in the specified output file. All file formats contain
the image size, so this will override any image size settings specified. Some
file formats (namely TGA and PNG) also store information about where the file
started... which will override these settings. It is up to the user to make sure
that all other options are set the same as the original render."

Your problem might be related to doing only a 'partial' render of the scene,
instead of the full scene.

Post a reply to this message

Good answer. Might be. However, the image sizes were not changes, means,
they were the same. But maybe rounding or otherwise processing numbers
behind the period sign of a float could cause the problem inside the POV
Engine. Imagine, you divide 10 by 3. The result (3.33333333) has many
numbers behind the period sign. But if a variable inside the programming
code allows only for - let's say - 3 numbers after that period sign
(3.333), and later that float value is for some reason multiplied by 3
again or in any other way processed, it would not lead back to the
original 10, but only to a "9.999".

Maybe, and that is just an unknowing assumption on my side, something
like that inside POV-Ray's programming code causes this unexactness: the
type of a float variable. But I am not sure. I develop software by
myself, too. But not in C++, but in Pascal/Delphi.

But I hope, this can be resolved somewhen.

Post a reply to this message