I'm working on a new version (0.95?) of the DF3 proximity pattern macros.

The main thing I'm doing is trying to make everything automatic, so a user
doesn't have to do much more than:

/* Only need to generate the DF3 Pattern the very first time */
#if( generate_df3 = true )
 //Proximity_SetMeshMode( mesh_mode )
 Proximity_GenerateMap( obj, object_name )
#end

/* Load the DF3 Proximity Pattern */
//Proximity_SetPatternSmoothingMode( true )
#declare df3_pattern = Proximity_LoadMap( obj, object_name )

and everything just works. The macros take care of finding a reasonably tight
bounding box, the number of voxels to use in the three dimensions, what
blurring values to use on load, etc.

You should get a good render with the default setting, and then you can tweak
them if you want to - starting from a scene where it should be working pretty
well initially.

I'm saving the "object_name.df3" file and also a "object_name.prox" file that
contains the parameters the macros need for loading.

And here is another test render, this time with both the pigment and normals
being driven by the proximity pattern (and some noise).

Umm, there also seem to be some rendering artefacts that I think are to do with
turning normals on in radiosity under the latest 3.7 beta.

Cheers,
Edouard.

Post a reply to this message

Attachments:
Download 'df3-prox-with-normals.jpg' (91 KB)

Preview of image 'df3-prox-with-normals.jpg'

Edouard schrieb:
> 
> Umm, there also seem to be some rendering artefacts that I think are to do with
> turning normals on in radiosity under the latest 3.7 beta.

Can you be more specific?

What I do see are two horizontal lines which are quite definitely 
radiosity artifacts indeed, but those are not particularly related to 
turning on normals. They are a general result of samples being taken 
during the final render, which are just more prone to appear when 
normals are turned on, for the simple reason that it requires a higher 
sample density.

Make sure you have always_sample off, low_error_factor set to something 
like 0.5, and reduce the pretrace_end value.

The radiosity statistics may give you a hint how good your pretrace 
settings are. I recommend making sure that no more than half the total 
number of samples is taken during the main render.

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> wrote:

> Umm, there also seem to be some rendering artefacts that I think are to do with
> turning normals on in radiosity under the latest 3.7 beta.
>
> Cheers,
> Edouard.

I can see some blocks in the middle of the fractal, would you mind posting the
radiosity portion of the scene?

-Reactor

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Edouard schrieb:
> >
> > Umm, there also seem to be some rendering artefacts that I think are to do with
> > turning normals on in radiosity under the latest 3.7 beta.
>
> Can you be more specific?
>
> What I do see are two horizontal lines which are quite definitely
> radiosity artifacts indeed, but those are not particularly related to
> turning on normals. They are a general result of samples being taken
> during the final render, which are just more prone to appear when
> normals are turned on, for the simple reason that it requires a higher
> sample density.

Ahh, I didn't know that - I hadn't seen that kind of artefact before.

My settings were:

        radiosity {
   pretrace_start 0.08
   pretrace_end 0.005
   count 20 * radiosity_quality
   nearest_count 5
   error_bound 1
   recursion_limit 2
   low_error_factor 0.5
   gray_threshold 0.0
   minimum_reuse 0.015
   brightness 1
   adc_bailout 0.01/2
         }

where radiosity_quality was 2.

always_sample off seemed to fix it, but I have to admit that I still find the
exact behaviour of many of the radiosity parameters a bit of a mystery.

> The radiosity statistics may give you a hint how good your pretrace
> settings are. I recommend making sure that no more than half the total
> number of samples is taken during the main render.

Ahh, OK - what am I looking for in the stats?

Cheers,
Edouard.

Post a reply to this message

Edouard schrieb:

> Ahh, I didn't know that - I hadn't seen that kind of artefact before.

They seem to rarely look like this; usually they're more prominent near 
edges where sample density is particularly high, and then accumulate 
there to give the whole area a distinctively jagged noisy look. It is 
probably only when the sample density is low (due to comparatively flat 
geometry and/or a high error_bound) yet at the same time pretrace is 
insufficient for some reason (e.g. due to some sparse geometric or 
fake-geometric features, or always_sample set to "on") that they exhibit 
this particular look.

