 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Alain <kua### [at] videotron ca> wrote:
> > Thomas de Groot <tho### [at] degroot org> wrote:
> >> On 12-4-2013 15:03, s.day wrote:
> >>> Would be nice to see a radiosity version of this image as well (I assume the
> >>> lighting is ambient currently?)
> >>
> >> Strange you say this. This *is* a radiosity version ;-)
> >>
> >> Currently:
> >>
> >> radiosity {
> >> pretrace_start 0.08
> >> pretrace_end 0.004
> >> count 50, 500
> >> nearest_count 10, 5
> >> error_bound 0.6
> >> recursion_limit 2
> >> low_error_factor .3
> >> gray_threshold 0.0
> >> minimum_reuse 0.010
> >> maximum_reuse 0.1
> >> brightness 1
> >> adc_bailout 0.01/2
> >> normal off
> >> media off
> >> always_sample off
> >> }
> >>
> >> Thomas
> >
> > Oops.. sorry, I guess looking at the inside of the windows it shows radiosity
> > effects, I think the shadows of the buildings on the road and to a certain
> > extent the shadows on the walls in many areas look too consistent, I would
> > expect them to darken a bit as they get into corners etc..
> >
> > I assume you have ambient_light set to zero in the scene? (looking at the
> > darkness inside the windows would point to this being set I guess).
> >
> > Will look more closely before I comment again ;-)
> >
> > Sean
> >
> >
>
> Rendered with version 3.7, so, ambient get automativaly turned OFF as
> soon as radiosity is activated.
> You can tell it use version 3.7 when you see double values after count
> and nearest_count, as well as the presance of maximum_reuse.
>
>
> Alain
If you have heard the saying ignorance is bliss, then I must be very happy ;-)
I have not tried the new double values on 3.7 do they make much difference to
performance? (always looking for ways to speed up a render).
Sean
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 14-4-2013 20:10, s.day wrote:
> Alain <kua### [at] videotron ca> wrote:
>> Rendered with version 3.7, so, ambient get automativaly turned OFF as
>> soon as radiosity is activated.
>> You can tell it use version 3.7 when you see double values after count
>> and nearest_count, as well as the presance of maximum_reuse.
>>
>>
>> Alain
>
> If you have heard the saying ignorance is bliss, then I must be very happy ;-)
<grin> Keep it that way. ;-)
>
> I have not tried the new double values on 3.7 do they make much difference to
> performance? (always looking for ways to speed up a render).
I have not experimented much I confess, and am not sure I entirely
understand their use, so I am not sure.
Thomas
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
>Thomas de Groot on date 12/04/2013 9.46 wrote:
> One step further. Some code clean-up and improvements, and, as shown, an
> added random texturing of the buildings.
>
> This version of the macros is gradually diverging from the one in
> p.b.s-f. I shall see how I can include the new features in the 'public'
> version ;-)
>
> Thomas
Even and even better.
Perhaps the walls on the ground floor of the homes with the "towers"
need to be reinforced in order to sustain the weight of the construction
(I think that at the time in Gancaloon were used stones or mud and wood
for constructions).
;-)
Paolo
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
> Alain <kua### [at] videotron ca> wrote:
>>> Thomas de Groot <tho### [at] degroot org> wrote:
>>>> On 12-4-2013 15:03, s.day wrote:
>>>>> Would be nice to see a radiosity version of this image as well (I assume the
>>>>> lighting is ambient currently?)
>>>>
>>>> Strange you say this. This *is* a radiosity version ;-)
>>>>
>>>> Currently:
>>>>
>>>> radiosity {
>>>> pretrace_start 0.08
>>>> pretrace_end 0.004
>>>> count 50, 500
>>>> nearest_count 10, 5
>>>> error_bound 0.6
>>>> recursion_limit 2
>>>> low_error_factor .3
>>>> gray_threshold 0.0
>>>> minimum_reuse 0.010
>>>> maximum_reuse 0.1
>>>> brightness 1
>>>> adc_bailout 0.01/2
>>>> normal off
>>>> media off
>>>> always_sample off
>>>> }
>>>>
>>>> Thomas
>>>
>>> Oops.. sorry, I guess looking at the inside of the windows it shows radiosity
>>> effects, I think the shadows of the buildings on the road and to a certain
>>> extent the shadows on the walls in many areas look too consistent, I would
>>> expect them to darken a bit as they get into corners etc..
>>>
>>> I assume you have ambient_light set to zero in the scene? (looking at the
>>> darkness inside the windows would point to this being set I guess).
>>>
>>> Will look more closely before I comment again ;-)
>>>
>>> Sean
>>>
>>>
>>
>> Rendered with version 3.7, so, ambient get automativaly turned OFF as
>> soon as radiosity is activated.
>> You can tell it use version 3.7 when you see double values after count
>> and nearest_count, as well as the presance of maximum_reuse.
>>
>>
>> Alain
>
> If you have heard the saying ignorance is bliss, then I must be very happy ;-)
>
> I have not tried the new double values on 3.7 do they make much difference to
> performance? (always looking for ways to speed up a render).
>
> Sean
>
>
>
The second value for count set a larger direction pool for the radiosity
sampling. It should not have any important effect on the speed, but can
affect the quality. In some cases, it allow you to use a smaller count
value, making the render faster. If used, it MUST be larger than the
first value. Those who use it seems to tend to use a value at least 10
times larger than the first one.
The double nearest_count can affect the quality and the speed. The first
value set the maximum bound to be used in areas where the samples have
more variation. The second value is the minimal value to be used in
areas where everything is prety uniform, like a large, plain wall.
maximim_reuse set the largest distance any sample can be reused. It's
grosly a ratio of the width ov the scene.
If you use a smaller pretrace_end value, you often can do with more
relaxed settings elsewhere. The default of 0.04 is often much to large,
I usualy use 0.01 or 0.005. low_error_factor also play a large role in
reducing the sampling done during the final trace and a small value can
greatly reduce artefacts on multi-core systems. Keep it at or under the
default value of 0.5.
Alain
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Alain <kua### [at] videotron ca> wrote:
> > Alain <kua### [at] videotron ca> wrote:
> >>> Thomas de Groot <tho### [at] degroot org> wrote:
> >>>> On 12-4-2013 15:03, s.day wrote:
> >>>>> Would be nice to see a radiosity version of this image as well (I assume the
> >>>>> lighting is ambient currently?)
> >>>>
> >>>> Strange you say this. This *is* a radiosity version ;-)
> >>>>
> >>>> Currently:
> >>>>
> >>>> radiosity {
> >>>> pretrace_start 0.08
> >>>> pretrace_end 0.004
> >>>> count 50, 500
> >>>> nearest_count 10, 5
> >>>> error_bound 0.6
> >>>> recursion_limit 2
> >>>> low_error_factor .3
> >>>> gray_threshold 0.0
> >>>> minimum_reuse 0.010
> >>>> maximum_reuse 0.1
> >>>> brightness 1
> >>>> adc_bailout 0.01/2
> >>>> normal off
> >>>> media off
> >>>> always_sample off
> >>>> }
> >>>>
> >>>> Thomas
> >>>
> >>> Oops.. sorry, I guess looking at the inside of the windows it shows radiosity
> >>> effects, I think the shadows of the buildings on the road and to a certain
> >>> extent the shadows on the walls in many areas look too consistent, I would
> >>> expect them to darken a bit as they get into corners etc..
> >>>
> >>> I assume you have ambient_light set to zero in the scene? (looking at the
> >>> darkness inside the windows would point to this being set I guess).
> >>>
> >>> Will look more closely before I comment again ;-)
> >>>
> >>> Sean
> >>>
> >>>
> >>
> >> Rendered with version 3.7, so, ambient get automativaly turned OFF as
> >> soon as radiosity is activated.
> >> You can tell it use version 3.7 when you see double values after count
> >> and nearest_count, as well as the presance of maximum_reuse.
> >>
> >>
> >> Alain
> >
> > If you have heard the saying ignorance is bliss, then I must be very happy ;-)
> >
> > I have not tried the new double values on 3.7 do they make much difference to
> > performance? (always looking for ways to speed up a render).
> >
> > Sean
> >
> >
> >
>
> The second value for count set a larger direction pool for the radiosity
> sampling. It should not have any important effect on the speed, but can
> affect the quality. In some cases, it allow you to use a smaller count
> value, making the render faster. If used, it MUST be larger than the
> first value. Those who use it seems to tend to use a value at least 10
> times larger than the first one.
>
> The double nearest_count can affect the quality and the speed. The first
> value set the maximum bound to be used in areas where the samples have
> more variation. The second value is the minimal value to be used in
> areas where everything is prety uniform, like a large, plain wall.
>
> maximim_reuse set the largest distance any sample can be reused. It's
> grosly a ratio of the width ov the scene.
>
> If you use a smaller pretrace_end value, you often can do with more
> relaxed settings elsewhere. The default of 0.04 is often much to large,
> I usualy use 0.01 or 0.005. low_error_factor also play a large role in
> reducing the sampling done during the final trace and a small value can
> greatly reduce artefacts on multi-core systems. Keep it at or under the
> default value of 0.5.
>
>
> Alain
Wow, thanks Alain, you have just supercharged the radiosity gathering stage of
my renders. I need to do a comparisson for quality, I usually run a no focal
blur/AA render to gather the radiosity data then reload this data with pretrace
set to 1. The radiosity render was running at about 5 hours and with these
settings is now taking about 7 minutes!
Will run the final high quality trace now to see if it looks as good as my 5
hour trace. Oh the hours I have wasted ;-)
Sean
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 15-4-2013 16:27, Paolo Gibellini wrote:
> >Thomas de Groot on date 12/04/2013 9.46 wrote:
>> One step further. Some code clean-up and improvements, and, as shown, an
>> added random texturing of the buildings.
>>
>> This version of the macros is gradually diverging from the one in
>> p.b.s-f. I shall see how I can include the new features in the 'public'
>> version ;-)
>>
>> Thomas
> Even and even better.
Thank you, Paolo :-)
> Perhaps the walls on the ground floor of the homes with the "towers"
> need to be reinforced in order to sustain the weight of the construction
> (I think that at the time in Gancaloon were used stones or mud and wood
> for constructions).
That's an idea, and easy to implement.
Thomas
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Thomas de Groot <tho### [at] degroot org> wrote:
> One step further. Some code clean-up and improvements, and, as shown, an
> added random texturing of the buildings.
>
> This version of the macros is gradually diverging from the one in
> p.b.s-f. I shall see how I can include the new features in the 'public'
> version ;-)
>
> Thomas
I like the textures, except that the stones in the street look too clean and
evenly worn for it to be an "Old" city.
The things that jar my sensibilities are the 2-1/2 foot drop from the bottom
step of the second house on the right, the perfectly clean lines of the
buildings and the grade of the street from one side to the other.
Just a suggestion, but you might consider making the street more level, if you
can. I understand that it's all one height field, but maybe you can find some
way to deform it - say you were to take a spline of the street and flatten the
pixels within a certain distance on either side, not necessarily perfectly
level, but more level than it is.
I don't know how your macro would handle the adjustment to the terrain.
I really love the concept.
Regards,
A.D.B.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 16-4-2013 19:52, Anthony D. Baye wrote:
> I like the textures, except that the stones in the street look too clean and
> evenly worn for it to be an "Old" city.
Of course. Be aware that this is all in some kind of beta state. The end
product will show a very different street surface texture.
>
> The things that jar my sensibilities are the 2-1/2 foot drop from the bottom
> step of the second house on the right, the perfectly clean lines of the
> buildings and the grade of the street from one side to the other.
<grin> Most of this has been solved at this moment, except for the clean
lines of the buildings. Some degrading has still to be done on them.
>
> Just a suggestion, but you might consider making the street more level, if you
> can. I understand that it's all one height field, but maybe you can find some
> way to deform it - say you were to take a spline of the street and flatten the
> pixels within a certain distance on either side, not necessarily perfectly
> level, but more level than it is.
This has been solved. For the close-up views a separate street surface
is generated, following the height_field but level cross-streetwise.
This is not an automatic process but modelled separately. Not so
difficult to do as I use a high-resolution mesh copy of the local
height_field for modelling purposes.
> I don't know how your macro would handle the adjustment to the terrain.
Simply by making a union of the street surface object and the
height_field before trace()
A new street view is being rendered.
>
> I really love the concept.
Thank you indeed. I have not finished exploring the possibilities.
Thomas
Post a reply to this message
|
 |
