Dear POVRay users,

when I put sky sphere (with HDR file) + reflective box (with gif texture file) +
reflective/refractive mesh2, the rendering results are different even they are
generated from the same pov file. Is this usual or am I missing something?

Thanks

Post a reply to this message

> Dear POVRay users,
>
> when I put sky sphere (with HDR file) + reflective box (with gif texture file) +
> reflective/refractive mesh2, the rendering results are different even they are
> generated from the same pov file. Is this usual or am I missing something?
>
> Thanks
>
>

Can you post a small sample scene that show your problem?
Many users can provide their own HDR and image map.
If the mesh2 is large, use a symplified/largely decimated one.
If the sanple scene is relatively small (under 5K), you can post it 
here. For larger ones, you can use povray.text.scene-files or 
povray.binaries.scene-files.

Make sure that you use spherical mapping for your HDR image. Add 
map_type 1 to your pigment.

Is your mesh2 closed?


Alain

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:

> > Dear POVRay users,
> >
> > when I put sky sphere (with HDR file) + reflective box (with gif texture file) +
> > reflective/refractive mesh2, the rendering results are different even they are
> > generated from the same pov file. Is this usual or am I missing something?
> >
> > Thanks
> >
> >
>
> Can you post a small sample scene that show your problem?
> Many users can provide their own HDR and image map.
> If the mesh2 is large, use a symplified/largely decimated one.
> If the sanple scene is relatively small (under 5K), you can post it
> here. For larger ones, you can use povray.text.scene-files or
> povray.binaries.scene-files.
>
> Make sure that you use spherical mapping for your HDR image. Add
> map_type 1 to your pigment.
>
> Is your mesh2 closed?

Yes, it is closed. I tested with a simple object (ovus) as well, and the same
problem existed. I post the simple test pov-file:

#version 3.7;

global_settings {
  assumed_gamma 1.33
  max_trace_level 30
  radiosity {
    count 200
    error_bound 0.1
    recursion_limit 2
    nearest_count 8
    brightness 1
    normal on
    adc_bailout 0.005
  }
}

#declare CamPos = <0.72, 1.52, 3.2>;
#declare CamLookAt = <0.2, 0.5, 0.8>;
camera {
  right -x*image_width/image_height
  location CamPos
  look_at CamLookAt
}

#declare F_Water = finish {
  ambient 0
  diffuse 0
  phong 1
  phong_size 90
  reflection {0.1, 1 fresnel on}
  conserve_energy
}

#declare F_Plane = finish {
  phong 0.37
  phong_size 25
  ambient 0
  reflection 0.05
}

#declare T_Water = texture {
  pigment { rgbf <0.98, 0.98, 0.98, 0.98> }
  finish {F_Water}
}

#declare T_Plane = texture {
  pigment { rgb<0.6, 0.3, 0.5> }
  finish {F_Plane}
}

#declare I_Water = interior {
  ior 1.33335
  fade_power 1
}

#declare M_Water = material {
  texture {T_Water}
  interior{I_Water}
}

#declare Water = ovus {
  0.2, 0.1
  translate -y*0.04
  material {M_Water}
}

#declare Thickness = 0.025;
#declare Table = box {
  <-2, -Thickness, -2>, <2, -Thickness*4, 2>
  rotate y*-49
  texture { T_Plane }
}

light_source {CamPos color rgb<0.9, 0.9, 1>*0.1}

sky_sphere {
  pigment {image_map {hdr "*HDR_FILE_PATH.hdr*" map_type 1 interpolate 2}}
  rotate y*-120
}

union {
  object {Table}
  object {
    Water
    translate <0, 0.5, 0.5>
  }
}

The table is always differently rendered with some jitters.

Post a reply to this message

Le 31/07/2011 12:45, kiwon nous fit lire :
> Alain <aze### [at] qwertyorg> wrote:
> 
> The table is always differently rendered with some jitters.
> 

Confirmed... using classical kitchen_probe.hdr... when more than 1
working thread.

