|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 19-04-06 à 15:09, Tamas Gunda a écrit :
> I created 3D cube images with Povray - spherical images assembled from 6 images,
> each of the images corresponding to one face of a cube. Without using radiosity
> there are no problems. However, if radiosity is turned on, the six images do not
> fit exactly, there are differences in brightness of the faces. The code is the
> exactly the same for all faces, only the camera is rotated by 90 degs. Seems
> that the result of rendering with radiosity turned on depends on the camera
> direction.
>
> To better understand, have a look at www.gunda.hu/cube/povray
>
> Another perfect example, without using radiosity, is at www.gunda.hu/cube
>
>
>
Strange, radiosity have no effect of the geometry and should be
independent of the camera's location and orientation.
What can happen is a difference on what areas radiosity is sampling. If
that's the case, increasing the count value should help, also, using the
two values variant often help :
count 175 25000
You may also want to reduce the value for pretrace_end. Default is 0.04.
Try 0.01, 0.005 or 0.0025.
Looking at the dark end and you really need more samples. Quadrupling
your count value may not be quite enough. You may also need to increase
the recursion_limit value to 4 or maybe 5. Also, reducing minimum_reuse
could also help. Default is 0.015. Try 0.01 down to 0.004.
Adding some roundness to the edges can do a lot in reducing the
artefacts in the darker areas. A clipped cylinder will do the trick.
If you can post the source of your scene, it'll be easier to diagnose
the issue and help you.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <kua### [at] videotronca> wrote:
> Strange, radiosity have no effect of the geometry and should be
> independent of the camera's location and orientation.
>
> What can happen is a difference on what areas radiosity is sampling. If
> that's the case, increasing the count value should help, also, using the
> two values variant often help :
> count 175 25000
>
> You may also want to reduce the value for pretrace_end. Default is 0.04.
> Try 0.01, 0.005 or 0.0025.
>
> Looking at the dark end and you really need more samples. Quadrupling
> your count value may not be quite enough. You may also need to increase
> the recursion_limit value to 4 or maybe 5. Also, reducing minimum_reuse
> could also help. Default is 0.015. Try 0.01 down to 0.004.
>
> Adding some roundness to the edges can do a lot in reducing the
> artefacts in the darker areas. A clipped cylinder will do the trick.
>
> If you can post the source of your scene, it'll be easier to diagnose
> the issue and help you.
>
>
>
> Alain
Thanks for the reply. Well, I tried sytematically many variations. It helped to
decrease the artefacts, however, the main problem could not be solved. It is
mostly influenced when playing with the radiosity brightness and finish/diffuse
values of the walls, but the effect of a given setting is different on the
different faces. Inspect www.gunda.hu/cube/povray again: In the third picture
some of the differences between the cube sides disappeared (the upper and the
right), while others became stronger. In other words, it seems to me that nearly
every setting influences more or less the brightness of the generated pictures,
and this influence depends somehow on the direction of the camera.
The radiosity settings used:
#if (radio)
global_settings {
ambient_light 0
radiosity {
pretrace_start 64/image_width
pretrace_end 4/image_width //8
count 250 25000 //150
nearest_count 10 //
error_bound 0.33 //0.5
recursion_limit 4 //3
low_error_factor 0.5 //0.5
gray_threshold 0.5 //0.5
minimum_reuse 0.004 //0.025
maximum_reuse 0.2 //0.2
brightness 1.3 //1.5
adc_bailout 0.01 //0.01
media m_media
//max_sample 1
//normal on
}
}
#else
global_settings {ambient_light .1}
#end
Tamas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.04.2019 um 21:09 schrieb Tamas Gunda:
> I created 3D cube images with Povray - spherical images assembled from 6 images,
> each of the images corresponding to one face of a cube. Without using radiosity
> there are no problems. However, if radiosity is turned on, the six images do not
> fit exactly, there are differences in brightness of the faces. The code is the
> exactly the same for all faces, only the camera is rotated by 90 degs. Seems
> that the result of rendering with radiosity turned on depends on the camera
> direction.
This is to be expected to some degree.
What happens is that radiosty takes a couple of samples of indirect
lighting, and interpolates between those. The location of those samples
is determined pseudo-randomly, with a heavy influence from the camera
perspective (as well as other factors).
The interpolation between samples introduces subtle artifacts (very low
"frequency" and thus difficult to see under normal circumstances); the
camera-dependent pseudo-randomness causes the artifacts to differ
significantly between renders, even with only minor variations in camera
perspective or radiosity settings. This means that in a 1:1 comparison,
or when stitching images without soft blending between them, the
artifacts will become evident.
In official POV-Ray, the only way to solve this is to use either very
high-quality radiosity settings, or somehow introduce high-"frequency"
noise, so that enough samples are taken that the accuracy of the image
gets high enough for the seams to remain within the limits of human
perception or "drowns" in noise.
In UberPOV, you could choose radiosity settings such that instead of
interpolating between a limited number of samples it would compute
indirect lighting for each surface point separately. This changes the
type of artifacts to high-frequency noise, which will automatically hide
the seams, and arbitrary trade-offs between quality and render time can
easily be made via stochastic anti-aliasing. However, this also
increases render time significantly, especially so if you aim to reduce
the noise below the threshold of human perception. Another drawback is
that UberPOV only supports v3.7.0 syntax, not that of v3.8.0-alpha
currently in development.
Another alternative would be to use MCPov, but it is more difficult to
set up (you probably need to tamper with the scene itself, not just
global settings), has a systematic error in brightness computations that
needs working around, is limited to v3.6 syntax, and does not support
multi-core operation "out of the box". The approach would be more or
less the same as with UberPOV, but it may be able to achieve the same
quality with less CPU time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 19-04-07 à 09:28, Tamas Gunda a écrit :
> Alain <kua### [at] videotronca> wrote:
>> Strange, radiosity have no effect of the geometry and should be
>> independent of the camera's location and orientation.
>>
>> What can happen is a difference on what areas radiosity is sampling. If
>> that's the case, increasing the count value should help, also, using the
>> two values variant often help :
>> count 175 25000
>>
>> You may also want to reduce the value for pretrace_end. Default is 0.04.
>> Try 0.01, 0.005 or 0.0025.
>>
>> Looking at the dark end and you really need more samples. Quadrupling
>> your count value may not be quite enough. You may also need to increase
>> the recursion_limit value to 4 or maybe 5. Also, reducing minimum_reuse
>> could also help. Default is 0.015. Try 0.01 down to 0.004.
>>
>> Adding some roundness to the edges can do a lot in reducing the
>> artefacts in the darker areas. A clipped cylinder will do the trick.
>>
>> If you can post the source of your scene, it'll be easier to diagnose
>> the issue and help you.
>>
>>
>>
>> Alain
>
> Thanks for the reply. Well, I tried sytematically many variations. It helped to
> decrease the artefacts, however, the main problem could not be solved. It is
> mostly influenced when playing with the radiosity brightness and finish/diffuse
> values of the walls, but the effect of a given setting is different on the
> different faces. Inspect www.gunda.hu/cube/povray again: In the third picture
> some of the differences between the cube sides disappeared (the upper and the
> right), while others became stronger. In other words, it seems to me that nearly
> every setting influences more or less the brightness of the generated pictures,
> and this influence depends somehow on the direction of the camera.
>
>
> The radiosity settings used:
>
> #if (radio)
> global_settings {
> ambient_light 0
> radiosity {
> pretrace_start 64/image_width
> pretrace_end 4/image_width //8
> count 250 25000 //150
> nearest_count 10
Using a larger value, op to 20, can help in smoothing some rough edges.
> error_bound 0.33 //0.5
> recursion_limit 4 //3
Try 5 to bring some more light down the hallway.
> low_error_factor 0.5 //0.5
Reducing this may eliminate some artefacts.
> gray_threshold 0.5 //0.5
Should be kept at the default of 0
> minimum_reuse 0.004 //0.025
> maximum_reuse 0.2 //0.2
> brightness 1.3 //1.5
Should be left at default of 1
> adc_bailout 0.01 //0.01
Try something smaller, like 1/256. It can help when you have very bright
and dark areas.
> media m_media
> //max_sample 1
> //normal on
> }
> }
>
> #else
> global_settings {ambient_light .1}
>
> #end
>
>
> Tamas
>
>
Just an idea :
Try rendering it all in one go, then, project onto a box or sphere :
First, render using this camera :
camera{
spherical
angle 360
up y
right x*2
}
Render with a 2:1 aspect ratio with radiosity.
The image will look a little strange with both ends of the hallway
visible at the same time.
You may want to do a test without radiosity first to get a feel of how
it work.
Next, project the resulting image onto a box :
box{-1, 1
pigment{image_map{ png"ImageName.png" map_type 1 scale <-1,1,1>}}
finish{emission 1 diffuse 0 ambient 0}
}
Or a sphere :
sphere{0 1
pigment{image_map{ png"ImageName.png" map_type 1 scale <-1,1,1>}}
finish{emission 1 diffuse 0 ambient 0}
}
Render with a normal camera at <0,0,0> with no light.
If the image is to bright or dim, adjust emission to compensate.
As the whole scene was rendered as a single image, there can be no
seams, allowing you to use more relaxed radiosity settings.
The final renders will be fast as the geometry is simple, there are no
light, and only an image_map to evaluate.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
>
> This is to be expected to some degree.
> ...
> ...
> ...
> In official POV-Ray, the only way to solve this is to use either very
> high-quality radiosity settings, or somehow introduce high-"frequency"
> noise, so that enough samples are taken that the accuracy of the image
> gets high enough for the seams to remain within the limits of human
> perception or "drowns" in noise.
>
Indeed, I used now very high radiosity settings (with rendering time about 20x),
and although the result is still not perfect but much better. See the third
variation at the above url now.
Tamas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 08.04.2019 um 19:06 schrieb Alain:
> Just an idea :
> Try rendering it all in one go, then, project onto a box or sphere :
That's actually a pretty smart idea.
It's important though to use a high enough resolution, or at least use
interpolation for the projected image.
Alternatively, the image could be rendered directly to a single cube map
image using a v3.8.0-alpha user-defined camera (or a v3.7.0 mesh camera,
but that's more of a hassle to set up). If 6 separate images are needed,
that could then simply be achieved by cutting the output image into
pieces in any image processing software.
Post a reply to this message
|
|
| |
| |
|
|
From: Alain
Subject: Re: Radiosity rendering depends on camera direction?
Date: 9 Apr 2019 20:07:55
Message: <5cad33db@news.povray.org>
|
|
|
| |
| |
|
|
Le 19-04-09 à 06:25, clipka a écrit :
> Am 08.04.2019 um 19:06 schrieb Alain:
>
>> Just an idea :
>> Try rendering it all in one go, then, project onto a box or sphere :
>
> That's actually a pretty smart idea.
> It's important though to use a high enough resolution, or at least use
> interpolation for the projected image.
>
That's why I suggested to do some test without radiosity to get the feel
of it.
The horizontal resolution should be about the sum of that of the
individual images.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 08.04.2019 um 19:06 schrieb Alain:
>
> > Just an idea :
> > Try rendering it all in one go, then, project onto a box or sphere :
>
> That's actually a pretty smart idea.
> It's important though to use a high enough resolution, or at least use
> interpolation for the projected image.
>
> Alternatively, the image could be rendered directly to a single cube map
> image using a v3.8.0-alpha user-defined camera (or a v3.7.0 mesh camera,
> but that's more of a hassle to set up). If 6 separate images are needed,
> that could then simply be achieved by cutting the output image into
> pieces in any image processing software.
Bingo!
Thanks, Alain. Rendering with 360 deg spherical camera in one go and then
projecting onto a sphere and cut to cubic images has yielded a seamless
spherical image. The resolution of the first rendering should be at least twice
to that of final image.
http://www.gunda.hu/cube/povray/index3.html
Tamas
Post a reply to this message
|
|
| |
| |
|
|
From: Alain
Subject: Re: Radiosity rendering depends on camera direction?
Date: 10 Apr 2019 16:47:03
Message: <5cae5647@news.povray.org>
|
|
|
| |
| |
|
|
Le 19-04-10 à 14:34, Tamas Gunda a écrit :
> clipka <ano### [at] anonymousorg> wrote:
>> Am 08.04.2019 um 19:06 schrieb Alain:
>>
>>> Just an idea :
>>> Try rendering it all in one go, then, project onto a box or sphere :
>>
>> That's actually a pretty smart idea.
>> It's important though to use a high enough resolution, or at least use
>> interpolation for the projected image.
>>
>> Alternatively, the image could be rendered directly to a single cube map
>> image using a v3.8.0-alpha user-defined camera (or a v3.7.0 mesh camera,
>> but that's more of a hassle to set up). If 6 separate images are needed,
>> that could then simply be achieved by cutting the output image into
>> pieces in any image processing software.
>
> Bingo!
>
> Thanks, Alain. Rendering with 360 deg spherical camera in one go and then
> projecting onto a sphere and cut to cubic images has yielded a seamless
> spherical image. The resolution of the first rendering should be at least twice
> to that of final image.
>
> http://www.gunda.hu/cube/povray/index3.html
>
> Tamas
>
>
Glad that it worked for you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 19-04-10 à 14:34, Tamas Gunda a écrit :
> clipka <ano### [at] anonymousorg> wrote:
>> Am 08.04.2019 um 19:06 schrieb Alain:
>>
>>> Just an idea :
>>> Try rendering it all in one go, then, project onto a box or sphere :
>>
>> That's actually a pretty smart idea.
>> It's important though to use a high enough resolution, or at least use
>> interpolation for the projected image.
>>
>> Alternatively, the image could be rendered directly to a single cube map
>> image using a v3.8.0-alpha user-defined camera (or a v3.7.0 mesh camera,
>> but that's more of a hassle to set up). If 6 separate images are needed,
>> that could then simply be achieved by cutting the output image into
>> pieces in any image processing software.
>
> Bingo!
>
> Thanks, Alain. Rendering with 360 deg spherical camera in one go and then
> projecting onto a sphere and cut to cubic images has yielded a seamless
> spherical image. The resolution of the first rendering should be at least twice
> to that of final image.
>
> http://www.gunda.hu/cube/povray/index3.html
>
> Tamas
>
>
If the individual images are, say, 1000 pixels whide, the spherical
render need to be 4000 pixels whide and 2000 pixels high.
Looking at the darker parts, I think that you may need to increase
recursion_limit by 1 or 2.
Also, it could be good to increase the count value as well as the pool
size (the second parameter of count).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|