Am 02.09.2014 18:11, schrieb LanuHum:
> 50 sphere_sweep with one material:
> 44 - good, AA - good
> 6 - error: color white, AA off

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.

Post a reply to this message

clipka <ano### [at] anonymousorg> 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? :( :( :(

Post a reply to this message

If I don't use UV of a problem isn't present.

Post a reply to this message

Attachments:
Download 'scene2.jpg' (25 KB)

Preview of image 'scene2.jpg'

> > Most likely the texture computations for the respective sphere sweeps
> > yield a result that is "Not a Number"

Maybe something like
#debug concat("<", vstr (5, ColorImage_Material_001, ",", 0, 3), ">\n")

would help identify the problem, except I don't know how to convert a UV pigment
identifier to a vector(?) so that you can monitor the results.

Christoph or someone else may know how to output the values/format of these
internal values to the debug stream.  If you're doing some sort of animation
with the .ini file, then I've found it useful to output the changing values to
screen.inc so that I can follow what's going on without having to use the
Message pane.  It also preserves that data in the rendered image, which might be
more useful than writing to a file, though you could certainly do both.

Post a reply to this message

Am 02.09.2014 19:28, schrieb LanuHum:
> clipka <ano### [at] anonymousorg> 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.

Post a reply to this message

On 02/09/2014 22:13, clipka wrote:
> Am 02.09.2014 19:28, schrieb LanuHum:
>> clipka <ano### [at] anonymousorg> 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'

Le_Forgeron <jgr### [at] freefr> wrote:

> Will have to get a set of freshly compiled binaries to go further, so do
> not hold your breath today.

Great!
The mistake disappeared.
Thanks a lot!

Post a reply to this message

Attachments:
Download 'scene3.jpg' (33 KB)

Preview of image 'scene3.jpg'

On 03/09/2014 18:39, LanuHum wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
>> Will have to get a set of freshly compiled binaries to go further, so do
>> not hold your breath today.
> 
> Great!
> The mistake disappeared.
> Thanks a lot!
> 
I have not yet changed anything... so it's probably just luck and some
non-initialised memory... or something else.

The bug-hunt is scheduled for this week-end.

-- 
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

Le_Forgeron <jgr### [at] freefr> wrote:

> I have not yet changed anything... so it's probably just luck and some
> non-initialised memory... or something else.
>
> The bug-hunt is scheduled for this week-end.
>

Till this day I used the version which was to the old address:
(github.com/LeForgeron/Hgpovray.git)
Only today, I make & make install a binary package, using your new link:
github.com/LeForgeron/povray
Perhaps, already something was changed?
But, if you were convinced that the error takes place, that, then is a fantasy
:)
Oh.

Post a reply to this message

Sorry.
Old version configure with --disable-optimiz (standard (official) Mageia
specfile)
Today I edited the specfile and removed an option --disable-optimiz

%configure2_5x --with-x COMPILED_BY="LanuHum" LIBS="-lboost_system
-lboost_thread -lboost_date_time"

Post a reply to this message