"Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
>
> The image is promissing, but too bright:
> is gamma correct?
> are albedo and conserve_energy used?
> are specular / mirror intensity values realistic ones?
> with darker lighting and a more punctual one, caustics will contrast more.

This image has darker walls and a darker ceiling.

Post a reply to this message

Attachments:
Download 'gemcuts-cam0-darkwalls.jpg' (48 KB)

Preview of image 'gemcuts-cam0-darkwalls.jpg'

"Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
>
> The image is promissing, but too bright:
> is gamma correct?
> are albedo and conserve_energy used?
> are specular / mirror intensity values realistic ones?
> with darker lighting and a more punctual one, caustics will contrast more.

This image has a darker table, while the lighting and room color are as in the
original.  The wood textures on all these demos are stock textures from
woods.inc; I will not roll my own for this demo.

Post a reply to this message

Attachments:
Download 'gemcuts-cam0-redtable.jpg' (72 KB)

Preview of image 'gemcuts-cam0-redtable.jpg'

"Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
>
> The image is promissing, but too bright:
> is gamma correct?
> are albedo and conserve_energy used?
> are specular / mirror intensity values realistic ones?
> with darker lighting and a more punctual one, caustics will contrast more.

The reddish wood texture is so busy it competes with the dispersed refracted
caustics, so I tried a simpler dark wood.  Again, the lighting and room color
are as in the original.

Post a reply to this message

Attachments:
Download 'gemcuts-cam0-browntable.jpg' (49 KB)

Preview of image 'gemcuts-cam0-browntable.jpg'

> "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
>>
>> The image is promissing, but too bright:
>> is gamma correct?
>> are albedo and conserve_energy used?
>> are specular / mirror intensity values realistic ones?
>> with darker lighting and a more punctual one, caustics will contrast more.
> 
> This image has darker walls and a darker ceiling.
> 

The best one for me :)

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> It occurred to me there may be a non-zero probability of being able to
> upload the module via my phone.  I'll try that later; however, even if I
> succeed, I won't be able to post a notice to the newsgroups until I get
> home Internet back.

