Am 24.09.2012 16:02, schrieb Thomas de Groot:
> Done a new render with finish{} added to the gold.
>
Hm, I fail to notice any improvement :(

Having not used any of the standard texture include files myself since 
decades I took a quick look at golds.inc and assume you did replace the 
P_Gold statements by
#declare P_Gold1 = srgb CVect1;
...and so on, right?

Well, I have sworn to keep my mouth shut on this topic but I simply 
can't help it. As I have stated multiple times all "color math" works 
only as expected within a linear color space (and doing this kind of 
math myself very often is one of the reasons I advocate for 
assumed_gamma 1.0 since decades).
Now the author of golds.inc does apply a lot of mathematical operations 
on this declared color vectors afterwards - but when this vectors are 
already defined as non-linear srgb values all these operations are 
pretty pointless and the final textures will never look like expected.

And to get even a bit on topic ;) you might find the M_Gold macro with 
its sub-macro calls that are used for *Preview* rendering useful (and 
with a high reflective value like M_Gold(0.9) ) as they give under all 
lighting conditions fairly realistic results.

-Ive

Post a reply to this message

On 25-9-2012 20:08, Ive wrote:
> Hm, I fail to notice any improvement :(

Well, I did, some... :-)

>
> Having not used any of the standard texture include files myself since
> decades I took a quick look at golds.inc and assume you did replace the
> P_Gold statements by
> #declare P_Gold1 = srgb CVect1;
> ...and so on, right?

Yep.

>
> Well, I have sworn to keep my mouth shut on this topic but I simply
> can't help it. As I have stated multiple times all "color math" works
> only as expected within a linear color space (and doing this kind of
> math myself very often is one of the reasons I advocate for
> assumed_gamma 1.0 since decades).
> Now the author of golds.inc does apply a lot of mathematical operations
> on this declared color vectors afterwards - but when this vectors are
> already defined as non-linear srgb values all these operations are
> pretty pointless and the final textures will never look like expected.

In fact, I do not see any difference, but I see your point.

>
> And to get even a bit on topic ;) you might find the M_Gold macro with
> its sub-macro calls that are used for *Preview* rendering useful (and
> with a high reflective value like M_Gold(0.9) ) as they give under all
> lighting conditions fairly realistic results.

So... where is this M_Gold() located? I cannot find it  :-(


Thomas

Post a reply to this message

On 26-9-2012 9:52, Thomas de Groot wrote:
> So... where is this M_Gold() located? I cannot find it  :-(

OK. Found it. My brain is sluggish (it's Wednesday, don't ask me why).

Thomas

Post a reply to this message

On 25-9-2012 20:08, Ive wrote:
> And to get even a bit on topic ;) you might find the M_Gold macro with
> its sub-macro calls that are used for *Preview* rendering useful (and
> with a high reflective value like M_Gold(0.9) ) as they give under all
> lighting conditions fairly realistic results.

I patched in an updated gold nugget bowl with M_Gold(0.9). I first tried 
a reflectance of 0.5 to see the difference.

Thanks for pointing me to the macros. I shall return to them in future 
scenes I am sure.

Thomas

Post a reply to this message

Am 28.09.2012 10:05, schrieb Thomas de Groot:
> I patched in an updated gold nugget bowl with M_Gold(0.9). I first tried
> a reflectance of 0.5 to see the difference.
>
Looks better, methinks ;)

The problem with most of these "old" texture definitions is not only the 
rgb vs. srgb problem. They are simply designed at a time when nobody was 
using radiosity or HDR-lighting (i.e. not necessarily HDRI but 
light_sources with emitting values higher than 1.0). For example 
golds.inc uses an ambient term for the color *calculation* but ambient 
(as part of the finish) gets meanwhile switched off as soon radiosity is 
used.
I'm always did find it easier to use textures that come close to real 
world physics (within the limitations of raytracing) and as such do work 
under all lighting conditions (conventional with/without radiosity and 
radiosity only) instead of tweaking a texture every time I use it.
To me this is not so much about photorealism, it is more about laziness ;)

-Ive

Post a reply to this message

On 28-9-2012 14:33, Ive wrote:
> Am 28.09.2012 10:05, schrieb Thomas de Groot:
>> I patched in an updated gold nugget bowl with M_Gold(0.9). I first tried
>> a reflectance of 0.5 to see the difference.
>>
> Looks better, methinks ;)

Yes, it does indeed.

> The problem with most of these "old" texture definitions is not only the
> rgb vs. srgb problem. They are simply designed at a time when nobody was
> using radiosity or HDR-lighting (i.e. not necessarily HDRI but
> light_sources with emitting values higher than 1.0). For example
> golds.inc uses an ambient term for the color *calculation* but ambient
> (as part of the finish) gets meanwhile switched off as soon radiosity is
> used.

I fully agree. Normally, I rarely use the "out of the box" textures and 
prefer to brew my own. Only for those special cases like gold I am 
rather unsure and tend to use something available, forgetting that they 
are often far from up-to-date.

> I'm always did find it easier to use textures that come close to real
> world physics (within the limitations of raytracing) and as such do work
> under all lighting conditions (conventional with/without radiosity and
> radiosity only) instead of tweaking a texture every time I use it.

You are privileged to know what you are talking about :-)

> To me this is not so much about photorealism, it is more about laziness ;)

An acceptable way of life ;-)

Thomas

Post a reply to this message

Am 28.09.2012 14:33, schrieb Ive:

> I'm always did find it easier to use textures that come close to real
> world physics (within the limitations of raytracing) and as such do work
> under all lighting conditions (conventional with/without radiosity and
> radiosity only) instead of tweaking a texture every time I use it.
> To me this is not so much about photorealism, it is more about laziness ;)

+1

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
> The animation feature of POV-Ray can be used to make it a spectral
> render engine. The basic idea is to render a set of gray-scale images
>   - each representing a specific wavelength - and finally combine them
> using the CIE color match function.
> To simplify this task I have created a few POV-Ray SDL scripts and some
> examples.
> You'll find the download link, some images and more explanation here:
>
> http://www.lilysoft.org/CGI/SR/Spectral%20Render.htm
>
> -Ive

Would this help POV to render caustics any faster?

I ask this because I could not after all my attempts get POV-Ray to render some
caustics scene with chromatic dispersion as fast as Lux Render did (Lux uses
spectral rendering)other than that I would have been so happy to use POV because
of so many other features, but for this particular scene, the speed issue was
really too high of a bottleneck, preventing it to keep the same quality between
the two renderers.

Post a reply to this message

Am 01.01.2013 22:23, schrieb Mr:
> Ive <ive### [at] lilysoftorg> wrote:
>> The animation feature of POV-Ray can be used to make it a spectral
>> render engine. The basic idea is to render a set of gray-scale images
>>    - each representing a specific wavelength - and finally combine them
>> using the CIE color match function.
>> To simplify this task I have created a few POV-Ray SDL scripts and some
>> examples.
>> You'll find the download link, some images and more explanation here:
>>
>> http://www.lilysoft.org/CGI/SR/Spectral%20Render.htm
>>
>> -Ive
>
> Would this help POV to render caustics any faster?
>
> I ask this because I could not after all my attempts get POV-Ray to render some
> caustics scene with chromatic dispersion as fast as Lux Render did (Lux uses
> spectral rendering)other than that I would have been so happy to use POV because
> of so many other features, but for this particular scene, the speed issue was
> really too high of a bottleneck, preventing it to keep the same quality between
> the two renderers.

I'm not sure how Lux does it, but here's one optimization I could 
imagine, which POV-Ray currently doesn't do:

When the generated photon map is evaluated for a dispersed (and hence 
monochromatic) ray from the camera, dispersed (and hence also 
monochromatic) photons with a different wavelength could theoretically 
be ignored (and those typically are a lot if you make ample use of 
high-quality dispersion).

In POV-Ray, the fact that a photon was subject to dispersion (and hence 
is monochromatic) is forgotten in the stored photons map; such photons 
are instead stored just like normal non-dispersed colored photons. Thus, 
POV-Ray needs to evaluate each and every photon even for monochromatic rays.

As Ive's approach only deals with one single wavelength per render 
anyway, it automatically gets that optimization for free. However, for 
non-dispersed rays and photons it loses a lot in terms of performance, 
as it needs to trace such rays and photons over and over again for each 
wavelength even though their trajectory is the same for all wavelengths.

Hard-coding this optimization into POV-Ray should be no big deal; it 
doesn't even need full-fledged spectral color math to work. It would 
probably increase the photons map memory footprint by 20% though.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 01.01.2013 22:23, schrieb Mr:
> > Ive <ive### [at] lilysoftorg> wrote:
> >> The animation feature of POV-Ray can be used to make it a spectral
> >> render engine. The basic idea is to render a set of gray-scale images
> >>    - each representing a specific wavelength - and finally combine them
> >> using the CIE color match function.
> >> To simplify this task I have created a few POV-Ray SDL scripts and some
> >> examples.
> >> You'll find the download link, some images and more explanation here:
> >>
> >> http://www.lilysoft.org/CGI/SR/Spectral%20Render.htm
> >>
> >> -Ive
> >
> > Would this help POV to render caustics any faster?
> >
> > I ask this because I could not after all my attempts get POV-Ray to render some
> > caustics scene with chromatic dispersion as fast as Lux Render did (Lux uses
> > spectral rendering)other than that I would have been so happy to use POV because
> > of so many other features, but for this particular scene, the speed issue was
> > really too high of a bottleneck, preventing it to keep the same quality between
> > the two renderers.
>
> I'm not sure how Lux does it, but here's one optimization I could
> imagine, which POV-Ray currently doesn't do:
>
> When the generated photon map is evaluated for a dispersed (and hence
> monochromatic) ray from the camera, dispersed (and hence also
> monochromatic) photons with a different wavelength could theoretically
> be ignored (and those typically are a lot if you make ample use of
> high-quality dispersion).
>
> In POV-Ray, the fact that a photon was subject to dispersion (and hence
> is monochromatic) is forgotten in the stored photons map; such photons
> are instead stored just like normal non-dispersed colored photons. Thus,
> POV-Ray needs to evaluate each and every photon even for monochromatic rays.
>
> As Ive's approach only deals with one single wavelength per render
> anyway, it automatically gets that optimization for free. However, for
> non-dispersed rays and photons it loses a lot in terms of performance,
> as it needs to trace such rays and photons over and over again for each
> wavelength even though their trajectory is the same for all wavelengths.
>
> Hard-coding this optimization into POV-Ray should be no big deal; it
> doesn't even need full-fledged spectral color math to work. It would
> probably increase the photons map memory footprint by 20% though.


Thanks! Your explanation is so clear! I would vote for the speed optimization as
I have so much RAM, but I would understand if others disagree. In which case I
would never be able to finish that stupid render. It's not even pretty, just a
comparative test :-)

Post a reply to this message