 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Operating on the theory that my csg was slowing down the render, I decided to
rebuild the scene from the void up using constructive csg as much as possible.
What follows is the current state of the scene, built almost entirely out of
prisms. The code is quite a bit less readable, but there are no difference(s)
at all.
The major speedup came when I changed the way I tiled the floors. Rather than
making a single large union of all the tiles on a particular level, I altered my
macro to pass back an array of tiles which I then use to tile a given area. I
cull tiles which fall inside areas I want kept clear using an inside(...)
statement. Render speed increased to "OH MY GOD THAT'S FAST".
Render Time:
Photon Time: No photons
Radiosity Time: 0 hours 0 minutes 17 seconds (17.107 seconds)
using 6 thread(s) with 95.544 CPU-seconds total
Trace Time: 0 hours 4 minutes 26 seconds (266.060 seconds)
using 6 thread(s) with 1535.187 CPU-seconds total
The upshot seems to be a problem in bounding of difference objects where the
base is composed of many small objects, much like you might expect from turning
off split_unions.
Regards,
A.D.B.
Post a reply to this message
Attachments:
Download 'rebuild.png' (565 KB)
Preview of image 'rebuild.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Operating on the theory that my csg was slowing down the render, I decided to
> rebuild the scene from the void up using constructive csg as much as possible.
>
> What follows is the current state of the scene, built almost entirely out of
> prisms. The code is quite a bit less readable, but there are no difference(s)
> at all.
>
> The major speedup came when I changed the way I tiled the floors. Rather than
> making a single large union of all the tiles on a particular level, I altered my
> macro to pass back an array of tiles which I then use to tile a given area. I
> cull tiles which fall inside areas I want kept clear using an inside(...)
> statement. Render speed increased to "OH MY GOD THAT'S FAST".
>
> Render Time:
> Photon Time: No photons
> Radiosity Time: 0 hours 0 minutes 17 seconds (17.107 seconds)
> using 6 thread(s) with 95.544 CPU-seconds total
> Trace Time: 0 hours 4 minutes 26 seconds (266.060 seconds)
> using 6 thread(s) with 1535.187 CPU-seconds total
>
> The upshot seems to be a problem in bounding of difference objects where the
> base is composed of many small objects, much like you might expect from turning
> off split_unions.
>
> Regards,
> A.D.B.
>
Yes, modeling a scene differently can have a *huge* impact on the render
time :)
Another thing that can be done:
When your tiles, or any kind of objects, are hiden under some other
opaque object and you see them in some hole in that object, you don't
need to use a difference nor intersection to cut them away. Makes the
scene simpler.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And everything but the water...
Render Time:
Photon Time: No photons
Radiosity Time: 0 hours 27 minutes 9 seconds (1629.585 seconds)
using 48 thread(s) with 9335.010 CPU-seconds total
Trace Time: 3 hours 2 minutes 41 seconds (10961.487 seconds)
using 48 thread(s) with 63746.286 CPU-seconds total
Regards,
A.D.B.
Post a reply to this message
Attachments:
Download 'rebuild.png' (836 KB)
Preview of image 'rebuild.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anthony D. Baye wrote on 14/09/2015 15.19:
> And everything but the water...
>
>
> Regards,
> A.D.B.
>
A nice scene and a nice mood!
Paolo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Paolo Gibellini <p.g### [at] gmail com> wrote:
> Anthony D. Baye wrote on 14/09/2015 15.19:
> > And everything but the water...
> >
>
> >
> > Regards,
> > A.D.B.
> >
> A nice scene and a nice mood!
> Paolo
Thank you.
And here's with the water. Such as it is.
I felt that the light was a little too bright so I cut the fade distance in
half. Might take it down even further.
Render Time:
Photon Time: No photons
Radiosity Time: 0 hours 27 minutes 27 seconds (1647.759 seconds)
using 48 thread(s) with 9805.663 CPU-seconds total
Trace Time: 2 hours 29 minutes 33 seconds (8973.296 seconds)
using 48 thread(s) with 53585.490 CPU-seconds total
Regards,
A.D.B.
Post a reply to this message
Attachments:
Download 'rebuild.png' (701 KB)
Preview of image 'rebuild.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 16.09.2015 um 23:44 schrieb Anthony D. Baye:
> I felt that the light was a little too bright so I cut the fade distance in
> half. Might take it down even further.
Hint: If striving for realism, avoid random tweaking of fade_distance;
if you feel that the light is too dim or too bright, always directly
tweak the light source's brightness instead - even if that means using
apparently insane brightness values to achieve the desired result.
Unless using an area_light with area_illumination on, fade_distance
should typically be roughly equal to the hypothetical radius of whatever
light source you are trying to simulate. So for instance, to simulate a
classic frosted E27 incandescent light bulb, and presuming you're using
a scale of 1m per POV-Ray unit for your scene, a fade_distance of 0.03
would be about the right value.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Unless using an area_light with area_illumination on, fade_distance
> should typically be roughly equal to the hypothetical radius of whatever
> light source you are trying to simulate. So for instance, to simulate a
> classic frosted E27 incandescent light bulb, and presuming you're using
> a scale of 1m per POV-Ray unit for your scene, a fade_distance of 0.03
> would be about the right value.
I wonder what part of the bulb determines this fade_distance: the frosted part,
the diameter of the socket (E27) or the incandescent part? I suppose the power
consumption given in Watt (Germany) with this kind of bulbs in former years and
now replaced by lumen with energy saving lamps usually influence the general
brightness only and not the fade_distance. The "incandescent" should influence
the color of the light source, so only the "frosted" remains. 3 cm is the
approximated radius of this bulbs and as they are frosted the point where their
full light intensity should arise. Is this the reason for this fade_distance?
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.09.2015 um 20:57 schrieb MichaelJF:
> clipka <ano### [at] anonymousorg> wrote:
>
>> Unless using an area_light with area_illumination on, fade_distance
>> should typically be roughly equal to the hypothetical radius of whatever
>> light source you are trying to simulate. So for instance, to simulate a
>> classic frosted E27 incandescent light bulb, and presuming you're using
>> a scale of 1m per POV-Ray unit for your scene, a fade_distance of 0.03
>> would be about the right value.
>
>
>
> I wonder what part of the bulb determines this fade_distance: the frosted part,
> the diameter of the socket (E27) or the incandescent part? I suppose the power
> consumption given in Watt (Germany) with this kind of bulbs in former years and
> now replaced by lumen with energy saving lamps usually influence the general
> brightness only and not the fade_distance. The "incandescent" should influence
> the color of the light source, so only the "frosted" remains. 3 cm is the
> approximated radius of this bulbs and as they are frosted the point where their
> full light intensity should arise. Is this the reason for this fade_distance?
Exactly. As you get closer to the surface of the light bulb, the light
source gets more and more non-point-like, and the inverse square law
they teach us at school breaks down.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Am 18.09.2015 um 20:57 schrieb MichaelJF:
>> clipka <ano### [at] anonymousorg> wrote:
>>
>>> Unless using an area_light with area_illumination on, fade_distance
>>> should typically be roughly equal to the hypothetical radius of whatever
>>> light source you are trying to simulate. So for instance, to simulate a
>>> classic frosted E27 incandescent light bulb, and presuming you're using
>>> a scale of 1m per POV-Ray unit for your scene, a fade_distance of 0.03
>>> would be about the right value.
>>
>>
>>
>> I wonder what part of the bulb determines this fade_distance: the frosted part,
>> the diameter of the socket (E27) or the incandescent part? I suppose the power
>> consumption given in Watt (Germany) with this kind of bulbs in former years and
>> now replaced by lumen with energy saving lamps usually influence the general
>> brightness only and not the fade_distance. The "incandescent" should influence
>> the color of the light source, so only the "frosted" remains. 3 cm is the
>> approximated radius of this bulbs and as they are frosted the point where their
>> full light intensity should arise. Is this the reason for this fade_distance?
>
> Exactly. As you get closer to the surface of the light bulb, the light
> source gets more and more non-point-like, and the inverse square law
> they teach us at school breaks down.
>
For an infinitely long linear light source, the illumination is
effectively intencity/distance. When you get closer from a long light
source, when the distance becomes small to very small relative to the
lenght, you have a similar effect.
For an infinite plane, the illumination becomes independent from the
distance. Here, also, when a planar light source is viewed from a small
distance relative to it's extent, it can be approximated as an infinite
plane.
I remember that I had to perform the demonstration for both cases using
some intergral manipulations back in colege.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18-9-2015 17:07, clipka wrote:
> Unless using an area_light with area_illumination on, fade_distance
> should typically be roughly equal to the hypothetical radius of whatever
> light source you are trying to simulate. So for instance, to simulate a
> classic frosted E27 incandescent light bulb, and presuming you're using
> a scale of 1m per POV-Ray unit for your scene, a fade_distance of 0.03
> would be about the right value.
>
Could you elaborate a bit on (the use of) /area_illumination/ please? I
have tried to look up info in the docs but there is nothing
comprehensive there (or is there?). Thanks!
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
