"Mike Williams" <mik### [at] nospamplease> wrote.
>>> Isosurface *disappears* at high resolution (fwd)
>>> http://news.povray.org/3bb0b351@news.povray.org
>>
>>Cannot duplicate.
>
>I can duplicate this (although the quick version that I wrote now runs
>to completion). The point at which the quick version collapsed into
>blankness has varied from beta to beta, and now manages to go all the
>way through. The original scene file posted by Warp still fails when
>rendered with the specified size and antialliassing.
>
>The question is whether this is a bug, or whether isosurfaces that use
>crackle can legitimately be expected to disappear.

This is not a bug.  That behavior is due to the wrong max_gradient value.

The function of the original scene file posted by Warp has extremely 
large gradient values.  See the warning message.

Try the following function for the isosurface of that scene,

function{min(1,max(-0.5,(1+Blob_threshold)-Blob_threshold^Funki1(x,y,z)
          -Blob_threshold^Funki2(x,y,z)))}

The maximum gradient in the warning message is much lower than that of 
the original function.  Then, it gives us better result.

R. Suzuki

Post a reply to this message

In article <yjd### [at] econymdemoncouk> , Mike Williams 
<mik### [at] nospamplease>  wrote:

>>> Isosurface *disappears* at high resolution (fwd)
>>> http://news.povray.org/3bb0b351@news.povray.org
>>
>>Cannot duplicate.
>
> I can duplicate this (although the quick version that I wrote now runs
> to completion). The point at which the quick version collapsed into
> blankness has varied from beta to beta, and now manages to go all the
> way through. The original scene file posted by Warp still fails when
> rendered with the specified size and antialliassing.
>
> The question is whether this is a bug, or whether isosurfaces that use
> crackle can legitimately be expected to disappear.

Which has already been explained in the thread following the report.

I really don't see what is so difficult to understand about this not being a
bug.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Mike Williams wrote in message ...
>>> Bugs with string/macro handling
>>> http://news.povray.org/3be76148$1@news.povray.org
>>
>>Partial confirmation.  I can get error cases #1 (Too many nested symbol
>>tables) and #2 ("BCFGHJKLMQSUVWXY") but none of the others.
>>
>>At first glance that the original poster is trying to do with the scene
>>description language is somewhat akin to driving nails with a shoe.  As
>>such I am unsure if this problem should be fixed or if the workaround
>>should be 'reimplement your code in perl, Python, rexx, or C.'
>
>I think I'll move that into the "not a bug" box, unless anyone has
>serious objections.


This is quite definitely a bug.  Whether it is a bug worth the effort of
fixing or not is another matter.

--
Mark

Post a reply to this message

Wasn't it Mike Williams who wrote:
>>> Isosurface *disappears* at high resolution (fwd)
>>> http://news.povray.org/3bb0b351@news.povray.org
>>
>>Cannot duplicate.
>
>I can duplicate this (although the quick version that I wrote now runs
>to completion). The point at which the quick version collapsed into
>blankness has varied from beta to beta, and now manages to go all the
>way through. The original scene file posted by Warp still fails when
>rendered with the specified size and antialliassing.
>
>The question is whether this is a bug, or whether isosurfaces that use
>crackle can legitimately be expected to disappear.

On further investigation, my short version does still collapse under
beta 10. I'd somehow managed to save the scene file with the magic
"three blank lines" missing. As noted (and confirmed) in the original
thread removing the three blank lines causes the scene to render
correctly.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Wasn't it R. Suzuki who wrote:
>"Mike Williams" <mik### [at] nospamplease> wrote.
>>>> Isosurface *disappears* at high resolution (fwd)
>>>> http://news.povray.org/3bb0b351@news.povray.org
>>>
>>>Cannot duplicate.
>>
>>I can duplicate this (although the quick version that I wrote now runs
>>to completion). The point at which the quick version collapsed into
>>blankness has varied from beta to beta, and now manages to go all the
>>way through. The original scene file posted by Warp still fails when
>>rendered with the specified size and antialliassing.
>>
>>The question is whether this is a bug, or whether isosurfaces that use
>>crackle can legitimately be expected to disappear.
>
>This is not a bug.  That behavior is due to the wrong max_gradient value.
>
>The function of the original scene file posted by Warp has extremely 
>large gradient values.  See the warning message.
>
>Try the following function for the isosurface of that scene,
>
>function{min(1,max(-0.5,(1+Blob_threshold)-Blob_threshold^Funki1(x,y,z)
>          -Blob_threshold^Funki2(x,y,z)))}
>
>The maximum gradient in the warning message is much lower than that of 
>the original function.  Then, it gives us better result.

That explanation was proposed in the original thread, but it didn't
explain the fact that decreasing the max_gradient, or changing the
amount reflection or removing three blank lines caused the scene to
render correctly. I've got a nagging suspicion that for such very subtle
changes to cause the scene to go from rendering correctly to being so
badly wrong there may be something nasty deep down that might possibly
come back and bite us later.

(One, irrelevant, side effect of this scene is that the scene will
render completely differently on a render farm than on a single machine.
The machine that renders the bottom third of the image will see the
isosurface, but a single machine that starts at the top and works all
the way down will not see any isosurface in the bottom third of the
image.)

