> But I think that maybe this is an accuracy thing with the roots of the equation,
> so maybe since the surface is infinitely thin, do something like creating a very
> thin shell using "abs(Function (x, y, z)) - a very small value".
>
> The other thing you could try is make it an isosurface and see if somehow that
> works any better.  You can also employ the shell method with that as well.
>
> That's all I've got right now.

I actually wrote this a while ago, and at that time I think I tried with an
isosurface but can't remember what was not working (on the top of my head I'd
say it was unpractically slow ?)

>
> Very cool surface, by the way   :)
> I might look at this for inspiration if I ever fool around with refining my
> modeling of the "schist disk" again.

Thanks :) This is kind of a classic actually, a so-called Seifert surface for a
torus knot. I isolated the problematic part when asking this question but if
you're curious here is what I actually wanted to plot (using jr tweaks ! Thought
I get an error from the +ac0.99 option, I'll try to figure out why).

Post a reply to this message

Attachments:
Download 'out.png' (196 KB)

Preview of image 'out.png'

hi,

"Adrien" <nomail@nomail> wrote:
> > ...
> Fantastic, thanks a lot ! ...

great.  (and, pleasure)


> ... Thought I get an error from the +ac0.99 option, I'll try to figure out why.

you do use a v3.8?


regards, jr.

Post a reply to this message

On 12/6/22 04:03, Adrien wrote:
> I'm trying to use Povray to plot a surface defined by a polynomial equation
> spitted out by an auxiliary program. However, whenever the degree of that
> polynomial is 10 or more I get a bunch of artifacts/black dots. Is there a way
> to fix that ? Either directly in Povray, or in the auxiliary program ?

As per others, stronger AA in official POV-Ray is probably your best / 
quick solution.


---
FWIW.

a) The box-ish fails in your original image are very likely related to 
the shadow cache bugs (there are 2.5 of these in official releases).

b) The general spotty result is at lest somewhat related to issues with 
the official sturmiam based solver.

c) Some of the spotty result is shadow tolerance related coupled to how 
accurate the sturm solver results are.

d) The results are somewhat inaccurate simply because it's a tenth order 
poly.

Attached an image using my current povr branch where a and b already 
better due fixes.

The issue (c) can be made better with povr's shadow_tolerance keyword 
changing the default from 1e-3 to 1e-2 in this particular case. Here the 
results just are a little inaccurate due the 10th order and we pick up 
at surface roots during shadow testing as real blockage when the roots 
are inaccurate representations of the ray origin root(d)...

Attached a povr result using no AA, default shadow tolerance of 1e-3.

Bill P.

Post a reply to this message

Attachments:
Download 'adrien_povrnoaa.png' (149 KB)

Preview of image 'adrien_povrnoaa.png'

Op 6-12-2022 om 14:45 schreef jr:
> hi,
> 
> "Adrien" <nomail@nomail> wrote:
>>> ...
>> Fantastic, thanks a lot ! ...
> 
> great.  (and, pleasure)
> 
> 
>> ... Thought I get an error from the +ac0.99 option, I'll try to figure out why.
> 
> you do use a v3.8?
> 
> 
Artefacts (almost) disappear with:

+am3 +a0.01 +ac0.99 +r4


-- 
Thomas

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Adrien" <nomail@nomail> wrote:
> > > ...
> > Fantastic, thanks a lot ! ...
>
> great.  (and, pleasure)
>
>
> > ... Thought I get an error from the +ac0.99 option, I'll try to figure out why.
>
> you do use a v3.8?
>
>
> regards, jr.

No 3.7, I had compiled 3.8 a while ago but it broke when I upgraded my distro.
Will compile again.

Post a reply to this message

hi,

"Adrien" <nomail@nomail> wrote:
> No 3.7, I had compiled 3.8 a while ago but it broke when I upgraded my distro.
> Will compile again.

<https://github.com/POV-Ray/povray/tags>


regards, jr.

Post a reply to this message

Op 6-12-2022 om 10:03 schreef Adrien:
> Hi,
> 
> I'm trying to use Povray to plot a surface defined by a polynomial equation
> spitted out by an auxiliary program. However, whenever the degree of that
> polynomial is 10 or more I get a bunch of artifacts/black dots. Is there a way
> to fix that ? Either directly in Povray, or in the auxiliary program ?
> 

wrapping up my experiments, I think I got a acceptable solution for your 
problem. Use the following additions/changes to your code (see attached 
image):

//=====================================================
//+w640 +h640 +am3 +a0.01 +ac0.99 +r3 +bm2 +bs8

#version 3.8;

global_settings {
   assumed_gamma 1.0
   radiosity {
     pretrace_start 16/max(image_width,image_height)
     pretrace_end   4/max(image_width,image_height)
     minimum_reuse  4/(max(image_width,image_height)-0.05)
     #if (Stochastic)
       count 10
     #else
       count 50, 1000
     #end
     nearest_count 20, 3
     error_bound 1
     recursion_limit 2
     low_error_factor .3
     gray_threshold 0.0
     //minimum_reuse 0.015
     maximum_reuse 0.1
     brightness 1

     adc_bailout 0.01/2
     normal off
     media off
     always_sample off
     //max_sample 1.0
   }
}

light_source {
   2*<5, 10, -40>
   color White
   area_light <5, 0, 0>, <0, 0, 5>, 5, 5
   adaptive 2
   area_illumination on
   jitter
   circular
   orient
   /*fade_power 1
   fade_distance 30*/
}
//=====================================================

All the rest is unchanged. Whether radiosity is "necessary" here is a 
matter of taste.

Very interesting poly btw...

-- 
Thomas

Post a reply to this message

Attachments:
Download 'adrien_poly.png' (176 KB)

Preview of image 'adrien_poly.png'

I see I have forgotten to add:

#declare Stochastic = on;

before the global_settings block. Sorry.

-- 
Thomas

Post a reply to this message

Le 2022-12-08 à 08:06, Thomas de Groot a écrit :
light_source {
   2*<5, 10, -40>
   color White
   area_light <5, 0, 0>, <0, 0, 5>, 5, 5
   adaptive 2
   area_illumination on
   jitter
   circular
   orient
   /*fade_power 1
   fade_distance 30*/
}

Using adaptive 2 with that area_light is exactly the same as not using 
it at all as the starting grid is 5x5.
For adaptive 2 to have any benefit, the grid need to be strictly larger 
than 5 in at least one direction. So,
  area_light <5, 0, 0>, <0, 0, 5>, 9, 9
or more.

Adaptive level, starting grid
	0		2x2
	1		3x3
	2		5x5
	3		9x9
Here is the formula to know the starting grid :
(adaptive level)^2 +1

Post a reply to this message

Op 08/12/2022 om 19:56 schreef Alain Martel:
> Using adaptive 2 with that area_light is exactly the same as not using 
> it at all as the starting grid is 5x5.
> For adaptive 2 to have any benefit, the grid need to be strictly larger 
> than 5 in at least one direction. So,
>   area_light <5, 0, 0>, <0, 0, 5>, 9, 9
> or more.
> 
> Adaptive level, starting grid
>      0        2x2
>      1        3x3
>      2        5x5
>      3        9x9
> Here is the formula to know the starting grid :
> (adaptive level)^2 +1

Of course! My bad.

Thanks Alain. Always good to know someone is watching your back! ;-)

-- 
Thomas

Post a reply to this message