Been playing with isosurfaces in 3.5 and I am wondering
if the attached image is a bug or not.  It happens using
f_noise3d and with f_noise_generator using generator 0 or 1.
Using f_noise_generator with a generator of 2 does not produce
the problem.
	.pov source posted on povray.scenes.text-files

Pete

Post a reply to this message

Attachments:
Download 'iso35_01.jpg' (14 KB)

Preview of image 'iso35_01.jpg'

In article <3bbce60b.1409922@localhost>, PeterC@nym.alias.net.almost 
says...

> 	Been playing with isosurfaces in 3.5 and I am wondering
> if the attached image is a bug or not. 

This is a typical problem resulting from an insufficient max_gradient.
Not a bug.

Lutz-Peter

Post a reply to this message

nospam wrote:
> 
>         Been playing with isosurfaces in 3.5 and I am wondering
> if the attached image is a bug or not.  It happens using
> f_noise3d and with f_noise_generator using generator 0 or 1.
> Using f_noise_generator with a generator of 2 does not produce
> the problem.
>         .pov source posted on povray.scenes.text-files
> 

Sorry, but sometimes i wonder why we put much work into the documentation
if it's not read.  

Reading the corresponding chapters from the docs when working on a new
feature is really a good idea, nearly everytime i read a chapter i
recognize something new or what i forgot.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

hmmm looks like a silhouette of a phoenix

nospam wrote:

>         Been playing with isosurfaces in 3.5 and I am wondering
> if the attached image is a bug or not.  It happens using
> f_noise3d and with f_noise_generator using generator 0 or 1.
> Using f_noise_generator with a generator of 2 does not produce
> the problem.
>         .pov source posted on povray.scenes.text-files
>
> Pete
>
>  [Image]

Post a reply to this message

http://www.students.tut.fi/~warp/povVFAQ/languageVFAQ.html#isosurfacebug

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Warp schrieb in Nachricht <3bbdba92@news.povray.org>...
>http://www.students.tut.fi/~warp/povVFAQ/languageVFAQ.html#isosurfacebug
>


Wouldn't it be good to mention "accuracy" in this VFAQ-Answer, too?

Marc-Hendrik

Post a reply to this message

Marc-Hendrik Bremer wrote:
> 
> Wouldn't it be good to mention "accuracy" in this VFAQ-Answer, too?
> 

For what reason? I don't remember many people having problems with that,
and the meaning is pretty self explanatory.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Christoph Hormann schrieb in Nachricht <3BBDE65F.62377969@gmx.de>...
>Marc-Hendrik Bremer wrote:
>>
>> Wouldn't it be good to mention "accuracy" in this VFAQ-Answer, too?
>>
>
>For what reason? I don't remember many people having problems with that,
>and the meaning is pretty self explanatory.