It may well not be a bug (that's why it's not in the confirmed bug
list). If it isn't a bug, then The reason it is not a bug is the one
stated by Thorsten in.

http://news.povray.org/3bb928b1$1@news.povray.org

        "Not a bug, but a limit in the crackle function when used with 
        isosurfaces."

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

"Mike Williams" wrote
>That explanation was proposed in the original thread, but it didn't
>explain the fact that decreasing the max_gradient, or changing the
>amount reflection or removing three blank lines caused the scene to
>render correctly. I've got a nagging suspicion that for such very subtle
>changes to cause the scene to go from rendering correctly to being so
>badly wrong there may be something nasty deep down that might possibly
>come back and bite us later.

That subtle change is due to the "isosurface cache". Following is a simple
example.
//-------------------------
#include "functions.inc"
camera { location <0,0,-30> look_at 0 angle 50 }
light_source { <1,2,-3>*10, 1.2 }
isosurface
{
  function { abs(mod(x+10,1)-0.5)+abs(z)-0.3+select( (f_r(x,y,z/4)-0.08) ,10,
0) }
  contained_by { box{-<2,10,0.3> <2,10,0.3> } }
  max_gradient 2
  pigment { rgb 1 }
  rotate y*0
}
//---------------------------

Try this scene with several different resolutions.  If you see a large
artifact, try to change the max_gradient value or rotation angle of y-axis.

A brief explanation of the cache technique is as follows.

If the minimum function value on a ray, F_min, is a positive
value, the latter calculation will be skipped in case (the distance
from the ray) < F_min/max_gradient.

This works properly if the real maximum gradient is less than the
max_gradient.  But if not, the possibility of improper rendering becomes high.

In the above case, F_min is about 10 in a certain condition.
Then, the latter calculation will be skipped in case
(the distance from the origin) < ~5(=~10/2).

>(One, irrelevant, side effect of this scene is that the scene will
>render completely differently on a render farm than on a single machine.

Yes.  But this occurs if the real maximum gradient is much greater than
'max_gradient' in the scene file.

I've not added "cache on/off" option to the original isosurface patch because
I was not sure whether it is really required or not.
Both the original scene and my example scene do not need this option
if we use a 'truncation' (min/max) technique.

R. Suzuki

Post a reply to this message

Wasn't it R. Suzuki who wrote:
>"Mike Williams" wrote
>>That explanation was proposed in the original thread, but it didn't
>>explain the fact that decreasing the max_gradient, or changing the
>>amount reflection or removing three blank lines caused the scene to
>>render correctly. I've got a nagging suspicion that for such very subtle
>>changes to cause the scene to go from rendering correctly to being so
>>badly wrong there may be something nasty deep down that might possibly
>>come back and bite us later.
>
>That subtle change is due to the "isosurface cache". Following is a simple
>example.
>//-------------------------
>#include "functions.inc"
>camera { location <0,0,-30> look_at 0 angle 50 }
>light_source { <1,2,-3>*10, 1.2 }
>isosurface
>{
>  function { abs(mod(x+10,1)-0.5)+abs(z)-0.3+select( (f_r(x,y,z/4)-0.08) ,10,
>0) }
>  contained_by { box{-<2,10,0.3> <2,10,0.3> } }
>  max_gradient 2
>  pigment { rgb 1 }
>  rotate y*0
>}
>//---------------------------
>
>Try this scene with several different resolutions.  If you see a large
>artifact, try to change the max_gradient value or rotation angle of y-axis.
>
>A brief explanation of the cache technique is as follows.
>
>If the minimum function value on a ray, F_min, is a positive
>value, the latter calculation will be skipped in case (the distance
>from the ray) < F_min/max_gradient.
>
>This works properly if the real maximum gradient is less than the
>max_gradient.  But if not, the possibility of improper rendering becomes high.
>
>In the above case, F_min is about 10 in a certain condition.
>Then, the latter calculation will be skipped in case
>(the distance from the origin) < ~5(=~10/2).

Thanks. That makes sense.

I think I'll add a simplified version of that to my isosurface tutorial
in a while.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Wasn't it Coridon Henshaw who wrote:
>> Media visible container line in front of object
>> (a visible whitish line appears at the edge of a transparent container
>> box for media)
>> http://news.povray.org/3bf45a3d@news.povray.org
>
>Confirmed.  This problem can be masked--but not eliminated--with 
>antialiasing.

In http://news.povray.org/3c596886@news.povray.org Thorsten says that
this hasn't been confirmed. 

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Wasn't it Coridon Henshaw who wrote:
>> [win gui] line with error highlighted but render finished succesfully
>> http://news.povray.org/va2tvt4tuitd67ik5t9ps334sbg6205bt3@4ax.com
>
>Not tested specifically, but I've run into this problem before with 
>ordinary parsing errors (e.g. undeclared identifiers) not related to 
>#fopen.

Thorsten doesn't accept that as confirmation, so I'll move it back into
unconfirmed.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Wasn't it Coridon Henshaw who wrote:
>> media & fog bug?
>> http://news.povray.org/3c1379e0$1@news.povray.org
>
>Confirmed.

Thorsten says it's not confirmed.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message