Somehow, I am able to post via the Web interface (from someone else's computer),
whereas I couldn't do it before the hurricanes.

But I've run into a new snag: when I add soft shadows and depth of field, the
scene takes forever to render.  Based on the render time of the thumbnail, I
estimate that a full-sized render would take 46 hours on my system.  But I would
really like, at least, depth of field with the small scale of the subject
matter.

Ordinarily, a 46 hour render would take a mere 46 hours, or a bit longer if I
'nice' the render so the computer is usable for other tasks during that period.
But while my power source is a part time generator, I would have to attend the
computer during the entire render, and bring the system in and out of
hibernation as the generator is powered down and up, and as I leave the house
and return.  That would extend the *elapsed* time to a nerve-wracking 2 or 3
weeks--if the hibernation process doesn't fail, which it does frequently.  So
this release will have to wait until I'm plugged into the grid.

Unfortunately, no one seems to know when that will be.  I'm getting conflicting
information from various sources that changes at least daily.  I'm even told
that I might well have already had electricity if it weren't for a ne'er-do-well
neighbor who appears to be a copper thief.  In fact he was caught, in
retrospect, in the act of cutting the very electrical line to my house, although
witnesses appear not to have known what he was up to.

It takes a very special kind of selfishness to screw your neighbors in the
aftermath of a disaster.  This almost makes me wish that the utility had
energized the line while he was in the act of cutting it, but that wouldn't be
very nice, would it?

In the meantime, I'm exploring reducing max_trace_level and dispersion_samples.
The latter looks promising; the former does not.

Post a reply to this message

> Cousin Ricky <ric### [at] yahoocom> wrote:
>> It occurred to me there may be a non-zero probability of being able to
>> upload the module via my phone.  I'll try that later; however, even if I
>> succeed, I won't be able to post a notice to the newsgroups until I get
>> home Internet back.
> 
> Somehow, I am able to post via the Web interface (from someone else's computer),
> whereas I couldn't do it before the hurricanes.
> 
> But I've run into a new snag: when I add soft shadows and depth of field, the
> scene takes forever to render.  Based on the render time of the thumbnail, I
> estimate that a full-sized render would take 46 hours on my system.  But I would
> really like, at least, depth of field with the small scale of the subject
> matter.

Can't help for the depth of field, but, for the soft shadows, I can.
You really need to use the adaptive option with as small a value as you 
can get away with. If you can use adaptive 0 without causing artefacts, 
do it. Hint : ALWAYS start with adaptive 0 for your area_light. Only use 
a larger value if you get artefacts such as illuminated spots into 
shadow or dark spots into illuminated areas.
Even better, if you can somehow hide those, do it.
Adaptive let you use very dense arrays for your area_light at a very 
small render time cost.
area_light x,y, 257, 257 adaptive 0
is almost as fast as
area_light x,y 4 4 jitter
for a much smoother result.

> 
> Ordinarily, a 46 hour render would take a mere 46 hours, or a bit longer if I
> 'nice' the render so the computer is usable for other tasks during that period.
> But while my power source is a part time generator, I would have to attend the
> computer during the entire render, and bring the system in and out of
> hibernation as the generator is powered down and up, and as I leave the house
> and return.  That would extend the *elapsed* time to a nerve-wracking 2 or 3
> weeks--if the hibernation process doesn't fail, which it does frequently.  So
> this release will have to wait until I'm plugged into the grid.

Use the +c option to continue an interrupted render.
If you use photons, be sure to save them to a file that you can reload 
when resuming your render.
Add:
    #if(file_exists ("myphotons.phot"))
    load_file "myphotons.phot"
    #else
    save_file "myphotons.phot"
    #end
in your photons block.
This allow you to bypass the photons shooting phase.

You can do the same for radiosity data, but you need to use some command 
line options.

> 
> In the meantime, I'm exploring reducing max_trace_level and dispersion_samples.
> The latter looks promising; the former does not.
> 
> 

You may also increase adc_bailout to something around 0.01 or maybe 
slightly more. Just don't overdo it.

Post a reply to this message

On 03/01/2018 17:40, Cousin Ricky wrote:
> So
> this release will have to wait until I'm plugged into the grid.
> 
> Unfortunately, no one seems to know when that will be.  I'm getting conflicting
> information from various sources that changes at least daily. 

How frustrating.

> I'm even told
> that I might well have already had electricity if it weren't for a ne'er-do-well
> neighbor who appears to be a copper thief.  In fact he was caught, in
> retrospect, in the act of cutting the very electrical line to my house, although
> witnesses appear not to have known what he was up to.
> 

Ah! memories of my childhood. Not that it was me that was doing the 
thieving. But I knew a few folk who got caught stealing lead off of 
church roofs. And it was only the big boys that tried to steal the 
copper busbars from unmanned distribution centres.



> It takes a very special kind of selfishness to screw your neighbors in the
> aftermath of a disaster.  This almost makes me wish that the utility had
> energized the line while he was in the act of cutting it, but that wouldn't be
> very nice, would it?
> 

It's not and you would have felt bad if it had happened.
It is appropriate though, but best kept a secret thought. ;)



-- 

Regards
     Stephen

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

> > But I've run into a new snag: when I add soft shadows and depth of field, the
> > scene takes forever to render.  Based on the render time of the thumbnail, I
> > estimate that a full-sized render would take 46 hours on my system.  But I would
> > really like, at least, depth of field with the small scale of the subject
> > matter.
>
> Can't help for the depth of field, but, for the soft shadows, I can.
> You really need to use the adaptive option with as small a value as you
> can get away with. If you can use adaptive 0 without causing artefacts,
> do it. Hint : ALWAYS start with adaptive 0 for your area_light. Only use
> a larger value if you get artefacts such as illuminated spots into
> shadow or dark spots into illuminated areas.
> Even better, if you can somehow hide those, do it.
> Adaptive let you use very dense arrays for your area_light at a very
> small render time cost.
> area_light x,y, 257, 257 adaptive 0
> is almost as fast as
> area_light x,y 4 4 jitter
> for a much smoother result.

.... As you've already explained to me and others many times in the past.  I'm
using 5, 5 adaptive 0 jitter, which is plenty smooth for this scene.

> > Ordinarily, a 46 hour render would take a mere 46 hours, or a bit longer if I
> > 'nice' the render so the computer is usable for other tasks during that period.
> > But while my power source is a part time generator, I would have to attend the
> > computer during the entire render, and bring the system in and out of
> > hibernation as the generator is powered down and up, and as I leave the house
> > and return.  That would extend the *elapsed* time to a nerve-wracking 2 or 3
> > weeks--if the hibernation process doesn't fail, which it does frequently.  So
> > this release will have to wait until I'm plugged into the grid.
>
> Use the +c option to continue an interrupted render.
> If you use photons, be sure to save them to a file that you can reload
> when resuming your render.
> Add:
>     #if(file_exists ("myphotons.phot"))
>     load_file "myphotons.phot"
>     #else
>     save_file "myphotons.phot"
>     #end
> in your photons block.
> This allow you to bypass the photons shooting phase.
>
> You can do the same for radiosity data, but you need to use some command
> line options.

You misunderstand me.  I am refusing to put myself through such an ordeal.  I'm
going to wait until I can render it in one shot.

The demo file already has a radiosity save/load option (for 2-pass radiosity),
with .ini files included for the users' convenience, but the photons take less

not enough to bother saving, even if I were to restart an incomplete render
every day.

Does the -C option even work in 3.7?  I seem to recall problems with that even
after the 3.7.0 release, and I've avoided it like the plague ever since.  (On my
system, hibernation doesn't interrupt a render, although if the hibernation
process fails, I will be forced to shut down the computer, which obviously
*would* interrupt a render.)

> > In the meantime, I'm exploring reducing max_trace_level and dispersion_samples.
> > The latter looks promising; the former does not.
>
> You may also increase adc_bailout to something around 0.01 or maybe
> slightly more. Just don't overdo it.

I needed dispersion_samples 12 while I was testing the diamond, but with the
diamond as a smaller part of a complete scene, I can get away with the default

time to about 28 hours.

I haven't experimented with adc_bailout due to the rational for setting the
default value at 1/255.  I realized early on that with assumed_gamma 1.0
converted to a file gamma of 2.2 or sRGB, a value of 1/255 would exceed the
intervals between darker colors, so on that basis, even *that* value is too
large.  But rethinking this, it is better to consider visual effects rather than
byte values, so I will consider increasing adc_bailout.

Thanks for your input.

Post a reply to this message

> Does the -C option even work in 3.7?  I seem to recall problems with that even
> after the 3.7.0 release, and I've avoided it like the plague ever since.  (On my
> system, hibernation doesn't interrupt a render, although if the hibernation
> process fails, I will be forced to shut down the computer, which obviously
> *would* interrupt a render.)
> 

The +c option works flawlessly for me.

Post a reply to this message