 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Leroy" <whe### [at] gmail com> wrote:
> "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.
>
> Nice scene!
> I have cases of the paper in your scene. Got them from a office supply store
> that closed down in the late 90's. Used to use the punch cards as book markers.
> Have Fun
Thank You. I ran out of green bar paper a long time ago. I still have half a
box of punch cards left. Indeed they make great book markers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Clarence1898" <dle### [at] comcastnet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ...
> Thank You. Of course the cards are punched. How else could I feed the program
> to the computer.
</grin>
> No, 1898 is not a reference to jazz. I grew up in the 50s and
> 60s, my taste in music runs more to classic rock and roll.
ah, ok, thanks. (about 10 years ahead of self, then :-))
in the reply to Leroy, you wrote: "I ran out of green bar paper a long time
ago". glad you did because I now (can) see what had "nagged" me re the image,
the solid colour bars. the (fan-fold) "green bar" I remember, and used, had six
(I think) thin, parallel green lines making each "bar". must be a
manufacturers' thing.
regards, jr.
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.
Hi,
Did you render this on a current POV-Ray version (3.7 or 3.8b), and if so with
the proper version directive?
I love the concept, the visual ideas, and they read like a very nice picture...
So though I'm not used to that, it motivates me to use for the first time (and
maybe the last if it comes out too harsh) a very meanly well-intended sarcasm :
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
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. To sum it up
use fresnel, ior, conserve_energy and a sum of diffuse+specular+reflection below
1.(most clean and shiny metals should have very very low diffuse)
Seriously, nice hues and punched cards though, as I do see them!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr" <m******r******at_hotmail_dot_fr> wrote:
> "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.
>
> Hi,
> Did you render this on a current POV-Ray version (3.7 or 3.8b), and if so with
> the proper version directive?
>
> I love the concept, the visual ideas, and they read like a very nice picture...
> So though I'm not used to that, it motivates me to use for the first time (and
> maybe the last if it comes out too harsh) a very meanly well-intended sarcasm :
> 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
> 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. To sum it up
> use fresnel, ior, conserve_energy and a sum of diffuse+specular+reflection below
> 1.(most clean and shiny metals should have very very low diffuse)
>
> Seriously, nice hues and punched cards though, as I do see them!
Thank You.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