|  |
|  |
|
 |
From: Thomas de Groot
Subject: Re: Gancaloon: Old City street new version 2
Date: 17 Apr 2013 03:26:43
Message: <516e4eb3@news.povray.org>
|
|
 |
|  |
|  |
|
 |
The same street after some improvements.
- a level street surface object is added.
- code influencing the buildings along the street boundaries has been
fine-tuned.
- doors, shutters, and bars have been added (not all visible here though).
Thomas
Post a reply to this message
Attachments:
Download 'gancaloon_old city street_07.jpg' (133 KB)
Preview of image 'gancaloon_old city street_07.jpg'

|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"s.day" <s.d### [at] uel ac uk> wrote:
>
> Wow, thanks Alain, you have just supercharged the radiosity gathering stage of
> my renders. I need to do a comparisson for quality, I usually run a no focal
> blur/AA render to gather the radiosity data then reload this data with pretrace
> set to 1. The radiosity render was running at about 5 hours and with these
> settings is now taking about 7 minutes!
>
> Will run the final high quality trace now to see if it looks as good as my 5
> hour trace. Oh the hours I have wasted ;-)
>
> Sean
Ahh.. thought that was too good to be true, the quality was not so good, still
with a few tweaks I now have almost identical quality with a 2 hour radiosity
gathering stage so still a big improvement.
Thanks
Sean
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|
 |