> always_sample off seemed to fix it, but I have to admit that I still find the
> exact behaviour of many of the radiosity parameters a bit of a mystery.

This does not really come as a surprise to me :-)

I still intend to get rid of at least /two/ of the parameters: 
nearest_count, which is partially redundant with low_error_factor when 
used with always_sample off, and always_sample which I find no reason 
whatsoever to set this to anything other than "off" (with the default 
value unfortunately being "on"), but work has stalled a bit on this.

Unfortunately, all the other parameters appear to be essential (or would 
need to be replaced with other ways of parameterizing the same thing). 
There are even some hard-coded parameters in the algorithm, a few of 
which I'm not perfectly happy hiding them from the user.


>> The radiosity statistics may give you a hint how good your pretrace
>> settings are. I recommend making sure that no more than half the total
>> number of samples is taken during the main render.
> 
> Ahh, OK - what am I looking for in the stats?

There should be a section like this:

--------------------------------------------------------------------------
   Pass     Depth 0    Depth 1    Depth 2           Total
--------------------------------------------------------------------------
   1             81         73          5             159
   2            156         36          -             192
   Final        256          4          -             260
--------------------------------------------------------------------------
   Total        493        113          5             611
   Weight     0.362      0.212      0.087
--------------------------------------------------------------------------

In this example, 81 samples were taken during first pretrace step, 156 
during the second, and another 256 samples were taken during the final 
render (at recursion depth 0; the other depths are not a problem as they 
cannot cause visible artifacts), so that 256 of 493 samples are taken 
during final render. This is a pretty ok ratio.

Post a reply to this message

High!

A question for convenience: are you identical with Edouard Poor? As I 
keep track of p.b.i. since 2000 and built a private archive of images 
posted here, almost 1,300 "artist folders" containing about 17,000 
images have accumulated since then on my "POV Gallery" DVD, and it would 
be handy to merge mistakenly created folders of identical POV artists...

See you in Khyberspace!

Yadgar

Now playing: Wishing (Asia)

Post a reply to this message

=?ISO-8859-1?Q?J=F6rg_=27Yadgar=27_Bleimann?= <yaz### [at] gmxde> wrote:
> keep track of p.b.i. since 2000 and built a private archive of images
> posted here, almost 1,300 "artist folders" containing about 17,000
> images have accumulated since then on my "POV Gallery" DVD

Wow, that's quite a collection. It would make a great slideshow. Do you keep all
posted images, or just "finished" ones? (for any given definition of
"finished"!)

Post a reply to this message

Among other things, clipka saw fit to write:

> There should be a section like this:
> 
> --------------------------------------------------------------------------
>    Pass     Depth 0    Depth 1    Depth 2           Total
> --------------------------------------------------------------------------
>    1             81         73          5             159
>    2            156         36          -             192
>    Final        256          4          -             260
> --------------------------------------------------------------------------
>    Total        493        113          5             611
>    Weight     0.362      0.212      0.087
> --------------------------------------------------------------------------
> 
> In this example, 81 samples were taken during first pretrace step, 156
> during the second, and another 256 samples were taken during the final
> render (at recursion depth 0; the other depths are not a problem as they
> cannot cause visible artifacts), so that 256 of 493 samples are taken
> during final render. This is a pretty ok ratio.

Would it make sense to print this ratio explicitly in the output, so that
the user can refer to its value?

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

Jellby schrieb:
> Would it make sense to print this ratio explicitly in the output, so that
> the user can refer to its value?

While writing that post I thought about that, too. Should be no problem 
actually. Maybe even print an outright warning if that ratio is found to 
have exceeded 50% during the render.

Post a reply to this message

"clipka" <ano### [at] anonymousorg> schreef in bericht 
news:4aa7e4e5@news.povray.org...
> Jellby schrieb:
>> Would it make sense to print this ratio explicitly in the output, so that
>> the user can refer to its value?
>
> While writing that post I thought about that, too. Should be no problem 
> actually. Maybe even print an outright warning if that ratio is found to 
> have exceeded 50% during the render.

Yes, please???  :-)

Thomas

Post a reply to this message