Because in my opinion those artefacts are not always caused by an inaccurate
max_gradient. Esp. those where big parts are missing or disappearing seems
to me more like an inaccurate accuracy then a max_gradient problem (which
are those black spots like in the scene the thread started with). I may be
wrong in this, but that's how I experienced it in the past.
In addition max_gradient and accuracy seems not to be independent if I
remember an article of the original isosurface-patch writer some weeks ago
correct (unfortunately it was in one of those "Hey folks!"-threats and I
can't find it). While max-gradient seems to determine the "step-width" of
the algorithm, accuracy tells when to stop to look for an ray-intersection.
Is this wrong?
Of course, max-gradient is far more often the problem, which leads to those
artefacts.

Marc-Hendrik

Post a reply to this message

Marc-Hendrik Bremer wrote:
> 
> Because in my opinion those artefacts are not always caused by an inaccurate
> max_gradient. Esp. those where big parts are missing or disappearing seems
> to me more like an inaccurate accuracy then a max_gradient problem (which
> are those black spots like in the scene the thread started with). I may be
> wrong in this, but that's how I experienced it in the past.

Accuracy just influences how small details are visible, lower values lead
to more detailed surfaces and usually require higher max_gradient.  Just
try it, the default value of 0.001 is quite low, if you use for example
0.1 on a RMF function isosurface, you will get a not very detailed
surface.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Christoph Hormann schrieb in Nachricht <3BBE0827.BE2E41F3@gmx.de>...
>Accuracy just influences how small details are visible, lower values lead
>to more detailed surfaces and usually require higher max_gradient.  Just
>try it, the default value of 0.001 is quite low, if you use for example
>0.1 on a RMF function isosurface, you will get a not very detailed
>surface.
>


While you are right that higher accuracy values decrease the level of
detail, it has other influences, too.
I just tried it with an old scene and attached the resulting image. I
increased the accuracy value by far (0.1 instead of 0.000001) and left
anything else the way it was (after converting to 3.5 language of course).
Pov reports, that I should decrease max_gradient to lower rentertime  (5.141
instead of 6). In my opinion that black part is one of those isosurface
artefacts.

Marc-Hendrik

Post a reply to this message

Attachments:
Download 'landschaft low acc.jpg' (12 KB)

Preview of image 'landschaft low acc.jpg'

Marc-Hendrik Bremer wrote:
> 
> While you are right that higher accuracy values decrease the level of
> detail, it has other influences, too.
> I just tried it with an old scene and attached the resulting image. I
> increased the accuracy value by far (0.1 instead of 0.000001) and left
> anything else the way it was (after converting to 3.5 language of course).
> Pov reports, that I should decrease max_gradient to lower rentertime  (5.141
> instead of 6). In my opinion that black part is one of those isosurface
> artefacts.
> 

From just the picture i can't conclude much, but Povray's suggestion that
max_gradient is too high does not necessarily need to be correct.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Wasn't it nospam who wrote:

>       Been playing with isosurfaces in 3.5 and I am wondering
>if the attached image is a bug or not.  It happens using
>f_noise3d and with f_noise_generator using generator 0 or 1.
>Using f_noise_generator with a generator of 2 does not produce
>the problem.
>       .pov source posted on povray.scenes.text-files

I guess it's way too late to suggest that max_gradient ought to be made
mandatory for isosurfaces.

Or warn "Warning: isosurface has no max_gradient set. The isosurface may
contain holes! Set a correct max_gradient value to get a proper
rendering of the isosurface."

Or let the default value of max_gradient be changed to a value that's
likely to look OK for simple surfaces. I'd suggest a default value of
10.

As things currently stand we're likely to be seeing an *awful* lot of
occurrences of this question in the future.



-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Post a reply to this message

Marc-Hendrik Bremer wrote:
> 
> That's undoubted (now Pov found a max_gradient of 6.294), but my point was,
> that setting the accuracy value to high, can lead to artefacts. I'll post a
> simplified code for this in p.t.s-f (under "Low accuracy values in
> Isosurfaces"). Output changes a bit (because of a simplified texture), but
> the behaviour should be reproducible. To exclude that this is a max_gradient
> problem I just rendered it with max_gradient 60. Those black parts remained.
> Perhaps it's another problem, but I can't imagine which.
> 

I can see what you mean.  But these artefacts are different from those
resulting of insufficient max_gradient.  I don't think they are something
new users have to struggle with very often.  

I don't know much about the isosurface algorithm, but maybe that's even
something that could be fixed.

BTW, i recognize some of my textures in that scene...

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Post a reply to this message

Marc-Hendrik Bremer wrote:
> 
> max_gradient problems are far more likely, I agree. There poped up just
> another one in p.b.p-t. Perhaps Warp should also mention that it's a good
> idea to make the container object as small as possible, since you can lower
> max_gradient with a smaler container wuite a bit and things will speed up.
> 

I don't think a smaller container can reduce required max_gradient (unless
the high gradient only occurs outside the smaller container object).  

Making container objects as small as possible should be quite obvious. 
It's also mentioned in detail in the documentation, so i don't think it's
required to put it in the FAQ unless Warp wants to make a general
'isosurface speed' section.

> 
> You think, that's a bug? I would say it's a user error.
> 

I would not say it's a bug, but it could be that the isosurface code can
be modified to avoid it.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Post a reply to this message

Marc-Hendrik Bremer wrote:
> 
> But a bigger container can require a higher max_gradient (see p.b.b-t
> "isosurface contained_by or evaluation problem"). I'm not sure if this is an
> expectable behaviour, but it seems somewhat logical to me. I finally found
> the description of the isosurface search method from R. Suzuki in p.general:
> RE: Isosurface and function pattern in v3.5
> (Message-ID<3b984214@news.povray.org> if that helps anything). If the points
> d1 and d2 he mentions are further apart, isn't a greater max_gradient
> needed?

No. The gradient of a function is a local property:  <df/dx, df/dy,
df/dz>  The max_gradient value is used to determine if there's a possible
intersection between two points (of arbitrary distance) under the
condition that the gradient between the two evaluated points is maximum.

> But that's all just guessing of course. But it's clear that if the container
> is to big (for what reason ever), the surface will sometimes (but
> reproducible - no "random-number-thingie" as with those pigment-patterns)
> disappear unless you raise max_gradient.

Because of the things mentioned above changing the container size should
have no influence in whether a surface is visible or not (onless you use
'evaluate' of course) but the scene you mentioned really seems to prove
the opposite.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Post a reply to this message

Marc-Hendrik Bremer wrote:
> 
> Please have a look at Mike Williams reply to "isosurface contained_by or
> evaluation problem" which describes much better than I can, why the size of
> the container has an influence.
> 

Yes, saw it.  Thanks.

In fact i mentioned this possibility in

news://news.povray.org/3BBEE00B.2E13A766%40gmx.de

but then forgot about it myself. :-)

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

