povray.binaries.tutorials message digest

[Bald Eagle] Re: List of Tutorials [157 days 17 hours and 58 minutes ago]

Fri, 31 Oct 2025 17:15:00 GMT

"Maetes" <nomail@nomail> wrote:

> If you know any good tutorials or have published some yourself, let me know.

Very old, one of my first:

https://news.povray.org/povray.binaries.tutorials/thread/%3Cweb.51f61e827603294573fc9ebb0%40news.povray.org%3E/

Face the camera:
https://news.povray.org/povray.binaries.animations/thread/%3C678d618a%40news.povray.org%3E/?mtop=444986&moff=16

Point_at_trans
https://news.povray.org/povray.binaries.images/message/%3Cweb.603d4fcda906d8e31f9dae300%40news.povray.org%3E/#%3Cweb.60
3d4fcda906d8e31f9dae300%40news.povray.org%3E

rotation matrices:
https://news.povray.org/povray.binaries.images/thread/%3Cweb.6065117d946f4e1c1f9dae3025979125%40news.povray.org%3E/?tto
p=446609&toff=500

Polygon testing
https://news.povray.org/povray.binaries.images/thread/%3Cweb.6040322ee3a6afa51f9dae300%40news.povray.org%3E/?ttop=44660
9&toff=500
Reminder to self- I think there's another way to do this with vector cross
products

Vcross and Vdot
https://news.povray.org/povray.binaries.images/thread/%3Cweb.603c2cf772f42fb31f9dae300%40news.povray.org%3E/?ttop=44660
9&toff=500


https://news.povray.org/povray.advanced-users/thread/%3Cweb.65c5154df4e0c5dc1f9dae3025979125%40news.povray.org%3E/

[yesbird] Re: List of Tutorials [157 days 19 hours and 17 minutes ago]

Fri, 31 Oct 2025 15:55:35 GMT

On 30/10/2025 23:23, Maetes wrote:
> I have created a page on my website where I want to summarize tutorials in the
> future. As helpful as possible and with working examples, most of them I test at
> least partially.
> 
> https://www.maetes.com/en/povray/tutorials-big-and-small-ones

Excellent work, very detailed and accurate - go on !
--
YB

[Leroy] Re: List of Tutorials [158 days 11 hours and 33 minutes ago]

Thu, 30 Oct 2025 23:40:00 GMT

"Maetes" <nomail@nomail> wrote:
> I have created a page on my website where I want to summarize tutorials in the
> future. As helpful as possible and with working examples, most of them I test at
> least partially.
>
>
> https://www.maetes.com/en/povray/tutorials-big-and-small-ones
>
>
> I won't search all forum posts for more, but when I find good ones, I will list
> them.
>
> If you know any good tutorials or have published some yourself, let me know.
>
> ma


Good work! I think I've used most of them over the years.

Have fun!

[Maetes] List of Tutorials [158 days 14 hours and 48 minutes ago]

Thu, 30 Oct 2025 20:25:00 GMT

I have created a page on my website where I want to summarize tutorials in the
future. As helpful as possible and with working examples, most of them I test at
least partially.


https://www.maetes.com/en/povray/tutorials-big-and-small-ones


I won't search all forum posts for more, but when I find good ones, I will list
them.

If you know any good tutorials or have published some yourself, let me know.

ma

[jr] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [707 days 23 hours and 58 minutes ago]

Mon, 29 Apr 2024 11:15:00 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> ...
> > so, the "take away" is to not mix RGB types and 's' variants in the
> > same scene ?
>
> I don't think it causes any technical problems 'under the hood'-- I sometimes
> mix the two 'flavors' in *object* colors, depending on...whim ;-) But as a
> *general* rule, it is probably not a good idea to mix one flavor in LIGHTS with
> another flavor on objects-- only because the resulting object colors would be
> somewhat unexpected.

ouch.  exactly the habit I've fallen into, srgb light + rgb all else.  </grin>



> Consider the following combinations ...

thank you very much for that.  simple and effective.


> Personally, I like to use the 3rd combination...just a personal choice due to
> familiarity with how colors in other graphics apps appear to me. No 'washed-out'
> colors, in other words. I have never been very good at choosing plain rgb
> triplets to get what I want.

same here, I need a visual of the colour, usually.  may try and address "the
habit".


@ingo, "I wouldn't miss srgb."

thanks for providing a "sideways perspective", appreciated.


regards, jr.

[Cousin Ricky] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [710 days 17 hours and 18 minutes ago]

Fri, 26 Apr 2024 17:55:04 GMT

On 4/25/24 08:40 (-4), Bald Eagle wrote:
> 
> So, it looks to me to be like this:
> 
> When POV-Ray uses an assumed_gamma that is <> 1, it funnels everything through a
> function that translates all of the colors from a line to a curve.
> 
> Also, when images are encoded using a gamma <> 1, the same thing happens.
> 
> So if you're going to use byte-encoded (s)rgb values from a color picker, then
> you're not going to be funneling them through any kind of software that "reads
> the image in" - you're manually bypassing that.  So you wind up having to
> manually do the correction yourself with the srgb keyword to pull all of the
> colors back into the linear space _of the pre-rendered SDL file_ before then
> rendering your image with what may be a(nother) non-linear gamma <>1.
> So if you just used the byte-encoded color values, you'd wind up applying gamma
> adjustments twice - the one that is inherent in the sampled image color values,
> and then the one that POV-Ray applies when you render the image with a gamma <>
> 1.

Sounds like you've got it.

> It's early, and the coffee is still sinking in, so I don't fully understand why
> gamma gets applied to an image in the first place - unless it's just a way to
> preserve the original gamma=1 color values for image-editing purposes.

I can't speak for the old pre-standardization days, but nowadays I
believe it's to minimize storage requirements.  If the image is stored
with a linear format, our non-linear perception would lead to banding in
darker areas of the image, and storage overkill in the lighter areas.
Eliminating the banding while keeping a linear format would require
significantly more storage.  By using a gamma that approximates our
perception, we shift the resolution balance towards the darker end, thus
reducing banding without increasing storage requirements.

Note that HDR formats such as EXR can get away with linear storage,
because they use floating point, rather than binary.

[Kenneth] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [711 days 18 hours and 28 minutes ago]

Thu, 25 Apr 2024 16:45:00 GMT

Thanks Cousin Ricky, that's a really good and useful distillation of the rgb vs.
srgb multiplication rules. I shall refer to it often. Those rules are easy to
forget :-(

> [jr wrote:]
> so, the "take away" is to not mix RGB types and 's' variants in the
> same scene ?

I don't think it causes any technical problems 'under the hood'-- I sometimes
mix the two 'flavors' in *object* colors, depending on...whim ;-) But as a
*general* rule, it is probably not a good idea to mix one flavor in LIGHTS with
another flavor on objects-- only because the resulting object colors would be
somewhat unexpected.  Consider the following combinations (while using
assumed_gamma 1.0):

the usual standard or typical way, no srgb:
light_source{ rgb <.3,.5,.7>}
object{... pigment{rgb <.5,.3,.1>}

vs.

light_source{ srgb <.3,.5,.7>} // srgb now
object{... pigment{rgb <.5,.3,.1>}

vs.

light_source{ srgb <.3,.5,.7>} // srgb now
object{... pigment{srgb <.5,.3,.1>} // srgb now

The object in each case will appear with a different brightness and a slightly
different hue...possibly not what you expect, given the unchanging triplet
values that you choose.

Personally, I like to use the 3rd combination...just a personal choice due to
familiarity with how colors in other graphics apps appear to me. No 'washed-out'
colors, in other words. I have never been very good at choosing plain rgb
triplets to get what I want.

[ingo] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [711 days 22 hours and 3 minutes ago]

Thu, 25 Apr 2024 13:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> It's early, and the coffee is still sinking in, so I don't fully understand why
> gamma gets applied to an image in the first place - unless it's just a way to
> preserve the original gamma=1 color values for image-editing purposes.
>

That is the core, or origin of the problem. In the early day it seemed wise to
safe files "gamma encoded" so they didn't need that process every time they put
an image on screen. It save clock cycles.

But when you operate on them you first have to go back to linear. But, but, we
didn't even know from what gamma we had to go to linear.... as no format stored
any metadata and Apple did it different any way. (PNM uses BT.709, but now often
srgb...). Even Adobe (Photoshop) did it wrong and happily operated on non linear
data.

For me, in POV-Ray, for a single data point this srgb is a non-issue. "One
tweaks a colour anyway". For importing images as texture it is a different
issue, but there also, tweak the image data to your desire to fit the scene or a
proper reference. I wouldn't miss srgb.

ingo

[Bald Eagle] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [711 days 22 hours and 28 minutes ago]

Thu, 25 Apr 2024 12:45:00 GMT

"ingo" <nomail@nomail> wrote:

> The problem is I don't understand the problem,

So, it looks to me to be like this:

When POV-Ray uses an assumed_gamma that is <> 1, it funnels everything through a
function that translates all of the colors from a line to a curve.

Also, when images are encoded using a gamma <> 1, the same thing happens.

So if you're going to use byte-encoded (s)rgb values from a color picker, then
you're not going to be funneling them through any kind of software that "reads
the image in" - you're manually bypassing that.  So you wind up having to
manually do the correction yourself with the srgb keyword to pull all of the
colors back into the linear space _of the pre-rendered SDL file_ before then
rendering your image with what may be a(nother) non-linear gamma <>1.
So if you just used the byte-encoded color values, you'd wind up applying gamma
adjustments twice - the one that is inherent in the sampled image color values,
and then the one that POV-Ray applies when you render the image with a gamma <>
1.

Now, anyone familiar with film gamma knows that higher gamma values give you a
more "contrasty" look than a gamma=1 image.   So think about what happens when
you think you're using srgb values, but you're using rgb values, and then
correct for a higher gamma to translate that into linear space --- you bend that
gamma curve in the _opposite_ direction - giving rise to that "washed out" look,
because you've _decreased_ the contrast of the color space.

SO, I think what we may want to see are several things.
An RGB cube viewed from a corner to give that nice RGB hexagon.
(I think that having a function {} using hexagonal coordinates to just color a
hexagonal prism would be nice little tool.)
A single image rendered as strips of increasing gamma, to show the differences.
Color strips and graphs to show the change in hue and brightness.
Do we have a mathematical way to express "gamma" or "contrast", given the full
range of color values in an image?


It's early, and the coffee is still sinking in, so I don't fully understand why
gamma gets applied to an image in the first place - unless it's just a way to
preserve the original gamma=1 color values for image-editing purposes.

- BW

[ingo] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [711 days 23 hours and 53 minutes ago]

Thu, 25 Apr 2024 11:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> "The srgb keyword [...]"

The problem is I don't understand the problem,

There's three ways in dealing with colour:
1. the easy way, everything in linear space (as POV-Ray does)
2. the proper way, CIE colour space.
3. the messy way (srgb et all)

in 1 & 2 every operations is done within the same colour space  so the results
are always the same. In linear colour space operations are easy, in CIE they are
hard(er) as it is a curved space. Only at the very end of the chain of
operations the result is adapted to the presentation method screen (nowadays
srgb), print on paper, print on slide, print om film, carve in wood, etch in
zinc, etc.

The messy way (3) kind off starts at the output and you have to adapt the input,
that's a strange way. The output isn't a fixed thing.

I kind of understand why the srgb colour was introduced in POV-Ray, but it feels
very wrong to me. A build in function, fromsrgb( ) would have been fine and
explicit. Maybe it can still be changed?

ingo

[Bald Eagle] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [712 days 16 hours and 23 minutes ago]

Wed, 24 Apr 2024 18:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I do believe it was stated somewhere above that POV-Ray takes into account the
> effective scene gamma... so I would recommend digging around in the source code.

https://news.povray.org/web.5f8799f076c60ba860e0cc3d0%40news.povray.org

"The srgb keyword always returns a color that *looks* the same across all
assumed_gamma settings.  To take your example, srgb 0.75 will *look* the same
whether your scene uses assumed_gamma 1, assumed_gamma 2.2, or assumed_gamma
srgb.  But this implies that, internally, it will evaluate to different rgb
values depending on the assumed_gamma setting.

When you use assumed_gamma srgb, the scene's nonlinearity aligns with the color
definition, which is why rgb and srgb return the same value.  And since sRGB is
close to gamma 2.2, rgb and srgb return close, but not identical, values under
assumed_gamma 2.2."

[Bald Eagle] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [713 days 10 hours and 8 minutes ago]

Wed, 24 Apr 2024 01:05:00 GMT

So, I did a little spreadsheet dabbing, and the srgb-to-rgb and inverse both
work perfectly and as expected.

So the real question at this point, is what do people want to know, have
available to them, and see in a documentation render, animation, macro,
function, etc?

It should unambiguously answer any questions that you have, and provide you with
any visual explanations that you might need, and data that you might to
copy/paste into a scene to solve whatever problem you might be experiencing.

- BW

[Thomas de Groot] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [713 days 22 hours and 58 minutes ago]

Tue, 23 Apr 2024 12:14:40 GMT

Op 23-4-2024 om 11:16 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 22/04/2024 om 19:18 schreef Bald Eagle:
>>> ...
>>> Oh please oh please oh please.....     ;)
>>
>> <large grin>
>>
>> I imagine that hell is paved ...
> 
> Hell yes !!  (I only got as far as tarring & feathering) </grin>
> 
> 
> regards, jr.
> 

That is bad enough already ;-)

-- 
Thomas

[Bald Eagle] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [713 days 23 hours and 3 minutes ago]

Tue, 23 Apr 2024 12:10:00 GMT

I forgot that there was also this post:

https://news.povray.org/povray.text.scene-files/thread/%3C58da4065%241%40news.povray.org%3E/

[Bald Eagle] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [714 days and 43 minutes ago]

Tue, 23 Apr 2024 10:30:00 GMT

"ingo" <nomail@nomail> wrote:

> Maybe our Cousin can add a simple demo what srgb input results in what rgb being
> used?

I totally agree about the darkroom - with the timer and trays - and the
thermometer.  Ansel Adams taught me a lot.

And we _have_ covered this topic extensively, and it's likely time that we ALL
put our heads together and hammered out some good macros with commentary, and
then putting together a scene / graph / animation would be trivial.

A spreadsheet would not be a bad idea either.

https://news.povray.org/web.5f8cb1fd76c60ba81f9dae300%40news.povray.org
https://news.povray.org/povray.general/thread/%3Cweb.60649d9bb9b7dccdd98418916e066e29%40news.povray.org%3E/?mtop=434374

I do believe it was stated somewhere above that POV-Ray takes into account the
effective scene gamma... so I would recommend digging around in the source code.

- BE

[jr] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [714 days 1 hour and 53 minutes ago]

Tue, 23 Apr 2024 09:20:00 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 22/04/2024 om 19:18 schreef Bald Eagle:
> > ...
> > Oh please oh please oh please.....     ;)
>
> <large grin>
>
> I imagine that hell is paved ...

Hell yes !!  (I only got as far as tarring & feathering) </grin>


regards, jr.

[Thomas de Groot] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [714 days 4 hours and 53 minutes ago]

Tue, 23 Apr 2024 06:19:42 GMT

Op 22/04/2024 om 19:18 schreef Bald Eagle:
> 
> WHEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE!
> 
> 'Round and 'round we go, when we'll stop NOBODY KNOWS!!!!!
> 
> https://news.povray.org/web.64b18904b039fa5d1f9dae3025979125%40news.povray.org
> 
> 
> 
> Can we do gamma again?  Oh please oh please oh please.....     ;)
> 

<large grin>

I imagine that hell is paved with white hot gamma, rgb, and srgb slabs....

-- 
Thomas

[ingo] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [714 days 5 hours and 48 minutes ago]

Tue, 23 Apr 2024 05:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Can we do gamma again?  Oh please oh please oh please.....     ;)

Maybe our Cousin can add a simple demo what srgb input results in what rgb being
used?

#version 3.8;
global_settings{ assumed_gamma 1.0 }

#for (i,0,1,0.1)
  #declare c = srgb i;
  #debug concat(str(i,0,2)," : ",vstr(3,c,", ",0,2), "\n")
#end

maybe add splines to it to show the relationship.

or the relation with gamma in photography how exposure time and development time
influence gamma while having the same min and max density as a result. And how
you can play with photographic paper to compensate for gamma errors a bit or use
it for artistic expression, kind of changing assumed_gamma .... sorry, got
carried a way, thoughts of red lights and darkrooms


ingo

[Bald Eagle] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [714 days 17 hours and 53 minutes ago]

Mon, 22 Apr 2024 17:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> Cousin Ricky <ric### [at] yahoocom> wrote:
> > ...
> > The first thing to remember is that POV-Ray has *one* and only *one*
> > color format.  The srgb keyword does not create a different kind of
> > color than the rgb keyword; it simply interprets its argument
> > differently.  ...
>
> (belated) thanks.
>
> so, the "take away" is to not mix RGB types and 's' variants in the same scene ?
>  and use RGB types only if values, due to arithmetic, may go "out of range" ?
>
> (a sort of "conclusion" with recommendation would have been ideal)
>
>
> regards, jr.

WHEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE!

'Round and 'round we go, when we'll stop NOBODY KNOWS!!!!!

https://news.povray.org/web.64b18904b039fa5d1f9dae3025979125%40news.povray.org









Can we do gamma again?  Oh please oh please oh please.....     ;)

[jr] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [714 days 19 hours and 8 minutes ago]

Mon, 22 Apr 2024 16:05:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> ...
> The first thing to remember is that POV-Ray has *one* and only *one*
> color format.  The srgb keyword does not create a different kind of
> color than the rgb keyword; it simply interprets its argument
> differently.  ...

(belated) thanks.

so, the "take away" is to not mix RGB types and 's' variants in the same scene ?
 and use RGB types only if values, due to arithmetic, may go "out of range" ?

(a sort of "conclusion" with recommendation would have been ideal)

regards, jr.

[Thomas de Groot] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [717 days 4 hours and 49 minutes ago]

Sat, 20 Apr 2024 06:23:41 GMT

Op 18/04/2024 om 22:44 schreef Cousin Ricky:
> THE ISSUE
> 
> What is gamma, why should assumed_gamma be set to 1, and how should we
> use the sRGB keywords introduced with POV-Ray 3.7?
> 
> [snip]
> ---
> Copyright (C) 2024 Richard Callwood III, CC-BY-SA 4.0.

Excellent! Thank you very much indeed!

[Real Life: so much to do; so little time... :(  ]

-- 
Thomas

[kurtz le pirate] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [717 days 19 hours and 25 minutes ago]

Fri, 19 Apr 2024 15:48:04 GMT

On 19/04/2024 16:27, Cousin Ricky wrote:
> On 2024-04-19 09:37 (-4), kurtz le pirate wrote:
>>>
>>> Example 1: the Dutch flag.  [snip]
>>
>> Red, white and blue... it's more the flag of the Netherlands than of
>> Germany, isn't it?
> 
> At least in English, "Dutch" means "of the Netherlands."  It does not
> mean "Deutsch," although the words have a common etymology.
> 
> (To confuse things, there's also Pennsylvania Dutch, which *is* a
> dialect of German, but that is another matter.)
> 

I read too fast and my English is really bad.
Sorry :(





-- 
Kurtz le pirate
Compagnie de la Banquise

[Cousin Ricky] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [717 days 20 hours and 46 minutes ago]

Fri, 19 Apr 2024 14:27:13 GMT

On 2024-04-19 09:37 (-4), kurtz le pirate wrote:
>>
>> Example 1: the Dutch flag.  [snip]
> 
> Red, white and blue... it's more the flag of the Netherlands than of
> Germany, isn't it?

At least in English, "Dutch" means "of the Netherlands."  It does not
mean "Deutsch," although the words have a common etymology.

(To confuse things, there's also Pennsylvania Dutch, which *is* a
dialect of German, but that is another matter.)

[kurtz le pirate] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [717 days 21 hours and 35 minutes ago]

Fri, 19 Apr 2024 13:37:57 GMT

On 18/04/2024 22:44, Cousin Ricky wrote:
> THE ISSUE
> 
> ...
> 
> EXAMPLES
> 
> Example 1: the Dutch flag.  Steps 2 & 3 are combined.  Since no
> additional math is required on the colors, there is no need to declare
> them as identifiers.
> 
>   pigment
>   { gradient y color_map
>     { [1/3 srgb <32, 71, 133> / 255] // Steps 2 & 3
>       [1/3 White]
>       [2/3 White]
>       [2/3 srgb <170, 28, 38> / 255] // Steps 2 & 3
>     }
>   }
> 

Red, white and blue... it's more the flag of the Netherlands than of
Germany, isn't it?


Apart from that, a very good and useful explanation.
It's always good to get back to basics.




-- 
Kurtz le pirate
Compagnie de la Banquise

[yesbird] Re: Gamma and the sRGB Keywords in POV-Ray 3.7: ... [717 days 22 hours and 37 minutes ago]

Fri, 19 Apr 2024 12:36:08 GMT

On 18/04/2024 23:44, Cousin Ricky wrote:
> THE ISSUE
> 
> What is gamma, why should assumed_gamma be set to 1, and how should we
> use the sRGB keywords introduced with POV-Ray 3.7?

Thanks, Cousin.
This question was always interesting to me - very clean and detailed
explanation.
--
YB

[Cousin Ricky] Gamma and the sRGB Keywords in POV-Ray 3.7: a Tu... [718 days 14 hours and 28 minutes ago]

Thu, 18 Apr 2024 20:44:36 GMT

THE ISSUE

What is gamma, why should assumed_gamma be set to 1, and how should we
use the sRGB keywords introduced with POV-Ray 3.7?

In the real world, a 1,600 lumen lamp emits twice as much light as an
800 lumen lamp, and a 40% gray object reflects half as much light as an
80% gray object.  To render this reality, POV-Ray must use linear color.
 Setting global_settings { assumed_gamma 1 } accomplishes this goal, and
has been the recommended setting since POV-Ray 3.7.

The problem is that our perceptions are non-linear, and our monitors and
software often reflect that non-linearity.  Gamma is the measure of this
non-linearity.  Typically, RGB colors are specified with the non-linear
sRGB standard, so in order for them to look correct with assumed_gamma
1, they must be decoded to a linear format.  This is what the sRGB
series of keywords (srgb, srgbf, srgbt, and srgbft) does[1].

In addition, many scene files written prior to POV-Ray 3.7 failed to
specify an assumed_gamma, so the resulting image defaulted to whatever
gamma was used by the computer--usually 2.2, which is similar to sRGB.
When rendered with POV-Ray 3.7, these scenes look pale and washed out.
The quick fix is to specify global_settings { assumed_gamma 2.2 }, but
if you wish to put in the work to make the scene physically realistic,
the new keywords can help.

However, confusion often arises over the use of these keywords.

HOW TO USE THE sRGB KEYWORDS

The first thing to remember is that POV-Ray has *one* and only *one*
color format.  The srgb keyword does not create a different kind of
color than the rgb keyword; it simply interprets its argument
differently.  When you #declare a color, the resulting variable has no
memory of which keyword was used to declare it.

The second thing to remember is that the keywords in the sRGB series
decode from sRGB to linear, not the other way around!

It is also important to remember that the entire expression following
the keyword is evaluated before the conversion is applied; and that the
standard sRGB function is defined for the domain 0...1.

Here is the general sequence for usage of these keywords:

  1. Set global_settings { assumed_gamma 1 } *before* using any of the
     keywords.

  2. An sRGB triplet that comes from a color picker, eyedropper tool,
     or published Web source is typically in the range <0,0,0> ...
     <255,255,255>.  These are byte triplets.  However, POV-Ray does not
     use byte triplets; these must be divided by 255 to bring them into
     the range <0,0,0> ... <1,1,1>.  This *must* be done first thing,
     and is the *only* math that should ever be done at this stage,
     though it may be combined with step 3.  If the color is specified
     in percentages, of course you would divide by 100 instead of 255.

  3. #declare (or #local) the color with the srgb keyword.  The
     resulting identifier contains a linear color.  *If and only if* no
     additional math is required, you may skip the #declare/#local and
     use the srgb directly in a pigment or light_source.

  4. Now, do whatever additional math you need on the identifier.  You
     may do this in a pigment or light_source or wherever.

If your color is from colors.inc, then you *must* skip step 2, because
these colors are already within <0,0,0> ... <1,1,1>.  For these colors,
you should use the srgbft keyword in step 3, because they are already
declared with filter and transmit components.

If your color comes from function eval_pigment(), you must skip steps 2
*and* 3.  Such colors are already within POV-Ray's working space, and
starting with POV-Ray 3.7, this includes image maps.

EXAMPLES

Example 1: the Dutch flag.  Steps 2 & 3 are combined.  Since no
additional math is required on the colors, there is no need to declare
them as identifiers.

  pigment
  { gradient y color_map
    { [1/3 srgb <32, 71, 133> / 255] // Steps 2 & 3
      [1/3 White]
      [2/3 White]
      [2/3 srgb <170, 28, 38> / 255] // Steps 2 & 3
    }
  }

Example 2: an orange light.  Since this example doesn't use a byte
triplet, step 2 is unnecessary.

  #declare C = srgb <1, 0.5, 0>; // This must be declared separately!
                                 // (step 3)
  #declare Ld = 100;
  #declare Fd = 1;
  light_source
  { <100, 50, 0>,
    C * (1 + pow (Ld/Fd, 2)) / 2 // Step 4: math is applied to
                                 // identifier C
    fade_power 2
    fade_distance Fd
  }

EPILOGUE

Linear color applies only to the tracing phase. The output command line
options Display_Gamma and File_Gamma should remain at their default sRGB
setting. The gamma option for image maps should normally be left
unspecified.

RESOURCES

This tutorial, plus discussion links and the scene file for the image,
can be found at: https://github.com/CousinRicky/POV-Gamma-sRGB

---
[1] Technically, these keywords convert an sRGB-specified color to match
whatever assumed_gamma you are using.  Using assumed_gamma 1 means they
will convert to linear.

---
Copyright (C) 2024 Richard Callwood III, CC-BY-SA 4.0.

[yesbird] Re: Friedrich Lohmueller's 3D Animation with POV... [1142 days 20 hours and 53 minutes ago]

Sun, 19 Feb 2023 14:19:26 GMT

Source is here:
http://web.archive.org/web/20220301024040/https://www.f-lohmueller.de/index.htm
-- 
YB

[yesbird] Re: Mike Williams's Isosurface Tutorial [1142 days 20 hours and 58 minutes ago]

Sun, 19 Feb 2023 14:14:39 GMT

Source is here:
http://web.archive.org/web/20190728000430/http://www.econym.demon.co.uk/isotut/index.htm
--
YB

[yesbird] Re: Friedrich Lohmueller's POV-Ray Tutorials [1142 days 20 hours and 59 minutes ago]

Sun, 19 Feb 2023 14:13:29 GMT

Source is here:
http://web.archive.org/web/20220301024040/https://www.f-lohmueller.de/index.htm
--
YB

[yesbird] Friedrich Lohmueller's POV-Ray Tutorials [1142 days 22 hours and 27 minutes ago]

Sun, 19 Feb 2023 12:45:24 GMT

For browsing:
https://povlab.online/povtutorial/

Archived:
https://povlab.online/arc/pov_tut.zip
-- 
YB

[yesbird] Mike Williams's Isosurface Tutorial [1142 days 22 hours and 46 minutes ago]

Sun, 19 Feb 2023 12:27:18 GMT

For browsing:
https://povlab.online/isotutorial/

Archived:
https://povlab.online/arc/iso_tut.zip
--
YB

[yesbird] Friedrich Lohmueller's 3D Animation with POV-Ray [1142 days 22 hours and 51 minutes ago]

Sun, 19 Feb 2023 12:22:04 GMT

For browsing:
https://povlab.online/animtutorial/

Archived:
https://povlab.online/arc/anim_tut.zip
--
YB

[yesbird] Re: Friedrich Lohmueller's POV-Ray Tutorials [1143 days 3 hours and 4 minutes ago]

Sun, 19 Feb 2023 08:08:39 GMT

> A very big thanks indeed!
Always welcome, the full archive is here, but keeping it on your own 
site is much safer, indeed.

http://web.archive.org/web/20220809075625/http://f-lohmueller.de/index.htm
--
YB

[yesbird] f-lohmueller.de - Tutorials and galleries [1143 days 3 hours and 9 minutes ago]

Sun, 19 Feb 2023 08:04:14 GMT

Maybe you already know, that archived version of this site available here:

http://web.archive.org/web/20220809075625/http://f-lohmueller.de/index.htm

--
YB

[Thomas de Groot] Re: Friedrich Lohmueller's POV-Ray Tutorials [1143 days 3 hours and 46 minutes ago]

Sun, 19 Feb 2023 07:27:05 GMT

Op 19/02/2023 om 06:35 schreef yesbird:
> Now available here: https://povlab.online/povtutorial/
> -- 
> YB

A very big thanks indeed! This is one of those sites that one refers to 
regularly. I never got around to download Friedrich's pages for 
safekeeping... :-(

-- 
Thomas

[yesbird] Friedrich Lohmueller's POV-Ray Tutorials [1143 days 5 hours and 37 minutes ago]

Sun, 19 Feb 2023 05:35:55 GMT

Now available here: https://povlab.online/povtutorial/
--
YB

[Cousin Ricky] Re: Beveled text isosurfaces tutorial [1534 days 17 hours and 19 minutes ago]

Sun, 23 Jan 2022 17:53:41 GMT

On 2020-10-14 20:00 (-4), Cousin Ricky wrote:
> This tutorial describes a two-step process for creating beveled text in
> POV-Ray with an isosurface.

I have made a minor update: I no longer recommend the 'once' keyword in
the image map.

[Thomas de Groot] Re: Isosurface Tutorial by Mike Williams [1787 days 4 hours and 39 minutes ago]

Sun, 16 May 2021 06:33:36 GMT

Op 15/05/2021 om 18:46 schreef Pekka Aho:
> ingo <ing### [at] tagpovrayorg> wrote:
>> http://web.archive.org/web/20160315000000
>> */http://www.econym.demon.co.uk/isotut/index.htm
> 
> Yes, I saw that in the off-topic area. But I wanted to post this zip IF
> something ever happens with the web archive. I'm a neurotic person what it comes
> to preserving useful stuff, so I tend to collect cool things on my own devices
> when possible. Plus, an offline version is nice to have around as well, me
> thinks.
> 
Ha! "great minds think alike"! ;-)

-- 
Thomas

[Pekka Aho] Re: Isosurface Tutorial by Mike Williams [1787 days 18 hours and 23 minutes ago]

Sat, 15 May 2021 16:50:00 GMT

ingo <ing### [at] tagpovrayorg> wrote:
> http://web.archive.org/web/20160315000000
> */http://www.econym.demon.co.uk/isotut/index.htm

Yes, I saw that in the off-topic area. But I wanted to post this zip IF
something ever happens with the web archive. I'm a neurotic person what it comes
to preserving useful stuff, so I tend to collect cool things on my own devices
when possible. Plus, an offline version is nice to have around as well, me
thinks.

[ingo] Re: Isosurface Tutorial by Mike Williams [1787 days 18 hours and 59 minutes ago]

Sat, 15 May 2021 16:13:56 GMT

in news:web.609fe84ffb749b2cbac92b0947dba873@news.povray.org Pekka Aho
wrote: 

> I thought I had lost it, but finally managed to find the isosurface
> tutorial in my personal backups. There was a "printer friendly
> version" available on Mike's pages back in the day, so I saved it
> just in case, as it's an excellent tutorial after all. As the actual
> website is gone, here's the downloaded version if someone's
> interested. :) 

http://web.archive.org/web/20160315000000
*/http://www.econym.demon.co.uk/isotut/index.htm

[Pekka Aho] Isosurface Tutorial by Mike Williams [1787 days 19 hours and 43 minutes ago]

Sat, 15 May 2021 15:30:00 GMT

I thought I had lost it, but finally managed to find the isosurface tutorial in
my personal backups. There was a "printer friendly version" available on Mike's
pages back in the day, so I saved it just in case, as it's an excellent tutorial
after all. As the actual website is gone, here's the downloaded version if
someone's interested. :)

best regards,
-Pekka

[Cousin Ricky] Beveled text isosurfaces tutorial [2000 days 11 hours and 12 minutes ago]

Thu, 15 Oct 2020 00:00:25 GMT

This tutorial describes a two-step process for creating beveled text in 
POV-Ray with an isosurface.  First an image map is created of the text 
to be manipulated; then the image map is read into a pigment function, 
which is used for the isosurface.  The technique avoids the inside 
corner artifacts of Bevelled_Text(), can create rounded edges, and works 
with any font.

[Thomas de Groot] Re: Bezier / bicubic_patch uv mapping reference [3675 days 3 hours and 17 minutes ago]

Tue, 15 Mar 2016 07:55:30 GMT

On 14-3-2016 17:17, Bald Eagle wrote:
> I put this together after struggling with stitching together bicubic-patch
> objects and trying to uv-map them either as a union{} or individually.
>
> Hopefully it's accurate - if not please chime in so that I can make corrections
> and bad information doesn't get disseminated and perpetuated.
>
> Perhaps there's a mechanism by which erroneous images can be removed or
> replaced?
>
> Anyway, hope you like.
>
>

Very useful. Thanks. On my dangerously tottering pile of ToDo/ToTry.

-- 
Thomas

[Bald Eagle] Bezier / bicubic_patch uv mapping reference [3675 days 18 hours and 53 minutes ago]

Mon, 14 Mar 2016 16:20:01 GMT

I put this together after struggling with stitching together bicubic-patch
objects and trying to uv-map them either as a union{} or individually.

Hopefully it's accurate - if not please chime in so that I can make corrections
and bad information doesn't get disseminated and perpetuated.

Perhaps there's a mechanism by which erroneous images can be removed or
replaced?

Anyway, hope you like.

[Nevado] PointWriter 1.2: Screenshot nr. 4 [4216 days 23 hours and 13 minutes ago]

Sat, 20 Sep 2014 12:00:01 GMT

Using the image tracing option in PointWriter 1.2.

[Nevado] Re: PointWriter: Screenshot nr. 3 [4223 days 16 hours and 43 minutes ago]

Sat, 13 Sep 2014 18:30:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 13.09.2014 09:44, schrieb Nevado:
> > Using the "Work in Back" option in PointWriter (cubic spline).
>
> Definitely looks like a cool tool!

Thanks :-)

[clipka] Re: PointWriter: Screenshot nr. 3 [4223 days 20 hours and 39 minutes ago]

Sat, 13 Sep 2014 14:34:21 GMT

Am 13.09.2014 09:44, schrieb Nevado:
> Using the "Work in Back" option in PointWriter (cubic spline).

Definitely looks like a cool tool!

[Nevado] PointWriter: Screenshot nr. 3 [4224 days 3 hours and 28 minutes ago]

Sat, 13 Sep 2014 07:45:01 GMT

Using the "Work in Back" option in PointWriter (cubic spline).

[Nevado] PointWriter: Screenshot nr. 2 [4224 days 3 hours and 28 minutes ago]

Sat, 13 Sep 2014 07:45:01 GMT

Using the 'Work in Back' option in PointWriter (linear splines).

[Nevado] PointWriter: Screenshot nr. 1 [4224 days 3 hours and 28 minutes ago]

Sat, 13 Sep 2014 07:45:01 GMT

Using the image tracing option in PointWriter.

[Lars R ] Rock blocks & Tutorial [4366 days 20 hours and 22 minutes ago]

Wed, 23 Apr 2014 14:51:04 GMT

I found a nice Povray Tutorial with interesting image examples. It is in
German, but I think most parts can be understand also by Non-German
people, e.g:

http://www.f-lohmueller.de/pov_tut/tex/tex_651d.htm

[William F Pokorny] Method for making df3 media ghosts. [4581 days 11 hours and 34 minutes ago]

Fri, 20 Sep 2013 23:38:26 GMT

Posting tarball tutorial example on the media method used to create the 
Halloween ghost image.

Bill P.

[Cousin Ricky] Spherical Law of Cosines [4604 days 9 hours and 3 minutes ago]

Thu, 29 Aug 2013 02:10:01 GMT

For all you hand-coded CSG fanatics.

[Bald Eagle] Trace Example [4635 days 3 hours and 23 minutes ago]

Mon, 29 Jul 2013 07:50:01 GMT

I've seen a lot of requests for explanations and/or tutorials on individual
Scene Description Language (SDL) commands.  Either the manual is short on
illuminating details, or the examples that are given don't really clarify the
use of the command.

I thought it would be good to post an example of what I think is a useful
example.

It's a rough prototype, and my POV skills are rudimentary, but I think it gets
the point across.  I'd like to write something like this for all of the
commands, and have the entire scene description unioned and able to be called
from a .ini file.  "Help.ini"   Then, I could just keep appending tutorial
examples to the file, and from within a scene I'm working on, issue the command:
Help (command) to paste in the scene description for immediate rendering.
Probably take a macro to do this.

Anyway, hope you like it.
Any comments are welcome, including improvements to my code, the image
composition, and anything trace ( ) can be used for that I left out.

Sorry the text looks like that.
Run the file for additional programmatic goodies I was unable to include in the
graphic due to a bug with using vstr ( ) with the text command.


// Persistence of Vision Ray Tracer Scene Description File
// File: Help.inc
// Vers: 3.6
// Desc: Illustration of trace ( ) function
// Date: 07/29/2013
// Auth: Bald Eagle
//

#version 3.6;
#include "colors.inc"   // Standard Color definitions
#include "textures.inc"   // Standard Texture definitions
#include "functions.inc"  // internal functions usable in user defined functions
#include "math.inc"
#include"strings.inc"

camera { orthographic location <1.0, 6, -10.0> up y*15 right x*15 look_at <1.0,
4.0,  0.0> }
// This is a VERY confusing camera type to use!

sky_sphere {
   pigment {
     gradient y
      color_map {
        [0.0 rgb <0.6,0.7,1.0>]
        [0.8 rgb <0.2,0.3,0.9>]
      }
   }
}

light_source { <0, 0, 0> color rgb <1, 1, 1> translate <-20, 20, -30>}
global_settings{ radiosity { recursion_limit 4 } }
//#########################################################################################################

#declare Left = -6.2;
#declare Text_size = 0.5;
#declare Vertical_spacing = 0.6;
#declare Text_color = texture { pigment{rgb 0.8} finish{reflection 0.05 phong 1}
};
#declare Line = 11;
text { ttf "arial.ttf" "POV-Ray trace ( ) function" 0.01, 0 scale Text_size
translate <Left, Line, 0> pigment {Black}}
#declare Line = Line - Vertical_spacing;
text { ttf "arial.ttf" "trace (Object, Measure_from, -Measure_from +
Measure_towards)" 0.01, 0 scale Text_size*0.8  scale y*1.5 pigment {Black}
translate <Left, Line, 0> }
#declare Line = Line - Vertical_spacing;
text { ttf "arial.ttf" "Trace sends a ray from top blue dot towards bottom blue
dot." 0.01, 0 pigment {Yellow} scale Text_size translate <Left, Line, 0> }
#declare Line = Line - Vertical_spacing;
text { ttf "arial.ttf" "If trace ray misses the Object ( ) then it returns <0,
0, 0>." 0.01, 0 pigment {Black} scale Text_size translate <Left, Line, 0> }
#declare Line = Line - Vertical_spacing;
text { ttf "arial.ttf" "If trace ray hits the Object ( ) then it returns the
intersection point." 0.01, 0 scale Text_size pigment {Green*1.5} translate
<Left, Line, 0> }
#declare Line = Line - Vertical_spacing;
text { ttf "arial.ttf" "(Green spheres)" 0.01, 0 scale Text_size pigment
{Green*1.5} translate <Left, Line, 0> }
#declare Line = Line - Vertical_spacing;
text { ttf "arial.ttf" "When an optional vector is added, (initially declared as
<0, 0, 0>)" 0.01, 0 scale Text_size pigment {Green*1.5} translate <Left, Line,
0> }
#declare Line = Line - Vertical_spacing;
text { ttf "arial.ttf" "trace returns the intersection point AND the vector
(Green arrows)" 0.01, 0 scale Text_size pigment {Green*1.5} translate <Left,
Line, 0> }
#declare Line = Line - Vertical_spacing;
text { ttf "arial.ttf" "that is normal to the Object's surface (Green discs) at
the intersection point. " 0.01, 0 scale Text_size pigment {Green*1.5} translate
<Left, Line, 0> }
#declare Line = Line - Vertical_spacing;
text { ttf "arial.ttf" "intersection point. (Vector scale = 1)" 0.01, 0 scale
Text_size pigment {Green*1.5} translate <Left, Line, 0> }
#declare Line = Line - Vertical_spacing;
text { ttf "arial.ttf" "trace (Object, Measure_from, -Measure_from +
Measure_towards, Normal_vector)" 0.01, 0 scale Text_size*0.8 scale y*1.5 pigment
{Black} translate <Left, Line, 0> }
// is there a way to easily mix text colors in a single line or text statement?

#declare Height = 4;
#declare Marker = 0.2;
cylinder {<-10, 0, 0.05>, <10, 0, 0.05>, 0.05 pigment {color Yellow} no_shadow}
cylinder {<-10, Height, 0.05>, <10, Height, 0.05>, 0.05 pigment {color Yellow}
no_shadow}

#declare Object = difference {
 sphere { <0, 0, 0>, 4.1 scale y*0.3 no_shadow}
 cylinder { <2, -4.1*0.4, 0>, <2, 4.1*0.4, 0>, 0.5 texture { pigment {color
White} finish {ambient White}} }
 box { <-0.6, 0, -0.6> <0.6, 3, 0.6> rotate x*70 rotate -z*15 translate <-2,
4*0.2, -2> texture { pigment {color White} finish {ambient White}} }
  }
text { ttf "arial.ttf" "Object ( )" 0.01, 0  translate <-2, 0.5, -4.2>
no_shadow}
// Show objects
object { Object texture { pigment { rgb 0.8} } }
object { cylinder { <2, -4.1*0.4, 0>, <2, 4.1*0.3, 0>, 0.5} scale <0.99, 0,
0.99> texture { pigment { color Green transmit 0.6 } } }
object { box { <-0.59, 0, -0.59> <0.59, 3, 0.59> rotate x*70 rotate -z*15
translate <-2, 4*0.2, -2> } texture { pigment { color Green transmit 0.6 } } }

sphere { <6, 0, 0>, 1 texture { pigment { rgb 0.8} }}
text { ttf "arial.ttf" "   NOT" 0.01, 0  scale Text_size translate <5, 1, -4.2>
no_shadow}
text { ttf "arial.ttf" "  Object" 0.01, 0  scale Text_size translate <5, 0.5,
-4.2> no_shadow}

#debug
"##############################################################################"
#debug "\n"
#debug "###########################  Debugging Information
###########################"
#debug "\n"

#declare Abscissa = -6;
#while (Abscissa <= 8)

#declare Normal_vector = <0, 0, 0>; // Optional vector - initially zeroed out,
trace will redefine to normal vector
#declare Measure_from = <Abscissa, Height, 0>;
sphere {Measure_from, Marker pigment { color Blue}}

#declare Measure_towards =<Abscissa,-2,0>;
sphere {Measure_towards, Marker pigment { color Blue}}

#declare Intersection = trace ( Object, Measure_from,
-Measure_from+Measure_towards, Normal_vector );
// I was unable to display with the text function after converting the vectors
to strings - the output was GARBLED.  Bug?
// So I output all of the values of the vectors in the trace loop to the #debug
stream
#debug concat("X = ", str (Abscissa, 3, 1))
#debug "\n"
#debug concat("  Measure_from = <", vstr(3, Measure_from, ", ", 0,1), ">")
#debug concat("  Measure_towards = <", vstr(3, Measure_towards, ", ", 0,1), ">")
#debug "\n"
#debug concat("  Intersection = <", vstr(3, Intersection, ", ", 0,1), ">")
#debug concat("  Normal_vector = <", vstr(3, Normal_vector, ", ", 0,1), ">")
#debug "\n"

#if ( vlength ( Normal_vector ) !=0 )
        cylinder { Intersection+<0,0.5,0>, Measure_from, Marker/5 texture {
pigment {color Blue} } }
        cone { Intersection, 0, Intersection+<0,0.5,0>, Marker/2 texture {
pigment {color Blue} } }
        cylinder { Intersection, Intersection+Normal_vector, Marker/4 texture {
pigment {color Green} } }
        sphere {Intersection, Marker pigment { color Green} no_shadow}
        cone { Intersection+Normal_vector, Marker/2,
Intersection+Normal_vector*1.5, 0 texture { pigment {color Green} } }
        cylinder { <0, 0, 0>, Normal_vector*0.05, 0.5 translate Intersection
texture { pigment {color Green} } }

#else
        cylinder {<Abscissa, Height,0>, Measure_towards, Marker/5 texture {
pigment {color Black}} no_shadow}
        cone { Measure_towards, 0, Measure_towards+<0,0.5,0>, Marker/2 texture {
pigment {color Black} }}
        text { ttf "arial.ttf" "X" 0.01, 0 translate <Abscissa-0.3, Height/2-.3,
0> texture { pigment {color Black} }}

#end  // end if / else
#declare Abscissa = Abscissa+2;  // increment loop
#end  // end while loop

text { ttf "arial.ttf" "illustration by user Bald Eagle  news.povray.org" 0.01,
0  scale Text_size translate <-2.2, -2.5, -4.2> texture { pigment {color Black}
} no_shadow}

// END OF SCENE DESCRIPTION

[Thomas de Groot] Re: Guidelines for City Builders - AKA Gancaloon... [5077 days and 12 minutes ago]

Sun, 13 May 2012 11:00:47 GMT

Version #2 of the tutorial, now called *Guidelines for City Builders*.

Thomas

[Thomas de Groot] Re: Gancaloon Making Of [5097 days 2 hours and 45 minutes ago]

Mon, 23 Apr 2012 08:28:07 GMT

On 23-4-2012 10:16, Paolo Gibellini wrote:
>  >Thomas de Groot on date 20/04/2012 10.23 wrote:
>> This is the Making Of description of my Gancaloon landscape. See p.b.i.
>>
>> Thomas
> A really very nice article, thank you,
> ;-)
> Paolo

My pleasure.

I shall probably make updates in the near future as I am working on 
alternative and additional possibilities. I shall post a notice when 
that happens.

Thomas

[Paolo Gibellini] Re: Gancaloon Making Of [5097 days 2 hours and 57 minutes ago]

Mon, 23 Apr 2012 08:16:05 GMT

>Thomas de Groot  on date 20/04/2012 10.23 wrote:
> This is the Making Of description of my Gancaloon landscape. See p.b.i.
>
> Thomas
A really very nice article, thank you,
;-)
Paolo

[D103] Re: Gancaloon Making Of [5100 days 1 hour and 33 minutes ago]

Fri, 20 Apr 2012 09:40:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> This is the Making Of description of my Gancaloon landscape. See p.b.i.
>
> Thomas

Actually, while I'm concentrating on my cloud map macros, I find this very
interesting. :) When I get the chance I'll be happy to study it in more detail.
Thanks for posting. :)

Regards,
D103

[Thomas de Groot] Gancaloon Making Of [5100 days 2 hours and 49 minutes ago]

Fri, 20 Apr 2012 08:24:19 GMT

This is the Making Of description of my Gancaloon landscape. See p.b.i.

Thomas

[Nekar Xenos] Re: TerraPOV - Sky system - Atmosphere - Part4, ... [5499 days 23 hours and 15 minutes ago]

Thu, 17 Mar 2011 11:57:45 GMT

On Mon, 28 Feb 2011 14:16:02 +0200, James <vis period optima amount gmail  
dot <"com>"> wrote:

> "Bruno Cabasson" <bru### [at] cabassoncom> wrote:
>> Hello crazy people who continue to read me! However I am happy you are
>> here.
>
> Hello there. I'm new to the group but have followed your TerraPOV  
> articles with
> interest. I don't know if TerraPOV is still a current project, so I  
> borrowed
> your most recently posted code and did some test renders with different
> environments. Hopefully I'm not rediscovering the wheel.
>
> The attached scene was traced from the surface of the planet at 2m  
> elevation
> facing sunwards: heading zero and sun elevation of -1 degree. I'm unsure  
> if this
> shows that TerraPOV is working or if it's a 'feature' of it. The scene  
> is your
> code with a cloud sphere at 5km altitude and a textured moon (true  
> scale) at a
> 15 earth radii distance.
>
> Test renders from satellite altitude look visually correct when compared  
> with
> NASA orbital images so your code seems quite accurate so far.
>
> Thanks.
> j.
>

I think there might be a hole in your planet if it is a mesh or an  
isosurface. It could help to put a black sphere inside your planet that is  
just a little bit smaller than your planet.

-- 
-Nekar Xenos-

[James] Re: TerraPOV - Sky system - Atmosphere - Part4, ... [5516 days 22 hours and 53 minutes ago]

Mon, 28 Feb 2011 12:20:01 GMT

"Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> Hello crazy people who continue to read me! However I am happy you are
> here.

Hello there. I'm new to the group but have followed your TerraPOV articles with
interest. I don't know if TerraPOV is still a current project, so I borrowed
your most recently posted code and did some test renders with different
environments. Hopefully I'm not rediscovering the wheel.

The attached scene was traced from the surface of the planet at 2m elevation
facing sunwards: heading zero and sun elevation of -1 degree. I'm unsure if this
shows that TerraPOV is working or if it's a 'feature' of it. The scene is your
code with a cloud sphere at 5km altitude and a textured moon (true scale) at a
15 earth radii distance.

Test renders from satellite altitude look visually correct when compared with
NASA orbital images so your code seems quite accurate so far.

Thanks.
j.

[DANSHOE] Shoemaster Creative QS 10.4 [5653 days 14 hours and 33 minutes ago]

Thu, 14 Oct 2010 20:40:00 GMT

Im an user of the software shoemaster Version 10.
I use the Pov Ray to render my designs.
but i have some problems doing it. beacuse. some times i try to open a file and
a message box apears "Eacces Violation:Eacces Violation". and don't allow me
render nothing...
 if someone pliz can help me.. i'll be very thankful.

[SharkD] Render for polarized glasses [5781 days 8 hours and 29 minutes ago]

Wed, 9 Jun 2010 02:43:48 GMT

I wrote a tutorial a long time ago on how to render scenes for polarized 
glasses:

http://www.ldraw.org/Article528.html

It deals specifically with LDraw models, but should be easy to apply to 
other contexts as well.

I was perusing the wiki so I decided to also link to it from the "How 
To" page.


-- 
http://isometricland.com

[Thomas de Groot] Re: Check(er) Your Gamma [5929 days 19 hours and 15 minutes ago]

Mon, 11 Jan 2010 15:57:46 GMT

Following this test, to all who find my images washed out, I am glad to say 
that my hardware and software are properly calibrated  :-)

Thanks Cristoph.

Thomas

[clipka] POV-Ray Voodoo #511: Radiosity brightness setting [5979 days 21 hours and 1 minute ago]

Sun, 22 Nov 2009 14:11:53 GMT

For all those who - just like me - have wondered what the most realistic 
setting for the radiosity "brightness" parameter should be:

After having done some experimenting and comparison with MCPov (see 
povray.unofficial.patches), I can conclude with confidence:

   "brightness 1.0" is absolutely right.

With "recursion_limit 1", it may even make sense to increase the 
brightness a bit above 1.0, to compensate for the "missing" multi-bounce 
diffuse illumination.

Any dissimilarities with MCPov results are pretty likely due to an error 
in MCPov (which gets the brightness wrong by a factor of 2), and any 
overly bright materials are pretty likely to be due to gamma issues, bad 
material settings, or inferior lighting setup. Or possibly even other 
bugs in conjunction with radiosity - but the default brightness value is 
absolutely right.

[clipka] Re: Check(er) Your Gamma [5995 days 12 hours and 17 minutes ago]

Fri, 6 Nov 2009 22:55:31 GMT

SharkD schrieb:
> On 11/6/2009 12:49 AM, clipka wrote:
>> I'd recommend to just skip the brightness and contrast stuff (you should
>> have done that already when calibrating the display), and just do the
>> eyes-squinting part and following.
> 
> Except that now I'm confused and can't remember *which* eye-squinting 
> instructions I'm supposed to follow...
> 
> Is there no tool where I can just click a button and say, "Fix my gamma!"?

I wish there was. However, as far as POV-Ray is concerned, the next beta 
should provide proper gamma handling almost "out of the box".

[Ive] Re: Check(er) Your Gamma [5995 days 20 hours and 18 minutes ago]

Fri, 6 Nov 2009 14:54:46 GMT

clipka wrote:
> To counterbalance it a bit: It does have flaws :-P What bothers me most 
> is that whenever I re-render any image file in whatever directory IC is 
> presently in, any subsequent attempt to skip to the next or previous 
> image - or even just choose "reopen image" - makes it jump to the first 
> image in the directory instead, which I think makes that "reopen image" 
> business pretty much pointless... (using version 1.0.10 here)
> 

Good to know, guess I messed things up when wrapping OS specific 
functionality (like directory monitoring) to prepare for a future 
cross-platform GUI. IC is in fact just the graphical front-end for a 
professional image processing library and as such basically just a hobby 
of mine and I have quite limited time for testing it. So I'm quite 
thankful for all feedback from users, especially about things that do 
not work as expected.

> 
> (I wonder why nobody ever bothered to add a "dither" switch to 
> POV-Ray... or did I miss something?)

I *think* there was once a dither option for color palette based image 
file formats like GIF ;)

-Ive

[SharkD] Re: Check(er) Your Gamma [5995 days 20 hours and 25 minutes ago]

Fri, 6 Nov 2009 14:48:05 GMT

On 11/6/2009 12:49 AM, clipka wrote:
> I'd recommend to just skip the brightness and contrast stuff (you should
> have done that already when calibrating the display), and just do the
> eyes-squinting part and following.

Except that now I'm confused and can't remember *which* eye-squinting 
instructions I'm supposed to follow...

Is there no tool where I can just click a button and say, "Fix my gamma!"?

Mike

[clipka] Re: Check(er) Your Gamma [5995 days 21 hours and 8 minutes ago]

Fri, 6 Nov 2009 14:04:54 GMT

Edouard schrieb:

> And I'd like to say that any frustration that leaks through in my posts about
> gamma is in no way directed at you - you are in fact the person who is trying to
> fix the mess POV is in now, and for that I am genuinely grateful. Any
> frustration is my own issues about what a mess the entire computer industry has
> gotten itself into, and how near impossible it is to properly fix the situation
> without breaking most existing content (which in turn causes many users to want
> to stick to their existing broken content, as they neither understand, nor have
> the time to fix it themselves).

Let me assure you in turn that the opposition I exhibit in my postings 
is solely targeted at that frustration. Even while I'm arguing how 
POV-Ray is doing nothing wrong, I still take your postings as an 
incentive to ponder how POV-Ray can be made even better.


>>> I can see it's displayed correctly. That's great. But you've taken the decision
>>> that the file should be output with that display gamma baked in, and that's not
>>> something that's desirable under all circumstances (like, for example, any
>>> manipulation of the image afterwards).
>> No, this is absolutely the proper way to do it with PNG image files, as
>> per the PNG file specification.
> 
> I agree that you've implemented one possible implementation, in complete
> accordance with the PNG spec. I don't think that it is the only way to implement
> it however.

Just to get things straight, I'd like to point out that it was /not me/ 
who implemented the PNG output file gamma handling. As a matter of fact, 
absolutely /nothing/ regarding gamma you see in POV-Ray 3.4.0.beta.34 is 
my work. I will take neither blame nor praise for it. While I did some 
coding for input file gamma handling, those changes are still pending 
release.


>>>> Note that Photoshop lies to you about brightness (and so do your eyes).
>>>> Photoshop also uses physically wrong math when blurring images (at least
>>>> the old version I own does).
>>> No - Photoshop is doing a sensible thing, and that's to work in linear space
>>> (exactly the same way that POV does). Photoshop is a production tool, and having
>>> gamma applied half way through your workflow will just screw everything up.
>> No, that's exactly the problem: Photoshop is /not/ working in linear
>> space - it happens to work in /whatever/ space the image happens to be
>> encoded in.
> 
> No - Photoshop has the notion of a workspace profile - the profile that you are
> manipulating the image in. It can differ from the image's profile, and it can
> differ from the output profile. In a production workflow, you might not even
> know the final output profile, or there may be several (e.g. it needs to be
> displayed on a web page, put in a video to be broadcast, and printed in a
> magazine). That's the point of having colour profiles attached to your content.

Then it all boils down to you picking the right working profile, no? 
Photoshop should then get along with whatever the input file gamma or 
color profile may be - and in the absence of such a profile should 
assume something sane, like sRGB.

 From your griping I must conclude that this is not the case however, so 
Photoshop must be doing something wrong in that workflow.


>> As linear encoding gives a great deal of precision loss with
>> low-brightness values (at the benefit of some precision gain with
>> high-brightness values, where it's not really needed), thereby leading
>> to color banding in dark areas, linear encoding is /not/ suited for
>> 8-bit color depth images.
> 
> This is a separate argument that has unfortunately conflated with gamma
> correction. Yes, human perception of luminosity is non-linear, but don't mix
> that up with the gamma argument. There are separate ways of dealing with that
> issue

Actually, I'm beginning to prefer speaking of gamma /encoding/. 
Nowadays, the number of serious software still requiring /gamma 
pre-correction/ has drastically diminished.

As a matter of fact, when speaking of PNG files, as per specification 
we're talking about /gamma encoding/ anyway.


 > (and it's 2009 - a 16bit PNG file really isn't a big deal any more...)

There are still a lot of use cases where users will want 8-bit depth 
output, and for such cases gamma encoding is virtually a must. Which in 
turn mandates to default to gamma encoding for 16-bit PNG as well, to 
keep things consistent and the code simple.


>> Sure it is; however, color banding is a bad thing, and therefore 8-bit
>> linear encoded PNG is /not/ an option either.
> 
> Actually I almost always render to a Radience HDR file.

I've seen serious color banding there, too, by the way (I guess 
gradients from pure blue to pastel blue are particularly susceptible). 
While I was all the rage for HDR when I discovered MegaPOV, I now 
definitely prefer OpenEXR.

 > My opinion is that an
> 8bit image isn't suited for anything other than final display. All my workflow
> should be in HDR, or, as a last resort, 16bit. Otherwise most operations you
> perform on the image will lead to noticeable degradation, whether you have a
> linear or non-linear 8bit image.

If your workflow starts with HDR anyway, then why do you worry about 
PNG? :-P


> As a final output image, linear is fine, surprisingly enough. Photoshop, for
> example, will dither images when you apply a linear profile to an 8bit image -
> you can't tell the difference, as that leaves no visible banding when displayed.

As a side note, older versions of Photoshop, like 6.0 (and hobbyists may 
still have those in use to cut costs... at least I for one do) did /not/ 
support such fancy things as HDR or 16-bit PNG.


> What do we need for the ICC profile? Gamma - which we have. RGB values - which
> are implied in the code (otherwise things like dispersion wouldn't work).

Let's rephrase that: "(otherwise things like dispersion would give 
physically inaccurate results)" - which is exactly what they do.

There is presently /no/ piece of code in all of POV-Ray that is really 
color-space-aware.

 > And a
> whitepoint - which we don't explicitly have, but I think you've more or less
> decided that we are working in sRGB space, so that implies D65.

Though sRGB may likely become the default color space to interface to 
the outside world (and will for sure be the first to get some 
rudimentary support, by implementing its transfer function as an 
alternative to a power-law gamma curve), I'm pretty much sure that it 
will /not/ be the one to use internally. I don't think all parts of 
POV-Ray are ready to properly handle negative color values, so some 
wide-gamut color space should definitely be preferred.

If I'm asked, I'd personally prefer to use a spectral color model, using 
at least 4 (better yet 6) distinct bands. With intersection tests 
constituting the heaviest workload, and modern compilers and CPUs being 
good at vectorization optimization, I don't think it will impact 
performance too much.

> If we have those, then we have all we need for an ICC profile.

As you see, however, we don't have all of those yet. We're getting a 
well-defined gamma, and that's a start, but everything else is still 
wanting.

> Plus I'd love a future version of POV to support different profiles. People
> already use this when they write scenes with Jaime Vives Piqueres' LightSys
> macros. Imagine if the information about the colourspace and illuminant from
> those macros could simply be reflected into the output file.

Yes, that would be great. And once we do have proper color management, 
it shouldn't be much of a problem to do color space transformations. But 
alas! we're not there yet.

>> And don't complain about any color banding you may observe: You're
>> asking for it.
> 
> As I said above, I don't get any banding when I use a tool like Photoshop to
> apply a linear profile to an 8bit image.

But that again implies that the POV-Ray output you're working with /is/ 
using gamma encoding, doesn't it?

>> (BTW, to scale a gamma-encoded image without messing up the colors, I
>> can highly recommend IC. It does properly convert the image to linear
>> color space before resampling.)
> 
> If I assign a linear profile to the image, then every graphics program scales
> the image correctly. That really does seem like a better outcome to me...

You were reporting problems with that workflow though, didn't you?


Well, maybe I know too little of color profiles, and totally 
misunderstand the term "linear profile". Dunno.

[clipka] Re: Check(er) Your Gamma [5995 days 22 hours and 24 minutes ago]

Fri, 6 Nov 2009 12:48:23 GMT

Ive schrieb:

> Thanks for the advertising ;)

To counterbalance it a bit: It does have flaws :-P What bothers me most 
is that whenever I re-render any image file in whatever directory IC is 
presently in, any subsequent attempt to skip to the next or previous 
image - or even just choose "reopen image" - makes it jump to the first 
image in the directory instead, which I think makes that "reopen image" 
business pretty much pointless... (using version 1.0.10 here)

Still, it has definitely become my favorite tool for "low-level" 
post-processing, such as resizing, color correcting, and conveting 
between image file formats. And to get rid of color banding in some 
exceptionally problematic scenes: Rendering to OpenEXR and then 
converting in IC to whatever file format I really want /always/ does the 
job.

(I wonder why nobody ever bothered to add a "dither" switch to 
POV-Ray... or did I miss something?)

[Ive] Re: Check(er) Your Gamma [5996 days and 58 minutes ago]

Fri, 6 Nov 2009 10:15:08 GMT

Edouard wrote:
> Ive <"ive### [at] lilysoftorg"> wrote:
>> A quick note about Photoshop and it's PNG support:
>>
>> I'm using Photoshop since version 4.0 and currently CS3 (still not sure
>> about updating to CS4) and every version had broken PNG support in one
>> way or another. Usually the gamma and sRGB chunk was ignored, some
>> version did completely mess up 16 bps images and CS3 writes colorimetric
>> chunks (color primaries and whitepoint) but 'forgets' to add the gamma
>> chunk (and it claims when saving to PNG that this file format does not
>> support any metadata - a plain lie because PNG even supports XMP, the
>> way that is favored by Adobe itself for storing metadata).
>> Given the long time and that PNG is a quite simple format it seems not
>> that far fetched that PNG support is broken deliberately - as some
>> people claim - but I fail to see the reason behind it.
> 
> Yes - it should write the gamma chunk when adding  profile. It says so in the
> spec.
> 
> I think PNG has never been a "pro" format in terms of their production
> customers, so Adobe hasn't given it the love. I don't think it's anything more
> sinister than that.
> 
> Photoshop 4? Pah - luxury! I started using version 2.0 - it didn't even have
> layers!

Photoshop 2.0? Pah, in fact I started with Aldus Photo-Styler. Aldus was 
later 'consumed' by Adobe (a company that had nothing to do with image 
processing at this time) and Photoshop 1.0 was nothing but the Aldus 
Photo-Styler with a new name. I had some break in my life back then and 
did start to make a living as musician but returned to IT business when 
Photoshop 4.0 was out.
And BTW Aldus did also maintain the TIFF specification and so it 
happened that the TIFF specs are now 'owned' by Adobe and the latest 
revision 6.0 is from 1992 (!!!) even if Adobe has greatly extended the 
format simply by adding lots of new features regarding TIFF into 
Photoshop...

-Ive

[Edouard] Re: Check(er) Your Gamma [5996 days 1 hour and 48 minutes ago]

Fri, 6 Nov 2009 09:25:01 GMT

Ive <"ive### [at] lilysoftorg"> wrote:
> A quick note about Photoshop and it's PNG support:
>
> I'm using Photoshop since version 4.0 and currently CS3 (still not sure
> about updating to CS4) and every version had broken PNG support in one
> way or another. Usually the gamma and sRGB chunk was ignored, some
> version did completely mess up 16 bps images and CS3 writes colorimetric
> chunks (color primaries and whitepoint) but 'forgets' to add the gamma
> chunk (and it claims when saving to PNG that this file format does not
> support any metadata - a plain lie because PNG even supports XMP, the
> way that is favored by Adobe itself for storing metadata).
> Given the long time and that PNG is a quite simple format it seems not
> that far fetched that PNG support is broken deliberately - as some
> people claim - but I fail to see the reason behind it.

Yes - it should write the gamma chunk when adding  profile. It says so in the
spec.

I think PNG has never been a "pro" format in terms of their production
customers, so Adobe hasn't given it the love. I don't think it's anything more
sinister than that.

Photoshop 4? Pah - luxury! I started using version 2.0 - it didn't even have
layers!

> clipka wrote:
> |...]
> > (BTW, to scale a gamma-encoded image without messing up the colors, I
> > can highly recommend IC. It does properly convert the image to linear
> > color space before resampling.)
>
> Thanks for the advertising ;)

When's the Mac version coming out? :-)

> -Ive

Cheers,
Edouard.

[Edouard] Re: Check(er) Your Gamma [5996 days 1 hour and 53 minutes ago]

Fri, 6 Nov 2009 09:20:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Edouard schrieb:

(Deep breath)

OK. Let me start this again...

Let me, in fact, start by saying that you have done a truly outstanding job with
POV 3.7, and I (and I'm certain, many others) are hugely grateful for all the
hard work you've done - both in the fun parts (like SSLT) and the, I imagine,
tedious and/or frustrating parts like fixing radiosity, and, of course, trying
to fix the gamma issues. Without your work I'd still be using Megapov, and
wouldn't have even been able to write the DF3 proximity macros (as a good
example; they rely on your binary writing patch for 3.7).

And I'd like to say that any frustration that leaks through in my posts about
gamma is in no way directed at you - you are in fact the person who is trying to
fix the mess POV is in now, and for that I am genuinely grateful. Any
frustration is my own issues about what a mess the entire computer industry has
gotten itself into, and how near impossible it is to properly fix the situation
without breaking most existing content (which in turn causes many users to want
to stick to their existing broken content, as they neither understand, nor have
the time to fix it themselves).

Anyway:

> > I can see it's displayed correctly. That's great. But you've taken the decision
> > that the file should be output with that display gamma baked in, and that's not
> > something that's desirable under all circumstances (like, for example, any
> > manipulation of the image afterwards).
>
> No, this is absolutely the proper way to do it with PNG image files, as
> per the PNG file specification.

I agree that you've implemented one possible implementation, in complete
accordance with the PNG spec. I don't think that it is the only way to implement
it however.

Baking the gamma in, and using only the gAMA chunk is certainly valid, but there
are other ways that are more advanced, and allow users, programs and OSs to make
better choices and use of the image data.

But, as I've said, baking in the gamma is a good solution for users who want to
render an image, and then do nothing else but look at the results. So what
you've done is good.

Or, in my opinion, good for that scenario. There are other scenarios (or
use-cases) for which that isn't such a good option. So I'm not saying that your
implementation choice is wrong, just that it isn't suited for all use-cases.

There's another entire set of use-cases where it is desirable for the output
file to have linear response. And luckily PNG (and other formats) can quite
easily support this too. Unfortunately the gAMA chunk by itself isn't a good way
to implement this for PNG. ICC profiles are the best route to making this work
across the widest range of platforms and applications.

There are still other scenarios where a full ICC profile would be best, even
when not using linear gamma. Any content that is going into a professional
production environment more or less must use the facilities of a full colour
management system, and ICC profiles are the way to go.

To recap - there is no right way or wrong way, but there are a number use-cases,
and (unfortunately) they require different types of PNG file. Many of the
use-cases collapse down to 2 or 3 different PNG files, so it's actually not that
bad.

> >> Note that Photoshop lies to you about brightness (and so do your eyes).
> >> Photoshop also uses physically wrong math when blurring images (at least
> >> the old version I own does).
> >
> > No - Photoshop is doing a sensible thing, and that's to work in linear space
> > (exactly the same way that POV does). Photoshop is a production tool, and having
> > gamma applied half way through your workflow will just screw everything up.
>
> No, that's exactly the problem: Photoshop is /not/ working in linear
> space - it happens to work in /whatever/ space the image happens to be
> encoded in.

No - Photoshop has the notion of a workspace profile - the profile that you are
manipulating the image in. It can differ from the image's profile, and it can
differ from the output profile. In a production workflow, you might not even
know the final output profile, or there may be several (e.g. it needs to be
displayed on a web page, put in a video to be broadcast, and printed in a
magazine). That's the point of having colour profiles attached to your content.

When I load a PNG file with a linear gamma ICC profile, Photoshop asks me
whether I want to work in the documents colourspace, or convert the image to my
working colourspace. This is a good thing, as the answer depends on what I'm
actually doing with the image. I can also change my working colourspace to any
profile including linear gamma. Also, good.

> As linear encoding gives a great deal of precision loss with
> low-brightness values (at the benefit of some precision gain with
> high-brightness values, where it's not really needed), thereby leading
> to color banding in dark areas, linear encoding is /not/ suited for
> 8-bit color depth images.

This is a separate argument that has unfortunately conflated with gamma
correction. Yes, human perception of luminosity is non-linear, but don't mix
that up with the gamma argument. There are separate ways of dealing with that
issue (and it's 2009 - a 16bit PNG file really isn't a big deal any more...)

> >> The /physical/ blurring by squinting your eyes, however, does indeed
> >> comprise a physically correct "computation" of (black+white)/2 (taking a
> >> few steps back may do the same job, and some people may just need to
> >> take off their glasses), which obviously gives you a grey of /truly/
> >> half the white value (*), which you can then visually compare to the
> >> grey of /allegedly/ half the white value.
> >
> > I'm arguing that for a digital artist who is using POV as part of their
> > workflow, having tools like Photoshop's blur give identical "output" to what you
> > see when you do the "squint" method, is a good thing.
>
> Sure it is; however, color banding is a bad thing, and therefore 8-bit
> linear encoded PNG is /not/ an option either.

Actually I almost always render to a Radience HDR file. My opinion is that an
8bit image isn't suited for anything other than final display. All my workflow
should be in HDR, or, as a last resort, 16bit. Otherwise most operations you
perform on the image will lead to noticeable degradation, whether you have a
linear or non-linear 8bit image.

As a final output image, linear is fine, surprisingly enough. Photoshop, for
example, will dither images when you apply a linear profile to an 8bit image -
you can't tell the difference, as that leaves no visible banding when displayed.

> > I'm sure lots of people will be happy to bake the gamma into their file if they
> > are producing "final" images with POV, and not intending to post-process them in
> > any way (as long as they know scaling the image is then a no-no). But there are
> > plenty of others who use POV in a workflow that includes scaling and other post
> > processing, and we would be better suited with having linear ICC profiles
> > attached to the images. There is no "right" way, it all depends on how the user
> > is intending to use the image.
>
> Feel free to use "File_Gamma=1.0" on the output file, which does exactly
> what you demand - except that it doesn't attach an ICC profile, but
> "only" a gAMA chunk, because an ICC profile would inevitably have to be
> a lie (POV-Ray is presently gamma- but not color space-aware). It's a
> shame that Photoshop 6.0 fails to support the gAMA chunk, but that's not
> POV-Ray's fault. And you can actually work around the problem by
> manually assigning your favorite linear ICC profile to the image /after/
> you have loaded it into Photoshop.

What do we need for the ICC profile? Gamma - which we have. RGB values - which
are implied in the code (otherwise things like dispersion wouldn't work). And a
whitepoint - which we don't explicitly have, but I think you've more or less
decided that we are working in sRGB space, so that implies D65.

If we have those, then we have all we need for an ICC profile.

And once you have ICC profiles, then it becomes trivial to encode the file in
sRGB gamma, linear gamma, or even some custom gamma.

Plus I'd love a future version of POV to support different profiles. People
already use this when they write scenes with Jaime Vives Piqueres' LightSys
macros. Imagine if the information about the colourspace and illuminant from
those macros could simply be reflected into the output file.

> And don't complain about any color banding you may observe: You're
> asking for it.

As I said above, I don't get any banding when I use a tool like Photoshop to
apply a linear profile to an 8bit image. Perhaps there are other tools out there
that don't do as good a job. It's a bit like non-dithered GIF images - they
looked highly posterised. The solution - no-one used a tool that could only
produce posterised images like that.

> (BTW, to scale a gamma-encoded image without messing up the colors, I
> can highly recommend IC. It does properly convert the image to linear
> color space before resampling.)

If I assign a linear profile to the image, then every graphics program scales
the image correctly. That really does seem like a better outcome to me...

Cheers,
Edouard.

[Ive] Re: Check(er) Your Gamma [5996 days 2 hours and 28 minutes ago]

Fri, 6 Nov 2009 08:45:20 GMT

SharkD wrote:
> On 11/5/2009 6:43 PM, clipka wrote:
>> No, that's exactly the problem: Photoshop is /not/ working in linear
>> space - it happens to work in /whatever/ space the image happens to be
>> encoded in.
> 
> I thought that Photoshop always worked in LAB space?
> 
> Mike

Not *always*, e.g. for all kind of affine projections (this includes 
simple resizing) it does not.

-Ive

[Ive] Re: Check(er) Your Gamma [5996 days 2 hours and 28 minutes ago]

Fri, 6 Nov 2009 08:45:11 GMT

A quick note about Photoshop and it's PNG support:

I'm using Photoshop since version 4.0 and currently CS3 (still not sure 
about updating to CS4) and every version had broken PNG support in one 
way or another. Usually the gamma and sRGB chunk was ignored, some 
version did completely mess up 16 bps images and CS3 writes colorimetric 
chunks (color primaries and whitepoint) but 'forgets' to add the gamma 
chunk (and it claims when saving to PNG that this file format does not 
support any metadata - a plain lie because PNG even supports XMP, the 
way that is favored by Adobe itself for storing metadata).
Given the long time and that PNG is a quite simple format it seems not 
that far fetched that PNG support is broken deliberately - as some 
people claim - but I fail to see the reason behind it.

clipka wrote:
|...]
> (BTW, to scale a gamma-encoded image without messing up the colors, I 
> can highly recommend IC. It does properly convert the image to linear 
> color space before resampling.)

Thanks for the advertising ;)

-Ive

[clipka] Re: Check(er) Your Gamma [5996 days 5 hours and 23 minutes ago]

Fri, 6 Nov 2009 05:50:00 GMT

SharkD schrieb:
> On 11/4/2009 11:58 PM, clipka wrote:
>> If you're referring to setting up POV-Ray, then yes: The POV-Ray 3.6
>> instructions how to identify the proper Display_Gamma setting for your
>> system are still valid for 3.7.
> 
> The docs say, "Now, lower the contrast until the alternating white and 
> black bars on the left edge of each column are equal in width." What do 
> they mean?? Which width am I measuring?

Um... I must confess that it's been a while since I last read that 
section of the docs.

I'd recommend to just skip the brightness and contrast stuff (you should 
have done that already when calibrating the display), and just do the 
eyes-squinting part and following.

[SharkD] Re: Check(er) Your Gamma [5996 days 8 hours and 8 minutes ago]

Fri, 6 Nov 2009 03:04:49 GMT

On 11/4/2009 11:58 PM, clipka wrote:
> If you're referring to setting up POV-Ray, then yes: The POV-Ray 3.6
> instructions how to identify the proper Display_Gamma setting for your
> system are still valid for 3.7.

The docs say, "Now, lower the contrast until the alternating white and 
black bars on the left edge of each column are equal in width." What do 
they mean?? Which width am I measuring?

Mike

[SharkD] Re: Check(er) Your Gamma [5996 days 8 hours and 19 minutes ago]

Fri, 6 Nov 2009 02:53:52 GMT

On 11/5/2009 6:43 PM, clipka wrote:
> No, that's exactly the problem: Photoshop is /not/ working in linear
> space - it happens to work in /whatever/ space the image happens to be
> encoded in.

I thought that Photoshop always worked in LAB space?

Mike

[clipka] Re: Check(er) Your Gamma [5996 days 11 hours and 29 minutes ago]

Thu, 5 Nov 2009 23:43:48 GMT

Edouard schrieb:

> I can see it's displayed correctly. That's great. But you've taken the decision
> that the file should be output with that display gamma baked in, and that's not
> something that's desirable under all circumstances (like, for example, any
> manipulation of the image afterwards).

No, this is absolutely the proper way to do it with PNG image files, as 
per the PNG file specification.

>> Note that Photoshop lies to you about brightness (and so do your eyes).
>> Photoshop also uses physically wrong math when blurring images (at least
>> the old version I own does).
> 
> No - Photoshop is doing a sensible thing, and that's to work in linear space
> (exactly the same way that POV does). Photoshop is a production tool, and having
> gamma applied half way through your workflow will just screw everything up.

No, that's exactly the problem: Photoshop is /not/ working in linear 
space - it happens to work in /whatever/ space the image happens to be 
encoded in.

As linear encoding gives a great deal of precision loss with 
low-brightness values (at the benefit of some precision gain with 
high-brightness values, where it's not really needed), thereby leading 
to color banding in dark areas, linear encoding is /not/ suited for 
8-bit color depth images.


>> The /physical/ blurring by squinting your eyes, however, does indeed
>> comprise a physically correct "computation" of (black+white)/2 (taking a
>> few steps back may do the same job, and some people may just need to
>> take off their glasses), which obviously gives you a grey of /truly/
>> half the white value (*), which you can then visually compare to the
>> grey of /allegedly/ half the white value.
> 
> I'm arguing that for a digital artist who is using POV as part of their
> workflow, having tools like Photoshop's blur give identical "output" to what you
> see when you do the "squint" method, is a good thing.

Sure it is; however, color banding is a bad thing, and therefore 8-bit 
linear encoded PNG is /not/ an option either.


> I'm sure lots of people will be happy to bake the gamma into their file if they
> are producing "final" images with POV, and not intending to post-process them in
> any way (as long as they know scaling the image is then a no-no). But there are
> plenty of others who use POV in a workflow that includes scaling and other post
> processing, and we would be better suited with having linear ICC profiles
> attached to the images. There is no "right" way, it all depends on how the user
> is intending to use the image.

Feel free to use "File_Gamma=1.0" on the output file, which does exactly 
what you demand - except that it doesn't attach an ICC profile, but 
"only" a gAMA chunk, because an ICC profile would inevitably have to be 
a lie (POV-Ray is presently gamma- but not color space-aware). It's a 
shame that Photoshop 6.0 fails to support the gAMA chunk, but that's not 
POV-Ray's fault. And you can actually work around the problem by 
manually assigning your favorite linear ICC profile to the image /after/ 
you have loaded it into Photoshop.

And don't complain about any color banding you may observe: You're 
asking for it.


(BTW, to scale a gamma-encoded image without messing up the colors, I 
can highly recommend IC. It does properly convert the image to linear 
color space before resampling.)

[Edouard] Re: Check(er) Your Gamma [5996 days 13 hours and 58 minutes ago]

Thu, 5 Nov 2009 21:15:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Edouard schrieb:
>
> >> (B) If (after fixing (A)) you see checkering in the preview window
> >> and/or the output file when rendering the scene file below, then your
> >> Display_Gamma (POV-Ray 3.6 and 3.7) and/or File_Gamma setting (POV-Ray
> >> 3.7 only), respectively, is wrong.
> >
> > Well that produces a broken file for me if I choose to output a PNG file (i.e.
> > the gray value isn't half the white value). HDR output works though (as I assume
> > it's in linear space).
>
> Careful!
>
> How did you /check/ that the gray value isn't "half the white value"?
>
> If you squint your eyes to "blur" the black-and-white-striped squares,
> and it then /appears/ to have the same brightness as the gray value,
> then that gray value /is/ half as bright as the white.

I can see it's displayed correctly. That's great. But you've taken the decision
that the file should be output with that display gamma baked in, and that's not
something that's desirable under all circumstances (like, for example, any
manipulation of the image afterwards).

> Note that Photoshop lies to you about brightness (and so do your eyes).
> Photoshop also uses physically wrong math when blurring images (at least
> the old version I own does).

No - Photoshop is doing a sensible thing, and that's to work in linear space
(exactly the same way that POV does). Photoshop is a production tool, and having
gamma applied half way through your workflow will just screw everything up.

If you assign a linear profile to the image (which you started to be able to do
in Photoshop 6), then Photoshop not only displayed the image correctly, but all
operations (like blurring it) also work exactly as you would want. I've attached
an image with a linear profile and one half blurred as an example.

Scaling the image also fails if there isn't a linear profile attached, and lots
of users here like to scale their final images down and don't really consider
that post-processing. Baked-in gamma makes that work incorrectly.

> The /physical/ blurring by squinting your eyes, however, does indeed
> comprise a physically correct "computation" of (black+white)/2 (taking a
> few steps back may do the same job, and some people may just need to
> take off their glasses), which obviously gives you a grey of /truly/
> half the white value (*), which you can then visually compare to the
> grey of /allegedly/ half the white value.

I'm arguing that for a digital artist who is using POV as part of their
workflow, having tools like Photoshop's blur give identical "output" to what you
see when you do the "squint" method, is a good thing.

I'm sure lots of people will be happy to bake the gamma into their file if they
are producing "final" images with POV, and not intending to post-process them in
any way (as long as they know scaling the image is then a no-no). But there are
plenty of others who use POV in a workflow that includes scaling and other post
processing, and we would be better suited with having linear ICC profiles
attached to the images. There is no "right" way, it all depends on how the user
is intending to use the image.

(Well, once ICC support is universal, then I would argue that a linear image
with the correct ICC profile is "right". We're not that far from that are we? On
my Mac, the OS, the browser, and image preview app, and the pro software like
Photoshop all get a linear ICC profiled file right every time...)

Cheers,
Edouard.

[clipka] Re: Check(er) Your Gamma [5996 days 19 hours and 26 minutes ago]

Thu, 5 Nov 2009 15:46:45 GMT

Edouard schrieb:

>> (B) If (after fixing (A)) you see checkering in the preview window
>> and/or the output file when rendering the scene file below, then your
>> Display_Gamma (POV-Ray 3.6 and 3.7) and/or File_Gamma setting (POV-Ray
>> 3.7 only), respectively, is wrong.
> 
> Well that produces a broken file for me if I choose to output a PNG file (i.e.
> the gray value isn't half the white value). HDR output works though (as I assume
> it's in linear space).

Careful!

How did you /check/ that the gray value isn't "half the white value"?

If you squint your eyes to "blur" the black-and-white-striped squares, 
and it then /appears/ to have the same brightness as the gray value, 
then that gray value /is/ half as bright as the white.

Note that Photoshop lies to you about brightness (and so do your eyes). 
Photoshop also uses physically wrong math when blurring images (at least 
the old version I own does).

The /physical/ blurring by squinting your eyes, however, does indeed 
comprise a physically correct "computation" of (black+white)/2 (taking a 
few steps back may do the same job, and some people may just need to 
take off their glasses), which obviously gives you a grey of /truly/ 
half the white value (*), which you can then visually compare to the 
grey of /allegedly/ half the white value.

(* provided you have set your display's black point properly)

[Edouard] Re: Check(er) Your Gamma [5996 days 23 hours and 43 minutes ago]

Thu, 5 Nov 2009 11:30:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> You know your gamma settings are wrong if...
>
> ... you see a chrome sphere on a /checkered/ plane (even if you squint
> your eyes or look from a distance) in this image/scene.
>
> Ideally, the plane should appear in a featureless uniform grey (except
> for some moiree effects near the horizon and maybe in the reflection).
> If instead it appears to show squares of alternating shades of grey,
> something's bogus:
>
> (A) If you see checkering in the attached image file, then your image
> viewing software / operating system / graphics drivers / display
> hardware is poorly calibrated, and you should fix it before proceeding.
>
> (B) If (after fixing (A)) you see checkering in the preview window
> and/or the output file when rendering the scene file below, then your
> Display_Gamma (POV-Ray 3.6 and 3.7) and/or File_Gamma setting (POV-Ray
> 3.7 only), respectively, is wrong.

Well that produces a broken file for me if I choose to output a PNG file (i.e.
the gray value isn't half the white value). HDR output works though (as I assume
it's in linear space).

Cheers,
Edouard.

[clipka] Re: Check(er) Your Gamma [5997 days 6 hours and 15 minutes ago]

Thu, 5 Nov 2009 04:58:17 GMT

SharkD schrieb:

> The instructions for adjusting your display settings are already in the 
> docs, aren't they?

If you're referring to setting up POV-Ray, then yes: The POV-Ray 3.6 
instructions how to identify the proper Display_Gamma setting for your 
system are still valid for 3.7.

If you're referring to setting up your image viewer / operating system / 
  graphics driver / display hardware, you will have to check out the 
respective manuals and/or them interwebs.

Usually your graphics card will have come with /some/ tool to check and 
adjust your display gamma to whatever the operating system typically 
expects, and most image viewers will rely on the operating system and 
drivers for converting from the OS' standard gamma to the display 
hardware gamma.


On a properly calibrated Windows PC, following the instructions to set 
up your Display_Gamma should usually give you a setting of 2.2.

[SharkD] Re: Check(er) Your Gamma [5997 days 6 hours and 58 minutes ago]

Thu, 5 Nov 2009 04:14:54 GMT

On 11/4/2009 9:00 AM, clipka wrote:
> SharkD schrieb:
>> On 11/3/2009 11:27 PM, clipka wrote:
>>> Forgot to attach the image... here it is.
>>
>> I see alternating gray squares. Should I kill myself now?
>
> I wouldn't go as far as that ;-)
>
> It's just that if you share your rendered images and/or scenes (or
> include files that do anything with color or brightness), other people
> will not get what you see. (Unless their system, too, happens to be
> mis-calibrated in the same manner :-))

The instructions for adjusting your display settings are already in the 
docs, aren't they?

Mike

[clipka] Re: Check(er) Your Gamma [5997 days 21 hours and 12 minutes ago]

Wed, 4 Nov 2009 14:01:01 GMT

SharkD schrieb:
> On 11/3/2009 11:27 PM, clipka wrote:
>> Forgot to attach the image... here it is.
> 
> I see alternating gray squares. Should I kill myself now?

I wouldn't go as far as that ;-)

It's just that if you share your rendered images and/or scenes (or 
include files that do anything with color or brightness), other people 
will not get what you see. (Unless their system, too, happens to be 
mis-calibrated in the same manner :-))

[SharkD] Re: Check(er) Your Gamma [5998 days 6 hours and 35 minutes ago]

Wed, 4 Nov 2009 04:37:24 GMT

On 11/3/2009 11:27 PM, clipka wrote:
> Forgot to attach the image... here it is.

I see alternating gray squares. Should I kill myself now?

Mike

[clipka] Re: Check(er) Your Gamma [5998 days 6 hours and 45 minutes ago]

Wed, 4 Nov 2009 04:28:17 GMT

Forgot to attach the image... here it is.

[clipka] Check(er) Your Gamma [5998 days 6 hours and 47 minutes ago]

Wed, 4 Nov 2009 04:25:53 GMT

You know your gamma settings are wrong if...

... you see a chrome sphere on a /checkered/ plane (even if you squint 
your eyes or look from a distance) in this image/scene.

Ideally, the plane should appear in a featureless uniform grey (except 
for some moiree effects near the horizon and maybe in the reflection). 
If instead it appears to show squares of alternating shades of grey, 
something's bogus:

(A) If you see checkering in the attached image file, then your image 
viewing software / operating system / graphics drivers / display 
hardware is poorly calibrated, and you should fix it before proceeding.

(B) If (after fixing (A)) you see checkering in the preview window 
and/or the output file when rendering the scene file below, then your 
Display_Gamma (POV-Ray 3.6 and 3.7) and/or File_Gamma setting (POV-Ray 
3.7 only), respectively, is wrong.


-----------------------------------------------------
// +w640 +h480 +a0.3

#include "colors.inc"

global_settings { #if (version < 3.7) assumed_gamma 1.0 #end }

#local CameraPos   = <0.0,0.0,-4.0>;
#local CameraDepth = 1.0;
#local CameraTilt  = 5;

camera {
   location  <0,0,0>
   direction z*CameraDepth
   right     x*image_width/image_height
   up        y
   translate CameraPos
   rotate    x*CameraTilt
}

sky_sphere {
   pigment {
     gradient y
     color_map {
       [0.0 rgb <0.6,0.7,1.0>]
       [0.7 rgb <0.0,0.1,0.8>]
     }
   }
}

light_source {
   <-30,30,-30>
   color rgb 1
   parallel
}

#declare Ratio = image_height*CameraDepth;
#declare FnScanlines = function { abs(mod(abs(Ratio*y/z+0.5),2.0)-1.0) }

plane {
   y, -1
   pigment {
     checker
     pigment { color rgb 0.5 }
     pigment {
       function { FnScanlines(x,y,z) }
       color_map {
         [0.0 color rgb 0.0 ]
         [0.5 color rgb 0.0 ]
         [0.5 color rgb 1.0 ]
         [1.0 color rgb 1.0 ]
       }
       translate CameraPos
       rotate x*CameraTilt
       rotate y*-30
       scale 1/3
     }
     scale 3
     rotate y*30
   }
}

sphere {
   0, 1
   pigment { color rgb 1 }
   finish { ambient 0 diffuse 0 reflection { 1 } }
}
-----------------------------------------------------

[SharkD] Re: TerraPOV - Sky system - Atmosphere - Part3, ... [6060 days 21 hours and 35 minutes ago]

Wed, 2 Sep 2009 13:38:03 GMT

SharkD wrote:
> A couple of comments:
> 
> 1. The sky seems very gray to me, almost metallic.
> 2. If you use a spherical camera you'll notice that there are two bright spots
> in the sky positioned 180 degrees from one another.
> 
> -Mike

Nevermind. This seems to be addressed in the later parts of the tutorial.

-Mike

[SharkD] Re: TerraPOV - Sky system - Atmosphere - Part3, ... [6060 days 21 hours and 48 minutes ago]

Wed, 2 Sep 2009 13:25:01 GMT

A couple of comments:

1. The sky seems very gray to me, almost metallic.
2. If you use a spherical camera you'll notice that there are two bright spots
in the sky positioned 180 degrees from one another.

-Mike

[Bruno Cabasson] TerraPOV - Sky system - Atmosphere - Part4, A Be... [6166 days 2 hours and 26 minutes ago]

Wed, 20 May 2009 08:46:45 GMT

Hello crazy people who continue to read me! However I am happy you are  
here.

A) Determining more accurate scattering color
---------------------------------------------
In the previous post  
(http://news.povray.org/povray.binaries.tutorials/thread/%3Cop.utj6u4lym1sclq%40pignouf%3E/
  
on May 7th), we played with some atmosphere parameters: elevation of the  
sun, altitude of the camera, the density power factor ('k' in  
d=Dmax*exp(-k*h/T)).

Now, there is another parameter which is worth to focus on: the rayleigh  
scattering color. TerraPOV follows the physical property of Rayleigh  
scattering which is wavelength dependent and is proportional to the 4th  
power of the ratio of the wavelengths, most scattering being short  
wavelengths (explaining blue sky). TerraPOV uses 3 'equivalent'  
wavelengths for red, green, and bue. Most of you know that RGB are related  
to the color spectrum of screen phospors and to human eye perception. So  
it is not physically correct to make 3 single wavelengths correpond to the  
RGB primaries. But we can try to determine better wavelengths that fit  
observation closer.

For the first posts, I determined them using a CIExy chart with sRGB color  
space and D65 white point I found on the web. I applied a ruler on the  
screen from D65 to R, G, and B primaries successively and see the  
intersection with the monochromatic locus. I got:

R --> 650 nm
G --> 555 nm
B --> 460 nm

giving the scattering color rgb <0.2508, 0.4719, 1.0000>.


That was a start point for the model. But, as we'll see below, the  
saturation of the sky color is too low.To go further, I put CIE 1931 Color  
Matching Function values in a spread sheet and re-calculated the  
monochromatic locus and the coordinates of RGB primaries in that context.  
With a precise chart, and 3 thin lines drawn from D65 to monocromatic  
locus through the 3 primaries. I got another set of values:

R --> 612 nm
G --> 549 nm
B --> 465 nm

giving the scattering color rgb <0.3333, 0.5147, 1.0000>.

In fact, those values obtained using the 4th power of the wavelength  
ratios are not really a color, but rather a set of relative scattering  
factors, normalized to blue. The behaviour is quite visually acceptable  
because it follows the basic physics rule (4th power).

Now, let's get into the color world. We take the previous 3 wavelengths  
and determine their RGB equivalent using the xyz -> RGB transformation  
(which can have negative values for red and green), and linear  
interpolation:

612 nm --> rgb <1.671473, -0.049618, 0.152247>
549 nm --> rgb <-0,290579, 1.499741, 0,233735>
465 nm --> rgb <-0.0333144, -0.0412474, 1.6444632>

We apply the relative factors and we get:

C =  0.3333*<1.671473, -0.049618, 0.152247>
    + 0.5147*<-0,290579, 1.499741, 0,233735>
    + 1.0000*<-0.0333144, -0.0412474, 1.6444632> = <0.3742, 0.7141, 1.8155>

And if we normalize to blue (remember, the TP_RAYLEIGH_AMOUNT variable is  
a multiplying factor defaulted to 1), we get:

#declare TP_RAYLEIGH_SCATTERING_COLOR = rgb <0.2061, 0.3933, 1.0>;

Surprisingly, this is very close to a simple rgb <0.2, 0.4, 1>.

It appears that the wavelengths are no more very useful: TP_LAMBDA_RED,  
TP_LAMBDA_GREEN, and TP_LAMBDA_BLUE are removed. This value is our new  
start point.

B) Checking colors
------------------
In order to check colors, we need to have our screen calibrated. Without  
devices and sepcialized software, one may visit the  
http://www.lagom.nl/lcd-test pages. This being done, we need to see what  
happens in all the sky sphere. We need a fisheye camera. Let's make  
TerraPOV provide several cameras. So we implement variables to chose which  
camera we want:

// Cameras
#declare TP_DEFAULT_CAMERA = 0;
#declare TP_FISHEYE_CAMERA = 1;

#declare TP_CAMERA = TP_FISHEYE_CAMERA;

#declare TP_FISHEYECAM_HEIGHT = 0.5*m;

#declare _tp_fisheye_camera = camera
{
     location 0
     angle 180
     right x*image_width/image_height
     look_at   z
     rotate -90*x
     rotate 180*y // To make the sun raise at the bottom of the image
     translate TP_FISHEYECAM_HEIGHT *y
}

#switch(TP_CAMERA )
     #case (TP_DEFAULT_CAMERA)
         camera {_tp_default_camera}
         #break

     #case (TP_FISHEYE_CAMERA)
         camera {_tp_fisheye_camera}
         #break

     #else
         camera {_tp_default_camera}
         #break
#end

The picture Skydome_rgb_0.2061_0.3933_1.0.png illustrates the situation  
for -5, -1, 1, 5, 20 and 70 deg elevation. Not so bad. We just notice that  
we have saturation of light near the horizon for intermediate elevations  
(20Â°).Increasing sampling (intervals and samples) for a better integration 

reduces this effect.

What will be our criteria for tuning colors at the stage we are now? I  
take 2 objective and quantizable parameters, and one subjective. The first  
two are the color of the sky and lightness of a white ground with 90Â¦  
elevation sun, the subjective criterion is the behaviour at low elevation  
and whether or not it looks realistic (remembering we still are in a pure  
atmosphere with air molecules only and with rayleigh scattering only).

Criterion #1:  Color of the sky: Hue, Saturation, and Lightness. Somebody  
called Zawischa from Hannover university wrote a paper on scattering and  
sky colors, see  
http://www.itp.uni-hannover.de/~zawischa/ITP/scattering.html. He computed  
the theoretical color of the sky due to Rayleigh scattering, and I'll  
trust him:

     Hue: 0.6
     Saturation: 0.533
     Lightness: 0.7

Let's try to get those values for a 90Â° elevation sun near the zenith.

Criterion #2: A 100% white ground with 100% diffuse appears 100% bright  
for a 90Â° elevation sun. The white light from our sun passing through a  
Rayleigh scattering media cannot produce white color on the ground. Never  
mind, that will be part of next step. For now, our goal is to approach  
these desired value as much as we can, and see what happens.

Criterion #3: Sunsets must appear natural.

All seen from ground level, of course.

We have at our disposal the scattering amount (defaulted to 1 for the  
moment), the Dmax of the atmosphere, the brightness of the sun (defaulted  
to 1 for the moment), and the scattering color of the media.

I sampled methodically a sufficiently wide domain for those parameters, I  
put the values obtained in a spreadsheet, and I could draw the following  
conclusions:

   - Increasing the scattering amount, increases lightness, and descreases  
saturation. In our case, we are always in the first part of the scattering  
amount/lightness curve. This is shown by figure  
IncreasingAmount_rgb_0.2_0.4_1.0.png. If we continue to increase the  
amount, the attenuation will prevail and the curve will bend until it gets  
a negative slope that reaches the x-axis asymptotically.

   - Increasing Red decreases mainly saturation

   - Increasing Green decreases mainly hue

   - Increasing brightness simply increases lightness

I varied the scattering amount from 0.5 to 5 by 0.25 step with default  
values for other prarameters, with scattering color rgb <0.2, 0.4, 1.0>. I  
varied red from 0.5 to 2, and green from 0.2 to 0.6, both with 0.05 step.  
I chose the values that corresponded best and tweaked by hand the  
scattering color.

I ended up with those values and the second series of skies  
Skydomes_bestrayleigh.png.

Amount = 2.3
Scattering color = rgb <0.135, 0.33, 1>
Brightness = 1/0.95 = 1.0526
Sky color at zenith, sun 90Â° elevation = hsl <0.6, 0.533, 0.698>
Ground color = rgb <0.996, 0.965, 0.855>  = hsl <0.128, 0.141, 0.996>
Ground Brighness = 0.996

Interpretation
--------------
- Amount: We cannot use the brightness parameter to increase the  
brightness of the sky, otherwise the ground will be saturated too quickly.  
So we must use the scattering amount parameter.

- Scattering color: the rgb values for the scattering color correspond to  
the following wavelengths, taking green as reference:

Red --> 686 nm
Green --> 549 nm
Blue --> 416 nm

The spectrum has been widened. This is because, in reality, our eyes  
percieve also shorter and longer wavelengths. Those values take into  
account what happens perceptually at both ends of the spectrum. Without  
being really aware of it, we performed an integration of those wavelengths  
with the Color Matching Functions. However the integrated spectrum is  
considered as uniform (rgb 1). Witout this, we could NEVER reach the  
saturation we wanted. So it's OK for our first objective criterion.

For the 3rd criterion, sunsets look obviously too greenish, and we have a  
yellow color at 5Â° elevation and still a little at 20Â°, which is
not very  
realistic. This is due to the high scattering amount value of 2.3.

What about the second criterion, color of the ground? As mentionned above,  
the white rgb 1 light of our sun cannot yield white color on the ground  
because it lost more blue than red by travelling through the atmosphere.  
The problem comes from sRGB assumptions and sun's real irradiance  
spectrum. Until now, our model does not match the sRGB assumptions: the  
light is rgb 1 at GROUND LEVEL with real values and the D65 white point is  
the color defined considering clear sky under so-called 'standard'  
conditions. That's why we cannot meet both objective criteria, nor is the  
subjective criterion met. We'll have to deal with sun's spectrum above the  
atmosphere, sun's spectrum on the ground. The difference is what is  
absorbed.

So, WTF? Can't we have it all?

Our model needs new features: taking spectra into account (white ground,  
good sky color, good lighness without a high amount of scttering), and  
absorption (ozone: less greenish sunsets). I hope we can have it all ...

Next post will deal with spectra and absorption: TerraPOV - Sky system -  
Atmosphere - Part5, An advanced model

Perhaps there will be some survivors to read me ...


Bruno

PS: The code for today:

#include "colors.inc"
#include "consts.inc"

global_settings
{
     #if (version < 3.7) assumed_gamma 1 #end
     max_trace_level 20
}

// Units
#declare m = 0.1; // A value of 1 makes the sun's distance ouside POV's  
numerical domain.
#declare km = 1000*m;
#declare mm = 0.001*m;

//    -----------------
// -- | Builtin enums | ------
//    -----------------
// Cameras
#declare TP_DEFAULT_CAMERA = 0;
#declare TP_FISHEYE_CAMERA = 1;

//    -------------
// -- | Parameters | ------
//    -------------

// Camera
#declare TP_CAMERA = TP_FISHEYE_CAMERA;

// Earth parameters
#declare TP_EARTH_RADIUS = 6378.137*km;

// Sun parameters
#declare TP_SUN_HEADING = 0;
#declare TP_SUN_ELEVATION = 70;
#declare TP_BRIGHTNESS = 1/0.95;
#declare TP_SUN_COLOR = White;
#declare TP_SUN_APPARENT_APERTURE = 0.5; // Commonly admitted value

// Atmosphere parameters
#declare TP_ATMO_BOTTOM = -1*m;

#declare TP_RAYLEIGH_FACTOR = 1.0;
#declare TP_RAYLEIGH_DENSITY_MAX = 1;
#declare TP_RAYLEIGH_AMOUNT = 2.3;

#declare TP_ATMO_INTERVALS = 5; // Necessary for good integration
#declare TP_ATMO_SAMPLES = 5;
#declare TP_ATMO_METHOD = 3;

// Default camera parameters
#declare TP_DEFCAM_HEIGHT = 2*m; // Let's be tall
#declare TP_DEFCAM_HEADING = 0;
#declare TP_DEFCAM_ELEVATION = -90; // Let's look up a little
#declare TP_DEFCAM_ANGLE = 60;

// Fisheye camera prameters
#declare TP_FISHEYECAM_HEIGHT = 0.5*m;

//    -------------
// -- |  Engine   | ------
//    -------------

// Earth
#declare _tp_earth = sphere
{
     0, TP_EARTH_RADIUS
     pigment {White} // Could be any predefined texture, but normally, the  
terrain hides the sphere
     finish {ambient 0 diffuse 1}
     translate -TP_EARTH_RADIUS*y
}

// Sun
#declare TP_SUN_DISTANCE = 10*TP_EARTH_RADIUS; // Far enough. Actual  
distance in the scene is not very critical, as the light ays are parallel
#declare TP_SUN_RADIUS =  
TP_SUN_DISTANCE*tan(radians(TP_SUN_APPARENT_APERTURE/2));
#declare _tp_basic_sun = light_source
{
   <0, 0, 0>
   color rgb TP_SUN_COLOR*TP_BRIGHTNESS
   looks_like {sphere{0, TP_SUN_RADIUS pigment{Yellow} finish {diffuse 0  
ambient 1}}}
   translate TP_SUN_DISTANCE*z
   parallel point_at -z
   rotate -TP_SUN_ELEVATION*x
   rotate TP_SUN_HEADING*y
}

// Atmosphere: density
#declare TP_BASE_RAYLEIGH_POWER = 6.7;  // Constant
#declare _tp_rayleigh_power = TP_BASE_RAYLEIGH_POWER*TP_RAYLEIGH_FACTOR;
#declare TP_ATMO_THICKNESS = 50*km;
#declare _tp_rayleigh_density = density
{
     function
     {
        
TP_RAYLEIGH_DENSITY_MAX*exp(-_tp_rayleigh_power*(sqrt(x*x+(y+TP_EARTH_RADIUS)*(y+TP_EARTH_RADIUS)+z*z)
 
- TP_EARTH_RADIUS - TP_ATMO_BOTTOM)/TP_ATMO_THICKNESS)
     }
}

// Atmosphere: scattering color
//#declare TP_RAYLEIGH_SCATTERING_COLOR = rgb  
<pow(TP_LAMBDA_BLUE/TP_LAMBDA_RED, 4), pow(TP_LAMBDA_BLUE/TP_LAMBDA_GREEN,  
4), 1>;
//#declare TP_RAYLEIGH_SCATTERING_COLOR = rgb <0.2061, 0.3933, 1.0>;
#declare TP_RAYLEIGH_SCATTERING_COLOR = rgb <0.135, 0.33, 1>;

// Atmosphere: media
#declare _tp_rayleigh_media = media
{
     method TP_ATMO_METHOD
     intervals TP_ATMO_INTERVALS
     samples TP_ATMO_SAMPLES
     scattering
     {
	RAYLEIGH_SCATTERING
	color TP_RAYLEIGH_AMOUNT*TP_RAYLEIGH_SCATTERING_COLOR/TP_ATMO_THICKNESS
	extinction 1 // The only physically accurate value
     }
     density {_tp_rayleigh_density}
}

// Atmosphere: shell
#declare _tp_rayleigh_atmosphere = difference
{
     sphere {0, TP_EARTH_RADIUS + TP_ATMO_BOTTOM + TP_ATMO_THICKNESS  
translate -TP_EARTH_RADIUS*y}
     sphere {0, TP_EARTH_RADIUS + TP_ATMO_BOTTOM translate  
-TP_EARTH_RADIUS*y}
     hollow
     pigment {rgbt 1}
     interior {media{_tp_rayleigh_media}}
}

// Default camera
#declare _tp_default_camera = camera
{
     location 0
     angle TP_DEFCAM_ANGLE
     right     x*image_width/image_height
     look_at   z
     rotate -TP_DEFCAM_ELEVATION*x
     rotate TP_DEFCAM_HEADING*y
     translate TP_DEFCAM_HEIGHT*y // Could use trace() to make sure we are  
above the surface. But no terrain yet ...
}

// Fisheye camera
#declare _tp_fisheye_camera = camera
{
     fisheye
     location 0
     angle 180
     right x*image_width/image_height
     look_at   z
     rotate -90*x
     translate TP_FISHEYECAM_HEIGHT*y
}


// Scene
object {_tp_earth}
object {_tp_rayleigh_atmosphere}
object {_tp_basic_sun}

#switch(TP_CAMERA )
     #case (TP_DEFAULT_CAMERA)
         camera {_tp_default_camera}
         #break

     #case (TP_FISHEYE_CAMERA)
         camera {_tp_fisheye_camera}
         #break

     #else
         camera {_tp_default_camera}
         #break
#end


-- 
Utilisant le client e-mail rÃ©volutionnaire d'Opera :  
http://www.opera.com/mail/

[Bruno Cabasson] TerraPOV - Sky system - Atmosphere - Part4, A Be... [6178 days 23 hours ago]

Thu, 7 May 2009 12:12:40 GMT

Hello here (if ever some people are still there  :p ).

Here we are for improving our atmosphere model. Last post produced our  
first blue sky using Rayleigh scattering media and following physics. Now  
let's play a bit with some parameters. This will help us to see how the  
model works, and to validiate the principle.

A) Playing with some parameters
===============================

1) Elevation
------------
We try different values: -5°, -1°, 1°, 5°, 20°, and 70°,
all other  
parameters unchanged. We get FirstBlueSky_-5_-1-1_5_20_70_deg.png. Not so  
bad, considering we only changed the elevation of the sun. The principle  
seems to work. We do have the redenning of the light, and we get something  
'acceptable' when the sun is below the horizon. Obviously, these are not  
perfect colors, but I recall, this is what we obtain considering only pure  
atmosphere, with only Rayleigh scattering, no other particles, no other  
effect or property. Not so bad on my opinion.

2) Altitude
-----------
We set the elevation to 45°. Remember: the camera has angle = 40° and a
5°  
pitch upwards. And we set altitude to different values: 2*m, 1000*m,  
4000*m. We get FirstBlueSky_2_1000_4000_m.png. Visually and with a color  
picker, we can see how the brightness decreases with altitude. This  
behaviour was expected because at high altitude, the light encounters less  
molecules (less distance + less density), there is less scattering, and we  
see less blue and more black from the outer space (considered as 100%  
black).

3) Density power factor
-----------------------
As seen previously, the density of the atmophere can be expressed by: d =  
Dmax*exp(-k*h/T), where h is the atitude and T the thickness of the  
atmosphere. In TerraPOV, the factor k os split into a default value  
TP_BASE_RAYLEIGH_POWER that expresses 'normality'and valued to 6.7 for a  
50km thick atmosphere, and a multiplying factor TP_RAYLEIGH_FACTOR,  
defaulted to 1.

As we increase TP_RAYLEIGH_FACTOR, the density curve will sharpen and  
become more spiky. The transition near the horizon will also be sharper.  
The overall number of particles will also decrease and there will be less  
scattering, yielding less reddening at low elevations. The sky will darken.

As we decrease TP_RAYLEIGH_FACTOR, the density curve will flatten. The  
transition near the horizon will also be smoother. The overall number of  
particles will also increase and there will be more scattering, yielding  
more reddening at low elevations. The sky will lighten.

The picture RelativeDensity.png shows curves of relative density for  
TP_RAYLEIGH_FACTOR = 0.5, 0.75, 1, 1.25, 1.5. The number of tarversed  
particles is proportinal to the surface under the curve until considered  
altitude.

REM: We can also control Dmax and compensate loss or gain of scattering,  
but it's another aspect. And it sems we do not - at first - need to change  
it.

Let's set elevation to 45° and vary TP_RAYLEIGH_FACTOR: we get  
FirstBlusSky_rayleigh_factor_0.5_0.75_1_1.25_1.5_elev45.png.
Let's set elevation to 2° and vary TP_RAYLEIGH_FACTOR: we get  
FirstBlusSky_rayleigh_factor_0.5_0.75_1_1.25_1.5_elev2.png.

The general behaviour seems to work fine, already with a basic model for  
atmosphere (pure atmosphere with only air molecules and only rayleigh  
scattering). It will soon be time to control the color values (Hue,  
Saturation, Light) and compare with photographs. This will help us  
determine correct values, and also reveal the limitations of this simple  
model. The model will then be augmented with additional medias to get  
closer to what we observe in nature.

To be continued in next post: TerraPOV - Sky system - Atmosphere - Part4,  
A Better model (cont'd)


Bruno

PS: Congratulations if you have read me until this point !!!

-- 
Utilisant le client e-mail révolutionnaire d'Opera :  
http://www.opera.com/mail/

[Bruno Cabasson] TerraPOV - Sky system - Atmosphere - Part3, A Bl... [6179 days 23 hours and 50 minutes ago]

Wed, 6 May 2009 11:23:10 GMT

Hello, It's me again.

After the general considerations, we now enter the core of the physical  
model of TerraPOV's Sky System: Getting a 'real' blue sky by Rayleigh  
scattering. In a previous article, I recommended the reader to refer to  
the web for Rayleigh scattering and blue sky. However, I feel like I can  
briefly expose the principle.

1) Rayleigh scattering
----------------------
Small particles have a physical property towards light that depends on the  
wavelength of the light and the size (and shape) of the said particles,  
and this property is called scattering. An incident ray of light is  
scattered in all directions according to a specific pattern as a  
consequence of the corresponding formula (Rayleigh). Air molecules have  
the property of scattering in the visible spectrum, and more in the short  
wavelengths (blue) than in longer wavelengths (red), by the 4th power of  
the ratio of wavelength. POV-Ray implements this type of scattering with  
type 4 (RAYLEIGH_SCATTERING in consts.inc), but only implements the  
pattern and is not wavelength-dependant. TerraPOV will do that through the  
chosen scaterring color by defining the amount of scattering of the 3  
red/green/blue components.

Now let's draw a white light ray through a medium that has Rayleigh  
scattering properties. The spectrum of the light constains more or less  
all wavelengths in the visible spectrum. What happens? The short  
wavelengths are scattered much more in other directions than the incident,  
and more than longer wavelengths. In the incident direction, the remainig  
spectrum has less short wavelengths than longer ones. That is: contains  
less blue than red. It becomes yellowish. In the other directions, it is  
the counterpart: it contains more blue that the other wavelentghs.

So, we have: in the direction of light (sun) blue has been reduced, the  
'white' sun light becomes yellowish (very bright ...), in all the other  
directions we see the blue rays that were scattered by the air molecules.  
As the light encounters more molecules during its travel (combination of  
path length and density of the medium, ie integration), its spectrum loses  
more and more short wavelengths: blue at first, then green, etc... At low  
elevations of the sun, he light travels longer through denser medium, and  
the sky near the horizon becomes red.

2) Density
----------
We saw in a previous article that the density d of the athmosphere  
descreases with altitude h by a function that can be expressed like:

    d = Dmax*exp(-k*h/T)

where Dmax is the density at level y=0, T is the considered thickness of  
atmosphere, and k is a factor.

TerraPOV will valuate Dmax = 1, T = 50*km, and k = 6.7,, but all are  
controllable.

In order to have more flexibility over the k factor which is very  
important in the result, TerraPOV splits k into a base factor of 6.7, and  
a multiplying factor defauted to 1 that expresses the 'distance' to  
'normality'.

The altitude h is NOT the y-coordinate, but indeed the vertical distance  
to the surface.

So we can write the following in our previous code:

#declare TP_BASE_RAYLEIGH_POWER = 6.7;  // Constant
#declare TP_RAYLEIGH_FACTOR = 1; // User defined
#declare _tp_rayleigh_power = TP_BASE_RAYLEIGH_POWER*TP_RAYLEIGH_FACTOR;

#declare TP_ATMO_THICKNESS = 50*km;
#declare TP_RAYLEIGH_DENSITY_MAX = 1;

#declare _tp_rayleigh_density = density
{
     function
     {
        
TP_RAYLEIGH_DENSITY_MAX*exp(-_tp_rayleigh_power*(sqrt(x*x+(y+TP_EARTH_RADIUS)*(y+TP_EARTH_RADIUS)+z*z)
 
- TP_EARTH_RADIUS)/TP_ATMO_THICKNESS)
     }
}

3) Scattering color
-------------------
As mentionned above, the amount of scattering is a function of the  
wavelength, or of a ratio of wavelengths. Scattering is more important for  
blue, less for green, and less for red. We take the blue as reference and  
take into account the fact that Rayleigh scattering is proportionnal to  
the 4th power of the ratio in wavelengths. This implies that we define  
wavelengths for our primary colors:

#declare TP_LAMBDA_RED = 650;   // nanometres
#declare TP_LAMBDA_GREEN = 555; // nanometres
#declare TP_LAMBDA_BLUE = 460;  // nanometres

#declare TP_RAYLEIGH_SCATTERING_COLOR = rgb  
<pow(TP_LAMBDA_BLUE/TP_LAMBDA_RED, 4), pow(TP_LAMBDA_BLUE/TP_LAMBDA_GREEN,  
4), 1>;

4) Media
--------
Who says media in POV, says sampling parameters. Let's make them TerraPOV  
parameters.

#declare TP_ATMO_INTERVALS = 3; // Necessary for good integration
#declare TP_ATMO_SAMPLES = 3;
#declare TP_ATMO_METHOD = 3; // Adaptive

Theses values will later be controlled by a global quality/preview switch.  
But for now, this is OK. The color used for the media controls the amount  
of scattering. As the density is normalized to 1 (TP_RAYLEIGH_DENSITY_MAX  
= 1 by default), and the light travels through TP_ATMO_THICKNESS media, we  
must compensate by dividing the amount by some normalizing value, and  
TP_ATMO_THICKNESS itself is a good candidate. We use a specific  
multiplying parameter to adjust the amount of scattering, and default it  
to 1.

#declare TP_RAYLEIGH_AMOUNT = 1;

The TerraPOV's media for the Rayleigh aspect can be written as:

#declare _tp_rayleigh_media = media
{
     method TP_ATMO_METHOD
     intervals TP_ATMO_INTERVALS
     samples TP_ATMO_SAMPLES = 3
     scattering
     {
	RAYLEIGH_SCATTERING
	color TP_RAYLEIGH_AMOUNT*TP_RAYLEIGH_SCATTERING_COLOR/TP_ATMO_THICKNESS
	extinction 1 // The only physically accurate value
     }
     density {_tp_rayleigh_density}
}

5)Atmophere's shell
--------------------
TerraPOV uses a spherical shell around the Earth for the atmosphere. This  
container is filled with our atmospheric media we just defined. The shell  
has a defined thikness (TP_ATMO_THICKNESS) and assumes it starts at level  
0. We can add a parameter to control the bottom altitude of the  
atmosphere. This allows, among other things, to prevent coincident surface  
artifact between Earth and atmosphere, and to put the camera outside the  
container. This forces us to redefine a bit the density  
_tp_rayleigh_density.

#declare TP_ATMO_BOTTOM = -1*m;
#declare _tp_rayleigh_density = density
{
     function
     {
        
TP_RAYLEIGH_DENSITY_MAX*exp(-_tp_rayleigh_power*(sqrt(x*x+(y+TP_EARTH_RADIUS)*(y+TP_EARTH_RADIUS)+z*z)
 
- TP_EARTH_RADIUS - TP_ATMO_BOTTOM)/TP_ATMO_THICKNESS)
     }
}

The shell is made of differenced spheres, filled with our media:

#declare _tp_rayleigh_atmosphere = difference
{
     sphere {0, TP_EARTH_RADIUS + TP_ATMO_BOTTOM + TP_ATMO_THICKNESS  
translate -TP_EARTH_RADIUS*y}
     sphere {0, TP_EARTH_RADIUS + TP_ATMO_BOTTOM translate  
-TP_EARTH_RADIUS*y}
     hollow
     pigment {rgbt 1}
     interior {media{_tp_rayleigh_media}}
}

6) Render
---------
We just add this statement

object {_tp_rayleigh_atmosphere}

and run ...

Yessssss!!!!

We get the attached image. It is the result without any tuning and  
refinement for a PURE atmosphere, made only of air molecules, and taking  
into account only the Rayleigh scattering effect, without anything else.  
The true atmosphere is more complex. We have still a long way to go before  
we can say that we are arrived to a good model. But even though this model  
in still basic, it is quite satisfactory.

Next article will play with the parameters and try to draw guidelines for  
improvements: TerraPOV - Sky system - Atmosphere - Part4, A Better model


Bruno


PS: Here is the code.

#include "colors.inc"
#include "consts.inc"

global_settings
{
     #if (version < 3.7) assumed_gamma 1 #end
     max_trace_level 20
}

// Units
#declare m = 0.1; // A value of 1 makes the sun's distance ouside POV's  
numerical domain.
#declare km = 1000*m;
#declare mm = 0.001*m;

//    -------------
// -- | Parameters | ------
//    -------------
// Earth parameters
#declare TP_EARTH_RADIUS = 6378.137*km;

// Sun parameters
#declare TP_SUN_HEADING = 0;
#declare TP_SUN_ELEVATION = 15;
#declare TP_BRIGHTNESS = 1;
#declare TP_SUN_COLOR = White;
#declare TP_SUN_APPARENT_APERTURE = 0.5; // Commonly admitted value

// Atmosphere parameters
#declare TP_ATMO_BOTTOM = -1*m;

#declare TP_RAYLEIGH_FACTOR = 1;
#declare TP_RAYLEIGH_DENSITY_MAX = 1;
#declare TP_RAYLEIGH_AMOUNT = 1;

#declare TP_ATMO_INTERVALS = 3; // Necessary for good integration
#declare TP_ATMO_SAMPLES = 3;
#declare TP_ATMO_METHOD = 3; // Adaptive

// Default camera parameters
#declare TP_DEFCAM_HEIGHT = 2*m; // Let's be tall
#declare TP_DEFCAM_HEADING = 0;
#declare TP_DEFCAM_ELEVATION = 5; // Let's look up a little
#declare TP_DEFCAM_ANGLE = 40;

//    -------------
// -- |  Engine   | ------
//    -------------

// Earth
#declare _tp_earth = sphere
{
     0, TP_EARTH_RADIUS
     pigment {White} // Could be any predefined texture, but normally, the  
terrain hides the sphere
     finish {ambient 0}
     translate -TP_EARTH_RADIUS*y
}

// Sun
#declare TP_SUN_DISTANCE = 10*TP_EARTH_RADIUS; // Far enough. Actual  
distance in the scene is not very critical, as the light ays are parallel
#declare TP_SUN_RADIUS =  
TP_SUN_DISTANCE*tan(radians(TP_SUN_APPARENT_APERTURE/2));
#declare _tp_basic_sun = light_source
{
   <0, 0, 0>
   color rgb TP_SUN_COLOR*TP_BRIGHTNESS
   looks_like {sphere{0, TP_SUN_RADIUS pigment{Yellow} finish {diffuse 0  
ambient 1}}}
   translate TP_SUN_DISTANCE*z
   parallel point_at -z
   rotate -TP_SUN_ELEVATION*x
   rotate TP_SUN_HEADING*y
}

// Atmosphere: density
#declare TP_BASE_RAYLEIGH_POWER = 6.7;  // Constant
#declare _tp_rayleigh_power = TP_BASE_RAYLEIGH_POWER*TP_RAYLEIGH_FACTOR;
#declare TP_ATMO_THICKNESS = 50*km;
#declare _tp_rayleigh_density = density
{
     function
     {
        
TP_RAYLEIGH_DENSITY_MAX*exp(-_tp_rayleigh_power*(sqrt(x*x+(y+TP_EARTH_RADIUS)*(y+TP_EARTH_RADIUS)+z*z)
 
- TP_EARTH_RADIUS - TP_ATMO_BOTTOM)/TP_ATMO_THICKNESS)
     }
}

// Atmosphere: scattering color
#declare TP_LAMBDA_RED = 650;   // nanometres
#declare TP_LAMBDA_GREEN = 555; // nanometres
#declare TP_LAMBDA_BLUE = 460;  // nanometres
#declare TP_RAYLEIGH_SCATTERING_COLOR = rgb  
<pow(TP_LAMBDA_BLUE/TP_LAMBDA_RED, 4), pow(TP_LAMBDA_BLUE/TP_LAMBDA_GREEN,  
4), 1>;

// Atmosphere: media
#declare _tp_rayleigh_media = media
{
     method TP_ATMO_METHOD
     intervals TP_ATMO_INTERVALS
     samples TP_ATMO_SAMPLES
     scattering
     {
	RAYLEIGH_SCATTERING
	color TP_RAYLEIGH_AMOUNT*TP_RAYLEIGH_SCATTERING_COLOR/TP_ATMO_THICKNESS
	extinction 1 // The only physically accurate value
     }
     density {_tp_rayleigh_density}
}

// Atmosphere: shell
#declare _tp_rayleigh_atmosphere = difference
{
     sphere {0, TP_EARTH_RADIUS + TP_ATMO_BOTTOM + TP_ATMO_THICKNESS  
translate -TP_EARTH_RADIUS*y}
     sphere {0, TP_EARTH_RADIUS + TP_ATMO_BOTTOM translate  
-TP_EARTH_RADIUS*y}
     hollow
     pigment {rgbt 1}
     interior {media{_tp_rayleigh_media}}
}

// Default camera
#declare _tp_default_camera = camera
{
     location 0
     angle TP_DEFCAM_ANGLE
     right     x*image_width/image_height
     look_at   z
     rotate -TP_DEFCAM_ELEVATION*x
     rotate TP_DEFCAM_HEADING*y
     translate TP_DEFCAM_HEIGHT*y // Could use trace() to make sure we are  
above the surface. But no terrain yet ...
}

// Scene
object {_tp_earth}
object {_tp_rayleigh_atmosphere}
object {_tp_basic_sun}
camera {_tp_default_camera}

-- 
Utilisant le client e-mail révolutionnaire d'Opera :  
http://www.opera.com/mail/

[Bruno Cabasson] TerraPOV - Sky system - Atmosphere - Part2, Glob... [6180 days 22 hours and 53 minutes ago]

Tue, 5 May 2009 12:19:47 GMT

This article explains TerraPOV's global geometric model for a scene. This  
involves Earth's and Sun's geometric parameters.

Just before we begin, we have to define some distance units we will often  
use in TerraPOV:

#declare m = 0.1; // A value of 1 makes the sun's distance ouside POV's  
numerical domain.
#declare km = 1000*m;
#declare mm = 0.001*m;

And, like POV-SDL, TerraPOV uses degrees for angles.

0) Outer space
--------------
Outer space is considered as fully dark. This is the case in POV-SDL if no  
background is specified.

1) Earth
---------
For current applications such as GPS, the reference Earth is an ellipsoid  
with semi-major axis of 6378.137 km and semi-minor axis of 6354.4523 km  
(WGS84 model). In many scientific applications and calculations, the Earth  
is simplified to a sphere with a radius of semi-major axis. TerraPOV  
expresses it as:

#declare TP_EARTH_RADIUS = 6378.137*km;

TerraPOV sets the origin at the surface of the Earth, that is:

#declare _tp_earth = sphere
{
     0, TP_EARTH_RADIUS
     pigment {White} // Could be any predefined texture, but normally, the  
terrain hides the sphere
     finish {ambient 0}
     translate -TP_EARTH_RADIUS*y
}

And that's enough for Earth.

2) Sun
------
The sun is the main light source for TerraPOV scenes. The sun's apparent  
aperture, due to real distance, allows to assume that the rays are  
parallel. At first, we use a simple parallel white light_source that  
looks_like a shere. The necessity to have a more advanced model for the  
sun depends on the type of sky used in the scene, whether clouds are  
present and if the sun is totally/partially hidden behind, its elevation.  
Until now I could not find a general model of the sun that can fit a few  
frequent situations. I'll come back to it later. The color of the  
light_source is expressed through 2 values: a color and a brightness,  
multiplied together. Later, the color could be normalized in order to  
match the energy of white (white carries an energy The brightness is used  
to compensate lightness diminution when the sun is hidden behind clouds or  
at low elevations.

For now, let's express what we have:

// User defined values
#declare TP_SUN_HEADING = 0;
#declare TP_SUN_ELEVATION = 15;
#declare TP_BRIGHTNESS = 1;
#declare TP_SUN_COLOR = White;
#declare TP_SUN_APPARENT_APERTURE = 0.5; // Commonly admitted value

// Computed values
#declare TP_SUN_DISTANCE = 10*TP_EARTH_RADIUS; // Far enough. Actual  
distance in the scene is not very critical, as the light ays are parallel
#declare TP_SUN_RADIUS =  
TP_SUN_DISTANCE*tan(radians(TP_SUN_APPARENT_APERTURE/2));

// Sun
#declare _tp_basic_sun = light_source
{
   <0, 0, 0>
   TP_SUN_COLOR*TP_BRIGHTNESS
   looks_like {sphere{0, TP_SUN_RADIUS pigment{Yellow} finish {diffuse 0  
ambient 1}}}
   translate TP_SUN_DISTANCE*z
   parallel point_at -z
   rotate -TP_SUN_ELEVATION*x
   rotate TP_SUN_HEADING*y
}

3) Camera
---------
We use a standard persepective camera, and the main parametes are  
contallable. In a normal lanscape scene, we can drop the camera above the  
terrain, helped by a preview image, and rough and fine offsets can be be  
applied. The camera can also be placed with respect to an object. For now,  
we just position the camera above the ground, at humain height. Let's also  
imagine that TerraPOV can provide several cameras, for different pusposes.  
So, let's define the default camera.

#declare TP_DEFCAM_HEIGHT = 2*m; // Let's be tall
#declare TP_DEFCAM_HEADING = 0;
#declare TP_DEFCAM_ELEVATION = 5;
#declare TP_DEFCAM_ANGLE = 40;

#declare _tp_default_camera = camera
{
     location 0
     angle TP_DEFCAM_ANGLE
     right     x*image_width/image_height
     look_at   z
     rotate -TP_DEFCAM_ELEVATION*x
     rotate TP_DEFCAM_HEADING*y
     translate TP_DEFCAM_HEIGHT*y; // Could use trace() to make sure we are  
above the surface. But no terrain yet ...
}

Now we have someting that expresses the global geometry of a TerraPOV  
scene. However it's still very basic, but we have already separated  
interesting parameters from the 'engine'.

// Scene
object {_tp_earth}
object {_tp_basic_sun}
camera {_tp_default_camera}


We put all together and render the scene. One can play with parameters.
REMARK: In a while, we will have many parameters. They will be split among  
several include files, and used by a standard main scene file.

// ------------------------------------
#include "colors.inc"

global_settings
{
     #if (version < 3.7) assumed_gamma 1 #end
     max_trace_level 20
}

// Units
#declare m = 0.1; // A value of 1 makes the sun's distance ouside POV's  
numerical domain.
#declare km = 1000*m;
#declare mm = 0.001*m;

// Earth parameters
#declare TP_EARTH_RADIUS = 6378.137*km;

// Sun parameters
#declare TP_SUN_HEADING = 0;
#declare TP_SUN_ELEVATION = 15;
#declare TP_BRIGHTNESS = 1;
#declare TP_SUN_COLOR = White;
#declare TP_SUN_APPARENT_APERTURE = 0.5; // Commonly admitted value

// Default camera parameters
#declare TP_DEFCAM_HEIGHT = 2*m; // Let's be tall
#declare TP_DEFCAM_HEADING = 0;
#declare TP_DEFCAM_ELEVATION = 5; // Let's look up a little
#declare TP_DEFCAM_ANGLE = 40;

// Computed values
#declare TP_SUN_DISTANCE = 10*TP_EARTH_RADIUS; // Far enough. Actual  
distance in the scene is not very critical, as the light ays are parallel
#declare TP_SUN_RADIUS =  
TP_SUN_DISTANCE*tan(radians(TP_SUN_APPARENT_APERTURE/2));

// Earth
#declare _tp_earth = sphere
{
     0, TP_EARTH_RADIUS
     pigment {White} // Could be any predefined texture, but normally, the  
terrain hides the sphere
     finish {ambient 0}
     translate -TP_EARTH_RADIUS*y
}

// Sun
#declare _tp_basic_sun = light_source
{
   <0, 0, 0>
   color rgb TP_SUN_COLOR*TP_BRIGHTNESS
   looks_like {sphere{0, TP_SUN_RADIUS pigment{Yellow} finish {diffuse 0  
ambient 1}}}
   translate TP_SUN_DISTANCE*z
   parallel point_at -z
   rotate -TP_SUN_ELEVATION*x
   rotate TP_SUN_HEADING*y
}

// Default camera
#declare _tp_default_camera = camera
{
     location 0
     angle TP_DEFCAM_ANGLE
     right     x*image_width/image_height
     look_at   z
     rotate -TP_DEFCAM_ELEVATION*x
     rotate TP_DEFCAM_HEADING*y
     translate TP_DEFCAM_HEIGHT*y // Could use trace() to make sure we are  
above the surface. But no terrain yet ...
}

// Scene
object {_tp_earth}
object {_tp_basic_sun}
camera {_tp_default_camera}

// ------------------------------------

Ok folks, I have finished for this part. Next article will add an  
atmosphere, and we'll get a blue sky ... automatically....

Coming next: TerraPOV - Sky system - Atmosphere - Part3, A Blue Sky


Bruno

-- 
Utilisant le client e-mail révolutionnaire d'Opera :  
http://www.opera.com/mail/

[Bruno Cabasson] TerraPOV - Sky system - Atmosphere - Part 1, Gen... [6181 days 23 hours and 1 minute ago]

Mon, 4 May 2009 12:11:36 GMT

After some experiments in POV, after seeing some POV artits' artwork, it  
appeared to me soooo clear that the only way to get realistic behaviour  
and colors for atmosphere is to follow ... reality. IOW follow physics and  
nature, as much as possible. Having a physically-realistic atmosphere will  
produce correct colors, and correct lighting for scenes, and also correct  
illumination for clouds and radiosity.

So, the main question is: what makes the atmosphere have such colors in  
such circumstances? That is:

     -) Why is the sky blue?
     -) Why is blue deeper at high altitudes?
     -) What makes the atmosphere become reddish at low elevations of the  
sun?
     -) What makes the atmosphre have such a variety of colors, especially  
at low elevations of the sun?
     -) How to have a correct illumination when the sun is below the  
horizon?
     -) etc ...
     -) How to make it 'automatic'?

The answer is: follow reality. That is:

     -) Have a physical model that can be handled by POV-SDL
     -) Determine the variables of this model
     -) Implement the model

All the aforementionned behaviours are due to the interaction between the  
sun's light and the atmosphere. This interaction is itself due to the  
sun's light spectrum, to the kind and density of particles in the  
atmosphere, and to the length of the path of the light through them. Every  
kind of particle has a specific scattering and absorption behaviour.  
Unless particular events (aurorae ...) air particules do not emit light by  
themselves. I will consider such phenomena later. These interactions  
produce a complex combination of colors which yields what we can observe.

This being said, lets deal a bit with those considerations.

A) SUN's spectrum
In nature, the sun's spectrum is not really white. Some wavelenghts are  
missing. But, in outer space, the color of the sun is reported by  
astronauts as being 'very' white. TerraPOV will default the sun's color to  
white.

B) Kind and density of particles
Until now, I distinguish global atmosphere and ground atmosphere.

Global atmosphere contains air molecules that are responsible for the  
Rayleigh scattering which produces the blueness of the sky, yellowishness  
of direct sunlight, and blueishness of shadowed areas. Please, refer to  
the Web for further information about Rayleigh scattering and blue sky.  
TerraPOV uses one media for that. The atmosphere also contains other  
particles, in various shape, size and behaviour. This is described by  
another media with scatterring and absorption parameters (color and  
amount).

Ground atmosphere is reponsible for this haze we can see near horizon and  
can influence a lot on resulting aspect of the sky. This includes all  
kinds of pollution, water vapour, specific gases and so forth. This is  
also described by a media with scatterring and absorption parameters.

As you know, the pressure of the atmosphere decreases with altitude. A  
search on the web informed me that the pressure decreases 'quite'  
exponentilly with height, and that the significant thickness is about  
50km. Beyond this altitude, the relative pressure is less than 1/1000 than  
that of sea level. The pressure at altitude h for an atmosphere of  
thickness T can be expressed with a formula of the kind p = Pmax *  
exp(-k*h/T). As density is directly related to pressure, TerraPOV use such  
formulae for all altitude-related densities. In order to match the values  
found on the web for the pressure/altitude relationship, the factor k is  
around 6.7 fot a thickness of 50km. In TerraPOV, Dmax, k and thickness are  
controllable.

C) Length of the light path trough atmosphere
This aspect is due to geometrical considerations: the earth is round, and  
the atmosphere is a shell around. Therefore, the length of the path of  
light depends on the elevation of the sun, and the geometry determines the  
way this length increases/decreases with elevation. This, with density, is  
responsible of the reddening at low elevations. TerraPOV uses a round  
earth and the atmosphere is a shell around it, with an exponentially  
decreasing density as exposed above.


Well here we are for this article. Next article will deal in detail with  
the geometrical model related to TerraPOV's sky system, and the first code  
fragments will appear.


Bruno.

-- 
Utilisant le client e-mail révolutionnaire d'Opera :  
http://www.opera.com/mail/

[Bruno Cabasson] TerraPOV foundation features: Preliminary [6182 days 2 hours and 17 minutes ago]

Mon, 4 May 2009 08:56:15 GMT

TerraPOV is a long-term project I started a while ago. I wanted it to be  
as declarative as I could have TerraPOV to do so, allowing the artist to  
minimmize programming, and then have those declarations be processed by a  
specialized engine. All in POV-SDL as a start point. The process of making  
a lansdcape scene would be the following:

    -) valuate a (large ...) set of defined parameters for the lansdcape  
framework of my scene, with defaults and predefined stuff, and with  
preview utilities
    -) perform little and 'quite defined' programming for what cannot be  
expressed with single values
    -) put my objects in the scene with placement/populating macros and few  
rules (user-defined code)
    -) render the scene using the TerraPOV engine that sets up the scene  
accordingly

The first question I had to answer was: what is a lanscape? Observing the  
nature, seeing 3D masters' artwork, and using Terragen for a few tries  
helped me define the main areas of what a lanscape is made of:

     -) Atmosphere, sky, cloudscape and so forth
     -) Terrain shaping and texturing, water
     -) Vegetation (very, very vast area ...)
     -) user-defined objects

I have explored more or less those areas, more for sky-related features,  
less for terrain, and even less for vegetation.

In this series of aticles, I will provide some code fragments that  
implement the main principles of TerraPOV, and let you use them right now.  
I will use the following basic coding rules:

     -) All TerraPOV-related identifiers start with 'TP_' or '_tp_', easy  
answer to some 'namespace' considerations
     -) Constants are uppercase: TP_SOME_CONSTANT
     -) Macros and parameters are lowercase: _tp_some_macro (_parameter_1,  
parameter_2). Macros shall not be considered as some kind of text  
substitution, but like 'real' fonctions or procedures, with typed  
parameters and returned value, and are written accordingly

Before I expose how all this assembles in a usable way, I'll describe what  
are the sets of parameters I defined, first for skyscape, then for  
terrain. When I have something consitent and useable for vegetation, I'll  
let you know. But for vegetation, I have in mind POV-Tree and PlantStudio  
to help defining a ready-to-use collections of vegetation objects, with  
placement and populating macros.

Well, now, let's start in the next article with the first area: TerraPOV's  
sky system: Atmosphere.

I hope I won't be too boring.... If so, let me know, I'll return to RSOCP   
:p

     Bruno

-- 
Utilisant le client e-mail révolutionnaire d'Opera :  
http://www.opera.com/mail/

[H Karsten] Re: How to render mirrored objects into _real_ p... [6289 days 20 hours and 58 minutes ago]

Fri, 16 Jan 2009 14:15:02 GMT

That explaines a view strange things, I've had in a view scenes.

Thanx :)

[clipka] Re: How to render mirrored objects into _real_ p... [6291 days and 13 minutes ago]

Thu, 15 Jan 2009 11:00:00 GMT

"Edouard Poor" <pov### [at] edouardinfo> wrote:
> This has tripped me up, but I believe that the image of the mirror ball, and the
> megapov "maptype 7" mapping are different.

They are different indeed.

For the plain viewing effect it doesn't make a difference though. And if you
need correct mapping, "HDRShop" is what you want to go for.

[Edouard Poor] Re: How to render mirrored objects into _real_ p... [6291 days 8 hours and 8 minutes ago]

Thu, 15 Jan 2009 03:05:00 GMT

This has tripped me up, but I believe that the image of the mirror ball, and the
megapov "maptype 7" mapping are different. Paul Debevec explains it on
http://www.debevec.org/probes/

"Note that each light probe image represents a full 360 × 360 degrees, or 4pi
steradians. Also note that the mapping being used is different than the mapping
one observes in a mirrored ball -- the mapping we're using avoids the problems
of poor sampling near the backwards-facing directions around the circumference
of the image."

Cheers,
Edouard.

[clipka] Re: Making matte/shadow-textures in instant-comp... [6292 days 21 hours and 43 minutes ago]

Tue, 13 Jan 2009 13:30:01 GMT

"H. Karsten" <h-karsten()web.de> wrote:
> By the way: don't confuse the chrome-map with HDRs the one has nothing to do
> with the other.

Well, they have, insofar as they are often combined ;)

They're then often called "HDR light probes" - but H. Karsten is right in that
there are indeed "light probes" which are not HDR at all (bad choice if I'm
asked), and there are HDR images that have nothing to do with light probes.

The reason why light probes and HDR usually go tother hand in hand is that a HDR
light probe still gives very good results if your reflective object happens to
be only somewhat reflective, while standard 8-bit file formats have some
disadvantages in these cases. They're much easier to produce with a digicam
though, and if you need something other than plain chrome for your rendered
object, you may think about using a sphere made of just the desired material.

[H Karsten] Making matte/shadow-textures in instant-composit... [6292 days 22 hours and 13 minutes ago]

Tue, 13 Jan 2009 13:00:01 GMT

Making matte/shadow-textures in instant-compositings

To complete the chrome-map tutorial, here the one to show you how to make
matte/shadow-textures in renderings.

I've posted a new thread, because you can use this also in other issues like
HDR-renderings of object into an additional photos of the HDR-environments and
more.

By the way: don't confuse the chrome-map with HDRs the one has nothing to do
with the other.

For this tutorial you'll need:
-Megapov
-A picture, where you like to put a 3d-object into.
-read this: web.496bc004fe4d566620776f0@news.povray.org

To let your 3d-object better fit into the real environment, a shadow is very
important - and in most cases its easy!

In fact, most cases means a plane: In normal environments, you have a ground and
you will put something on it. What you need is a plane that is more or less
opaque in-, and invisible outside of the shadows.

The first step is, to fit the plane, or other objects, to the
background-picture. this is the most difficult part. Sometimes you need to
adjust your lens-angle to.

When this is done, do this:

plane {y,0  // adjust plane first
hollow on
pigment {
projection {
object {your_object} // this pattern projects your object onto the plane
point <-20,40,15> // point of the light_source
//normal on  // use this to get an occlusion-effect                        //
instead of a normal shadow
blur .1,64  // this blurs your shadow (amount,samples)
}
color_map {
[0 color rgbt 1] // this is outside of the shadow (invisible)
[1 color rgbt <0,0,0,0.5>] // experiment with the last value:
}}}      // 1=invisible 0=black

If you have more than one object, define them as a union{..} and take them for
the projection{object{...}} keyword.

To finalize your rendering, focus the camera somewhere between your object and
the camera-plane that contains the background-image. Use small values for the
aperture keyword.

With this trick, you cam adjust the sharpness between you object and the photo.

Sharp objects often looking very artificial.

Have fun

Holger

[H Karsten] How to render mirrored objects into _real_ pictu... [6293 days 12 hours and 53 minutes ago]

Mon, 12 Jan 2009 22:20:00 GMT

This is a simple tutorial that shows you to render chrome-textured objects into
real pictures, taken by your photo-camera.

You need:
-A camera (optional a stand)
-A Chrome-Ball
-Megapov

- Put the ball almost to the place, where you like to have the 3d-object.
- Make a Photo (best, from far away with a narrow angle. Otherwise, you see your
self..)
- Make a second picture without the ball from almost the same place (best with a
stand)
- Crop the Ball picture
- Use the cropped picture as image-map for the environment sphere
(shrinkwraped!!),"no_image"
- Use the other picture as image.map for the background-plane
(screen.inc),"no_reflection"

have fun :)

PS.: Compare the image-numbers in the scene with the numbers in the uploaded
image.

####################################################################################

#include "screen.inc"

Set_Camera_Location(<0.0, 0.5, -4.0>)
Set_Camera_Look_At(<0.0, 0.0,  0.0>)
Set_Camera_Aspect(image_width,image_height)
#declare T=texture{pigment{
image_map {
  jpeg "3.jpg"
  map_type 0
  interpolate 2
}}
finish{ambient 1}
}
object{
Screen_Plane (T, 1000, <0,0>, <1,1>)
no_reflection
}
sphere {
  0.0, 1
  texture {
    pigment {
image_map {
  jpeg "2.jpg"
  map_type 7
  interpolate 2
}
    }
finish{ambient 1}
  }
scale <-1,1,1>
scale 1000
rotate y*180
no_image
}

julia_fractal {
  <-0.083,0.0,-0.83,-0.025>
  quaternion
  cube
  max_iteration 4
  precision 20
finish{reflection 1}
//optional...
rotate <frame_number,frame_number*2,frame_number*4>
scale 0.3
translate <.35,-0.2,0>
}

[Meothuru] Tutorial to make Grid-Patterns and Wireframes [6752 days 5 hours and 33 minutes ago]

Fri, 12 Oct 2007 05:40:01 GMT

This tutorial will show you, how to create wireframe-models and
grid-patterns in a quick and easy way.

To create wireframes and grids, POV-Ray offers the special-pattern:

 Tiles_Ptrn()

With this pattern you can create tiled patterns - and the grid-pattern
is the "mother of all tiled patterns". So in this way you can create
wireframe-models and grid-patterns by "pigmenting" the figures,
with this special pattern.

A first example:
//------------------------------------------
#include "textures.inc"

plane { <0,1,0>,0
   pigment {
      Tiles_Ptrn()
      color_map{
         [0.00 color rgb <1,1,1>]   // white stanchions
         [0.04 color rgb <0,0,0>]  // black spaces
      }
      rotate x*90  // rotates the pattern onto the "upper side" of the plane
   }
}

light_source {<5,5,-5>,1}
camera {location <5,5,-5> look_at 0}
//-------------------------------------------

This short example shows a black plane with a white grid-pattern.

So far, so good...but wireframe-models are transparent.This is no
problem...for
creating wireframes, we only have to modify the color_map a litte bit. We
make
the black spaces simply transparent - and this looks likes this:

      color_map{
         [0.00 color rgb <1,1,1>]   // white stanchions
         [0.04 color rgbt <0,0,0,1>]  // transparent spaces
      }

That's all you have to do, to alternate a grid-pattern into a
wireframe-pattern.

In the same easy way you can modify  the thickness of the stanchions.
You simply change the value of the second entry. i.e.

      color_map{
         [0.00 color rgb <1,1,1>]   // white stanchions
         [0.08 color rgbt <0,0,0,1>]  // transparent spaces
      }

Here the value was changed from 0.04 to 0.08 to make the stanchions thicker.
For thinner stanchions the value must be set to a lower value.But of course
this
method have limits.

In the next step, I demonstrate how to change the size and the ratio of the
pattern. To do this, you have to insert a "scale" in this way:

   pigment {
      Tiles_Ptrn()
      color_map{
         [0.00 color rgb <1,1,1>]   // white stanchions
         [0.04 color rgbt <0,0,0,1>]  // transparent spaces
      }
      scale <0.5, 1, 0.5>    // Here yo can set the size and ratio of the
grid
   }


For some figures it is necessary/sensefull to render the grid-pattern
with "uv_mapping" to get usable results.For example, we want
to render a sphere-figure, that shows a grid-pattern just like the
longitudes/latitudes on a globe. The next example will show such a
sphere-figure as a wireframe-model, with a "longitude/latitude"-pattern.

//---------------------------------
#include "colors.inc"
#include "textures.inc"

background {Gray75}

sphere{ <0,0,0>,3
   pigment {
      uv_mapping                         // render pattern with
"uv_mapping".
      Tiles_Ptrn()
      color_map{
         [0.00 color rgb <0,0,0>]      // black stanchions
         [0.06 color rgbt <0,0,0,1>]  // transparent spaces
      }
      scale <0.066, 0.066, 1>            // set size/ratio
   }
}

light_source {<5,5,-5>,1}
camera {location <5,5,-5> look_at 0}
//------------------------------------------------


And now let us create a litte more complexe wireframe-model.

//--------------------------------------------------
#include "textures.inc"

sky_sphere {
   pigment { gradient <0, 1, 0>
      color_map {
         [ 0 color rgb <0.054902, 0.219608, 0.4> ]
         [ 0.5 color rgb <0.960784, 0.960784, 0.960784> ]
         [ 1 color rgb <0.054902, 0.219608, 0.4> ]
      }
   }
}

union {
   sphere {  <0, 0, 0>, 1  translate -2*x  }

   cylinder { <1.1, 0, 0>, <-1.1, 0, 0>, 0.4
      open
      pigment {
         Tiles_Ptrn()
         color_map {
            [ 0 color rgb <0, 0, 0> ]
            [ 0.05 color rgbt <0, 0, 0, 1> ]
         }
         scale 0.2       // The cylinder must have his own, other scaled
wireframe-pattern.
      }                     // Because the cylinder have a smaller radius,
than the spheres.
      rotate x*45
   }

   sphere {  <0, 0, 0>, 1  translate 2*x }

   pigment {
      uv_mapping  //the wireframe-pattern for both spheres - but not for the
cylinder.
      Tiles_Ptrn()
      color_map {
         [ 0 color rgb <0, 0, 0> ]
         [ 0.05 color rgbt <0, 0, 0, 1>]
      }
      scale 0.05
   }
}

light_source { <4, 5, -5>, rgb <1, 1, 1>}
camera { location <5, 5, -5>   look_at 0 }
//------------------------------------------

OK...this is the end of this tutorial. I hope it helps you a litte bit, to
have more fun
with POV-Ray.

[Dahman] Re: POV-Ray 3.6 Complete Textures Guide [6781 days 21 hours and 23 minutes ago]

Wed, 12 Sep 2007 13:50:00 GMT

"Pook" <nomail@nomail> wrote:
> Hi! I used to be very frustrated by making silly mistakes while editing POV
> textures which sometimes require very complicated syntax. To make the life
> a bit easier I made "POV-Ray 3.6 Textures Complete Guide" which is a kind
> of a catalog that lists of all the textures, pigments, materials, finishes,
> interiors and radiosity (totally about 500 pages) and provides their code .
> It's here:
> http://www.3dplumbing.net/tutorials/textures_guide_POV/index.html
>
> It is quite handy to have the examples of POV syntax available at any time.
> Moreover, you can use the pieces of the code in your scenes without the
> necessity to point to the inc files which are located in the POV-Ray for
> Windows v3.6, for example, directory. Everything is tested.  Also this
> guide gives a nice opportunity to experiment with POV syntax. You can use
> textures as templates to create your own or to modify existing ones. You
> can subtract peaces of the code from different textures and combine them to
> make completely new ones. So it's fun and a broad field for experimenting
> and studying POV-Ray. Some tricks about advanced textures are here:
> http://www.3dplumbing.net/tutorials/textures_advanced_POV/index.html
>
> Enjoy!


Pook, thanks for sharing.
Very useful.

Regards
Dahman

[Pook] POV-Ray 3.6 Complete Textures Guide [6818 days 9 hours and 43 minutes ago]

Tue, 7 Aug 2007 01:30:00 GMT

Hi! I used to be very frustrated by making silly mistakes while editing POV
textures which sometimes require very complicated syntax. To make the life
a bit easier I made "POV-Ray 3.6 Textures Complete Guide" which is a kind
of a catalog that lists of all the textures, pigments, materials, finishes,
interiors and radiosity (totally about 500 pages) and provides their code .
It's here:
http://www.3dplumbing.net/tutorials/textures_guide_POV/index.html

It is quite handy to have the examples of POV syntax available at any time.
Moreover, you can use the pieces of the code in your scenes without the
necessity to point to the inc files which are located in the POV-Ray for
Windows v3.6, for example, directory. Everything is tested.  Also this
guide gives a nice opportunity to experiment with POV syntax. You can use
textures as templates to create your own or to modify existing ones. You
can subtract peaces of the code from different textures and combine them to
make completely new ones. So it's fun and a broad field for experimenting
and studying POV-Ray. Some tricks about advanced textures are here:
http://www.3dplumbing.net/tutorials/textures_advanced_POV/index.html

Enjoy!

[Grassblade] Re: How to move an object along a particular spi... [6875 days 16 hours and 53 minutes ago]

Sun, 10 Jun 2007 18:20:01 GMT

"Joe" <Pre### [at] aolcom> wrote:
> Is there a way to evaluate the integral with a different program, transfer
> that information to a file (a txt i guess) and have Povray read it from
> that text file in order to animate a path for a sphere?

Yes, definitely, POV-ray can read ASCII text files, see 3.2.2.3 in the
documentation that comes with POVray (for Windows). For some reason the
same topic is numbered 2.2.2.3 in the on-line documentation:
http://www.povray.org/documentation/view/3.6.1/238/

If you make a search for "Handle" on the newsgroup, you should obtain some
really good examples of reading/writing ASCII files.

[kurtz le pirate] Re: How to move an object along a particular spi... [6879 days 16 hours and 54 minutes ago]

Wed, 6 Jun 2007 18:18:27 GMT

In article <web.466495c47064b1ed998929610@news.povray.org>,
 "Joe" <Pre### [at] aolcom> wrote:

> Is there a way to evaluate the integral with a different program, transfer
> that information to a file (a txt i guess) and have Povray read it from
> that text file in order to animate a path for a sphere?


hum... just a try :

x=0
y=0

for i=1 ... n
  t=eval(fn)
  x=cos(2.pi.t)
  y=sin(2.pi.t)
  sx=sum(x)
  sy=sum(y)
  draw point at <xs,ys>


for cornu spiral fn => i^2/321



not tested :)

-- 
klp

[Joe] Re: How to move an object along a particular spi... [6881 days 12 hours and 28 minutes ago]

Mon, 4 Jun 2007 22:45:01 GMT

Is there a way to evaluate the integral with a different program, transfer
that information to a file (a txt i guess) and have Povray read it from
that text file in order to animate a path for a sphere?

[Grassblade] Re: How to move an object along a particular spi... [6881 days 14 hours and 58 minutes ago]

Mon, 4 Jun 2007 20:15:01 GMT

Of course you can do integrals in POV-ray. You can do anything with POV-ray.
*Fanatical glint in the eye*
You can obtain a numerical approximation of the integral by applying its
definition, i.e. take a very small dx, evaluate y and add dx*y to previous
sum in the loop.
You can also use the generalised hypergeometric solution, see
http://mathworld.wolfram.com/CornuSpiral.html The generalised
hypergeometric looks like a nasty customer to code, but it has the
advantage of being an exact solution.

[Joe] How to move an object along a particular spiral. [6881 days 22 hours and 28 minutes ago]

Mon, 4 Jun 2007 12:45:01 GMT

Anybody know how to move any object over the "Cornu spiral". I just started
this and I've been trying to use the parametric equations way because that
is what the spiral can be defined in. I get stuck when it comes to doing
the integrals in Pov-Ray. I don't even know if you can do integrals in
Pov-Ray. Thanks for any help. :)

[Elija] Making a hollow sphere cloud like and fluffy! [6929 days 19 hours and 43 minutes ago]

Tue, 17 Apr 2007 15:30:03 GMT

I have attached a partial screen shot taken part way through a render so I
can try and describe what I have so far been unable to do.

As you can see, the top of the sphere is very sharply delineated whereas the
effect I am after is the more cloud like effect that you can see at the
bottom of it.

This is the code for one of the spheres in the image.

==============  Code begins  ================================
union {
 light_source {
  <0, 1, 2>
  color Red
  looks_like {
   sphere {
    <0, 1, 2> 0.25
    no_shadow
    hollow
    pigment { Clear }
    finish { ambient 0.0 }
   }
  }
 }

 sphere {
  <0, 1, 2> 2
  pigment {
   color White
   filter 0.85
  }
  no_shadow
  hollow
  interior {
   ior 1.001
   media {
    scattering {
     2,
     0.3
    }
   }
  }
  finish {
   ambient 0.0
  }
 }
 translate <0, 0, 2>
}
==============  Code ends  ==================================

Can anyone suggest how to get the cloud like effect?

[Allen] Re: Sand material [6937 days 4 hours and 18 minutes ago]

Tue, 10 Apr 2007 06:55:01 GMT

"nemesis" <nam### [at] gmailcom> wrote:
> "motorsep" <nomail@nomail> wrote:
> > Here is what they have for 3DS MAX:
> > http://www.rebelthink.com/images/natshaders/images/old/Sand_RENDER.jpg
> > http://www.rebelthink.com/images/natshaders/images/new/Sand_Daylight_HI.jpg
> >
> > How can I achive such effect with Povray?
>
> I'm guessing a heightfield, atmospheric media and scattering media inside
> the heightfield to simulate subsurface scattering will do the job.
>
> this irtc image shows sand without subsurface scattering:
> http://www.irtc.org/ftp/pub/stills/2004-08-31/em_giza.jpg
>
> some stupid media is used here:
> http://www.irtc.org/ftp/pub/stills/2005-02-28/adsub.jpg
>
> and here is a better use of atmospheric media to convey a nice effect:
> http://www.irtc.org/ftp/pub/stills/2002-08-31/tnw_icla.jpg
>
> Unfortunately, none of the pictures show scattering media inside the
> heightfield.  Like, say, inside the transparent difference of the
> heightfield against a barely scaled version of itself.  Is that possible?

~~~~~~~~~~~~

Cool, You found my crap sub image.  I've found another way to do sand that
looks good.  I'm just unable to really test it due to my raytracing pc
catching fire.

Take a Heightfield that looks like the dunes you wish to create.  Make this
like a declaration so it doesn't appear.  The reason for this is because
you want to trace the entire surface with billions of random spheres.  This
should give the effect you are looking for.  If not spheres, use cubes for a
crystal look.

When the camera is close, you can see individual sand crystals.  At a
distance it looks like dunes.  But if done right, each cube will reflect
light like sand would as well.  Just experiment with this idea and it will
work out.

Tim's idea on his iceland image works very well as well.  Use two
heightfields and fill the space between with media.  But have one
heightfield below to give the presence of ground.

Hope this helps
~Allen

[Trevor G Quayle] Re: hi i'm looking for an HDRI tutorial on povray [7033 days 21 hours and 13 minutes ago]

Wed, 3 Jan 2007 14:00:01 GMT

"St." <dot### [at] dotcom> wrote:
> "Johan Feyaerts" <joh### [at] nospamhotmailcom> wrote in message
> news:459aa983$1@news.povray.org...
> > Hi
> >
> > Where can I find a good tutorial on HDRI in povray?
>
>    I ripped this link from exactly the same question asked 3 years ago:
> http://www.helensimages.com/tgtips.htm
>
>    You don't need Terregen but once you've acquired a few probes, you can
> envelope your scene in this sphere:
>
>   sphere {<0, 1, 0> 650
>     texture{ pigment { image_map { hdr "something_probe.hdr" once
> interpolate 2 map_type 1} rotate <0, 0, 0> scale 1 }}}
>
>     ~Steve~

Some additional information:

To control the brightness of the map, just adjust the ambient. One way I
suggest is to use 'f-stops' (if you don't know what f-stops are and mean,
have a search for it on google. Basically it is a n^2 law, i.e., +1 f-stop
doubles the brightness, and -1 f-stop will half the brightness etc.)

Add something like:
#declare FStops=0;
#declare Bright = pow(2,FStops);

then use:
finish{ambient Bright diffuse 0}

Adjust FStops to the brightness you want.

-tgq

[St ] Re: hi i'm looking for an HDRI tutorial on povray [7034 days 5 hours and 37 minutes ago]

Wed, 3 Jan 2007 05:36:01 GMT

"Johan Feyaerts" <joh### [at] nospamhotmailcom> wrote in message 
news:459aa983$1@news.povray.org...
> Hi
>
> Where can I find a good tutorial on HDRI in povray?

   I ripped this link from exactly the same question asked 3 years ago: 
http://www.helensimages.com/tgtips.htm

   You don't need Terregen but once you've acquired a few probes, you can 
envelope your scene in this sphere:

  sphere {<0, 1, 0> 650
    texture{ pigment { image_map { hdr "something_probe.hdr" once 
interpolate 2 map_type 1} rotate <0, 0, 0> scale 1 }}}

    ~Steve~

[Johan Feyaerts] hi i'm looking for an HDRI tutorial on povray [7034 days 16 hours and 22 minutes ago]

Tue, 2 Jan 2007 18:50:43 GMT

Hi

Where can I find a good tutorial on HDRI in povray?

[Meothuru] Looking for a "Bow wave"-tutorial [7181 days 6 hours and 8 minutes ago]

Wed, 9 Aug 2006 05:05:00 GMT

Does anybody know one ?


Background:
A sphere-object(should be planet) comes up, from under
a plane-object and move this way:

 translate <2*clock, 6*clock, -10*clock>

As long the sphere-object and the plane-objet have contact,
in front of the sphere-object, there should be a bow wave.
I make some experiments with blob-objects, but it looks realy
poor.

So now I'm look for a "Bow wave"-tutorial


thx

[javakidv1] Re: pov objects [7222 days 17 hours and 28 minutes ago]

Wed, 28 Jun 2006 17:45:01 GMT

Ken <tyl### [at] pacbellnet> wrote:
> ingo wrote:
> >
> > §FireFly§ wrote:
> >
> > >I cant find the povobjects page can someone please tell me the address
> > >to it
> > >
> > http://cgi-bin.spaceports.com/~pov/cgi-bin/objlist.cgi
>
> That is a bad link.
>
> Try this one instead - http://povobjects.virtualave.net/
>
> --
> Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
> http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

that link is bad too

[motorsep] Re: Sand material [7280 days 7 hours and 3 minutes ago]

Tue, 2 May 2006 04:10:01 GMT

thanks guys. I will experiment with that stuff..

[Arne Kleinophorst] Re: Sand material [7306 days 3 hours and 44 minutes ago]

Thu, 6 Apr 2006 07:29:06 GMT

motorsep schrieb:
> Hi,
> 
> Here is what they have for 3DS MAX:
> http://www.rebelthink.com/images/natshaders/images/old/Sand_RENDER.jpg
> http://www.rebelthink.com/images/natshaders/images/new/Sand_Daylight_HI.jpg
> 
> How can I achive such effect with Povray?
> Maybe somebody have pre-made sand material or can create one?
> 
> Thank you.
> 

Hmm, for the Shader-effect with the daylight Pic, i would try to 
experiment with a ground fog with some turbulence. It won't be correct 
on the surface but you might get a similar effect.

Arne

[nemesis] Re: Sand material [7306 days 21 hours and 28 minutes ago]

Wed, 5 Apr 2006 13:45:00 GMT

"motorsep" <nomail@nomail> wrote:
> Here is what they have for 3DS MAX:
> http://www.rebelthink.com/images/natshaders/images/old/Sand_RENDER.jpg
> http://www.rebelthink.com/images/natshaders/images/new/Sand_Daylight_HI.jpg
>
> How can I achive such effect with Povray?

I'm guessing a heightfield, atmospheric media and scattering media inside
the heightfield to simulate subsurface scattering will do the job.

this irtc image shows sand without subsurface scattering:
http://www.irtc.org/ftp/pub/stills/2004-08-31/em_giza.jpg

some stupid media is used here:
http://www.irtc.org/ftp/pub/stills/2005-02-28/adsub.jpg

and here is a better use of atmospheric media to convey a nice effect:
http://www.irtc.org/ftp/pub/stills/2002-08-31/tnw_icla.jpg

Unfortunately, none of the pictures show scattering media inside the
heightfield.  Like, say, inside the transparent difference of the
heightfield against a barely scaled version of itself.  Is that possible?

[motorsep] Sand material [7308 days 19 hours and 8 minutes ago]

Mon, 3 Apr 2006 16:05:01 GMT

Hi,

Here is what they have for 3DS MAX:
http://www.rebelthink.com/images/natshaders/images/old/Sand_RENDER.jpg
http://www.rebelthink.com/images/natshaders/images/new/Sand_Daylight_HI.jpg

How can I achive such effect with Povray?
Maybe somebody have pre-made sand material or can create one?

Thank you.

[motorsep] Re: Brushed Aluminum material [7308 days 19 hours and 48 minutes ago]

Mon, 3 Apr 2006 15:25:00 GMT

Thanks. I will take a look on that.

> "Roman Reiner" <lim### [at] gmxde> wrote:

> I guess you mean you don't want to use image files as textures. proceduals
> are textures as well ;)

[Roman Reiner] Re: Brushed Aluminum material [7311 days and 58 minutes ago]

Sat, 1 Apr 2006 10:15:01 GMT

"motorsep" <nomail@nomail> wrote:
> Hi,
>
> I totally new to Povray :) I use it with Blender through Blend2POV, so if I
> need materials, I have to write a code in Text window in Blender..
> I need brushed aluminum for my contemporary door handles. And I don't really
> want to use any textures.
> Can somebody show me how can I create such material please?
> I would greately appreciate your reply!
> Thank you.

I guess you mean you don't want to use image files as textures. proceduals
are textures as well ;)

Anyway. I guess what you're looking for are blurred reflections. You maybe
want to have a look here:
http://tag.povray.org/povQandT/languageQandT.html#blurredreflection
it's written for povray 3.5 and if i remember right i had problems to run
this code with a newer version but the idea behind it remains the same.
Brushed metal effects can be achieved by an uneven scaling of the normal
pattern.

In addition or if you get problems i recommend a search for blurred
reflection. This has been a topic here a couple of times!
Hope this helps.
Regards Roman

[motorsep] Brushed Aluminum material [7311 days 4 hours and 8 minutes ago]

Sat, 1 Apr 2006 07:05:01 GMT

Hi,

I totally new to Povray :) I use it with Blender through Blend2POV, so if I
need materials, I have to write a code in Text window in Blender..
I need brushed aluminum for my contemporary door handles. And I don't really
want to use any textures.
Can somebody show me how can I create such material please?
I would greately appreciate your reply!
Thank you.

[Ken Hutson] Re: Isosurface Tutorial updated [7491 days 8 hours and 45 minutes ago]

Mon, 3 Oct 2005 02:27:33 GMT

Excellent material Mike!

"Mike Williams" <mik### [at] nospamplease> wrote in message 
news:ci+sVC### [at] econymdemoncouk...
> I've substantially updated my isosurface tutorial at
> <http://www.econym.demon.co.uk/isotut>.
>
> There's now an almost[1] complete catalogue of the built in functions,
> and each page now contains a zip file of all the sources used for the
> images on that page. So pop by if you've ever wondered what the Kampyle
> of Eudoxus looks like, or want know what various parameters of the
> func_16 surface do.
>
> [1] I'd be glad of any hints on how to use any of the remaining built in
> functions, namely: imp_func, data_3D_3, data_2D_3, data_3D_1, data_2D_1,
> odd_sphere and iso_pigment.
>
> -- 
> Mike Williams
> Gentleman of Leisure

[Jeff Houck] Re: Best Tutorial? [7628 days 10 hours and 10 minutes ago]

Thu, 19 May 2005 01:02:57 GMT

Jjjakal wrote:
> What is the best tutorial to learning Povray tecniques?
> 
> 
http://www.google.com/search?hl=en&q=povray+tutorial&btnG=Google+Search

[Jjjakal] Best Tutorial? [7629 days 9 hours and 58 minutes ago]

Wed, 18 May 2005 01:15:00 GMT

What is the best tutorial to learning Povray tecniques?

[David Wallace] Re: reflection map [7678 days 5 hours and 38 minutes ago]

Wed, 30 Mar 2005 05:35:10 GMT

Reflection is a part of an object's finish.  Pigments and normals may be mapped 
by patterns, but not finishes.  To pull this off, the whole texture needs mapping:

#declare texShiny = texture {
   pigment { rgb <0.45,0.89,0.67> }
   finish {
     reflection { 0.23, 0.78 falloff 1 }
     brilliance 3
   }
}

#declare texMatte = texture {
   pigment { rgb <0.45,0.89,0.67> }
   finish {
     reflection { 0.00, 0.05 falloff 1 }
     brilliance 1.2
   }
}

#declare texCar = texture {
   gradient y
   texture_map {
     [0.0 texMatte]
     [1.0 texShiny]
   }
}

What I suspect you really want is to model only half the car and then create a 
mirror image.  The answer to that is even easier:

#declare CarLeft = union {
    ...
}

#declare CarRight = object { CarLeft scale <-1,1,1> }

This will simplify modeling, but it won't save trace time.

Le Forgeron wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Muniz wrote:
> 
>>Hello people,
>>
>>
>>I'm starting with pov, and I'd like to know if is there any way to use
>>reflection map in pov as texture?
>>
>>I'm modeling a car, and I'd like to use a texture as reflection map to
>>render the image faster (than use reflection tag). It doesn't matter if the
>>reflection is realistic, how do I make it?
>>
> 
> HDRI ?
> sky_sphere ?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFCSQ/Ys/YJ43cSjHIRAkCXAJ9xkkqIogpFA3hoVvRcyGC2ZFTYsACfaFxq
> kKmvdfadKD4zWGAYAUqAWxQ=
> =sOv4
> -----END PGP SIGNATURE-----


-- 
--------------
David Wallace
TenArbor Consulting
"Just In Time Cash"
www.tenarbor.com
1-866-572-CASH

[Le Forgeron] Re: reflection map [7679 days 2 hours and 52 minutes ago]

Tue, 29 Mar 2005 08:20:40 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Muniz wrote:
> Hello people,
> 
> 
> I'm starting with pov, and I'd like to know if is there any way to use
> reflection map in pov as texture?
> 
> I'm modeling a car, and I'd like to use a texture as reflection map to
> render the image faster (than use reflection tag). It doesn't matter if the
> reflection is realistic, how do I make it?
> 
HDRI ?
sky_sphere ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCSQ/Ys/YJ43cSjHIRAkCXAJ9xkkqIogpFA3hoVvRcyGC2ZFTYsACfaFxq
kKmvdfadKD4zWGAYAUqAWxQ=
=sOv4
-----END PGP SIGNATURE-----

[Muniz] reflection map [7679 days 13 hours and 58 minutes ago]

Mon, 28 Mar 2005 21:15:00 GMT

Hello people,


I'm starting with pov, and I'd like to know if is there any way to use
reflection map in pov as texture?

I'm modeling a car, and I'd like to use a texture as reflection map to
render the image faster (than use reflection tag). It doesn't matter if the
reflection is realistic, how do I make it?


Thanks,
Marcelo Muniz

[Burki] Re: Ocean or sea tutorial? [7691 days 14 hours and 38 minutes ago]

Wed, 16 Mar 2005 20:35:01 GMT

>
> http://free.prohosting.com/~olana/povray/povray.html has what you need and
> more

  ---> Error 404

But you could try this one, very helpful:

   http://www-public.tu-bs.de:8080/~y0013390/pov/water/index.html


Yours,
Bu.

[Maurice] Re: A new radiosity tutorial [7692 days 16 hours and 28 minutes ago]

Tue, 15 Mar 2005 18:44:34 GMT

Hildur K. wrote:
> Maurice <cel### [at] nospamhotmailcom> wrote:
> 
>>Hildur K. wrote:
>>
>>>I posted a radiosity tutorial on my website:
>>>
>>>http://www.simnet.is/hildurka/pages/raditut1.htm
>>>
>>>All comments welcome,
>>>
>>>Hildur Kolbrun
>>>
>>>
>>
>>Where is it?
> 
> 
> sorry about this, reconstructed the whole site,
> you should be able to find it here
> http://www.simnet.is/hildurka/content/tut1page.htm
> 
> Everybody, thanks for your comments.
> 
Thanks for putting it back.



-- 
Maurice

http://get-me.to/Hendrix

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GEd-s+:+aC++UL+PL+E-W++N++o--K-
wO---M-VPS+PEY+PGPt++++5--XRtv+
b+DI+D--Ge++h----y++++
------END GEEK CODE BLOCK------

[Hildur K ] Re: A new radiosity tutorial [7692 days 18 hours and 43 minutes ago]

Tue, 15 Mar 2005 16:30:01 GMT

Maurice <cel### [at] nospamhotmailcom> wrote:
> Hildur K. wrote:
> > I posted a radiosity tutorial on my website:
> >
> > http://www.simnet.is/hildurka/pages/raditut1.htm
> >
> > All comments welcome,
> >
> > Hildur Kolbrun
> >
> >
> Where is it?

sorry about this, reconstructed the whole site,
you should be able to find it here
http://www.simnet.is/hildurka/content/tut1page.htm

Everybody, thanks for your comments.

[Hildur K ] Re: A new radiosity tutorial [7692 days 18 hours and 48 minutes ago]

Tue, 15 Mar 2005 16:25:00 GMT

Maurice <cel### [at] nospamhotmailcom> wrote:
> Hildur K. wrote:
> > I posted a radiosity tutorial on my website:
> >
> > http://www.simnet.is/hildurka/pages/raditut1.htm
> >
> > All comments welcome,
> >
> > Hildur Kolbrun
> >
> >
> Where is it?

Sorry, reconstructed my site, forgot to update this link.
you should be able to find the tutorial here:
http://www.simnet.is/hildurka/content/tut1page.htm

[regdo] Re: calcul the difference of image [7707 days 12 hours and 56 minutes ago]

Mon, 28 Feb 2005 22:16:43 GMT

scorpmetal wrote:
> I learn to POVRAY only 1 month. I work in domain vision of omnidirectionnal
> robotic. is these anybody like me? Can The POVRAY  calculate the difference
> into 2 image? How we calculate?
> If this is possible, answer me to the mail:
> sco### [at] yahoocom
> Thanks to everyone
> 
> 
With as little information, it's difficult to answer.
Anyway, some picture-oriented software may be more efficient for that 
need (if it is to "xor" two pictures, or something like that).
Still, it *is* possible with pov, but it's not its goal, and not as easy 
as many other tools.

[scorpmetal] calcul the difference of image [7707 days 20 hours and 53 minutes ago]

Mon, 28 Feb 2005 14:20:00 GMT

I learn to POVRAY only 1 month. I work in domain vision of omnidirectionnal
robotic. is these anybody like me? Can The POVRAY  calculate the difference
into 2 image? How we calculate?
If this is possible, answer me to the mail:
sco### [at] yahoocom
Thanks to everyone

[Rishi] Interior Tutorial [7713 days 20 hours and 29 minutes ago]

Tue, 22 Feb 2005 14:43:32 GMT

Hi,

I am looking for an 'interior tutorial'. Does anyone have any links/ 
suggestions (apart from the documentatiion)?

Thanks in advance.

Rishi

[Jim Charter] Re: UV Mapping tutorial for Blender / Poseray / ... [7718 days 4 hours and 29 minutes ago]

Fri, 18 Feb 2005 06:44:01 GMT

Stefan Viljoen wrote:
> Hi guys
> 
> I'm pulling my hair out to do UVmapped textures with Pov. I've got Gilles
> Tran's tut, but I'm too stupid to get it working - I also don't have Poser.
> 
> Anybody know of a URL to a simple, newbie oriented tut that maybe refers to
> using GPL tools only (maybe Blender and / or Wings, Poseray) to do UV
> mapping with Pov? I've got UVMapper as well. 
> 
> So far I have succeeded in UVmapping a simple cube, but anything more
> complex eludes me. Blender seems to have powerful facilties for this, and
> I've figured out a simple workflow to use it to UVmap to Pov (via Poseray)
> but I can't seem to get anything but a cube working...
> 
> The Blender UV tuts of course don't refer to Pov at all - and my improvised
> workflow only seems to do cubes or simple cube like shapes (via Poseray).
> 
> Any pointers or URL's? All available stuff I've googled for seem to refer to
> using commercial apps, or only one app (like the Blender tutorials) but
> very little about using these programs' to get UVmapping in POV.
> 
I have yet to see anything too useful out there, though it has been 
awhile since the last time I looked.  I think it is important to realize 
that there is no magic bullet.  Also note that how you project the 
vertices to produce an effctive UV template varies for each model AND it 
is just half the battle.  Using that template to produce a texture is 
the other half of the art.  Have you read  Leigh Van Der Byl's texture 
forum over on CGTalk?  It's a good starting point and also there are 
some tut list there afaik.  But surely you have?  She's one of your own!

[FlyerX] Re: UV Mapping tutorial for Blender / Poseray / ... [7718 days 4 hours and 36 minutes ago]

Fri, 18 Feb 2005 06:36:34 GMT

Stefan Viljoen wrote:
> Hi guys
> 
> I'm pulling my hair out to do UVmapped textures with Pov. I've got Gilles
> Tran's tut, but I'm too stupid to get it working - I also don't have Poser.
> 
> Anybody know of a URL to a simple, newbie oriented tut that maybe refers to
> using GPL tools only (maybe Blender and / or Wings, Poseray) to do UV
> mapping with Pov? I've got UVMapper as well. 
> 
> So far I have succeeded in UVmapping a simple cube, but anything more
> complex eludes me. Blender seems to have powerful facilties for this, and
> I've figured out a simple workflow to use it to UVmap to Pov (via Poseray)
> but I can't seem to get anything but a cube working...
> 
> The Blender UV tuts of course don't refer to Pov at all - and my improvised
> workflow only seems to do cubes or simple cube like shapes (via Poseray).
> 
> Any pointers or URL's? All available stuff I've googled for seem to refer to
> using commercial apps, or only one app (like the Blender tutorials) but
> very little about using these programs' to get UVmapping in POV.
> 
> Thanks!!

The easiest way when I started out was to create 1st a simple square 
image. I labeled the bottom edge U and the left edge V and added some 
arrows from the lower left corner along the edges to indicate the 
direction of increasing U and V.

In UVmapper I remapped several models and applied this image as a map to 
see how it wrapped around.

In PoseRay I can do that easily and you can do simple uv mapping 
(planar, cylindrical, spherical and cube) but if you want power on each 
vertex UVmapper is better in creating UV coordinates.

The PoseRay manual has simple previews of what each uv mapping looks like.

FlyerX

[Stefan Viljoen] UV Mapping tutorial for Blender / Poseray / Pov? [7718 days 5 hours and 12 minutes ago]

Fri, 18 Feb 2005 06:01:04 GMT

Hi guys

I'm pulling my hair out to do UVmapped textures with Pov. I've got Gilles
Tran's tut, but I'm too stupid to get it working - I also don't have Poser.

Anybody know of a URL to a simple, newbie oriented tut that maybe refers to
using GPL tools only (maybe Blender and / or Wings, Poseray) to do UV
mapping with Pov? I've got UVMapper as well. 

So far I have succeeded in UVmapping a simple cube, but anything more
complex eludes me. Blender seems to have powerful facilties for this, and
I've figured out a simple workflow to use it to UVmap to Pov (via Poseray)
but I can't seem to get anything but a cube working...

The Blender UV tuts of course don't refer to Pov at all - and my improvised
workflow only seems to do cubes or simple cube like shapes (via Poseray).

Any pointers or URL's? All available stuff I've googled for seem to refer to
using commercial apps, or only one app (like the Blender tutorials) but
very little about using these programs' to get UVmapping in POV.

Thanks!!
-- 
---
Stefan Viljoen
Software Support Technician
Polar Design Solutions

[Neil Kolban] Re: MakeSnow Tutorial [7730 days 12 hours and 22 minutes ago]

Sat, 5 Feb 2005 22:51:05 GMT

Mike,
This is great stuff.  I have added a link to your article at the POV-Ray 
wiki.  It would be great to have your tutorial/paper hosted on the Wiki.  If 
you would like to do this great.  If you wish, I would be happy to do this 
on your behalf.  If you don't want to have the article hosted on the wiki 
... that is fine too .. you have contributed much so far.

Neil

"Mike Kost" <con### [at] povraytashcorpnet> wrote in message 
news:42052395@news.povray.org...
> I've written a tutorial on understanding Gilles Tran's MakeSnow macro.
> It's up at http://povray.tashcorp.net/tutorials/dd_makesnow
>
> Enjoy!
>
> Mike
> http://povray.tashcorp.net

[Mike Kost] MakeSnow Tutorial [7730 days 15 hours and 22 minutes ago]

Sat, 5 Feb 2005 19:50:45 GMT

I've written a tutorial on understanding Gilles Tran's MakeSnow macro.
It's up at http://povray.tashcorp.net/tutorials/dd_makesnow

Enjoy!

Mike
http://povray.tashcorp.net

[Maurice] Re: A new radiosity tutorial [7771 days 15 hours and 46 minutes ago]

Sun, 26 Dec 2004 19:26:37 GMT

Hildur K. wrote:
> I posted a radiosity tutorial on my website:
> 
> http://www.simnet.is/hildurka/pages/raditut1.htm
> 
> All comments welcome,
> 
> Hildur Kolbrun
> 
> 
Where is it?

[Alan] Sand [7794 days 11 hours and 29 minutes ago]

Fri, 3 Dec 2004 23:44:21 GMT

Does anyone know of a good pattern and color map to generate a sand texture? 
It must work on a collection of really small (few pixel) sized spheres.

[Shurakai] Re: Animation of molecular structures [7798 days 23 hours and 33 minutes ago]

Mon, 29 Nov 2004 11:40:00 GMT

KalleK <kal### [at] gmxde> wrote:
> > If You should have comments, critic or a good idea how to improve the whole
> > thing, i would be happy if You would tell me.
>
> Just spotted a typo:
> In the Menu at the top of your page, I read "CrytalPov" (without "s")
>
> cukk


Thanks, :). Already corrected.

Shu.

[KalleK] Re: Animation of molecular structures [7798 days 23 hours and 58 minutes ago]

Mon, 29 Nov 2004 11:14:42 GMT

> If You should have comments, critic or a good idea how to improve the whole
> thing, i would be happy if You would tell me.

Just spotted a typo:
In the Menu at the top of your page, I read "CrytalPov" (without "s")

cukk

[Shurakai] Re: Animation of molecular structures [7799 days and 53 minutes ago]

Mon, 29 Nov 2004 10:20:01 GMT

Bruce <flo### [at] nospamfreefr> wrote:
> Just one question : I quickly read Your tutorial and saw a lot of option
> about rendering (especially work on texture or light). The goal of such
> pictures is rather to guve a touchable representation of something hard
> to represent, what is then the goal of exploding time render needed
> (using radiosity for example) just for some "artistic" needs? Anyway,
> that's optionnal, so it won't be boring, but I was wondering the use of
> representing carbon atom as wood :-)

Hi Bruce,

as You said, photons and radiosity are optional. The sense behind CP is to
have the possibility to create a fast rendering animation, or if You know
how, You can use photons and radiosity to prepare a photorealistic high
resolution background picture, which needs hours of rendering time. It's
the users choise. You only need to define a scene after the CP macro in
CrystalPOV.pov and then the molecule will look even more nice. Actually, to
be honest i did not find the right radiosity settings to get out some sense
of this option. :( But i'm still learning and i hope i can create some kind
of picture, even when i'm not a good artist. Lol, the wood carbon texture
was just an example for the use of the texture refining macro. I know it
looks a bit stupid :), i think i'll try to get the brushed metal macro
working with CP and then i'll chnage it.

Thanks for Your comments, Shu.

BtW. There's now the english CrystalPOV.pov with english description
available.

[Bruce] Re: Animation of molecular structures [7801 days 10 hours and 29 minutes ago]

Sat, 27 Nov 2004 00:43:43 GMT

Shurakai a écrit :
> Dear community, dear chemists and crystallographers,
> i proudly present the completed english tutorial for CrystaPOV.

That's really an impressive piece of work! Good job.
I'm not personnally a chimist (rather of of these engineers), but I'm 
sure my student sister will appreciate for his lab works :-)

Just one question : I quickly read Your tutorial and saw a lot of option 
about rendering (especially work on texture or light). The goal of such 
pictures is rather to guve a touchable representation of something hard 
to represent, what is then the goal of exploding time render needed 
(using radiosity for example) just for some "artistic" needs? Anyway, 
that's optionnal, so it won't be boring, but I was wondering the use of 
representing carbon atom as wood :-)

> If You should have comments, critic or a good idea how to improve the whole
> thing, i would be happy if You would tell me.

Not really tested yet (I just quickly read the tutorial), but I'll use 
my last knowledges in chemistry to try it tomorrow

Good night to all Europeans, good evening to American and good morning 
top people living in Asia.


-- 
Bruce

[Shurakai] Animation of molecular structures [7801 days 15 hours and 28 minutes ago]

Fri, 26 Nov 2004 19:45:01 GMT

Dear community, dear chemists and crystallographers,

i proudly present the completed english tutorial for CrystaPOV.
CrystalPOV is a kind of scene template for POV-Ray 3.6, which allows You to
visualize and animate Your molecular structures. Every molecular structure
can be used either a drawn and energy minimized molecule or a measured
x-ray structure due to the MDL *.mol file import option of all structure
viewing software. CrystalPOV has been especially designed for the use with
ORTEP3 but is also functioning with Accelrys DS Viewer 5.0 and Yasara View.
You can animate small molecules, big supramolecular structures, proteins,
surfaces and so on. The limiting factor is (as far as i know) only the time
You want to spend for rendering and parsing :). The tool, tutorial and some
samples can be found here :

http://tilo.ackro.de/CrystalPOV/index.php

Make sure You have at least a DSL connection if You want to read the
tutorial. I added lots of pictures and movies to explain it in detail with
samples for all the options.
If You should have comments, critic or a good idea how to improve the whole
thing, i would be happy if You would tell me.

Shu.

[Anthony D Baye] Re: Lightning? [7807 days 20 hours and 10 minutes ago]

Sat, 20 Nov 2004 15:02:26 GMT

Rune has an electricity macro for use with MegaPov.
http://runevision.com
It's a little old, and it requires Megapov's Glow object, but it works
rather well.
I'll post a demonstration image in P.B.I.

ADB

dave wrote:

> Any idea of how to make lightning between two points?
>
> dave

--
//Anthony D. Baye, Student - Comp.Sci.
#default{pigment{rgb<0,.4,1>}finish{reflection 0.3 specular 0.6}}#macro
m(a,g,e)#local A=0;
#while(A<360)#local
am=a*.75;cylinder{vrotate(a*x,A*g*z),vrotate(am*x,(A+135)*g*z)e}
#local A=A+90;#end #local B=0;#while(B<360)sphere{a*x,e rotate
B/2*g*z}#local B=B+1;
#end #end m(2,1,.03)m(2,-1,.03)light_source{<-3,10,-15>,rgb
1}camera{location-7*z look_at 0}

[Bruce] Re: Lightning? [7809 days 19 hours and 9 minutes ago]

Thu, 18 Nov 2004 16:04:16 GMT

dave a écrit :
> Any idea of how to make lightning between two points?

For animation, I used to draw a random succession of cylinders with no 
shadow and a quite high ambient value
It was between 2 sphere, I drew about 10 cylinders (linked to each other 
with spheres, apex of the 1st one was base of the snd one... and so on) 
and I used random value to jitter those points. After some trys, this 
rendered great as a small electrical arc. I suppose you could use 
somehow the same method to modelize a hige lightning
Regards,

-- 
Bruce

[dave] Lightning? [7809 days 23 hours and 33 minutes ago]

Thu, 18 Nov 2004 11:40:00 GMT

Any idea of how to make lightning between two points?

dave

[Jim Charter] Regdo: locating buttons on calculator in Wings [7824 days 8 hours and 44 minutes ago]

Thu, 4 Nov 2004 02:28:23 GMT

Regdo, You might like to try some variation on these ideas

[Mike Kost] Parametric Objects Tutorial [7863 days 13 hours and 13 minutes ago]

Sat, 25 Sep 2004 22:00:01 GMT

I've written a tutorial on using parametric surfaces. I've posted it at

http://povray.tashcorp.net/tutorials/dd_parametric_objects/

Mike

[SeeSchloss] Re: New CHM [7908 days 13 hours and 59 minutes ago]

Wed, 11 Aug 2004 21:13:57 GMT

On Wed, 11 Aug 2004 23:13:23 +0200, SeeSchloss wrote:

> On Mon, 05 Feb 2001 20:48:21 +0100, Micha Riser wrote:
> 
>> Is there any .CHM browser for linux?
> 
> Yep, there's xchm, you can get it at http://xchm.sourceforge.net chmlib
> also has an utility called chmextract, which dumps the content of a chm
> file in plain html files.

OMG, I need to read the date of the message, next time :D

[SeeSchloss] Re: New CHM [7908 days 14 hours and 1 minute ago]

Wed, 11 Aug 2004 21:12:20 GMT

On Mon, 05 Feb 2001 20:48:21 +0100, Micha Riser wrote:

> Is there any .CHM browser for linux?

Yep, there's xchm, you can get it at http://xchm.sourceforge.net
chmlib also has an utility called chmextract, which dumps the content of a
chm file in plain html files.

[Marneus Calgar] Re: A new radiosity tutorial [8007 days 3 hours and 6 minutes ago]

Wed, 5 May 2004 08:06:58 GMT

Great pictures !!!

-- 

Dark Skull Software
http://www.darkskull.net


"Hildur K." <hil### [at] 3dcafemailevery1net> a écrit dans le message de
news:web.408a8e2a85e6501b32f6017a0@news.povray.org...
> I posted a radiosity tutorial on my website:
>
> http://www.simnet.is/hildurka/pages/raditut1.htm
>
> All comments welcome,
>
> Hildur Kolbrun
>
>

[Rafal 'Raf256' Maj] My first tutorial - media quality [8008 days 19 hours and 33 minutes ago]

Mon, 3 May 2004 15:40:07 GMT

http://www.raf256.com/3d/povray/tutorial/cloudscraper/

Small tutorial about setting media quality, and choosing between fast-
render and nice-render.

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

[Rafal 'Raf256' Maj] Re: A new radiosity tutorial [8008 days 19 hours and 34 minutes ago]

Mon, 3 May 2004 15:39:10 GMT

hil### [at] 3dcafemailevery1net 
news:web.408a8e2a85e6501b32f6017a0@news.povray.org

> http://www.simnet.is/hildurka/pages/raditut1.htm

Very nice images :)

Small sugestion for the WWW site itself, change background color from white 
to dark-gray, so that page is readable before background image is loaded.

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

[Felbrigg] Re: A new radiosity tutorial [8014 days 19 hours and 43 minutes ago]

Tue, 27 Apr 2004 15:29:42 GMT

Good Turorial, Radiosity training sources are always appreciated by me.

 However ( you knew there would be a "however" ) I'd like a bit more info in
your tutorial about the "tinkering" you did to some settrings, not just what
you changed by why.  What were some of the settings you rendered and then
discarded.

That said,  is GREAT!!!!

Thanks.

[Hildur K ] A new radiosity tutorial [8017 days 19 hours and 13 minutes ago]

Sat, 24 Apr 2004 16:00:01 GMT

I posted a radiosity tutorial on my website:

http://www.simnet.is/hildurka/pages/raditut1.htm

All comments welcome,

Hildur Kolbrun

[Marvin Taylor] Re: size limit on binaries ?? [8104 days 18 hours and 9 minutes ago]

Wed, 28 Jan 2004 17:04:11 GMT

MR wrote:
> hello,
> 
> i'm sure its noted somewhere, but instead of me having to dig for
> it could somebody tell me the size limit for binary posts.
> 
> i'm writing a tutorial on a human motion include file, and a few
> sample AVI's just naturally go along with it.  this would push the
> size over 10MB.  most likely this is just way to big of a download
> and i need to do without the demo AVI's.  and i just hate animated
> gifs... i think i'd rather go with a series of stills instead.

As one of many who has fast machines but a SLOOOOWWWW internet 
connection, I'd suggest making a smaller source-only archive for 
downloading.

Thanks!

[AngleWyrm] Re: CHM [8105 days 1 hour and 23 minutes ago]

Wed, 28 Jan 2004 09:49:34 GMT

Logo is a nice touch; a pov animation?

Something that I struggle with, that I could surely use a help file for, is
animation. For instance, a reference page on the necessary parameters
Start_Clock, End_Clock, Start_Frame, Final_Frame (might have got em
wrong--see?)

And I'm still trying to figure out how to make a camera orbit the origin.

[Dayv] Cloth? [8105 days 8 hours and 7 minutes ago]

Wed, 28 Jan 2004 03:05:23 GMT

I've downloaded POV-Man and the ClothRay patch from
http://tofbouf.free.fr/clothray/index_en.html and it's great for making a
cloth to lay on something... draped over an object like a table cloth or a
picnic blanket or bed sheet or something... but I need to make a flag
hanging on a wall and can't find a way to get ClothRay to do that... there
is apparently a way to make hanging cloths with it, but the website is in
French and the English tutorials don't cover that.  Does anyone know how to
use clothray to do what I need or know of something else I might use?  I
tried creating something manualy but it looks too much like it's made of
cardboard rather than a cloth flag.

HELP!

Thanks,
Dayv

[ingo] Re: Lighting question [8201 days 2 hours and 4 minutes ago]

Fri, 24 Oct 2003 09:09:04 GMT

in news:3f9822ff$1@news.povray.org Test User wrote:

> What do you think?
> 

Fine. Some more things you could try to get a more lively text, less flat:
- try a bit of 'turbulence' on the gradient texture
- try adding a 'normal' to the text, maybe also with the gradient pattern

Ingo

[Test User] Re: Lighting question [8201 days 16 hours and 22 minutes ago]

Thu, 23 Oct 2003 18:50:39 GMT

Ah, thanks. I knew I just needed to be pointed in the right direction...

What do you think?

"ingo" <ing### [at] tagpovrayorg> wrote in message
news:Xns### [at] netplexaussieorg...
> in news:3f97f9e7@news.povray.org Test User wrote:
>
> > If anyone can give me any
> > hints or ideas to try I would appreciate it.
> >
> >
>
> A simple solution could be to put a skysphere in your scene and texture it
> with a gradient. Then put a black box behind the text. You'll have to play
> with the colour_map of for the gradient to get the desired result.
>
> Ingo

[ingo] Re: Lighting question [8201 days 19 hours and 6 minutes ago]

Thu, 23 Oct 2003 16:07:08 GMT

in news:3f97f9e7@news.povray.org Test User wrote:

> If anyone can give me any
> hints or ideas to try I would appreciate it.
> 
> 

A simple solution could be to put a skysphere in your scene and texture it 
with a gradient. Then put a black box behind the text. You'll have to play 
with the colour_map of for the gradient to get the desired result.

Ingo

[Test User] Lighting question [8201 days 19 hours and 18 minutes ago]

Thu, 23 Oct 2003 15:55:19 GMT

I just discovered POV-Ray yesterday, gone through the tutorial, played
around along the way... I LOVE using a programming interface for doing this.
Point and click is not my friend. :)

But having little experience with this stuff, I can't quite seem to get my
grip on a problem I'd like to tackle. I have a simple logo that I'd like to
put together, but I can't seem to get the lighting such that it looks even
remotely ok. I can get the text out there, make it metal, but due to the
emptiness of the universe I suppose, the surface is just plain. Here's an
example of what I'd like to do and what I've got. If anyone can give me any
hints or ideas to try I would appreciate it.

Thanks

[caffeinebill] Re: [good tutorial] [8222 days 15 hours and 43 minutes ago]

Thu, 2 Oct 2003 19:30:01 GMT

Tom Galvin wrote:
>"jim" <jpkara at mindspring.com> wrote in message
>news:3c5854fd[at]news.povray.org...
>>
>> From: "C.J. - POV User" <hou### [at] yahoocom>
>> Subject: New tutorial and look for the PRSG(mpeg[at]349kb)
>> Date: Monday, November 20, 2000 4:37 AM
>>
>> Impact is a  tutorial that looks at how to make a multistage animation.
>Once
>> at the site just navigate to the "advance 2" page and click the image.
>> Also, the PRSG has a new look. Opinions?
>>
>> --
>> C.J. - POV User
>> POV Ray Study Gallery
>> www.crosswinds.net/~povstudy
>> hou### [at] yahoocom
>>
>
>http://hyperion.spaceports.com/~povstudy/ is the correct URL now.
>

<a
href="http://users3.ev1.net/~povstudy/i_prsg.htm">http://users3.ev1.net/~povstudy/i_prsg.htm</a>
is the correct URL now.

[St ] Re: Good sPatch tutorial [8240 days 20 hours and 34 minutes ago]

Sun, 14 Sep 2003 14:38:45 GMT

"Ken" <tyl### [at] pacbellnet> wrote in message
news:3F6475E3.E16CD76F@pacbell.net...


> >     Ken, this link doesn't work anymore. Is it a place I may have
> > visited before, but now has a new host/address, etc?
>
> I posted that like 4 1/2 years ago and don't remember for sure
exactly
> which site it was. I suspect it was Anto's sPatch Head Modelling
Tutorial
> because that is the only one I recall seening. You can find that now
at -
>
> http://matkovic.com/anto/


 Thanks Ken, I realise it was some time ago. I just thought you might
have a new link.

  Time wasn't wasted though, I've been meaning to check Anto's Head
Tutorial out, and have now downloaded his .zip file. Thanks for the
'heads' up...   ;)

      ~Steve~

> -- 
> Ken Tyler

[Ken] Re: Good sPatch tutorial [8240 days 21 hours and 6 minutes ago]

Sun, 14 Sep 2003 14:07:11 GMT

"St." wrote:
> 
> "Ken" <tyl### [at] pacbellnet> wrote in message
> news:36E8E387.3DA856FA@pacbell.net...
> > Richard Speir wrote:
> > >
> > > I'm looking for an sPatch tutorial, and am wondering if anyone
> could
> > > provide me with a link. I'm especially interested in organic
> modeling,
> > > specifically plants, but any help would be appreciated. Thanks.
> >
> > Check out the tutorials on this page:
> >
> > http://www.geocities.com/SoHo/Studios/7415/tutorial1.html
> 
>     Ken, this link doesn't work anymore. Is it a place I may have
> visited before, but now has a new host/address, etc?

I posted that like 4 1/2 years ago and don't remember for sure exactly
which site it was. I suspect it was Anto's sPatch Head Modelling Tutorial
because that is the only one I recall seening. You can find that now at -

http://matkovic.com/anto/

-- 
Ken Tyler

[St ] Re: Good sPatch tutorial [8240 days 21 hours and 30 minutes ago]

Sun, 14 Sep 2003 13:42:46 GMT

"Ken" <tyl### [at] pacbellnet> wrote in message
news:36E8E387.3DA856FA@pacbell.net...
> Richard Speir wrote:
> >
> > I'm looking for an sPatch tutorial, and am wondering if anyone
could
> > provide me with a link. I'm especially interested in organic
modeling,
> > specifically plants, but any help would be appreciated. Thanks.
>
> Check out the tutorials on this page:
>
> http://www.geocities.com/SoHo/Studios/7415/tutorial1.html

    Ken, this link doesn't work anymore. Is it a place I may have
visited before, but now has a new host/address, etc?

   ~Steve~


>
> -- 
> Ken Tyler
>
> mailto://tylereng@pacbell.net

[Matthew Pace] media [8265 days 15 hours and 48 minutes ago]

Wed, 20 Aug 2003 19:24:56 GMT

Hello, im looking for a good place for a somewhat n00b to learn media, 
especially light-emitting media.  any suggestions?  thanks a lot in 
advance.
~matt

[Anne Postma] Re: free modeler/renderer [8266 days 22 hours and 48 minutes ago]

Tue, 19 Aug 2003 12:25:07 GMT

Now that's what I call a good tip !!

Thanks !

[Tim Nikias v2 0] Re: Good Particle System Tutorial [8354 days 12 hours and 11 minutes ago]

Fri, 23 May 2003 23:01:37 GMT

Well, here's something nice I've found on the net:

http://www.cs.unc.edu/~davemc/Particle/

aside of that, all I can say: Its not that difficult. I've
been working on a particle system which doesn't
use frame-by-frame output, but instead, works
on iterative steps and thus needs no external files
to generate speeds/positions/directions on a
frame by frame basis.

What you need to do is create a loop, in which a
particle is given a (random) starting position with
a (random) direction, and move it along that
direction, whilst adding gravity. Best is to set a
speed and direction for the particle, both saved in
one vector: the length is the speed, the direction
itself is the direction (doh! :-). For gravity, add
a constant downward vector (like <0,-1,0>) for
every step/frame to the speed/direction-vector
of a particle.
Thus, a particle shoots of and drops due to gravity.
For object-interaction, check the line between newly
calculated point for the frame, and the position before.
This might be achieved using the trace()-function.
Based on the distance from the starting position and
the speed of the particle, calculate the time of impact
and let it repel from there (incoming angle = outcoming
angle).
For better detail, use more discrete steps, e.g. instead
of just calculating the next position, calculate 10 and
check for object-interaction in between.
Problem comes when particles lie on a floor, they tend to
drop through at some point. I'd say take care of that
with an extra check, not just the "normal" object-interaction.

That's the basics. Starting from that, you can do fine
yourself. Its not that difficult, once the first steps are
made and the basic concept has been understood.

Regards,
Tim


-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

> Hello, I need a good particle system tutorial for a beginner to the
subject.
> I have been looking into Runes new app,
> but it is too complicated from the point of view of a beginner.  I know
> there has to be something out there for someone like me...anyone have any
> suggestions?
>
>

[Anubis] Good Particle System Tutorial [8354 days 17 hours and 3 minutes ago]

Fri, 23 May 2003 18:10:14 GMT

Hello, I need a good particle system tutorial for a beginner to the subject.
I have been looking into Runes new app,
but it is too complicated from the point of view of a beginner.  I know
there has to be something out there for someone like me...anyone have any
suggestions?

[AArDvarK] free modeler/renderer [8423 days 4 hours and 48 minutes ago]

Sun, 16 Mar 2003 06:25:15 GMT

http://forms.caligari.com/forms/ts3all_free.html

[Ken] Re: can I get help here? [8431 days 8 hours and 39 minutes ago]

Sat, 8 Mar 2003 02:33:32 GMT

AArDvarK wrote:
> 
> Thank you, I will re-set it up and post an image of
> the problem in here, by tomorrow.

If you post an image please do so in povray.binaries.images. This group
is explicitly for binary tutorials and is not supposed to be used for
posting of images or general text based discussions on using the program.

Please read the info I've provided for our new visitors here -
http://news.povray.org/povray.announce.frequently-asked-questions/26102/185129/?tmax=100#185129

Thanks,

-- 
Ken Tyler - POV-Ray TAG

[AArDvarK] Re: can I get help here? [8431 days 13 hours and 37 minutes ago]

Fri, 7 Mar 2003 21:36:00 GMT

Thank you, I will re-set it up and post an image of
the problem in here, by tomorrow.

Alex


"Txemi Jendrix" <tji### [at] euskalnetnet> wrote in message news:3e68d820@news.povray.org...
| AArDvarK <cravdraa@yahoo*spamless*.com> escribis en el mensaje de noticias
| 3e66f314$1@news.povray.org...
| > Is this a group I can ask for tech-help in?
| >
| > I am using:
| >
| > Poser4.03
| > PoseRay 2.6.6 (as new at it)
| > POVray 3.5 (as new at it)
| > megaPOV 1.0 (as new at it)
| > Truespace 5.1 (not good at it yet)
| > Photoshop 6/7
| > other 2d apps
| >
| > I would like to get a realistic (descent) render
| > from a Poseray .POV export, but I cannot...
| 
| Hi Alex.
| There is no much traffic in this group, but I also use
| Poser, Pov and Poseray.
| I can't get any clue about your problem from your post.
| Can you tell me what warnings give you Povray when you
| try to render, perhaps something related to image maps?.
| Try to be more precisse and maybe we could help you.
| Bye
| 
| Txemi Jendrix
| http://www.txemijendrix.com
| 
| 
|

[Txemi Jendrix] RE: can I get help here? [8431 days 17 hours and 38 minutes ago]

Fri, 7 Mar 2003 17:34:24 GMT

AArDvarK <cravdraa@yahoo*spamless*.com> escribió en el mensaje de noticias
3e66f314$1@news.povray.org...
> Is this a group I can ask for tech-help in?
>
> I am using:
>
> Poser4.03
> PoseRay 2.6.6 (as new at it)
> POVray 3.5 (as new at it)
> megaPOV 1.0 (as new at it)
> Truespace 5.1 (not good at it yet)
> Photoshop 6/7
> other 2d apps
>
> I would like to get a realistic (descent) render
> from a Poseray .POV export, but I cannot...

Hi Alex.
There is no much traffic in this group, but I also use
Poser, Pov and Poseray.
I can't get any clue about your problem from your post.
Can you tell me what warnings give you Povray when you
try to render, perhaps something related to image maps?.
Try to be more precisse and maybe we could help you.
Bye

Txemi Jendrix
http://www.txemijendrix.com

[AArDvarK] Re: can I get help here? [8432 days 5 hours and 49 minutes ago]

Fri, 7 Mar 2003 05:23:54 GMT

Thank you Ingo, I like that page.
Alex

"ingo" <ing### [at] tagpovrayorg> wrote in message news:Xns### [at] povrayorg...
| in news:3e66f314$1@news.povray.org AArDvarK wrote:
| 
| 
| > Is this a group I can ask for tech-help in?
| 
| Not realy, read the group povray.announce.frequently-asked-questions there 
| is a posting by Ken in it that explains it all.
|  
| > I would like to get a realistic (descent) render
| > from a Poseray .POV export, but I cannot...
| > 
| 
| Altough it does not use the same tools you have, have a look at this:
| 
| http://www.oyonale.com/ressources/english/tutuv.htm
| 
| Ingo

[ingo] Re: can I get help here? [8432 days 19 hours and 16 minutes ago]

Thu, 6 Mar 2003 15:56:36 GMT

in news:3e66f314$1@news.povray.org AArDvarK wrote:

> Is this a group I can ask for tech-help in?

Not realy, read the group povray.announce.frequently-asked-questions there 
is a posting by Ken in it that explains it all.

> I would like to get a realistic (descent) render
> from a Poseray .POV export, but I cannot...
> 

Altough it does not use the same tools you have, have a look at this:

http://www.oyonale.com/ressources/english/tutuv.htm

Ingo

[AArDvarK] can I get help here? [8433 days 4 hours and 8 minutes ago]

Thu, 6 Mar 2003 07:04:52 GMT

Is this a group I can ask for tech-help in?

I am using:

Poser4.03
PoseRay 2.6.6 (as new at it)
POVray 3.5 (as new at it)
megaPOV 1.0 (as new at it)
Truespace 5.1 (not good at it yet)
Photoshop 6/7 
other 2d apps 

I would like to get a realistic (descent) render
from a Poseray .POV export, but I cannot...

Alex

[autowitch] Re: Sea? [8523 days 16 hours and 45 minutes ago]

Thu, 5 Dec 2002 18:27:29 GMT

Sean,

Christoph Hormann wrote a good tutorial on this.  Take a look at
http://www-public.tu-bs.de:8080/~y0013390/pov/water/

This is probably the wrong newsgroup for this question though.  Try the
.newusers group.  A lot more people will be looking in that one and you will
get more thoughts on the subject.
--
autowitch
http://www.autowitch.org

"Sean Connolly" <Sm.### [at] btopenworldcom> wrote in message
news:3def9457@news.povray.org...
> How can I get a realistic (or even a not so realistic) sea? I'm very new
to
> this and I'm still figuring out how to do things, so any help would be
> appreciated, thanks. :)
>
>

[Sean Connolly] Sea? [8523 days 17 hours and 12 minutes ago]

Thu, 5 Dec 2002 18:00:55 GMT

How can I get a realistic (or even a not so realistic) sea? I'm very new to
this and I'm still figuring out how to do things, so any help would be
appreciated, thanks. :)

[Wade] Help to do a lamp shade [8642 days 14 hours and 46 minutes ago]

Thu, 8 Aug 2002 20:26:53 GMT

I'd like to see how to do a lamp shade (either stained-glass shade, plastic
or paper).  I want to do it long hand.

Wade
__________________________________________________________________ Wade
Markham ICQ#: 44258048 Current ICQ status: + More ways to contact me i See
more about me:
__________________________________________________________________

[Le Forgeron] Re: THE BEST resource I have found for Animation... [8719 days 21 hours and 52 minutes ago]

Thu, 23 May 2002 13:20:41 GMT

Bryan Valencia wrote:

> This one is WAY BEYOND anything I have seen on this subject.
> 
> 
> http://vcdhelp.com/
> 
> All it needs now is a discussion of how to turn 40 billion frames and 20
> thousand individual sound snippets into an MPEG-1 file.
> 
> 
> 

Note: If it is for a DVD, it's MPEG-2 !

A 4 Hours DVD, at 24 fps, has only 345600 frames.
With an average of 100k per frame, all you would
need is a 35 TB disk for the pictures, before encoding.

-- 
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,
Ne pas être obligé d'en rien rendre à César,
Vis-à-vis de soi-même en garder le mérite,
Bref, dédaignant d'être le lierre parasite,
Lors même qu'on n'est pas le chêne ou le tilleul,
Ne pas monter bien haut, peut-être, mais tout seul !

[bob h] Re: Help to do a tree [8725 days 5 hours and 21 minutes ago]

Sat, 18 May 2002 05:51:32 GMT

"Mymy Go" <mym### [at] wanadoofr> wrote in message
news:3ce2c17c$1@news.povray.org...
>
>   I only need to program from a to z a tree on Pov Ray and I would like
not
> to use macros or programs form the others.....only a "manual"
program...:o)
> Do you have any helps for me?

Maybe some clarification is needed here, I didn't understand your question
exactly. Do you want to learn how to script one of your own? Or to use an
include file which creates trees for use in POV-Ray. I ask that because when
you said the word "programs", to me, that sounds like you didn't want to use
ready-made include files. So, a tutorial about how to go about this would be
what you want I guess. I don't know of one myself. However...

A complicated (to me) how-to see this:
http://www.cs.mcgill.ca/~svasil/557/Report557.htm

If not a tutorial, but program to input variables and get output then maybe
check here: http://showcase.netins.net/web/wolf359/gra_3d.htm

Someone might see and answer your question better from povray.general, you
happened to ask this in a binaries group which is only for posting tutorial
files.

bob h

[Mymy Go] Help to do a tree [8727 days 14 hours and 59 minutes ago]

Wed, 15 May 2002 20:13:48 GMT

I only need to program from a to z a tree on Pov Ray and I would like not
to use macros or programs form the others.....only a "manual" program...:o)
Do you have any helps for me?

thx!!

[Bryan Valencia] THE BEST resource I have found for Animation DVD... [8742 days 15 hours and 8 minutes ago]

Tue, 30 Apr 2002 20:05:12 GMT

This one is WAY BEYOND anything I have seen on this subject.


http://vcdhelp.com/

All it needs now is a discussion of how to turn 40 billion frames and 20
thousand individual sound snippets into an MPEG-1 file.

[Gleb] Coloured Raytracer.pov [8784 days 10 hours and 6 minutes ago]

Wed, 20 Mar 2002 01:07:15 GMT

see povray.beta-test

[Dawn McKnight] Re: Stained glass how-to or examples? [8813 days 13 hours and 35 minutes ago]

Mon, 18 Feb 2002 21:38:10 GMT

I think the easiest way to do this would be to use an image map to a 
png, with the palatted colors keyed to different levels of transmit.

Mark M. Wilson wrote:

>Has anyone seen examples of stained glass windows in their "travels"
>through the world of ray tracery?  I'm working on a virtual cathedral
>project and I'd like to get some ideas about how to do the windows, esp.
>the right degree of opacity/translucence.
>THanks for anything,
>Mark M. Wilson
>

[ingo] Splines.bas [8814 days 23 hours and 38 minutes ago]

Sun, 17 Feb 2002 11:35:16 GMT

A basic file (from c.g.r.r) by Steve Noskowicz, showing the basis matrices 
of various splines and their use.

Ingo

[Mark M Wilson] Stained glass how-to or examples? [8816 days 15 hours and 20 minutes ago]

Fri, 15 Feb 2002 19:53:14 GMT

Has anyone seen examples of stained glass windows in their "travels"
through the world of ray tracery?  I'm working on a virtual cathedral
project and I'd like to get some ideas about how to do the windows, esp.
the right degree of opacity/translucence.
THanks for anything,
Mark M. Wilson

[Tom Galvin] Re: [good tutorial] [8829 days 17 hours and 11 minutes ago]

Sat, 2 Feb 2002 18:02:00 GMT

"jim" <jpkara at mindspring.com> wrote in message
news:3c5854fd@news.povray.org...
>
> From: "C.J. - POV User" <hou### [at] yahoocom>
> Subject: New tutorial and look for the PRSG(mpeg@349kb)
> Date: Monday, November 20, 2000 4:37 AM
>
> Impact is a  tutorial that looks at how to make a multistage animation.
Once
> at the site just navigate to the "advance 2" page and click the image.
> Also, the PRSG has a new look. Opinions?
>
> --
> C.J. - POV User
> POV Ray Study Gallery
> www.crosswinds.net/~povstudy
> hou### [at] yahoocom
>

http://hyperion.spaceports.com/~povstudy/ is the correct URL now.

[jim] [good tutorial] [8832 days 14 hours and 55 minutes ago]

Wed, 30 Jan 2002 20:18:05 GMT

From: "C.J. - POV User" <hou### [at] yahoocom>
Subject: New tutorial and look for the PRSG(mpeg@349kb)
Date: Monday, November 20, 2000 4:37 AM

Impact is a  tutorial that looks at how to make a multistage animation. Once
at the site just navigate to the "advance 2" page and click the image.
Also, the PRSG has a new look. Opinions?

--
C.J. - POV User
POV Ray Study Gallery
www.crosswinds.net/~povstudy
hou### [at] yahoocom

[Dawn McKnight] Re: povray DECALS [8834 days 18 hours and 8 minutes ago]

Mon, 28 Jan 2002 17:04:42 GMT

Antonio Garrido wrote:

> somebody knows how to apply decals in povray?

There's an excellent tutorial on this, using the example of sticking a
label on a beer bottle, at
<http://www.spiritone.com/~english/cyclopedia/bottle.html>.

It was of imense help to me when I started putting decals on my
starfighter.

[Ken] Re: povray DECALS [8858 days 7 hours and 58 minutes ago]

Sat, 5 Jan 2002 03:14:25 GMT

Peter Popov wrote:
> 
> On Thu, 3 Jan 2002 16:41:57 -0000, "Antonio Garrido" <aga### [at] ctves>
> wrote:
> 
> >somebody knows how to apply decals in povray?
> >thanks a lot
> 
> It's all in the docs, namely in the section on layered textures.

And image_map.

-- 
Ken Tyler

[Peter Popov] Re: povray DECALS [8858 days 13 hours and 30 minutes ago]

Fri, 4 Jan 2002 21:43:06 GMT

On Thu, 3 Jan 2002 16:41:57 -0000, "Antonio Garrido" <aga### [at] ctves>
wrote:

>somebody knows how to apply decals in povray?
>thanks a lot

It's all in the docs, namely in the section on layered textures.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

[Antonio Garrido] povray DECALS [8858 days 15 hours and 53 minutes ago]

Fri, 4 Jan 2002 19:20:00 GMT

somebody knows how to apply decals in povray?
thanks a lot
Antonio

[Preacher Dave] Re: Ocean or sea tutorial? [8897 days 7 hours and 18 minutes ago]

Tue, 27 Nov 2001 03:54:43 GMT

"Arie L. Stavchansky" <ari### [at] andrewcmuedu> wrote in message
news:B7EB5364.12BA%ari### [at] andrewcmuedu...
> Hi there,
>
> I'm interested in finding out if there is a tutorial on how to make
> realistic water planes.  This is similar to what is found in packages like
> Bryce.  Does anybody have any sample code that I can use?  Also, how I can
I
> make a sun appear as though it is setting on the horizon.  Thanks for your

http://free.prohosting.com/~olana/povray/povray.html has what you need and
more

[Jack] POVMan 0.71.4 with ClothRay [8909 days 19 hours and 11 minutes ago]

Wed, 14 Nov 2001 16:02:07 GMT

Hi:

I am looking around for some detailed tutorials on using ClothRay in
animations that involve mesh objects as the environment for the cloth mesh.

I have had very good results with merging my POSER characters into POVMan
based on MegaPOV 0.7 based on POV-Ray 3.1 (I just love how much this has
grow in the last few years.).

Anyway,  I want to start making more realistic clothing for my characters
and the cloth mesh just seems to float on through my character mesh.

Best regards,
Jack

[Arie L Stavchansky] Ocean or sea tutorial? [8943 days 17 hours and 26 minutes ago]

Thu, 11 Oct 2001 17:47:16 GMT

Hi there,

I'm interested in finding out if there is a tutorial on how to make
realistic water planes.  This is similar to what is found in packages like
Bryce.  Does anybody have any sample code that I can use?  Also, how I can I
make a sun appear as though it is setting on the horizon.  Thanks for your
help.

Arie

[Wilson Reis] Re: Help with povray! [8947 days 7 hours and 51 minutes ago]

Mon, 8 Oct 2001 03:21:31 GMT

Well, it's not clear for me if it was a question or a statement, but i think
i could explain that "abs" and "&" thing.

Will
Horrible POVer
Horrible writing in english
Fairly decent math student


"Phil Clute" <pcl### [at] tiacnet> escreveu na mensagem
news:392C1EA6.C3B78DC1@tiac.net...
> For Isosurfaces definately start at Samuel's site:
> http://members.aol.com/stbenge/
> ...and then move over to Mike's page:
> http://www.econym.demon.co.uk/isotut/
>
> Just go through each lesson one at a time and try them out. I still
> think isosurfaces are confusing but I understand how to use them better
> and I'm learning more all them time. I would like to understand more
> clearly why each thing works the way it does... for instance why does
> "abs" mirror the opposite side, or why does "&" cause an intersection?
> etc.
>
> --
> Phil
> ...coffee?...yes please! extra sugar,extra cream...Thank you.

[Thomas Baier] Re: Poser Conversion Tutorial [9039 days 5 hours and 35 minutes ago]

Sun, 8 Jul 2001 05:37:27 GMT

On Fri, 6 Jul 2001 13:10:50 +0100, "Tom Melly" <tom### [at] tomandlucouk>
wrote:

you mention a bug in 3DWin trying version 3 of your tutorial.
Could you be more specific so i can fix it?

Thnx

-tb

>I've started work on a Poser 3 to Megapov 7 tutorial
>
>http://www.tomandlu.co.uk/raytracing/postut/
>
>By no means complete, but any comments appreciated.

[Tom Melly] Poser Conversion Tutorial [9040 days 23 hours and 2 minutes ago]

Fri, 6 Jul 2001 12:10:51 GMT

I've started work on a Poser 3 to Megapov 7 tutorial

http://www.tomandlu.co.uk/raytracing/postut/

By no means complete, but any comments appreciated.

--
#macro G(D,E,F)#local I=array[3]{D,E,F}#local B=0;triangle{#while(
B<3)#while(I[B])A[mod(I[B],10)]+#local I[B]=div(I[B],10);#end<-5,-
2,9>#local B=B+1;#end}#end #local A=array[7]{x,x*2,x*4,y,y*2,y*4,z
}light_source{-x*6-z*9,1}mesh{G(105,10,146)G(105,246,10)G(105,56,
146)G(105,1256,246)G(1256,126,220)G(22156,2216,201)pigment{rgb 1}}//TM

[John Albarelli] Breeze Tutorial? [9050 days 20 hours and 49 minutes ago]

Tue, 26 Jun 2001 14:23:45 GMT

Anyone know of a good online Breeze Designer tutorial?  Especially making
blobs...I can't seem to get two blob objects to interact.  Thanks.

John

[dioptase] Camera [9054 days 3 hours and 12 minutes ago]

Sat, 23 Jun 2001 08:01:21 GMT

I'm looking for informations (url, books, algorithms...) about a roll
function that could be used with PovRay cameras and sky parameter. This is
implemented in Moray program and very useful...
The objective is to compute the coordinates of sky vector from location and
lookat points, to roll the camera around the line of sight with a
determinate value.

        Eric

[Batronyx] Re: Leaving a wake in water. . . [9065 days 16 hours and 47 minutes ago]

Mon, 11 Jun 2001 18:26:08 GMT

Dayv wrote in message <3b2194c8@news.povray.org>...
>I'm working on an animation.  I have a plane with a water material and I
>want to have 2 spheres travel through the water and leave a wake as they
>travel... any thoughts on how this could be done???
>

Just off of the top of my head, and completely untried:

Use a heightfield. Difference either a box the size of your heigtfield, or
separate heightfield representing only the y-extruded xz profile of your wake
heightfield, and then drop your wake heightfield into the hole. This would only
define the general shape of the wake. You might then find Chris Colefax's
spray.inc useful for the burst of spray either side of the wake.

Hope that helps with a place to start.

----------------------------------------
Batronyx ^"^
bat### [at] cadronhsacom
http://www.batronyx.com
Bhuddist monk to hotdog vendor:
     "Make me one with everything."
----------------------------------------

[Dayv] Leaving a wake in water. . . [9068 days 7 hours and 58 minutes ago]

Sat, 9 Jun 2001 03:15:20 GMT

I'm working on an animation.  I have a plane with a water material and I
want to have 2 spheres travel through the water and leave a wake as they
travel... any thoughts on how this could be done???

Thanks,
Dayv

[Jon Berndt] Media tutorials? [9140 days 19 hours and 26 minutes ago]

Wed, 28 Mar 2001 15:47:17 GMT

Where can I find a good media tutorial that covers ALL of media?

[Pedro Bravo] Re: Cloth Simulator documentation in Windows Hel... [9149 days 12 hours and 1 minute ago]

Mon, 19 Mar 2001 23:11:36 GMT

Hey Mike, I had the exact problem... You just have to run the instalation
program and select "Install from Internet", then it's going to ask for some
things, internet connection, etc. and then it's going to give you a list of
things. Select ONLY cygwin(don't-remember-the-exact-name) (note that for
selecting you mustn't use the square box, you click on the version)... you
have to unselect all others... i think then it'll download and install the
thing automatically.
bye

> Wasn't it Pedro Bravo who wrote:
> >Hi all
> >I spent all of my day working on this... initially it was just for me,
> >but it occured to me to put it here...
> >...hope Jerome doesn't get mad because I "stole" his docs...
> >anyway, I hope it'll be useful to someone
>
> Does anybody have an idiots guide to obtaining the cygwin DLL file
> that's required for the windows version?
>
> Christoph Hormann's page simply says
>
>   For running this version you will need the Cygwin DLL that is
>   available on http://sources.redhat.com/cygwin/
>
> but the installer on that page asks all sorts of questions that I don't
> seem to be guessing the correct answers to, and I just seem to have
> ended up with an icon for the PIF for the Cygnus Bash Shell (whatever
> that is) on my dektop, and a C:\WINDOWS\Desktop\latest directory full of
> *.tar.gz files (whatever they are), but no DLLs.
>
> --
> Mike Williams
> Gentleman of Leisure

[Christoph Hormann] Re: Cloth Simulator documentation in Windows Hel... [9149 days 12 hours and 6 minutes ago]

Mon, 19 Mar 2001 23:06:41 GMT

Mike Williams wrote:
> 
> but the installer on that page asks all sorts of questions that I don't
> seem to be guessing the correct answers to, and I just seem to have
> ended up with an icon for the PIF for the Cygnus Bash Shell (whatever
> that is) on my dektop, and a C:\WINDOWS\Desktop\latest directory full of
> *.tar.gz files (whatever they are), but no DLLs.
> 

The setup program allows to selectively download the single packages.  You
only need cygwin-x.x.x.tar.gz where x.x.x stands for the version number,
for example:

ftp://ftp.franken.de/pub/win32/develop/gnuwin32/cygwin/mirrors/cygnus/latest/cygwin/cygwin-1.1.8-2.tar.gz

or from any other mirror site.  

If you have already installed cygwin, the dll is probably in the /bin
directory of the cygwin installation (you specified it after starting the
installation).  If you only downloaded the packed files, look for the one
starting with cygwin and unpack it.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

[ingo] Re: Cloth Simulator documentation in Windows Hel... [9149 days 13 hours and 23 minutes ago]

Mon, 19 Mar 2001 21:49:39 GMT

in <oM1dcAArUnt6EwM+@econym.demon.co.uk> Mike Williams wrote:

>Does anybody have an idiots guide to obtaining the cygwin DLL file
>that's required for the windows version? 

if the dll is all you need:

http://download.lycos.com/swbasic/BasicResults.asp?query=cygwin1.dll

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

[Mike Williams] Re: Cloth Simulator documentation in Windows Hel... [9149 days 13 hours and 55 minutes ago]

Mon, 19 Mar 2001 21:18:11 GMT

Wasn't it Pedro Bravo who wrote:
>Hi all
>I spent all of my day working on this... initially it was just for me,
>but it occured to me to put it here...
>...hope Jerome doesn't get mad because I "stole" his docs...
>anyway, I hope it'll be useful to someone

Does anybody have an idiots guide to obtaining the cygwin DLL file
that's required for the windows version? 

Christoph Hormann's page simply says 

  For running this version you will need the Cygwin DLL that is 
  available on http://sources.redhat.com/cygwin/ 

but the installer on that page asks all sorts of questions that I don't
seem to be guessing the correct answers to, and I just seem to have
ended up with an icon for the PIF for the Cygnus Bash Shell (whatever
that is) on my dektop, and a C:\WINDOWS\Desktop\latest directory full of
*.tar.gz files (whatever they are), but no DLLs.

-- 
Mike Williams
Gentleman of Leisure

[Pedro Bravo] Cloth Simulator documentation in Windows Help fo... [9151 days 7 hours and 16 minutes ago]

Sun, 18 Mar 2001 03:56:35 GMT

Hi all
I spent all of my day working on this... initially it was just for me,
but it occured to me to put it here...
...hope Jerome doesn't get mad because I "stole" his docs...
anyway, I hope it'll be useful to someone

[Fabien HENON] Re: New CHM [9191 days 13 hours and 42 minutes ago]

Mon, 5 Feb 2001 21:30:37 GMT

inclosed is my own itss.dll.(found in windows system in a win ME).

Hope it solves the problem

I know the chm files are closely linked to IE5. They need a HH.exe
executable to be read and it is installed with IE5.



Arne Kleinophorst a écrit :

> Micha Riser schrieb:
> >
> > Is there any .CHM browser for linux?
> >
> > --
> > Micha Riser       email address: mri### [at] gmxnet
> > http://www.povworld.de/   The World of POV-Ray!
>
> it's not even working with Win ME on my Computer. I get a crash with
> itss.dll when trying to open it?
>
> Greets, Arne

[Fabien HENON] Re: New CHM [9191 days 13 hours and 48 minutes ago]

Mon, 5 Feb 2001 21:24:24 GMT

alas no. I am.

But the chm files can be converted into HMTL and or PDF ( not easily
though).
If you ever find something, please tell me.

Micha Riser a écrit :

> Is there any .CHM browser for linux?
>
> --
> Micha Riser       email address: mri### [at] gmxnet
> http://www.povworld.de/   The World of POV-Ray!

[Arne Kleinophorst] Re: New CHM [9191 days 14 hours and 46 minutes ago]

Mon, 5 Feb 2001 20:26:58 GMT

Micha Riser schrieb:
> 
> Is there any .CHM browser for linux?
> 
> --
> Micha Riser       email address: mri### [at] gmxnet
> http://www.povworld.de/   The World of POV-Ray!

it's not even working with Win ME on my Computer. I get a crash with
itss.dll when trying to open it?

Greets, Arne

[Micha Riser] Re: New CHM [9191 days 15 hours and 25 minutes ago]

Mon, 5 Feb 2001 19:48:21 GMT

Is there any .CHM browser for linux?

--
Micha Riser       email address: mri### [at] gmxnet
http://www.povworld.de/   The World of POV-Ray!

[Fabien HENON] New CHM [9192 days 13 hours and 17 minutes ago]

Sun, 4 Feb 2001 21:55:45 GMT

You can download a new version of the CHM file I compiled.

This one contains news objects : height_fields, lathes, prisms, box,
sphere, torus and a few more. There are still a few mistakes.

Next step : add a search index, and finish with the objects.

URL :
http://perso.club-internet.fr/ffjhenon/

As always any comments are welcomed.
Hope this is useful to newcomers.


Fabien

[Artemia Salina] Re: Another format 185 Kb [9223 days 1 hour and 53 minutes ago]

Fri, 5 Jan 2001 09:19:34 GMT

Fabien HENON wrote:

> This one written with the new Windows format : chm.
> Although it is only readable (AFAIK) on the Windows OSes, I will use
> this format from now on.

Why?

> CHM can be converted into HTM and then into PDF.

Why use a "new" Windows only format for documentation when HTML will
suffice?
How are users of other OS's supposed to convert CHM into a readable
format on
their machines?

[samrat] Re: Linux Pov Ray [9235 days 8 hours and 17 minutes ago]

Sun, 24 Dec 2000 02:55:58 GMT

Ken wrote:

> 
> 
> Javier Belanche wrote:
> > 
> > I have some problems with the installation of POV on Linux. What's the
> > right way to go on?
> > 
> > thanks!
> 
> On this news server is a group called 'povray.unix'. You should
> repost your question there so that you get the help you need.
> 
yeh taats right

[samrat] Re: New tutorial and look for the PRSG(mpeg@349kb) [9235 days 8 hours and 18 minutes ago]

Sun, 24 Dec 2000 02:54:47 GMT

C.J. - POV User wrote:

> Impact is a  tutorial that looks at how to make a multistage animation.
> Once at the site just navigate to the "advance 2" page and click the
> image. Also, the PRSG has a new look. Opinions?
> 
> --
> C.J. - POV User
> POV Ray Study Gallery
> www.crosswinds.net/~povstudy
> hou### [at] yahoocom
> 
> 
good

[Fabien HENON] CHM [9245 days 11 hours and 50 minutes ago]

Wed, 13 Dec 2000 23:23:15 GMT

I deleted it yesterday by mistake. That was a blunder. There it is
again.

Fabien

[Fabien HENON] Re: New one [9245 days 12 hours ago]

Wed, 13 Dec 2000 23:13:03 GMT

Thanks for all the remarks. When I have some time I'll finish with the objects
and then with the textures. As it's the hardest part in POV, don't expect it to
be finished before next year.

Thanks again for the encouragements.

Fabien

Mick Hazelgrove a écrit :

> Excellent work - keep them coming!
>
> BTW The tutorial has cleared up a lot of  my problems with up and right.
> Some pics as examples of different camera types would be nice.
>
> Mick
>
> "Bob H."
> <per### [at] aolcom?subject=PoV-News:%20&body=Relating%20to%20POV-Ray:>
> wrote in message news:3a371180$1@news.povray.org...
> > Got a look at it yesterday and it opened at a perfect window size.  Not
> full
> > screen here at 1152x864 but just right for the tutorial panes.
> >
> > Bob H.
> >
> >
> >

[Mick Hazelgrove] Re: New one [9245 days 16 hours and 45 minutes ago]

Wed, 13 Dec 2000 18:28:01 GMT

Excellent work - keep them coming!

BTW The tutorial has cleared up a lot of  my problems with up and right.
Some pics as examples of different camera types would be nice.

Mick


"Bob H."
<per### [at] aolcom?subject=PoV-News:%20&body=Relating%20to%20POV-Ray:>
wrote in message news:3a371180$1@news.povray.org...
> Got a look at it yesterday and it opened at a perfect window size.  Not
full
> screen here at 1152x864 but just right for the tutorial panes.
>
> Bob H.
>
>
>

[Bob H ] Re: New one [9246 days 5 hours and 8 minutes ago]

Wed, 13 Dec 2000 06:04:48 GMT

Got a look at it yesterday and it opened at a perfect window size.  Not full
screen here at 1152x864 but just right for the tutorial panes.

Bob H.

[Sander] Re: light source & camera CHM help 496 Kb [9246 days 21 hours and 5 minutes ago]

Tue, 12 Dec 2000 14:08:00 GMT

in povray.binaries.tutorials, Fabien HENON says...
> Thanks for the remark.
> For the chm file, I merely downloaded HTML Help Workshop from the
> Microsoft
> site to compile it.
> The pages are first built with Netscape HTML editor (Composer).
> Once the pages are finished, they have to be indexed and compiled with
> HHW.
> It is a great tool.
> Yet I had to learn with errors and trials ( it reminds me of POV).
> I still have to find how to use the 'search' tab properly. It might be
> useful.

Thanks for the information: I'll have a try as soon as my system is in 
order (hangs repeatedly...)

> 
> You mentionned HCW. Is it another compiler? I'd like to know about
> Microsoft
> competitors if there are any.

No competitor: it is MS Help Workshop. I got it together with Borland's 
C++ version 5 and also a more recent version came with Borland C++Builder 
v5. The funny thing is both HCW.exe's are accompanied by HCRTF.exe that 
looks the same, has nearly the same version number, but is smaller. It 
suggests that it has to do with RTF files. I haven't used it not looked 
into the help file.
This is what the directory contains, where I have the most recent 
HCW.exe:
===================
hcw.GID      130139 08-12-2000      14:56 H  A
hcw.FTG      245760 13-08-2000      15:19     
hcw.FTS      362496 13-08-2000      15:19     
hcrtf.exe    276480 31-01-2000      04:00     
hcw.cnt       18428 31-01-2000      04:00     
hcw.exe      500736 31-01-2000      04:00     
hcw.hlp      631431 31-01-2000      04:00     
hwdll.dll    154112 31-01-2000      04:00     
===================

> 
> As the file is getting larger and larger, I think I'll have to upload
> the file to my new site. The download speed might improve.
> 
> 
> Cheers
> 
> Fabien

In short: I am not very well 'au courant' with the help compiler business 
:)  But it works and it is able to generate very large help files.

-- 
Regards,  Sander

[Bob H ] Re: light source & camera CHM help 496 Kb [9247 days 3 hours and 15 minutes ago]

Tue, 12 Dec 2000 07:57:23 GMT

"Fabien HENON" <ffj### [at] club-internetfr> wrote in message
news:3A355F8F.8FE15821@club-internet.fr...
>
> I am going to make it appear maximized on opening. I found the right flag for
that.
>

Better you than me.  I say again, it's a good work you have begun.

Bob H.

[Fabien HENON] Re: light source & camera CHM help 496 Kb [9247 days 12 hours and 5 minutes ago]

Mon, 11 Dec 2000 23:08:11 GMT

"Bob H." a écrit :

> "Fabien HENON" <ffj### [at] club-internetfr> wrote in message
> news:3A30DF45.407DFB8A@club-internet.fr...
> > Here a version of POV-help compiled in chm format including light and
> > camera with a few enhancements.
> > It is designed to be viewed at 1024 x 768.
> > At 800 x 600, the layout is sopmewhat destroyed.
>
> First of all it's great work, concise and easy to follow.

Thanks

> I didn't proof read
> but I scanned over the segments and it all looked good to me, with the one
> exception that your white light bulb is yellow which might confuse someone.
> That's in the light_source segment on "color".  The cyan light bulb is okay but
> then comparing that with the white light bulb (which shows as yellow as I said)
> then you expect a yellowish light source.  Reading of course clears that up
> but... an incorrectness I'd say.

Yes that's true, I just wanted to make a normal light bulb which yellow. But I'll
correct that.

>
> Only other thing that caught my attention was the "tightness" article, but I
> think you are showing as much as possible at once.  The radius 18 falloff 18
> along with tightness 100.  I think it works okay, but I stopped to wonder if
> someone without any knowledge of it would stumble over that.  It's probably
> just because it's all old stuff to me and yet I still have to think as I type
> those keywords in, you know, like my thinking getting in the way.
> I'm anticipating seeing how this tutorial grows.

I am going to deal with objects now. It's going to be a bit tougher (or at least
longer)

>
>
> Oh, one other thing.  When I first ran these two chm files they started too
> small for me, about a 250x250 square window so I maximized them.  After closing
> and opening again they came up as almost full screen (1152x864 res. here) but
> not maximized.  You said 1024x768 so that made me think they were supposed to
> open at that res.  What I'm seeing now is really that they are maximized minus
> the window borders.  Just the first ever run time was small.

I am going to make it appear maximized on opening. I found the right flag for that.

>
>
> Bob H.

Fabien HENON

[Bob H ] Re: light source & camera CHM help 496 Kb [9249 days 11 hours and 8 minutes ago]

Sun, 10 Dec 2000 00:04:57 GMT

"Fabien HENON" <ffj### [at] club-internetfr> wrote in message
news:3A30DF45.407DFB8A@club-internet.fr...
> Here a version of POV-help compiled in chm format including light and
> camera with a few enhancements.
> It is designed to be viewed at 1024 x 768.
> At 800 x 600, the layout is sopmewhat destroyed.

First of all it's great work, concise and easy to follow.  I didn't proof read
but I scanned over the segments and it all looked good to me, with the one
exception that your white light bulb is yellow which might confuse someone.
That's in the light_source segment on "color".  The cyan light bulb is okay but
then comparing that with the white light bulb (which shows as yellow as I said)
then you expect a yellowish light source.  Reading of course clears that up
but... an incorrectness I'd say.
Only other thing that caught my attention was the "tightness" article, but I
think you are showing as much as possible at once.  The radius 18 falloff 18
along with tightness 100.  I think it works okay, but I stopped to wonder if
someone without any knowledge of it would stumble over that.  It's probably
just because it's all old stuff to me and yet I still have to think as I type
those keywords in, you know, like my thinking getting in the way.
I'm anticipating seeing how this tutorial grows.

Oh, one other thing.  When I first ran these two chm files they started too
small for me, about a 250x250 square window so I maximized them.  After closing
and opening again they came up as almost full screen (1152x864 res. here) but
not maximized.  You said 1024x768 so that made me think they were supposed to
open at that res.  What I'm seeing now is really that they are maximized minus
the window borders.  Just the first ever run time was small.

Bob H.

[Fabien HENON] Re: light source & camera CHM help 496 Kb [9249 days 13 hours and 32 minutes ago]

Sat, 9 Dec 2000 21:41:20 GMT

Thanks for the remark.
For the chm file, I merely downloaded HTML Help Workshop from the
Microsoft
site to compile it.
The pages are first built with Netscape HTML editor (Composer).
Once the pages are finished, they have to be indexed and compiled with
HHW.
It is a great tool.
Yet I had to learn with errors and trials ( it reminds me of POV).
I still have to find how to use the 'search' tab properly. It might be
useful.

You mentionned HCW. Is it another compiler? I'd like to know about
Microsoft
competitors if there are any.

As the file is getting larger and larger, I think I'll have to upload
the file to my new site. The download speed might improve.


Cheers

Fabien


Sander a écrit :

> in povray.binaries.tutorials, Fabien HENON says...
> > Here a version of POV-help compiled in chm format including light and
> > camera with a few enhancements.
> > It is designed to be viewed at 1024 x 768.
> > At 800 x 600, the layout is sopmewhat destroyed.
> >
> > Remarks and comments are warmly welcomed.
> >
> > Fabien.
>
> Looks good! I have learned something about lights just now!!
>
> Then I am also intrigued by the HH-workshop; I have used the HCW program
> a little and I was baffled by the spaghetti-like set of pages one has to
> make for even a small help file. After some time I completely lost the
> overview, but that may be just me. Now, looking for the HHW files, I
> found them to be very expensive. What do you use??
> --
> Regards,  Sander

[Sander] Re: light source & camera CHM help 496 Kb [9250 days 13 hours and 16 minutes ago]

Fri, 8 Dec 2000 21:56:38 GMT

in povray.binaries.tutorials, Fabien HENON says...
> Here a version of POV-help compiled in chm format including light and
> camera with a few enhancements.
> It is designed to be viewed at 1024 x 768.
> At 800 x 600, the layout is sopmewhat destroyed.
> 
> Remarks and comments are warmly welcomed.
> 
> Fabien.

Looks good! I have learned something about lights just now!!

Then I am also intrigued by the HH-workshop; I have used the HCW program 
a little and I was baffled by the spaghetti-like set of pages one has to 
make for even a small help file. After some time I completely lost the 
overview, but that may be just me. Now, looking for the HHW files, I 
found them to be very expensive. What do you use??
-- 
Regards,  Sander

[Fabien HENON] light source & camera CHM help 496 Kb [9250 days 21 hours and 8 minutes ago]

Fri, 8 Dec 2000 14:05:16 GMT

Here a version of POV-help compiled in chm format including light and
camera with a few enhancements.
It is designed to be viewed at 1024 x 768.
At 800 x 600, the layout is sopmewhat destroyed.

Remarks and comments are warmly welcomed.

Fabien.

[ingo] Re: Another format 185 Kb [9253 days 19 hours and 7 minutes ago]

Tue, 5 Dec 2000 16:06:02 GMT

Fabien HENON wrote:

>Is the font size too small or too large ?

 A little too small for reading big pieces, ok for a quick look up.

>I'll try keeping the same layout but with a smaller font size.

 Maybe a smaller indentation (2 spaces)? Especially in "look_at".

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

[Fabien HENON] Re: Another format 185 Kb [9254 days 12 hours and 56 minutes ago]

Mon, 4 Dec 2000 22:16:47 GMT

ingo a écrit :

> Fabien HENON wrote:
>
> >This one written with the new Windows format : chm.
> >
>
> Fabien,
> I think I prefer this over a pdf, but I have some questions and remarks.

Thanks for the remark.

>
>
> Is it possible to make the font size adjustable for the user?
>

As far as what I have seen with HTML Help Workshop,  the font can only be set
at compilation time.
Is the font size too small or too large ?

>
> How far do you intend to go with the "linking", will it be possible to
> jump from normal:Valid values to any of the patters?

Yes. That's something I'll do but only at the end.

>
>
> When not running full-screen, the bits of scene code next to the pictures
> get cut off in such a way that it's not "readable" anymore. Maybe put it
> over or under the pictures.
>

Thanks, that's a problem I overlooked. I might relunctantly have to change
the layout of the examples (I loved this one). I'll try keeping the same
layout but with a smaller font size.
I don't think that an example code with its rendered image at the bottom will
look great.

>
> With TAB it's possible to jump from the list on the left to the text on
> the right and then scroll with the arrow keys. There seems to be no
> keyboard way back though.
>

There might be hotkeys to include before the compilation for the navigation,
but I have not found them yet.
The TAB key does not do anything on my computer.

Merci

Fabien

>
> Ingo
>
> --
> Photography: http://members.home.nl/ingoogni/
> Pov-Ray    : http://members.home.nl/seed7/

[ingo] Re: Another format 185 Kb [9254 days 18 hours and 49 minutes ago]

Mon, 4 Dec 2000 16:23:30 GMT

Fabien HENON wrote:

>This one written with the new Windows format : chm.
>

Fabien,
I think I prefer this over a pdf, but I have some questions and remarks.

Is it possible to make the font size adjustable for the user?

How far do you intend to go with the "linking", will it be possible to 
jump from normal:Valid values to any of the patters?

When not running full-screen, the bits of scene code next to the pictures 
get cut off in such a way that it's not "readable" anymore. Maybe put it 
over or under the pictures.

With TAB it's possible to jump from the list on the left to the text on 
the right and then scroll with the arrow keys. There seems to be no 
keyboard way back though.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

[Fabien HENON] Re: camera [9255 days 13 hours and 17 minutes ago]

Sun, 3 Dec 2000 21:55:43 GMT

I will have to take the project a bit further for it to be interesting.
When the light and objects are finished.

Fabien.

Micha Riser a écrit :

> very nice!
>
> you might be interested about the pov-ray tutorial book project we just
> have started. See
>  http://www.povworld.de/book/
> for further infos. Feel free to join our team.
>
> - Micha

[Fabien HENON] Another format 185 Kb [9255 days 13 hours and 24 minutes ago]

Sun, 3 Dec 2000 21:49:19 GMT

First, thanks for the feedback I had for the previous 'tutorials' I
posted.

Here is another format of the camera tutorial which was translated into
PDF.
This one written with the new Windows format : chm.
Although it is only readable (AFAIK) on the Windows OSes, I will use
this format from now on.
CHM can be converted into HTM and then into PDF.

Next one will be 'lights'

Fabien

[Micha Riser] Re: camera [9256 days 12 hours and 18 minutes ago]

Sat, 2 Dec 2000 22:54:55 GMT

very nice!

you might be interested about the pov-ray tutorial book project we just
have started. See 
 http://www.povworld.de/book/
for further infos. Feel free to join our team.

- Micha

[Fabien HENON] camera [9259 days 11 hours and 31 minutes ago]

Wed, 29 Nov 2000 23:42:02 GMT

Another one about cameras

[C J - POV User] Re: New tutorial and look for the PRSG(mpeg@349kb) [9268 days 7 hours and 17 minutes ago]

Tue, 21 Nov 2000 03:55:55 GMT

OK, it sould be right now....
=P

--
C.J. - POV User
POV Ray Study Gallery
www.crosswinds.net/~povstudy
hou### [at] yahoocom
Christoph Hormann <Chr### [at] schunteretctu-bsde> wrote in message
news:3A193E94.D0E21969@schunter.etc.tu-bs.de...
>
>
> "C.J. - POV User" wrote:
> >
> > Impact is a  tutorial that looks at how to make a multistage animation.
Once
> > at the site just navigate to the "advance 2" page and click the image.
> > Also, the PRSG has a new look. Opinions?
> >
>
> Some links are wrong: if you want to change to a different tutorial
> section after selecting one the links go to something like:
>
> file:///C:/My%20Documents/My%20Webs/tutorial-main.htm
>
> The layout looks good, but i still don't like your Pov code formating with
> proportional font and no indention. :-)
>
> Christoph
>
> --
> Christoph Hormann <chr### [at] gmxde>
> Homepage: http://www.schunter.etc.tu-bs.de/~chris/

[C J - POV User] Re: New tutorial and look for the PRSG(mpeg@349kb) [9268 days 7 hours and 19 minutes ago]

Tue, 21 Nov 2000 03:54:10 GMT

OIC...
That would make it easier to read. I never realy notice myself, but I will
make sure that I address that with any additional tutorials in the future.

Thanks!
--
C.J. - POV User
POV Ray Study Gallery
www.crosswinds.net/~povstudy
hou### [at] yahoocom

Chris Huff <chr### [at] maccom> wrote in message
news:chrishuff-2061CE.17444620112000@news.povray.org...
> In article <3a195b41@news.povray.org>, "C.J."
> <hou### [at] yahoocom> wrote:
>
> > BTW - I understand about the indenting, but what is wrong with
> > proportional fonts? My main concern is for easy reading...
>
> Code doesn't "line up" as well when using a proportional font. That is
> why nearly all programmers use a fixed-width font, it makes the layout
> of the code easier and far more readable when all characters are the
> same width.
>
> In addition, it will make the code snippets "stand out" more, so the
> reader can identify them more quickly.
>
> --
> Christopher James Huff
> Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
> TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
>
> <><

[Chris Huff] Re: New tutorial and look for the PRSG(mpeg@349kb) [9268 days 12 hours and 28 minutes ago]

Mon, 20 Nov 2000 22:44:24 GMT

In article <3a195b41@news.povray.org>, "C.J." 
<hou### [at] yahoocom> wrote:

> BTW - I understand about the indenting, but what is wrong with 
> proportional fonts? My main concern is for easy reading...

Code doesn't "line up" as well when using a proportional font. That is 
why nearly all programmers use a fixed-width font, it makes the layout 
of the code easier and far more readable when all characters are the 
same width.

In addition, it will make the code snippets "stand out" more, so the 
reader can identify them more quickly.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

[C J ] Re: New tutorial and look for the PRSG(mpeg@349kb) [9268 days 18 hours and 1 minute ago]

Mon, 20 Nov 2000 17:11:29 GMT

I know that when I ran a test of the site from home everything was fine. I
guess I did not notice that it was pulling the pages from my hard drive and
not what was up on the site. Bummer!
I also noted that the right hand side of some of the table cells are to
wide, causing a repeat in the background image. Doh!

...and I was so close!

C.J. - POV User
BTW - I understand about the indenting, but what is wrong with proportional
fonts? My main concern is for easy reading...

Christoph Hormann <Chr### [at] schunteretctu-bsde> wrote in message
news:3A193E94.D0E21969@schunter.etc.tu-bs.de...
>
>
> "C.J. - POV User" wrote:
> >
> > Impact is a  tutorial that looks at how to make a multistage animation.
Once
> > at the site just navigate to the "advance 2" page and click the image.
> > Also, the PRSG has a new look. Opinions?
> >
>
> Some links are wrong: if you want to change to a different tutorial
> section after selecting one the links go to something like:
>
> file:///C:/My%20Documents/My%20Webs/tutorial-main.htm
>
> The layout looks good, but i still don't like your Pov code formating with
> proportional font and no indention. :-)
>
> Christoph
>
> --
> Christoph Hormann <chr### [at] gmxde>
> Homepage: http://www.schunter.etc.tu-bs.de/~chris/

[Christoph Hormann] Re: New tutorial and look for the PRSG(mpeg@349kb) [9268 days 20 hours and 4 minutes ago]

Mon, 20 Nov 2000 15:09:07 GMT

"C.J. - POV User" wrote:
> 
> Impact is a  tutorial that looks at how to make a multistage animation. Once
> at the site just navigate to the "advance 2" page and click the image.
> Also, the PRSG has a new look. Opinions?
> 

Some links are wrong: if you want to change to a different tutorial
section after selecting one the links go to something like:

file:///C:/My%20Documents/My%20Webs/tutorial-main.htm

The layout looks good, but i still don't like your Pov code formating with
proportional font and no indention. :-)

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/

[C J - POV User] New tutorial and look for the PRSG(mpeg@349kb) [9268 days 22 hours and 29 minutes ago]

Mon, 20 Nov 2000 12:44:03 GMT

Impact is a  tutorial that looks at how to make a multistage animation. Once
at the site just navigate to the "advance 2" page and click the image.
Also, the PRSG has a new look. Opinions?

--
C.J. - POV User
POV Ray Study Gallery
www.crosswinds.net/~povstudy
hou### [at] yahoocom

[Peter J Holzer] Re: New doc [9270 days 10 hours and 11 minutes ago]

Sun, 19 Nov 2000 01:01:51 GMT

On Thu, 16 Nov 2000 14:16:00 +0100, Fabien HENON wrote:
>Il s'agit d'un message multivolet au format MIME.
>--------------DB2B8FB4AEE0A511EF40ABED
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>For a try, I have 'converted' the POV documentation into a new form
>which I find more readable.
>Then again, this is just a beginning, and I have started with the part
>which is the hardest to me : Interior and media.
>
>It is not finished yet, but I'd like some feedback to know if it might
>be useful to some of you and what improvements can be added.
>It works best with Acrobat Reader 4.0 (the one with indexes on the left)
>

Things I like:

  * Different colors for text, code, default values, etc.

  * Sans serif font for text (better for reading on screen, though I
    prefer serifed fonts on paper).

  * The open parentheses which indicates whether the keyword opens a
    block.

Things I don't like:

  * Text is too wide. Keep it to about 2/3 of the page. 

  * Same font for text and examples. I'd prefer examples to be set in a
    fixed-width font (but not Courier, if possible), but at least it
    should be different from text so that you can use the same font in
    the text for short code snippets (alternatively you could use the
    same color).

  * The layout is strange. E.g., on p. 7 the example looks like:

	interior {
	          media {
		         absorption rgb <0.4,0.9,0.7> } }
    
    but it should be either on one line or look like:

	interior {
	    media {
		absorption rgb <0.4,0.9,0.7>
	    }
	}
    
    i.e. consistend indentation and closing parethesis below
    corresponding keyword.

    On p. 9 there are alernatively short and long lines!

  * Missing syntax.

Things I'm not sure about:

  * The yellowish background. It's quite nice on screen, but might cause
    problems with printing (poor contrast, slow printing, high toner
    usage). Most people seem to prefer to print long PDF files.



-- 
   _  | Peter J. Holzer    | Perl ist der geglückte Versuch, einen
|_|_) | Sysadmin WSR       | braindump direkt ausführbar zu machen.
| |   | hjp### [at] wsracat      |    -- Lutz Donnerhacke in dasr.
__/   | http://www.hjp.at/ |

[Matt Giwer] comment on tutorials [9270 days 22 hours and 38 minutes ago]

Sat, 18 Nov 2000 12:35:01 GMT

One way or another they all have their good points. But may I point to
some existing documentation? 

	The basic HTML docs are quite good. As you go through them there are
fragments of code and changes in code used to illustrate points without
illustrations, i.e. included images. 

	I have been thinking about going through the docs and creating those
illustrations. However I am not the kind of person who can go through a
project like that start to finish. And I have been procrastinating over
starting for over a year now. And I have no idea if such a project is
already underweigh or if it has been tried and found not worth it. 

	With that I leave it open to any discussion it generates. 

-- 
It must be terrible to be bound by the past 
or in hopes of the future. 
	-- The Iron Webmaster, 169

[Christoph Hormann] Re: New doc [9271 days 12 hours and 18 minutes ago]

Fri, 17 Nov 2000 22:54:35 GMT

Fabien HENON wrote:
> 
> >
> > - fixed width font for code parts
> 
> Could you explain what you mean ?
> 

It's very common to do code parts in a non proportional font for better
readability.

> 
> By the way, this is not meant to replace the official documentation, but
> merely an alternative.
> 

Maybe you should consider making it more different from the official docu,
which is mainly designed for reference (apart from the 'beginning
tutorial' section)

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/

[Fabien HENON] Re: New doc [9271 days 14 hours and 7 minutes ago]

Fri, 17 Nov 2000 21:06:11 GMT

Christoph Hormann a écrit :

> It looks good for a first try, but i personally don't find it that easy to
> read :-)
>
> Some things that i find very good in the official docu and that are
> missing in your version:
>
> - fixed width font for code parts

Could you explain what you mean ?

>
> - keywords highlighted in the main text

I'll give the dealt-with keywords a different color from the rest of the
text.
Red should stand out.

>
> - cross links in the text

That's something I'll add when it is finished.

>
>
> i also miss the complete syntax description like:
>
> INTERIOR:
>   interior { [INTERIOR_IDENTIFIER] [INTERIOR_ITEMS...] }
> INTERIOR_ITEM:
>   ior Value | caustics Value |
>   fade_distance Distance | fade_power Power
>   MEDIA...
>

That's precisely the point. For a beginner, the complete syntax is
rather
obscure. You don't know what is inside what and what keywords are
allowed.
ie : for the INTERIOR_ITEMS, you have to refer to the INTERIOR_ITEM
below. And if you want to add some media, you have to follow your way
down to the MEDIA_ITEM.
I like the 'tree' shown in the index of Acrobat. It displays the
'parents' and 'children' links : You have to use 'interior' first to be
allowed to use 'media' in an object. 

But then again these statements are mine and mine only.

By the way, this is not meant to replace the official documentation, but
merely an alternative.

>
> Of course these are only my personal preferences.
>
> Christoph
>
> --
> Christoph Hormann <chr### [at] gmxde>
> Homepage: http://www.schunter.etc.tu-bs.de/~chris/

[Christoph Hormann] Re: New doc [9271 days 21 hours and 16 minutes ago]

Fri, 17 Nov 2000 13:57:21 GMT

It looks good for a first try, but i personally don't find it that easy to
read :-)

Some things that i find very good in the official docu and that are
missing in your version:

- fixed width font for code parts
- keywords highlighted in the main text
- cross links in the text

i also miss the complete syntax description like:

INTERIOR:
  interior { [INTERIOR_IDENTIFIER] [INTERIOR_ITEMS...] }
INTERIOR_ITEM:
  ior Value | caustics Value | 
  fade_distance Distance | fade_power Power
  MEDIA...


Of course these are only my personal preferences. 

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/

[Fabien HENON] Re: New doc [9272 days and 30 minutes ago]

Fri, 17 Nov 2000 10:42:49 GMT

I'll mention it in the next version.
If I am right, negative ior values give a kind of glow. I definitely have to try
this one again.

Thanks for the comment.

Pabs a écrit :

> Fabien HENON wrote:
>
> > It is not finished yet, but I'd like some feedback to know if it might
> > be useful to some of you and what improvements can be added.
>
> In the ior section you might mention something about negative ior values after
> you experiment with them.
> --
> Bye
> Pabs

[Pabs] Re: New doc [9272 days 7 hours and 57 minutes ago]

Fri, 17 Nov 2000 03:15:25 GMT

Fabien HENON wrote:

> It is not finished yet, but I'd like some feedback to know if it might
> be useful to some of you and what improvements can be added.

In the ior section you might mention something about negative ior values after
you experiment with them.
--
Bye
Pabs

[Fabien HENON] New doc [9272 days 22 hours ago]

Thu, 16 Nov 2000 13:12:45 GMT

For a try, I have 'converted' the POV documentation into a new form
which I find more readable.
Then again, this is just a beginning, and I have started with the part
which is the hardest to me : Interior and media.

It is not finished yet, but I'd like some feedback to know if it might
be useful to some of you and what improvements can be added.
It works best with Acrobat Reader 4.0 (the one with indexes on the left)

Cheers

Fabien

[Ken] Re: pov objects [9346 days 6 hours and 47 minutes ago]

Mon, 4 Sep 2000 04:25:31 GMT

ingo wrote:
> 
> §FireFly§ wrote:
> 
> >I cant find the povobjects page can someone please tell me the address
> >to it
> >
> http://cgi-bin.spaceports.com/~pov/cgi-bin/objlist.cgi

That is a bad link.

Try this one instead - http://povobjects.virtualave.net/

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[ingo] Re: pov objects [9346 days 14 hours and 58 minutes ago]

Sun, 3 Sep 2000 20:15:21 GMT

§FireFly§ wrote:

>I cant find the povobjects page can someone please tell me the address
>to it 
>
http://cgi-bin.spaceports.com/~pov/cgi-bin/objlist.cgi

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

[] pov objects [9346 days 18 hours and 17 minutes ago]

Sun, 3 Sep 2000 16:55:36 GMT

I cant find the povobjects page can someone please tell me the address to it

thanks Jason

[Chris Huff] Re: Source Code [9351 days 20 hours and 49 minutes ago]

Tue, 29 Aug 2000 14:24:08 GMT

In article <39ABC052.BBC6408B@pacbell.net>, lin### [at] povrayorg 
wrote:

> Not that I am aware of though I seem to remember that Chris Huff
> has a tutorial on writing patches for the program that may be
> of some interest to you.
> 
> http://chrishuff.dhs.org/

My new web site is http://homepage.mac.com/chrishuff/. The dhs.org one 
will be updated someday, but for now, I am only using mac.com. Anyway, 
the tutorial isn't on the web page, it is right in this group:
Chris Huff <chr### [at] yahoocom> Making POV Patches(first draft) - 
attached files (1/1)  360 99.12.05 1:11 PM

I doubt it will be much help though...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

[Ken] Re: Source Code [9351 days 21 hours and 16 minutes ago]

Tue, 29 Aug 2000 13:56:23 GMT

Mathias wrote:
> 
> Does there exist an tutorial for the Source Code from POV Ray ?

Not that I am aware of though I seem to remember that Chris Huff
has a tutorial on writing patches for the program that may be
of some interest to you.

http://chrishuff.dhs.org/

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Mathias] Source Code [9351 days 22 hours and 37 minutes ago]

Tue, 29 Aug 2000 12:35:52 GMT

Does there exist an tutorial for the Source Code from POV Ray ?

Thxs,
Mathias

[Mathias] Source Code [9351 days 22 hours and 38 minutes ago]

Tue, 29 Aug 2000 12:34:54 GMT

Does there exist an tutorial for the Source Code from POV Ray ?

Thxs,
Mathias

[Christoph Hormann] Re: Media tutorial (emission) [9372 days 1 hour and 39 minutes ago]

Wed, 9 Aug 2000 09:34:07 GMT

Toni Bratincevic wrote:
> 
> http://members.xoom.com/Intercepto/tutorials/media.zip
> 
> There are probably many mistakes in grammar, because my english is not very
> good.
> The document is doc-word95 format and it has 2.8 mb zipped (9mb unzipped)
> and it explains some basics of some advanced techniques.
> 
> I would like If you send me any comments about tutorial, some corrections,
> proposals.
> 
> I will continue writing this tutorial and explain many situations where
> media can be used, specially emission, but I would like now to get feedback
> from you.
> 
> Toni.

Looks impressively detailed, even though you totally focus on emitting media. 
Nice detailed introduction into the density stuff.  The warptexture macro seems
a good idea, even though i did not yet get to really understand it :-)

How about converting it to HTML and putting it on the Web...

Christoph

--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/

[Toni Bratincevic] Media tutorial (emission) [9372 days 1 hour and 56 minutes ago]

Wed, 9 Aug 2000 09:17:15 GMT

http://members.xoom.com/Intercepto/tutorials/media.zip

There are probably many mistakes in grammar, because my english is not very
good.
The document is doc-word95 format and it has 2.8 mb zipped (9mb unzipped)
and it explains some basics of some advanced techniques.

I would like If you send me any comments about tutorial, some corrections,
proposals.

I will continue writing this tutorial and explain many situations where
media can be used, specially emission, but I would like now to get feedback
from you.

Toni.

[Ken] Re: Linux Pov Ray [9380 days 13 hours and 37 minutes ago]

Mon, 31 Jul 2000 21:36:06 GMT

Javier Belanche wrote:
> 
> I have some problems with the installation of POV on Linux. What's the right
> way to go on?
> 
> thanks!

On this news server is a group called 'povray.unix'. You should
repost your question there so that you get the help you need.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Javier Belanche] Linux Pov Ray [9380 days 14 hours and 55 minutes ago]

Mon, 31 Jul 2000 20:17:53 GMT

I have some problems with the installation of POV on Linux. What's the right
way to go on?

thanks!

[Bob Hughes] Re: Help with povray! [9397 days and 9 minutes ago]

Sat, 15 Jul 2000 11:04:20 GMT

"Bob Hughes" <per### [at] aolcom?subject=PoV-News:> wrote in message
news:396fbf18@news.povray.org...
| "Ian Witham" <ian### [at] hotmailcom> wrote in message
| news:396e47bc@news.povray.org...
| |
| | Stranger still... I just installed the new version of OE and now the
message
| | reads properly "//" cool!
|
| file://Not for me it doesn't, and I just D/L the IE 5.01 SP1 a few days ago.
| Is that the 5.5 beta by any chance?  Never mind, it is.  I just now looked at
| your message post properties.  Well that's good news then, thanks for the
| insight.

Forget what I said (secondly anyway) because I hadn't realized my OE was now at
version 5.5 despite IE only being 5.01 still.  Maybe it's the IE version that
matters?  This is OT so maybe I should ask in povray.off-topic while there's a
recent IE 5.5 discussion.

Bob

[Bob Hughes] Re: Help with povray! [9397 days 9 hours and 41 minutes ago]

Sat, 15 Jul 2000 01:32:08 GMT

"Ian Witham" <ian### [at] hotmailcom> wrote in message
news:396e47bc@news.povray.org...
|
| Stranger still... I just installed the new version of OE and now the message
| reads properly "//" cool!

file://Not for me it doesn't, and I just D/L the IE 5.01 SP1 a few days ago.
Is that the 5.5 beta by any chance?  Never mind, it is.  I just now looked at
your message post properties.  Well that's good news then, thanks for the
insight.

Bob

[Peter Hertel] SV: Tip pop up in HTML for media [9398 days 11 hours and 26 minutes ago]

Thu, 13 Jul 2000 23:46:41 GMT

> > You will find the very beginning (it's just a sketch) of what I did.
> > The doc is written in HTML. I have one question for the webmasters : Is
> > there a way to display a comment ( just like Excel or Word) in a HTML
> > page when you move your mouse over either a word or a link.

If it's a tooltip you want you can do it with javascript.
I don't know it, but I've seen it done. I can't remember where though..

There might be some tutorials about it here:
http://www.pageresource.com/jscript/index2.htm
http://htmlgoodies.earthweb.com/beyond/js.html

--
Peter
http://hertel.no/bigone

[Ian Witham] Re: Help with povray! [9398 days 12 hours and 22 minutes ago]

Thu, 13 Jul 2000 22:50:36 GMT

"Marc-Hendrik Bremer" <Mar### [at] t-onlinede> wrote in message
news:396df42c$1@news.povray.org...
> That was probably your Newsreader, which 'thought' this was the beginning
of
> a link and extended it. OE does something like that at least.
> >

Stranger still... I just installed the new version of OE and now the message
reads properly "//" cool!

[Marc-Hendrik Bremer] Re: Help with povray! [9398 days 18 hours and 19 minutes ago]

Thu, 13 Jul 2000 16:54:04 GMT

That was probably your Newsreader, which 'thought' this was the beginning of
a link and extended it. OE does something like that at least.

Marc-Hendrik

Ian Witham schrieb in Nachricht <396dcc0e@news.povray.org>...

>How strange.. surely you mean "//" not "file://"?
>
>

[Ian Witham] Re: Help with povray! [9398 days 21 hours and 10 minutes ago]

Thu, 13 Jul 2000 14:02:54 GMT

> Try to analyze the sample scenes coming along with standard POV. Simply
> manipulate them a bit and look what happens. Remember that you can
> comment out the old code with "file://". So it is easy to undo your
> manipulation.

How strange.. surely you mean "//" not "file://"?

[Karl Pelzer] Re: Help with povray! [9399 days 4 hours and 37 minutes ago]

Thu, 13 Jul 2000 06:35:48 GMT

Try to analyze the sample scenes coming along with standard POV. Simply
manipulate them a bit and look what happens. Remember that you can
comment out the old code with "//". So it is easy to undo your
manipulation.
If you manipulate a certain instruction you can read the according
paragraph in the manual.
I know that might be hard, but it works. I hope you have a fast enough
computer for your testings ;-)

Karl

[Bob Hughes] Re: Okay? HeLp Me PlEaSe... [9408 days 6 hours and 21 minutes ago]

Tue, 4 Jul 2000 04:51:45 GMT

To further compliment Ken's reply:

+a0.2 +r2 +am2 +j1

...on the command-line or...

Antialias_Threshold=0.2  ;+a  with 0.3 is default
Antialias_Depth=2  ;+r  uses integers 1 to 5 typically(?)
Sampling_Method=2  ;+am  the type to use, 1 default
Jitter=1  ;+j  0 to 1  (use +j0 when animating)

put into an INI file can yield fairly good results, just beware of longer
render times the lower +a goes and higher +r goes.  It's all relative to those
settings.
Have a read of your POV-Scene help file or document regarding antialiasing
options.  Important stuff.

Bob

[Ken] Re: Okay? HeLp Me PlEaSe... [9408 days 9 hours and 17 minutes ago]

Tue, 4 Jul 2000 01:56:01 GMT

Jade Hewitt wrote:
> 
> Hi! I kind of new to this, so can anyone give me some tips on how to like
> keep the roughness out of my picture? I don't know if any of you know what
> I'm talking about, but if you do please help. Thanx!
> 
>             Jade

I believe you are referring to the evil "jaggies". If so you need
to use anti-aliasing when rendering your images. You can turn on
AA by putting the appropriate switch in a .ini file or on the
command line (see the docs for which switch to use). If you are
using the Windows version of the program you should see a window
in the tool bar for setting image size. It also has options for
No AA or with AA you can try to see if it fixes your problem. Also
remember the larger you render your image the more pixels you have
avialable. Larger images will always give better results.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Jade Hewitt] Okay? HeLp Me PlEaSe... [9408 days 9 hours and 27 minutes ago]

Tue, 4 Jul 2000 01:46:14 GMT

Hi! I kind of new to this, so can anyone give me some tips on how to like
keep the roughness out of my picture? I don't know if any of you know what
I'm talking about, but if you do please help. Thanx!

            Jade

[Fabien Hénon] Re: Very rough draft tutorial [9444 days 13 hours and 8 minutes ago]

Sun, 28 May 2000 22:05:13 GMT

I forgot :

The first file to open is index.html.

Fabien Hénon

Fabien Hénon a écrit :

> Just for fun, I wanted to use frames for the POVRAY documentation in
> HTML.
>
> I say it again, it is only a trial. Only a some links about the camera
> statements works ( those underlined).
>
> It is best viewed at 1024 x 768 with either Netscape 4.7 or IE 5 (even
> though there is no javascript yet).
>
> Tell me what you think and most important your suggestions.
>
> I started this after a visist on Popeney's site on javascript :
>
> http://www.calpoly.edu/~dpopeney/javascript.html
>
> Fabien Hénon
>
>   ------------------------------------------------------------------------
>               Name: doc.zip
>    doc.zip    Type: Download Fichier (application/zip)
>           Encoding: base64

[Fabien Hénon] Very rough draft tutorial [9444 days 13 hours and 48 minutes ago]

Sun, 28 May 2000 21:24:52 GMT

Just for fun, I wanted to use frames for the POVRAY documentation in
HTML.

I say it again, it is only a trial. Only a some links about the camera
statements works ( those underlined).

It is best viewed at 1024 x 768 with either Netscape 4.7 or IE 5 (even
though there is no javascript yet).

Tell me what you think and most important your suggestions.

I started this after a visist on Popeney's site on javascript :

http://www.calpoly.edu/~dpopeney/javascript.html


Fabien Hénon

[Phil Clute] Re: Help with povray! [9448 days 16 hours and 51 minutes ago]

Wed, 24 May 2000 18:22:06 GMT

For Isosurfaces definately start at Samuel's site:
http://members.aol.com/stbenge/
...and then move over to Mike's page:
http://www.econym.demon.co.uk/isotut/

Just go through each lesson one at a time and try them out. I still
think isosurfaces are confusing but I understand how to use them better
and I'm learning more all them time. I would like to understand more
clearly why each thing works the way it does... for instance why does
"abs" mirror the opposite side, or why does "&" cause an intersection?
etc.

-- 
Phil
...coffee?...yes please! extra sugar,extra cream...Thank you.

[Psychomek] Re: Help with povray! [9448 days 21 hours and 42 minutes ago]

Wed, 24 May 2000 13:30:34 GMT

Tried that but for some reason it is just not clicking in my head. :{

Saadat Saeed wrote:

> Try starting with the POV manuals for the standard version of POV. I
> started out that way..... and am improving (I hope)!
>
> BR/Saadat
>
> Psychomek wrote:
>
> > Help i need tutorials for Megapov 0.5 out the wazoo cause i can't seem
> > to get through my thick skull how to do the Pov script.
> > I need this in a tutorial:
> >             1. Language simple enough for a 4 yo could understand
> >             2. one that assumes that you know absolutely nothing about
> > the code.
> >             3. one that is understandable after being awake 36 hours.
> >             4. and it should include Media, Isosurface, photons, and
> > most desperately TEXTURES (Can't figure them out)
> >
> > So please help me!  I'm almost at my wits end i have tried reading the
> > Povray manual but after 12 hours of work it is totally confusing.
> > please help me!

[Saadat Saeed] Re: Help with povray! [9450 days 2 hours and 34 minutes ago]

Tue, 23 May 2000 08:39:18 GMT

Try starting with the POV manuals for the standard version of POV. I
started out that way..... and am improving (I hope)!

BR/Saadat

Psychomek wrote:

> Help i need tutorials for Megapov 0.5 out the wazoo cause i can't seem
> to get through my thick skull how to do the Pov script.
> I need this in a tutorial:
>             1. Language simple enough for a 4 yo could understand
>             2. one that assumes that you know absolutely nothing about
> the code.
>             3. one that is understandable after being awake 36 hours.
>             4. and it should include Media, Isosurface, photons, and
> most desperately TEXTURES (Can't figure them out)
>
> So please help me!  I'm almost at my wits end i have tried reading the
> Povray manual but after 12 hours of work it is totally confusing.
> please help me!

[Psychomek] Help with povray! [9450 days 4 hours and 50 minutes ago]

Tue, 23 May 2000 06:22:44 GMT

Help i need tutorials for Megapov 0.5 out the wazoo cause i can't seem
to get through my thick skull how to do the Pov script.
I need this in a tutorial:
            1. Language simple enough for a 4 yo could understand
            2. one that assumes that you know absolutely nothing about
the code.
            3. one that is understandable after being awake 36 hours.
            4. and it should include Media, Isosurface, photons, and
most desperately TEXTURES (Can't figure them out)

So please help me!  I'm almost at my wits end i have tried reading the
Povray manual but after 12 hours of work it is totally confusing.
please help me!

[Saadat Saeed] Re: Lightbulb [9452 days 3 hours and 5 minutes ago]

Sun, 21 May 2000 08:08:22 GMT

thankyou

[Saadat Saeed] CAR! [9452 days 3 hours and 9 minutes ago]

Sun, 21 May 2000 08:03:53 GMT

Anyone has a tutorial on creating a CAR in POV!

I am not talking about a F1 Car tutorial on Spatch I saw somewhere....

I am taking about a standard car like a FIAT UNO or a Toyota Camry!!!!!

BR/Saadat

[Peter Hertel] SV: matrix keyword tutorial [9454 days 15 hours and 9 minutes ago]

Thu, 18 May 2000 20:04:01 GMT

Thank you very much. That's exactly what I was looking for
Peter


Ken <tyl### [at] pacbellnet> wrote in message
news:3921D82D.7A563167@pacbell.net...
>
>
> Peter Hertel wrote:
> >
> > I once came by a tutorial which described the matrix keyword very well
(for
> > my needs)
> > But I've lost the bookmark, and I can't find it in the links section at
> > povray.org
> > I belive I found the link povray.general newsgroup some time ago..
>
> There are two you can look at -
>
> http://www.gate.net/~shipbrk/raytrace/matrix.html
>
> http://www.erols.com/vansickl/matrix.htm
>
> --
> Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
> http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Ken] Re: matrix keyword tutorial [9456 days 11 hours and 48 minutes ago]

Tue, 16 May 2000 23:24:50 GMT

Peter Hertel wrote:
> 
> I once came by a tutorial which described the matrix keyword very well (for
> my needs)
> But I've lost the bookmark, and I can't find it in the links section at
> povray.org
> I belive I found the link povray.general newsgroup some time ago..

There are two you can look at -

http://www.gate.net/~shipbrk/raytrace/matrix.html

http://www.erols.com/vansickl/matrix.htm

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Peter Hertel] matrix keyword tutorial [9456 days 11 hours and 50 minutes ago]

Tue, 16 May 2000 23:22:31 GMT

I once came by a tutorial which described the matrix keyword very well (for
my needs)
But I've lost the bookmark, and I can't find it in the links section at
povray.org
I belive I found the link povray.general newsgroup some time ago..

--
Peter
http://hertel.no/bigone

[Chris Huff] Re: Isosurface Tutorial updated [9458 days 15 hours and 38 minutes ago]

Sun, 14 May 2000 19:35:14 GMT

In article <ZTq### [at] econymdemoncouk>, Mike Williams 
<mik### [at] econymdemoncouk> wrote:

> Using a negative threshold isn't a solution, it just makes the surface
> that you're interested in larger. MegaPOV still treats locations where
> the function is numerically less than the threshold as "inside".

Er, right...what was I thinking?
Just using the negative of the function should work though.

> Experiments also reveal that "open inverse" produces a rather different
> effect from "sign -1". In CSG, the "open" seems to be ignored most of
> the time, so the objects intersect with just the "inverse", i.e. the
> positive copy of the target surface inside an inverse contained_by
> object.

Yes, this is right. It should work fine in media, but not with CSG.
And I don't remember why I thought "open" was necessary(I must have 
written that in a moment of caffeine deprivation). "inverse" should work 
the same as "sign -1", though. They both have the effect of flipping the 
inside and outside, right? Or is my brain still short-circuiting?

> The problematic surfaces seem to be those in the i_algbr library where
> the origin lies in the region that we would intuitively consider to be
> the "outside" of the object. The author of the i_algbr library seems to
> have rigged the code so that the point <0,0,0> is always in the "inside"
> region, even in surfaces like Torus_gumdrop and Dupin_Cyclid (which are
> rather like torusses, with <0,0,0> in the middle of what we would
> consider to be the hole) .

This is certainly non-intuitive. I have noticed a lot of odd design 
decisions in the isosurface syntax(the use of <> brackets for holding 
parameters, a different meaning for "bounded_by"(no longer the a 
problem, now that we have "contained_by"), functions using the bounding 
box for data, etc.), hopefully all of these will be cleared up when the 
official version is released.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

[Mike Williams] Re: Isosurface Tutorial updated [9458 days 16 hours and 35 minutes ago]

Sun, 14 May 2000 18:37:57 GMT

Wasn't it Chris Huff who wrote:
>In article <6dS### [at] econymdemoncouk>, Mike Williams 
><mik### [at] econymdemoncouk> wrote:
>
>> An alternative solution is to add the keyword "open" just after the
>> contained_by statement.
>
>Note that this solution doesn't help if your object contains media or is 
>used in CSG...though "open inverse" should work. I would suggest just 
>using a negative threshold, or declaring the function(a good practice 
>anyway) and using it's negative("-FuncName(x,y,z)").
>Or use "sign -1". :-)
>

Using a negative threshold isn't a solution, it just makes the surface
that you're interested in larger. MegaPOV still treats locations where
the function is numerically less than the threshold as "inside".

Experiments also reveal that "open inverse" produces a rather different
effect from "sign -1". In CSG, the "open" seems to be ignored most of
the time, so the objects intersect with just the "inverse", i.e. the
positive copy of the target surface inside an inverse contained_by
object.

Another solution relies on the fact that all (or is that "almost all")
the problematic surfaces are those from the "i_algbr" library and
therefore have what I call "field strength" as their first parameter.
Negating the field strength (e.g. function {"Bicorn" <-1,1>}) has
exactly the same effect as adding "sign -1".

The problematic surfaces seem to be those in the i_algbr library where
the origin lies in the region that we would intuitively consider to be
the "outside" of the object. The author of the i_algbr library seems to
have rigged the code so that the point <0,0,0> is always in the "inside"
region, even in surfaces like Torus_gumdrop and Dupin_Cyclid (which are
rather like torusses, with <0,0,0> in the middle of what we would
consider to be the hole) .

-- 
Mike Williams
Gentleman of Leisure

[Chris Huff] Re: Isosurface Tutorial updated [9459 days 11 hours and 44 minutes ago]

Sat, 13 May 2000 23:28:30 GMT

In article <6dS### [at] econymdemoncouk>, Mike Williams 
<mik### [at] econymdemoncouk> wrote:

> Wasn't it Simen Kvaal who wrote:
> >You seem to know these built-in-functions well!
> 
> It didn't start out that way. It took a lot of hard work to obtain all
> that information.

I'll bet! I personally avoid using the built-in functions(the syntax is 
awful, and I highly doubt it would survive if these functions are 
included in the official version), but this is very useful information 
for those who do use them.

> A subtle, and not quite intentional, side effect of the presence of my
> container surfaces is that they clobber the parts where the surface runs
> round the contained_by sphere. Because my transparent container surfaces
> are exactly coincident with the contained_by surface, only one of them
> gets rendered, and that happens to be the transparent surface.

I suggest something like "scale 1.001" to remedy this...or maybe "scale 
0.999", so those parts stand out as container-intersections. This could 
make debugging functions easier, since you could immediately see that 
the problem is a container intersecting with the surface.

> An alternative solution is to add the keyword "open" just after the
> contained_by statement.

Note that this solution doesn't help if your object contains media or is 
used in CSG...though "open inverse" should work. I would suggest just 
using a negative threshold, or declaring the function(a good practice 
anyway) and using it's negative("-FuncName(x,y,z)").
Or use "sign -1". :-)

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

[Mike Williams] Re: Isosurface Tutorial updated [9459 days 20 hours and 8 minutes ago]

Sat, 13 May 2000 15:04:37 GMT

Wasn't it Simen Kvaal who wrote:
>You seem to know these built-in-functions well!

It didn't start out that way. It took a lot of hard work to obtain all
that information.

>I've played with them, but never got anything to work. So I decided to give
>your source-files a try. I fired up algbr015.pov (Duphin_Cyclid-thing), and
>it worked fine! However, when I tried to make my own scene, I found that it
>seems the behaviour of these bulit-in functions are somewhat erratic. For
>example, when _removing_ the last four lines of algbr015.pov, the ones
>placing the transparent container, the Isosurface only shows something like
>a solid ball! And without affecting the code for the iso at all.
>
>Du you know why such things happen (stuff like this happen to my isos all
>the time), and mayby how to avoid/predict them?

What's happening is that several built in functions produce surfaces
that are actually inside out, and the Duphin_Cyclid is one of them.
What's happening is that the contained_by sphere is intersecting the
"inside" of the cyclid at all points, so what actually gets rendered is
the contained_by sphere, and the cyclid itself is a hollow space inside
this sphere where you can't see it. I don't know an easy way to predict
inside-out-ness, but the solution is easy, use "sign -1".

A subtle, and not quite intentional, side effect of the presence of my
container surfaces is that they clobber the parts where the surface runs
round the contained_by sphere. Because my transparent container surfaces
are exactly coincident with the contained_by surface, only one of them
gets rendered, and that happens to be the transparent surface.

An alternative solution is to add the keyword "open" just after the
contained_by statement.

I'll go back through my tutorial to check for inside-out surfaces and
turn them right side out.

-- 
Mike Williams
Gentleman of Leisure

[Simen Kvaal] Re: Isosurface Tutorial updated [9460 days 12 hours and 39 minutes ago]

Fri, 12 May 2000 22:33:49 GMT

You seem to know these built-in-functions well!

I've played with them, but never got anything to work. So I decided to give
your source-files a try. I fired up algbr015.pov (Duphin_Cyclid-thing), and
it worked fine! However, when I tried to make my own scene, I found that it
seems the behaviour of these bulit-in functions are somewhat erratic. For
example, when _removing_ the last four lines of algbr015.pov, the ones
placing the transparent container, the Isosurface only shows something like
a solid ball! And without affecting the code for the iso at all.

Du you know why such things happen (stuff like this happen to my isos all
the time), and mayby how to avoid/predict them?

Simen.


Mike Williams skrev i meldingen ...
>I've substantially updated my isosurface tutorial at
><http://www.econym.demon.co.uk/isotut>.
>
>There's now an almost[1] complete catalogue of the built in functions,
>and each page now contains a zip file of all the sources used for the
>images on that page. So pop by if you've ever wondered what the Kampyle
>of Eudoxus looks like, or want know what various parameters of the
>func_16 surface do.
>

[Bob Hughes] Re: Isosurface Tutorial updated [9462 days 23 hours and 54 minutes ago]

Wed, 10 May 2000 11:18:52 GMT

Looking great there.  I was wondering what 'helix2' was compared to
'helix', among other things.  Just the "built-in" functions was something
I have been wanting to know better all along.
Thanks plenty.

Bob

"Mike Williams" <mik### [at] nospamplease> wrote in message
news:ci+sVC### [at] econymdemoncouk...
| I've substantially updated my isosurface tutorial at
| <http://www.econym.demon.co.uk/isotut>.
|
| There's now an almost[1] complete catalogue of the built in functions,
| and each page now contains a zip file of all the sources used for the
| images on that page. So pop by if you've ever wondered what the Kampyle
| of Eudoxus looks like, or want know what various parameters of the
| func_16 surface do.
|
| [1] I'd be glad of any hints on how to use any of the remaining built in
| functions, namely: imp_func, data_3D_3, data_2D_3, data_3D_1, data_2D_1,
| odd_sphere and iso_pigment.
|
| --
| Mike Williams
| Gentleman of Leisure

[Mike Williams] Isosurface Tutorial updated [9463 days 4 hours and 30 minutes ago]

Wed, 10 May 2000 06:42:57 GMT

I've substantially updated my isosurface tutorial at
<http://www.econym.demon.co.uk/isotut>.

There's now an almost[1] complete catalogue of the built in functions,
and each page now contains a zip file of all the sources used for the
images on that page. So pop by if you've ever wondered what the Kampyle
of Eudoxus looks like, or want know what various parameters of the
func_16 surface do.

[1] I'd be glad of any hints on how to use any of the remaining built in
functions, namely: imp_func, data_3D_3, data_2D_3, data_3D_1, data_2D_1,
odd_sphere and iso_pigment.

-- 
Mike Williams
Gentleman of Leisure

[Mike Williams] Re: Isosurface Tutorial [9471 days 10 hours and 39 minutes ago]

Tue, 2 May 2000 00:34:03 GMT

Wasn't it Me who wrote:
>
>Wasn't it Simen Kvaal who wrote:
>
>>One thing: What about a tute for the built-in functiions, like "sphere" and
>>"torus?" Personally, there's a lot I don't understand there...
>
>OK. I'll add something.
>
>Expect an update in the next few days.
>

I've now added a general page about built in functions, and a page that
covers all the "standard" built in functions except "imp_func" (about
which I don't have a clue). The library functions look like taking a lot
longer to cover.

http://www.econym.demon.co.uk/isotut/

-- 
Mike Williams
Gentleman of Leisure

[Mike Williams] Re: Isosurface Tutorial [9471 days 17 hours and 57 minutes ago]

Mon, 1 May 2000 17:15:40 GMT

Wasn't it Simen Kvaal who wrote:

>One thing: What about a tute for the built-in functiions, like "sphere" and
>"torus?" Personally, there's a lot I don't understand there...

OK. I'll add something.

Expect an update in the next few days.

-- 
Mike Williams
Gentleman of Leisure

[Simen Kvaal] Re: Isosurface Tutorial [9473 days 11 hours and 26 minutes ago]

Sat, 29 Apr 2000 23:47:10 GMT

Very good! Excellent demonstration images too. All the features of the
surfaces (such as real bumps et.c.) comes out nicely from the images.

One thing: What about a tute for the built-in functiions, like "sphere" and
"torus?" Personally, there's a lot I don't understand there...

Simen.

Mike Williams skrev i meldingen <+Pf0### [at] econymdemoncouk>...
>
>I've put together a little bit of an unofficial tutorial about
>isosurfaces at
>
>http://www.econym.demon.co.uk/isotut/
>
>Hope you like it.
>--
>Mike Williams
>Gentleman of Leisure

[Peter Popov] Re: Lightbulb [9474 days 2 hours and 56 minutes ago]

Sat, 29 Apr 2000 08:16:25 GMT

Found it,

From: "Bob Hughes" <inv### [at] aolcom>
Newsgroups: povray.text.scene-files
Subject: Lightbulb (incandescent 60 Watt kind)
Date: Thu, 9 Sep 1999 00:20:58 -0500
Message-ID: <37d743d0@news.povray.org>


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

[Peter Popov] Re: Lightbulb [9474 days 3 hours and 5 minutes ago]

Sat, 29 Apr 2000 08:07:48 GMT

On Sat, 29 Apr 2000 10:26:38 +0300, "Saadat Saeed"
<nat### [at] hotmailcom> wrote:

>Any tutorials on making glowing objects like a lightbulb?????

Some time ago there was a series of posts culminating in an excellent
lightbulb model. I think it's also available in the POV objects
collection.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

[Saadat Saeed] Lightbulb [9474 days 3 hours and 42 minutes ago]

Sat, 29 Apr 2000 07:30:40 GMT

Any tutorials on making glowing objects like a lightbulb?????

[Dast] Re: Isosurface Tutorial [9500 days 8 hours and 16 minutes ago]

Mon, 3 Apr 2000 02:57:04 GMT

Mike Williams wrote:
> 
> I've put together a little bit of an unofficial tutorial about
> isosurfaces at
> 
> http://www.econym.demon.co.uk/isotut/
> 
> Hope you like it.

Thanks greatly!  It has made my bookmark list.  :)

--Chris

[David Wilkinson] Re: Isosurface Tutorial [9500 days 15 hours and 23 minutes ago]

Sun, 2 Apr 2000 19:49:29 GMT

On Fri, 31 Mar 2000 18:13:01 +0100, Mike Williams <mik### [at] nospamplease> wrote:

>
>I've put together a little bit of an unofficial tutorial about
>isosurfaces at
>
>http://www.econym.demon.co.uk/isotut/
>
>Hope you like it.

Very nicely done Mike.
 I have added it to my personal collection of really useful POV html files.
Thanks
David
----------------------------
dav### [at] cableinetcouk
http://members.vavo.com/squiffy/
http://www.hamiltonite.mcmail.com
----------------------------

[Bob Hughes] Re: Isosurface Tutorial [9502 days 5 hours and 58 minutes ago]

Sat, 1 Apr 2000 05:15:07 GMT

Very nice layout and all.  Makes for the only other such tutorial I know of thus
far too.

Bob

"Mike Williams" <mik### [at] nospamplease> wrote in message
news:+Pf0### [at] econymdemoncouk...
|
| I've put together a little bit of an unofficial tutorial about
| isosurfaces at
|
| http://www.econym.demon.co.uk/isotut/
|
| Hope you like it.
| --
| Mike Williams
| Gentleman of Leisure

[Mike Williams] Isosurface Tutorial [9502 days 16 hours and 45 minutes ago]

Fri, 31 Mar 2000 18:28:13 GMT

I've put together a little bit of an unofficial tutorial about
isosurfaces at

http://www.econym.demon.co.uk/isotut/

Hope you like it.
-- 
Mike Williams
Gentleman of Leisure

[David Wilkinson] Re: placing onjects on hfs with leveller [9533 days 12 hours and 28 minutes ago]

Tue, 29 Feb 2000 22:45:19 GMT

On Tue, 29 Feb 2000 17:13:28 -0000, "Mick Hazelgrove" <mha### [at] mindaswinternetcouk>
wrote:

>
>I've written a quick tutorial on using Leveller to place objects on a hf
>landscape. You can find it at the address below, link on first page.
>
Thanks Mick that's quite useful.
David
----------------------------
dav### [at] cwcomnet
http://www.hamiltonite.mcmail.com
----------------------------

[Mick Hazelgrove] placing onjects on hfs with leveller [9533 days 15 hours and 52 minutes ago]

Tue, 29 Feb 2000 19:21:17 GMT

Hi all

I've written a quick tutorial on using Leveller to place objects on a hf
landscape. You can find it at the address below, link on first page.

If you have problems reading it in Netscape let me know and if you can help
rectify them I would be grateful.

Mick
--
*************************************************************
       http://www.minda.swinternet.co.uk/index.htm

*************************************************************

[TonyB] Re: Making POV Patches(first draft) - attached f... [9619 days 15 hours and 42 minutes ago]

Sun, 5 Dec 1999 19:30:43 GMT

Thank you very much, that was very enlightening. I wouldn't have been able
to come up with all that on my own. God bless you. =)

Now, I'm off to learn C, and <gulp> C++...

[Chris Huff] Making POV Patches(first draft) - attached files... [9619 days 17 hours and 2 minutes ago]

Sun, 5 Dec 1999 18:11:18 GMT

Here it is, a very early draft version. It contains 2 tutorials, one for 
adding a solid pattern and the other for adding a noise3d() function.
Please tell me what you think.
Because of the differences with line endings for Mac and PC, I have 
included both a Mac and a PC text version. I am thinking of using HTML, 
that would eliminate the problem with line endings and make the 
formatting much clearer. Any comments?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Writing POV-Ray Patches(draft)

    Introduction
    Adding Reserved Words
    Adding Parsing Code
    Data Types
    Utility Functions and Macros
    Step-by-step tutorials:
        Adding a solid pattern.
        Adding a noise3d function.

Introduction
When I started writing patches, I found that there were no "getting started" documents
around. This is my attempt to rectify this problem. The finished document will consist
of a few reference sections, and some fully self-contained tutorials. Because the
tutorials are completely self-contained, there is a lot of duplication of things such
as reserving words and tokens, and parsing. I will try to keep things separated and
organized enough that you don't have to read the same thing over and over.




Adding Reserved Words
There are 2 places you need to modify to add a reserved word: an enum named TOKEN_IDS
in parse.h, and an array named Reserved_Words[] in tokenize.c.
The entry in TOKEN_IDS gives POV a way to refer to the token, and the entry in
Reserved_Words[] tells POV what string to associate with that token.

While it doesn't matter where in Reserved_Words[] the entry is placed, the position in
TOKEN_IDS does matter. Just follow the comments for now, I plan on making a "map" of
TOKEN_IDS sometime in the future.




Adding Parsing Code
Here I will explain how to add parsing code, and explain the various functions and
macros. For now, try finding a piece of code that does something close to what you
want, and copy off of that.




Data Types
Here I will document the various data types used in POV-Ray.




Utility Functions and Macros
Here I will document the various functions and macros available.




Tutorials:
Adding a solid pattern.
Here we will add a "solid" pattern to POV-Ray. This pattern is constant over space,
and is probably the simplest pattern possible, but it is quite useful when used with
animations and blend maps.
The first step is to add the reserved word. The syntax for this pattern will be as
follows:
pigment {
    solid PATT_VAL
    ...other pigment stuff...
}
As you can see, we need to reserve the word "solid" for use with the solid pattern.
To do this, you need to add a line in parse.h and tokenize.c.
In parse.h, add an entry to the enum TOKEN_IDS, at the end, but before LAST_TOKEN:
  MATERIAL_ID_TOKEN,
  UV_ID_TOKEN,
  VECTOR_4D_ID_TOKEN,
  SOLID_TOKEN,//Here
  LAST_TOKEN
};
This is what the token will be referred to as from within the program. However, you
need to tell POV-Ray what string to associate with that token. You do that by adding
an entry to the array Reserved_Words[] in tokenize.c:
  {X_TOKEN, "x"},
  {YES_TOKEN, "yes"},
  {Y_TOKEN, "y"},
  {Z_TOKEN, "z"},
  {SOLID_TOKEN, "solid"}
};
You may want to put the entry in alphabetical order with the other entries, I prefer
to leave my additions at the end in one place.

Next, you need to give POV-Ray what to refer to the pattern itself as. The token is
just for parsing, the pattern itself is referred to by a #define in pattern.h.
Place yours after the density file identifier in the list of #defines at the top of
this file, and number it accordingly:
#define BOXED_PATTERN           29
#define CYLINDRICAL_PATTERN     30
#define DENSITY_FILE_PATTERN    31
#define SOLID_PATTERN           32
The placement in this list does matter, depending on the type of pattern you are
adding. There are comments to show where to put the #define. Because this is just an
ordinary float pattern like bozo or gradient, we put it at the end with the others.

Next, you need to add a place to store the value of the pattern. In frame.h, find the
#define TPATTERN_FIELDS. Add in a variable for the pattern value:
#define TPATTERN_FIELDS                  \
  DBL solidVal;/*here*/                  \
  unsigned short Type, Wave_Type, Flags; \
  int References;                        \
  SNGL Frequency, Phase;                 \
Notice that we use DBL and SNGL, these are #defines commonly used in the POV source.
They are defined in frame.h, among other things. I recommend you look through frame.h
just to see what other things are defined there.

Now we have the tokens, the pattern identifier, and a place to store the pattern data,
the next step is the parser. You need to add a case in the function Parse_Pattern() in
the file parstxtr.c for the solid pattern.
This is pretty straightforward, there are macros for adding the cases. I usually just
copy an existing pattern that does something close to what I want. Add the case for
the solid pattern right after the one for density file:
     CASE (DENSITY_FILE_TOKEN)
       if (Old_Type==DENSITY_FILE_PATTERN) 
       {
         Destroy_Density_File(Old_Density_File);
       }   
       New->Type = DENSITY_FILE_PATTERN;
       New->Vals.Density_File = Create_Density_File();
       GET(DF3_TOKEN);
       New->Vals.Density_File->Data->Name = Parse_String();
       Read_Density_File(New->Vals.Density_File);
       EXIT
     END_CASE

     CASE (SOLID_TOKEN)
       New->Type = SOLID_PATTERN;
       New->solidVal = Parse_Float();
       EXIT
     END_CASE
Use the token ID for your pattern keyword as the parameter to the CASE macro, and set
the type of the pattern to your pattern identifier defined in pattern.h. Also add a
call to Parse_Float() to parse the parameter. This function returns the value of the
float parsed, so assign that value to the variable you added in frame.h.

Now all you have to do is add code for calculating the actual pattern. This time, open
pattern.c. Add a prototype for your function in the list at the top of this file:
static DBL density_file (VECTOR EPoint, TPATTERN *TPat);
static DBL solid(VECTOR EPoint, TPATTERN *TPat);
Then go to a convenient place in the file, I choose the end, and add the
implementation for the function:
static DBL solid(VECTOR EPoint, TPATTERN *TPat)
{
    return TPat->solidVal;
}
If you ever need to, you can add initializers for the variables in Init_TPat_Fields(),
and copy them in Copy_TPat_Fields(), although they aren't necessary for this pattern,
since the only time the solid() function will be called the variable will have been
assigned, and Copy_TPat_Fields() already takes care of copying it.

The only thing remaining is to tell POV-Ray to use this function for calculating the
solid pattern. Add a single line to the function Evaluate_TPat(), after density file:
    case DENSITY_FILE_PATTERN:value = density_file (TPoint, TPat);  break;
    case SOLID_PATTERN:value        = solid(TPoint, TPat);          break;


That should be it. You now have a working solid pattern.



Adding a noise3d() function.
Here we will add a noise3d() function to POV-Ray. This function returns a value in the
range 0-1 depending on the location in space, and is identical to the bozo pattern. If
you have used isosurfaces, you are probably already familiar with it.
The first step is to add the reserved word. The syntax for this function will be:
noise3d(VECTOR_POS)
I chose a vector for this instead of 3 float values, because if you are using float
values, it only means you have to use 2 extra characters(<>), but if I chose float
values, it would require 3 dot operators and 2 more copies of the vector identifier to
use it with a vector:
noise3d(<FloatX, FloatY, FloatZ>)//using 3 floats with vector syntax
noise3d(VectID.x, VectID.y, VectID.z)//using vector identifier with float syntax

For this patch, we need to reserve the word "noise3d".
To do this, you need to add a line in parse.h and tokenize.c.
In parse.h, add an entry to the enum TOKEN_IDS. Since this is a float function, it
needs to be entered in a specific place:
  DEFINED_TOKEN,
  NOISE3D_TOKEN,//Here
  FLOAT_FUNCT_TOKEN,

/*WARNING: All new functions returning a float value must be placed
  before FLOAT_FUNCT_TOKEN or the parser won't work right. */

This is what the token will be referred to as from within the program. However, you
need to tell POV-Ray what string to associate with that token. You do that by adding
an entry to the array Reserved_Words[] in tokenize.c:
  {X_TOKEN, "x"},
  {YES_TOKEN, "yes"},
  {Y_TOKEN, "y"},
  {Z_TOKEN, "z"},
  {NOISE3D_TOKEN, "noise3d"}
};
You may want to put the entry in alphabetical order with the other entries, I prefer
to leave my additions at the end in one place.

The next step is to tell POV-Ray what to do when it encounters this token. Open up
express.c, and go to the function Parse_Num_Factor(). Since noise3d() returns a float,
we will put it in the case for float functions. Lets add our function at the top:


    CASE (FLOAT_FUNCT_TOKEN)
       /* All of these functions return a DBL result */
       switch(Token.Function_Id)
         {
          case NOISE3D_TOKEN:
            Parse_Vector_Param(Vect);
            Val = Noise(Vect);
            break;

          case ABS_TOKEN:
            Val = Parse_Float_Param();
            Val = fabs(Val);
            break;

That is it, you now have a working noise3d() function!


Writing POV-Ray Patches(draft)

    Introduction
    Adding Reserved Words
    Adding Parsing Code
    Data Types
    Utility Functions and Macros
    Step-by-step tutorials:
        Adding a solid pattern.
        Adding a noise3d function.

Introduction
When I started writing patches, I found that there were no "getting started" documents
around. This is my attempt to rectify this problem. The finished document will consist
of a few reference sections, and some fully self-contained tutorials. Because the
tutorials are completely self-contained, there is a lot of duplication of things such
as reserving words and tokens, and parsing. I will try to keep things separated and
organized enough that you don't have to read the same thing over and over.




Adding Reserved Words
There are 2 places you need to modify to add a reserved word: an enum named TOKEN_IDS
in parse.h, and an array named Reserved_Words[] in tokenize.c.
The entry in TOKEN_IDS gives POV a way to refer to the token, and the entry in
Reserved_Words[] tells POV what string to associate with that token.

While it doesn't matter where in Reserved_Words[] the entry is placed, the position in
TOKEN_IDS does matter. Just follow the comments for now, I plan on making a "map" of
TOKEN_IDS sometime in the future.




Adding Parsing Code
Here I will explain how to add parsing code, and explain the various functions and
macros. For now, try finding a piece of code that does something close to what you
want, and copy off of that.




Data Types
Here I will document the various data types used in POV-Ray.




Utility Functions and Macros
Here I will document the various functions and macros available.




Tutorials:
Adding a solid pattern.
Here we will add a "solid" pattern to POV-Ray. This pattern is constant over space,
and is probably the simplest pattern possible, but it is quite useful when used with
animations and blend maps.
The first step is to add the reserved word. The syntax for this pattern will be as
follows:
pigment {
    solid PATT_VAL
    ...other pigment stuff...
}
As you can see, we need to reserve the word "solid" for use with the solid pattern.
To do this, you need to add a line in parse.h and tokenize.c.
In parse.h, add an entry to the enum TOKEN_IDS, at the end, but before LAST_TOKEN:
  MATERIAL_ID_TOKEN,
  UV_ID_TOKEN,
  VECTOR_4D_ID_TOKEN,
  SOLID_TOKEN,//Here
  LAST_TOKEN
};
This is what the token will be referred to as from within the program. However, you
need to tell POV-Ray what string to associate with that token. You do that by adding
an entry to the array Reserved_Words[] in tokenize.c:
  {X_TOKEN, "x"},
  {YES_TOKEN, "yes"},
  {Y_TOKEN, "y"},
  {Z_TOKEN, "z"},
  {SOLID_TOKEN, "solid"}
};
You may want to put the entry in alphabetical order with the other entries, I prefer
to leave my additions at the end in one place.

Next, you need to give POV-Ray what to refer to the pattern itself as. The token is
just for parsing, the pattern itself is referred to by a #define in pattern.h.
Place yours after the density file identifier in the list of #defines at the top of
this file, and number it accordingly:
#define BOXED_PATTERN           29
#define CYLINDRICAL_PATTERN     30
#define DENSITY_FILE_PATTERN    31
#define SOLID_PATTERN           32
The placement in this list does matter, depending on the type of pattern you are
adding. There are comments to show where to put the #define. Because this is just an
ordinary float pattern like bozo or gradient, we put it at the end with the others.

Next, you need to add a place to store the value of the pattern. In frame.h, find the
#define TPATTERN_FIELDS. Add in a variable for the pattern value:
#define TPATTERN_FIELDS                  \
  DBL solidVal;/*here*/                  \
  unsigned short Type, Wave_Type, Flags; \
  int References;                        \
  SNGL Frequency, Phase;                 \
Notice that we use DBL and SNGL, these are #defines commonly used in the POV source.
They are defined in frame.h, among other things. I recommend you look through frame.h
just to see what other things are defined there.

Now we have the tokens, the pattern identifier, and a place to store the pattern data,
the next step is the parser. You need to add a case in the function Parse_Pattern() in
the file parstxtr.c for the solid pattern.
This is pretty straightforward, there are macros for adding the cases. I usually just
copy an existing pattern that does something close to what I want. Add the case for
the solid pattern right after the one for density file:
     CASE (DENSITY_FILE_TOKEN)
       if (Old_Type==DENSITY_FILE_PATTERN) 
       {
         Destroy_Density_File(Old_Density_File);
       }   
       New->Type = DENSITY_FILE_PATTERN;
       New->Vals.Density_File = Create_Density_File();
       GET(DF3_TOKEN);
       New->Vals.Density_File->Data->Name = Parse_String();
       Read_Density_File(New->Vals.Density_File);
       EXIT
     END_CASE

     CASE (SOLID_TOKEN)
       New->Type = SOLID_PATTERN;
       New->solidVal = Parse_Float();
       EXIT
     END_CASE
Use the token ID for your pattern keyword as the parameter to the CASE macro, and set
the type of the pattern to your pattern identifier defined in pattern.h. Also add a
call to Parse_Float() to parse the parameter. This function returns the value of the
float parsed, so assign that value to the variable you added in frame.h.

Now all you have to do is add code for calculating the actual pattern. This time, open
pattern.c. Add a prototype for your function in the list at the top of this file:
static DBL density_file (VECTOR EPoint, TPATTERN *TPat);
static DBL solid(VECTOR EPoint, TPATTERN *TPat);
Then go to a convenient place in the file, I choose the end, and add the
implementation for the function:
static DBL solid(VECTOR EPoint, TPATTERN *TPat)
{
    return TPat->solidVal;
}
If you ever need to, you can add initializers for the variables in Init_TPat_Fields(),
and copy them in Copy_TPat_Fields(), although they aren't necessary for this pattern,
since the only time the solid() function will be called the variable will have been
assigned, and Copy_TPat_Fields() already takes care of copying it.

The only thing remaining is to tell POV-Ray to use this function for calculating the
solid pattern. Add a single line to the function Evaluate_TPat(), after density file:
    case DENSITY_FILE_PATTERN:value = density_file (TPoint, TPat);  break;
    case SOLID_PATTERN:value        = solid(TPoint, TPat);          break;


That should be it. You now have a working solid pattern.



Adding a noise3d() function.
Here we will add a noise3d() function to POV-Ray. This function returns a value in the
range 0-1 depending on the location in space, and is identical to the bozo pattern. If
you have used isosurfaces, you are probably already familiar with it.
The first step is to add the reserved word. The syntax for this function will be:
noise3d(VECTOR_POS)
I chose a vector for this instead of 3 float values, because if you are using float
values, it only means you have to use 2 extra characters(<>), but if I chose float
values, it would require 3 dot operators and 2 more copies of the vector identifier to
use it with a vector:
noise3d(<FloatX, FloatY, FloatZ>)//using 3 floats with vector syntax
noise3d(VectID.x, VectID.y, VectID.z)//using vector identifier with float syntax

For this patch, we need to reserve the word "noise3d".
To do this, you need to add a line in parse.h and tokenize.c.
In parse.h, add an entry to the enum TOKEN_IDS. Since this is a float function, it
needs to be entered in a specific place:
  DEFINED_TOKEN,
  NOISE3D_TOKEN,//Here
  FLOAT_FUNCT_TOKEN,

/*WARNING: All new functions returning a float value must be placed
  before FLOAT_FUNCT_TOKEN or the parser won't work right. */

This is what the token will be referred to as from within the program. However, you
need to tell POV-Ray what string to associate with that token. You do that by adding
an entry to the array Reserved_Words[] in tokenize.c:
  {X_TOKEN, "x"},
  {YES_TOKEN, "yes"},
  {Y_TOKEN, "y"},
  {Z_TOKEN, "z"},
  {NOISE3D_TOKEN, "noise3d"}
};
You may want to put the entry in alphabetical order with the other entries, I prefer
to leave my additions at the end in one place.

The next step is to tell POV-Ray what to do when it encounters this token. Open up
express.c, and go to the function Parse_Num_Factor(). Since noise3d() returns a float,
we will put it in the case for float functions. Lets add our function at the top:


    CASE (FLOAT_FUNCT_TOKEN)
       /* All of these functions return a DBL result */
       switch(Token.Function_Id)
         {
          case NOISE3D_TOKEN:
            Parse_Vector_Param(Vect);
            Val = Noise(Vect);
            break;

          case ABS_TOKEN:
            Val = Parse_Float_Param();
            Val = fabs(Val);
            break;

That is it, you now have a working noise3d() function!

[Fabien Hénon] Tip pop up in HTML for media [9625 days 12 hours and 26 minutes ago]

Mon, 29 Nov 1999 22:47:10 GMT

For my own use, I wanted to rewrite the POV documentation concerning the

media feature. I guess that most of you will agree that it's not that
easy to master.
If I may say so, I prefer the way the POV documentation was written
before 3.1.  It seems more obscure to me now.


You will find the very beginning (it's just a sketch) of what I did.
The doc is written in HTML. I have one question for the webmasters : Is
there a way to display a comment ( just like Excel or Word) in a HTML
page when you move your mouse over either a word or a link.

I've had one answer already, but the tip on the web-page is not
displayed long enough.
The trick is to read the POV syntax while being able to understand every
keyword of the media feature.

I hope my request is clear enough.

Thanks

Fabien

[Ken] Re: macro tutorials - any really detailed ones o... [9664 days 23 hours and 58 minutes ago]

Thu, 21 Oct 1999 11:14:45 GMT

darrenf wrote:
> 
> Hello
> 
> Just wondering whether anyone has got any detailed web pages on programming
> macros for povray 3.1???

 The making and using of macros is really not all that complicated and
I have not seen anyone attempt to write a tutorial on the subject.

 Most of the mystery behind how they work is all of the other programming
like commands that have been part of Pov for a while now like while loops,
if / else directives, and other similar functions. You can learn a lot by
looking at examples of other peoples macros and fortunately for you I just
posted 58 of them on my home page 2 days ago.

 Making a macro is simple. Making useful commands to feed to a macro is the
difficult part. You might want to visit my links page tutorials section to
look at some of the more advanced tutorials.

> Also any really complicated organic macros out there??

 The closest thing to organic macros I have seen are a couple of tree
generating macros. See my links page or the povray.org links page for
sites that contain them.

-- 
Ken Tyler -  1100+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[darrenf] macro tutorials - any really detailed ones out t... [9665 days and 19 minutes ago]

Thu, 21 Oct 1999 10:53:29 GMT

Hello

Just wondering whether anyone has got any detailed web pages on programming
macros for povray 3.1???

Also any really complicated organic macros out there??

hope you can all help

thanks

check out my site : www.dazzy-d.demon.co.uk


--
Ice is forming on the tips of my wings
Unheeded warnings, I thought I thought of everything
No navigator to guide my way home
Unladened, empty and turned to stone

Learning to fly - pink floyd

[TonyB] Re: Colors question. [9673 days 11 hours and 15 minutes ago]

Tue, 12 Oct 1999 23:57:54 GMT

>> how would I turn an RGB value of 156,111,90 into a povray RGB value?
>
>Divide by 255 ---> rgb < 0.611, 0.435, 0.352 >


OR, easier:

rgb <156,111,90>/255

[Ken] Re: Colors question. [9673 days 13 hours and 27 minutes ago]

Tue, 12 Oct 1999 21:45:54 GMT

"Mr.3D" wrote:
> 
> how would I turn an RGB value of 156,111,90 into a povray RGB value?

Divide by 255 ---> rgb < 0.611, 0.435, 0.352 >

-- 
Ken Tyler -  1100+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Mr 3D] Colors question. [9673 days 14 hours and 5 minutes ago]

Tue, 12 Oct 1999 21:07:56 GMT

how would I turn an RGB value of 156,111,90 into a povray RGB value?

[Ken] Re: Req: media [9702 days 14 hours and 15 minutes ago]

Mon, 13 Sep 1999 20:58:17 GMT

Colm wrote:
> 
> Where can I get a tutorial on the use of "media"?
> The docs don't seem to cover it very well... apart from an explanation
> of the syntax.

 No one that I know of has written a comrehensive tutorial on the subject.
About the only thing resembling a tutorial that I have a link for is:

http://members.xoom.com/POVRAY3/media1.html
http://members.xoom.com/POVRAY3/media2.html

  You might also spend some time browsing through povray.binaries.scene-files
and povray.text.scene-files groups and look at the code posted by others here.

If you have any specific questions about how to apply it some people here are
gaining speed on using and understanding media and will often help with direct
questions.

Other than that experimentation is a good teacher when all else fails :)

-- 
Ken Tyler

See my 1000+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

[Colm] Req: media [9702 days 14 hours and 30 minutes ago]

Mon, 13 Sep 1999 20:42:50 GMT

Where can I get a tutorial on the use of "media"?
The docs don't seem to cover it very well... apart from an explanation
of the syntax.

[Larry Fontaine] RE: Rounding off edges [9708 days 12 hours and 46 minutes ago]

Tue, 7 Sep 1999 22:26:45 GMT

Visuals of the macros:

[Edward C ] Re: size limit on binaries ?? [9735 days 1 hour and 24 minutes ago]

Thu, 12 Aug 1999 09:48:52 GMT

If you have access to some space on a web-server (it seems most people can
get some without having to leave thier desks), it may be a better option to
put your tutorial there then write a brief description of it and post that
here in-stead.

[Dave Kreskowiak] Re: size limit on binaries ?? [9735 days 19 hours and 34 minutes ago]

Wed, 11 Aug 1999 15:39:00 GMT

This server allows a post of 1MB.


MR <a### [at] bnet> wrote in message news:37b17425@news.povray.org...
> hello,
>
> i'm sure its noted somewhere, but instead of me having to dig for
> it could somebody tell me the size limit for binary posts.
>
> i'm writing a tutorial on a human motion include file, and a few
> sample AVI's just naturally go along with it.  this would push the
> size over 10MB.  most likely this is just way to big of a download
> and i need to do without the demo AVI's.  and i just hate animated
> gifs... i think i'd rather go with a series of stills instead.
>
> thanks, miker
>
>

[MR] size limit on binaries ?? [9735 days 22 hours and 11 minutes ago]

Wed, 11 Aug 1999 13:01:25 GMT

hello,

i'm sure its noted somewhere, but instead of me having to dig for
it could somebody tell me the size limit for binary posts.

i'm writing a tutorial on a human motion include file, and a few
sample AVI's just naturally go along with it.  this would push the
size over 10MB.  most likely this is just way to big of a download
and i need to do without the demo AVI's.  and i just hate animated
gifs... i think i'd rather go with a series of stills instead.

thanks, miker

[Ken] Re: Tutorials [9750 days 12 hours and 30 minutes ago]

Tue, 27 Jul 1999 22:43:15 GMT

Steve wrote:
> 
> Timothy
> 
> Check http://twysted.net/  there are lots of links there to
> tutorials, also uncle Ken's links page at
> http://home.pacbell.net/tylereng/links.htm
> 

> --
> Cheers
> Steve

Unfortunatly the list at twysted it no longer available. I have the majority
of them in my links collection though as you stated.

-- 
Ken Tyler

mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm

[Steve] Re: Tutorials [9750 days 12 hours and 58 minutes ago]

Tue, 27 Jul 1999 22:14:51 GMT

Timothy 

Check http://twysted.net/  there are lots of links there to
tutorials, also uncle Ken's links page at
http://home.pacbell.net/tylereng/links.htm 

"Timothy A. Grubb" wrote:
> 
> I am starting to set up areas for tutorials on my site. Movies, Gfx,
> text would all be allowed. POV has always had an active community so I
> thought this may be a good way for people to learn. I have been trying
> to get schools to use the program for many purposes but many of the
> teachers think that it is too hard for the students to learn. I will
> probably do the first few myself but more of the in depth stuff is
> beyond my POV knowledge.
> 
> --
> Timothy A. Grubb
> tgr### [at] educationelectriccom
> www.educationelectric.com

-- 
Cheers
Steve

------------------------------------------------------------------------------------------------
%HAV-A-NICEDAY Error reading file mailto:sjl### [at] ndirectcouk

[Alan Holding] Re: Spatch [9751 days 17 hours and 5 minutes ago]

Mon, 26 Jul 1999 18:08:22 GMT

Nick Portelli wrote in message <377### [at] pilotmsuedu>...
>I'm finally getting around to useing spatch and was wondering if there
>was any other new tutorials.  Spatch says you can add points to the
>endpoints and midpoints of a segment.  I have not figured out how to add
>one to a mid point.  If any one knows please tell me.  Thanks,.

Have you been to Dom's home?

http://www.mech.ed.ac.uk/~dom/3d/3d.html

Scroll down the page for links to the sPatch tutorials.

Alan

ICQ 27372656

[Paul Johnsson] Radiosity tutorial [9753 days 3 hours and 3 minutes ago]

Sun, 25 Jul 1999 08:10:05 GMT

Hi.

I have just started to test the Radiosity functions in POV, but I have
some troubles setting all varialbles correct...

Is there a Radiosity tutorial or a "Radiosity beginners guide" out there
somewhere?

I think that many people would aprechiate such a tutorial explaning the
Radiosity function more throughly than the manual.

[Thomas de Groot] Re: Spatch [9758 days 22 hours and 31 minutes ago]

Mon, 19 Jul 1999 12:42:19 GMT

In the following site by Anto Matkovic there is a very comprehensive
tutorial for making heads. He explains also the way to add mid and end
point to a spline.
http://www.geocities.com/SoHo/Studios/7415/index.html

Have fun!!

Nick Portelli wrote:
> 
> I'm finally getting around to useing spatch and was wondering if there
> was any other new tutorials.  Spatch says you can add points to the
> endpoints and midpoints of a segment.  I have not figured out how to add
> one to a mid point.  If any one knows please tell me.  Thanks,.

-- 

Thomas A.M. de Groot
  Netherlands Institute of Applied Geoscience TNO - National Geological
Survey
  Geo-Marine and Coast Department
  Head, Coastal Research Section
    P.O. Box 80015
    3508 TA Utrecht
    The Netherlands

  Phone: +31 30 256 45 58 (direct dialling)
  Fax: +31 30 256 45 55

[Timothy A Grubb] Tutorials [9759 days 1 hour and 34 minutes ago]

Mon, 19 Jul 1999 09:38:50 GMT

I am starting to set up areas for tutorials on my site. Movies, Gfx,
text would all be allowed. POV has always had an active community so I
thought this may be a good way for people to learn. I have been trying
to get schools to use the program for many purposes but many of the
teachers think that it is too hard for the students to learn. I will
probably do the first few myself but more of the in depth stuff is
beyond my POV knowledge.

--
Timothy A. Grubb
tgr### [at] educationelectriccom
www.educationelectric.com

[T'vakah] UV mapping [9768 days 17 hours and 19 minutes ago]

Fri, 9 Jul 1999 17:53:55 GMT

Just wondering one can learn how to use the UV mapping feature of SuperPatch
and UVPOV?


T'vakah

[Rick] Here ya Go :) [9775 days and 4 minutes ago]

Sat, 3 Jul 1999 11:08:28 GMT

Its for doing heads, i didnt do to well, ie, mune didnt look like the
examples but it a greate place to start.

Rick

[Nick Portelli] Spatch [9775 days 19 hours and 59 minutes ago]

Fri, 2 Jul 1999 15:13:33 GMT

I'm finally getting around to useing spatch and was wondering if there
was any other new tutorials.  Spatch says you can add points to the
endpoints and midpoints of a segment.  I have not figured out how to add
one to a mid point.  If any one knows please tell me.  Thanks,.

[Blake Ranolph] Re: Any Ideas? [9818 days 1 hour and 57 minutes ago]

Fri, 21 May 1999 09:16:14 GMT

Dave wrote:
> 
> Hi all.
> Does anyone out there have any ideas on how I might model a christmas
> stocking?  (in 3.1)  I was thinking on making one out of blobs, but I'm not
> very proficient with them...  I never seem to get the result I expect, and
> less often the result I want...  Any other ideas?  (And I'll settle for any
> type stocking.. the modern shaped kind or the kind that look like real
> socks.  I'm not picky <G>)
> 
> Thanks!
> 
> Ciao!
> DH

Maybe out of simple objects but (with sufficient lighting) you could
apply normals to make a less-euphoric look to it.  =]

oo o  o   (   (  ( (=-- inf### [at] veriocom --=) )  )   )   o  o oo

[Ken] Re: Fire in Pov 3.1 [9819 days 17 hours and 6 minutes ago]

Wed, 19 May 1999 18:06:49 GMT

Bob Hughes wrote:
> 
> You could certainly get somewhere I think by simply looking over the media
> examples for P-R 3.1. See under the Scenes\Interior\Media folder the
> several hollow*.pov files. Shouldn't be too difficult to throw a medai
> container into a scene and change it to suit your needs.
> If you run into trouble just ask at povray.general newsgroup for hints and
> tips.

  Besides the useful comments made by Bob there are a couple of examples
you could work from available on line. Browse through the povray.text.
scene-files group looking for the word fire in the messge header. There
were I believe at least a couple of scenes posted their that had fire
included in their objects. If you don't mind downloading a large amount
of message headers you could go back as far as 08-01-1998 in the images
group and do the same search for fire in the message header. When media
first became available myself along with a few other people had some
pretty active discussions on that subject mostly within that group. In
several of those discussions where specifics on the parameters to use
and what types of patterns worked the best. Included also were working
examples of realistic appearing flame utilizing the media featue in Pov.

  If you are impatient and have to have it all right now you can try
the two examples of flame posted in the Pov Objects collections at:

http://twysted.net/povobjects/

  Look in the burning and fire section of the collection. There are
two examples there, one posted by me using media to make flames for a
set of candles, and the second by H. E. Day showing a flaming streak
of fire similar to what a flame thrower would produce. You might be
able to adapt the source in those files to your work but I think you
will learn more if you also follow my earlier suggestion of looking
up the past newsgroup articles on the subject.

Cheers,

-- 
Ken Tyler

mailto://tylereng@pacbell.net

[Bob Hughes] Re: Fire in Pov 3.1 [9819 days 23 hours and 50 minutes ago]

Wed, 19 May 1999 11:22:32 GMT

You could certainly get somewhere I think by simply looking over the media
examples for P-R 3.1. See under the Scenes\Interior\Media folder the
several hollow*.pov files. Shouldn't be too difficult to throw a medai
container into a scene and change it to suit your needs.
If you run into trouble just ask at povray.general newsgroup for hints and
tips.

Timothy Stallmann wrote:
> 
> I don't  use PovRay much, but I am making a model for a school project,
> and I have everything done except for the flame that I need (I am
> modelling a jetpack, and I need flaming engines). In the PovRay 3.0
> documentation, there was a really good fire example (if I remember
> correctly), but that used halos. Does anyone know of a good fire
> tutorial for povray 3.1, or, can I just open my file in povray 3.0 and
> do the fire there? (I don't have any other atmospheres in my file).
> 
> --
> signoff
> Tim Stallmann
> fen### [at] geocitiescom

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto://inversez@aol.com?Subject=PoV-News

[Timothy Stallmann] Fire in Pov 3.1 [9820 days 9 hours and 49 minutes ago]

Wed, 19 May 1999 01:24:18 GMT

I don't  use PovRay much, but I am making a model for a school project,
and I have everything done except for the flame that I need (I am
modelling a jetpack, and I need flaming engines). In the PovRay 3.0
documentation, there was a really good fire example (if I remember
correctly), but that used halos. Does anyone know of a good fire
tutorial for povray 3.1, or, can I just open my file in povray 3.0 and
do the fire there? (I don't have any other atmospheres in my file).

-- 
signoff
Tim Stallmann
fen### [at] geocitiescom

[Dave Helfrich] Re: Where are my lights???? [9859 days 7 hours and 22 minutes ago]

Sat, 10 Apr 1999 03:50:54 GMT

Actually I want them to point up... in the original version of this scene
there are more objects that they should be shining on.  When I realized they
weren't shining on anything, I began commenting out things one by one to try
to find out what was blocking the lights.  I copied the "un-commented" code
into a new file to post.  Otherwise I'd have sent in a .pov file with
something like 500 lines commented out -- more than half.  I will try your
suggestion though, and see if it makes any difference.  If it does, then at
least it'll be a starting point.

Thanks a lot.

--Dave

Bob Hughes wrote in message <370D7E03.31BB938A@aol.com>...
>Try changing all your point_at 50*y to -50*y to direct them downward
>instead. They still behave like spotlights, that is, they point in one
>direction; not endless cylinders going in both directions. I first
>thought they did myself.
>I didn't try your script out, though I believe that is the answer.

>>
>>  [Image]
>>
>>  [Image]
>>
>> // Textures
>>
>> // I'm using a staggared radial texture for the floor.  Here's the
>> // basic texture... It will be phased later to get the circular-checkered
>> // effect.  Kind of like the floor on the stage of this year's Academy
Awards, but not exactly.
>> #declare rad =
>> pigment {
>>         radial
>>         color_map {
>>                 [0.5 color rgb 1.0]
>>                 [0.5 color rgb 0.0]
>>         }
>>         frequency 10
>> }
>>
>> // here is the texture of the rings that will surround the floor
>> // and contain the fountains, and for all the other stone in the scene as
well.
>> #declare stonetexture =
>> texture {
>>         pigment {
>>                 color rgb 0.5
>>         }
>>
>>         normal {granite 1}
>> }
>>
>> // Lights... camera... ...ray trace!
>>
>> light_source {
>>         <0, 1000, 0>
>>         color rgb 0.5//<0.17, 0.17, 0.2>
>>         media_attenuation off
>>         media_interaction off
>>         shadowless // this is always shadowless.  just to help illuminate
things while I try
>>                    // to figure out why the cylinder lights don't light
>> }
>>
>> // these are the cylindrical lights
>>
>> light_source { // #1
>>         <0, 0, 82>
>>         color rgb <2.00, 0.50, 0.50>
>>         cylinder
>>         radius 45
>>         falloff 47
>>         tightness 100
>>         point_at <0, 50, 82>
>>         rotate <0, 270, 0>
>>         media_interaction on
>>         shadowless //made this shadowless for test run
>> }
>>
>> light_source { //#2
>>         <0, 0, 82>
>>         color rgb <2.00, 1.00, 0.50>
>>         cylinder
>>         radius 45
>>         falloff 47
>>         tightness 100
>>         point_at <0, 50, 82>
>>         rotate <0, 306, 0>
>>         media_interaction on
>>         shadowless //made this shadowless for test run
>> }
>>
>> light_source { //#3
>>         <0, 0, 82>
>>         color rgb <2.00, 2.00, 0.50>
>>         cylinder
>>         radius 45
>>         falloff 47
>>         tightness 100
>>         point_at <0, 50, 82>
>>         rotate <0, 342, 0>
>>         media_interaction on
>>         shadowless //made this shadowless for test run
>> }
>>
>> light_source { //#4
>>         <0, 0, 82>
>>         color rgb <0.50, 2.00, 0.50>
>>         cylinder
>>         radius 45
>>         falloff 60
>>         tightness 100
>>         point_at <0, 50, 82>
>>         rotate <0, 18, 0>
>>         media_interaction on
>>         shadowless //made this shadowless for test run
>> }
>>
>> light_source { //#5
>>         <0, 0, 82>
>>         color rgb <0.50, 0.50, 2.00>
>>         cylinder
>>         radius 45
>>         falloff 47
>>         tightness 100
>>         point_at <0, 50, 82>
>>         rotate <0, 54, 0>
>>         media_interaction on
>>         shadowless //made this shadowless for test run
>> }
>>
>> light_source { //#6
>>         <0, 0, 82>
>>         color rgb <2.00, 0.50, 2.00>
>>         cylinder
>>         radius 45
>>         falloff 47
>>         tightness 100
>>         point_at <0, 50, 82>
>>         rotate <0, 90, 0>
>>         media_interaction on
>>         shadowless //made this shadowless for test run
>> }
>>
>> camera {
>>         location <0, 200, 0>
>>         look_at <0, 0, 0>
>> }
>>
>> // Every scene needs some objects.
>>
>> // I've never used discs before.. but layering concentric rings
>> // was the only way I could think of to get the pattern I wanted.
>> // The discs have the "rad" pattern, one half phase off from each other.
>>
>> disc { // White circle in the center
>>         <0, 0, 0>, y, 5
>>         pigment {color rgb 1}
>> }
>>
>> disc {
>>         <0, 0, 0>, y, 10, 5
>>         pigment {rad}
>> }
>>
>> disc {
>>         <0, 0, 0>, y, 15, 10
>>         pigment {rad phase 0.5}
>> }
>>
>> disc {
>>         <0, 0, 0>, y, 20, 15
>>         pigment {rad}
>> }
>>
>>
>> disc {
>>         <0, 0, 0>, y, 25, 20
>>         pigment {rad phase 0.5}
>> }
>>
>> disc {
>>         <0, 0, 0>, y, 30, 25
>>         pigment {rad}
>> }
>>
>> disc {
>>         <0, 0, 0>, y, 35, 30
>>         pigment {rad phase 0.5}
>> }
>>
>> disc {
>>         <0, 0, 0>, y, 40, 35
>>         pigment {rad}
>> }
>>
>> disc {
>>         <0, 0, 0>, y, 45, 40
>>         pigment {rad phase 0.5}
>> }
>>
>> disc {
>>         <0, 0, 0>, y, 50, 45
>>         pigment {rad}
>> }
>>
>> disc {
>>         <0, 0, 0>, y, 55, 50
>>         pigment {rad phase 0.5}
>> }
>>
>> disc {
>>         <0, 0, 0>, y, 60, 55
>>         pigment {rad}
>> }
>>
>> disc {
>>         <0, 0, 0>, y, 65, 60
>>         pigment {rad phase 0.5}
>> }
>>
>> disc {
>>         <0, 0, 0>, y, 70, 65
>>         pigment {rad}
>> }
>>
>>
>> // this large ring immediately surrounds the floor
>> difference {
>>         cylinder {
>>                 <0, -3, 0>, <0, 1, 0>, 72
>>         }
>>
>>         cylinder {
>>                 <0, -3.1, 0>, <0, 1.1, 0>, 70
>>         }
>>         texture {stonetexture}
>> }
>>
>> // this outer ring will surround the floor, and the several mini-rings
that will hold the fountains.
>> difference {
>>         cylinder {
>>                 <0, -3, 0>, <0, 1, 0>, 94
>>         }
>>
>>         cylinder {
>>                 <0, -3.1, 0>, <0, 1.1, 0>, 92
>>         }
>>         texture {stonetexture}
>> }
>>
>> // Here's the ground that will surround the floor.  I cut out the area
where
>> // the floor and rings are so you don't see grass (or this really bad
>> // aproximation of grass) in the bottom.
>> difference {
>>         plane {
>>                 y, -0.5
>>                 texture {
>>                         pigment {
>>                                 color rgb <0.25, 1.00, 0.25>
>>                         }
>>
>>                         normal {
>>                                 average
>>                                 normal_map {         // just arbitary
trial & error numbers to not
>>                                         [granite 2]  // have too smooth
of a ground
>>                                         [bumps 1]
>>                                         [dents 2]
>>                                         [crackle 1]
>>                                 }
>>                         }
>>                 }
>>                 hollow
>>         }
>>
>>         cylinder {
>>                 <0, -3.00001, 0>, <0, 1, 0>, 94
>>                 texture {
>>                         pigment {
>>                                 color rgb 0.50
>>                         }
>>
>>                         normal {
>>                                 average
>>                                 normal_map {
>>                                         [granite 2]  // more arbitrary
trial & error valuse to make
>>                                         [crackle 2]  // the inside of the
pools not be smooth
>>                                 }
>>                         }
>>                 }
>>          hollow
>>          no_shadow
>>         }
>>         hollow on
>> }
>>
>
>--
> omniVERSE: beyond the universe
>  http://members.aol.com/inversez/homepage.htm
> mailto:inv### [at] aolcom?Subject=PoV-News

[Dave Helfrich] Re: Where are my lights???? [9859 days 7 hours and 22 minutes ago]

Sat, 10 Apr 1999 03:50:45 GMT

Thanks for the tips...
First of all though, the cylinders that the lights fall in are (supposedly)
clear.  I tried using the "no_shadow" option on them as well, to no avail.

The center is a series of concentric discs, immediately followed by a thin
ring (difference of 2 cylinders.)  The outer most ring is also a difference
of 2 cylinders.  The large ring between them is actually a cylinder, <0, -3,
0>, <0, 1, 0> that is differenced from a plane (y= -0.5).  The large ring
does have a texture because I didn't want the green of the plane to show
there.  But if it's got the "no_shadow" option on it, why wouldn't the
lights shine through?  I think I'm going to try to give that large inner
ring a clear texture and see if that helps.

Secondly, I also tried raising the light sources up along the y axis.. as
high as y=10, which should have taken them well above any of the rings.
Still didn't help.

Thirdly, the camera angle I used in this was so I could get a "bird's eye"
view of the scene.  I don't generally render scenes at that angle...  I do
it on occasion just to get a look at how things are placed when I'm having
difficulties (as I was with this one).  I haven't had any problems yet doing
that.

There are actually more objects in this scene, but I commented them out
while in an attempt to isolate what was blocking the light sources.  When I
sent the sample code, I didn't include those objects.  (Otherwise there'd be
something like 500 or so lines of code commented out.)

Thanks for your tips...  I'll play with it some more and see what I can do.

--Dave

Ken wrote in message <370D82E5.175D0F9A@pacbell.net>...
>Hi,
>
>  I took a look at your scene file and think I can explain your
>proceedural misunderstanding. I would have tried rendering it
>after making some changes but I am rendering a scene while on line
>and don't want to stop it right now.
>  You have each of your disks located at y = 0. You also have a
>couple of cylinders at y = 0 that are at least 1/2 a pov unit thick
>(I didn't memorize all of the paramaters of your scene so bear with
>me on my generalizations}. Now you have added several cylinder light
>sources ringing this construction all at a uniform distance of 80 units
>or so and each is lying on the y = 0 zero plane. All I can tell you is
>that in pov, as it is in real life, light cannot travel through solid
>objects and that is what you are expecting them to do with the current
>arrangement. Add a positive y value to your light statements and they
>should start to work. I am almost certain that is your problem.
>
>They are specified now as:
>
> light_source { <0, 0, 80 > stuff }
>
>Try changing them to:
>
> light_source { <0, 3, 80 > stuff }
>
>and see if that makes a difference in their perfomance.
>
>Also when I checked to see what camera position you are using
>I noticed that you have your camera at:
>
>camera { location < 0, 200, 0 > look_at <0,0,0>}
>
>You are very lucky that this alone is not crashing the program. In
>most cases it causes a divide by zero error and the program terminates
>with a program fualt. Even if you are getting away with it now it is not
>a good practice to continue. If you need a straight overhead position
>like this always add a very small amount of -z to the camera location.
>
>Example:
>camera { location < 0, 200, -0.0001 > look_at <0,0,0>}
>
>That very tiny amount will keep the program from having the divide by
>zero problem and will in all but the most extreme cases be totaly
>undetectable in the way the scene looks when rendered.
>
>
>--
>Ken Tyler
>
>mailto://tylereng@pacbell.net

[Ken] Re: Where are my lights???? [9860 days 5 hours and 35 minutes ago]

Fri, 9 Apr 1999 05:37:44 GMT

Hi,

  I took a look at your scene file and think I can explain your
proceedural misunderstanding. I would have tried rendering it
after making some changes but I am rendering a scene while on line
and don't want to stop it right now.
  You have each of your disks located at y = 0. You also have a
couple of cylinders at y = 0 that are at least 1/2 a pov unit thick
(I didn't memorize all of the paramaters of your scene so bear with
me on my generalizations}. Now you have added several cylinder light
sources ringing this construction all at a uniform distance of 80 units
or so and each is lying on the y = 0 zero plane. All I can tell you is
that in pov, as it is in real life, light cannot travel through solid
objects and that is what you are expecting them to do with the current
arrangement. Add a positive y value to your light statements and they
should start to work. I am almost certain that is your problem.

They are specified now as:

 light_source { <0, 0, 80 > stuff }

Try changing them to:

 light_source { <0, 3, 80 > stuff }

and see if that makes a difference in their perfomance.

Also when I checked to see what camera position you are using
I noticed that you have your camera at:

camera { location < 0, 200, 0 > look_at <0,0,0>}

You are very lucky that this alone is not crashing the program. In
most cases it causes a divide by zero error and the program terminates
with a program fualt. Even if you are getting away with it now it is not
a good practice to continue. If you need a straight overhead position
like this always add a very small amount of -z to the camera location.

Example:
camera { location < 0, 200, -0.0001 > look_at <0,0,0>}

That very tiny amount will keep the program from having the divide by
zero problem and will in all but the most extreme cases be totaly
undetectable in the way the scene looks when rendered.


-- 
Ken Tyler

mailto://tylereng@pacbell.net

[Bob Hughes] Re: Where are my lights???? [9860 days 6 hours ago]

Fri, 9 Apr 1999 05:12:33 GMT

Try changing all your point_at 50*y to -50*y to direct them downward
instead. They still behave like spotlights, that is, they point in one
direction; not endless cylinders going in both directions. I first
thought they did myself.
I didn't try your script out, though I believe that is the answer.


Dave Helfrich wrote:
> 
> Hi everyone!  I've been working on a scene and I'm having some trouble with
> some cylindrical lights I have in there.  In a nutshell, the scene thus far
> is a top view of a floor (made of nested discs), surrounded by a moat-like
> stone ring.  The bottom of the ring is at -3 along the y axis.  I have 6
> cylinder lights all starting at <0, 0, 82> and rotated to the places I want
> them.  The problem is that they don't light anything unless I make them
> shadowless.  I'm including 2 images... the first one rendered without the
> shadowless lights, the second with them.  I'm guessing that they're not
> lighting anything because there's something blocking them and casting a
> shadow.  I tried using the "no_shadow" option on the objects around the
> lights, but it didn't help.  What's wrong?  I'm also attaching the source.
> 
> I'd appreciate any help anyone could give me.
> 
> Thanks!
> Dave.
> 
>  [Image]
> 
>  [Image]
> 
> // Textures
> 
> // I'm using a staggared radial texture for the floor.  Here's the
> // basic texture... It will be phased later to get the circular-checkered
> // effect.  Kind of like the floor on the stage of this year's Academy Awards, but
not exactly.
> #declare rad =
> pigment {
>         radial
>         color_map {
>                 [0.5 color rgb 1.0]
>                 [0.5 color rgb 0.0]
>         }
>         frequency 10
> }
> 
> // here is the texture of the rings that will surround the floor
> // and contain the fountains, and for all the other stone in the scene as well.
> #declare stonetexture =
> texture {
>         pigment {
>                 color rgb 0.5
>         }
> 
>         normal {granite 1}
> }
> 
> // Lights... camera... ...ray trace!
> 
> light_source {
>         <0, 1000, 0>
>         color rgb 0.5//<0.17, 0.17, 0.2>
>         media_attenuation off
>         media_interaction off
>         shadowless // this is always shadowless.  just to help illuminate things
while I try
>                    // to figure out why the cylinder lights don't light
> }
> 
> // these are the cylindrical lights
> 
> light_source { // #1
>         <0, 0, 82>
>         color rgb <2.00, 0.50, 0.50>
>         cylinder
>         radius 45
>         falloff 47
>         tightness 100
>         point_at <0, 50, 82>
>         rotate <0, 270, 0>
>         media_interaction on
>         shadowless //made this shadowless for test run
> }
> 
> light_source { //#2
>         <0, 0, 82>
>         color rgb <2.00, 1.00, 0.50>
>         cylinder
>         radius 45
>         falloff 47
>         tightness 100
>         point_at <0, 50, 82>
>         rotate <0, 306, 0>
>         media_interaction on
>         shadowless //made this shadowless for test run
> }
> 
> light_source { //#3
>         <0, 0, 82>
>         color rgb <2.00, 2.00, 0.50>
>         cylinder
>         radius 45
>         falloff 47
>         tightness 100
>         point_at <0, 50, 82>
>         rotate <0, 342, 0>
>         media_interaction on
>         shadowless //made this shadowless for test run
> }
> 
> light_source { //#4
>         <0, 0, 82>
>         color rgb <0.50, 2.00, 0.50>
>         cylinder
>         radius 45
>         falloff 60
>         tightness 100
>         point_at <0, 50, 82>
>         rotate <0, 18, 0>
>         media_interaction on
>         shadowless //made this shadowless for test run
> }
> 
> light_source { //#5
>         <0, 0, 82>
>         color rgb <0.50, 0.50, 2.00>
>         cylinder
>         radius 45
>         falloff 47
>         tightness 100
>         point_at <0, 50, 82>
>         rotate <0, 54, 0>
>         media_interaction on
>         shadowless //made this shadowless for test run
> }
> 
> light_source { //#6
>         <0, 0, 82>
>         color rgb <2.00, 0.50, 2.00>
>         cylinder
>         radius 45
>         falloff 47
>         tightness 100
>         point_at <0, 50, 82>
>         rotate <0, 90, 0>
>         media_interaction on
>         shadowless //made this shadowless for test run
> }
> 
> camera {
>         location <0, 200, 0>
>         look_at <0, 0, 0>
> }
> 
> // Every scene needs some objects.
> 
> // I've never used discs before.. but layering concentric rings
> // was the only way I could think of to get the pattern I wanted.
> // The discs have the "rad" pattern, one half phase off from each other.
> 
> disc { // White circle in the center
>         <0, 0, 0>, y, 5
>         pigment {color rgb 1}
> }
> 
> disc {
>         <0, 0, 0>, y, 10, 5
>         pigment {rad}
> }
> 
> disc {
>         <0, 0, 0>, y, 15, 10
>         pigment {rad phase 0.5}
> }
> 
> disc {
>         <0, 0, 0>, y, 20, 15
>         pigment {rad}
> }
> 
> 
> disc {
>         <0, 0, 0>, y, 25, 20
>         pigment {rad phase 0.5}
> }
> 
> disc {
>         <0, 0, 0>, y, 30, 25
>         pigment {rad}
> }
> 
> disc {
>         <0, 0, 0>, y, 35, 30
>         pigment {rad phase 0.5}
> }
> 
> disc {
>         <0, 0, 0>, y, 40, 35
>         pigment {rad}
> }
> 
> disc {
>         <0, 0, 0>, y, 45, 40
>         pigment {rad phase 0.5}
> }
> 
> disc {
>         <0, 0, 0>, y, 50, 45
>         pigment {rad}
> }
> 
> disc {
>         <0, 0, 0>, y, 55, 50
>         pigment {rad phase 0.5}
> }
> 
> disc {
>         <0, 0, 0>, y, 60, 55
>         pigment {rad}
> }
> 
> disc {
>         <0, 0, 0>, y, 65, 60
>         pigment {rad phase 0.5}
> }
> 
> disc {
>         <0, 0, 0>, y, 70, 65
>         pigment {rad}
> }
> 
> 
> // this large ring immediately surrounds the floor
> difference {
>         cylinder {
>                 <0, -3, 0>, <0, 1, 0>, 72
>         }
> 
>         cylinder {
>                 <0, -3.1, 0>, <0, 1.1, 0>, 70
>         }
>         texture {stonetexture}
> }
> 
> // this outer ring will surround the floor, and the several mini-rings that will
hold the fountains.
> difference {
>         cylinder {
>                 <0, -3, 0>, <0, 1, 0>, 94
>         }
> 
>         cylinder {
>                 <0, -3.1, 0>, <0, 1.1, 0>, 92
>         }
>         texture {stonetexture}
> }
> 
> // Here's the ground that will surround the floor.  I cut out the area where
> // the floor and rings are so you don't see grass (or this really bad
> // aproximation of grass) in the bottom.
> difference {
>         plane {
>                 y, -0.5
>                 texture {
>                         pigment {
>                                 color rgb <0.25, 1.00, 0.25>
>                         }
> 
>                         normal {
>                                 average
>                                 normal_map {         // just arbitary trial & error
numbers to not
>                                         [granite 2]  // have too smooth of a ground
>                                         [bumps 1]
>                                         [dents 2]
>                                         [crackle 1]
>                                 }
>                         }
>                 }
>                 hollow
>         }
> 
>         cylinder {
>                 <0, -3.00001, 0>, <0, 1, 0>, 94
>                 texture {
>                         pigment {
>                                 color rgb 0.50
>                         }
> 
>                         normal {
>                                 average
>                                 normal_map {
>                                         [granite 2]  // more arbitrary trial & error
valuse to make
>                                         [crackle 2]  // the inside of the pools not
be smooth
>                                 }
>                         }
>                 }
>          hollow
>          no_shadow
>         }
>         hollow on
> }
> 

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto:inv### [at] aolcom?Subject=PoV-News

[Dave Helfrich] Where are my lights???? [9860 days 7 hours and 30 minutes ago]

Fri, 9 Apr 1999 03:42:52 GMT

Hi everyone!  I've been working on a scene and I'm having some trouble with
some cylindrical lights I have in there.  In a nutshell, the scene thus far
is a top view of a floor (made of nested discs), surrounded by a moat-like
stone ring.  The bottom of the ring is at -3 along the y axis.  I have 6
cylinder lights all starting at <0, 0, 82> and rotated to the places I want
them.  The problem is that they don't light anything unless I make them
shadowless.  I'm including 2 images... the first one rendered without the
shadowless lights, the second with them.  I'm guessing that they're not
lighting anything because there's something blocking them and casting a
shadow.  I tried using the "no_shadow" option on the objects around the
lights, but it didn't help.  What's wrong?  I'm also attaching the source.

I'd appreciate any help anyone could give me.

Thanks!
Dave.

[Bob Hughes] Re: location <0,0,0> [9860 days 15 hours and 47 minutes ago]

Thu, 8 Apr 1999 19:26:03 GMT

Looks like it's going to be a great resource. Good work.
Got lessons on how to make a website look professional like that? j/k!
Mine is like so many others, personal chaos. LOL


Ron wrote:
> 
> Hello,
> I'd like to invite everyone to the new web site location <0,0,0> which is
> dedicated to helping POV-Ray users.
> You can reach the site either by going to http://welcome.to/location.0.0.0
> or http://www2.cybercities.com/l/location/
> Feel free to send me feedback.
> Thanks,
>         Ron

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto:inv### [at] aolcom?Subject=PoV-News

[Ron] location <0,0,0> [9860 days 19 hours and 21 minutes ago]

Thu, 8 Apr 1999 15:52:09 GMT

Hello,
I'd like to invite everyone to the new web site location <0,0,0> which is 
dedicated to helping POV-Ray users.
You can reach the site either by going to http://welcome.to/location.0.0.0 
or http://www2.cybercities.com/l/location/
Feel free to send me feedback.
Thanks,
	Ron

[Nathan Zwalsh] Df3 Help Please [9867 days 2 hours and 30 minutes ago]

Fri, 2 Apr 1999 08:43:03 GMT

i need help with the media density file's. i'm trying to simulate a
nuclear explosion using df3s and a cube, instead of using cylinder +
sphere objects. if any one can show me a decent tutorial or help me with
this i would be very grateful.

Nathan Zwalsh
nrz### [at] fatnetnet
p.s I've already downloaded the TGA2DF3 program.

[JORDIPC] Spanish Pov Team [9881 days 11 hours and 11 minutes ago]

Fri, 19 Mar 1999 00:01:29 GMT

Hola...

Envio este emilio porque estoy buscando personas que tengan ganas de
desarrollar proyectos en equipo, para compartir conocimientos y dudas,
en fin para no trabajar en solitario con este programa tan potente...

Si estas interesado hazmelo saber:
cra### [at] axisorg

[tommaso] SOLIDO [9882 days 1 hour and 16 minutes ago]

Thu, 18 Mar 1999 09:57:14 GMT

con il POVRAY

voglio disegnare un SOLIDO con 8 vertici
come fare?


NON   con la "box" (2 punti opposti) e poi con "scale"
NON   con "union" di 6 polygons


Ma solo introducendo le coordinate di 8 punti generici.



Grazie

Tommaso

Tst### [at] capoleucait

[Bob Hughes] Re: Winner's tutorials [9885 days 22 hours and 18 minutes ago]

Sun, 14 Mar 1999 12:54:56 GMT

Quite a concept there.
Only thing I can mention is about the drawings, in the lower left corner
the first "highlight" example is apparently horizontally flipped. Makes
for a bit of confusion.
Liked getting the inside info on what was going on for the making of
that render, interesting stuff.
I usually read those texts that go along with the IRTC entries but
seldom read more than a few at a time. Maybe this will put it all out in
the open more.

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

[Fabien Mosen] Winner's tutorials [9886 days 1 hour and 20 minutes ago]

Sun, 14 Mar 1999 09:53:13 GMT

There is currently a discussion on the IRTC mailing list
where people asks winners of IRTC rounds to write tutorials
about how they work to achieve these results.

Since I won the "elements" round, I tried to write the
first "winner's tutorial"...  It's been posted on the mailing list,
but, here, I can add the scanned sketches...

Comments, suggestions, whatever, tell me !

Cheers,
Fabien.

**********************************************************
IRTC WINNER'S TUTORIAL - ELEMENTS (jul-aug 98)- PXL506.JPG
**********************************************************

THE IDEA
--------
First, JM came up with a simple idea : showing the pixels (picture
ELEMENTS)
of a screen.  In further discussions, some changes popped up : it could
be
figured with r/g/b flowers, or r/g/b bees in a honeycomb.  I especially
liked the idea of the honeycomb because it was close enough to the real
arrangement of phosphors.  In fact, since I had already sumitted
someting for 
that round (fmelem.jpg), I expected JM to create the scene.  As time
passed,
it seemed JM hasn't enough interest/skills (he's a beginner) to do it,
and 
I decided to do it myself, wishing to not abandon such a good idea.
Then, instead of bees, I imagined putting little people, with their own
little
domestic lives, in the honeycombs.  At that moment, the problem I
encoutered
was : "how do I make it clear that they are pixels from a screen ?";  I
had to
show both the screen and the big pixels... -dong !- a magnifying glass
!!
That's it !
At that point, the setup is clear : a screen, a magnifying glass, and
simple
surroundings.

THE HONEYCOMB
-------------
I did some sketches (see the scanned ones) to create the people and
their
"houses".  The little guys were designed from the start to have
articulated
members, something that would be easy to position with a simple macro.
When using one people, you just give the rotation of shoulders,
knees,...
They are simple CSG, so is the furniture.  Each room is white, with
only one area light to give the overall color; the area light allows
the soft and grany aspect that I like.  3 different rooms were created,
and repeated along.  Final step was to render that at 800*600, with
a camera angled to match approximatively the angle between the screen
and the mag. glass (nothing very precise, but it looks good enough)


THE SCREEN
----------
The general dimensions are taken on a 15" screen.  The rendered model is
entirely imaginary, because I needed something simpler, that would not
take too long to render.
It uses some complex (well, not too much) CSG, attention was paid to
curved surfaces and chamfered corners, because they "attract" highlights
much better than flat and right corner shapes.
The "PXL-506" label is in fact the car plate of JM ! (and is a
height-field).
Inside the screen, there's a coloured lightsource that fake the light
coming
from the cathodic tube, and, of course, the image_map is no_shadowed...
I had to choose a map for the screen.  While I'm using a Win-AMD
computer,
I didn't want to show a Windows screen, much too common and graphically 
uninteresting; Mac is also too common; I wanted something that will be
recognised
by people who knows more marginal platforms.  I finally choosen to use
a NextStep (the OS Steve Jobs created after leaving Apple) screenshot,
and found one quickly by searching on the web.
A careful attention was paid to the plastic texture, zooming very
strongly
on the surface to find the right normal scaling.

THE MAGNIFYING GLASS
--------------------
Structurally simple, but since it's viewed from very close, it needs
high
detail level.  See sketch to have an explanation about the profile.
The connection between the handle and the glass needed to be "animated",
with some shape complication, to make it visually interesting.
The image of the "pixels" is mapped onto a disc inside the glass, and 
the glass is a refractive flattened sphere.

THE WALL BEHIND
---------------
The wooden plinth is made of rounded elements, just to catch highlights
andinteresting shadows.  Careful wood scaling (and orientation !)is very 
important, as is the randomization of the position of the woodgrain
between 
each vertical board (if you repeat the object along with its texture,
the repeat 
will show badly).
The wallpaper is mainly a plane with a checker-in-checker bluish
texture;
In real life, most of the wallpapers tend to unglue at the junction with
a plint.  That's why I put a height-field, with the same texture, just
at
the top of the plinth, to simulate that imperfection.

THE LIGHTS
----------
- a general area-light, that cast some ambient lighting; kind of faked 
radiosity (less compute-intensive !)
- an area light in the desk (?) lamp, wich give vivid lighting to the
important 
elements in the scene.  Point-lights doesn't exist in real life; to
achieve
some realism, area lights are the way to go (provided the settings are
correct :
if you model a lamp, use the size of the reflector as the area size).
- a light inside the monitor (see higher)

all lights in the scene are sliiiiiightly colored, it gives you control
about
warmth or coldness of a light (white light doen't exist, either).

THE CUP OF POV-TEA
------------------
It's a composition-filler; I really took a cup and made some tea, to
find 
the good color, and I observed that the liquid intersected with the
recipient
as a "negative torus"; it was modelled like that, and catch a nice
highlight.
The sticker was inspired by a real Lipton sticker, paying some tribute
to the
POV-Tea(m)... (I think that it attracts sympathy from many voters ;). 
It
says : "Pov-Tea(m) - pigment Yellow - Quality 9" instead of "Lipton  -
Yellow 
Label Tea - Quality N°1"

NOTES
-----
The composition is quite framed (it's usually how I do); the screen is
one
frame, the mag.glass is another one, the blue wall and yellowish wood
almost
define to squares.  This gives opportunity to put interest in different
areas,
having a main subject, and subsequent things around.

Many elements of the scene are the result of cautious real-life
observations :
the light inside the screen, the tea in the cup...

[Ken] Re: Good sPatch tutorial [9888 days 1 hour and 18 minutes ago]

Fri, 12 Mar 1999 09:54:40 GMT

Richard Speir wrote:
> 
> I'm looking for an sPatch tutorial, and am wondering if anyone could
> provide me with a link. I'm especially interested in organic modeling,
> specifically plants, but any help would be appreciated. Thanks.

Check out the tutorials on this page:

http://www.geocities.com/SoHo/Studios/7415/tutorial1.html

-- 
Ken Tyler

mailto://tylereng@pacbell.net

[Richard Speir] Good sPatch tutorial [9888 days 4 hours and 50 minutes ago]

Fri, 12 Mar 1999 06:23:09 GMT

I'm looking for an sPatch tutorial, and am wondering if anyone could
provide me with a link. I'm especially interested in organic modeling,
specifically plants, but any help would be appreciated. Thanks.

[Ken] 2D to 3D Image Tutorial (500k) [9894 days 22 hours and 45 minutes ago]

Fri, 5 Mar 1999 12:28:08 GMT

By: Ken Tyler
Date: 03-05-1999


  A simple approach to making 3D objects from 2D images:


   The contents of the enclosed zip file demonstrate how to extract an
 object or part of an image and use it to create a duplicate of that object
 in 3D using a height field as the method employed to give 3 dimensional
 characteristics. There is an assumption that you have the program Leveller
 installed on your system. While not mandatory to the process it can and
 will make it easier for you to make it happen. If you are impaired by the
 OS you use then you can follow the part of the tutorial that explains how
 to extract the image and then use what ever method you need to use to finish
 from there. Probably the single hardest part is getting a good clean image
 to work with and then extractining just the right parts of the image. The
 rest is just proceedural modeling (yeah right).

    I did not plan on releasing this publicly as it was a favour to another
 user. As such it is very rough and not well articulated. If someone finds
 the information useful and learns a new skill then it has more than served
 it's original purpose. I have no plans on developing this any further than
 what you will find with inside the zip file.

   Anyway here is the basics on the included material. I choose a simple
 maple leaf as the object to create. It proceeded quickly in terms of
 processing and took about 4 times as long to document. If you read the
 readme.txt file first it explains what the images in the zip file are
 for. The HF_TUTOR.TXT is the tutorial and there is an example .pov scene
 file provided as well. I suggest you get it out of your system an render
 the .pov file right away. This way by seeing the results possible the
 process part won't sound as bad as it might otherwise.

   If you look carefully at the rendered image from pov there are little
 artefacts visible around where the image border would have been. I missed
 that part when I was blocking out the background and it shows how much
 attention to detail is necessary to get good results. Also I put absolutely
 no extra effort into the finer details that would make this look even better.
 Feathering the edges, cleaner blocking of the background, and a little more
 work spent on some of the large veins in the leaf and this would almost rate
 as a classic pov object.

   The original .jpg is included for reference and I'm sure you will agree
 the process has more possibilities than many people would think. When you
 look at the original image you will see that it is almost trash file quality.
 If you can take an image this poor in quality and produce something useful
 with it just imagine what you can do with a high quality image to start with.

  Good luck and if I can clear up any confusion or answer any questions about
 the process I'll be around. Just give a yell. Jim Kress has a good feel for
 the process now and can also answer specific questions related to the project
 he just finished.


-- 
Ken Tyler

mailto://tylereng@pacbell.net

[Spider] Re: Spiral objects? [9906 days 12 hours and 18 minutes ago]

Sun, 21 Feb 1999 22:54:43 GMT

Julius Klatte wrote:
> 
> >I think my reply was if anything accurate and in context
> with the
> >requested information. If time had permitted I would have
> provided
> >a more a definitive answer.
> 
> Sorry Ken, my answer was aimed at Spider's message... I
> guessed it missed its target.
> I took a look at your list (nice work by the way) and
> couldn't find anyone really covering the subject, so I guess
> I'll have an addition to your list in a moment (or a bit
> longer).
I think I got the point, and I really hope I didn't offend you. That was
not my intention.

-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

[Julius Klatte] Re: Spiral objects? [9906 days 12 hours and 18 minutes ago]

Sun, 21 Feb 1999 22:54:39 GMT

>humble apologizes.


That's not necessary... I wasn't offended, just surprised

Julius

[Julius Klatte] Re: Spiral objects? [9906 days 12 hours and 20 minutes ago]

Sun, 21 Feb 1999 22:52:59 GMT

>I think my reply was if anything accurate and in context
with the
>requested information. If time had permitted I would have
provided
>a more a definitive answer.

Sorry Ken, my answer was aimed at Spider's message... I
guessed it missed its target.
I took a look at your list (nice work by the way) and
couldn't find anyone really covering the subject, so I guess
I'll have an addition to your list in a moment (or a bit
longer).

Thanks again

Julius

[Spider] Re: Spiral objects? [9908 days 12 hours and 11 minutes ago]

Fri, 19 Feb 1999 23:01:25 GMT

:oþ

[Spider] Re: Spiral objects? [9908 days 12 hours and 11 minutes ago]

Fri, 19 Feb 1999 23:01:23 GMT

Ahh, sorry for my misinterpretation of the question. I humbly apologize
If I have offended you by my lack of understanding in the English
language.

humble apologizes.
-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

[Ken] Re: Spiral objects? [9909 days 10 hours and 22 minutes ago]

Fri, 19 Feb 1999 00:50:39 GMT

Julius Klatte wrote:
> 
> Guys!
> What do you take me for?!
> 
> I KNOW how spirals should be made, what I asked was if
> anyone knew of an already existing tutorial about it, since
> I'm thinking about making one myself...
> 
> Thanks.... I guess...?
> 
> Julius

I think my reply was if anything accurate and in context with the
requested information. If time had permitted I would have provided
a more a definitive answer. As I either did not know at that time,
or had no time to find out, I at least narrowed the field of search
for you by a very wide margin.

At least "I" didn't just provide an example like one other person did.

:)

-- 
Ken Tyler

mailto://tylereng@pacbell.net

[Julius Klatte] Re: Spiral objects? [9909 days 11 hours and 21 minutes ago]

Thu, 18 Feb 1999 23:51:45 GMT

Guys!
What do you take me for?!

I KNOW how spirals should be made, what I asked was if
anyone knew of an already existing tutorial about it, since
I'm thinking about making one myself...

Thanks.... I guess...?

Julius

[Ken] Re: Spiral objects? [9917 days 8 hours and 36 minutes ago]

Thu, 11 Feb 1999 02:36:43 GMT

Julius Klatte wrote:
> 
> Does anyone know of an already existing tutorial about
> creating spiral shapes?
> 
> Thanks
> 
> Julius

There is a new group on the server called announce.frequently.asked.questions
that I posted a pov tutorials link faq to last week. If there has been a
tutorial written on the subject you will find a link for it there.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

[Spider] Re: Spiral objects? [9917 days 13 hours ago]

Wed, 10 Feb 1999 22:12:51 GMT

There was a thread called 3D match some time ago in .general, where a
spiral was created..

An easier way to do it is like this: (untested)

#declare rounds = 15;
#declare radii = 10;
#declare O = sphere { <0,0,0>,0.5 pigment { Yellow }}
#declare MaxY = 50;
#declare Num = 1500;
#declare iNum = 1/Num;
#declare iNum360 = iNum*360;
#declare iNumMaxY = iNum*MaxY;
#declare N=Num;
#while(N>0)
  object {O translate <radii,N*iNumMaxY,0> rotate <0,N*iNum360,0> }
  #declare N = N-1;
#end

This should do a spiral between 0 and MaxY, evenly spread with Num
objects. 
I also have a spiral like #macro in the fireworks include file. The one
to make the trails of the fireworks.

//Spider
Julius Klatte wrote:
> 
> Does anyone know of an already existing tutorial about
> creating spiral shapes?
> 
> Thanks
> 
> Julius

[Julius Klatte] Spiral objects? [9917 days 14 hours and 5 minutes ago]

Wed, 10 Feb 1999 21:07:30 GMT

Does anyone know of an already existing tutorial about
creating spiral shapes?

Thanks

Julius

[news povray org] perhaps usefull for someones ?? [9925 days 21 hours and 30 minutes ago]

Tue, 2 Feb 1999 13:42:43 GMT

I write this for my own usage. It can help you to put your camera or to
choose the scale : Your Unit/ POV Unit. Sorry for my english, but I'm
french.

[Mike] Re: Its not so simple [9981 days 7 hours and 17 minutes ago]

Wed, 9 Dec 1998 03:55:25 GMT

No, you're right.

But think of it this way...media actually makes more sense.  Ever get
consistent results with a glowing media?  I never did.  And attenuating
kinda' stunk.  It didn't absorb, it just added it's color to the one
behind it.

Media is pretty simple.  If you want it to absorb, just give it an
absorption and a value.  Emit - emission and a value.  Scatter some
light - scattering and a value.  A little of each - just use more than
one.

It's different, but in my opinion it's better too.  The odd reflection
artifacts when using halos seem to be gone now.  I still keep a copy of
3.02 on my computer, but I use 3.1 for most of my new work.

-Mike

Axel Baune wrote:

>  In general it is not possible to convert the old Halos to the new
> Medias because they are completly different implemented. If I am wrong
> please report!
>
>

[Axel Baune] Its not so simple [9981 days 19 hours and 3 minutes ago]

Tue, 8 Dec 1998 16:10:13 GMT

Hello,

I've tried it for myself to convert old Haloeffects to the new Medias,
and found ist is not possible to get
the same effects as with the old halos.

One problem is, that the New Medias ignore the transmit and filter
informations of the colors. For some of the Halos you could convert them
to new Medias under certain circumstances, but this is not possible for
all and somtimes it is very difficult to get the old effects.

The scaling problem persist in the form, that when you scale the media
the same portion of emitting, absorption or scattering is distributed to
a larger space. This means you will get lower emission, absorption or
scattering per unit. To compensate this effect simly scale the amount of
emitting, absorption or scatterin in the same way as the object, i.e. if
you have emitting 0.75 befor scaling try emitting 0.75*Scaling for the
scaled Object.

In general it is not possible to convert the old Halos to the new Medias
because they are completly different implemented. If I am wrong please
report!

Yours Axel

--
------------------------------------------------------------------------------
Axel Baune                                            Phone:  +49 731 502 4242
Department of Neural Information Processing             Fax:  +49 731 502 4156
University of Ulm
89069 Ulm                            email: aba### [at] neuroinformatikuni-ulmde
Germany                            URL (privat): http://www.uni-ulm.de/~abaune
------------------------------------------------------------------------------

[Saif Ansari] Superpatch. [9990 days 6 hours and 12 minutes ago]

Mon, 30 Nov 1998 05:00:30 GMT

Any tutorials or extended helpfiles available?  I'm a bit dense and have
trouble with the helpfiles that came with it ... I can fill out the 
basics, but I can't really apply them.  Don't mean to belittle the
software or the helpfile - they're both great, just a problem with my
own brain :)

Thanks.
-- 
Saif Ansari
	Choking on the dust of humanity
	Slashing my wrists with silicon

"And when you see what's been achieved,
is there a feeling that you've been decieved?"  - Dave Gilmour

[Mike] Re: Help: Povray 3.1 new atmosphere stuff [9996 days 20 hours and 8 minutes ago]

Mon, 23 Nov 1998 15:04:53 GMT

Phase alone doesn't do a very good job of simulating water in my opinion.
You'll get better results by averaging patterns and moving them in
different directions.  You can include phase with the averaged patterns.

You really should use normals for creating your water surface.  The reason
it looks bad is that the official POV doesn't take angle into account for
calculating reflection.  You will get much better results using Mike
Paul's wyzPOV, which you can get at http://twysted.net.  It's also
included in the superpatch, minus the total internal reflection ( the part
that makes prisms act as a mirror).

Some pattern suggestions:  Try a gradient pattern for getting the look of
waves on the shoreline. Bumps looks good for farther out waves.  Try the
bumps traveling a little along the y axis too to get more variation to the
waves.

Tim Soderstrom wrote:

> Wow that was quick :) Thanks for the help! ONE more thing, if you can
> help me (I forgot to mention this after I posted it). the Pov-Ray DOC
> (thank God for it) mentions about phasing pigments and such. However,
> I'm having a problem doing it. I've done it before, but it wasn't fast
> enough, so I upped the clock value:
>
> sphere{
>  <0, 0, 0>
>  15
>  pigment{
>   bozo
>   color_map{
>   [0 rgb <1, 1, 1>]
>   [1 rgb <0, 0, 0>]
>   }
>  phase (clock*4)
>  }
> }
>
> but the AVI didn't show much. What I am wondienrg is how to properly
> achive something like a realistic water texture (using a pigment and
> *NOT* normal, as the reflection of objects goes to crap) that
> ripples....
>
> Thanks again for your help, hope I'm not being too annoying :)
>
> Tim Soderstrom
>

[Tim Soderstrom] Re: Help: Povray 3.1 new atmosphere stuff [9997 days 15 hours and 34 minutes ago]

Sun, 22 Nov 1998 19:39:03 GMT

Wow that was quick :) Thanks for the help! ONE more thing, if you can 
help me (I forgot to mention this after I posted it). the Pov-Ray DOC 
(thank God for it) mentions about phasing pigments and such. However, 
I'm having a problem doing it. I've done it before, but it wasn't fast 
enough, so I upped the clock value: 

sphere{
 <0, 0, 0>
 15
 pigment{ 
  bozo
  color_map{
  [0 rgb <1, 1, 1>]
  [1 rgb <0, 0, 0>]
  }
 phase (clock*4)
 }
}

but the AVI didn't show much. What I am wondienrg is how to properly 
achive something like a realistic water texture (using a pigment and 
*NOT* normal, as the reflection of objects goes to crap) that 
ripples....

Thanks again for your help, hope I'm not being too annoying :)

Tim Soderstrom

Ken wrote:
> 
> A short tutorial on media can be found at:
> http://members.xoom.com/POVRAY3/media1.html
> 
> I don't know if it will help but it can't hurt.
> 
> I'm not sure about the official release of v3.1 for linux but
> there has been an unofficial release or two. There was an
> announcement on povray.general about it sometime shortly after
> the official windows release came out. I believe the posters
> name was Glen Berry and had the url. Twist's site might also
> have a copy of it laying around. For that try:
> http://www.twysted.net
> 
> Ken Tyler
>

[Ken] Re: Help: Povray 3.1 new atmosphere stuff [9997 days 15 hours and 53 minutes ago]

Sun, 22 Nov 1998 19:19:56 GMT

A short tutorial on media can be found at:
http://members.xoom.com/POVRAY3/media1.html

I don't know if it will help but it can't hurt.

I'm not sure about the official release of v3.1 for linux but
there has been an unofficial release or two. There was an
announcement on povray.general about it sometime shortly after
the official windows release came out. I believe the posters
name was Glen Berry and had the url. Twist's site might also
have a copy of it laying around. For that try:
http://www.twysted.net

Ken Tyler

[Tim Soderstrom] Help: Povray 3.1 new atmosphere stuff [9997 days 16 hours and 3 minutes ago]

Sun, 22 Nov 1998 19:09:38 GMT

Before Pov-Ray 3.1 came out, I think I had finally perfected the use of 
atmospheric effects, then 3.l came out...heh. The problem I am having is 
that the povuser.txt file doesn't have sufficient informatino on using 
the new atmospheric effects. I ended up just droping it in a scene I was 
working on, and it ended up working out for the better. 

BUT, just so I know, how do I set an atmospheric effect to show a rainy 
haze that only really shows up when light hits it (I was trying to get 
spotlight beams to show up). I tried doing it, but I got a lot of 
distortion and grainy stuff.. I thought about using clear boxes and 
filling them with an atmosphere, but then I would also have to simulate 
fog...argh! :)

Any help would be apreciated. If you could direct me toward an example, 
or a documented source, that'd be just fine by me! :)

Also, any ideas of when Pov-Ray 3.1a will be comming out in Linux?

[Dave] Any Ideas? [10001 days 12 hours and 54 minutes ago]

Wed, 18 Nov 1998 22:19:05 GMT

Hi all.
Does anyone out there have any ideas on how I might model a christmas
stocking?  (in 3.1)  I was thinking on making one out of blobs, but I'm not
very proficient with them...  I never seem to get the result I expect, and
less often the result I want...  Any other ideas?  (And I'll settle for any
type stocking.. the modern shaped kind or the kind that look like real
socks.  I'm not picky <G>)

Thanks!

Ciao!
DH

[Joost Smits] Conversion Halos to PovRay 3.1? [10005 days 20 hours and 12 minutes ago]

Sat, 14 Nov 1998 15:01:12 GMT

Dear all,

I got lost a bit. I always used halos in PovRay 3.0, for example to make

nice stars in the sky. In PovRay 3.1 this all changed. I do not
understand what I need to do to make the new interior/media combination
to work like the old halos... Is there a
conversion rule?

--
Joost Smits
jsm### [at] prizenl

[support] Freeware Newsreader software/Usenet Open server ... [10021 days 17 hours and 12 minutes ago]

Thu, 29 Oct 1998 18:00:52 GMT

The eBayTech website has been updated as of October 1, 1998

The Usenet open server list has been updated as of October 23, 1998 and contains 870
servers.

http://www.ebaytech.com/resource.htm

*UsenetGrab! version 2.0 will be available on October 26, 1998. (for Usenet)
*WebGrab! version 1.1 will be available on October 30, 1998. (for WWW)
*AudioGrab! version 1.0 will be available on November 1, 1998. (for MP3
Search/AudioSearch)

And...If you didn't know it, ALL version 1.0 software is completely free.  
(Check the site for registration codes!)

http://www.ebaytech.com/software.htm

Thanks-
eBayTech
http://www.ebaytech.com/

[Psychomek] Help... Need a matrial map [10025 days 21 hours and 29 minutes ago]

Sun, 25 Oct 1998 13:43:56 GMT

Hi i need a Stained glass image for a matrial map for moray   Preferably
one similar to a tiffany lamp shade

[Peter Popov] Re: Fractal tutorials? [10040 days 8 hours and 9 minutes ago]

Sun, 11 Oct 1998 03:03:52 GMT

Psychomek wrote in message <361FC1D5.7E23AE90@geocities.com>...
>  I just started playing with a hypercomplex fractal....    below is the
fractal
>script...   but it is a bad image.. :{


<code>

>most of the fractal is out of view and i haven't had time to run a picture
with

That's the first problem I encountered with these complex types -- they are
quite unpredictable. I had to manually place the camera in each picture so
that I could see something. No good for a weekend render.

>a better view point.... :{   but as you can see I have a complex one for
the
>Hypercomplex fractals :}   my type of personality make something simple and
make
>it as complex as posible!  as soon as i can find a computer store where i
can
>buy a dual procsessor motherboard, i will really make some interesting pics
:}

Yeah, that's the second problem. I have virtually 1000+ vube and sqr pics,
but very little of the other kinds. I have a K6, and it's not an FPU
champion :(

Please post some of the pics you like... as well as code :)

Peter

[Psychomek] Re: Fractal tutorials? [10040 days 13 hours and 49 minutes ago]

Sat, 10 Oct 1998 21:23:26 GMT

Peter Popov wrote:

> Psychomek wrote in message <361D3243.723D33DE@geocities.com>...
> >Are there any Fractal tutorials for povray out there?
>
> I haven't seen any. The best way to do this is to render, say, 250 fractals
> of each main type (sin, cos hypercomplex and quaternion) and see how their
> parameters affect the shape. The more complex functions aren't as
> predictable and are much slower to render, so this approach may not help
> you. I personally think that they aren't as interesting as cube or sqr.
> Anyway, when you get one you like, start tweaking to get a better idea of
> the control params. I can post a POV file that will render a random
> (clock-based) julia and display the parameters on the screen (i.e. in the
> image itself), useful for cube & sqr quaternion and hypercomplex (they fit).
>
> Peter

  I just started playing with a hypercomplex fractal....    below is the fractal
script...   but it is a bad image.. :{

#declare W = 5
#declare P = 3.141592
#declare D = 21
#declare J = 47
#declare K = 640


julia_fractal {
    <-0.083,0.0,-0.83,-0.025>
    hypercomplex
    pwr(cos((W*P)/(D*K)),K/P*J)
    max_iteration 15
    precision 90
    texture {
    T_Ruby_Glass
      }
    }
most of the fractal is out of view and i haven't had time to run a picture with
a better view point.... :{   but as you can see I have a complex one for the
Hypercomplex fractals :}   my type of personality make something simple and make
it as complex as posible!  as soon as i can find a computer store where i can
buy a dual procsessor motherboard, i will really make some interesting pics :}

[Peter Popov] Re: Fractal tutorials? [10041 days 9 hours and 5 minutes ago]

Sat, 10 Oct 1998 02:07:44 GMT

Psychomek wrote in message <361D3243.723D33DE@geocities.com>...
>Are there any Fractal tutorials for povray out there?


I haven't seen any. The best way to do this is to render, say, 250 fractals
of each main type (sin, cos hypercomplex and quaternion) and see how their
parameters affect the shape. The more complex functions aren't as
predictable and are much slower to render, so this approach may not help
you. I personally think that they aren't as interesting as cube or sqr.
Anyway, when you get one you like, start tweaking to get a better idea of
the control params. I can post a POV file that will render a random
(clock-based) julia and display the parameters on the screen (i.e. in the
image itself), useful for cube & sqr quaternion and hypercomplex (they fit).

Peter

[Psychomek] Fractal tutorials? [10042 days 12 hours and 26 minutes ago]

Thu, 8 Oct 1998 22:46:29 GMT

Are there any Fractal tutorials for povray out there?

[Eric] Twyst and twysted.net [10051 days 2 hours and 9 minutes ago]

Wed, 30 Sep 1998 09:03:26 GMT

[Dave] Re: Rotating CSGs [10066 days 7 hours and 34 minutes ago]

Tue, 15 Sep 1998 03:38:27 GMT

>It easy with just a ball because all you have to do is rotate the
>texture but once I get to rotating the whole CSG it always rotates
>around an axis unkown? and sorta orbits it's original location.



That's exactly what it does.  the "rotate" command rotates things in
reference to the origin.  to rotate just the object, you'd have to translate
it so it's centered around the origin, rotate it, then translate it back to
where you want it.

Dave

[Dave] Re: #if...#else...#HELP!!! [10066 days 7 hours and 40 minutes ago]

Tue, 15 Sep 1998 03:32:31 GMT

Thank you very much... I'll try that!

[Philippe Debar] Re: #if...#else...#HELP!!! [10077 days 12 hours and 59 minutes ago]

Thu, 3 Sep 1998 22:13:47 GMT

Hi Dave

#if (clock<=1)
  translate <0, clock*20, 0>
#else
  #if (1<clock<=2)
    #declare elseclock = clock-1
    translate <0, 20, 0>
    rotate <0, 0, ((clock-1)*180)>
  #else
    #if (2<clock<=3)
      translate <0, -20, 0>
    #else
      #if (clock<=4)
        #declare elsclock= clock-3
        translate (-20+(20*(clock-3)))*y
      #end
    #end
  #end
#end

Why it doesn't work: (or so I believe)
(1<clock<=2)
pov first evaluates 1<clock and returns either false (=0) or true
(=1), then it check the resulting boolean<=2, which is always true...
you should write ((1<clock)&(clock<=2)).

However, there is a simpler way to do this: #switch

#switch (clock) // use clock for all tests
  #range (0,1) // if 0<=clock<=1, then...
    translate <0, clock*20, 0>
  #break //<-- this exit the #switch test, so #range(1,2) isn't used
too when clock=1
  #range (1,2)
    translate <0, 20, 0>
    rotate <0, 0, ((clock-1)*180)>
  #break
  #range (2,3)
    translate <0, -20, 0>
  #break
  #range (3,4)
    translate (-20+(20*(clock-3)))*y
  #break // this one isn't necessary... but it is neater this way.
  #else
    #error "\nClock out of range" // just for fun
#end // close the #switch directive

#switch uses also #case(aValue), but in this case this isn't very
usefull - except if you want subliminal images :-) See the doc.

Hope this helps,

Povingly,

Philippe

[JohnT] Hourglass tutorial. [10079 days 12 hours and 14 minutes ago]

Tue, 1 Sep 1998 22:59:07 GMT

Hi, this may have been done before but as I am a beginner and also a helpful
chap I thought I would put a simple tutorial together to show how I did this
for other beginners to follow.

Regards,
JohnT

[Marcel Schmidt] GUI-Extensions [10086 days 18 hours and 10 minutes ago]

Tue, 25 Aug 1998 17:02:28 GMT

where can I get informations about writing POVRAY-3.x-GUI-Extensions?

Marcel Schmidt
mar### [at] theofficenet

[K Tyler] Re: Rotating CSGs [10104 days 22 hours and 57 minutes ago]

Fri, 7 Aug 1998 12:15:40 GMT

Gregoire Millette wrote:

> Anybody know how to rotate a CSG object properly.
> I have an animation I'm working on and  I have a CSG that I just want to
> rotate on it's X axis while having it move on the Z axis creating the
> illusion that it's rolling.
> It easy with just a ball because all you have to do is rotate the
> texture but once I get to rotating the whole CSG it always rotates
> around an axis unkown? and sorta orbits it's original location.
>
> Any ideas?
>
> Greg

  Some where in the POV-Ray docs, I believe in the tutorial, section 4,
discussing the use of the clock function. One of the demonstrations
used for the tutorial is that of a ball rolling along the floor left to right.
It will give you a pretty go idea of what kind of methods to use for
the effect you describe.

    I'll offer you a little hint to get you going.
Now that you have your object rotating on it's axis,
you need to apply a translate to the object `after' the
rotate statement.
    If you place it before the rotate statement it will
cause your object to travel in continuously expanding
circles rather than having it appear to roll across the
ground.

It would look something like this:

object{YourObject rotate 720*x*clock translate 100*z*clock.}

This example will have your object rotate completely
2 times during one clock cycle and move it 100 units
into the z direction at the same time.

The example in the docs tutorial is even more informative
and even tells you how to change the direction of travel half
way through your animation. I'd read up on it if I were you.

Hope this helps and happy rendering.

K.Tyler

[Gregoire Millette] Rotating CSGs [10104 days 23 hours and 54 minutes ago]

Fri, 7 Aug 1998 11:19:10 GMT

Anybody know how to rotate a CSG object properly.
I have an animation I'm working on and  I have a CSG that I just want to
rotate on it's X axis while having it move on the Z axis creating the
illusion that it's rolling.
It easy with just a ball because all you have to do is rotate the
texture but once I get to rotating the whole CSG it always rotates
around an axis unkown? and sorta orbits it's original location.

Any ideas?

Greg

[Qman] Texture Placement [10112 days 10 hours and 42 minutes ago]

Fri, 31 Jul 1998 00:30:29 GMT

Does Anybody have any tricks for placing image_maps on Mesh objects, Keeping
track of transformations.

I did translate < -0.5, -0.5, 0.0>, this helps with rotation. I Have a hard
time keeping orentation in my head. Any tips would be appreciated.

[marc] Re: Halos.... ? [10130 days 9 hours and 11 minutes ago]

Mon, 13 Jul 1998 02:01:34 GMT

Dana Dauphinee wrote in message <35A94BFE.E0793B8E@sympatico.ca>...
>
>
>Dave wrote:
>
>> Have you tried using fog?
>
> I've tried, but I can't get anything but a white mess with fog. :o( heh I
>don't have ANY luck, it seems!
>
>Dana
 I had the same prop with fog until twyst explained to me (in #POVRAY) try a
smaller distance the smaller the distance to less fog there is

[Dana Dauphinee] Re: Halos.... ? [10130 days 10 hours and 23 minutes ago]

Mon, 13 Jul 1998 00:50:04 GMT

Dave wrote:

> Have you tried using fog?

 I've tried, but I can't get anything but a white mess with fog. :o( heh I
don't have ANY luck, it seems!

Dana

[Dave] Re: Halos.... ? [10131 days 14 hours and 22 minutes ago]

Sat, 11 Jul 1998 20:50:39 GMT

Dana Dauphinee wrote in message <35A1B046.4BCC2B88@sympatico.ca>...
>    I'm not posting a file with this, I'd just like some help, since
>this is a Tutorials group.  I've posted my first semi-gratifying image
>on the binaries.images group, so if you want to take a look at it, it's
>there....
>    Anywho, my question is....  could someone explain to me a little but
>more about halos?  I have MoRay, and I've looked through the POV docs,
>and I'm never getting the results I'm after.  In my image, I have two
>cones, a spotlight focused on each.  I'd like to get a dust-like effect,
>or something of that sort, coming from the spotlight, so that it looks
>sort of like a streetlight shining on the cones... or like sunshine
>coming in from a dusty window... that sort of effect.  Is there anyway I
>can do this? I'm trying what I 'know' how to do, but, obviously, that
>isn't much.  What's the easiest way to do this?
>
>Many thanks for your help,
>
>~Dana
>
>(Oh, what the heck, Ill post my file here, too!)
>

Have you tried using fog?

[PoD] Re: Halos.... ? [10135 days 11 hours and 11 minutes ago]

Wed, 8 Jul 1998 00:01:31 GMT

Dana Dauphinee wrote:
> 
>     I'm not posting a file with this, I'd just like some help, since
> this is a Tutorials group.  I've posted my first semi-gratifying image
> on the binaries.images group, so if you want to take a look at it, it's
> there....
>     Anywho, my question is....  could someone explain to me a little but
> more about halos?  I have MoRay, and I've looked through the POV docs,
> and I'm never getting the results I'm after.  In my image, I have two
> cones, a spotlight focused on each.  I'd like to get a dust-like effect,
> or something of that sort, coming from the spotlight, so that it looks
> sort of like a streetlight shining on the cones... or like sunshine
> coming in from a dusty window... that sort of effect.  Is there anyway I
> can do this? I'm trying what I 'know' how to do, but, obviously, that
> isn't much.  What's the easiest way to do this?
> 
> Many thanks for your help,
> 
> ~Dana
> 
> (Oh, what the heck, Ill post my file here, too!)
> 

Have you read section 4.10.4 The Atmosphere in the docs?
Atmosphere is pretty slow to render and so a bit of a pain to get right
but the examples in the docs can be pasted straight into your scene as a
starting point.

Cheers, PoD.

[Dana Dauphinee] Halos.... ? [10136 days 4 hours and 49 minutes ago]

Tue, 7 Jul 1998 06:24:06 GMT

I'm not posting a file with this, I'd just like some help, since
this is a Tutorials group.  I've posted my first semi-gratifying image
on the binaries.images group, so if you want to take a look at it, it's
there....
    Anywho, my question is....  could someone explain to me a little but
more about halos?  I have MoRay, and I've looked through the POV docs,
and I'm never getting the results I'm after.  In my image, I have two
cones, a spotlight focused on each.  I'd like to get a dust-like effect,
or something of that sort, coming from the spotlight, so that it looks
sort of like a streetlight shining on the cones... or like sunshine
coming in from a dusty window... that sort of effect.  Is there anyway I
can do this? I'm trying what I 'know' how to do, but, obviously, that
isn't much.  What's the easiest way to do this?

Many thanks for your help,

~Dana

(Oh, what the heck, Ill post my file here, too!)

[Dave] Re: #if...#else...#HELP!!! [10136 days 22 hours and 52 minutes ago]

Mon, 6 Jul 1998 12:21:07 GMT

I found a way to get around the problem, by translating the camera along a
spline instead, but I still want to know what's wrong with my #if...#else
statement if anything or want to know why I didn't get the result I
expected.

Thanks.
Dave

[Dave] #if...#else...#HELP!!! [10142 days 12 hours and 10 minutes ago]

Tue, 30 Jun 1998 23:03:05 GMT

Hi.  I'm sending a .pov file that I'm having some trouble with and hoping
that there is someone out there who can tell me what I'm doing wrong.
Basically, I'm trying to create a short animation that would eventually be
converted to an animated .gif for a friend's web site.  The basic idea is
that you have the words "View my guestbook"  (If I get this to work, I'll
make another saying "Sign my guestbook").  The words are as close to being
centered around the origin as I can get them, and they were created in
Moray.  I was planning to animate the camera instead of the actual text.
The animation is divided up into 4 equally timed parts. (so I used a
starting clock value of 0 and a final value of 4 to make my calculations
easier -- or so I thought)  The camera should start out looking between two
letters in the center so you originally see only blackness.  Then it should
back up behind the text until the text pretty much fills up the view,
backwards. (part 1) Then the camera rotates around to the front of the text.
(part2)  Then it should pause there. (part 3) And finally move toward the
text until you are back to the original blackness.(part 4)  How ever I must
be doing something wrong because I seem to be getting hung up on the second
part.  It starts ok, backs up, but then just keeps rotating.  I've never
used the "#if...#else" statement before and thought maybe that was the
problem.  I'm also including a file called "view.ini" that I used to render
the file.  Please help...

Thanks.
Dave

[Tristan Wibberley] Re: Gamma and Colour Values [20492 days 20 hours and 22 minutes ago]

Fri, 27 Feb 1970 14:51:21 GMT

Gamma is used to describe the peculiar properties of each individual
display device. 

On some monitors, a luminance value of 0 is displayed with lightness 0, and
a luminance value of 1 is displayed with lightness 1, but a luminance of
0.5 is displayed with lightness  ~0.2 because the actual appearance is not
linear (dark colours appear too dark). On other monitors, it is displayed
differently, the number that describes the deviation from linearity is
Gamma.

If you produce an image designed for viewing on a monitor with Gamma of
2.4, it will look wrong on a monitor with Gamma of 2.0. You can tell Povray
what the Gamma of the viewing method is (I can't remember the syntax
offhand), if the image is viewed on another monitor, the image must have
it's Gamma corrected for the new monitor. To do Gamma correction, you (or
whatever will do the correction) must know the original gamma of the image,
and the gamma of the display device. By storing the original Gamma with the
image you give half of that information, but I don't think JPEG provides
for that... PNG does, but that is no use unless the viewer corrects the
Gamma for their system.

For more information, search the web for "gamma".

Dinesh Shah <din### [at] indiamailcom> wrote in article
<34f1c525.0@news.povray.org>...
> 
> Hi
> I am attaching 4 jpgs which are created using various gamma values.
> 
> apart from that I have used various colour values from 0.5 to 4.0
> 
> Now my question is  greater value of colour increases the brightness of
that
> colour? And how gamma will help? Is gamma value is stored in the file?
> 
> --
> Dinesh Shah :-)
> din### [at] indiamailcom
> 
> 
> 
> 
> 
> 
> 
> 
>

[Dinesh Shah] Gamma and Colour Values [10269 days 16 hours and 27 minutes ago]

Mon, 23 Feb 1998 18:45:39 GMT

Hi
I am attaching 4 jpgs which are created using various gamma values.

apart from that I have used various colour values from 0.5 to 4.0

Now my question is  greater value of colour increases the brightness of that
colour? And how gamma will help? Is gamma value is stored in the file?

--
Dinesh Shah :-)
din### [at] indiamailcom

[Dinesh Shah] Gamma and Colour Values [10273 days 22 hours and 4 minutes ago]

Thu, 19 Feb 1998 13:08:41 GMT

Hi
I am attaching 4 jpgs which are created using various gamma values.

apart from that I have used various colour values from 0.5 to 4.0

Now my question is  greater value of colour increases the brightness of that
colour? And how gamma will help? Is gamma value is stored in the file?

--
Dinesh Shah :-)
din### [at] indiamailcom

[Ken] Re: Human Models [9735 days 13 hours and 3 minutes ago]

Wed, 11 Aug 1999 22:09:26 GMT

Bill Hedge wrote:
> 
> Thanks, Ken! I appreciate you pointing out the Blobman to me. However, I
> think I should have been a bit more clear. What I'm actually looking for is
> something I can use in Moray. Perhaps I posted to the wrong groups. Any
> other suggestions?

Try posting a similar question in the moray.win newsgroup on this server.

-- 
Ken Tyler

See my 700+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

[Bill Hedge] Re: Human Models [9735 days 14 hours and 58 minutes ago]

Wed, 11 Aug 1999 20:14:44 GMT

Thanks, Ken! I appreciate you pointing out the Blobman to me. However, I
think I should have been a bit more clear. What I'm actually looking for is
something I can use in Moray. Perhaps I posted to the wrong groups. Any
other suggestions?
Ken <tyl### [at] pacbellnet> wrote in message
news:37B155A1.C375CE4E@pacbell.net...
>
>
> Bill Hedge wrote:
> >
> > Hey,
> >
> > I was wondering if anyone would be able to help me out here. I'm looking
for
> > a human model for use in POV. Specifically, one that is actually made of
> > objects and not wireframes created by a conversion utility from, say,
> > 3DSMAX. Any help would be greatly appreciated. TIA!
>
> Follow this link to the resources section and download the blobman include
> file. I have seen some pretty impressive resulta from this file posted
> recently and you can see a couple of examples in Peter's image gallery
> at the same site. Specificaly the Silver Surfer and his Storm Troopers.
>
> http://members.xoom.com/HoustonGraph/
>
> --
> Ken Tyler
>
> See my 700+ Povray and 3D Rendering and Raytracing Links at:
> http://home.pacbell.net/tylereng/index.html

[Ken] Re: Human Models [9736 days and 21 minutes ago]

Wed, 11 Aug 1999 10:51:26 GMT

Bill Hedge wrote:
> 
> Hey,
> 
> I was wondering if anyone would be able to help me out here. I'm looking for
> a human model for use in POV. Specifically, one that is actually made of
> objects and not wireframes created by a conversion utility from, say,
> 3DSMAX. Any help would be greatly appreciated. TIA!

Follow this link to the resources section and download the blobman include
file. I have seen some pretty impressive resulta from this file posted
recently and you can see a couple of examples in Peter's image gallery
at the same site. Specificaly the Silver Surfer and his Storm Troopers.

http://members.xoom.com/HoustonGraph/

-- 
Ken Tyler

See my 700+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

[Bill Hedge] Human Models [9736 days 10 hours and 29 minutes ago]

Wed, 11 Aug 1999 00:44:07 GMT

Hey,

I was wondering if anyone would be able to help me out here. I'm looking for
a human model for use in POV. Specifically, one that is actually made of
objects and not wireframes created by a conversion utility from, say,
3DSMAX. Any help would be greatly appreciated. TIA!

[Mark Kilbourne] Mesh texturing [9917 days 12 hours and 6 minutes ago]

Wed, 10 Feb 1999 23:06:44 GMT

How do you import a dxf model into POVRay so that you texture it easily?
Primarily I'm inteseted in importing models created in Plant Studio.  I can
import using a conversion program,  however it is organised in such a way
that I can't figure out any easy way to texture.  In other words I can't
distiguish flowers from stems from berries.  Any help would be much
appreciated.

[Renzo Del Fabbro] Re: Output File Format [9018 days 12 hours and 42 minutes ago]

Sat, 28 Jul 2001 22:30:50 GMT

John Albarelli ha scritto:

> I know this is a newbie question, but I can't find it in the documentation,
> and my mind is not what it once was.  How do I get pov to change the format
> of the output file in Pov-ray v3.1 for Windows? Thanks.
>

When U render by POV U can save Your rendered image in different formats
TGA, BMP or PNG in a Directory U can chose.
Try to edit the Povray.ini file from:

"Tools"--> "Edit master POVRAY.INI"

U can add a raw like:

Output_File_Type=T
if U want a TGA ... or =S insted of T if U want a BMP or =N if You need a
PNG output image

and also the raw :
Output_File_Name=C:\images\

tells POVRay where to save the rendered image

at the end of the ini file there are also the output directory and the
library paths where pov try to search for the files "he" needs when it start
to render.
BTW: the ini file is read only when pov start!!!!

-----------------
Renzo Del Fabbro
e-mail: ren### [at] liberoit
location: http://members.tripod.com/azzazzel/
----------------------------------------------------eof

[Alexander Lazic] Re: Output File Format [9041 days 15 hours and 10 minutes ago]

Thu, 5 Jul 2001 20:02:49 GMT

Hi,

"John Albarelli" <joh### [at] smithandmahoneycom> writes:

> I know this is a newbie question, but I can't find it in the
> documentation, and my mind is not what it once was.  How do I get pov
> to change the format of the output file in Pov-ray v3.1 for Windows?

ALT-C or Render => Edit Settings/Render and there add in the

"Section": Command line Option the prefered Format

From the Help Section "File Output Options":

+FC     Compressed Targa-24 format (RLE, run length encoded)
+FN     New PNG (portable network graphics) format
+FP     Unix PPM format
+FS     System-specific such as Mac Pict or Windows BMP
+FT     Uncompressed Targa-24 format

Hth

al ;-)

[John Albarelli] Output File Format [9054 days 22 hours and 13 minutes ago]

Fri, 22 Jun 2001 12:59:50 GMT

I know this is a newbie question, but I can't find it in the documentation,
and my mind is not what it once was.  How do I get pov to change the format
of the output file in Pov-ray v3.1 for Windows? Thanks.

John

[Ron Parker] Re: INFO: Inverse [9841 days 17 hours and 40 minutes ago]

Tue, 27 Apr 1999 17:33:03 GMT

On Tue, 27 Apr 1999 08:12:44 -0700, Josh English wrote:
>Inverse only applies to unions, differences, etc...

Not true.  It applies to all objects with insides.  It just doesn't
usually matter except in CSG (and in bounded_by and clipped_by) and
perhaps with media.

[Josh English] Re: INFO: Inverse [9841 days 18 hours and 59 minutes ago]

Tue, 27 Apr 1999 16:13:36 GMT

Inverse only applies to unions, differences, etc...

You want to apply a warp statement to the object.
from the docs...

However, by specifying our turbulence inside warp statement you tell
POV-Ray that the order in which turbulence, transformations and other
warps are applied is significant. Here's an example of a turbulence warp.

  warp { turbulence <0,1,1> octaves 3 lambda 1.5 omega 0.3 }

The significance is that this

 pigment {
   wood
   translate <1,2,3> rotate x*45 scale 2
   warp { turbulence <0,1,1> octaves 3 lambda 1.5 omega 0.3 }
 }

produces different results than this...

 pigment {
   wood
   warp { turbulence <0,1,1> octaves 3 lambda 1.5 omega 0.3 }
   translate <1,2,3> rotate x*45 scale 2
 }

You may specify turbulence without using a warp statement. However you
cannot control the order in which they are evaluated unless you put them
in a warp

Josh English
eng### [at] spiritonecom
Hassoun wrote:

> Hi
> can i use "inverse" to reverse the order (or the sequence) in which
> objects are modified (translated, rotated, scaled)? any info of how to
> do this operation?
>
> thanks in advance
> Hassoun

[St ] Re: Newbie looking for tutorials [8203 days 17 hours and 43 minutes ago]

Tue, 21 Oct 2003 17:29:24 GMT

"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3f94edaa$1@news.povray.org...
> "JC (Exether)" <no### [at] spamfr> wrote in message
news:3f94d75c$1@news.povray.org...
>
> > Hmmm, HER  imho, it's rare enough to mention.    :-)
>
> What's a HER? Is it some kind of terrorist?

     Yes.

  ~Steve~    ;)


>
>

[Tom Galvin] Re: Newbie looking for tutorials [8203 days 18 hours and 54 minutes ago]

Tue, 21 Oct 2003 16:18:24 GMT

"JC (Exether)" <no### [at] spamfr> wrote in news:3f94d75c$1@news.povray.org:

> Hmmm, HER  imho, it's rare enough to mention.    :-)
> 

My apologies.  


-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

[JC (Exether)] Re: Newbie looking for tutorials [8203 days 20 hours and 2 minutes ago]

Tue, 21 Oct 2003 15:10:34 GMT

Tom Melly wrote:
> "JC (Exether)" <no### [at] spamfr> wrote in message news:3f94d75c$1@news.povray.org...
> 
> 
>>Hmmm, HER  imho, it's rare enough to mention.    :-)
> 
> 
> What's a HER? Is it some kind of terrorist?
> 
Sometimes you would say yes.   :-))

[Jim Charter] Re: Newbie looking for tutorials [8203 days 20 hours and 56 minutes ago]

Tue, 21 Oct 2003 14:17:04 GMT

Tom Melly wrote:
> "JC (Exether)" <no### [at] spamfr> wrote in message news:3f94d75c$1@news.povray.org...
> 
> 
>>Hmmm, HER  imho, it's rare enough to mention.    :-)
> 
> 
> What's a HER? Is it some kind of terrorist?
> 
> 
Apparently the French group's been hiding one of them.  I'm jealous!

[Tom Melly] Re: Newbie looking for tutorials [8204 days 2 hours and 47 minutes ago]

Tue, 21 Oct 2003 08:26:18 GMT

"JC (Exether)" <no### [at] spamfr> wrote in message news:3f94d75c$1@news.povray.org...

> Hmmm, HER  imho, it's rare enough to mention.    :-)

What's a HER? Is it some kind of terrorist?

[JC (Exether)] Re: Newbie looking for tutorials [8204 days 4 hours and 22 minutes ago]

Tue, 21 Oct 2003 06:51:08 GMT

Tom Galvin wrote:
> "Tim Nikias v2.0" <tim.nikias (@) gmx.de> wrote in
> news:3f93f3e7$1@news.povray.org: 
> 
> 
>>Begin with the Documentation. It will lead you to the first image
>>everyone has produced: reflective sphere on checkered plane (a
>>variation of that theme is an obligatory first post to PBI).
>>
>>Then, ...
>>
> 
> 
> Whoa!  The docs and samples scenes should keep him busy for a while ;)
> 
> 
> 
Hmmm, HER  imho, it's rare enough to mention.    :-)

[Tom Galvin] Re: Newbie looking for tutorials [8204 days 13 hours and 43 minutes ago]

Mon, 20 Oct 2003 21:29:46 GMT

"Tim Nikias v2.0" <tim.nikias (@) gmx.de> wrote in
news:3f93f3e7$1@news.povray.org: 

> Begin with the Documentation. It will lead you to the first image
> everyone has produced: reflective sphere on checkered plane (a
> variation of that theme is an obligatory first post to PBI).
> 
> Then, ...
> 

Whoa!  The docs and samples scenes should keep him busy for a while ;)



-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

[Tim Nikias v2 0] Re: Newbie looking for tutorials [8204 days 20 hours and 32 minutes ago]

Mon, 20 Oct 2003 14:40:39 GMT

Begin with the Documentation. It will lead you to the first image everyone
has produced: reflective sphere on checkered plane (a variation of that
theme is an obligatory first post to PBI).

Then, download some simple scenes (you can judge that by the amount of
objects mainly) and scan through them, try to make sense of them, at least
in parts, and create your own ones based off of what you find.

And THEN, make your very own images, starting with an empty scene-file.

It is, for later days and reviews, good to keep track in your scene file
when the file was initially made, when the last update was done, with which
POV-Ray (3.5 at the moment), Author, etc.

You can find some info on my website, there are descriptions of some files
in my "Past Projects" section, and some scene-files in my "Downloads" (IRTC
Images) and "Gallery v2.0" (sources for those). You'll also find some
Include-Files you might find useful (especially the I/O-Macros to read/write
data arrays).

Regards,
Tim

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: tim.nikias (@) gmx.de


> Hi to all the gurus !
>
> I am a newbie. I repeat, I am a really, really, brand new newbie. Just
getting up to learn rendering, ray tracing, modelling, etc.
>
> I am looking for online tutorials for modelling, POVRAY, rendering, ray
tracing, .... in other words, I am looking for tutorials that cover
everything including
> the kitchen sink. :)
>
> Can anyone here help out, please ?
>
> No, I don't have a lot of money to spare, so books ($$$$) is out of the
question. All I can afford is to download all the tutorials into my computer
so I can learn
> from them, one at a time.
>
> If you know a good tutorial or two, please tell me. I'd be forever
grateful, and perhaps one day when I am rich enough, I'll treat you a round
of beer (or the
> beverage of your choice) for your help.
>
> Thanks all of you in advance !
>
> Marie
> pen### [at] myrealboxcom


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.528 / Virus Database: 324 - Release Date: 16.10.2003

[penang] Newbie looking for tutorials [8205 days 2 hours and 23 minutes ago]

Mon, 20 Oct 2003 08:49:24 GMT

Hi to all the gurus !

I am a newbie. I repeat, I am a really, really, brand new newbie. Just getting up to
learn rendering, ray tracing, modelling, etc.

I am looking for online tutorials for modelling, POVRAY, rendering, ray tracing, ....
in other words, I am looking for tutorials that cover everything including
the kitchen sink. :)

Can anyone here help out, please ?

No, I don't have a lot of money to spare, so books ($$$$) is out of the question. All
I can afford is to download all the tutorials into my computer so I can learn
from them, one at a time.

If you know a good tutorial or two, please tell me. I'd be forever grateful, and
perhaps one day when I am rich enough, I'll treat you a round of beer (or the
beverage of your choice) for your help.

Thanks all of you in advance !

Marie
pen### [at] myrealboxcom

[Dave] Re: Conversion Halos to PovRay 3.1? [10001 days 12 hours and 56 minutes ago]

Wed, 18 Nov 1998 22:16:38 GMT

But how about converting non-solid looking halos... like fire or something..
to 3.1?  It took me a long time to figure out "halo" and to get them to look
somewhat decent.  Just when I thought I had it down pretty well, they go
away.  :(
Thanks..


Ciao!
DH

[Joost Smits] Re: Conversion Halos to PovRay 3.1? [10005 days 18 hours and 35 minutes ago]

Sat, 14 Nov 1998 16:37:36 GMT

Joost Smits wrote:

> Dear all,
>
> I got lost a bit. I always used halos in PovRay 3.0, for example to make
>
> nice stars in the sky. In PovRay 3.1 this all changed. I do not
> understand what I need to do to make the new interior/media combination
> to work like the old halos... Is there a
> conversion rule?
>
> --
> Joost Smits
> jsm### [at] prizenl

My problem in a PovRay 3.1 file:

#include "colors.inc"
#include "textures.inc"
#include "shapes.inc"

#declare Scaling = 1;   // Problem: if you vary the scaling the moon changes
size, but also appearance!

// CAMERA POSITION
camera {
  right      < 1.33, 0, 0 >
  up         < 0, 1, 0 >
  direction  < 0, 0, 1 >
  location   < 0, 0, -8*Scaling>
  look_at <  0, 0, 0 >
 }

background { color rgb<0.03, 0.17, 0.41>  }

light_source{<0,1000,1000>
  White
  shadowless
  }

#declare moon=
sphere { 0, 1
 texture{
   pigment{rgbt 1}
 }
   interior{
     media{
       emission 1
       scattering{1,0.1}
       intervals 10
       samples 1, 15
       density{
         spherical
         color_map{
          [0    rgb 0]
          [0.3  rgb <0.5,0.5,0.5>]
          [1    rgb 1]
         }
       }
     }
   }
   hollow
}

object {moon
  scale Scaling
 }

If you change the Scaling, the size of the moon obviously changes, and also
your distance to the moon. Problem now is that the appearance is different.
I want this moon with an aura, a "glow" effect. Yes, I know of the Lens
Flares of Nathan Kopp, but these files generate a magnitude of error
messages in my PovRay 3.1. And, I am sure it is a simple trick to get the
halo effect of PovRay 3.0 in PovRay 3.1 !

I will include my Xmas card from last year. The moon (and harder to see: the
stars) has the effect I am looking for. I only had to define a "star" and
could scale them to for example the moon.

All the best,

Joost Smits
jsm### [at] prizenl

(check also out http://www.prize.nl/jsmits/ and
http://www.prize.nl/jsmits/xmas97/)

[Jeff Lee] Re: Insignia in POV-ray [10206 days 17 hours and 20 minutes ago]

Mon, 27 Apr 1998 17:52:46 GMT

Chris Jeppesen <chr### [at] digiquillcom> wrote:
>
> I'm working on a Saturn 5 model, and I'm trying to paint the insignia on
> it. USA, Flags, etc. 
>
> I was wondring if there is a way to model these markings in CSG, instead
> of using an image_map. 
>
> What I was thinking is a "texture intersection." Imagine a cylinder and
> a box overlapping in space. Only show the cylinder, but color it white
> on points outside the box, and red inside.

That is possible to do, but it takes a bit of work.

For example, say I have a 10-unit-tall white cylinder, of radius 2, and
I want to put a 1-by-1 red square about 1/4 of the way from the top end
(but only on one "side" of the cylinder):

  // CylSquar.pov
  //
  #declare C_Cyl_Square = colour rgb <1,0,0> // the red square
  #declare C_Cyl_Rest   = colour rgb <1,1,1> // the white surrounding it

  #declare P_Cyl_Y = pigment { gradient y
    colour_map {
      [0.70 C_Cyl_Rest]   // 0.00 through 0.70 (0.75 minus half the
      [0.70 C_Cyl_Square] //  square's height) is white
      [0.80 C_Cyl_Square] // 0.70 through 0.80 is red
      [0.80 C_Cyl_Rest]   // 0.80 through 1.00 is white again.
    }
  }

  #declare P_Cyl_X = pigment { gradient x
    pigment_map {
      [0.25 P_Cyl_Y]     // Taking advantage of the symmetry of the
      [0.25 C_Cyl_Rest]  //  X gradient here.
    }
  }

  #declare P_Cylinder = pigment { gradient z
    pigment_map {
      [0.50 P_Cyl_X]     // Now we ensure that the square appears on
      [0.50 C_Cyl_Rest]  //  only one side of the cylinder, rather than
    }                    //  going all the way through.
    translate <0,-0.5,-0.5>  // Centre the pigment on where the cylinder
    scale <2,10,4>           //  will be, and scale it appropriately.
  }

  cylinder { <0,-5,0>, <0,5,0>, 2 pigment { P_Cylinder }}
  camera { location <0,0,-20> look_at <0,0,0> }
  light_source { <-100,100,-200> colour rgb <1,1,1> }

That's a lot of work for a simple square, but you could easily use that
sort of thing to produce the black-and-white markings on the Saturn V
(the radial pattern will be quite helpful for that, in places).

Things like the "USA" are certainly possible to do, though it will be an
extremely laborious process.  The stars on the flag will be a headache,
too, but the stripes and field are fairly easy:

  // FlagTest.pov
  //
  #declare C_Flag_Red   = colour rgb <1,0,0>
  #declare C_Flag_White = colour rgb <1,1,1>
  #declare C_Flag_Blue  = colour rgb <0,0,0.75>

  #declare P_Flag_Stripes = pigment { gradient y
    colour_map {
      [ 0/13 C_Flag_Red]   [ 1/13 C_Flag_Red]
      [ 1/13 C_Flag_White] [ 2/13 C_Flag_White]
      [ 2/13 C_Flag_Red]   [ 3/13 C_Flag_Red]
      [ 3/13 C_Flag_White] [ 4/13 C_Flag_White]
      [ 4/13 C_Flag_Red]   [ 5/13 C_Flag_Red]
      [ 5/13 C_Flag_White] [ 6/13 C_Flag_White]
      [ 6/13 C_Flag_Red]   [ 7/13 C_Flag_Red]
      [ 7/13 C_Flag_White] [ 8/13 C_Flag_White]
      [ 8/13 C_Flag_Red]   [ 9/13 C_Flag_Red]
      [ 9/13 C_Flag_White] [10/13 C_Flag_White]
      [10/13 C_Flag_Red]   [11/13 C_Flag_Red]
      [11/13 C_Flag_White] [12/13 C_Flag_White]
      [12/13 C_Flag_Red]   [13/13 C_Flag_Red]
    }
  }

  #declare P_Flag_FieldX = pigment { gradient x
    pigment_map {
      [0.45 C_Flag_Blue]
      [0.45 P_Flag_Stripes]
    }
  }

  #declare P_Flag_FieldY = pigment { gradient y
    pigment_map {
      [6/13 P_Flag_Stripes]
      [6/13 P_Flag_FieldX]
    }
  }

  box {0,1 pigment { P_Flag_FieldY } translate -0.5 scale <1.75,1,0.01>}
  camera { location <0,0,-2> look_at <0,0,0> }
  light_source { <-100,100,-200> colour rgb <1,1,1> }

Hope this helps!


-- 
Jeff Lee         shi### [at] gatenet         http://www.gate.net/~shipbrk/

[Chris Jeppesen] Insignia in POV-ray [10209 days 18 hours and 10 minutes ago]

Fri, 24 Apr 1998 17:03:05 GMT

I'm working on a Saturn 5 model, and I'm trying to paint the insignia on
it. USA, Flags, etc. 

I was wondring if there is a way to model these markings in CSG, instead
of using an image_map. 

What I was thinking is a "texture intersection." Imagine a cylinder and
a box overlapping in space. Only show the cylinder, but color it white
on points outside the box, and red inside.

Can this be done? Is there another way?

Thanks in advance.
------------------------------
Chris Jeppesen
Go see my Orbital Mechanics Explained Page!
http://www.geocities.com/CapeCanaveral/Launchpad/3392/
EMail I will read: Chr### [at] digiquillcom
------------------------------

[Ken] Re: planet Earth using a texture map? [9776 days 13 hours and 11 minutes ago]

Thu, 1 Jul 1999 22:01:30 GMT

Robert Acklin wrote:

> 
> Did you use povray to create the mount'ns in the 1st pic?
> (oldies.html)
> If not, what did you use? If so how? (or just point me to
> the right doc)
> 
> --
> Rob
> -----

  What you are seeing is a Pov generated Height Field. There are many
ways to create them but the easiest is by using a heght field modeling
program like Leveller. 

See my links in the group below for several programs that produce images
usable for height fields in Povray.

povray.announce.frequently-asked-questions

-- 
Ken Tyler

mailto://tylereng@pacbell.net

[Robert Acklin] Re: planet Earth using a texture map? [9776 days 13 hours and 21 minutes ago]

Thu, 1 Jul 1999 21:52:01 GMT

<cco### [at] amerisurecom> wrote in message
news:36e3fbf0$1$ppbaare$mr2ice@news.povray.org...
> In <35dcd18b.0@news.povray.org>, on 08/20/98
>    at 09:39 PM, "Ashley McGlone" <ash### [at] premierwebnet> said:
>
> >Newbie question:
>
> >How can I create planet Earth using a texture map?
> >TIA
>
> >Mr. Ashley McGlone
> >Ash### [at] PremierWebNet
> >http://www.premierweb.net/users/ashley/welcome.html
>
>
> The easiest way is just to create a sphere and use a spherical surface
> map. I did this with an image I got from the NASA web site.  Check out my
> page http://members.xoom.com/scarfield/3d/povray/oldies.html
>

Did you use povray to create the mount'ns in the 1st pic?
(oldies.html)
If not, what did you use? If so how? (or just point me to
the right doc)

--
Rob
-----
/*----------------oOOo--(- *)--Oooo------------------*/
   while (( WinNT > Win9x ) && ( Linux != FreeBSD ))
       if (( Asm < Pascal ) && ( C++ > C ))
           email("rob### [at] volcom");
       else
           email("rac### [at] moccasunutcedu");
/*---------------------------------------------------*/
            http://earth.vol.com/~robace/

[Blake Ranolph] Re: A better scene [9818 days 2 hours and 7 minutes ago]

Fri, 21 May 1999 09:06:21 GMT

Dinesh Shah wrote:
> 
> Hi,
> case 2:
>     plane
>     {    y, -5
>          pigment { checker White, Black scale 5 rotate 45*y }
>      }
> Both code will produce same result. In that case which is better?
> Or which renders faster, if faster at all?

Case 2 will parse faster.  But not to a significant ammount that you
will notice anything.
(BTW, case 1 says scale <5,1,5> and scale 5 is the same as <5,5,5>)

oo o  o   (   (  ( (=-- inf### [at] veriocom --=) )  )   )   o  o oo

[Jan Ludewig] Re: A better scene [9838 days and 45 minutes ago]

Sat, 1 May 1999 10:27:38 GMT

Dinesh Shah schrieb:

> case 1:
>     plane
>     {    y, -5
>          pigment { checker White, Black }
>          scale <5,1,5>
>          rotate 45*y
>     }

You scale the object and rotate it WITH the pigment on it

> case 2:
>     plane
>     {    y, -5
>          pigment { checker White, Black scale 5 rotate 45*y }
>      }

You scale the pigment and rotate it WIHTOUT the plane itself, so this should be
faster but:
It only works as a plane is infinite, try this with a box and you'll get
different results.

[cconner] Re: planet Earth using a texture map? [9891 days 18 hours and 39 minutes ago]

Mon, 8 Mar 1999 16:33:53 GMT

In <35dcd18b.0@news.povray.org>, on 08/20/98 
   at 09:39 PM, "Ashley McGlone" <ash### [at] premierwebnet> said:

>Newbie question:

>How can I create planet Earth using a texture map?
>TIA

>Mr. Ashley McGlone
>Ash### [at] PremierWebNet
>http://www.premierweb.net/users/ashley/welcome.html


The easiest way is just to create a sphere and use a spherical surface
map. I did this with an image I got from the NASA web site.  Check out my
page http://members.xoom.com/scarfield/3d/povray/oldies.html


_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_
+                                                       +
+  Chris C. Conner                                      +
+  con### [at] usanet     or     cco### [at] amerisurecom     +
+                                                       +
~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~

[Remco de Korte] Re: Candle light [10025 days 13 hours and 38 minutes ago]

Sun, 25 Oct 1998 21:35:18 GMT

Patrick Hagerty wrote:
> 
> Ken,
> 
>     I'm also interested in a semi-realistic (or better) flame and I looked
> for the example scene you mentioned, but there doesn't seem to be any such
> object.  I have also taken the time to render all of the examples shipped
> with POV and used a graphical image browser and don't see any that have
> anything that looks like a flame in them.
> 
> If I've overlooked something, I'd appreciate being set straight.
> 
> Thanks,
> Patrick Hagerty
> pat### [at] hagwarecom
> 
> Ken wrote:
> 
> > There is one example scene provided with POV-Ray I believe
> > the title is matches.pov. It is an excellent example of producing
> > flames. In POV-Ray 3.01 it was in the showoff directory.
> >
> > Ken
> >
> > Ashley McGlone wrote:
> >
> > > Does anyone know how to create a realistic candle flame and use it as a
> > > light source?  Please reply to me privately.  TIA
> > >
> > > Mr. Ashley McGlone
> > > Ash### [at] PremierWebNet

There's no candle in the demo-files as far as I could see either. But I saw one
posted just a short while ago. Either that or it was on a webpage....
Hm....
Anyway, I've been working on it too and I've managed to get a semi-realistic
result. It is not as good as it could be, but it did the job for me (the image
might be somewhere in the binaries-group) and it might be a start.
Perhaps someone will post a good, thorough, usable include, otherwise I'd be
happy to share my crap :-)

Good luck,

Remco

[Ken] Re: Candle light [10025 days 17 hours and 27 minutes ago]

Sun, 25 Oct 1998 17:45:52 GMT

Patrick Hagerty wrote:

> Ken,
>
>     I'm also interested in a semi-realistic (or better) flame and I looked
> for the example scene you mentioned, but there doesn't seem to be any such
> object.  I have also taken the time to render all of the examples shipped
> with POV and used a graphical image browser and don't see any that have
> anything that looks like a flame in them.
>
> If I've overlooked something, I'd appreciate being set straight.
>
> Thanks,
> Patrick Hagerty
> pat### [at] hagwarecom

The file I was referencing was included with the 3.0x version of Pov-Ray.
Halos have been discontinues in the 3.1 version and as a consequence
the example was removed. There is an example of producing flames by
Dan Connelly posted to the povray.binaries.images group. It dates back
to some time around 9/25/98.  This example uses the new media feature
in v3.1 and is worth looking at. While not useful as a candle flame perhaps
it can get you going in the right direction.

Ken Tyler

[Patrick Hagerty] Re: Candle light [10025 days 18 hours and 29 minutes ago]

Sun, 25 Oct 1998 16:43:57 GMT

Ken,

    I'm also interested in a semi-realistic (or better) flame and I looked
for the example scene you mentioned, but there doesn't seem to be any such
object.  I have also taken the time to render all of the examples shipped
with POV and used a graphical image browser and don't see any that have
anything that looks like a flame in them.

If I've overlooked something, I'd appreciate being set straight.

Thanks,
Patrick Hagerty
pat### [at] hagwarecom


Ken wrote:

> There is one example scene provided with POV-Ray I believe
> the title is matches.pov. It is an excellent example of producing
> flames. In POV-Ray 3.01 it was in the showoff directory.
>
> Ken
>
> Ashley McGlone wrote:
>
> > Does anyone know how to create a realistic candle flame and use it as a
> > light source?  Please reply to me privately.  TIA
> >
> > Mr. Ashley McGlone
> > Ash### [at] PremierWebNet

[Ken] Re: Candle light [10065 days 7 hours and 20 minutes ago]

Wed, 16 Sep 1998 03:52:59 GMT

There is one example scene provided with POV-Ray I believe
the title is matches.pov. It is an excellent example of producing
flames. In POV-Ray 3.01 it was in the showoff directory.

Ken

Ashley McGlone wrote:

> Does anyone know how to create a realistic candle flame and use it as a
> light source?  Please reply to me privately.  TIA
>
> Mr. Ashley McGlone
> Ash### [at] PremierWebNet

[Ashley McGlone] Candle light [10065 days 7 hours and 54 minutes ago]

Wed, 16 Sep 1998 03:19:22 GMT

Does anyone know how to create a realistic candle flame and use it as a
light source?  Please reply to me privately.  TIA

Mr. Ashley McGlone
Ash### [at] PremierWebNet

[Ashley McGlone] planet Earth using a texture map? [10091 days 8 hours and 26 minutes ago]

Fri, 21 Aug 1998 02:46:51 GMT

Newbie question:

How can I create planet Earth using a texture map?
TIA

Mr. Ashley McGlone
Ash### [at] PremierWebNet
http://www.premierweb.net/users/ashley/welcome.html

[Dinesh Shah] Re: A better scene [10269 days 2 hours and 48 minutes ago]

Tue, 24 Feb 1998 08:24:34 GMT

Hi Birch

Thanks for the answer

I will look at the difference in more complex scenes

thanks

Dinesh Shah :-)
din### [at] indiamailcom

Lance Birch <:-)Lan### [at] tpgicomau> wrote in message
<34f1e5a0.0@news.povray.org>...
>Generally speaking there shouldn't be too much of a speed difference in
>rendering although technically I think:
>
>plane
>    {    y, -5
>         pigment { checker White, Black scale 5 rotate 45*y }
>     }
>
>is faster because it's only rotating the texture and not the object.
>
>--
>Lance Birch
>Remove the smiley to e-mail.
>http://www1.tpgi.com.au/users/ambient/lance
>
>

[Lance Birch] Re: A better scene [10269 days 14 hours and 5 minutes ago]

Mon, 23 Feb 1998 21:07:48 GMT

Generally speaking there shouldn't be too much of a speed difference in
rendering although technically I think:

plane
    {    y, -5
         pigment { checker White, Black scale 5 rotate 45*y }
     }

is faster because it's only rotating the texture and not the object.

--
Lance Birch
Remove the smiley to e-mail.
http://www1.tpgi.com.au/users/ambient/lance

[Dinesh Shah] A better scene [10273 days 21 hours and 25 minutes ago]

Thu, 19 Feb 1998 13:48:17 GMT

Hi,

It is possible create same object with slightly deferent code. as u can see
from bellow

case 1:
    plane
    {    y, -5
         pigment { checker White, Black }
         scale <5,1,5>
         rotate 45*y
    }

case 2:
    plane
    {    y, -5
         pigment { checker White, Black scale 5 rotate 45*y }
     }

Both code will produce same result. In that case which is better?
Or which renders faster, if faster at all?
--
Dinesh Shah :-)
din### [at] indiamailcom