using +wt1 removes the difference (but it is still sensible to +BS(int)
+RP(int) +RS(int) (Block Size, Render pattern, Render step)

Looks like some code is using a global resource, unprotected (like a
random generator ?)

Post a reply to this message

Le 2011/07/31 09:25, Le_Forgeron a écrit :
> Le 31/07/2011 12:45, kiwon nous fit lire :
>> Alain<aze### [at] qwertyorg>  wrote:
>>
>> The table is always differently rendered with some jitters.
>>
>
> Confirmed... using classical kitchen_probe.hdr... when more than 1
> working thread.
>
> using +wt1 removes the difference (but it is still sensible to +BS(int)
> +RP(int) +RS(int) (Block Size, Render pattern, Render step)
>
> Looks like some code is using a global resource, unprotected (like a
> random generator ?)

There is a note about radiosity that say that *exact* reproduction is 
NOT guaranteed from render to render when using radiosity.
It seems to be because radiosity use some montecarlo approximation and 
some other pseudo-random sequences.

There is a flag that can be set to increase the similarity. It will tend 
to slightly increase the rendering time.

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:
> There is a note about radiosity that say that *exact* reproduction is
> NOT guaranteed from render to render when using radiosity.

Is this always correct even when I do not use the HDR image?

--
Kiwon

Post a reply to this message

On 01.08.11 06:58, kiwon wrote:
> Alain<aze### [at] qwertyorg>  wrote:
>> There is a note about radiosity that say that *exact* reproduction is
>> NOT guaranteed from render to render when using radiosity.
>
> Is this always correct even when I do not use the HDR image?

Yes, it is due to radiosity. HDR has nothing to do with it.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> On 01.08.11 06:58, kiwon wrote:
> > Alain<aze### [at] qwertyorg>  wrote:
> >> There is a note about radiosity that say that *exact* reproduction is
> >> NOT guaranteed from render to render when using radiosity.
> >
> > Is this always correct even when I do not use the HDR image?
>
> Yes, it is due to radiosity. HDR has nothing to do with it.

Thanks. This sounds like that it isn't a good choice to use radiosity for
animation. Huh?

--
Kiwon

Post a reply to this message

Am 31.07.2011 15:25, schrieb Le_Forgeron:

> Looks like some code is using a global resource, unprotected (like a
> random generator ?)

Possibly the radiosity sample cache; for pretrace efficiency, this is 
shared among all threads, with the effect that a sample at a certain 
point may or may not be taken depending on whether another thread has 
already taken samples nearby or not.

You may try using +HR (or "High_Reproducibility=on"); this will 
essentially prevent re-use of radiosity samples taken for a different 
render block in the same pretrace pass (with certain well-controlled 
exceptions), so that the radiosity pretrace always produces the very 
same set of samples regardless of thread scheduling and number of render 
threads. It is slower though.

At present this option affects only radiosity sampling; however, the 
idea is for the option to eliminate any non-determinisms in render 
artifacts (there still are some, but I never found the time to hunt them 
down yet) by throwing a moderate deal of extra computing effort at them 
if they can't be avoided otherwise.

Post a reply to this message

Am 02.08.2011 13:53, schrieb kiwon:
> Thorsten Froehlich<tho### [at] trfde>  wrote:
>> On 01.08.11 06:58, kiwon wrote:
>>> Alain<aze### [at] qwertyorg>   wrote:
>>>> There is a note about radiosity that say that *exact* reproduction is
>>>> NOT guaranteed from render to render when using radiosity.
>>>
>>> Is this always correct even when I do not use the HDR image?
>>
>> Yes, it is due to radiosity. HDR has nothing to do with it.
>
> Thanks. This sounds like that it isn't a good choice to use radiosity for
> animation. Huh?

If you want to do radiosity in animations, make sure to use very 
high-quality settings to minimize any radiosity artifacts (which of 
course requires high render times, which you'll usually want to avoid in 
animations).

If your animation is limited to changes in camera perspective you can 
mitigate this drawback by re-using the radiosity samples from frame to 
frame. You may even get away with lower quality settings if you do two 
passes of the animation, one for collecting radiosity samples to cover 
all camera angles (this can be a low-resolution pass rendering only 
every N-th frame) and one for the actual render. (Without the first pass 
you might see some flickering at the border of areas the camera sees for 
the first time).

Post a reply to this message