I was working on a gem cuts module for the Object Collection when 
Hurricane Irma struck.  The module was essentially finished, but 
required testing and documentation.

Alas, I have made very little progress in the past 3 months, and while I 
am in Florida, I prioritized other things.  Like finishing an online 
backup (also interrupted by Irma) and catching up on YouTube.  Rather 
than upload a partially tested module with incomplete documentation, or 
trying to rush everything to completion in the short time I have (a sure 
recipe for a broken module), I'll just leave this sneak preview.

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.

Post a reply to this message

Attachments:
Download 'gemcuts.jpg' (99 KB)

Preview of image 'gemcuts.jpg'

Cousin Ricky <ric### [at] yahoocom> wrote:
> I was working on a gem cuts module for the Object Collection when
> Hurricane Irma struck.  The module was essentially finished, but
> required testing and documentation.
>
> Alas, I have made very little progress in the past 3 months, and while I
> am in Florida, I prioritized other things.  Like finishing an online
> backup (also interrupted by Irma) and catching up on YouTube.  Rather
> than upload a partially tested module with incomplete documentation, or
> trying to rush everything to completion in the short time I have (a sure
> recipe for a broken module), I'll just leave this sneak preview.
>
> 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.

Courage for the hacking... If you do manage to commit (to GIT?) from an android
phone, I would be interested to know how.

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.

Post a reply to this message

Le 17-12-13 à 03:52, Mr a écrit :
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> I was working on a gem cuts module for the Object Collection when
>> Hurricane Irma struck.  The module was essentially finished, but
>> required testing and documentation.
>>
>> Alas, I have made very little progress in the past 3 months, and while I
>> am in Florida, I prioritized other things.  Like finishing an online
>> backup (also interrupted by Irma) and catching up on YouTube.  Rather
>> than upload a partially tested module with incomplete documentation, or
>> trying to rush everything to completion in the short time I have (a sure
>> recipe for a broken module), I'll just leave this sneak preview.
>>
>> 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.
> 
> Courage for the hacking... If you do manage to commit (to GIT?) from an android
> phone, I would be interested to know how.
> 
> 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.
> 

Maybe using textures from metals.inc. Those have insane ambient values. 
Should change them to ambient 0.

Post a reply to this message

Once again, using someone else's computer; I hope this goes through.

"Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> Courage for the hacking... If you do manage to commit (to GIT?) from an android
> phone, I would be interested to know how.

If I commit, it will be through the Object Collection uploader. I'll let Le
Forgeron worry about GitHub.

> The image is promissing, but too bright:
> is gamma correct?
> are albedo and conserve_energy used?
> are specular / mirror intensity values realistic ones?

My gamma is always 1.0, and I always use conserve_energy.

I did not albedo, because I want the example to run in pre-3.7 scenes. Both
gemstones use an entirely transparent pigment, so the diffuse value is
irrelevant. For the specular value, I precalculated a base value using the
albedo formula in parstxtr.cpp, and then reduced it according to a formula I
developed to /estimate/ the Fresnel effect.

> with darker lighting and a more punctual one, caustics will contrast more.

I will consider lowering the lighting and using a darker wood for the table. I
don’t know what you mean by "punctual." (Nothing is punctual in ray tracing.)

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
> Le 17-12-13 à 03:52, Mr a écrit :
> > 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.
>
> Maybe using textures from metals.inc. Those have insane ambient values.
> Should change them to ambient 0.

Alain, you know me better than that!

I used very low ambient and diffuse values.  I didn't use zero, because I'm not
using blurred reflection.  (My focus for this module is the modeling, not the
textures.)

Post a reply to this message