On Fri, 5 Oct 2001 03:14:04 +0200, Lutz-Peter Hooge <lpv### [at] gmxde>
wrote:

>In article <3bbce60b.1409922@localhost>, PeterC@nym.alias.net.almost 
>says...
>
>> 	Been playing with isosurfaces in 3.5 and I am wondering
>> if the attached image is a bug or not. 
>
>This is a typical problem resulting from an insufficient max_gradient.
>Not a bug.
>
>Lutz-Peter

Thanks for the help.  Since I've never used Mega-POV, this whole
isosurface thing is completely new to me.

Pete

Post a reply to this message

On Fri, 05 Oct 2001 08:24:15 +0200, Christoph Hormann
<chr### [at] gmxde> wrote:

--snippage--

>
>Sorry, but sometimes i wonder why we put much work into the documentation
>if it's not read.  
>

Rather than playing dump-on-the-newbie as well as Oh-So-High-And
-Mighty, you *could* have referred me to the relevent section of the
documentation that I glaringly overlooked.

In other words, you expended the effort to reply to my posting
but contributed nothing.

Fortunately, others on these newsgroups with a less negative
frame of mind have posted helpful and informative posts.

Good day

Post a reply to this message

nospam wrote:
> 
> Rather than playing dump-on-the-newbie as well as Oh-So-High-And
> -Mighty, you *could* have referred me to the relevent section of the
> documentation that I glaringly overlooked.
> 
> In other words, you expended the effort to reply to my posting
> but contributed nothing.
> 

Sad you see it that way, looking for 'isosurface' in the help index will
bring you immediately it the relevant sections (isosurface
object/tutorial) and there you will find both the information needed to
solve the problem and the hints to understand it.

> Fortunately, others on these newsgroups with a less negative
> frame of mind have posted helpful and informative posts.
> 

I do not like this attitude.  If you don't appreciate the way i answered
your question that's ok, but you should not expect that everytime you have
a question someone will directly give a solution for it.  It was perfectly
possible to find a solution from what i answered.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Christoph wrote:
>Marc-Hendrik Bremer wrote:
>> Wouldn't it be good to mention "accuracy" in this VFAQ-Answer, too?
>
>For what reason? I don't remember many people having problems with 
>that, and the meaning is pretty self explanatory.

There is a plobrem on "accuracy" if the thickness of the isosurface 
is thinner than the accuracy value.  For example, following isosurface 
will generate artifacts(artefacts). 

isosurface {
        function {-0.002+abs(-3.0+f_r(x,y,z))}
        contained_by { sphere { 0, 3.1 } } 
        accuracy 0.01                      
}

Thus if the isosurface has a fine-structure, the "accuracy" value 
should be less than the size of the fine-structure.

R. Suzuki

Post a reply to this message

"R. Suzuki" wrote:
> 
> There is a plobrem on "accuracy" if the thickness of the isosurface
> is thinner than the accuracy value.  For example, following isosurface
> will generate artifacts(artefacts).
> 
> isosurface {
>         function {-0.002+abs(-3.0+f_r(x,y,z))}
>         contained_by { sphere { 0, 3.1 } }
>         accuracy 0.01
> }
> 
> Thus if the isosurface has a fine-structure, the "accuracy" value
> should be less than the size of the fine-structure.
> 

Yes, it seems quite natural, same happens when tesselating such
isosurfaces.  I think there is nothing you can do about it.

BTW, you can create nice moire-like patterns with that method. :-)

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message