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

On 03/09/2014 20:34, Le_Forgeron wrote:
> 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.
> 
Ok, I found the source of the issue (propagation of NaN).

Now I wonder how to fix it.

Notice that your original spline, a cubic_spline, is repeating 3 times
the first point's coordinates: the first one is for the slope at start,
the second one is for the first actual point (start), but what is the
third one for ?

That's also happening at the end of your spline (last point is repeated
3 times).

So, a fast workaround would be to avoid triplicated extremities (and
probably duplicated intermediates), but that's

The NaN is created when two consecutive points (of the actual spline
segments) are strictly identical, so their difference is exactly a null
vector. (due to noise and numerical computation, it does not always
happens as easy as it seems). As that vector, once normalized is used as
part of the base with local U & V vector, having a degenerated 3D-base
is not a good thing to compute the new U & V vectors. Current code is
like Roman arithmetic: no expectation or notion of zero. Need some
Indian's innovation to fix it, sort of.


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