IT'S NOT A BUG IT'S A ...


There are holes in my isosurface, or it doesn't appear at all. 
Try setting max_gradient higher.


Parametric isosurfaces run about 50 times slower than MegaPOV.
Side effect of the removal of interval arithmetic.


Not all functions are available for use within user defined functions.
E.g. val(), rand() are not available.
The list of available functions is documented in 6.1.6.


My isosurface disappears half way through the render.
Crackle pigments are not suitable for use in isosurfaces.


Isosurface renders differently to MegaPOV.
This may be due to the fact that MegaPOV handled the square roots of
negative values incorrectly.


Some of the pigments in woods.inc look horrible.
Some of the pigments, such as "P_WoodGrain4B" are intended to be used in
conjunction with colour_maps from woodmaps.inc. With the default
colour_map they look weird.
Many of the pigments just happen to look OK because the default
colour_map for the wood pigment pattern consists of shades of brown.


The help system often leaves temporary files in Windows\temp.
Blame MicroSoft.


Within a function, "x" sometimes means "the x co-ordinate of the current
point" and sometimes means the vector <1,0,0>.
When the syntax demands a vector, "x" is interpreted as "<1,0,0,>".


Texture_map can't have more than 256 entries.
It's a limitation.


"diffuse" doesn't accept functions.
(Well, technically, you could use a float function to calculate the
diffuse value for an object, but you get a single value that applies to
the whole object.)
It's a limitation.


New noise generator isn't very random.
You shouldn't really be trying to use noise as a random number generator
(use rand() instead), even though the old noise generator did work quite
well.


Artefacts appear on the surface of a distant torus.
It's a limitation of the floating point accuracy of your computer. The
torus primitive uses a fourth order equation, so it fails first.


Isosurface intersections and merges (& and |) are the wrong way round in
beta 8
They were the wrong way round before. The beta 8 way is considered
correct.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

> Crackle pigments are not suitable for use in isosurfaces.

Why is this? Just the fact that it has non-differentiable points in the
function? In my experience setting a very high max_gradient usually
minimizes that problem; is there another reason for it?

> Artefacts appear on the surface of a distant torus.
> It's a limitation of the floating point accuracy of your computer. The
> torus primitive uses a fourth order equation, so it fails first.

Ah, thanks for the explanation about it being a fourth-order equation.

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

Post a reply to this message

"Mike Williams" wrote
> Isosurface intersections and merges (& and |) are the wrong way 
> round  in beta 8
> They were the wrong way round before. The beta 8 way is considered
> correct.

Thank you for the listing.

According to POV Help 6.1.3.3., & and | are logical operators.  
Thus, the result of (A & B) or (A | B) should be always boolean 
values of 0 and 1.  However, these expressions return min() 
or max() values in isosurface functions of beta 8.   
I think this is wrong behavior.

For me, && and || are more familiar as logical operators 
because those are used as so in Mathematica, C, etc.
But unfortunately, & and | were adopted as logical operators
in the previous POV-Ray version.

R. Suzuki

Post a reply to this message

In article <3c09f549@news.povray.org> , "R. Suzuki" <r-s### [at] aistgojp> 
wrote:

> According to POV Help 6.1.3.3., & and | are logical operators.
> Thus, the result of (A & B) or (A | B) should be always boolean
> values of 0 and 1.  However, these expressions return min()
> or max() values in isosurface functions of beta 8.
> I think this is wrong behavior.
>
> For me, && and || are more familiar as logical operators
> because those are used as so in Mathematica, C, etc.
> But unfortunately, & and | were adopted as logical operators
> in the previous POV-Ray version.

Exactly.  They will be changed to only work like boolean operators in a
future beta version.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Mike Williams wrote:
> My isosurface disappears half way through the render.
> Crackle pigments are not suitable for use in isosurfaces.

They work for me. (Are you referring to the standard crackle pattern?)

Post a reply to this message

Wasn't it JRG who wrote:
>Mike Williams wrote:
>> My isosurface disappears half way through the render.
>> Crackle pigments are not suitable for use in isosurfaces.
>
>They work for me. (Are you referring to the standard crackle pattern?)

This was my understanding of the outcome of the thread

Isosurface *disappears* at high resolution (fwd)
http://news.povray.org/3bb0b351@news.povray.org

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Mike Williams schrieb in Nachricht <7HPp+SA$DsC8Ew$+@econym.demon.co.uk>...
>Wasn't it JRG who wrote:
>>Mike Williams wrote:
>>> My isosurface disappears half way through the render.
>>> Crackle pigments are not suitable for use in isosurfaces.
>>
>>They work for me. (Are you referring to the standard crackle pattern?)
>
>This was my understanding of the outcome of the thread
>
>Isosurface *disappears* at high resolution (fwd)
>http://news.povray.org/3bb0b351@news.povray.org


Just use the right (low) accuracy-value and perhaps some high max_gradient
and anything should work fine. Some randomness is involved so one might get
different results between renders, but crackle works fine in many cases
afaik.

Marc-Hendrik

Post a reply to this message