Le 17-12-21 à 11:36, Cousin Ricky a écrit :
> Alain <kua### [at] videotronca> wrote:
>> Le 17-12-13 à 03:52, Mr a écrit :
>>> 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.
>>
>> Maybe using textures from metals.inc. Those have insane ambient values.
>> Should change them to ambient 0.
> 
> Alain, you know me better than that!
> 
> I used very low ambient and diffuse values.  I didn't use zero, because I'm not
> using blurred reflection.  (My focus for this module is the modeling, not the
> textures.)
> 
> 
Even without blured reflection, using ambient >0 for metals is not 
realistic.

Post a reply to this message

Le 17-12-21 à 11:30, Cousin Ricky a écrit :
> Once again, using someone else's computer; I hope this goes through.
> 
> "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
>> Courage for the hacking... If you do manage to commit (to GIT?) from an android
>> phone, I would be interested to know how.
> 
> If I commit, it will be through the Object Collection uploader. I'll let Le
> Forgeron worry about GitHub.
> 
>> The image is promissing, but too bright:
>> is gamma correct?
>> are albedo and conserve_energy used?
>> are specular / mirror intensity values realistic ones?
> 
> My gamma is always 1.0, and I always use conserve_energy.
> 
> I did not albedo, because I want the example to run in pre-3.7 scenes. Both
> gemstones use an entirely transparent pigment, so the diffuse value is
> irrelevant. For the specular value, I precalculated a base value using the
> albedo formula in parstxtr.cpp, and then reduced it according to a formula I
> developed to /estimate/ the Fresnel effect.
> 
>> with darker lighting and a more punctual one, caustics will contrast more.
> 
> I will consider lowering the lighting and using a darker wood for the table. I
> don’t know what you mean by "punctual." (Nothing is punctual in ray tracing.)
> 
> 

I think he mean smaller area_light, using a point light, or not adding 
photons{area_light} to an area_light.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
> Le 17-12-21 à 11:36, Cousin Ricky a écrit :
> > Alain <kua### [at] videotronca> wrote:
> >> Le 17-12-13 à 03:52, Mr a écrit :
> >>> 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.
> >>
> >> Maybe using textures from metals.inc. Those have insane ambient values.
> >> Should change them to ambient 0.
> >
> > Alain, you know me better than that!
> >
> > I used very low ambient and diffuse values.  I didn't use zero, because I'm not
> > using blurred reflection.  (My focus for this module is the modeling, not the
> > textures.)
> >
> >
> Even without blured reflection, using ambient >0 for metals is not
> realistic.

You know, it's rather frustrating when you notice you made a mistake, but can't
respond for another 6 days.  I used radiosity in that scene; there is no
ambient, period!

I did put a diffuse of 0.035 on the metals.  I did a render last night with zero
diffuse, and there is hardly a difference in appearance.

Post a reply to this message

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

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

Alain <kua### [at] videotronca> wrote:
> Le 17-12-21 à 11:30, Cousin Ricky a écrit :
> > "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> >> with darker lighting and a more punctual one, caustics will contrast more.
> >
> > I will consider lowering the lighting and using a darker wood for the table. I
> > don’t know what you mean by "punctual." (Nothing is punctual in ray tracing.)
>
> I think he mean smaller area_light, using a point light, or not adding
> photons{area_light} to an area_light.

I used no area lights in that render.

Post a reply to this message

"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.

I played with the lighting and the environment.  Since I can't use my newsreader
right now, I will have to upload the images one at a time.

This one has dimmed lighting.

Post a reply to this message

Attachments:
Download 'gemcuts-cam0-dimlight.jpg' (42 KB)

Preview of image 'gemcuts-cam0-dimlight.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.

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'

Le 17-12-27 à 11:47, Cousin Ricky a écrit :
> "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

Le 18-01-03 à 12:40, Cousin Ricky a écrit :
> 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:
> Le 18-01-03 à 12:40, Cousin Ricky a écrit :
> > 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
than 6 minutes on my quad 4 (12½ minutes for 3.6 users, but they deserve it ;-),
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
7.  This cuts the photons down to less than 3½ minutes, and the projected trace
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

Le 18-01-04 à 11:52, Cousin Ricky a écrit :

> 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