Le 2025-08-05 à 19:45, Cousin Ricky a écrit :
> On 2025-08-05 07:47, Mr wrote:
>>
>> could you please use conserve_energy keyword with your metals, as they are
>> currently so blindingly bright that I can't see the picture ! ;-P
> 
> Conserve_energy is intended for transparent textures; it is not relevant
> for metals (except maybe transparent aluminum).  The usual problem with
> legacy metallic textures is diffuse and ambient finishes that are too
> high, and that appears to be the problem with the typeball in this image.
> 
>> I wish Cousin Ricky's macros could be included in POV-Ray sources, so that the
>> default way of calling a metal would have all that hard-wired. because users
>> should be able to trust the defaults to not do that kind of thing.
> 
> I have proposed updates of metals.inc and golds.inc that use textures
> derived from RC3Metal.  I will probably submit a pull request when my
> Git learning curve levels off somewhat.  But this will also require a
> consensus resolution to the issue I raise in the p.beta-test thread
> "Ambient and diffuse for include files?"
> 
>> To sum it up
>> use fresnel, ior, conserve_energy
> 
> Fresnel, ior, and conserve_energy are for non-metallic textures.  For
> metals, the 'metallic' keyword takes care of all these factors.
> 
>> and a sum of diffuse+specular+reflection below
>> 1.(most clean and shiny metals should have very very low diffuse)
> 
> Diffuse+reflection should be below 1; specular albedo should be
> comparable to reflection, if you use use specular at all.  Yes, diffuse
> should be low, but I would add that the ambient should be even lower;
> the ambient-to-diffuse ratio should be no higher than for the other
> finishes in your scene.  For a purely metallic texture, both diffuse and
> ambient should be zero, though the world usually isn't that clean.
> 

I use ambient 0 for my metallic textures. I also tent to use diffuse no 
higher than 0.1, and that's for the dullest metals.

Post a reply to this message

The only time I ever use Ambient values are for light generating surfaces. lcd
screens etc...


Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2025-08-05 07:47, Mr wrote:

> Conserve_energy is intended for transparent textures; it is not relevant
> for metals (except maybe transparent aluminum).

I should have known! I stand corrected, my mistake probably came from my wish
that using such a keyword in a texture would actually constrain all of the
shading chain to be so ! (maybe Uberpov or any experimental version did it at
one point?) because having a way to add up diffuse ambient specular(s) including
phong and reflection above 1 certainly also break the conservation of energy...
I don't mind having to break out of the default for establishing realism, but, i
guess I expected that one keyword to do it would be the expected toolset's
consistency and efficiency.


> Fresnel, ior, and conserve_energy are for non-metallic textures.  For
> metals, the 'metallic' keyword takes care of all these factors.
Oh! I had the distorted memory that the metallic keyword only took care of
propagating diffuse color to reflection and/or specular. Thanks

> Diffuse+reflection should be below 1; specular albedo should be
> comparable to reflection, if you use use specular at all.
why should we use the same value for specular and reflection when using both?
Say if we think of emulating a layered material with varnished mirror-like
reflectivity but a more say oily or smooth inner structure... Couldn't both
these layers have different shininess?

Post a reply to this message

"Clarence1898" <dle### [at] comcastnet> wrote:

> It was rendered by version 3.5 probably 20 years ago.  I recovered the images
> from an old hard drive, unfortunately I could not find the original source.  I
> still have a couple of drives to check, hopefully the source is on one of them.
> I would like to render it on a newer version.


Sorry again for the too harsh comment then ! (and also technically wrong as
demonstrated by Cousin Ricky)
It was out of sheer enthusiasm for POV's capacities combined with the
frustration about other communities ignoring those under the false belief that
it's not able to achieve modern looking results.

Post a reply to this message

"Mr" <m******r******at_hotmail_dot_fr> wrote:

> I don't mind having to break out of the default for establishing realism, but, i
> guess I expected that one keyword to do it would be the expected toolset's
> consistency and efficiency.


> why should we use the same value for specular and reflection when using both?
> Say if we think of emulating a layered material with varnished mirror-like
> reflectivity but a more say oily or smooth inner structure... Couldn't both
> these layers have different shininess?

Hi Maurice,

I think that for a lot of things, we're just going to have to set up systems
that lay out the underlying theoretical framework in SDL, using functions,
macros, and comments for placeholders.

So, in the same way that we can't query camera location, or directly access mesh
or prism vertices, and so need to store those values in variables/identifiers
and arrays - so we will need to store all of the texturing values and manually
process them that way.

In the absence of a dev team / developer / development - we'll just have to
program everything in SDL.  Then, once someone gets around to writing source
code to implement such things, "all they will have to do" is translate from SDL
to cpp/C. (and yes, they will have to smoothly integrate that into the whole
existing source code framework).

At the very least, it helps the rest of learn about what makes textures more
realistic, since we can follow the logic or how the textures are formally
constructed.  Presumably, there will also be equations for lighting models and
other light/shadow/reflection effects that will be used as a basic for the macro
/algorithm logic that will self-document such things and help people learn about
those as well.

- BW

Post a reply to this message

"Clarence1898" <dle### [at] comcastnet> wrote:
> I was going through some old drives and found this one.  I posted this probably
> 20 years ago as my obligatory first RSOCP.  I came across Povray in the early
> 90s and have used it off and on ever since.  I thought it might be interesting
> to see what programming Pov scenes would be like in the 1970's.  Just for a
> little background, I've been a mainframe programmer since 1969, and now enjoy
> programming PC's.

Getting around to commenting on this scene a little late . . .

This is a pretty cool scene.
I really like the Selectric ball, and the punch cards.

I remember playing with shoeboxes full of punch cards at my grandparents' house
growing up.
They still sell the tractor-feed paper:  apparently lots of businesses still use
it.

The font on the paper and punch cards is nice - and I like the traditional
slipping into the scene of "Persistence of Vision" on the cards.  :)

I put a bunch of such Easter Eggs into my Secret Passage scene.

It's good to see that you're still playing with POV-Ray all these many years
later.

- BW

Post a reply to this message