POV-Ray : Newsgroups : povray.bugreports : Blobs: Error 1: Negative Values: Holes! / Error 2: Alpha Value Overwriting? : Re: Blobs: Error 1: Negative Values: Holes! / Error 2: Alpha ValueOverwriting? Server Time
23 Apr 2024 04:14:45 EDT (-0400)
  Re: Blobs: Error 1: Negative Values: Holes! / Error 2: Alpha ValueOverwriting?  
From: clipka
Date: 22 Dec 2015 20:15:32
Message: <5679f5b4@news.povray.org>
Am 22.12.2015 um 18:15 schrieb Sven Littkowski:
> The scene took the entire night up to now for rendering, but I discover
> two problems and think, it could be caused by programming.
> 
> DEFINITE 1ST ERROR

Is it definite? Have you diagnosed the symptoms in enough depth to be
sure about this?

Blobs (and actually most features of POV-Ray) have been around for quite
a while now, and it is unlikely that any obvious bug in their
implementation has survived through all these years undetected.
Therefore, any error in the current version would probably have been
introduced with recent architectural changes; thus, an easy test whether
some unexpected behaviour is truly a bug would be to compare whatever
version you are using (I'll presume it's the latest semi-official dev
build) to the official 3.7.0 release and/or the last 3.6 release:

- If the stuff works as expected with official 3.7.0 but does not with
the latest dev build, it is fully justified to label it as a "definite
error".

- If the unexpected behaviour also occurs with official 3.7.0, it might
work as designed, and what you're seeing might just be known limitations
of that design; if the unexpected behaviour even occurs with 3.6, it's
almost guaranteed to be as designed.


> I have a blob, and work with regular (positive) values, but on a few
> locations also with negative values. And these negative values seem to
> give a problem: around their edges are holes or black areas (holes or
> not covered with texture).

Those artifacts might actually be the result of inherent limitations in
the numerical precision of the algorithm used. Try using "sturm on" in
the blob to choose a more precise (but slower) algorithm.

> POSSIBLE 2ND ERROR
> I believe that there is a 2nd problem: while all other areas of the ship
> hull follow the texture's FINISH declarations, it seems the blob does
> not: the low-light areas should have been almost black, but are gray. My
> FINISH declarations use an alpha value for textures of 0.0, but it seems
> here that 0.0 is not accepted or it is overwritten.

Your finish declarations certainly do not use an "alpha value", as
there's no such thing in finish. Either you mean pigment (with an alpha
value specified in conjunction with an image_map, or via the colour's
transmit or filter component), or you mean something else. Ambient perhaps?

For any further analysis you'd really have to provide a self-contained
scene, something I can just throw at POV-Ray and recreate exactly what
you see, both on the input and output side. As long as you post only
snippets, we can't rule out any number of stuff you did /not/ post: Does
the scene have an active radiosity block you didn't post? Do the
textures that you didn't post possibly have a finish with non-zero
"ambient" or "emission", either explicitly or by inheriting from some
default block you didn't post? Could one of all the light sources you
didn't post account for the brightening?

Also, judging from the cut-off planet you posted recently, I'd guess
that the background stars are not part of the original rendered image,
and were added in a post-processing step; could the brightening have
been introduced in that context?


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.