|
 |
On 02/09/2014 22:13, clipka wrote:
> Am 02.09.2014 19:28, schrieb LanuHum:
>> clipka <ano### [at] anonymous org> wrote:
>>
>>> The AA problem is certainly just a side effect of the underlying bug.
>>> Most likely the texture computations for the respective sphere sweeps
>>> yield a result that is "Not a Number" (NaN, e.g. due to an attempt to
>>> take the square root of a negative number or the like) or infinity;
>>> anti-aliasing can't digest these values, and comes up with NaN or
>>> infinity for the entire pixels.
>>>
>>> It is only after anti-aliasing, when the value is converted to the 8-bit
>>> integer range, that it turns into a sane value (and only because
>>> integers don't have values to represent NaN or infinity); on some
>>> platforms this value is zero, yielding black, while on other systems it
>>> is the maximum possible integer value, yielding white.
>>
>> Sorry, I at all didn't understand, what to do to me? :( :( :(
>
> Don't worry, there's probably nothing /you/ can do about it anyway;
> apparently there's a bug in Jerome's sphere sweep UV mapping code.
>
Probably right.
The interesting part is that my rendering is black, not white, when
using the gcc compiled version while the icc one shocked on assert about
povray: backend/support/imageutil.cpp:935: int pov::map_pos(const double
*, const pov::Pattern_Struct *, double *, double *): Assertion `(*ycoor
>= 0.0) && (*ycoor < (double)image->iheight)' failed.
Will have to get a set of freshly compiled binaries to go further, so do
not hold your breath today.
--
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))
Post a reply to this message
Attachments:
Download 'scene.png' (33 KB)
Preview of image 'scene.png'
|
|
