povray.text.tutorials message digest

[Maetes] Re: Tutorial - Planets [121 days 8 hours and 18 minutes ago]

Thu, 4 Dec 2025 15:25:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> "Maetes" <nomail@nomail> wrote:
> > I have written a small (?) tutorial on how to create a planet with
> > high-resolution maps, image-maps, bump-maps and spherical heightfields.

> > Greeting Martin
>
> Thanks! I like the idea of two per-level steps!

I had no other choice, it was just too long :)
And if I add a mini atmosphere-tutorial, it will be even longer (page 3).
What about a ring-system? (page 4)

I wish I could do something like this around the clock, but you know,...
real-life ...

m

[Maetes] Re: Tutorial - Planets [121 days 8 hours and 23 minutes ago]

Thu, 4 Dec 2025 15:20:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> Fine work! I have used everything you had in part 1! It was easy to follow, well
> written, and plenty of graphics. It had all that was needed and not much you
> didn't.

Thanks


> Part2 is not as well organize. From the line:
>  You can continue experimenting with the variables or parameters Radius,
> HeightDiff, max_gradient and accuracy.
>  Where it didn't mention that this was for an isosurface, to the 'PRO's & CON's
> that leave image_maps and isosurfaces off the list.
> Part2 doesn't feel like a tutorial, but more like 'look at this stuff'.

You're right, hardly what I had in mind, but at some point I wanted to finish
it.
I'll keep this in mind when I revise or expand the tutorial


>  I did like the animation and I always like Mars. A few years back I drove
> deeply into Mar with POV with image and bump maps. Exploring Mars by adding
> water levels and cutting the tops off the high ground. But I'm getting off
> topic.

Yes, a bit off-topic, but interesting.
I tried this briefly with reference to planet Earth, it's not so easy with
spherical heightfields.


> I appreciated the work you did putting this altogether. I remember the hours I
> spent working with Mars and other planets.

Ouh yes, I know, many many ... many hours :)

Ma

[Mr] Re: Tutorial - Planets [135 days 13 hours and 3 minutes ago]

Thu, 20 Nov 2025 10:40:00 GMT

"Maetes" <nomail@nomail> wrote:
> I have written a small (?) tutorial on how to create a planet with
> high-resolution maps, image-maps, bump-maps and spherical heightfields.
>
> https://www.maetes.com/en/blog/how-to-build-a-planet
>
>
> Since there may be more tutorials at some point, I would of course be interested
> in your opinion. It's useless if no one understands it or wants to read it.
>
> Too short, too long, too much text, too many details, incomprehensible, errors
> inside, whatever.
>
> I guess I've told too much. Unfortunately, I kept coming up with more and more
> text.
>
> Greeting Martin

Thanks! I like the idea of two per-level steps!

[Leroy] Re: Tutorial - Planets [148 days 1 hour and 48 minutes ago]

Fri, 7 Nov 2025 21:55:00 GMT

"Maetes" <nomail@nomail> wrote:
> I have written a small (?) tutorial on how to create a planet with
> high-resolution maps, image-maps, bump-maps and spherical heightfields.
>
> https://www.maetes.com/en/blog/how-to-build-a-planet
>
>
> Since there may be more tutorials at some point, I would of course be interested
> in your opinion. It's useless if no one understands it or wants to read it.
>
> Too short, too long, too much text, too many details, incomprehensible, errors
> inside, whatever.
>
> I guess I've told too much. Unfortunately, I kept coming up with more and more
> text.
>
> Greeting Martin

Fine work! I have used everything you had in part 1! It was easy to follow, well
written, and plenty of graphics. It had all that was needed and not much you
didn't.

Part2 is not as well organize. From the line:
 You can continue experimenting with the variables or parameters Radius,
HeightDiff, max_gradient and accuracy.
 Where it didn't mention that this was for an isosurface, to the 'PRO's & CON's
that leave image_maps and isosurfaces off the list.
 I did like the animation and I always like Mars. A few years back I drove
deeply into Mar with POV with image and bump maps. Exploring Mars by adding
water levels and cutting the tops off the high ground. But I'm getting off
topic.
Part2 doesn't feel like a tutorial, but more like 'look at this stuff'.

I appreciated the work you did putting this altogether. I remember the hours I
spent working with Mars and other planets.

Have Fun!

[yesbird] Re: Tutorial - Planets [149 days 1 hour and 23 minutes ago]

Thu, 6 Nov 2025 22:20:06 GMT

On 06/11/2025 22:16, Maetes wrote:
> Since there may be more tutorials at some point, I would of course be interested
> in your opinion. It's useless if no one understands it or wants to read it.

Thanks for this tutorial, I like the detailed explanations and 
step-by-step approach.

Maybe I will use it in my VR-Planetarium project, this is the first 
draft (POC):
https://yesbird.online/gallery/?m=deep_space&e=env_space2&r=true
--
YB

[Maetes] Tutorial - Planets [149 days 4 hours and 23 minutes ago]

Thu, 6 Nov 2025 19:20:00 GMT

I have written a small (?) tutorial on how to create a planet with
high-resolution maps, image-maps, bump-maps and spherical heightfields.

https://www.maetes.com/en/blog/how-to-build-a-planet


Since there may be more tutorials at some point, I would of course be interested
in your opinion. It's useless if no one understands it or wants to read it.

Too short, too long, too much text, too many details, incomprehensible, errors
inside, whatever.

I guess I've told too much. Unfortunately, I kept coming up with more and more
text.

Greeting Martin

[19100] Re: Multiprocessing with POV-Ray [856 days 8 hours and 23 minutes ago]

Thu, 30 Nov 2023 15:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "19100" <nomail@nomail> wrote:
> > I've put together a guide for a neat trick I imagine many people here are
> > familiar with, how to use "multi-threading" with older versions of POV-Ray:
> > https://19100.neocities.org/guides/povraymultiprocessing
>
> another real neat exploration, v cool.  (your use of 'dd' is teaching this old
> dog new tricks :-))
>
>
> regards, jr.

Thanks! I ended up switching out dd at someone's request, but good to know it
was informative.

[jr] Re: Multiprocessing with POV-Ray [856 days 9 hours and 43 minutes ago]

Thu, 30 Nov 2023 14:00:00 GMT

hi,

"19100" <nomail@nomail> wrote:
> I've put together a guide for a neat trick I imagine many people here are
> familiar with, how to use "multi-threading" with older versions of POV-Ray:
> https://19100.neocities.org/guides/povraymultiprocessing

another real neat exploration, v cool.  (your use of 'dd' is teaching this old
dog new tricks :-))

regards, jr.

[19100] Multiprocessing with POV-Ray [860 days 5 hours and 53 minutes ago]

Sun, 26 Nov 2023 17:50:00 GMT

I've put together a guide for a neat trick I imagine many people here are
familiar with, how to use "multi-threading" with older versions of POV-Ray:
https://19100.neocities.org/guides/povraymultiprocessing

[19100] Re: POV-Ray 2.2 Compilation Tutorial [948 days 7 hours and 58 minutes ago]

Wed, 30 Aug 2023 15:45:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "19100" <nomail@nomail> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > ... the <source> tags ...
> >
> > Thanks for giving it a quick look. My understanding of <nowiki> is that it
> > disables MediaWiki syntax for that block right?
>
> yes.
>
>
> > If you could explain the benefit of it vs <source> that would be great to know.
>
> as happens so often in life :-) I found the reference to the extension providing
> the <source> pretty much after posting; first item in editing guidelines, no
> less :-(.  without that extension in place I would have argued to keep ml-like
> mark-up out of the page; either <nowiki> or <pre> would preserve the given
> formatting.  so, sorry, my bad.  hth.
>
>
> regards, jr.

Ah, no worries, I see where you were coming from.

[jr] Re: POV-Ray 2.2 Compilation Tutorial [949 days 4 hours and 23 minutes ago]

Tue, 29 Aug 2023 19:20:00 GMT

hi,

"19100" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ... the <source> tags ...
>
> Thanks for giving it a quick look. My understanding of <nowiki> is that it
> disables MediaWiki syntax for that block right?

yes.

> If you could explain the benefit of it vs <source> that would be great to know.

as happens so often in life :-) I found the reference to the extension providing
the <source> pretty much after posting; first item in editing guidelines, no
less :-(.  without that extension in place I would have argued to keep ml-like
mark-up out of the page; either <nowiki> or <pre> would preserve the given
formatting.  so, sorry, my bad.  hth.

regards, jr.

[19100] Re: POV-Ray 2.2 Compilation Tutorial [951 days 8 hours and 23 minutes ago]

Sun, 27 Aug 2023 15:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "19100" <nomail@nomail> wrote:
> > ...
> > I'm something of a MediaWiki noob so let me know if anything's amiss.
>
> have only had a quick few minutes to look, sorry.  ok for the most part I think.
> the <source> tags though I'd recommend replacing with <nowiki> (or perhaps
> <pre>, cf "boxed").  there may be other "stuff", will have another (hopefully
> closer) read in the next days.  (and thanks, the guide's neat)
>
>
> regards, jr.

Thanks for giving it a quick look. My understanding of <nowiki> is that it
disables MediaWiki syntax for that block right? If you could explain the benefit
of it vs <source> that would be great to know.

[jr] Re: POV-Ray 2.2 Compilation Tutorial [954 days 5 hours and 33 minutes ago]

Thu, 24 Aug 2023 18:10:00 GMT

hi,

"19100" <nomail@nomail> wrote:
> ...
> I'm something of a MediaWiki noob so let me know if anything's amiss.

have only had a quick few minutes to look, sorry.  ok for the most part I think.
the <source> tags though I'd recommend replacing with <nowiki> (or perhaps
<pre>, cf "boxed").  there may be other "stuff", will have another (hopefully
closer) read in the next days.  (and thanks, the guide's neat)

regards, jr.

[jr] Re: POV-Ray 2.2 Compilation Tutorial [961 days 14 hours and 38 minutes ago]

Thu, 17 Aug 2023 09:05:00 GMT

hi,

"19100" <nomail@nomail> wrote:
> ...
> I'm something of a MediaWiki noob so let me know if anything's amiss.

I rarely have to use "mark-down", but will have a look at the source sometime in
the coming days.


regards, jr.

[19100] Re: POV-Ray 2.2 Compilation Tutorial [963 days 4 hours and 33 minutes ago]

Tue, 15 Aug 2023 19:10:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "19100" <nomail@nomail> wrote:
> > ...
> > Appreciate it, I'll send Chris a message.
>
> seems to have worked :-).  good.
>
>
> regards, jr.

It sure did, here's the page:
https://wiki.povray.org/content/HowTo:Compile_POV-Ray_2.2
I'm something of a MediaWiki noob so let me know if anything's amiss.

[jr] Re: POV-Ray 2.2 Compilation Tutorial [965 days 8 hours and 43 minutes ago]

Sun, 13 Aug 2023 15:00:00 GMT

hi,

"19100" <nomail@nomail> wrote:
> ...
> Appreciate it, I'll send Chris a message.

seems to have worked :-).  good.


regards, jr.

[19100] Re: POV-Ray 2.2 Compilation Tutorial [968 days 9 hours and 53 minutes ago]

Thu, 10 Aug 2023 13:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "19100" <nomail@nomail> wrote:
> > Seems like the account systems aren't unified like I figured they might be and
> > registration appears to be disabled. What's the process for getting editing
> > rights?
>
> yeah, not straightforward.  use the current webmaster address ,'w1061 _at_
> povray.org'.  fair warning though, you may need to .. prod; self required
> several requests before Chris ('CC') found the time.
>
>
> regards, jr.

Appreciate it, I'll send Chris a message.

[jr] Re: POV-Ray 2.2 Compilation Tutorial [969 days 5 hours and 33 minutes ago]

Wed, 9 Aug 2023 18:10:00 GMT

hi,

"19100" <nomail@nomail> wrote:
> Seems like the account systems aren't unified like I figured they might be and
> registration appears to be disabled. What's the process for getting editing
> rights?

yeah, not straightforward.  use the current webmaster address ,'w1061 _at_
povray.org'.  fair warning though, you may need to .. prod; self required
several requests before Chris ('CC') found the time.

regards, jr.

[19100] Re: POV-Ray 2.2 Compilation Tutorial [971 days 9 hours and 58 minutes ago]

Mon, 7 Aug 2023 13:45:00 GMT

Seems like the account systems aren't unified like I figured they might be and
registration appears to be disabled. What's the process for getting editing
rights?

[19100] Re: POV-Ray 2.2 Compilation Tutorial [972 days 8 hours and 38 minutes ago]

Sun, 6 Aug 2023 15:05:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "19100" <nomail@nomail> wrote:
> > I've written a guide for compiling POV-Ray 2.2 from source and incorporating a
> > deterministic random number generator, hope someone finds this useful:
> > https://19100.neocities.org/guides/povray2compilation
>
> thank you very much, very nice indeed.  (also, imo, a candidate for the wiki)
> only, so far, had a quick read of the page, but bookmarked for the near future.
>
>
> regards, jr.

Thanks, a wiki page sounds like a good idea, I'll get on that.

[jr] Re: POV-Ray 2.2 Compilation Tutorial [974 days 5 hours and 38 minutes ago]

Fri, 4 Aug 2023 18:05:00 GMT

hi,

"19100" <nomail@nomail> wrote:
> I've written a guide for compiling POV-Ray 2.2 from source and incorporating a
> deterministic random number generator, hope someone finds this useful:
> https://19100.neocities.org/guides/povray2compilation

thank you very much, very nice indeed.  (also, imo, a candidate for the wiki)
only, so far, had a quick read of the page, but bookmarked for the near future.

regards, jr.

[19100] POV-Ray 2.2 Compilation Tutorial [978 days 8 hours and 53 minutes ago]

Mon, 31 Jul 2023 14:50:00 GMT

I've written a guide for compiling POV-Ray 2.2 from source and incorporating a
deterministic random number generator, hope someone finds this useful:
https://19100.neocities.org/guides/povray2compilation

[Josh English] Camera Sky Vector Tutorial [1054 days 19 hours and 48 minutes ago]

Tue, 16 May 2023 03:54:53 GMT

I found the website for my old Cyclopedia of Solutions, with all the 
2005-era HTML and images, but none of the original POV-Ray scripts that 
generated the images.

I've reworked it as a nine-frame animation. Each frame is explained in 
the comments of the #switch statement. I hope that format is readable.

Any feedback is welcome.

[jr] Re: Saturn's Rings with Adjustable Starfield Sky... [1473 days 13 hours and 28 minutes ago]

Wed, 23 Mar 2022 10:15:00 GMT

hi,

"Molly-J" <nomail@nomail> wrote:
> //      This is Saturns Rings with commentary for tutorial purposes

nice.  (audacious! :-))  made me smile.  thank you.


regards, jr.

[Thomas de Groot] Re: Saturn's Rings with Adjustable Starfield Sky... [1473 days 15 hours and 59 minutes ago]

Wed, 23 Mar 2022 07:43:27 GMT

Neat. Thanks!

-- 
Thomas

[Molly-J] Saturn's Rings with Adjustable Starfield Sky_Sph... [1474 days 7 hours and 13 minutes ago]

Tue, 22 Mar 2022 16:30:00 GMT

//      This is Saturns Rings with commentary for tutorial purposes
//      Molly J.

// YOU MAY HAVE TO COPY AND PASTE THIS INTO YOUR OWN TEXT READER TO PRESERVE
LEGIBLE FORMATTING. STUPID 80 CHARACTER LINE LIMIT INHERITED FROM PUNCH-CARDS!

camera { location <0,0,-200> look_at <0,0,0> right x*1600/900 angle 4 }

background {rgb <0, 0, 0>}

light_source { <-15,5,-15> color rgb <2,2,2> } // sharp shadows-- "parallel?
point source?"


//    STARRY SKY BACKGROUND SPHERE ADAPTED FROM Jeff Burton'S "stars.inc"
//    THIS PIGMENT IS LESS CROWDED WITH STARS AND LABELED BY COLOUR.
//    TO CHANGE THE POPULATION COUNT, CHANGE THE BANDWIDTH ON THE LINES
//    FOR EXAMPLE "0.270  0.2701" TO "0.270  0.27001"
//    REMEMBER TO MATCH THE BLACK LINE THAT FOLLOWS TO "0.27001  0.470"
//
//    0.000 BLACK 0.270 YELLOW 0.2701 BLACK 0.470 BLUE 0.4701 BLACK 0.680 RED
0.6801 BLACK 0.880 WHITE 0.8801 BLACK 1.000


//    BLACK SKY SPHERE WITH STARS
sky_sphere
{
    pigment
        {
                granite
                color_map
                {
                        [ 0.000  0.270 color rgb < 0, 0, 0> color rgb < 0, 0, 0>
]    // BLACK
                        [ 0.270  0.2701 color rgb <.5,.5,.4> color rgb
<.8,.8,.4> ]    // YELLOW STARS DIM TO BRIGHT (0.270-)
                        [ 0.2701  0.470 color rgb < 0, 0, 0> color rgb < 0, 0,
0> ]    // BLACK
                        [ 0.470  0.4701 color rgb <.4,.4,.5> color rgb
<.4,.4,.8> ]    // BLUE STARS DIM TO BRIGHT (0.470-)
                        [ 0.4701  0.680 color rgb < 0, 0, 0> color rgb < 0, 0,
0> ]    // BLACK
                        [ 0.680  0.6801 color rgb <.5,.4,.4> color rgb
<.8,.4,.4> ]    // RED STARS DIM TO BRIGHT (0.680-)
                        [ 0.6801  0.880 color rgb < 0, 0, 0> color rgb < 0, 0,
0> ]    // BLACK
                        [ 0.880  0.8801 color rgb <.5,.5,.5> color rgb < 1, 1,
1> ]    // WHITE STARS DIM TO BRIGHT (0.880-)
                        [ 0.8801  1.000 color rgb < 0, 0, 0> color rgb < 0, 0,
0> ]    // BLACK
                }
                turbulence 8
                sine_wave
                scale .5
        }
}

//      PLANET IMAGE MAPS AVAILABLE ONLINE ARE GENERALLY PLATE-CARREE
PROJECTIONS WITH THE PRIME MERIDIAN IN THE CENTER -
//      THIS WRAPS LONGITUDE ZERO ON THE LEFT SIDE. ROTATE THE PLANET -90
DEGREES ON THE Y AXIS TO PUT IT IN FRONT

// SATURN:
sphere
{       <0,0,0>, 1.0 scale <1,1,1>
        pigment {image_map {jpeg "/home/molly/.povray/3.7/saturn.jpg" map_type 1
interpolate 4 }}
        finish {reflection 0.0 refraction 0.0 metallic 0.0}

        rotate y*-90    // Correction for prime meridian AT ZERO

        // CHOOSE LATITUDE / LONGITUDE
        rotate y*-75    // Longitude - West is negative
        rotate x*-13    // Latitude - North is negative
}


//      APPLYING AN IMAGE MAP TO A DISC IN THE CORRECT ORIENTATION FOR
CONCENTRIC RINGLETS IS NOT INTUITIVE
//      BE SURE YOUR IMAGE MAP OF THE RING'S CROSS-SECTION IS ORIENTED
INNER>OUTER, LEFT>RIGHT
//      CREATE THE DISC WITH ORIENTATION VECTOR ON THE Y AXIS
//      USE MAP_TYPE ZERO
//      SCALE THE MAP TO MATCH THE OUTER DIAMETER OF THE DISC; 5 IN THIS CASE
//      WARP WITH CYLINDRICAL ORIENTATION IN THE X AXIS
//      APPLY THE SAME X-Y ROTATIONS AS YOU DID THE PLANET SO THEY MATCH EACH
OTHER


//RINGS:
disc
{       <0,0,0>, <0,1,0>, 5.0, 2.0 // <POSITION>, <ATTITUDE = +Z>, OUTER, INNER
-- match image scale to OUTER. ATT-Z = X-warp **

        pigment
        {       image_map { png "2k_saturn_ring_alpha.png" map_type 0
interpolate 4}
                scale 5  // match ring diameter **
                warp { cylindrical orientation x dist_exp 0 } // TEXTURE WARP
ORIENTATION = X **
        }

        // LAT-LONG
        rotate y*-75    // West is negative
        rotate x*-13    // North is negative
}

// YOU MAY HAVE TO COPY AND PASTE THIS INTO YOUR OWN TEXT READER TO PRESERVE
LEGIBLE FORMATTING

[Bald Eagle] Re: driving simulation examples [1685 days 13 hours and 3 minutes ago]

Mon, 23 Aug 2021 10:40:00 GMT

Maybe Leroy might have some ideas.

http://leroyw.byethost15.com/

https://www.youtube.com/watch?v=oxD8bSPVMng




"ynjiun" <nomail@nomail> wrote:
> Hi,
>
> Not sure I am in the right group or not.
>
> I am looking for tutorial or even better sample codes or .pov files for driving
> scene simulation examples. For example, are we able to use povray to simulate
> the road conditions as shown in Kitti dataset? Where can we find such models to
> begin with?
>
> Thank you very much for your help.
>
> -Ynjiun

[ynjiun] driving simulation examples [1686 days 1 hour and 48 minutes ago]

Sun, 22 Aug 2021 21:55:00 GMT

Hi,

Not sure I am in the right group or not.

I am looking for tutorial or even better sample codes or .pov files for driving
scene simulation examples. For example, are we able to use povray to simulate
the road conditions as shown in Kitti dataset? Where can we find such models to
begin with?

Thank you very much for your help.

-Ynjiun

[Thomas de Groot] Re: Planet Atmosphere Tutorial [1910 days 15 hours and 50 minutes ago]

Sun, 10 Jan 2021 07:52:38 GMT

Op 10/01/2021 om 08:49 schreef Thomas de Groot:
> Op 10/01/2021 om 08:41 schreef Thomas de Groot:
>> Op 10/01/2021 om 05:13 schreef Mike Horvath:
>>> This tutorial assumes the planet radius is always 1. What do I need 
>>> to do if the radius is some other value? thanks.
>>>
>>>
>>> Mike
>>>
>>
>> The quick answer would be:
>> 1) define a new radius for the planet; e.g. Radius = 100;
>> 2)  multiply the rgb value in the media elements (scattering in the 
>> example) by 1/Radius; e.g. scattering {4, rgb <.4,.5,1>*5*(1/Radius) 
>> extinction .00005}
>> 3) Scale your planet and atmosphere union; e.g. union{ sphere{...} 
>> sphere{...} scale 100}
>>
> 
> I just see that the author additionally scales the atmosphere by 1.04. I 
> think you should also compensate for that.
> 
> Another possibility would be to fix the planet's and atmosphere's radius 
> from the start and not be troubled by extra scaling:
> 
> union{
>     sphere {0, 100 texture {Planet1}}
>     sphere {0, 104 hollow pigment{rgbt 1.0} interior {media {atmos1} 
> media{atmos2}}}
> }
> 
> The example above about scattering applies also to the absortion media 
> of course.
> 

And finally, just to be faster than Alain :-)
*Always* use intervals 1 and samples with only one value. Remember that 
this is a 1999 tutorial!

And now I shut up.


-- 
Thomas

[Thomas de Groot] Re: Planet Atmosphere Tutorial [1910 days 15 hours and 53 minutes ago]

Sun, 10 Jan 2021 07:49:36 GMT

Op 10/01/2021 om 08:41 schreef Thomas de Groot:
> Op 10/01/2021 om 05:13 schreef Mike Horvath:
>> This tutorial assumes the planet radius is always 1. What do I need to 
>> do if the radius is some other value? thanks.
>>
>>
>> Mike
>>
> 
> The quick answer would be:
> 1) define a new radius for the planet; e.g. Radius = 100;
> 2)  multiply the rgb value in the media elements (scattering in the 
> example) by 1/Radius; e.g. scattering {4, rgb <.4,.5,1>*5*(1/Radius) 
> extinction .00005}
> 3) Scale your planet and atmosphere union; e.g. union{ sphere{...} 
> sphere{...} scale 100}
> 

I just see that the author additionally scales the atmosphere by 1.04. I 
think you should also compensate for that.

Another possibility would be to fix the planet's and atmosphere's radius 
from the start and not be troubled by extra scaling:

union{
    sphere {0, 100 texture {Planet1}}
    sphere {0, 104 hollow pigment{rgbt 1.0} interior {media {atmos1} 
media{atmos2}}}
}

The example above about scattering applies also to the absortion media 
of course.

-- 
Thomas

[Thomas de Groot] Re: Planet Atmosphere Tutorial [1910 days 16 hours and 2 minutes ago]

Sun, 10 Jan 2021 07:41:10 GMT

Op 10/01/2021 om 05:13 schreef Mike Horvath:
> This tutorial assumes the planet radius is always 1. What do I need to 
> do if the radius is some other value? thanks.
> 
> 
> Mike
> 

The quick answer would be:
1) define a new radius for the planet; e.g. Radius = 100;
2)  multiply the rgb value in the media elements (scattering in the 
example) by 1/Radius; e.g. scattering {4, rgb <.4,.5,1>*5*(1/Radius) 
extinction .00005}
3) Scale your planet and atmosphere union; e.g. union{ sphere{...} 
sphere{...} scale 100}

-- 
Thomas

[Mike Horvath] Re: Planet Atmosphere Tutorial [1910 days 19 hours and 29 minutes ago]

Sun, 10 Jan 2021 04:13:42 GMT

This tutorial assumes the planet radius is always 1. What do I need to 
do if the radius is some other value? thanks.


Mike



On 10/13/2013 3:40 AM, posfan12 wrote:
> "MichaelJF" <mi-### [at] t-onlinede> wrote:
>> Hi Mike,
>>
>> a lot of Geocities can be found at the wayback machine (web.archive.org):
>>
>>
http://web.archive.org/web/19990202172115/http://www.geocities.com/SiliconValley/Sector/4317/
>>
>> Best regards,
>> Michael
> 
> Thank you!
> 
> 
> Mike
>

[Cousin Ricky] Re: Fwd: Just a test binary to send to Usenet us... [2115 days 23 hours and 5 minutes ago]

Fri, 19 Jun 2020 00:38:06 GMT

On 2020-03-08 3:46 PM (-4), PeterFerrie wrote:
> For your convenience, I provide you with an attached file.

1. This is a text-only newsgroup; binary attachments are not
    appropriate.
2. This news server is not connected to Usenet.  See section 4 of the
    AUP: https://news.povray.org/3F2F2C40.91C72C69%40pacbell.net

[PeterFerrie] Fwd: Just a test binary to send to Usenet using ... [2218 days 3 hours and 57 minutes ago]

Sun, 8 Mar 2020 19:46:07 GMT

For your convenience, I provide you with an attached file.

[Mike Horvath] Re: New tutorial about 2D screen coordinates [2768 days 22 hours and 55 minutes ago]

Wed, 5 Sep 2018 00:47:35 GMT

On 9/2/2018 3:43 AM, Kenneth wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>>
>> Could you provide a sample where the script fails? I tried a +z to -z
>> camera direction, as well as a wide angle, and the numbers seemed okay.
>>
> 
> If you can pull up Norbert's original pristine file, add these test objects to
> the scene (they're independent of his code-- they're just origin markers to see
> what's going on)...
> 

Oh, I wasn't sure if you were talking about Norbert's script or 
"screen.inc".


Mike

[Thomas de Groot] Re: New tutorial about 2D screen coordinates [2769 days 17 hours and 8 minutes ago]

Tue, 4 Sep 2018 06:34:38 GMT

On 4-9-2018 1:13, Kenneth wrote:
> 
> It will be fun to compare the two independent approaches we've come up with.
> 

I am looking forward to it. My version is just cosmetic stuff so I 
expect yours to be fundamentally better.

-- 
Thomas

[Kenneth] Re: New tutorial about 2D screen coordinates [2770 days and 28 minutes ago]

Mon, 3 Sep 2018 23:15:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> On 2-9-2018 3:54, Kenneth wrote:
> > Thomas, I've been playing around with [Norbert's] code, and I see where some
> > improvements can be made...
>
> You are right. Over time, I have "improved" on the code, one of the
> improvements being the possibility to use true 2D screen coordinates
> instead of percentages. Also that "facing" problem is more or less
> tackled I think, although I regularly have cases where it does not work.
> However, It mostly works and I light a candle to Saint Norbert each
> time. :-)
>
> Anyway, find here my version attached.
>

hey, I think I've figured out most of the needed changes-- after a marathon
coding session ;-)  I still haven't taken a look at your own code (yet!) ; I
first wanted to see what I could come up with. I'll probably post my version
(along with some needed instructions on how to use it), but I'll do it
elsewhere, so as not to hi-jack this thread any further.

It will be fun to compare the two independent approaches we've come up with.

[Kenneth] Re: New tutorial about 2D screen coordinates [2771 days 15 hours and 58 minutes ago]

Sun, 2 Sep 2018 07:45:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
>
> Could you provide a sample where the script fails? I tried a +z to -z
> camera direction, as well as a wide angle, and the numbers seemed okay.
>

If you can pull up Norbert's original pristine file, add these test objects to
the scene (they're independent of his code-- they're just origin markers to see
what's going on)...

union{
cylinder{0,.4*x .012} // X
cylinder{0,.4*y .012} // Y
cylinder{0,.4*z .012} // Z
text{ttf "cyrvetic.ttf" "+ X" 0.1, 0 rotate 90*x scale .15
     translate <.4,.03,0>} // " + X"
text{ttf "cyrvetic.ttf" "+ Y" 0.1, 0 scale .15
     translate <-.1,.4,0>} // " + Y"
text{ttf "cyrvetic.ttf" "+ Z" 0.1, 0 rotate 90*x scale .15
     translate <-.1,.03,.45>} // "+ Z"
     translate .32*y
     pigment{rgb <.2,.2,1>}
   }

Now set his x_pos and y_pos variables to...
#declare x_pos = 20;
#declare y_pos = 90;

Now, run his code, with no no other changes. (Note that his camera is facing -z
by default, not the usual +z.) In the render, the 'positive' x-axis direction is
still facing to the right, when it should be to the left. (It's like the render
has been 'mirrored.') He does include a 'mirror' variable within the macro-- a
switch from +1 to -1 -- which will fix that-- but it also flips his on-screen
text (next to the arrow,) so don't use it.

Now, change his camera to a forward-looking one. Try this...
#declare cam_loc = <-.5,1.8,-3>;
#declare lookat  = <.1,0.2,2>;

In this render, the axis markers look correct, the arrow's text looks correct--
but the arrow is actually on the wrong side of the screen now (left to right).
The x_pos of 20 should put it on the left, but it's now on the right.

Most of this behavior requires only minor fixes (some of which I've managed to
figure out, in a quick-and-dirty way) but I'm still testing things.

And I haven't yet taken a look at Thomas's newer code, to see what goodies he
has come up with...

[Thomas de Groot] Re: New tutorial about 2D screen coordinates [2771 days 16 hours and 55 minutes ago]

Sun, 2 Sep 2018 06:47:38 GMT

On 2-9-2018 8:41, Thomas de Groot wrote:
> Anyway, find here my version attached.
> 

I see (too late, sorry) that for my version you may need the following 
macro too, but only for the testing of the position finder, otherwise 
not. And you can replace that by your own stuff of course.

-- 
Thomas

[Thomas de Groot] Re: New tutorial about 2D screen coordinates [2771 days 17 hours and 1 minute ago]

Sun, 2 Sep 2018 06:41:30 GMT

On 2-9-2018 3:54, Kenneth wrote:
> Thomas, I've been playing around with his code, and I see where some
> improvements can be made. One of the problems I've come across is that the code
> itself seems to be built around a 'backward'-facing camera (i.e., the camera
> position and look_at point resulting in a -z look_at direction.) With a regular
> forward-facing camera, the code produces some odd results (and fixing things is
> apparently not just a simple matter of tweaking only one thing.) But I'm
> continuing to work at it...and to find some way to improve it's accuracy (which
> I suspect is due to whatever particular camera angle is used-- it *seems* to be
> more accurate with a 'zoom' angle rather than wide-angle.) It's quite a
> 'magical' piece of code otherwise.
> 

You are right. Over time, I have "improved" on the code, one of the 
improvements being the possibility to use true 2D screen coordinates 
instead of percentages. Also that "facing" problem is more or less 
tackled I think, although I regularly have cases where it does not work. 
However, It mostly works and I light a candle to Saint Norbert each 
time. :-)

Anyway, find here my version attached.

-- 
Thomas

[Mike Horvath] Re: New tutorial about 2D screen coordinates [2771 days 20 hours and 34 minutes ago]

Sun, 2 Sep 2018 03:08:41 GMT

On 9/1/2018 9:54 PM, Kenneth wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> For ages I have been using Norbert Kern's
>> position_finder.pov macro from 2006
>>
>>
http://news.povray.org/povray.binaries.scene-files/attachment/%3Cweb.4478509041a06b1c9bff7e8b0%40news.povray.org%3E/p
> osition_finder.pov.txt
>>
> 
> For anyone who's interested, here's the link to Norbert's original post (which
> took me awhile to find)...
> 
>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.44784f2141a06b1c9bff7e8b0%40news.povray.org%3E/?ttop=423977
> &toff=3700
> 
> It's not very detailed, unfortunately.
> 
> Thomas, I've been playing around with his code, and I see where some
> improvements can be made. One of the problems I've come across is that the code
> itself seems to be built around a 'backward'-facing camera (i.e., the camera
> position and look_at point resulting in a -z look_at direction.) With a regular
> forward-facing camera, the code produces some odd results (and fixing things is
> apparently not just a simple matter of tweaking only one thing.) But I'm
> continuing to work at it...and to find some way to improve it's accuracy (which
> I suspect is due to whatever particular camera angle is used-- it *seems* to be
> more accurate with a 'zoom' angle rather than wide-angle.) It's quite a
> 'magical' piece of code otherwise.
> 

Could you provide a sample where the script fails? I tried a +z to -z 
camera direction, as well as a wide angle, and the numbers seemed okay.


Mike

[Kenneth] Re: New tutorial about 2D screen coordinates [2771 days 21 hours and 43 minutes ago]

Sun, 2 Sep 2018 02:00:01 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> For ages I have been using Norbert Kern's
> position_finder.pov macro from 2006
>
>
http://news.povray.org/povray.binaries.scene-files/attachment/%3Cweb.4478509041a06b1c9bff7e8b0%40news.povray.org%3E/p
osition_finder.pov.txt
>

For anyone who's interested, here's the link to Norbert's original post (which
took me awhile to find)...

http://news.povray.org/povray.binaries.images/thread/%3Cweb.44784f2141a06b1c9bff7e8b0%40news.povray.org%3E/?ttop=423977
&toff=3700

It's not very detailed, unfortunately.

Thomas, I've been playing around with his code, and I see where some
improvements can be made. One of the problems I've come across is that the code
itself seems to be built around a 'backward'-facing camera (i.e., the camera
position and look_at point resulting in a -z look_at direction.) With a regular
forward-facing camera, the code produces some odd results (and fixing things is
apparently not just a simple matter of tweaking only one thing.) But I'm
continuing to work at it...and to find some way to improve it's accuracy (which
I suspect is due to whatever particular camera angle is used-- it *seems* to be
more accurate with a 'zoom' angle rather than wide-angle.) It's quite a
'magical' piece of code otherwise.

[Mike Horvath] Re: New tutorial about 2D screen coordinates [2772 days 11 hours and 30 minutes ago]

Sat, 1 Sep 2018 12:13:16 GMT

I added another, simpler sample scene to the wiki article.


Mike

[Bald Eagle] Re: New tutorial about 2D screen coordinates [2772 days 11 hours and 33 minutes ago]

Sat, 1 Sep 2018 12:10:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> #local ScreenLoc_1 = Get_Screen_XY(SphereLoc_1);
> sphere {SphereLoc_1, 0.1 pigment {Cyan}}

Having used the old screen.inc, and just giving the code here a cursory look - I
would say yes.
All of that stuff just seems to be his scene code for placing the spheres at the
corners of that rotated cube.
The only important thing is the macro call.

[Mike Horvath] Re: New tutorial about 2D screen coordinates [2772 days 12 hours and 34 minutes ago]

Sat, 1 Sep 2018 11:08:57 GMT

On 8/31/2018 11:15 PM, Kenneth wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> I just created a new tutorial about how to calculate very precise values
>> for the 2D screen coordinates of objects in a POV-Ray render.
>>
> 
> That is very cool! I'm already trying to think of other offbeat uses for it.
> 
> Just a suggestion (truly off the top of my head): Would it be possible in some
> way to incorporate some of the complex-looking SCENE code (in your wiki example)
> into an 'additional' #macro or .inc file, that could then 'call' the new
> Screen.inc? (Assuming that those parts are 'generic' for any scene.) If I'm
> correctly grasping your wiki example from a 'first look', there are currently
> some required scene code entries like...
> 
> #local TempAngle = pi/2 - atan(1/cos(pi/4));
> #local TempTrans = transform
> {
>   rotate  +x * 45
>   rotate  +z * degrees(TempAngle)
>   translate +y * sin(TempAngle)
>   translate +y * 1/10
> }
> 
> ....and
> 
> #local SphereLoc_1 = vtransform(-x, TempTrans);  [etc.]
> 
> I'm wondering if this stuff could be 'hidden' from the user (within the
> additional macro or inc file), so that the only actual scene code required would
> be  something like...
> 
> #local ScreenLoc_1 = Get_Screen_XY(SphereLoc_1);
> sphere {SphereLoc_1, 0.1 pigment {Cyan}}
> 
> Sorry if my idea seems too simplistic (or just dumb!), but it's my first thought
> on seeing the wiki's example code and its 'apparent' complexity. Maybe I'm not
> yet grasping which scene code elements are truly part of the 'main idea.'
> 

I could replace the "hedgehog" with something simpler, such as a box or 
pyramid. Thanks for the suggestion!


Mike

[Kenneth] Re: New tutorial about 2D screen coordinates [2772 days 19 hours and 43 minutes ago]

Sat, 1 Sep 2018 04:00:01 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> For ages I have been using Norbert Kern's
> position_finder.pov macro from 2006...

*That* looks quite useful as well; thanks for the link. I must have missed it
way back in '06.

[Kenneth] Re: New tutorial about 2D screen coordinates [2772 days 20 hours and 23 minutes ago]

Sat, 1 Sep 2018 03:20:01 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> I just created a new tutorial about how to calculate very precise values
> for the 2D screen coordinates of objects in a POV-Ray render.
>

That is very cool! I'm already trying to think of other offbeat uses for it.

Just a suggestion (truly off the top of my head): Would it be possible in some
way to incorporate some of the complex-looking SCENE code (in your wiki example)
into an 'additional' #macro or .inc file, that could then 'call' the new
Screen.inc? (Assuming that those parts are 'generic' for any scene.) If I'm
correctly grasping your wiki example from a 'first look', there are currently
some required scene code entries like...

#local TempAngle = pi/2 - atan(1/cos(pi/4));
#local TempTrans = transform
{
 rotate  +x * 45
 rotate  +z * degrees(TempAngle)
 translate +y * sin(TempAngle)
 translate +y * 1/10
}

....and

#local SphereLoc_1 = vtransform(-x, TempTrans);  [etc.]

I'm wondering if this stuff could be 'hidden' from the user (within the
additional macro or inc file), so that the only actual scene code required would
be  something like...

#local ScreenLoc_1 = Get_Screen_XY(SphereLoc_1);
sphere {SphereLoc_1, 0.1 pigment {Cyan}}

Sorry if my idea seems too simplistic (or just dumb!), but it's my first thought
on seeing the wiki's example code and its 'apparent' complexity. Maybe I'm not
yet grasping which scene code elements are truly part of the 'main idea.'

[Thomas de Groot] Re: New tutorial about 2D screen coordinates [2773 days 16 hours and 7 minutes ago]

Fri, 31 Aug 2018 07:36:03 GMT

On 31-8-2018 4:39, Mike Horvath wrote:
> I just created a new tutorial about how to calculate very precise values 
> for the 2D screen coordinates of objects in a POV-Ray render.
> 
> http://wiki.povray.org/content/HowTo:Output_2D_screen_coordinates#Sample_Scene 
> 
> 
> LMKWYT
> 
> 
> Mike

Thank you indeed! Very useful. Noting it does exactly the opposite of 
what I generally do :-) For ages I have been using Norbert Kern's 
position_finder.pov macro from 2006, to get (with variable precision I 
must confess) a position somewhere on a 3D landscape or object, 
calculated from a 2D render of the scene. I then use the found 3D 
coordinates to place new objects in the scene.

http://news.povray.org/povray.binaries.scene-files/attachment/%3Cweb.4478509041a06b1c9bff7e8b0%40news.povray.org%3E/position_finder.pov.txt

-- 
Thomas

[Mike Horvath] New tutorial about 2D screen coordinates [2773 days 21 hours and 4 minutes ago]

Fri, 31 Aug 2018 02:39:14 GMT

I just created a new tutorial about how to calculate very precise values 
for the 2D screen coordinates of objects in a POV-Ray render.

http://wiki.povray.org/content/HowTo:Output_2D_screen_coordinates#Sample_Scene

LMKWYT


Mike

[Chalchiuhticue Naabah] Re: Cartoon Tut! [3125 days 20 hours and 28 minutes ago]

Wed, 13 Sep 2017 03:15:01 GMT

"Nathan Kopp" <Nat### [at] Koppcom> wrote:
> DEPerere <per### [at] infomaniakch> wrote...
> >
> > I've noticed that with find_edges, shadowed surfaces can take the color
> > set in PIGMENT_STATEMENTS. When DEPTH_THRESH is set to a little value,
> > instead the single colored line of the edge, we have a big colored area.
> > Setting a high value fix this problem, but another can arise. We may
> > loose some edges.
>
> Keep the value low, but not that low.  In your example, increasing the value
> to 5 or 6 solved the problem of the large grey areas, while keeping the
> edges.
>
> > See my post on p.b.i. I used Ionic5 to illustrate the DEPTH_THRESH
> > problem, in B/W.
>
> See my reply in p.b.i for a further explanation.
>
> -Nathan

[clipka] Re: Peaceful coexistence between 3.7.0 and 3.7.1 [3304 days 13 hours and 55 minutes ago]

Sat, 18 Mar 2017 09:47:56 GMT

Am 18.03.2017 um 03:16 schrieb Cousin Ricky:
> The POV-Ray 3.7.0 cannot run the 3.7.1 version of ior.inc, which means
> if I beta test 3.7.1, I must commit.  Or does it?  The solution to this
> problem was embarrassingly simple:

On Windows, the solution should be even more embarrassingly simple:

- The `ior.inc` for POV-Ray 3.7.0 should be residing in
`%USERPROFILE%\Documents\POV-Ray\v3.7\include`, and that's where POV-Ray
3.7.0 should be looking for it.

- The `ior.inc` for POV-Ray 3.7.1-beta should be residing in
`%USERPROFILE%\Documents\POV-Ray\v3.7-beta\include`, and that's where
POV-Ray 3.7.1-beta should be looking for it.

If that's not the case, let us know.

(Your solution /may/ come in handy later during release candidate phase
or after release, in case someone wants to keep the old 3.7.0 binaries
around, as 3.7.1 will then switch from `v3.7-beta` to `v3.7`.)


On Unix, you can run the `configure` script with the `--prefix=`
parameter to have `make install` install the beta to a different
location, which I /think/ should also solve the issue.

[Cousin Ricky] Peaceful coexistence between 3.7.0 and 3.7.1 [3304 days 21 hours and 31 minutes ago]

Sat, 18 Mar 2017 02:12:03 GMT

The POV-Ray 3.7.0 cannot run the 3.7.1 version of ior.inc, which means 
if I beta test 3.7.1, I must commit.  Or does it?  The solution to this 
problem was embarrassingly simple:

0. Before starting, make sure you have a copy of the 3.7.0 version of
    ior.inc somewhere safe.  By "safe," I mean someplace it will not be
    overwritten by the POV-Ray installation process.

1. After installing the beta, rename ior.inc in the production include
    directory to ior371.inc.

    You can find the name of this directory in the Library paths
    listing in the message window after you render a scene; it is
    typically My Documents\POV-Ray\v3.7 in Windows and
    /usr/local/share/povray-3.7/include in Unix.

2. Copy the 3.7.0 version of ior.inc to the production
    include directory, renaming it to ior370.inc.

3. Create the following file, name it ior.inc, and copy it to the
    production include directory:

----------[BEGIN CODE]----------
/* ior.inc switch
  * Persistence of Vision Ray Tracer include file
  *
  * Loads a standard version of ior.inc according to the scene's
  * POV-Ray version.
  */
#include #if (version = 3.7) "ior370.inc" #else "ior371.inc" #end
-----------[END CODE]-----------

I recommend keeping a copy this file in one of your user directories, as 
this process must be repeated after every beta install.

[Cousin Ricky] Re: #declare vs. #local Mojo [3859 days 2 hours and 28 minutes ago]

Thu, 10 Sep 2015 21:15:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Some fun(?) fact to know:
>
> If, in an include file or macro, you use #declare with an identifier
> that already happens to exist at a non-global scope, you will NOT change
> the corresponding global variable, but the most local variable of that name.
>
> Expected that? I didn't.

http://wiki.povray.org/content/Reference:Declare_and_Local_Directives#Identifier_Name_Collisions

[clipka] Re: #declare vs. #local Mojo [3936 days 1 hour and 55 minutes ago]

Thu, 25 Jun 2015 21:47:56 GMT

Am 25.06.2015 um 08:09 schrieb Le_Forgeron:

> ( there is also #for... the
> variable is kind of #local, yet should it be allowed to be updated
> with #local ? )

Mucking around with the variable in a #for statement isn't really what 
I'd call best practice, but if you need to change the value, then #local 
should be the thing to use.

[Thorsten Froehlich] Re: #declare vs. #local Mojo [3936 days 12 hours and 3 minutes ago]

Thu, 25 Jun 2015 11:40:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Some fun(?) fact to know:
>
> If, in an include file or macro, you use #declare with an identifier
> that already happens to exist at a non-global scope, you will NOT change
> the corresponding global variable, but the most local variable of that name.
>
> Expected that? I didn't.

Expected? No.
Knew? Yes.

The problem with this odd behavior is that it is actively being used. Or used to
be at least.

Thorsten

[Le Forgeron] Re: #declare vs. #local Mojo [3936 days 17 hours and 34 minutes ago]

Thu, 25 Jun 2015 06:09:11 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 25/06/2015 02:26, clipka a Ã©crit :
> Some fun(?) fact to know:
> 
> If, in an include file or macro, you use #declare with an
> identifier that already happens to exist at a non-global scope, you
> will NOT change the corresponding global variable, but the most
> local variable of that name.
> 
> Expected that? I didn't.

I did, but I know how the context are stacked...

My hint: do not mix #declare and #local for the same variable, or even
parameter name of macro.

The same kind of problem happens with other languages, it's called
shadowing and it's a mess to know which one is used.

The long way would be to issue warning when using #local on a
#declare/d variable, and vice-versa, but it might requires extending
each storage to store that piece of data ( there is also #for... the
variable is kind of #local, yet should it be allowed to be updated
with #local ? )


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlWLmwcACgkQhKAm8mTpkW32VQQA033DeqL81d9BI1pJi1x36162
CLTu8rPTzYZa0FbOTuCF+QtyqNOiVtsyx5qGjopK3UKLzvw/ss/ZLErbVmlvGD6Q
Mq7WwXAedgrFP0hTtTrUJV09Bgh98O35+SdHq7fGjcoF2eizjI41oSalzzknPePO
oi8stAyB3RcXzHx2SFY=
=l9L2
-----END PGP SIGNATURE-----

[clipka] #declare vs. #local Mojo [3936 days 23 hours and 16 minutes ago]

Thu, 25 Jun 2015 00:26:44 GMT

Some fun(?) fact to know:

If, in an include file or macro, you use #declare with an identifier 
that already happens to exist at a non-global scope, you will NOT change 
the corresponding global variable, but the most local variable of that name.

Expected that? I didn't.

[jhu] Re: Updated scripts for make-shift cluster rende... [4447 days 4 hours and 18 minutes ago]

Thu, 30 Jan 2014 19:25:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:

>
> IMHO with 3.7, you would make better use of block splitting by using a
> portion whose boundary are aligned with block size (+BS option)
>
> Notice that you parse the scene multiple times... and that there would
> be issue with radiosity and maybe photons.

Edit as you see fit.

For radiosity, I think saving the first few passes and then loading the
radiosity data for each machine should work.

[Le Forgeron] Re: Updated scripts for make-shift cluster rende... [4447 days 4 hours and 44 minutes ago]

Thu, 30 Jan 2014 18:58:39 GMT

Le 30/01/2014 00:51, jhu nous fit lire :
> See
>
http://news.povray.org/povray.text.tutorials/thread/%3Cweb.4bab09e0aad27b55ab8b233e0%40news.povray.org%3E/
> for general principles.
> 
> I have two 6-core machines that I use for rendering scenes that take a long time
> to render. Given a scene called "foo.pov", "foo1,pov" and "foo2.pov" are just
> copies of each other.

> We end up with numerous files named 1.png to 1061.png once all the machines are
> finished rendering, each file being a 20 line portion of the final image. Stitch
> them together using imagemagick command-line programs:

IMHO with 3.7, you would make better use of block splitting by using a
portion whose boundary are aligned with block size (+BS option)

Notice that you parse the scene multiple times... and that there would
be issue with radiosity and maybe photons.

[jhu] Updated scripts for make-shift cluster rendering [4447 days 23 hours and 48 minutes ago]

Wed, 29 Jan 2014 23:55:01 GMT

See
http://news.povray.org/povray.text.tutorials/thread/%3Cweb.4bab09e0aad27b55ab8b233e0%40news.povray.org%3E/
for general principles.

I have two 6-core machines that I use for rendering scenes that take a long time
to render. Given a scene called "foo.pov", "foo1,pov" and "foo2.pov" are just
copies of each other.

First machine runs this script:

******************
#!/bin/bash
for ((i=1; i<=1080; i+=20))
do
  if [ ! -e "$i.png" ]
   then
    touch $i.png
    let "j = i + 19"
    povray +A0.3 -d +ifoo1 +O$i.png +w1920 +h1080 +SR$i +ER$j
  fi
done
********************

Second machine runs this script

******************
#!/bin/bash
 for ((i=1; i<=1080; i+=20))
 do
  if [ ! -e "$i.png" ]
   then
    touch $i.png
    let "j = i + 19"
    povray +A0.3 -d +ifoo2 +O$i.png +w1920 +h1080 +SR$i +ER$j
  fi
 done
********************

We end up with numerous files named 1.png to 1061.png once all the machines are
finished rendering, each file being a 20 line portion of the final image. Stitch
them together using imagemagick command-line programs:

******************************
#!/bin/bash

for ((i=1; i<=1080; i+=20))
do
  let "j = i + 19"
  let "k = i - 1"
  convert -define png:size=1920x1080 -extract 1920x20+0+$k $i.png $i\_new.png
done

mv 1_new.png 0001_new.png

for ((i=21; i<=99; i+=20))
do
        mv $i\_new.png 00$i\_new.png
done

for ((i=101; i<=999; i+=20))
do
        mv $i\_new.png 0$i\_new.png
done

convert `ls *\_new.png` -append image.png
**********************************************

Final image is image.png

[posfan12] Re: Planet Atmosphere Tutorial [4556 days 15 hours and 58 minutes ago]

Sun, 13 Oct 2013 07:45:01 GMT

"MichaelJF" <mi-### [at] t-onlinede> wrote:
> Hi Mike,
>
> a lot of Geocities can be found at the wayback machine (web.archive.org):
>
>
http://web.archive.org/web/19990202172115/http://www.geocities.com/SiliconValley/Sector/4317/
>
> Best regards,
> Michael

Thank you!


Mike

[MichaelJF] Re: Planet Atmosphere Tutorial [4556 days 16 hours and 23 minutes ago]

Sun, 13 Oct 2013 07:20:00 GMT

"posfan12" <nomail@nomail> wrote:
> "Darcy Johnston" <djo### [at] inamecomNOSPAM> wrote:
> > Well, I've finally done it. I managed to get my first tutorial up at my
> > website.
> > It describes how to create a planet's atmosphere using media. You can access
> > it in the tutorial section of my website (see address below). Please let me
> > know what you think of it. Hopefully, I will be able to offer new tutorials
> > in the future.
> >
> > Cheers,
> > Darcy
> > djo### [at] inamecomNOSPAM
> > http://www.geocities.com/SiliconValley/Sector/4317
>
> Dammit Geocities!!!!!!
>
>
> Mike

Hi Mike,

a lot of Geocities can be found at the wayback machine (web.archive.org):

http://web.archive.org/web/19990202172115/http://www.geocities.com/SiliconValley/Sector/4317/

Best regards,
Michael

[posfan12] Re: Planet Atmosphere Tutorial [4556 days 16 hours and 38 minutes ago]

Sun, 13 Oct 2013 07:05:01 GMT

"Darcy Johnston" <djo### [at] inamecomNOSPAM> wrote:
> Well, I've finally done it. I managed to get my first tutorial up at my
> website.
> It describes how to create a planet's atmosphere using media. You can access
> it in the tutorial section of my website (see address below). Please let me
> know what you think of it. Hopefully, I will be able to offer new tutorials
> in the future.
>
> Cheers,
> Darcy
> djo### [at] inamecomNOSPAM
> http://www.geocities.com/SiliconValley/Sector/4317

Dammit Geocities!!!!!!


Mike

[Le Forgeron] Re: Highlight Voodo [5017 days 17 hours and 1 minute ago]

Mon, 9 Jul 2012 06:41:34 GMT

Le 06/07/2012 19:34, clipka a Ã©crit :
> Am 06.07.2012 16:47, schrieb Cousin Ricky:
>> clipka<ano### [at] anonymousorg>  wrote:
>>> Am 06.07.2012 02:22, schrieb Cousin Ricky:
>>>> clipka<ano### [at] anonymousorg>   wrote:
>>>>> If we're talking about dull surfaces, then mu - as stated above,
>>>>> POV-Ray
>>>>> does not natively support dull (aka blurred) reflections.

A bit late, but have a look at "crand".
It's not a blurred reflection, but the noise added to the usual
reflection is often enough to move away from the perfectly smooth surface.

Crand has not been re-implemented in povray 3.7RC6, but the next RC
should have it.
(so, look at it in 3.6 in the meantime)

-- 
Real software engineers work from 9 to 5, because that is
the way the job is described in the formal spec.  Working
late would feel like using an undocumented external procedure.

[clipka] Re: Highlight Voodo [5020 days 6 hours and 8 minutes ago]

Fri, 6 Jul 2012 17:34:53 GMT

Am 06.07.2012 16:47, schrieb Cousin Ricky:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 06.07.2012 02:22, schrieb Cousin Ricky:
>>> clipka<ano### [at] anonymousorg>   wrote:
>>>> If we're talking about dull surfaces, then mu - as stated above, POV-Ray
>>>> does not natively support dull (aka blurred) reflections.
>>>
>>> This is probably not a good idea (yet?) anyway.  Best to let the users weigh the
>>> various methods and tradeoffs.
>>
>> Well, I personally think blurred reflections are a /great/ thing to
>> have. They can really make or (in case of their absence) break a scene
>> (especially if they're in tune with the highlights parameters).
>
> I agree; I just don't know that we've agreed upon the best way to implement it.

It seems plain as hell to me that the only reasonable way to implement 
it is some kind of oversampling with jitter added to the reflected ray.

And it seems also plain as hell to me that the only reasonable way to 
handle the resulting heavy blow on render performance is to integrate 
all oversampling-based mechanisms into one bigger picture, encompassing 
anti-aliasing, focal blur, media, fog, area lights, subsurface light 
transport, and blurred reflections/refractions. As it is now, all of 
these features do their own full-blown oversampling, thus having a fully 
multiplicative effect on render time each, even though oversampling 
could be much more "lazy" whenever additional oversampling is performed 
somewhere "closer" to the camera anyway.

That, in my opinion, is the only reasonable way to implement it.

As for syntax, parameterization should obviously make it easy to 
properly "synchronize" reflection and highlight parameters, ideally in 
such a way that the very same values used in both the reflection 
"blurriness parameter" and specular roughness produces the most 
realistic match (not the phong_size BTW, as specular highlights are the 
better choice when it comes to realism); adding fresnel support for 
highlights would be highly desirable as well.

Some additional parameters might be added to control the oversampling, 
though I think they can just as well be deduced from the blurriness and 
strength of reflection.

All in all, aside from the choice of keywords and other syntax details, 
I think that after giving it thorough thought, there are no notable 
things to disagree about.

(Speaking of Syntax, copying the MCPov one for the sake of scene 
portability is definitely a no-go; not only is it far away from all 
traditional POV-Ray syntax patterns - it also uses a totally 
intransparent "blurriness" parameterization, and the oversampling 
parameterization is rather poor as well.)

[Cousin Ricky] Re: Highlight Voodo [5020 days 8 hours and 53 minutes ago]

Fri, 6 Jul 2012 14:50:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 06.07.2012 02:22, schrieb Cousin Ricky:
> > clipka<ano### [at] anonymousorg>  wrote:
> >> If we're talking about dull surfaces, then mu - as stated above, POV-Ray
> >> does not natively support dull (aka blurred) reflections.
> >
> > This is probably not a good idea (yet?) anyway.  Best to let the users weigh the
> > various methods and tradeoffs.
>
> Well, I personally think blurred reflections are a /great/ thing to
> have. They can really make or (in case of their absence) break a scene
> (especially if they're in tune with the highlights parameters).

I agree; I just don't know that we've agreed upon the best way to implement it.

[clipka] Re: Highlight Voodo [5020 days 13 hours and 9 minutes ago]

Fri, 6 Jul 2012 10:33:43 GMT

Am 06.07.2012 02:22, schrieb Cousin Ricky:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 04.07.2012 23:27, schrieb Cousin Ricky:
>>> How is this relationship affected if the material isn't "polished"?
>>
>> Mu. POV-Ray's reflection is only realistic for polished surfaces.
>
> What is mu?

A concept from (AFAIK) Zen Buddhism: A reply given to questions for 
which there is no meaningful answer.

>>> Is there any relationship between reflection and roughness/phong_size?
>>
>> If we're talking about polished surfaces: Yes, obviously there is a
>> relationship - it's in the formulae given above.
>
> What I'm asking is for a given reflection value, can we predict what the
> roughness value will be?

No; the reflection value describes how /much/ of the incoming light is 
reflected (for light coming from other objects); the roughness value 
describes how /focused/ the reflection of incoming light will be (from 
light sources).

>> If we're talking about dull surfaces, then mu - as stated above, POV-Ray
>> does not natively support dull (aka blurred) reflections.
>
> This is probably not a good idea (yet?) anyway.  Best to let the users weigh the
> various methods and tradeoffs.

Well, I personally think blurred reflections are a /great/ thing to 
have. They can really make or (in case of their absence) break a scene 
(especially if they're in tune with the highlights parameters).

[Cousin Ricky] Re: Highlight Voodo [5020 days 23 hours and 18 minutes ago]

Fri, 6 Jul 2012 00:25:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 04.07.2012 23:27, schrieb Cousin Ricky:
> > How is this relationship affected if the material isn't "polished"?
>
> Mu. POV-Ray's reflection is only realistic for polished surfaces.

What is mu?

> > Is there any relationship between reflection and roughness/phong_size?
>
> If we're talking about polished surfaces: Yes, obviously there is a
> relationship - it's in the formulae given above.

What I'm asking is for a given reflection value, can we predict what the
roughness value will be?

> If we're talking about dull surfaces, then mu - as stated above, POV-Ray
> does not natively support dull (aka blurred) reflections.

This is probably not a good idea (yet?) anyway.  Best to let the users weigh the
various methods and tradeoffs.

[clipka] Re: Highlight Voodo [5022 days and 19 minutes ago]

Wed, 4 Jul 2012 23:24:17 GMT

Am 04.07.2012 23:27, schrieb Cousin Ricky:
> clipka<ano### [at] anonymousorg>  wrote:
>> Instead, for a polished material, a value of
>>
>>       specular 0.25 * ((1/ROUGHNESS)+1) * REFLECTION
>>
>> or
>>
>>       phong 0.5 * (PHONG_SIZE + 1) * REFLECTION
>>
>> is actually realistic, [...]
>
> How is this relationship affected if the material isn't "polished"?

Mu. POV-Ray's reflection is only realistic for polished surfaces.

> How is this affected by variable or fresnel reflection?

Phong and specular currently don't respect fresnel's law, so when using 
fresnel reflection you should reduce the specular or phong parameter a 
bit to compensate; it's not the real thing though.

> Is there any relationship between reflection and roughness/phong_size?

If we're talking about polished surfaces: Yes, obviously there is a 
relationship - it's in the formulae given above.

If we're talking about dull surfaces, then mu - as stated above, POV-Ray 
does not natively support dull (aka blurred) reflections.

>> BTW there's also a similar law goverining the "diffuse" parameter: If
>> you set "brilliance" to anything but 1, you should set "diffuse" to a
>> maximum of
>>
>>       diffuse 0.5 * (BRILLIANCE + 1)
>>
>> which would correspond to a diffuse reflection of 100%.
>
> Does this mean that you can set diffuse>  1 if brilliance is>  1?

Well, you /can/ do that regardless of brilliance, except that it would 
be unrealistic at brilliance = 1; but for a material with brilliance 2, 
diffuse 1.2 isn't unrealistic.

> In metals.inc and golds.inc, brilliance is increased as reflection is increased.
>   Is there such a correlation in reality, or was that just the way it was decided
> to define the textures?

That's just the way they did it. There's not much parameterization in 
metals.inc or golds.inc that has any correlation to reality whatsoever - 
the material parameters were chosen solely for artistic reasons.

BTW, by now POV-Ray has acquired some new syntax to automatically do the 
above computations for you: Specifying

     specular albedo SPECULAR_ALBEDO
     roughness ROUGHNESS

     phong albedo PHONG_ALBEDO
     phong_size PHONG_SIZE

     diffuse albedo DIFFUSE_ALBEDO
     brilliance BRILLIANCE

is equivalent to:

     specular 0.25 * ((1/ROUGHNESS)+1) * SPECULAR_ALBEDO
     roughness ROUGHNESS

     phong 0.5 * (PHONG_SIZE + 1) * PHONG_ALBEDO
     phong_size PHONG_SIZE

     diffuse 0.5 * (BRILLIANCE + 1) * DIFFUSE_ALBEDO
     brilliance BRILLIANCE

Specular and phong albedo should be equal to reflection (for polished 
materials), while the sum of reflection and diffuse albedo should be 1 
or lower.

(Fresnel (or variable) reflection equivalent is still not supported for 
highlights though, and significantly dull reflection is still not 
available out of the box.)

[Cousin Ricky] Re: Highlight Voodo [5022 days 2 hours and 13 minutes ago]

Wed, 4 Jul 2012 21:30:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Instead, for a polished material, a value of
>
>      specular 0.25 * ((1/ROUGHNESS)+1) * REFLECTION
>
> or
>
>      phong 0.5 * (PHONG_SIZE + 1) * REFLECTION
>
> is actually realistic, [...]

How is this relationship affected if the material isn't "polished"?

How is this affected by variable or fresnel reflection?

Is there any relationship between reflection and roughness/phong_size?

> BTW there's also a similar law goverining the "diffuse" parameter: If
> you set "brilliance" to anything but 1, you should set "diffuse" to a
> maximum of
>
>      diffuse 0.5 * (BRILLIANCE + 1)
>
> which would correspond to a diffuse reflection of 100%.

Does this mean that you can set diffuse > 1 if brilliance is > 1?

In metals.inc and golds.inc, brilliance is increased as reflection is increased.
 Is there such a correlation in reality, or was that just the way it was decided
to define the textures?

[waggy] Re: Highlight Voodo [5246 days 8 hours and 53 minutes ago]

Wed, 23 Nov 2011 14:50:01 GMT

Thank you very much.  Are these "Clipka's Laws", or is there another term for
these relations?

[Warp] Re: Highlight Voodo [5247 days 4 hours and 25 minutes ago]

Tue, 22 Nov 2011 19:18:16 GMT

clipka <ano### [at] anonymousorg> wrote:
> The realistic range for the "specular" and "phong" parameters is /not/ 
> limited to 0..1.

  Using a very strong specular/phong highlight, but making the highlight
small, is a good trick to make a surface look like highly polished, such
as glass (which usually has very sharp highlights rather than smooth ones).

-- 
                                                          - Warp

[clipka] Highlight Voodo [5247 days 4 hours and 57 minutes ago]

Tue, 22 Nov 2011 18:46:02 GMT

Fun fact to know:

The realistic range for the "specular" and "phong" parameters is /not/ 
limited to 0..1.

Instead, for a polished material, a value of

     specular 0.25 * ((1/ROUGHNESS)+1) * REFLECTION

or

     phong 0.5 * (PHONG_SIZE + 1) * REFLECTION

is actually realistic, e.g.

     finish {
       reflection { 0.2 }
       specular 50.05
       roughness 0.001
     }

or

     finish {
       reflection { 0.2 }
       phong 100.1
       phong_size 1000
     }


BTW there's also a similar law goverining the "diffuse" parameter: If 
you set "brilliance" to anything but 1, you should set "diffuse" to a 
maximum of

     diffuse 0.5 * (BRILLIANCE + 1)

which would correspond to a diffuse reflection of 100%.

[clipka] Re: Radiosity Voodoo - Volume 2: The Parameters [5310 days 8 hours and 25 minutes ago]

Tue, 20 Sep 2011 15:18:05 GMT

Am 20.09.2011 13:58, schrieb Cousin Ricky:
> "clipka"<nomail@nomail>  wrote:
>> The pretrace_end value should be low enough to allow all necessary samples to be
>> taken during pretrace already. I recommend using 1/min(image_width,image_height)
>> if you are patient enough, which causes the last pretrace to be taken at the
>> same resolution as the main render; [snip]
>
> It appears that 1/max(image_width,image_height) achieves the result that you
> describe.

Darn, I guess you're right.

[Cousin Ricky] Re: Radiosity Voodoo - Volume 2: The Parameters [5310 days 11 hours and 43 minutes ago]

Tue, 20 Sep 2011 12:00:01 GMT

"clipka" <nomail@nomail> wrote:
> The pretrace_end value should be low enough to allow all necessary samples to be
> taken during pretrace already. I recommend using 1/min(image_width,image_height)
> if you are patient enough, which causes the last pretrace to be taken at the
> same resolution as the main render; [snip]

It appears that 1/max(image_width,image_height) achieves the result that you
describe.

[clipka] Random tip on focal blur [5697 days 6 hours and 2 minutes ago]

Sun, 29 Aug 2010 17:40:23 GMT

For a realistic effect that helps hint at your scene's dimensions, set 
the "aperture" parameter to a value corresponding to about 5mm - a 
diameter of a human pupil - in your scene. E.g. if your scene uses 1 
unit = 1", set aperture to 5/25.4 = 0.197.

Similarly, when trying to simulate a photographic camera, "aperture" 
should be set to a value corresponding to whatever physical diameter the 
camera's aperture is supposedly set to (or, more precisely, /appears/ to 
be set to when looking into the camera lens).

[jhu] Re: jhu's very ghetto cluster for rendering stil... [5854 days and 58 minutes ago]

Thu, 25 Mar 2010 22:45:01 GMT

"Kenneth" <kdw### [at] earthlinknet> wrote:
> "jhu" <nomail@nomail> wrote:
> > If you're like me, you'll have several computers at your disposal that you've
> > collected over the years. Well, time to dust them off and make them do something
> > useful...
> >
> > Here are the general steps to set this whole thing up:
> > .....
> > Sounds simple, so let's get started.
> >
>
> Good God Almighty.
>
> I think you left one step out (at least for me):
>
> 00) Return to college, get Computer Science degree.
>
> Ken  :-[

This coming from the guy who made the B29 bomber over here:
http://news.povray.org/povray.binaries.images/thread/%3Cweb.4baae0a4649f667b65f302820%40news.povray.org%3E/

I think my ghetto cluster setup is pretty simple relatively speaking!

[Kenneth] Re: jhu's very ghetto cluster for rendering stil... [5854 days 1 hour and 23 minutes ago]

Thu, 25 Mar 2010 22:20:01 GMT

"jhu" <nomail@nomail> wrote:
> If you're like me, you'll have several computers at your disposal that you've
> collected over the years. Well, time to dust them off and make them do something
> useful...
>
> Here are the general steps to set this whole thing up:
> .....
> Sounds simple, so let's get started.
>

Good God Almighty.

I think you left one step out (at least for me):

00) Return to college, get Computer Science degree.

Ken  :-[

[jhu] Re: jhu's very ghetto cluster for rendering stil... [5854 days 15 hours and 28 minutes ago]

Thu, 25 Mar 2010 08:15:01 GMT

Warp <war### [at] tagpovrayorg> wrote:
> jhu <nomail@nomail> wrote:
> > #!/bin/sh
> > echo "P6 1920 1080 255" >> scene.ppm
>
> > for ((i=1; i<=1080; i++))
>
>   AFAIK that form of the 'for' directive is a bash extension not available
> in the original sh. Hence that script is basically broken because the first
> line claims it's runnable by using sh.
>
>   (In linux systems /bin/sh is just an alias for /bin/bash, which is something
> I cannot comprehend. bash is certain *not* the same thing as sh, and making
> them equal only produces broken sh scripts which assume bash extensions but
> still claim to be runnable using sh. The script above works, but only if if
> /bin/sh is an alias for bash or another shell that supports the extension.
> It won't work in systems where /bin/sh is the true original sh.)
>
> >  cat scene_$i.ppm | sed '1,3d' >> scene.ppm
>
>   sed '1,3d' scene_$i.ppm >> scene.ppm
>
> --
>                                                           - Warp

Never noticed that since I always installed bash everywhere I went. Hehe...

[Warp] Re: jhu's very ghetto cluster for rendering stil... [5854 days 16 hours and 11 minutes ago]

Thu, 25 Mar 2010 07:31:36 GMT

jhu <nomail@nomail> wrote:
> #!/bin/sh
> echo "P6 1920 1080 255" >> scene.ppm

> for ((i=1; i<=1080; i++))

  AFAIK that form of the 'for' directive is a bash extension not available
in the original sh. Hence that script is basically broken because the first
line claims it's runnable by using sh.

  (In linux systems /bin/sh is just an alias for /bin/bash, which is something
I cannot comprehend. bash is certain *not* the same thing as sh, and making
them equal only produces broken sh scripts which assume bash extensions but
still claim to be runnable using sh. The script above works, but only if if
/bin/sh is an alias for bash or another shell that supports the extension.
It won't work in systems where /bin/sh is the true original sh.)

>  cat scene_$i.ppm | sed '1,3d' >> scene.ppm

  sed '1,3d' scene_$i.ppm >> scene.ppm

-- 
                                                          - Warp

[jhu] jhu's very ghetto cluster for rendering still im... [5854 days 16 hours and 38 minutes ago]

Thu, 25 Mar 2010 07:05:01 GMT

If you're like me, you'll have several computers at your disposal that you've
collected over the years. Well, time to dust them off and make them do something
useful. Currently I have a 2.6 GHz Athlon64 and a 1.2 GHz Celeron-L at my
disposal.

Here are the general steps to set this whole thing up:

0) Put some sort of unix-like OS on the computers and install ssh (I'm assuming
you've already done this part)
1) Give all computers access to the same directory via nfs
2) Make a copy of the .pov file for each computer
3) Have each computer render one or more lines of the scene
4) stitch all the scene files together

Sounds simple, so let's get started.


PART 1 - Give all computers access to the same directory via nfs


If you don't already have a centralized file server with nfs, you can designate
one of computers as the nfs server. Grab the packages via your particular
package manager. Now to setup your nfs server; here's a good link:
http://nfs.sourceforge.net/nfs-howto/ar01s03.html

The gist of it is to edit "/etc/hosts.deny", "/etc/hosts.allow", and
"/etc/exports".

Let's edit "/etc/hosts.deny" first and put in the following:
portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL

That way no one can mount your nfs volume, even you! So let's edit
"/etc/hosts.allow" to change that. Here's mine:
portmap: 192.168.11.204, 192.168.1.204, 192.168.11.206
lockd:   192.168.11.204, 192.168.1.204, 192.168.11.206
rquotad: 192.168.11.204 , 192.168.1.204, 192.168.11.206
mountd:  192.168.11.204 , 192.168.1.204, 192.168.11.206
statd:   192.168.11.204 , 192.168.1.204, 192.168.11.206

You'll need to know your computers' IP addresses or host names. Then add them
in. Now to edit the "/etc/exports" file. Here's mine:
/opt 192.168.1.204(rw,insecure,sync,no_wdelay)
/opt 192.168.11.204(rw,insecure,sync,no_wdelay)
/opt 192.168.11.206(rw,insecure,sync,no_wdelay)

In my case, I'm sharing my nfs server's "/opt" directory with the other
computers. Now you just need to mount the remote directory to your computer
somewhere. I made a new directory "nfs" in my other computers' home directory so
when I remotely log in to them I just type "mount 192.168.11.101:/opt nfs" with
192.168.11.101 being my nfs server


PART 2

So now you have the remote directory mounted on each computer. Now to make
multiple copies of your .pov file. Let's call them scene1.pov, scene2.pov, and
scene3.pov. If you need radiosity, you'll need to render the original scene and
edit your scene file to save the radiosity data. Once that is done, edit all the
copies of the scene files to load the radiosity data. Now the fun part. Let's
write a script in the shared directory that will be run by each computer.

Here's script1.sh :

#!/bin/bash
while [ ! -e "scene_1080.ppm" ]
do
 for ((i=1; i<=1080; i++))
 do
  if [ ! -e "scene_$i.ppm" ]
   then
    touch scene_$i.ppm
    povray +A0.3 -d +FP +iscene1 +Oscene_$i.ppm +w1920 +h1080 +SR$i +ER$i
  fi
 done
done


Here's script2.sh :

#!/bin/bash
while [ ! -e "scene_1080.ppm" ]
do
 for ((i=1; i<=1080; i++))
 do
  if [ ! -e "scene_$i.ppm" ]
   then
    touch scene_$i.ppm
    povray +A0.3 -d +FP +iscene2 +Oscene_$i.ppm +w1920 +h1080 +SR$i +ER$i
  fi
 done
done

The preceding scripts render the scene at 1920x1080 one line at a time.
Eventually we'll end up with 1080 PPM files of 1920 pixels in length. Now,
depending on how long it takes to parse the scene file, it may be better to make
POV-Ray render several rows at a time instead of one at a time. Edit as
appropriate.


PART 3

So now we have 1080 PPM files. PPM files are great for manipulation since the
way POV-Ray generates them, the first three lines are text followed by the image
data. In general there are 6 types of PPM files, designated P1, P2, P3, P4, P5,
or P6. POV-Ray outputs PPM files as the P6 type: the data portion is in red,
green, blue triplets in binary format. The other significant one is the P3 type
in which the RGB triplets are in ASCII.

If you open up one of these files in a text editor you'll see the following:

P6
1920 1080
255
*** image data ***

So what we need to do is make a new PPM file with an appropriate header,
strip the first three lines from each of our 1080 PPM files, and then append the
image data to the new file. Here's the script to do that:

#!/bin/sh
echo "P6 1920 1080 255" >> scene.ppm

for ((i=1; i<=1080; i++))
do
 cat scene_$i.ppm | sed '1,3d' >> scene.ppm
done


Now you can convert scene.ppm to your favorite image format.

[clipka] Re: ARRAYS: More possibilities then the manual t... [6039 days 9 hours and 42 minutes ago]

Mon, 21 Sep 2009 14:00:27 GMT

My! I was always thoroughly convinced that you can't store arrays in 
arrays...

This is precious gold man!

Also note that this allows to store multiple elements of different type 
in one array, by wrapping each in another 1-element array.

[Kene] Re: ARRAYS: More possibilities then the manual t... [6039 days 11 hours and 13 minutes ago]

Mon, 21 Sep 2009 12:30:01 GMT

> // --------- Start of code ----------------------------------------
> #declare Obj = 0;
> #declare Var = 1;
> #declare Tex = 2;
> #declare Total = array[3]
>
> // Make the subarrays
> #declare Objects = array[2]
> #declare Vars = array[4]
>   {0,1, -1, +1}
> #declare Textur = array[2]
>   {pigment{color rgb <0,1,0>},
>    pigment{color rgbt <1,1,1,0.4>} }
>
> // Connect everything
> #declare Total[Obj] = Objects
> #declare Total[Tex] = Textur
> #declare Total[Var] = Vars
>
> // Use it:
> #declare  Total[Obj][0] =
>   sphere{ Total[Var][0], Total[Var][1]
>           texture { Total[Tex][0]}}
> #declare  Total[Obj][1] =
>   box{    Total[Var][2], Total[Var][3]
>           texture { Total[Tex][1]}}
>
> // Show it:
> object {Total[Obj][0]}
> object {Total[Obj][1]}
>
> light_source {
>   <-20, 40, -20>
>   color rgb <1,1,1> }
> camera {
>   location <0,0,-3>
>   look_at 0 }
>
> // -------   End of code -----------------------------------------
>
> Why is this useful?
> You can give a macro in one name (Total) a couple
> of objects and all his variables and let it do something
> with it.
> For instance: the macro can reach the textures and
> can change them.
>
> I hope someone can use this.
>
> Jaap Frank

This is a very good explanation of arrays to me and I have been searching the
documentation and the net. It is making things very exciting for me. Thanks
Jaap!

[Mike Raiford] Re: How To do Proper Gamma in POV-Ray 3.7 [6051 days 23 hours and 44 minutes ago]

Tue, 8 Sep 2009 23:58:34 GMT

clipka wrote:
> 
> Choose a suitable output file gamma pre-correction; 2.20 is a very good choice,
> because it is a quasi-standard in the internet (being a compromise between
> typical PC and Mac display gamma values). Otherwise, choosing the same as your
> Display_Gamma is not a bad idea either, but be prepared for other people to
> complain about your shots being too dark or too washed-out.

BTW, a nice page to check your screen gamma:

http://www.lagom.nl/lcd-test/gamma_calibration.php

[Thomas de Groot] Re: How To do Proper Gamma in POV-Ray 3.7 [6129 days 11 hours and 54 minutes ago]

Tue, 23 Jun 2009 11:48:25 GMT

Ive,

I answered to your message last week (2 replies) but they could not be 
delivered for 5 days apparently. Don't know why.

Thomas

[Ive] Re: How To do Proper Gamma in POV-Ray 3.7 [6134 days 6 hours and 5 minutes ago]

Thu, 18 Jun 2009 17:37:39 GMT

clipka wrote:

> But I'm talking about solutions here, not root causes.

A solution does always require full knowledge of root causes, everything
else is 'just' a workaround. To be fair, I'm pretty sure you know that 
and given the rest of your posts it seems very much that you are looking 
for root causes yourself and just want to figure out everything by 
yourself. Thats absolutely fine with me.

-Ive

[clipka] Re: How To do Proper Gamma in POV-Ray 3.7 [6134 days 10 hours and 58 minutes ago]

Thu, 18 Jun 2009 12:45:00 GMT

Ive <"ive### [at] lilysoftorg"> wrote:
> >> why would this be a good choice?
> >
> > Because chances are that your standard image viewers don't care about gamma.
> >
> So what you mean is: it's a good choice because some people might use a
> crappy piece of software. Seems not like a good advice to me.

Note that I didn't call it a good choice - I called it not a bad choice. It
depends on what you want to do with the image. I warned about the consequences,
so I see no problem there.

> You are using the output file as input file so how can this be a proof
> that File_Gamma does effect the file used as image_map on input? Try a
> much simpler test by just using any jpeg file as image_map, use various
> settings for File_Gamma, keep Display_Gamma the same and compare.

That's a bad suggestion, because it will change the output file gamma, and
therefore make the output files not comparable anyway.

What I observed was that

(1) The output file didn't work as input file.

(2) Processing the file as described did the job, provided that the "display
curve" value used in the generation of the HDR file matched the File_Gamma
setting.

(3) When changing the File_Gamma between generation of the image and using it as
input file, the process worked fine when using the new File_Gamma setting, but
did not when using the old value.

The first is proof that POV-Ray's gamma handling is still far from ideal.

The second and third, combined, are proof that there is *some* effect of
File_Gamma on *input* files - even if this is the case only for HDR images.

Note that the effects observed when using the image as input are clearly
indicative of a problem either with the input material, or the process of
coverting the input material to linear color space.

If the fix depends on a particular POV-Ray setting at the time the file is used
as *input*, it is also indicative of this setting affecting the conversion of
input material to linear color space.

Any logical loopholes I'm missing here?

> > At any rate, even though it may appear queer (it does to me), the approach I
> > described *does* do some good.
> >
> > As you say yourself: Try it out!
>
> No need to try, it is obvious that this does work, I do not even see
> what seems so queer to you, I just mentioned some back drafts.

I wouldn't be that perplexed if the correction to be applied would depend on the
File_Gamma with which a file was *created* - but for some mysterious reason the
proper value to supply to HDRShop depends on the File_Gamma with which the file
is to be *used*.

> > Note however that this loss of dynamic range primarily applies to low color
> > component values in an otherwise comparatively bright color (for dark colors,
> > all components will be scaled up and E adjusted accordingly), and therefore has
> > not much effect on overall brightness or color anyway.
>
> Huh. There is no loss of dynamic range (how should it) there is 'just'
> some loss of information caused by the way data is stored.

If you interpret that information loss as noise, we're talking about dynamic
range again.

> > What's the point in having perfect ICC profile handling if POV-Ray gets the
> > gamma wrong.
>
> In many cases (and ALL files created by e.g. Photoshop, or MOST files as
> distributed within Poser or by DAZ) POV-Ray gets the gamma wrong
> *because* it cannot handle ICC color profiles.

May well be. But I'm talking about solutions here, not root causes. And if that
solution gets the Gamma fixed at the cost of the ICC information, then I say
it's a comparatively small price to pay. (Although of course I agree that it
would be better to have both right.)

> In fact POV-Ray only gets the gamma right when it uses a PNG file that
> does include a gamma-chunk (but ONLY in this case), the sRGB-chunk, the
> chromaticity-chunk and the ICC-chunk are ignored by POV-Ray and therefor
> it does not work correctly with a PNG as e.g. written by Photoshop CS3.
> And POV-Ray gets Radiance and OpenEXR right because it correctly assumes
> a linear color space there.

Interestingly enough, it even gets the gamma from its own output wrong.

> > (Whatever IC is, anyway...)
>
> And I was pretty sure you have visited my HP, maybe you should look
> around a bit next time when you are there... ;)

Now that Thomas pointed me there, I found out that I did see the site earlier.
"IC" didn't stick with me though.

[Ive] Re: How To do Proper Gamma in POV-Ray 3.7 [6134 days 11 hours and 48 minutes ago]

Thu, 18 Jun 2009 11:54:52 GMT

clipka wrote:

>> why would this be a good choice?
> 
> Because chances are that your standard image viewers don't care about gamma.
> 
So what you mean is: it's a good choice because some people might use a 
crappy piece of software. Seems not like a good advice to me.

> Setup was as follows:
> 
> - added another plane to that gamma test shot
> - mapped the (.png) *output* of a previous run to that plane
> - size the texture so that antialiasing would kick in on the checkered part
> 
> Antialias did kick in on the texture, and did blur the checkered parts to what I
> guess was a nice 50% grey - but the circle in the texture came out significantly
> brighter than the original sphere, and so did the upper parts of the texture,
> creating a prominent gradient.
> 
> Using the described procedure to convert to HDR did fix this issue. But the
> proper gamma to choose in HDRShop did *not* depend on the File_Gamma with which
> the file was *created*, but rather with which it was to be *used*.
> 
> 
> Try for yourself.
> 
> I guess that's why it is "File_Gamma", and not "Output_File_Gamma".
> 
You are using the output file as input file so how can this be a proof 
that File_Gamma does effect the file used as image_map on input? Try a 
much simpler test by just using any jpeg file as image_map, use various 
settings for File_Gamma, keep Display_Gamma the same and compare.

> I guess you're somewhat mistaken here: From all I see, the .HDR format *does*
> seem to be able to use a gamma encoding for the pixel values, as specified in
> the optional "GAMMA=..." header string. (I don't know what the default is, but
> it may well be 1.0, i.e. linear encoding.)
> 
Read the RADIANCE documentation about this, for short a RADIANCE HDR 
file is always linear no matter what.

> At any rate, even though it may appear queer (it does to me), the approach I
> described *does* do some good.
> 
> As you say yourself: Try it out!

No need to try, it is obvious that this does work, I do not even see 
what seems so queer to you, I just mentioned some back drafts.

> Note however that this loss of dynamic range primarily applies to low color
> component values in an otherwise comparatively bright color (for dark colors,
> all components will be scaled up and E adjusted accordingly), and therefore has
> not much effect on overall brightness or color anyway.

Huh. There is no loss of dynamic range (how should it) there is 'just' 
some loss of information caused by the way data is stored.

> What's the point in having perfect ICC profile handling if POV-Ray gets the
> gamma wrong.

In many cases (and ALL files created by e.g. Photoshop, or MOST files as 
distributed within Poser or by DAZ) POV-Ray gets the gamma wrong 
*because* it cannot handle ICC color profiles.
In fact POV-Ray only gets the gamma right when it uses a PNG file that 
does include a gamma-chunk (but ONLY in this case), the sRGB-chunk, the 
chromaticity-chunk and the ICC-chunk are ignored by POV-Ray and therefor 
it does not work correctly with a PNG as e.g. written by Photoshop CS3.
And POV-Ray gets Radiance and OpenEXR right because it correctly assumes 
a linear color space there.

> .... and probably doesn't work either (see above).

Nope. This definitely works (for exactly the same reason Radiance does 
work) and I have no intention of getting into a fight about this because 
both of our 'solutions' use the same workarounds to overcome some 
serious limitations POV-Ray has in this regard.

> 
> (Whatever IC is, anyway...)

And I was pretty sure you have visited my HP, maybe you should look 
around a bit next time when you are there... ;)

-Ive

[Thomas de Groot] Re: How To do Proper Gamma in POV-Ray 3.7 [6134 days 12 hours and 6 minutes ago]

Thu, 18 Jun 2009 11:36:19 GMT

"clipka" <nomail@nomail> schreef in bericht 
news:web.4a3a19c5b683ece6e01952250@news.povray.org...
>
> (Whatever IC is, anyway...)
>
>
http://www.lilysoft.org/IC/ic_index.htm
It can nicely be used instead of HDR-Shop, which (imo) asks to many private 
information before downloading....

Thomas

[clipka] Re: How To do Proper Gamma in POV-Ray 3.7 [6134 days 12 hours and 58 minutes ago]

Thu, 18 Jun 2009 10:45:00 GMT

Ive <"ive### [at] lilysoftorg"> wrote:
> This is NOT a good test for gamma on a CRT monitor, where the influence
> of the dynamic quality of the signal while horizontal tracing is much
> greater than the actual gamma. Only horizontal lines should be used for
> dithering gray-shades on a CRT. I'm not so sure about TFT's but it might
> work there.

Agreed - for CRTs it's not ideal (but better than nothing); scaling the checker
pattern by <5,1,1> or something alike should help. For TFT's it does a pretty
good job - especially through the anti-aliasing, which in the upper part of the
image will blur some of the squares to 50% grey in a moiree-like fashion, giving
you prominent moiree-like effects if gamma isn't set properly.

> > (3) CHOOSE A PROPER OUTPUT FILE GAMMA
>
> > Otherwise, choosing the same as your
> > Display_Gamma is not a bad idea either,
>
> why would this be a good choice?

Because chances are that your standard image viewers don't care about gamma.

> > (5) FIX YOUR TEXTURES
> >
> > This is the trickiest part: By specifying File_Gamma, not only will POV-Ray
> > create output files with the corresponding gamma pre-correction, but it also
> > affects POV-Rays gamma handling of all *input* files!
>
> This is NOT true (for the current beta 32), please do check such things
> before stating them.

Be assured that it *is* true - I actually *tested* it.

Setup was as follows:

- added another plane to that gamma test shot
- mapped the (.png) *output* of a previous run to that plane
- size the texture so that antialiasing would kick in on the checkered part

Antialias did kick in on the texture, and did blur the checkered parts to what I
guess was a nice 50% grey - but the circle in the texture came out significantly
brighter than the original sphere, and so did the upper parts of the texture,
creating a prominent gradient.

Using the described procedure to convert to HDR did fix this issue. But the
proper gamma to choose in HDRShop did *not* depend on the File_Gamma with which
the file was *created*, but rather with which it was to be *used*.

Try for yourself.

I guess that's why it is "File_Gamma", and not "Output_File_Gamma".

> > - Identify all the *color* texture files you're working with. (Don't bother
> > about bump maps, specular maps or transparency maps; I guess they should be
> > ok.)
> >
> This greatly depends.

That's the "guess" part of my statement.

> > - Load each texture in HDRShop, which will prompt you for a gamma value
> > ("display curve"); choose the same value as your File_Gamma!
> >
> Huh? This does not make sense because when you choose file_gamma of
> let's say 1.0 (e.g. for OpenExr output - where btw. file_gamma is
> ignored by POV anyway 'cause HDR formats are per definition in linear
> color space) this will not help at all. Try it out!
> What should be done (if you go this route) select for e.g. JPEG files
> always gamma 2.2.

I guess you're somewhat mistaken here: From all I see, the .HDR format *does*
seem to be able to use a gamma encoding for the pixel values, as specified in
the optional "GAMMA=..." header string. (I don't know what the default is, but
it may well be 1.0, i.e. linear encoding.)

At any rate, even though it may appear queer (it does to me), the approach I
described *does* do some good.

As you say yourself: Try it out!

> > - Save the file in HDR format.
> >
> I guess you mean the RADIANCE format here, so be aware that this goes
> ahead with some loss of information because the RGBE storage format of
> RADIANCE will not cover the full (low) dynamic range of a 8 bit/sample
> image.

This is of course only true when using linear encoding. But yes, that's what
HDRShop outputs.

Note however that this loss of dynamic range primarily applies to low color
component values in an otherwise comparatively bright color (for dark colors,
all components will be scaled up and E adjusted accordingly), and therefore has
not much effect on overall brightness or color anyway.

> The more accurate OpenEXR is not supported by HDR-Shop and TIFF or PFM
> HDR formats are not supported by POV-Ray.

OpenEXR also has the disadvantage of being unavailable in out-of-the-box custom
builds of POV-Ray.

> Note also that HDR-Shop completely ignores any ICC color profile within
> JPEG - and these are very common for e.g. Poser textures and in many
> cases are NOT just sRGB profiles.

What's the point in having perfect ICC profile handling if POV-Ray gets the
gamma wrong.

> > I'm not sure what *exactly* this does, but it works; when placed in a scene with
> > ambient 1, the texture will now be output exactly as it was input. At last.
>
> I'm not sure about what exactly you are not sure here. You are just
> using a HDR image as texture map (that is - as already mentioned - in
> linear color space by definition) and POV will use it as it is.

The point is that the very same texture file - even when using HDR - will work
as a texture with some File_Gamma=... setting, but not with another.

> As an alternative what I do: I use IC to convert JPEG files to 8 or 16
> bit/sample PNG files.
> This has 3 advantages:
> - no loss of information.
> - ICC color profiles (and any other colorimetric information) is
> properly handled.
> - much smaller file size.

.... and probably doesn't work either (see above).

(Whatever IC is, anyway...)

[Ive] Re: How To do Proper Gamma in POV-Ray 3.7 [6134 days 15 hours ago]

Thu, 18 Jun 2009 08:43:12 GMT

clipka wrote:

> Gamma handling is still a difficult issue; here's how to approach it *properly*:
> 
> (1) MATCH YOUR DISPLAY
> 
> Make sure you have your Display_Gamma set to properly. The following test scene
> may help:
> 
> // Render with +w800 +h600 +am2 +r3 +a0.1
> 
> #if (version <= 3.6) global_settings { assumed_gamma 1.0 } #end
> 
> camera {
>   location  <0.0, 0.0, -4.0>
>   direction 1.5*z
>   right     x*image_width/image_height
>   look_at   <0.0, 0.0, 0.0>
> }
> 
> background { rgb 0.5 }
> 
> plane { -z, -1
>   texture {
>     pigment { checker color rgb 1 color rgb 0 scale .02 }
>     finish { ambient 1 diffuse 0 specular 0 }
>   }
>   rotate x*45
> }
> 
> sphere { 0.0, 1
>   texture {
>     pigment { color rgb 0.5 }
>     finish { ambient 1 diffuse 0 specular 0 }
>   }
> }

This is NOT a good test for gamma on a CRT monitor, where the influence 
of the dynamic quality of the signal while horizontal tracing is much 
greater than the actual gamma. Only horizontal lines should be used for 
dithering gray-shades on a CRT. I'm not so sure about TFT's but it might 
work there.


> (2) DO *NOT* ADJUST OUTPUT GAMMA IN YOUR SCENE FILE
> 
> Do not make use of the global "assumed_gamma" statement (or set it to 1.0 in
> versions prior to 3.7).
> 
Agreed.


> (3) CHOOSE A PROPER OUTPUT FILE GAMMA
> 
> Choose a suitable output file gamma pre-correction; 2.20 is a very good choice,
> because it is a quasi-standard 

not a 'quasi-standard' it IS the W3C standard.

>in the internet (being a compromise between
> typical PC and Mac display gamma values). 

that's just a myth but doesn't matter in this context

> Otherwise, choosing the same as your
> Display_Gamma is not a bad idea either,

why would this be a good choice?

> but be prepared for other people to
> complain about your shots being too dark or too washed-out.

Exactly.


> 1.00 (no gamma pre-correction) would seem like a good choice theoretically, but
> it's actually bad from a dynamics point of view.
> 
Ok.


> (4) FIX YOUR COLORS
> 
> Make sure *all* your individual color values are *NOT* gamma pre-corrected, but
> linear - which means that you usually will have to "fix" colors from external
> sources (e.g. colors picked from an image in Photoshop or the like). A macro
> should do the job (I didn't throw one together yet, because I usually do color
> tweaking in POV anyway).
> 
Right.

> 
> (5) FIX YOUR TEXTURES
> 
> This is the trickiest part: By specifying File_Gamma, not only will POV-Ray
> create output files with the corresponding gamma pre-correction, but it also
> affects POV-Rays gamma handling of all *input* files!

This is NOT true (for the current beta 32), please do check such things 
before stating them.


> Unfortunately, there's
> currently no mechanism to override this. Worse yet: Even a file created with
> POV-Ray itself may not work properly as an input file, even if created with the
> same File_Gamma settings!
> 
> The good news is, the issue can be worked around as follows:
> 
> - Identify all the *color* texture files you're working with. (Don't bother
> about bump maps, specular maps or transparency maps; I guess they should be
> ok.)
> 
This greatly depends.


> - Load each texture in HDRShop, which will prompt you for a gamma value
> ("display curve"); choose the same value as your File_Gamma!
>
Huh? This does not make sense because when you choose file_gamma of 
let's say 1.0 (e.g. for OpenExr output - where btw. file_gamma is 
ignored by POV anyway 'cause HDR formats are per definition in linear 
color space) this will not help at all. Try it out!
What should be done (if you go this route) select for e.g. JPEG files 
always gamma 2.2.

> - Save the file in HDR format.
>
I guess you mean the RADIANCE format here, so be aware that this goes 
ahead with some loss of information because the RGBE storage format of
RADIANCE will not cover the full (low) dynamic range of a 8 bit/sample 
image.
The more accurate OpenEXR is not supported by HDR-Shop and TIFF or PFM 
HDR formats are not supported by POV-Ray.
Note also that HDR-Shop completely ignores any ICC color profile within 
JPEG - and these are very common for e.g. Poser textures and in many 
cases are NOT just sRGB profiles.


> - In POV-Ray, use the HDR file instead of the original one.
> 
> I'm not sure what *exactly* this does, but it works; when placed in a scene with
> ambient 1, the texture will now be output exactly as it was input. At last.

I'm not sure about what exactly you are not sure here. You are just 
using a HDR image as texture map (that is - as already mentioned - in 
linear color space by definition) and POV will use it as it is.

As an alternative what I do: I use IC to convert JPEG files to 8 or 16 
bit/sample PNG files.
This has 3 advantages:
- no loss of information.
- ICC color profiles (and any other colorimetric information) is 
properly handled.
- much smaller file size.

As an important side note: I really mean 'use IC' not because I want to 
advertise it, it's not commercial anyway, but because a lot of other 
software will write PNG files that are not correctly interpreted by 
POV-Ray. Including e.g. Photoshop CS3 that does not add a gamma-chunk to 
the PNG file but uses the colorimetric-chunk instead - and this one is 
just ignored by POV-Ray (and BTW so is also the sRGB-chunk).


-Ive

[clipka] How To do Proper Gamma in POV-Ray 3.7 [6134 days 22 hours and 53 minutes ago]

Thu, 18 Jun 2009 00:50:00 GMT

Gamma handling is still a difficult issue; here's how to approach it *properly*:

(1) MATCH YOUR DISPLAY

Make sure you have your Display_Gamma set to properly. The following test scene
may help:

// Render with +w800 +h600 +am2 +r3 +a0.1

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

camera {
  location  <0.0, 0.0, -4.0>
  direction 1.5*z
  right     x*image_width/image_height
  look_at   <0.0, 0.0, 0.0>
}

background { rgb 0.5 }

plane { -z, -1
  texture {
    pigment { checker color rgb 1 color rgb 0 scale .02 }
    finish { ambient 1 diffuse 0 specular 0 }
  }
  rotate x*45
}

sphere { 0.0, 1
  texture {
    pigment { color rgb 0.5 }
    finish { ambient 1 diffuse 0 specular 0 }
  }
}


(2) DO *NOT* ADJUST OUTPUT GAMMA IN YOUR SCENE FILE

Do not make use of the global "assumed_gamma" statement (or set it to 1.0 in
versions prior to 3.7).


(3) CHOOSE A PROPER OUTPUT FILE GAMMA

Choose a suitable output file gamma pre-correction; 2.20 is a very good choice,
because it is a quasi-standard in the internet (being a compromise between
typical PC and Mac display gamma values). Otherwise, choosing the same as your
Display_Gamma is not a bad idea either, but be prepared for other people to
complain about your shots being too dark or too washed-out.

1.00 (no gamma pre-correction) would seem like a good choice theoretically, but
it's actually bad from a dynamics point of view.


(4) FIX YOUR COLORS

Make sure *all* your individual color values are *NOT* gamma pre-corrected, but
linear - which means that you usually will have to "fix" colors from external
sources (e.g. colors picked from an image in Photoshop or the like). A macro
should do the job (I didn't throw one together yet, because I usually do color
tweaking in POV anyway).


(5) FIX YOUR TEXTURES

This is the trickiest part: By specifying File_Gamma, not only will POV-Ray
create output files with the corresponding gamma pre-correction, but it also
affects POV-Rays gamma handling of all *input* files! Unfortunately, there's
currently no mechanism to override this. Worse yet: Even a file created with
POV-Ray itself may not work properly as an input file, even if created with the
same File_Gamma settings!

The good news is, the issue can be worked around as follows:

- Identify all the *color* texture files you're working with. (Don't bother
about bump maps, specular maps or transparency maps; I guess they should be
ok.)

- Load each texture in HDRShop, which will prompt you for a gamma value
("display curve"); choose the same value as your File_Gamma!

- Save the file in HDR format.

- In POV-Ray, use the HDR file instead of the original one.

I'm not sure what *exactly* this does, but it works; when placed in a scene with
ambient 1, the texture will now be output exactly as it was input. At last.

[Some Yahoo] tutorial: renaming each frame after render [6147 days 6 hours and 55 minutes ago]

Fri, 5 Jun 2009 16:48:16 GMT

I found this useful for creating an image name from a string created while rendering.

The string 'newname' is calculated during the parse.


//by Bryan Valencia
//POV-RAY v. 3.6
//Create and execute a DOS Batch command after each frame
//example


//works with the following line in the render ini file
//Post_Frame_Command=fix.bat %o

#declare cmd1=concat("del  \"",newname,"\"\n");
#declare cmd2=concat("ren %1  \"",newname,"\"\n");


#fopen myfile "fix.bat" write
#write(myfile, cmd1)
#write(myfile, cmd2)
#fclose myfile

[Jaime Vives Piqueres] Re: Chief Architect and POV-Ray [6243 days 11 hours and 37 minutes ago]

Sun, 1 Mar 2009 12:05:59 GMT

nemesis escribió:
> Way to go, Jaime!  Pure finesse.  Good to see there was a good reason to 
> ignorancia.org remain without updates as you were learning your way
> through the software...

   Thanks for the excuse, but I thought that I was simply being lazy... :)

> I've seen CA before and indeed the default renderings were appalling next
> to what users of other packages were getting from their default
> integrated renderers and it was like getting povray a bad name.  I hope
> the tutorial spreads and gets noted by CA users.

   Yeah... that was the point.

> This one looks friggin awesome: 
> http://www.ignorancia.org/uploads/chief-architect/wips/ventanal2-04.jpg

   ...apart from the terrific decoration, you mean? ;)

--
Jaime

[Jaime Vives Piqueres] Re: Chief Architect and POV-Ray [6243 days 11 hours and 40 minutes ago]

Sun, 1 Mar 2009 12:02:38 GMT

Warp escribió:

> I must confess those are some jaw-dropping images. Awesome work.
> 

   Thanks! ...I really put a lot of hours into this, but at least I learned a
lot of radiosity tricks which I'm going to publish separately, as they are
valid for any POV-Ray scene. Most of them are ways to avoid common radiosity
artifacts.

--
Jaime

[nemesis] Re: Chief Architect and POV-Ray [6244 days 23 hours and 3 minutes ago]

Sat, 28 Feb 2009 00:40:00 GMT

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> Here is a tutorial about using Chief Architect and POV-Ray to create
> decent architectural renderings:
>
> http://www.ignorancia.org/en/index.php?page=Chief_Architect

Way to go, Jaime!  Pure finesse.  Good to see there was a good reason to
ignorancia.org remain without updates as you were learning your way through the
software...

I've seen CA before and indeed the default renderings were appalling next to
what users of other packages were getting from their default integrated
renderers and it was like getting povray a bad name.  I hope the tutorial
spreads and gets noted by CA users.

This one looks friggin awesome:
http://www.ignorancia.org/uploads/chief-architect/wips/ventanal2-04.jpg

[Warp] Re: Chief Architect and POV-Ray [6245 days and 34 minutes ago]

Fri, 27 Feb 2009 23:08:50 GMT

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> Here is a tutorial about using Chief Architect and POV-Ray to create
> decent architectural renderings:

> http://www.ignorancia.org/en/index.php?page=Chief_Architect

  I must confess those are some jaw-dropping images. Awesome work.

-- 
                                                          - Warp

[Jaime Vives Piqueres] Chief Architect and POV-Ray [6245 days 1 hour and 18 minutes ago]

Fri, 27 Feb 2009 22:24:52 GMT

Here is a tutorial about using Chief Architect and POV-Ray to create
decent architectural renderings:

http://www.ignorancia.org/en/index.php?page=Chief_Architect

Chief Architect X1 is a professional home design software. It uses POV-Ray
as the internal raytracing engine, and also exports to POV format, but
standard results don't seem to be showing off the best POV-Ray can do. So I
had to develop an alternative method to put my usual tricks in action.

Please, point any errors or typos, make suggestions or criticism, and if you
are a CA user... please try it and report how it works for you.

Regards,

--
Jaime

[clipka] Re: Radiosity Voodoo - Volume 1: How Radiosity R... [6266 days 7 hours and 8 minutes ago]

Fri, 6 Feb 2009 16:35:00 GMT

"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> Just found this now. I am going to consult this in detail. Excellent work.
> Thank you very much indeed.

Well, I guess I need to post a revised version; some of the observations &
guesses turned out wrong, as I found out by trying to optimize the code
accordingly.

For example, to my great dismay the low error factor can *not* be used for the
same effect as nearest reuse count when alway sample is off.

I still don't really understand *why* that is though (or, to be precise, I do
understand why it can make *some* difference, but I have no clue why it gives
the results it does).

[Thomas de Groot] Re: Radiosity Voodoo - Volume 1: How Radiosity R... [6267 days 15 hours and 23 minutes ago]

Thu, 5 Feb 2009 08:19:31 GMT

Just found this now. I am going to consult this in detail. Excellent work. 
Thank you very much indeed.

Thomas

[clipka] Re: Radiosity Voodoo - Volume 1: How Radiosity R... [6282 days 6 hours and 8 minutes ago]

Wed, 21 Jan 2009 17:35:00 GMT

Christoph Hormann <chr### [at] gmxde> wrote:
> This is a very comprehensive description of radiosity workings in
> POV-Ray but i think you are mistaken about one central point:  The
> radiosity pretrace will not be able to (and was never designed to) take
> all samples necessary during pretrace in a real life scene.

It may not have been *designed* to do so, but for good quality it *must* do so
(at least to some good degree). Otherwise you get lots of artifacts everywhere
near new samples taken during final render, because some nearby pixels were
computed earlier, but would have been influenced by the new sample if it had
been there already.

There are a few things to note out here:

- When talking about samples *needed*, I mean needed by *algorithm*, not by
*theoretical* considerations.

- The algorithm in POV is designed so that it will enforce a certain minimum
effective radius of samples, so in this sense it will never *need* an infinite
number of samples.

- I'm advocating nothing more than *good* coverage, not a *perfect* one.

There's a point here to be made though, and it just gives me an idea how to
automatically get an exhaustive enough but not too slow pretrace:

Samples taken during final render that affect only a single pixel probably don't
hurt anyone. Artifacts appear only where samples are taken that should by
algorithm affect other pixels already calculated.

So there must be a way to use this fact to come up with a criterion when to stop
pretracing even though sample coverage doesn't seem to be rather incomplete yet.

Note however that just stopping pretrace at the final render's pixel size
doesn't suffice: on areas seen from a very shallow angle, a spot that still
needs samples may be "thin" enough on screen in one direction to slip through a
pixel-sized pretrace, but still "wide" enough in the other direction to do harm.

So the radiosity tracing code should report the "apparent" size of the largest
sample gathered for a pretrace ray (or some value directly enough related to
it), and if the pretrace finds that it needs to gather no more "oversized"
samples then it is (with a certain probability) safe to leave sampling in that
area to the final trace.

(I *love* having inspiring arguments with you, guys!)

[Christoph Hormann] Re: Radiosity Voodoo - Volume 1: How Radiosity R... [6282 days 16 hours and 13 minutes ago]

Wed, 21 Jan 2009 07:29:50 GMT

clipka schrieb:

> I guess it's time to sum up a few things I have learned both during
> experimenting with POV-Ray radiosity, and digging through (and tampering with)
> the source code. So here comes volume 1 of my "black magic" tome. I fear it's
> still as flawed as the 3.6 radiosity code was (I confess I didn't bother to
> read it again after hacking it in), but it may give you some insight already:
> 
> [...]

This is a very comprehensive description of radiosity workings in 
POV-Ray but i think you are mistaken about one central point:  The 
radiosity pretrace will not be able to (and was never designed to) take 
all samples necessary during pretrace in a real life scene.  The main 
reason is that a scene with edges and corners in the geometry (i.e. 
surfaces with infinite curvature) will require an infinite sample 
density at these corners and unless you do not shoot any camera rays 
during the final render pass that have not yet been traced during 
pretrace (and this usually always happens - aa, jitter) you will need 
additional samples in the render.  To avoid this practically you would 
have to raise the error_bound during final trace by a huge amount 
(possibly adaptively like possible in latest megapov).

-- Christoph

[clipka] Radiosity Voodoo - Volume 3: Odds And Ends [6303 days 7 hours and 13 minutes ago]

Wed, 31 Dec 2008 16:30:01 GMT

3.A Troubleshooting
    -------------------


smeared shadows:

horizontally smeared shadows are the results of samples being taken during the
final pass. This typically indicates that your pretrace is too coarse. Make sure
you have set "always_sample" to "off", and check your pretrace_end. You will
probably want to choose a smaller value (i.e. higher resolution), or increase
minimum_reuse.

Alternatively, you can render the scene twice, using the save_data keyword on
the first and load_data on the second run. Make sure to use exactly the same
settings, or you may end up with yet more samples to be taken during the second
run.


smooth meshes & triangles:

Radiosity is problematic with meshes and smooth triangles, as these objects'
effective normal differs from their true geometric normal.

Radiosity is designed to cope with effective normals differing from "raw"
geometric normals (e.g. due to bump mapping); however, the true geometric normal
is never reported by the mesh or triangle object in the first place, so
Radiosity never finds out about the discrepancy.

The problem results in radiosity samples occasionally picking up light from the
inside of a mesh, which may in turn be illuminated through radiosity samples on
the inside surface which happen to be picking up light from the outside.

As a workaround, use a recursion_limit of no more than 2. This should prevent
any light from leaking into closed meshes and back out again. Alternatively,
insert a slightly "slimmed down" copy of the mesh with a pitch black surface
texture.

To truly solve this issue, geometric shapes need to be extended by an interface
to report both the effective and true geometric normal of intersection points.


black splotches:

There is a bug in 3.6 and all prior versions (and a related flaw in 3.7.0 betas
up to .29) regarding the handling of max_trace_level during radiosity sampling,
almost inevitably causing stray black splotches, typically flocking near
reflective or refractive objects. The only reliable way to get rid of these is
to increase your scene's max_trace_level.


splotches in general:

Some people report that reducing both "count" and "error_bound" will help with
some very stubborn scenes.



    3.B Undocumented Details And Issues
    -----------------------------------


adaptive quality parameters:

Various quality settings are automatically reduced when taking "deeper"
radiosity samples. This includes the number of rays shot.

low_error_factor:

Contrary to documentation, this factor is effective during all pretrace steps,
not just the last one, and it affects error_bound, minimum_reuse, and a hard-
coded kind of "maximum_reuse" value.

Black Splotches:

There is a bug in 3.6 and all prior versions (and a related flaw in 3.7.0 betas
up to .29) regarding the handling of max_trace_level during radiosity sampling,
almost inevitably causing stray black splotches, typically flocking near
reflective or refractive objects. The only reliable way to get rid of these is
to increase your scene's max_trace_level.

Save/Load Limitation:

When saving previously gathered radiosity data, POV-Ray 3.6 only saves the "top-
level" samples. If the samples are not sufficient for the scene they are loaded
into, this will require a lot of "deeper" samples to be taken all over again.


---(End of Tutorial)---

[clipka] Radiosity Voodoo - Volume 2: The Parameters [6303 days 7 hours and 13 minutes ago]

Wed, 31 Dec 2008 16:30:00 GMT

2. The Parameters
    -----------------


material ambient and global ambient_light:

With radiosity used to compute indirect illumination, PoV-ray's classic ambient
mechanism is basically obsolete. The mathematical principles behind it, however,
are exactly what is needed to simulate objects that emit light, allowing them to
act as light sources for radiosity.

In scenes with conventional lighting, merely "spiced up" with radiosity for
indirect lighting, you will usually want to turn off the ambient mechanism, by
either specifying a global ambient_light value of 0, or setting all materials'
ambient value to 0. Or both, which is probably the best idea: Setting
ambient_light to 0 ensures that no material will emit light whatsoever without
having to update all the material library you may be using, while defining your
own materials with an ambient of 0 ensures that you can later use them again in
radiosity-only scenes.

In radiosity-only scenes, you need some objects to emit light, so your global
ambient_light must be nonzero (unless the only light source you will be using is
a sky sphere). For ease of use, a value of 1 is ideal, so that you can directly
control an object's emissive brightness by its material's ambient value.

Sometimes you may want to use materials from a library which were defined with a
nonzero ambient value for conventional lighting. In this case, you may resort to
using a very small global ambient_light (e.g. 0.001), and turning up your light-
emitting objects' ambient value accordingly (multiply by 1000 in this case),
although I recommend to avoid such quirks. Note also that you cannot assign an
ambient value to a sky_sphere.


global max_trace_level:

In radiosity-only scenes, you want to set this a good deal higher than normal -
Otherwise you *will* end up with stray dark splotches, that can't be really
cured by any other means.


adc_bailout:

This parameter specifies an alternate ADC bailout value to use when tracing a
radiosity sample ray.

In POV 3.6 and earlier, and 3.7 beta versions up to .29, contrary to
documentation this value was actually implemented as a factor to multiply the
standard value with; e.g. if your global adc_bailout was set to 0.01 and your
radiosity adc_bailout was set to 0.02, you would have an effective ADC bailout
value of 0.0002 during radiosity tracing, rendering this mechanism mostly
useless.


always_sample:

When set to "off", this effectively sets "nearest_count" to 1 during the final
render, so that new radiosity samples are only taken if they are absolutely
needed.

For quick test renders, you may want to set this parameter to "on" to get away
with a faster pretrace (or none at all).

Othrwise, you will definitely want to set this parameter to "off", as new
samples taken during final trace may cause visible "jumps" in color or
brightness between areas rendered before and after the new sample was taken.

(Note that I recommend to set "nearest_count" to 1 anyway, which leaves this
option without any effect.)


count:

This parameter is fairly straightforward: It specifies how many rays are shot
for every radiosity sample.

If your scene is quite homogenous regarding color and brightness, you will
probably want to set this parameter fairly low to get a fast render.

If your scene has some comparatively small features of distinct color or
brightness, make sure you set this parameter fairly high, otherwise those
features will be totally missed for some radiosity samples, while having too
much impact on samples if they happen to be hit, resulting in visible splotches.
As a rule of thumb, set this value high enough so that every prominently colored
feature will typically be hit by multiple rays. Note however that having
a lot of such objects of similar color allows you to reduce the count again.

If you use a High Dynamic Range light probe for illumination with very small
areas contributing very much of the total brightness, make sure to crank the
count parameter up to maximum, and/or use a heavily blurred version of the
probe. I recommend the latter for speed considerations, but it requires either
that your light probe itself is not visible in the background or in reflections,
that you use strong focal blur, or that you use a version of PoV-ray that
supports the no_radiosity flag so that you can set up one sky sphere for
radiosity and another for reflections and background. Using a radiosity pre-
render with a blurrier sky texture may be a fallback option, but since the final
render may need to take additional samples despite best efforts, I recommend
some other approach if possible.


low_error_factor:

This parameter determines the relation between the density of samples taken
during pretrace, and the density of samples required for the final render. More
precisely, it specifies a scaling factor for the distance at which a sample is
still considered re-usable.

You may normally want to set this parameter to a value somewhere near 0.5, which
ensures that even if the pretrace missed some points, these will still be
covered by nearby samples instead of requiring additional ones being taken
during the final render.

If your scene is radiosity-lit with small light sources, and the maximum of 1600
sample rays turns out to be still insufficient, you may additionally want to
reduce low_error_factor. The effect of reducing low_error_factor by a certain
factor is somewhat similar to further increasing the count by the square of that
factor, except that it may give a slightly better quality at slightly lower
performance, and may require a higher-resolution pretrace.

Note that nearest_count does something similar, but not as good.


minimum_reuse:

The mechanism behind this parameter sacrifices quality to gain speed, by
enforcing a certain minimum distance between radiosity samples, depending on how
far away (and therefore how small in the final image) they are. The
minimum_reuse specifies the ratio between the minimum distance of two radiosity
samples and the camera distance.

If your scene contains only large structures, you will probably want to set this
parameter fairly high to get a fast render.

However, if your scene contains lots of small details and you rely solely on
radiosity for lighting, make sure you set this parameter low enough, using the
following formula, where detail_size is the size of your smallest detail on
screen:

minimum_reuse = 0.5 * (detail_size / image_width) * tan (camera_angle/2)

Aside from improving render speed (including getting away with a lower-
resolution pretrace), there is no benefit of setting this parameter to a high
value.


nearest_count:

This parameter specifies how many samples must be "within reach" to re-use them.
However, this does not place any upper limit on the number of samples actually
re-used.

Note that you normally want this effectively turned off during the final render
to prevent additional samples from being taken, by specifying "always_sample
off".

I recommend always setting this parameter to 1, as a higher sample density can
be achieved just as well by lowering low_error_factor, which has the benefit of
enforcing a more homogenous sample distribution, while nearest_count may allow
samples to "flock", thereby somewhat reducing the benefit.

Note that increasing nearest_count by a certain factor has the same effect on
overall sample density as dividing low_error_factor by the root of that factor.

(It seems that previous versions of POV-Ray used this value to place an *upper*
limit on the number of samples re-used for a certain point, which may explain
the existence of this otherwise obsolete parameter.)


pretrace_start & pretrace_end:

The pretrace_end value should be low enough to allow all necessary samples to be
taken during pretrace already. I recommend using 1/min(image_width,image_height)
if you are patient enough, which causes the last pretrace to be taken at the
same resolution as the main render; otherwise set it according to the following
formula:

pretrace_end = 0.5 * minimum_reuse / tan (camera_angle/2)

If you choose a high nearest_count to work around the 1600 sample ray limit,
make sure to further reduce this value according to the following formula:

pretrace_end = 0.5 * minimum_reuse / ( tan (camera_angle/2) * sqrt
(nearest_count) )

This makes sure that you get the full number of samples for every pixel.

For pretrace_start, I recommend using some power-of-2-fold of the value you use
for pretrace_end, especially if you intend to go for a full-resolution last
pretrace. Basically, any power of 2 will do, although it should not be too low,
especially if you have chosen a high nearest_count. I suggest going for
dramatically high values, as this will ensure the most homogenous distribution
of samples.


recursion_limit:

This parameter specifies how many "generations" of samples will be taken.

For rather open scenes, a value of 1 should usually suffice. If you have many
dark edges and hollows though, you may want to set this to 2 or even 3 to shed
light into all corners.

Note however that this may also increase the risk of light "leaking" through
thin walls, especially at corners.


---(End of Volume 2)---

[clipka] Radiosity Voodoo - Volume 1: How Radiosity Reall... [6303 days 7 hours and 18 minutes ago]

Wed, 31 Dec 2008 16:25:01 GMT

I guess it's time to sum up a few things I have learned both during
experimenting with POV-Ray radiosity, and digging through (and tampering with)
the source code. So here comes volume 1 of my "black magic" tome. I fear it's
still as flawed as the 3.6 radiosity code was (I confess I didn't bother to
read it again after hacking it in), but it may give you some insight already:


    1. How Radiosity Really Works
    -----------------------------


The Basics:

Radiosity is intended to replace PoV-ray's classic material-based approach of
modeling ambient illumination with a more realistic geometry-based model, to
take into account diffusely reflected (or possibly emitted) light from other
objects, giving a non-uniform ambient illumination.

Although it is correct to speak of ambient illumination here, I will avoid this
term to avoid its ambiguity in the PoV-ray radiosity world, and instead speak of
"indirect illumination".

The very basic concept is that in order to get the indirect illumination for a
certain point, you would shoot a vast number of rays in virtually every
direction, checking how much light would come from whatever object happens to be
hit.

As a straightforward implementation of this concept would lead to incredibly
long render times, it is of course not feasible without optimizations.
Furthermore, there are additional details to consider.


Radiosity Samples:

The main optimization is to not compute the indirect illumination for every
point encountered, but to take only representative "samples", and to determine
the actual illumination for any specific point by interpolating between nearby
samples. This can be done because in the real world this indirect illumination
typically changes only very gradually.

In PoV-ray terms, this interpolation is called "re-use" of samples.


Re-Use:

Whether a sample can be re-used for a certain point in question depends on a
variety of geometric factors, the main of which are:

* The overall distance to nearby geometric features: This comes as a byproduct
of the shooting of rays for the sample, and is simply an average of the
distances the rays have travelled before hitting an object. A "harmonic mean" is
used (the inverse of the arithmetic mean of the inverses) so that nearby objects
have a higher influence on this value.

* The direction and distance to the nearest object: This comes as a byproduct of
the shooting of rays as well. A sample is deemed less re-usable for points in or
near this direction.

* The curvature of the object: This is measured by the difference in the normal
vectors of the sample and the point in question.

From all these factors, a weight is computed for the sample, and all samples
interpolated according to their weight.

(In practice of course, there are several mechanisms in place to quickly filter
out samples that cannot possibly have a nonzero weight for a given point.)


Test Ray Pattern:

Shooting rays in virtually every direction is, of course, virtually impossible.
Therefore, only a limited number of rays can be shot, and their directions
should be chosen carefully. The algorithm to choose the number of rays should
ideally satisfy the following criteria:

* The algorithm should be fast. Doing things the stupid way but fast may
actually be more clever than spending time on finding the best way.

* The rays should be biased towards the normal, to accomodate for the fact that
light coming in at shallower angles contributes less to the overall brightness
of a surface. This could be modeled by multiplying the brightness of each ray
with a corresponding correctional term, but modeling it instead by biasing the
distribution of the rays is much more elegant, because it can do without the
correctional term (which would be a trigonometric function and therefore quite
expensive in terms of computng time), and also does not waste time on shooting
many rays in directions that contribute few to the total brightness.

* Aside from this bias, the rays should be distributed very uniformly; first to
not waste computing time on rays that happen to be almost identical and
therefore are likely to contribute the same brightness and color; and second to
prevent parts of the scene to have a higher impact on the computed brightness
(because they happen to receive more rays) than others.

* The algorithm should provide a way to control the total numbers of rays shot.

* The algorithm should be non-random, to be suitable for animations.

(For certain reasons it would be desirable to have a certain random element in
the distribution of rays; however, this typically collides with multiple of the
above criteria and is therefore ignored in PoV-ray.)

PoV-ray uses a precomputed table of directions specially designed to meet all of
the above. However, the maximum number of rays shot is limited by the size of
the table, which contains "only" 1600 entries.


Light Sources:

Radiosity significantly changes how lighting works, and allows for objects
themselves to act as light sources.

PoV-ray combines radiosity with its classic lighting model. This allows for
beginners to first experiment with it by just "pimping up" classically-lit
scenes with radiosity a bit. However, radiosity can also be used stand-alone
(although this sacrifices soft highlights unless one is familiar with other
advanced techniques), by making objects themselves emit light. Details how to do
this are mentioned later.


Recursions:

When PoV-ray starts taking radiosity samples, there is a hen-and-egg problem: To
determine the indirect illumination at a sample point, it needs to shoot rays
and determine how much light comes from that direction - which in turn may
depend on the indirect illumination there, and due to a current lack of
(completed) samples cannot be computed right now.

PoV-ray solves this problem in a pragmatic way, by doing a limited-depth
recursion, keeping track of separate sets of samples for each level of depth.

The levels of depth can be seen as some kind of "generations" (although the
individual generations are not computed in sequential order, but rather as
needed):

When shooting rays for a first-generation sample, the world is assumed do be
devoid of any indirect illumination, and any object hit is assumed to be
illuminated only from classic lighting, maybe reflect or refract, and maybe emit
light itself.

When shooting rays for the second-generation sample, the world is assumed to be
indirectly illuminated as described by the first-generation samples.

When shooting rays for the third-generation sample, the world is assumed to be
indirectly illuminated as described by the second-generation samples - and so
on, until the desired number of generations has been reached.

(Note that these "generations" are *not* coincidental with radiosity pre-trace
passes.)


Pre-Trace:

The intention of the radiosity sampling pre-trace is to take all samples that
the final render may ever need, to avoid any new samples to be taken during the
final render, as this may cause visible "jumps" in color or brightness between
areas rendered before and after the new sample was taken.

To make sure the collection of samples is dense enough, by default the pre-trace
actually takes more samples than it would normaly deem necessary. This is
achieved by running multiple passes, and collecting additional samples on each
pass until it finds a certain minimum number of samples "within reach" of each
spot it examines.

To make sure that the distribution of samples is comparatively homogenous, the
pre-trace starts with a very coarse pass, and gradually increases in resolution.
In addition, the pre-sampling uses a good deal of jitter to avoid any clear
patterns in the sampling distribution.

The pre-trace may not always be successful at achieving these goals, so
sometimes taking new samples during the final trace cannot be totally avoided.


--- (End of Volume 1) ---

[Hadmut] Shiny buttons? [6793 days 15 hours and 12 minutes ago]

Wed, 29 Aug 2007 08:30:56 GMT

Hi,

is there a tutorial about how to make shiny buttons (e.g. for web pages)
with povray? (There are tutorials for programs like photoshop or gimp,
but these just use fake reflections etc.)

regards
Hadmut

[em-sigma] Re: Drawing 3D text [6801 days 13 hours and 38 minutes ago]

Tue, 21 Aug 2007 10:05:00 GMT

"carleton" <nomail@nomail> wrote:
> Hi folks, I am starting a one man software company and am looking for a
> logo.  I saw this the other day:
>
> http://www.phplivesupport.com/pics/screenshots/setup_trackit.gif
>
> and realized it was EXACTLY what I was looking for, except rather then a
> dollar sign, I wanted two capital letter P's.  Years back (around 1992) I
> played with povray and thought it would be the ideal tool to create such a
> graphic, but it has been so long I thought I might see if anyone here might
> be able to help me setup on a script to create something basic like this.
>
> Carleton


Hello Carleton,

I think it is not so difficult to set up a scene with POVRAY to get
something similar.

Just use a basic scene and add 2 lines with a text object, e.g.

text { ttf "timrom.ttf", "PP", 0.5, 0 pigment { White }}
text { ttf "wingdng3.ttf", "Q", 0.05, 0 rotate <90,45,0> scale 3 translate
<-1.25,0.35,0.25> pigment { White }}


A little tweaking will be necessary, but that won't be too hard to do.

Greetings, em-sigma

[carleton] Drawing 3D text [6814 days 12 hours and 38 minutes ago]

Wed, 8 Aug 2007 11:05:00 GMT

Hi folks, I am starting a one man software company and am looking for a
logo.  I saw this the other day:

http://www.phplivesupport.com/pics/screenshots/setup_trackit.gif

and realized it was EXACTLY what I was looking for, except rather then a
dollar sign, I wanted two capital letter P's.  Years back (around 1992) I
played with povray and thought it would be the ideal tool to create such a
graphic, but it has been so long I thought I might see if anyone here might
be able to help me setup on a script to create something basic like this.

Carleton

[kurtz le pirate] Re: POV-Ray 3.6 Complete Textures Guide [6815 days 6 hours and 8 minutes ago]

Tue, 7 Aug 2007 17:34:41 GMT

In article <web.46b7cb0c43a20d46d6f7de180@news.povray.org>,
 "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!


good job. have you see : 
  <http://www.rene-schwietzke.de/povray/texlib/index.html>

-- 
klp

[Jim Henderson] Re: POV-Ray 3.6 Complete Textures Guide [6815 days 19 hours and 30 minutes ago]

Tue, 7 Aug 2007 04:12:19 GMT

Very handy, thanks!

I've been meaning to improve my skills at creating textures, but myself 
don't understand a lot of the basics, and seeing these examples will most 
certainly help. :-)

Jim

[Pook] POV-Ray 3.6 Complete Textures Guide [6815 days 22 hours and 8 minutes ago]

Tue, 7 Aug 2007 01:35: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!

[Mike Williams] Re: spiral [6833 days 16 hours and 22 minutes ago]

Fri, 20 Jul 2007 07:20:40 GMT

Wasn't it zeroin23 who wrote:
>Hay is this a helix?

The path of a thin strip of that is a helix, e.g. if you set the limits
to  <pi,0> <8*pi,0.01>  then you get a thin line that follows a helical
path.

The problem is that the width of the ribbon consists of points that are
always in the positive x and y directions, which isn't like anything
you'd expect.

This gives a ribbon that has a surface parallel to the axis. The
ribbon's width is in the z direction.
    function {sin(u)}
    function {cos(u)}
    function {u+v}

This gives a ribbon that has a surface that is perpendicular to the
axis. The ribbon's width is outwards from the centre in the direction
<sin(u),cos(v)>
    function {sin(u)*(1+v)}
    function {cos(u)*(1+v)}
    function {u}

-- 
Mike Williams
Gentleman of Leisure

[zeroin23] Re: spiral [6833 days 17 hours and 13 minutes ago]

Fri, 20 Jul 2007 06:30:02 GMT

Hay is this a helix?

The parametric v controls the width of ribbon while u controls the number of
turn. I am checking as for some camera location, it looks like a helix, but
location <-10, 10, -30> it looked really weird.

I am using this for my alpha protein structure.
Any clues for rendering beta sheets?

thx

======================
 #include "colors.inc"
  background{White}
  camera {
    angle 20
    location <10, 10, -30>
    look_at <0, 1, 0>
  }
  light_source { <20, 20, -20> color White }
  parametric {
    function {sin(u)+v}
    function {cos(u)+v}
    function {u}

    <pi,0>, <8*pi,0.6>
    //contained_by { sphere{0, 10} }
    contained_by{box{-20,20}}
    max_gradient 0.1
    accuracy 0.0001
    precompute 10 x,y,z
    pigment {rgb <1,0,0>}
  }

[sahraoui] Re: spiral [6942 days 4 hours and 48 minutes ago]

Mon, 2 Apr 2007 18:55:01 GMT

which thread. I did not see your posting.
Are you talking about the f_helix?
Again neither param.inc nor f_helix let you
play with the origin of the helix.
Like I said to mike williams,
you cannot put thesee helices on a lattice.
I can send you the image of the helices on
a square lattice but did not put the sinus
in effect.

thanks

"Grassblade" <nomail@nomail> wrote:
> "sahraoui" <sch### [at] uiucedu> wrote:
> > Thanks for the message.
> > Actually I like the power of parametric objects.
> > I am not sure however how to make these dotes spheres howeve
> > Also in param.inc there was a line
> > #include makemesh.inc
> > but I am not sure where is that include file.
> >
> > thanks
> I just posted the parametric equation for the "straight" tubular helix on
> your other thread. Makemesh.inc should be in Ingo's zip. To run param.inc
> you need to tell POV-ray where to look for makemesh.inc, you can either
> drop all the inc's in POVray/ include directory, or edit povray.ini in the
> renderer directory to point to whatever directory you unzipped the param
> tool in. This is in the Windows version, I do not know if or how the Mac
> version differs.

[sahraoui] Re: spiral [6943 days 7 hours and 48 minutes ago]

Sun, 1 Apr 2007 15:55:01 GMT

Mike Williams <nos### [at] econymdemoncouk> wrote:
> Wasn't it sahraoui who wrote:
> >Hi Mike
> >
> >Thanks a lot for the file.
> >Actually i was trying that same loop
> >but got entangled inside and got the code
> >to run forever until I saw your message. thanks again.
> >The parametric stuff did not work for some reason.
> >
> >Now here is the thing. What you sent me make the spiral follow
> >the sinus line indeed but BUT every "circle" of the spiral
> >is NOT perpendicular to the line of the sinus but it
> >is always perpendicular to the horizontal.
> >In other words your code produce a helix who axis is
> >always parallel to the horizontal
> >but what would be perfect is a helix whose axis
> >is parallel to the sinus fonction that follows, andn that I beleive
> >is not a piece of cake...but may be not for you Oh gentleman of Leisure
>
> The basic strategy would be to tilt each "circle" by an amount that
> varied with the cosine. The tricky bit would be to calculate the correct
> value for the amount of tilt ("B" in the following code) from the other
> values.
>
> #declare R1=1.5;
> #declare F1=1.2;
> #declare R2=0.15;
> #declare N=100;
> #declare H=10;
>
> #declare F2=0.2;
> #declare A=0.5;
> #declare B=-0.2;
>
> sphere_sweep {
>   b_spline
>   100,
>   #declare Y=0;
>   #while (Y<N)
>     #declare X=R1*sin(F1*Y)+A*sin(F2*Y);
>     <X, Y*H/N-H/2 + B*X*cos(F2*Y) , R1*cos(F1*Y)>,R2
>     #declare Y=Y+1;
>   #end
>   pigment {rgb 1}
> }
>
> >embedding that into a larger sheet of beads would be quite a challenge too.
>
> In what way?
>


Here what I am trying to do;
What follow are not very optimized. Some parameters
were there but they are superfluous now...




#declare Ball =
 sphere{<0,0,0>,0.15
   texture{
     pigment{color rgb<1,0.65,0.0>}
     finish {diffuse 0.9 phong 1}

    }// end of texture
 // texture component
// defines an object's surface bumpiness

 }// end of sphere



#declare rods =
cylinder{<0,0,0>,<0,2,0>,0.1
//cylinder {
 // -0.01*x,  0.02*x,  1
   open
texture{
    pigment{color rgb<1,0,0>}
   normal { bumps 0.5 scale <0.005,0.25,0.005>}
   finish {diffuse 0.9 phong 1}
    }


}



#declare E = 5;
#declare Z = -E;    // start value Z
#declare EndZ = E;  // end value Z
#declare Step = 0.2;// step value
//------- loop start Z:
#while ( Z < EndZ + Step)

  #declare X = -E; // start value X
  #declare EndX = E; // end value X
  //------ loop start X:
  #while ( X < EndX + Step)

  object{ Ball
  translate<X,0.1*X*sin(2*Z)
              +0.1*Z*cos(2*X),Z>}
object{ rods
translate<X,0.1*X*sin(2*Z)
              +0.1*Z*cos(2*X),Z>}

  #declare X = X+Step;//next X value
  #end // --------------- loop end X

#declare Z = Z+Step;//next Z value
#end // --------------- loop end Z


#declare Ball =
 sphere{<0,2,0>,0.15
   texture{
     pigment{color rgb<1,0.65,0.0>}
     finish {diffuse 0.9 phong 1}
    }// end of texture
 }// end of sphere

#declare E = 5;
#declare Z = -E;    // start value Z
#declare EndZ = E;  // end value Z
#declare Step = 0.2;// step value
//------- loop start Z:
#while ( Z < EndZ + Step)

  #declare X = -E; // start value X
  #declare EndX = E; // end value X
  //------ loop start X:
  #while ( X < EndX + Step)

  object{ Ball
  translate<X,0.1*X*sin(2*Z)
              +0.1*Z*cos(2*X),Z>}

  #declare X = X+Step;//next X value
  #end // --------------- loop end X

#declare Z = Z+Step;//next Z value
#end // --------------- loop end Z


//THis is the water sheet in blue made of cylinders

#declare rods =
cylinder{<0,2.05,0>,<0,2.5,0>,0.11
//cylinder {
 // -0.01*x,  0.02*x,  1
   //open
texture{
    pigment{color rgb<0,0.3,1>}
   normal { bumps 0.5 scale <0.005,0.25,0.005>}
   finish {diffuse 0.9 phong 1}
    }
// texture component
// defines an object's surface bumpiness


}

//this loop will make the water sheet

#declare E = 5;
#declare Z = -E;    // start value Z
#declare EndZ = E;  // end value Z
#declare Step = 0.2;// step value
//------- loop start Z:
#while ( Z < EndZ + Step)

  #declare X = -E; // start value X
  #declare EndX = E; // end value X
  //------ loop start X:
  #while ( X < EndX + Step)

object{ rods
translate<X,0.1*X*sin(2*Z)
              +0.1*Z*cos(2*X),Z>}

  #declare X = X+Step;//next X value
  #end // --------------- loop end X

#declare Z = Z+Step;//next Z value
#end // --------------- loop end Z

//This is the next monolayer

#declare Ball =
 sphere{<0,2.55,0>,0.15
   texture{
     pigment{color rgb<1,0.65,0.0>}
     finish {diffuse 0.9 phong 1}
    }// end of texture
 }// end of sphere

#declare E = 5;
#declare Z = -E;    // start value Z
#declare EndZ = E;  // end value Z
#declare Step = 0.2;// step value
//------- loop start Z:
#while ( Z < EndZ + Step)

  #declare X = -E; // start value X
  #declare EndX = E; // end value X
  //------ loop start X:
  #while ( X < EndX + Step)

  object{ Ball
  translate<X,0.1*X*sin(2*Z)
              +0.1*Z*cos(2*X),Z>}

  #declare X = X+Step;//next X value
  #end // --------------- loop end X

#declare Z = Z+Step;//next Z value
#end // --------------- loop end Z

//this will make the aliphatic layers

#declare rods =
cylinder{<0,2.7,0>,<0,4.7,0>,0.11
//cylinder {
 // -0.01*x,  0.02*x,  1
   //open
texture{
    pigment{color rgb<1,0,0>}
   normal { bumps 0.5 scale <0.005,0.025,0.005>}
   finish {diffuse 0.99 phong 1}
    }
// texture component
// defines an object's surface bumpiness


}



#declare E = 5;
#declare Z = -E;    // start value Z
#declare EndZ = E;  // end value Z
#declare Step = 0.2;// step value
//------- loop start Z:
#while ( Z < EndZ + Step)


  #declare X = -E; // start value X
  #declare EndX = E; // end value X
  //------ loop start X:
  #while ( X < EndX + Step)

object{ rods
translate<X,0.1*X*sin(2*Z)
              +0.1*Z*cos(2*X),Z>}

  #declare X = X+Step;//next X value
  #end // --------------- loop end X

#declare Z = Z+Step;//next Z value
#end // --------------- loop end Z

//This is the next monolayer with links between some spheres

//THis IS THE SPIRALs

//spiral

#declare Amplitude = 0.160 ;
#declare Minimal_Length   = 0.80 ;
#declare Middle_Length    = Amplitude + Minimal_Length ;  //superfluous
parameter



#declare Sp_Length = Middle_Length+Amplitude*sin((clock+Time_test)*2*pi);
#declare Spiral  =  //--------------------------------- the spiral
union{
 #local N_per_Rev = 125;   // Number of Elements per revolutions
 #local N_of_Rev  = 8.00;  // Total number of revolutions

 #local H_per_Ref = Middle_Length / N_of_Rev;
 #local Nr = 0;                          // start loop
 #while (Nr< N_per_Rev*N_of_Rev)
   sphere{ <0,4.8,0>,0.025
           translate<0.05, 0, -Nr*H_per_Ref/N_per_Rev>
           //rotate<0,0,  Nr * 360/N_per_Rev>
          rotate<0,0,Nr*360/N_per_Rev>
           texture{ Chrome_Metal
                    finish {ambient 0.15 diffuse 0.85 phong 1}}
         }
 #local Nr = Nr + 1;    // next Nr
 #end // --------------------------------- end of loop


} // end of union  -------------------------------- end of spiral


//--------------------------------------------------------------------- end





#declare Ball =
 sphere{<0,4.8,0>,0.15
   texture{
     pigment{color rgb<1,0.65,0.0>}
     finish {diffuse 0.9 phong 1}
    }// end of texture
 }// end of sphere

#declare links =
cylinder{<0,4.8,0>,<0.,4.8,0.2>,0.05


texture{
    pigment{color rgb<1,1,0>}
   normal { bumps 0.5 scale <0.005,0.25,0.005>}
   finish {diffuse 0.9 phong 1}
    }
// texture component
// defines an object's surface bumpiness


}


#declare E = 5;
#declare Z = -E;    // start value Z
#declare EndZ = E;  // end value Z
#declare Step = 0.2;// step value
//------- loop start Z:
#while ( Z < EndZ + Step)

  #declare X = -E; // start value X
  #declare EndX = E; // end value X
  //------ loop start X:
  #while ( X < EndX + Step)

  object{ Ball
  translate<X,0.1*X*sin(2*Z)
              +0.1*Z*cos(2*X),Z>}
              object{Spiral
              translate<X,0.1*X*sin(2*Z)
              +0.1*Z*cos(2*X),Z>}

  #declare X = X+Step;//next X value
  #end // --------------- loop end X

#declare Z = Z+Step;//next Z value
#end // --------------- loop end Z

//This is the network of spring
//first we construct a helix


#declare E = 5;
#declare Z = -E;    // start value Z
#declare EndZ = E;  // end value Z
#declare Step = 0.5;// step value

#while ( Z < EndZ + Step)

  #declare X = -E; // start value X
  #declare EndX = E; // end value X

  #while ( X < EndX + Step)



  #declare X = X+Step;//next X value
  #end // --------------- loop end X

#declare Z = Z+Step;//next Z value
#end // --------------- loop end Z


and the last sheet should have random spring attached to the beads.
Meaning that if you span the sheet you find five consecutive spring
connecting
the beads and sometimes you find less or more..like this:

#declare Rnd_1 = seed (1153);

#declare Ball =
  sphere{<0,0,0>,0.25
    texture{
      pigment{color rgb<1,0.8,0>}
      finish {diffuse 0.9 phong 1}
    }// end of texture
  }// end of sphere

//------------------------------------
//----------------
#declare links =
cylinder{<0,0,0>,<0.59,0,0.0>,0.051

texture{
    pigment{color rgb<1,1,0>}
   //normal { bumps 0.5 scale <0.005,0.25,0.005>}
   finish {diffuse 0.19 phong 1}
    }



}

//end of rods

//spiral

#declare Amplitude = 0.160 ;
#declare Minimal_Length   = 0.80 ;
#declare Middle_Length    = Amplitude + Minimal_Length ;




#declare Sp_Length = Middle_Length+Amplitude*sin((clock+Time_test)*2*pi);
#declare Spiral  =  //--------------------------------- the spiral
union{
 #local N_per_Rev = 125;   // Number of Elements per revolutions
 #local N_of_Rev  = 8.00;  // Total number of revolutions

 #local H_per_Ref = Middle_Length / N_of_Rev;
 #local Nr = 0;                          // start loop
 #while (Nr< N_per_Rev*N_of_Rev)
   sphere{ <0,0,0>,0.025
           translate<0.05, 0, -Nr*H_per_Ref/N_per_Rev>//


          rotate<0,0,Nr*360/N_per_Rev>
           texture{ Chrome_Metal
                    finish {ambient 0.15 diffuse 0.85 phong 1}}
         }
 #local Nr = Nr + 1;    // next Nr
 #end // --------------------------------- end of loop


} // end of union  -------------------------------- end of spiral



//--------------------------------------------------------------------- end



#declare X=-5;

#declare EndX = 5;  //   end value X
#declare Step = 0.85;// step value

#while ( X < EndX + Step)//loop start
  object{ Ball translate <X,0,0>}

#declare X = X + Step; // next X
#end // ------------------- loop end
#declare Z = -5;  // start value Z
#declare EndZ = 5;  //   end value Z
#declare Step = 0.85;// step value

#while ( Z < EndZ*2 + Step)

  #declare X = -5;  // start value X
  #declare EndX = 5;//   end value X

  #while ( X < EndX*2 + Step)


   object{ Ball translate <X,0,Z>}

object{Spiral translate<X,0,Z*5*rand(Rnd_1)>}

  #declare X = X + Step;//next X
  #end // ----------- loop end X

#declare Z = Z + Step; //next Z
#end // ------------ loop end Z
> --
> Mike Williams
> Gentleman of Leisure

[Grassblade] Re: spiral [6944 days 13 hours and 13 minutes ago]

Sat, 31 Mar 2007 10:30:01 GMT

"sahraoui" <sch### [at] uiucedu> wrote:
> Thanks for the message.
> Actually I like the power of parametric objects.
> I am not sure however how to make these dotes spheres howeve
> Also in param.inc there was a line
> #include makemesh.inc
> but I am not sure where is that include file.
>
> thanks
I just posted the parametric equation for the "straight" tubular helix on
your other thread. Makemesh.inc should be in Ingo's zip. To run param.inc
you need to tell POV-ray where to look for makemesh.inc, you can either
drop all the inc's in POVray/ include directory, or edit povray.ini in the
renderer directory to point to whatever directory you unzipped the param
tool in. This is in the Windows version, I do not know if or how the Mac
version differs.

[Mike Williams] Re: spiral [6944 days 22 hours and 46 minutes ago]

Sat, 31 Mar 2007 00:57:16 GMT

Wasn't it sahraoui who wrote:
>Hi Mike
>
>Thanks a lot for the file.
>Actually i was trying that same loop
>but got entangled inside and got the code
>to run forever until I saw your message. thanks again.
>The parametric stuff did not work for some reason.
>
>Now here is the thing. What you sent me make the spiral follow
>the sinus line indeed but BUT every "circle" of the spiral
>is NOT perpendicular to the line of the sinus but it
>is always perpendicular to the horizontal.
>In other words your code produce a helix who axis is
>always parallel to the horizontal
>but what would be perfect is a helix whose axis
>is parallel to the sinus fonction that follows, andn that I beleive
>is not a piece of cake...but may be not for you Oh gentleman of Leisure

The basic strategy would be to tilt each "circle" by an amount that
varied with the cosine. The tricky bit would be to calculate the correct
value for the amount of tilt ("B" in the following code) from the other
values.

#declare R1=1.5;
#declare F1=1.2;
#declare R2=0.15;
#declare N=100;
#declare H=10;

#declare F2=0.2;
#declare A=0.5;
#declare B=-0.2;

sphere_sweep {
  b_spline
  100,            
  #declare Y=0;
  #while (Y<N)
    #declare X=R1*sin(F1*Y)+A*sin(F2*Y);
    <X, Y*H/N-H/2 + B*X*cos(F2*Y) , R1*cos(F1*Y)>,R2
    #declare Y=Y+1;
  #end
  pigment {rgb 1}
}

>embedding that into a larger sheet of beads would be quite a challenge too.

In what way?

-- 
Mike Williams
Gentleman of Leisure

[sahraoui] Re: spiral [6945 days and 43 minutes ago]

Fri, 30 Mar 2007 23:00:02 GMT

Thanks for the message.
Actually I like the power of parametric objects.
I am not sure however how to make these dotes spheres howeve
Also in param.inc there was a line
#include makemesh.inc
but I am not sure where is that include file.

thanks
"Grassblade" <nomail@nomail> wrote:
> "sahraoui" <sch### [at] uiucedu> wrote:
> > Hi
> >
> > I was wondering if there is a simple way
> > to draw a helix on a sinus. Instead of having a straigh helix
> > we should have a helix that would follow a sine function. It seems
> > hard but may be I am not optimising the code. so far it is not working
> >
> > regards
>
> I would turn to parametric objects, with them you can get pretty much
> anything that strikes your fancy, provided you know your way around them.
> I'm not too familiar with them myself, but I do know you can find pointers
> at Mike Williams page:
> http://www.econym.demon.co.uk/isotut/parametric.htm
>
> The helix isn't mentioned over there, at least I haven't found it with only
> a quick sweep, but its parametric equation is:
>
> #declare Fx = function {sin(5*v)}
> #declare Fy = function {v}
> #declare Fz = function {cos(5*v)}
>
> parametric {
>   function {Fx(u,v,0)}
>   function {Fy(u,v,0)}
>   function {Fz(u,v,0)}
>     <2*pi,-pi>,<4*pi,2.1*pi>
>   contained_by{box{-2,2}}
>   precompute 18, x,y,z
>   pigment {rgb x}
>   }
>
> If you render the above you'll only see a series of dots in a helix pattern,
> that is because the above formula implies 0 thickness. I do not know how to
> change it so that it becomes a sphere sweep of a given radius along the
> helix.
> Anyway, to address your question, simply modify Fy (the helix's axis) to
> accomodate for a sin(v) or whatnot.
>
> Parametric objects render exceedingly slowly, so you may want to use Ingo
> Janssen's param.inc. You can find more details at Mike Williams page.

[sahraoui] Re: spiral [6945 days 3 hours and 33 minutes ago]

Fri, 30 Mar 2007 20:10:00 GMT

Hi Mike

Thanks a lot for the file.
Actually i was trying that same loop
but got entangled inside and got the code
to run forever until I saw your message. thanks again.
The parametric stuff did not work for some reason.

Now here is the thing. What you sent me make the spiral follow
the sinus line indeed but BUT every "circle" of the spiral
is NOT perpendicular to the line of the sinus but it
is always perpendicular to the horizontal.
In other words your code produce a helix who axis is
always parallel to the horizontal
but what would be perfect is a helix whose axis
is parallel to the sinus fonction that follows, andn that I beleive
is not a piece of cake...but may be not for you Oh gentleman of Leisure

embedding that into a larger sheet of beads would be quite a challenge too.

Regards and have a great week end

Mike Williams <nos### [at] econymdemoncouk> wrote:
> Wasn't it sahraoui who wrote:
> >Actually
> >I use a while loop to make my spiral and I can make
> >as many as possible and it is rather simple
> >it is a translation and a rotation.
> >BUT with this method it is not easy to make the helix
> >follow a sine curve.
>
> If you're using a sphere_sweep, like this
>
> #declare R1=1.5;
> #declare F1=1.2;
> #declare R2=0.15;
> #declare N=100;
> #declare H=10;
>
> sphere_sweep {
>   b_spline
>   100,
>   #declare Y=0;
>   #while (Y<N)
>     <R1*sin(F1*Y),Y*H/N-H/2,R1*cos(F1*Y)>,R2
>     #declare Y=Y+1;
>   #end
>   pigment {rgb 1}
> }
>
> Then you can just add an extra sinusoidal factor to the x value of the
> points, like this
>
> #declare R1=1.5;
> #declare F1=1.2;
> #declare R2=0.15;
> #declare N=100;
> #declare H=10;
>
> #declare F2=0.2;
> #declare A=0.25;
>
> sphere_sweep {
>   b_spline
>   100,
>
>   #declare Y=0;
>   #while (Y<N)
>     <R1*sin(F1*Y)+A*sin(F2*Y),Y*H/N-H/2,R1*cos(F1*Y)>,R2
>     #declare Y=Y+1;
>   #end
>   pigment {rgb 1}
> }
>
>
> --
> Mike Williams
> Gentleman of Leisure

[Mike Williams] Re: spiral [6945 days 18 hours and 42 minutes ago]

Fri, 30 Mar 2007 05:01:18 GMT

Wasn't it sahraoui who wrote:
>Actually
>I use a while loop to make my spiral and I can make
>as many as possible and it is rather simple
>it is a translation and a rotation.
>BUT with this method it is not easy to make the helix
>follow a sine curve.

If you're using a sphere_sweep, like this

#declare R1=1.5;
#declare F1=1.2;
#declare R2=0.15;
#declare N=100;
#declare H=10;

sphere_sweep {
  b_spline
  100,            
  #declare Y=0;
  #while (Y<N)
    <R1*sin(F1*Y),Y*H/N-H/2,R1*cos(F1*Y)>,R2
    #declare Y=Y+1;
  #end
  pigment {rgb 1}
}

Then you can just add an extra sinusoidal factor to the x value of the
points, like this

#declare R1=1.5;
#declare F1=1.2;
#declare R2=0.15;
#declare N=100;
#declare H=10;

#declare F2=0.2;
#declare A=0.25;

sphere_sweep {
  b_spline
  100,            

  #declare Y=0;
  #while (Y<N)
    <R1*sin(F1*Y)+A*sin(F2*Y),Y*H/N-H/2,R1*cos(F1*Y)>,R2
    #declare Y=Y+1;
  #end
  pigment {rgb 1}
}


-- 
Mike Williams
Gentleman of Leisure

[sahraoui] Re: spiral [6946 days 1 hour and 43 minutes ago]

Thu, 29 Mar 2007 22:00:01 GMT

Actually
I use a while loop to make my spiral and I can make
as many as possible and it is rather simple
it is a translation and a rotation.
BUT with this method it is not easy to make the helix
follow a sine curve.

sigh!


"Grassblade" <nomail@nomail> wrote:
> "sahraoui" <sch### [at] uiucedu> wrote:
> > Hi
> >
> > I was wondering if there is a simple way
> > to draw a helix on a sinus. Instead of having a straigh helix
> > we should have a helix that would follow a sine function. It seems
> > hard but may be I am not optimising the code. so far it is not working
> >
> > regards
>
> I would turn to parametric objects, with them you can get pretty much
> anything that strikes your fancy, provided you know your way around them.
> I'm not too familiar with them myself, but I do know you can find pointers
> at Mike Williams page:
> http://www.econym.demon.co.uk/isotut/parametric.htm
>
> The helix isn't mentioned over there, at least I haven't found it with only
> a quick sweep, but its parametric equation is:
>
> #declare Fx = function {sin(5*v)}
> #declare Fy = function {v}
> #declare Fz = function {cos(5*v)}
>
> parametric {
>   function {Fx(u,v,0)}
>   function {Fy(u,v,0)}
>   function {Fz(u,v,0)}
>     <2*pi,-pi>,<4*pi,2.1*pi>
>   contained_by{box{-2,2}}
>   precompute 18, x,y,z
>   pigment {rgb x}
>   }
>
> If you render the above you'll only see a series of dots in a helix pattern,
> that is because the above formula implies 0 thickness. I do not know how to
> change it so that it becomes a sphere sweep of a given radius along the
> helix.
> Anyway, to address your question, simply modify Fy (the helix's axis) to
> accomodate for a sin(v) or whatnot.
>
> Parametric objects render exceedingly slowly, so you may want to use Ingo
> Janssen's param.inc. You can find more details at Mike Williams page.

[Grassblade] Re: spiral [6946 days 2 hours and 38 minutes ago]

Thu, 29 Mar 2007 21:05:01 GMT

"sahraoui" <sch### [at] uiucedu> wrote:
> Hi
>
> I was wondering if there is a simple way
> to draw a helix on a sinus. Instead of having a straigh helix
> we should have a helix that would follow a sine function. It seems
> hard but may be I am not optimising the code. so far it is not working
>
> regards

I would turn to parametric objects, with them you can get pretty much
anything that strikes your fancy, provided you know your way around them.
I'm not too familiar with them myself, but I do know you can find pointers
at Mike Williams page:
http://www.econym.demon.co.uk/isotut/parametric.htm

The helix isn't mentioned over there, at least I haven't found it with only
a quick sweep, but its parametric equation is:

#declare Fx = function {sin(5*v)}
#declare Fy = function {v}
#declare Fz = function {cos(5*v)}

parametric {
  function {Fx(u,v,0)}
  function {Fy(u,v,0)}
  function {Fz(u,v,0)}
    <2*pi,-pi>,<4*pi,2.1*pi>
  contained_by{box{-2,2}}
  precompute 18, x,y,z
  pigment {rgb x}
  }

If you render the above you'll only see a series of dots in a helix pattern,
that is because the above formula implies 0 thickness. I do not know how to
change it so that it becomes a sphere sweep of a given radius along the
helix.
Anyway, to address your question, simply modify Fy (the helix's axis) to
accomodate for a sin(v) or whatnot.

Parametric objects render exceedingly slowly, so you may want to use Ingo
Janssen's param.inc. You can find more details at Mike Williams page.

[sahraoui] spiral [6946 days 3 hours and 18 minutes ago]

Thu, 29 Mar 2007 20:25:02 GMT

Hi

I was wondering if there is a simple way
to draw a helix on a sinus. Instead of having a straigh helix
we should have a helix that would follow a sine function. It seems
hard but may be I am not optimising the code. so far it is not working

regards

[redsky] Re: Animation Agrivations [7010 days 18 hours and 54 minutes ago]

Wed, 24 Jan 2007 04:48:34 GMT

"Chris" <chr### [at] yahoocom> wrote in news:399e3177@news.povray.org:

> Can anyone out there tell where I can find a really good animation
> tutorial for a completey braindead newbie?
> 
> 
> 

Hi!
You cn use 3dtotal.com
if i worng spell. Pls use google for find some grate tuto.

[David Wallace] Re: Landscape [7202 days 3 hours and 22 minutes ago]

Sun, 16 Jul 2006 20:20:50 GMT

gonzo wrote:
> "Shams" <sha### [at] yahoocom> wrote:
>> Folks I've been trying to make a realistic landscape using POV-ray 3.5 but
>> I'm not getting satisfactory results. The tutorials were of little help.
>> Help Please!
>>
>> Shams
> 
> What are you trying, and which results aren't satisfactory?  (Isosurface?
> Height_field?  Wrong shape? Bad texture?)  Landscapes are a complex
> subject, and usually require a mix of several different factors to work.
> 
> RG
> 
> 
> 
Roll your own:

// Landscape functions

#include "functions.inc"

#declare IsTest = 0;
#declare IsWater = 0;

#global_settings {
	#if(!IsTest) hf_gray_16 on #end
	number_of_waves 35
}

#declare aspect = image_width/image_height;
#declare aperSize = 3000;

#declare l0Pat = function { f_ridged_mf(x,y,z,0.01,3.58,19,-.0,3.1,3) }

#declare l1Pat = function { pattern {
	crackle
	metric 1.4
	form <1.0,-0.2, 0.3>
	scale 1400
} }

#declare l2Pat = function { pattern {
	granite
	scale 4900
} }

#declare w1Pat = function { pattern {
	waves
	triangle_wave
	frequency 12
	turbulence 0.21
	scale 3000
} }

#declare w2Pat = function { pattern {
	ripples
	triangle_wave
	frequency 43
	turbulence 0.21
	scale 5000
} }

#declare l3Pat = function { pattern {
	leopard
	sine_wave
	turbulence 1.21
	octaves 8
	omega 0.73
	scale 800
} }

#if (IsWater)
	#declare lkpat = function { pow(w1Pat(x,y,z),0.5)*.70 + 
pow(w2Pat(x,0,z),2.0)*0.30 }
#else
	#declare lkpat = function { (1-pow(l1Pat(x,y,z),1.2))*.88 + 
pow(l2Pat(x,0,z),1.2)*0.15+pow(l3Pat(x,0,z),2)*0.20 }
#end

plane { y, 0
	texture {
		pigment {
			function { lkpat(x,y,z) }
			color_map {
				[0.00 rgb (IsTest ? <0,1,1> : <0,0,0>) ]
				[1.00 rgb (IsTest ? <1,0,0> : <1,1,1>) ]
			}
		}
		finish { ambient 1 }
	}
}

camera {
	orthographic
	location < 0.0, 2.0, 0.0> look_at < 0.0, 0.0, 0.0>
	right x*aperSize*aspect
	up z*aperSize
}

What I am creating here is an image that can then be used as a height field.

#declare Ground = height_field {
	png "lakeb.png"
	smooth
	translate <-.5,-.5,-.5>
	texture { texGnd }
	scale <1e4, 260, 1e4>
}


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

[moocow] Re: Summing over indices of an array [7396 days 17 hours and 33 minutes ago]

Tue, 3 Jan 2006 06:10:00 GMT

> RTFM.

I couldn't find that in the documentation. Could you give me a link?


> Arrays exist while parsing, functions are evaluated while rendering.
> Functions are not macros!

Thanks.

> > Why can't I do:
> > #define f1 = function { f1(x,y,z) + g(x,y,z) }
> > ?
>
> This cannot work as it creates an infinite recursion!

Only if you assume functions are evaluated lazily, and don't unroll all
function references into a closed form. Apparently that's how POV works.

For all I knew, it could be the same as with scalar values:
#define f = function(x) { x }
//f(x) = x
#define f = function(x) { f(x) + 1 }
//f(x) = x+1

[nomail] Re: Summing over indices of an array [7396 days 17 hours and 58 minutes ago]

Tue, 3 Jan 2006 05:45:00 GMT

"moocow" <nomail@nomail> wrote:
> What if I want to define a function as a sum of other functions?

There is nothing preventing you from doing it.

> #declare X = array[N]
> //set X's
>
> #declare f = function{ sum(i, 0, N-1, pow(.5, pow( vlength(<x,y,z> - X[i]),
> 2))) }
>
> I can't think of how to make that work.

RTFM.

> Also, why these restrictions?

Why is the sky blue? The primary use for functions is in isosurfaces,
functions are not a macro replacement.

> Why can't I sum outside a function or

The SDL supports means to compute the sum via a macro.

> use arrays inside?

Arrays exist while parsing, functions are evaluated while rendering.
Functions are not macros!

> Why can't I do:
> #define f1 = function { f1(x,y,z) + g(x,y,z) }
> ?

This cannot work as it creates an infinite recursion!

[moocow] Re: Summing over indices of an array [7396 days 22 hours and 38 minutes ago]

Tue, 3 Jan 2006 01:05:00 GMT

Christoph Hormann <chr### [at] gmxde> wrote:
> Mike Williams wrote:
> >
> > I think you have to use a loop:
> >
>
> Bah, you surely don't have to:
>
> #macro Add(i)
>    #if (i>0)
>      #local R=Add(i-1)+elem[i];
>    #else
>      #local R=elem[i];
>    #end
>    R
> #end
>
> #declare Sum=Add(n);
>
> ;-)
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 23 Sep. 2004 _____.//^>_*_<^/.______

What if I want to define a function as a sum of other functions?

#declare X = array[N]
//set X's

#declare f = function{ sum(i, 0, N-1, pow(.5, pow( vlength(<x,y,z> - X[i]),
2))) }

I can't think of how to make that work.

Also, why these restrictions? Why can't I sum outside a function or use
arrays inside? Why can't I do:
#define f1 = function { f1(x,y,z) + g(x,y,z) }
?

[Noam L ] Re: How to make 3D letters [7472 days 9 hours and 16 minutes ago]

Wed, 19 Oct 2005 14:26:20 GMT

What if he does an intersection between a text and a box, and then use
uv-mapping to map the signatures onto the box?


On Tue, 21 Jan 2003 17:08:41 -0600, "hughes, b."
<omn### [at] charternet> wrote:

>"D" <dui### [at] hetnetnl> wrote in message
>news:3e2dad67@news.povray.org...
>> I have recorded a CD with my (hobby)band and want to design a CD cover.
>> My idea is to use 3D letters to write our band name and wrap photographs
>> around them.
>>
>> Does someone have (or knows a location to find) 3D fonts I can use,
>> because I'm quite sure they must already excist (as include files).
>>
>> (I'm a new povray user, but can program C/C++)
>
>Well... you can use any acceptable font file for a text object. TTF's for
>example. What might prove difficult is placing images onto the letters,
>other than simply plunking them on. UV mapping isn't possible for the text
>object. Although, maybe using planar, spherical, toroidal and such would be
>enough. You can also place the letters in various ways.
>
>If you are wanting to have more control of the shape of the letters
>themselves then you'll need to try something else. Have a look at the Links:
>http://www.povray.org/resources/links/3D_Programs/Fonts_and_Font_Utilities/?
>sort=alpha#s06_01_07
>

[earthdog] Isosurface Brick [7510 days 7 hours and 9 minutes ago]

Sun, 11 Sep 2005 16:34:13 GMT

Can anyone give me an example of how to create a "brick" from an 
isosurface?  So far all I've created have either only one side perturbed 
or have no resemblance to an actual brick.

-->Jeff

[Mike Kost] Quick Media Rendering Tutorial [7535 days 22 hours and 17 minutes ago]

Wed, 17 Aug 2005 01:25:59 GMT

Hey All,

I published a tutorial on rendering times when you degrade media quality.
The idea is to do low-quality but fast renderings while you're still
composing your scene. The articles on my website:
http://povray.tashcorp.net/tutorials/dd_media_perf

Mike
--
http://povray.tashcorp.net

[gonzo] Re: Landscape [7547 days 3 hours and 58 minutes ago]

Fri, 5 Aug 2005 19:45:00 GMT

"Shams" <sha### [at] yahoocom> wrote:
> Folks I've been trying to make a realistic landscape using POV-ray 3.5 but
> I'm not getting satisfactory results. The tutorials were of little help.
> Help Please!
>
> Shams

What are you trying, and which results aren't satisfactory?  (Isosurface?
Height_field?  Wrong shape? Bad texture?)  Landscapes are a complex
subject, and usually require a mix of several different factors to work.

RG

[Mike Kost] Re: Landscape [7558 days 6 hours and 16 minutes ago]

Mon, 25 Jul 2005 17:26:26 GMT

Shams wrote:
> Folks I've been trying to make a realistic landscape using POV-ray 3.5 but
> I'm not getting satisfactory results. The tutorials were of little help.
> Help Please!
> 
> Shams

Shams,

Christoph Hormann (to the best of my memory at the moment) had started a
Landscape Of the Week campaign some time back, resulting in lots of
landscape examples posted to the newsgroups. If you search the newsgroups
for 'LotW' (http://www.povray.org/search/ - be sure to select 'just
news.povray.org'), you'll find several povray source examples for
inspiration.

All the best,

Mike K
--
http://povray.tashcorp.net

[Shams] Landscape [7558 days 9 hours and 8 minutes ago]

Mon, 25 Jul 2005 14:35:00 GMT

Folks I've been trying to make a realistic landscape using POV-ray 3.5 but
I'm not getting satisfactory results. The tutorials were of little help.
Help Please!

Shams

[MontanaSteve] Re: Arbaro??? [7644 days 19 hours and 43 minutes ago]

Sat, 30 Apr 2005 04:00:01 GMT

Thanks Mike, I tried that and it worked great. Good greif! The inc file is
over 18,700 lines.

Mike Kost <con### [at] povraytashcorpnet> wrote:
> I'm assuming that you've already exported the include file. The include file
> has 3 declares in it:
> - #declare NAME_height = X;
> - #declare NAME_stems = mesh2 { };
> - #declare NAME_leaves = mesh2 { };
>
> When I exported the desert bush (desert_bush.inc), for example, the "NAME"
> was desert_bush_13 and I had:
> - #declare desert_bush_13_height = 3.07616;
> - #declare desert_bush_13_stems =
> - #declare desert_bush_13_leaves = mesh2 {
>
> I don't know where the 13 came from :)
>
> To get a quick look at the tree, I used the following:
> -----<snip>--------
>
> camera { location <0,5,5> look_at <0,1,0> angle 60 }
>
> light_source {
>     <0,20,0> color rgb 1.0
>     area_light
>     <0,0,0.5>, <0.5,0,0>, 3, 3
>     adaptive 2
>     circular
> }
>
> // -+-+-+- Tree -+-+-+-
> #include "desert_bush.inc"
>
> object {
>     desert_bush_13_stems
>     texture {
>         pigment { color rgb <0.57/1.5, 0.41/1.5, 0.37/1.5> }
>         finish { ambient 0.5 }
>     }
> }
>
> object {
>     desert_bush_13_leaves
>     texture {
>         pigment { color rgb <0, 1, 0> }
>         finish { ambient 0.5 }
>     }
> }
>
> -----</snip>-------
>
> Happy rendering,
>
> Mike
> --
> http://povray.tashcorp.net
>
> MontanaSteve wrote:
> > I just downloaded the latest version of Arbaro and find that the
> > documentation is not designed for new users.  All right now, how do I get
> > any trees into a POVray scene?. I did a Google seach and most of the sites
> > are in languages that I cannot read.  Can someone please help me?

[Mike Kost] Re: Arbaro??? [7655 days 6 hours and 18 minutes ago]

Tue, 19 Apr 2005 17:24:53 GMT

I'm assuming that you've already exported the include file. The include file
has 3 declares in it: 
- #declare NAME_height = X;
- #declare NAME_stems = mesh2 { };
- #declare NAME_leaves = mesh2 { };

When I exported the desert bush (desert_bush.inc), for example, the "NAME"
was desert_bush_13 and I had:
- #declare desert_bush_13_height = 3.07616;
- #declare desert_bush_13_stems =
- #declare desert_bush_13_leaves = mesh2 {

I don't know where the 13 came from :)

To get a quick look at the tree, I used the following:
-----<snip>--------

camera { location <0,5,5> look_at <0,1,0> angle 60 }

light_source {
    <0,20,0> color rgb 1.0
    area_light
    <0,0,0.5>, <0.5,0,0>, 3, 3
    adaptive 2
    circular
}

// -+-+-+- Tree -+-+-+-
#include "desert_bush.inc"

object {
    desert_bush_13_stems
    texture {
        pigment { color rgb <0.57/1.5, 0.41/1.5, 0.37/1.5> }
        finish { ambient 0.5 }
    }
}

object {
    desert_bush_13_leaves
    texture {
        pigment { color rgb <0, 1, 0> }
        finish { ambient 0.5 }
    }
}

-----</snip>-------

Happy rendering,

Mike
--
http://povray.tashcorp.net

MontanaSteve wrote:
> I just downloaded the latest version of Arbaro and find that the
> documentation is not designed for new users.  All right now, how do I get
> any trees into a POVray scene?. I did a Google seach and most of the sites
> are in languages that I cannot read.  Can someone please help me?

[MontanaSteve] Arbaro??? [7659 days 3 hours and 53 minutes ago]

Fri, 15 Apr 2005 19:50:00 GMT

I just downloaded the latest version of Arbaro and find that the
documentation is not designed for new users.  All right now, how do I get
any trees into a POVray scene?. I did a Google seach and most of the sites
are in languages that I cannot read.  Can someone please help me?

[Txemi Jendrix] Re: Newbie to POV [7690 days 2 hours and 45 minutes ago]

Tue, 15 Mar 2005 20:58:02 GMT

Toshiya wrote:

> can someone help me with the basics? I've messed around with 3D Studio Max
> in the past and it looks very different to this

This is the better link I can provide:

http://www.f-lohmueller.de/pov_tut/pov__eng.htm

But if you come from 3D Studio Max you can try with Moray

http://www.stmuc.com/moray/menews.html

Install it and follow the tutorials included in the help file.

Hope this helps

-- 
Txemi Jendrix
www.txemijendrix.com

[regdo] Re: Newbie to POV [7690 days 2 hours and 47 minutes ago]

Tue, 15 Mar 2005 20:56:03 GMT

ingo wrote:
> in news:web.423515f1ef257ace4b2ca0be0@news.povray.org Toshiya wrote:
> 
> 
>>can someone help me with the basics? I've messed around with 3D
>>Studio Max in the past and it looks very different to this
> 

> The second basics there is is the manual. Even if you don't intend to 
> write scenes by hand, work through the tutorial par of the docs as it 
> gives a good idea of how POV-Ray works.
> 

> Ingo
> 

Looking at small renders of the sample scenes (there are many provided 
with POV) and wandering into the code to see how everything is placed, 
modified, etc, is of great help, too !
Some of the scene are very easy to understand, even if you only discover 
that language.

Regis.

[ingo] Re: Newbie to POV [7691 days 4 hours and 5 minutes ago]

Mon, 14 Mar 2005 19:37:23 GMT

in news:web.423515f1ef257ace4b2ca0be0@news.povray.org Toshiya wrote:

> can someone help me with the basics? I've messed around with 3D
> Studio Max in the past and it looks very different to this

Toshiya,

The first of the basics is that there is no modeller, you probably 
noticed. Everything comes from a readable text script. Yet you can use 
all kind of modellers and many output POV-Ray's SDL directly or you can 
use mesh converters on *.obj etc. files. There is no modeller that fully 
supports every aspect of POV-Ray but Moray comes close. So to get 
everything out of it you'll have to learn some scripting, especialy if 
you want to use the more advanced features like radiosity, photons or 
media.

The second basics there is is the manual. Even if you don't intend to 
write scenes by hand, work through the tutorial par of the docs as it 
gives a good idea of how POV-Ray works.

If language is a problem, there is an international news group on this 
server where you can post in your own language. On the web you may find 
some more or less complete translations of the POV-Ray documentation.

Ingo

[Toshiya] Newbie to POV [7691 days 18 hours and 58 minutes ago]

Mon, 14 Mar 2005 04:45:00 GMT

can someone help me with the basics? I've messed around with 3D Studio Max
in the past and it looks very different to this

[Rishi] Slopes? [7715 days 13 hours and 48 minutes ago]

Fri, 18 Feb 2005 09:55:00 GMT

Can anyone suggest a good tutorial for Slope (anything apart from the
documentation)?

Regards,

Rishi

[Warp] Re: Summing over indices of an array [7741 days 10 hours and 15 minutes ago]

Sun, 23 Jan 2005 13:27:58 GMT

Christoph Hormann <chr### [at] gmxde> wrote:
> Bah, you surely don't have to:

  But using a recursive macro is an awfully inefficient way of doing that
(at least with the current SDL parser).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[Christoph Hormann] Re: Summing over indices of an array [7742 days 15 hours and 13 minutes ago]

Sat, 22 Jan 2005 08:30:02 GMT

Mike Williams wrote:
> 
> I think you have to use a loop:
> 

Bah, you surely don't have to:

#macro Add(i)
   #if (i>0)
     #local R=Add(i-1)+elem[i];
   #else
     #local R=elem[i];
   #end
   R
#end

#declare Sum=Add(n);

;-)

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

[Mike Williams] Re: Summing over indices of an array [7742 days 15 hours and 36 minutes ago]

Sat, 22 Jan 2005 08:06:26 GMT

Wasn't it Max Ulbrich who wrote:
>Hi,
>
>I just trying to get started with Povray and try to sum elements of an 
>array.
>If I use elem[0]+elem[1]+elem[2]+... it works fine.
>If I try sum(i,1,n,elem[i]) I get an error.

sum() only works inside a function{} and array[] references don't work
inside a function{}. So, whether you're trying to do the sum inside or
outside a function{} it's not going to work.

I think you have to use a loop:

#declare i=1;
#declare Sum=0;
#while (i<=n)
  #declare Sum = Sum + elem[i];
  #declare i=i+1;
#end

-- 
Mike Williams
Gentleman of Leisure

[Max Ulbrich] Summing over indices of an array [7742 days 16 hours and 35 minutes ago]

Sat, 22 Jan 2005 07:07:52 GMT

Hi,

I just trying to get started with Povray and try to sum elements of an 
array.
If I use elem[0]+elem[1]+elem[2]+... it works fine.
If I try sum(i,1,n,elem[i]) I get an error.
What is the usual way to get it done? I cannot find help in the Povray 
tutorial from the povray web page. Is there a good online tutorial that 
explains easy things and has lots of examples?
Thanks,
Max

[Amazon Warrior] Fractal tutorials [7761 days 10 hours and 53 minutes ago]

Mon, 3 Jan 2005 12:49:46 GMT

Doubtless someone has asked this before, but I'm a noob, so I'll ask
again...

Are there any good fractal tutorials out there?  I know there is a (pretty
dry) description of  the syntax in the pov help file, but I'm looking for
examples, hints and tips, where-why-and-how sort of stuff.  Any advice would
be welcome.

I do generally try to use the help file first before pestering people, but
I'm finding as I learn more that the pov help file is really good if you
know either absolutely nothing about programming, pov and maths, or
everything about them.  But not much good for covering middle ground, so to
speak.

[Jaime Vives Piqueres] [7834 days 9 hours and 16 minutes ago]

Fri, 22 Oct 2004 14:26:34 GMT

Hola serpito:

> Agradeseria que alguien me informará de donde puedo descargar tutoriales en
> español de pov-ray.

   ¿Te refieres a tutoriales de terceros? No conozco muchos, pero Txemi
creo que tenia varios en su pagina:

   http://www.txemijendrix.com

   Si lo que quieres es una traduccion del manual oficial del programa, 
lo tienes en mi sitio, gracias a la colaboracion de unos cuantos 
usuarios hispanohablantes:

   http://www.ignorancia.org/traduccion/

   No es perfecto, y ademas es de la version 3.5, pero sirve sin mayores 
problemas en el mayoria de casos.

   Saludos!

--
Jaime

[serpito] [7835 days 8 hours and 22 minutes ago]

Thu, 21 Oct 2004 15:20:41 GMT

Agradeseria que alguien me informará de donde puedo descargar tutoriales en
español de pov-ray.


                        gracias

[ingo] single colour layers, texturing [7888 days 4 hours and 24 minutes ago]

Sun, 29 Aug 2004 19:18:48 GMT

This is not a true tutorial, it's more like a receipe showing a possible 
way of creating textures and keeping control on them.

In p.a-u Gary Blessing asked how to re-colour an existing wood texture 
from 'woods.inc'. When I started with POV-Ray I had similar problems. 
The use of many differently coloured entries in a colour_map makes it 
complex to change the colour of a texture, especialy if it is also a 
layered texture.

In the world of printing one can only use one colour per printing 
cylinder. So all a cylinder does is put more or less pigment on the 
substrate. I tried to do the same with POV-Ray.

It is doen by using layered textures. Each layer has only one colour in 
it. The "density" of the colour is controlled by the filter / transmit 
component. Both these components are fixed. The only thing that can be 
changed when using the texture is the colour of it. 

By layering the various patterns colour mixing occurs, so in the end 
you'll have more colour shades than layers. The first layer is a plain 
base colour, with no pattern. Changing this colour can give you quickly 
a different looking colour-way, think of varying the colours of a 
planched floor. 

Each layer is put inside a macro to make use and control easier.

Below, a simple scene to play with:

//---%<------%<---
#version 3.6;

#macro T1_base(cBase)
  texture {pigment{rgb cBase}}
#end

#macro T1_layer01(cLayer01)
  texture {
    pigment {
      wood
      sine_wave
      turbulence <0.01,0.03,0.01>
      octaves 7
      lambda 0.75
      omega 0.5
      colour_map {
        [0.0, rgb cLayer01 filter 0.1]
        [0.8, rgb cLayer01 filter 0.8]
        [1.0, rgb cLayer01 filter 1]
      }
    }
  }
#end

#macro T1_layer02(cLayer02)
  texture {
    pigment {
      wood 
      scale <1.2,1,1.3>
      turbulence <0.03,0.01,0.02>
      octaves 3
      lambda 1
      omega 0.75
      colour_map {
        [0.3, rgb cLayer02 filter 0.7]
        [0.4, rgb 1 filter 1 transmit 0.3]
        [0.7, rgb cLayer02 filter 0.3]
        [1.0, rgb 1 filter 1]
      }
    }
  }
#end

#macro T1(cBase,cLayer01,cLayer02)
  T1_base(cBase)
  T1_layer01(cLayer01)
  T1_layer02(cLayer02)
#end

global_settings {
  assumed_gamma 1.0
}

camera {
  //orthographic
  location  <0.0, 0, -6>
  right     x*image_width/image_height
  look_at   0
  angle 60
}

sky_sphere {pigment{function{abs(y)}}}

light_source {
  <0, 0, -550>, 1
}

sphere {
  0.0, 1.2
  material {
    T1(<1,0.85,0.7>,<1,0.75,0.8>,<0.8,0.75,0.9>)
    texture {
      pigment{rgbf 1}
      finish{specular 0.4}
    }
    scale 0.1
    rotate <0,44,0>
  }
  translate -1.2*x
}

box {
  -1,1
  material {
    T1_base(<0.92,0.75,0.6>)
    T1_layer01(<0.8,0.62,0.45>)
    T1_layer02(<0.75,0.60,0.45>)
    scale 0.1
    rotate <0,88,0>
  }  
  translate <1.2,-1,0>
}

box {
  -1,1
  material {
    T1_base(1)
    T1_layer01(0.7)
    T1_layer02(0.4)
    scale 0.1
    rotate <0,88,0>
  }  
  translate <1.2,1,0>
}
//---%<------%<---

Ingo

[Rafal 'Raf256' Maj] Media quality tutorial? URL [8009 days 18 hours and 2 minutes ago]

Fri, 30 Apr 2004 05:41:02 GMT

My first tutorial-like small www page,
  http://www.raf256.com/3d/povray/tutorial/cloudscraper/
about using media (+ density file) and setting it's quality 
critics are welcomed.


-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

[ABX] Re: Flowers [8012 days 7 hours and 50 minutes ago]

Tue, 27 Apr 2004 15:53:11 GMT

On Tue, 27 Apr 2004 11:40:22 EDT, "" <nomail@nomail> wrote:
> I can't seem to find a place where I can get flowers to put in my scene.  I
> am making a scene that needs flowers and I can't find any.

This is kind of tutorial thread
http://news.povray.org/povray.general/thread/%3C3### [at] Rapidnetcom%3E/
Perhaps entries in http://www.irtc.org/stills/1998-06-30/ could help.

ABX

[nomail] Flowers [8012 days 7 hours and 58 minutes ago]

Tue, 27 Apr 2004 15:45:01 GMT

I can't seem to find a place where I can get flowers to put in my scene.  I
am making a scene that needs flowers and I can't find any.

Allen

[JC (Exether)] Re: Question about transforming a box into anoth... [8071 days 23 hours and 54 minutes ago]

Fri, 27 Feb 2004 23:48:33 GMT

Robin Johansen wrote:

> Is it possible to change to box (with four corners in one end) to have only
> two corners in the other end?
> 
> And how do I do it?

I don't understand the question.
If what you want to do is roof-like prism, maybe have look at the prism 
primitive. Otherwise try reformulating your question.

JC

-- 
http://exether.free.fr/irtc (more IRTC stats !)

[Robin Johansen] Question about transforming a box into another s... [8072 days 2 hours and 3 minutes ago]

Fri, 27 Feb 2004 21:40:04 GMT

Is it possible to change to box (with four corners in one end) to have only
two corners in the other end?

And how do I do it?

[Warp] Re: Media [8096 days 12 hours and 24 minutes ago]

Tue, 3 Feb 2004 11:19:10 GMT

jfmiller <jfm### [at] hotmailcom> wrote:
> With all dew deference to the work put into the Pov documentation, it would
> be really helpfull if someone could write a clear and compleate tutorial on
> how to use media in POV.

  The POV-Ray 3.6 documentation will most probably include a simple
media tutorial which should be very helpful as an introduction to media.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

[Felbrigg] Re: Media [8096 days 13 hours and 1 minute ago]

Tue, 3 Feb 2004 10:42:08 GMT

Have you peeps gone mad!  The Pov Documentation was about as clear as some
muddy mud on a muddy day. It may have explained to all you boffins but it
sent me crazy!

What the docs need is a simple real-use scene, a step by step guide based on
that scene.  For instance, start with the typical sphere over a a chequered
plane, fill it with flaming media, than add smoke, then put spotlights
behind it into the distance and overlay an atmospheric general media.  Then
add some simple clouds using some of the differn't patterns.  Anyway I think
you see where I'm going.

"Kitsune_e" <kit### [at] hotmailcom> wrote in message
news:web.3e2edb5c44d655bec7e180360@news.povray.org...
> Robert Chaffe wrote:
> >--
> >> how to use media in POV.
> >
> >Meanwhile, perhaps the following might be a good start.
> >
> >This one appears to be written for version 3.1 but might be useful
anyway:
> >http://www.3dluvr.com/intercepto/pov_tuto.htm
> >
> >--
> >Robert Chaffe
> >http://www.donovansweb.com/~chaffe/
> >
>
> Yes!  This is a very clear tutorial, introducing both the syntax and
> advanced methods for using media.  This is exactly what I have been
looking
> for and I would recommend it to anyone seeking to understand media!  I
have
> been struggling to control media for a couple months, but this tutorial
> cleared up all my questions.
>
> Thanks!
>
>
>

[Dayv] Re: Cloth? [8099 days 19 hours and 35 minutes ago]

Sat, 31 Jan 2004 04:07:30 GMT

Hmm.. That tutorial is the same one that was translated from French... about
draping the cloth on an object.  Does anyone know how to attach two of the
corners so it can hang?  I can duplicate the draped cloth over an object..
and I've played with the settings a little, though I don't really understand
what's happeing.  I need it to hang something like this:

http://tofbouf.free.fr/clothray/mpg/rideau2.mpg

Anythoughts?
Thanks!
"Dayv" <onl### [at] earthlinknet> wrote in message
news:4019cf40@news.povray.org...
> I didn't realize that.. I'll check it out.  Thanks!!!!!!!
>
> "ABX" <abx### [at] abxartpl> wrote in message
> news:j1me10h6phb4epsato4lm8m198s9bvso29@4ax.com...
> > On Tue, 27 Jan 2004 22:07:15 -0500, "Dayv" <onl### [at] earthlinknet>
> wrote:
> > > 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.
> >
> > Clothray is included in MegaPOV 1.0. If POV-Man is not requirement then
> try
> > MegaPOV. Several things were fixed in Clothray included in MegaPOV and
> sample
> > scenes with tutorials.
> >
> > http://megapov.inetart.net/manual/tutorials.html
> >
> > ABX
>
>

[Dayv] Re: Cloth? [8100 days 20 hours and 15 minutes ago]

Fri, 30 Jan 2004 03:28:00 GMT

I didn't realize that.. I'll check it out.  Thanks!!!!!!!

"ABX" <abx### [at] abxartpl> wrote in message
news:j1me10h6phb4epsato4lm8m198s9bvso29@4ax.com...
> On Tue, 27 Jan 2004 22:07:15 -0500, "Dayv" <onl### [at] earthlinknet>
wrote:
> > 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.
>
> Clothray is included in MegaPOV 1.0. If POV-Man is not requirement then
try
> MegaPOV. Several things were fixed in Clothray included in MegaPOV and
sample
> scenes with tutorials.
>
> http://megapov.inetart.net/manual/tutorials.html
>
> ABX

[ABX] Re: Cloth? [8102 days 17 hours and 2 minutes ago]

Wed, 28 Jan 2004 06:40:43 GMT

On Tue, 27 Jan 2004 22:07:15 -0500, "Dayv" <onl### [at] earthlinknet> wrote:
> 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.

Clothray is included in MegaPOV 1.0. If POV-Man is not requirement then try
MegaPOV. Several things were fixed in Clothray included in MegaPOV and sample
scenes with tutorials.

http://megapov.inetart.net/manual/tutorials.html

ABX

[Dayv] Cloth? [8102 days 20 hours and 38 minutes ago]

Wed, 28 Jan 2004 03:04:26 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

[JC (Exether)] Re: fast/reasonable menger sponge rendering [8156 days 10 hours and 43 minutes ago]

Fri, 5 Dec 2003 12:59:58 GMT

At level 5, you seem to have 20^5 = 3200000 objects which is a lot.
When you want to save memory, it is usually a good idea to turn toward 
meshes because duplication of a mesh just uses the same object in memory 
which is not true for CSGs.

But I'm not sure it is going to be very efficient if you just replace 
your box with a mesh-box. It's still worth giving it a try. Another 
possibility is to generate or create a menger's mesh with, say one or 
two levels and then use it as a base object for a macro generated 
menger's sponge.

JC

ehmdjii wrote:
> hello, 
> im trying to render a menger sponge with this simple code:
> 
> #macro makemenger(d)
>  #if (d=0)
>   box{-1,1}
>  #else
>   #local i=0;
>   union {
>   #while (i<20)
>    object { makemenger(d-1) translate posi[i]*2 scale 1/3}
>    #local i=i+1;
>   #end 
>   }
>  #end
> 
> which just places boxes in their position.
> i can render a sponge at level 4 quite good, but at level 5 it starts to 
> parse, but after 5 minutes the memory is full and i get an E/A error.
> 
> probably because its too many boxes.
> so are there any tricks to use just one instance of the box in the 
> memory?
> 
> any tips and hints are welcome! ;)
> 
> thanks!

[ehmdjii] fast/reasonable menger sponge rendering [8159 days 23 hours and 12 minutes ago]

Tue, 2 Dec 2003 00:30:30 GMT

hello, 
im trying to render a menger sponge with this simple code:

#macro makemenger(d)
 #if (d=0)
  box{-1,1}
 #else
  #local i=0;
  union {
  #while (i<20)
   object { makemenger(d-1) translate posi[i]*2 scale 1/3}
   #local i=i+1;
  #end 
  }
 #end

which just places boxes in their position.
i can render a sponge at level 4 quite good, but at level 5 it starts to 
parse, but after 5 minutes the memory is full and i get an E/A error.

probably because its too many boxes.
so are there any tricks to use just one instance of the box in the 
memory?

any tips and hints are welcome! ;)

thanks!

[wfx] Re: image and ground area [8215 days 5 hours and 32 minutes ago]

Tue, 7 Oct 2003 18:11:06 GMT

Hughes, B. wrote:

> "wfx" <wol### [at] gmxat> wrote in message
> news:3f81c57f@news.povray.org...
>> hi,
>> i hope im in the right newsgroup.
> 
> Hi there. Not exactly... The "right" newsgroup might have been
> povray.general or povray.newusers  :-)
> 
im sorry and thx next time i use it ;-)

>> My problem is to fit this
>> http://teg.sourceforge.net/fx/themes/SDLport/world.tga image
>> to the ground.
>> My result looks to this
>> http://teg.sourceforge.net/fx/themes/SDLport/burg.png
>> (yes i play with kpovray modeler)
> 
> I don't know what the kpovray modeler is. Although what you need to do, if
> I guess correctly, is to orient the image_map onto the ground plane. Looks
> almost like you have it mapping at a 90 degree angle to the ground now
> (only a single line of the image exists into infinity), which would be the
> default.
> 
> For instance, map_type 0 (planar) projects images onto a wall facing -z,
> so if your ground is a y plane then you'll want to rotate 90 degrees on
> the x axis to lay it flat. And also translate it into position and scale
> to the size needed. For example, look at your POV script where the
> image_map is applied and have it look something like this:
> 
> pigment {
>     image_map {
>         tga "world.tga"
>         map_type 0 // onto plane
>         once // do not tile
>     }
> translate -0.5 // center it
> scale <800,478,1>/2 // use image x and y resolution divided by two
> rotate 90*x // lay onto y plane, facing +y or up, now is x and z oriented
> scale 0.5 // rescale to final size (could be anything except 0)
> translate <1,0,1> // move to final position (someplace under your castle)
> }
> 
> This is, of course, only one way of going about it. Only I hadn't known
> what to scale and translate it to, howver the image resolution is same as
> what I found for that image file. The POV-Ray documentation concerning
> image_map should point you in the right direction. Hopefully I've helped
> you figure it out already, too.
> 
> Ahhh, I see what kpovmodeler is now, I believe. It's at
> http://www.kpovmodeler.org/ in case anyone else wonders about it. I'd be
> guessing this too, but it probably works with coordinates the same as the
> official POV-Ray; unlike Moray, which reorients to a different coordinate
> system. So doing as I said will probably help.
> 
> Bob H.
Ok yes you help me a lot now it looks like this :-)
http://teg.sourceforge.net/fx/themes/SDLport/castel.png

Thx a lot now i can do it better.

[Hughes, B ] Re: image and ground area [8215 days 23 hours and 34 minutes ago]

Tue, 7 Oct 2003 00:08:42 GMT

"wfx" <wol### [at] gmxat> wrote in message
news:3f81c57f@news.povray.org...
> hi,
> i hope im in the right newsgroup.

Hi there. Not exactly... The "right" newsgroup might have been
povray.general or povray.newusers  :-)

> My problem is to fit this
> http://teg.sourceforge.net/fx/themes/SDLport/world.tga image
> to the ground.
> My result looks to this
> http://teg.sourceforge.net/fx/themes/SDLport/burg.png
> (yes i play with kpovray modeler)

I don't know what the kpovray modeler is. Although what you need to do, if I
guess correctly, is to orient the image_map onto the ground plane. Looks
almost like you have it mapping at a 90 degree angle to the ground now (only
a single line of the image exists into infinity), which would be the
default.

For instance, map_type 0 (planar) projects images onto a wall facing -z, so
if your ground is a y plane then you'll want to rotate 90 degrees on the x
axis to lay it flat. And also translate it into position and scale to the
size needed. For example, look at your POV script where the image_map is
applied and have it look something like this:

pigment {
    image_map {
        tga "world.tga"
        map_type 0 // onto plane
        once // do not tile
    }
translate -0.5 // center it
scale <800,478,1>/2 // use image x and y resolution divided by two
rotate 90*x // lay onto y plane, facing +y or up, now is x and z oriented
scale 0.5 // rescale to final size (could be anything except 0)
translate <1,0,1> // move to final position (someplace under your castle)
}

This is, of course, only one way of going about it. Only I hadn't known what
to scale and translate it to, howver the image resolution is same as what I
found for that image file. The POV-Ray documentation concerning image_map
should point you in the right direction. Hopefully I've helped you figure it
out already, too.

Ahhh, I see what kpovmodeler is now, I believe. It's at
http://www.kpovmodeler.org/ in case anyone else wonders about it. I'd be
guessing this too, but it probably works with coordinates the same as the
official POV-Ray; unlike Moray, which reorients to a different coordinate
system. So doing as I said will probably help.

Bob H.

[wfx] image and ground area [8216 days 4 hours and 1 minute ago]

Mon, 6 Oct 2003 19:41:52 GMT

hi,
i hope im in the right newsgroup.
My problem is to fit this 
http://teg.sourceforge.net/fx/themes/SDLport/world.tga image
to the ground.
My result looks to this
http://teg.sourceforge.net/fx/themes/SDLport/burg.png
(yes i play with kpovray modeler)

and i dont know how to fix it 
(i read something but maybe the wrong)

thx a lot
wfx

[Steve Shelby] Re: ARRAYS: More possibilities then the manual t... [8228 days 8 hours and 58 minutes ago]

Wed, 24 Sep 2003 14:45:01 GMT

Jaap Frank wrote:
>Hi,
>
>this is a small explanation of advanced use of arrays.
>In the manual you will find several limitations in using
>arrays, but you can circumvent this.
>
Jaap,
Can this method be used to transform an array over time, that is add a clock
value ot an array? For example, I have a spline defined by an array:
#declare MySpline = create_spline (array [6] {<-2, .6, 0>,<-1.2, .6,
0>,<-.4,-.6,0>,<.4,-.6,0>,<1.2,.6,0>,<2,.6,0>}
Say I want to transform the spline in an animation to this:
#declare MySpline = create_spline (array [6] {<-2, .1, 0>,<-1.2, .1,
0>,<-.4,-.0,0>,<.4,-.0,0>,<-1.2,0,0>,<2,0,0>}
Can that be done?
Thank you,
Steve Shelby
she### [at] earthlinknet

[Jaap Frank] ARRAYS: More possibilities then the manual tells... [8299 days 23 hours and 40 minutes ago]

Tue, 15 Jul 2003 00:02:35 GMT

Hi,

this is a small explanation of advanced use of arrays.
In the manual you will find several limitations in using
arrays, but you can circumvent this.

If you declare a multi-dimensional array the normal way,
    #declare A = array[2][2][2]
you can't take a single dimension from it:
    #declare B = A[2][2]    // this gives an error

Also you can't put different things in it. Once you have
initiated one entry with some kind of variable type, all the
other entries have to be of the same kind.
But, ... you can put everything what you like in it,
arrays too!

If you declare an array, you give it a name:
    #declare Times = array[2]
You then put some values in it:
    #declare Times[0] = 23.24;
    #declare Times[1] = 12.57;
Compare this with:
    #declare Times0 = 23.24;
    #declare Times1 = 12.57;
Look at it the following way:
It looks as if POVray uses Times[0] and Times[1]
as a name for a variable.
You can then imagine that you can put everything in it.
Only the way the names are stored in memory is different
for arrays.

Here are two examples:

If you want a very high dimensional array, this can be done.
Further you can extract a peace of an array.

// --------- Start of code ----------------------------------------
#declare A = array[2][2][2]
#declare B = array[2][2][2]
#declare C = array[2][2][2]
//    Connect the arrays
#declare B[0][0][0] = C
#declare A[0][0][0] = B
//    Initiate something
#declare A[0][0][0][0][0][0][0][0][0]=0.345;
//    Extract a piece
#declare D = A[0][0][0][0][0][0]

//#declare E = A[0][0][0][0][0] //<-- this gives an error of coarse

#debug str(A[0][0][0][0][0][0][0][0][0],5,3)
// -------   End of code -----------------------------------------

Amazingly POV does not get confused!!

This way it is also possible to put different things into one total array.
In one subarray you can put objects and in other subarrays some
different kind of variables.
So you can build your own multi variable type of array.

// --------- Start of code ----------------------------------------
#declare Obj = 0;
#declare Var = 1;
#declare Tex = 2;
#declare Total = array[3]

// Make the subarrays
#declare Objects = array[2]
#declare Vars = array[4]
  {0,1, -1, +1}
#declare Textur = array[2]
  {pigment{color rgb <0,1,0>},
   pigment{color rgbt <1,1,1,0.4>} }

// Connect everything
#declare Total[Obj] = Objects
#declare Total[Tex] = Textur
#declare Total[Var] = Vars

// Use it:
#declare  Total[Obj][0] =
  sphere{ Total[Var][0], Total[Var][1]
          texture { Total[Tex][0]}}
#declare  Total[Obj][1] =
  box{    Total[Var][2], Total[Var][3]
          texture { Total[Tex][1]}}

// Show it:
object {Total[Obj][0]}
object {Total[Obj][1]}

light_source {
  <-20, 40, -20>
  color rgb <1,1,1> }
camera {
  location <0,0,-3>
  look_at 0 }

// -------   End of code -----------------------------------------

Why is this useful?
You can give a macro in one name (Total) a couple
of objects and all his variables and let it do something
with it.
For instance: the macro can reach the textures and
can change them.

I hope someone can use this.

Jaap Frank

[The Brain] Re: Isosurface Tutorial Update [8336 days 10 hours and 4 minutes ago]

Sun, 8 Jun 2003 13:38:38 GMT

OK...
All tutorials about isos I read give me more Questions than Answers. Is it a
criminal act to understand those things not? :p

But this is no criticism. I guess I would laud it if i had a brain :))

[Helen] Re: HDRI tutorials?? [8339 days 23 hours and 58 minutes ago]

Wed, 4 Jun 2003 23:44:37 GMT

"Manuel" <man### [at] tinit> wrote in news:3ed8af39$1@news.povray.org:

> Hi,
> where I can find a tutorials and sample
> scenes about HDRI with Povray?
> 
> thx,
> 
>           Manuel

A very short one for windows and terragen at 
http://www.helensimages.com/tgtips.htm

Write if you want the scene of 
http://www.renderosity.com/viewed.ez?galleryid=370118

Helen

[Jon S Berndt] Re: Slope [8342 days 11 hours and 2 minutes ago]

Mon, 2 Jun 2003 12:40:53 GMT

"Jon S. Berndt" <a@b.c> wrote in message news:3edb3ef2@news.povray.org...

> Can anyone tell me if there is a tutorial for using the "slope" pattern
> modifier online?  I am finding the Help file to be not completely
> descriptive enough for me.
>
> Jon

Never mind.  :-/  I figured it out.  I'll make some suggestions in the
.documentation.inbuilt group (I think that's the appropriate place, no?)

Jon

[Jon S Berndt] Slope [8342 days 11 hours and 31 minutes ago]

Mon, 2 Jun 2003 12:11:30 GMT

Can anyone tell me if there is a tutorial for using the "slope" pattern
modifier online?  I am finding the Help file to be not completely
descriptive enough for me.

Jon

[Manuel] HDRI tutorials?? [8344 days 10 hours and 9 minutes ago]

Sat, 31 May 2003 13:33:45 GMT

Hi,
where I can find a tutorials and sample
scenes about HDRI with Povray?

thx,

          Manuel

[ABX] how to store and access control points together ... [8380 days 15 hours and 39 minutes ago]

Fri, 25 Apr 2003 08:03:49 GMT

This example is based on method described at
http://news.povray.org/6lpkut0vdh0h6gljr7u2v4mip6olddkmel%404ax.com
I do not added much comments. Names of macros and variables should explain it
clear. Add your favourite spline type.

#version 3.5;

#include "strings.inc"

#macro Create_Spline_With_Remembered_Points(List)
  #local Size=dimension_size(List,1);
  #local A=array[3];
  #local A[0]=array[1];
  #local A[1]=array[Size];
  #local A[2]=array[Size];
  #local C=0;
  #while (C<Size)
    #local V=<List[C].x,List[C].y,List[C].z>;
    #local T=List[C].t;
    #local A[0][0]=spline{ #if(C) A[0][0] #end T , V };
    #local A[1][C]=T;
    #local A[2][C]=V;
    #local C=C+1;
  #end
  A
#end

#macro Get_Spline_Dimension(Extended_Spline_Structure)
  dimension_size(Extended_Spline_Structure[1],1)
#end

#macro Get_Nth_T_Param(N,Extended_Spline_Structure)
  (
  #if(N<Get_Spline_Dimension(Extended_Spline_Structure))
    Extended_Spline_Structure[1][N]
  #else
    #error "Index for spline out of range"
  #end
  )
#end

#macro Get_Nth_Control_Point(N,Extended_Spline_Structure)
  (
  #if(N<Get_Spline_Dimension(Extended_Spline_Structure))
    Extended_Spline_Structure[2][N]
  #else
    #error "Index for spline out of range"
  #end
  )
#end

#macro Evaluate_Extended_Spline(T,Extended_Spline_Structure)
  (Extended_Spline_Structure[0][0](T))
#end

#local Extended_Spline=Create_Spline_With_Remembered_Points(
  // 4D components where 4th one is time parameter
  array[3]{
    <1,0,0,-.5>
    <0,1,0,0>
    <0,0,1,.5>
  }
);

#local Size=Get_Spline_Dimension(Extended_Spline);
#local Param=Get_Nth_T_Param(1,Extended_Spline);
#local ControlPoint=Get_Nth_Control_Point(1,Extended_Spline);
#local Point=Evaluate_Extended_Spline(.25,Extended_Spline);

#debug concat("number of control points: ",str(Size,0,0),"\n")
#debug concat("second control point: ",str(Param,0,-1),
              ",",VStr(ControlPoint),"\n")
#debug concat("evaluated point: s(.25)=",VStr(Point),"\n")

ABX

[hughes, b ] Re: Realistic Looking Water (plane) [8470 days 5 hours and 21 minutes ago]

Sat, 25 Jan 2003 18:21:26 GMT

"Optium" <Opt### [at] coxnet> wrote in message
news:3e31701b$1@news.povray.org...
> I'll remember to post in a different group next time :P but thanks alot
for
> the link, I know Christoph's page is a nice page, but I had never seen a
> water tutorial on it before. Anyway, thanks again for the help, it's
GREATLY
> appreciated.

Welcome to my help (if and when it is), anytime.

Bob

[Optium] Re: Realistic Looking Water (plane) [8471 days 6 hours and 47 minutes ago]

Fri, 24 Jan 2003 16:55:55 GMT

I'll remember to post in a different group next time :P but thanks alot for
the link, I know Christoph's page is a nice page, but I had never seen a
water tutorial on it before. Anyway, thanks again for the help, it's GREATLY
appreciated.
-Optium

"hughes, b." <omn### [at] charternet> wrote in message
news:3e30bcf0@news.povray.org...
> Yes, many have asked, many have tried, some have succeeded, others have
> failed. *sigh*
>
> But anyway... :-)  "realistic" usually means you either need to employ
> fresnel reflection and a media or fog or fade_color into the water object.
> Or... also use a isosurface instead of a plain plane.
>
> Here's one tutorial: http://www-public.tu-bs.de:8080/~y0013390/pov/water/
>
> POV news groups hint:
> It can be much better to ask questions at povray.newusers or
povray.general
> than in these specific places which are intended for posting the type of
> items as per the group name, e.g. a tutorial  :-)
> You can get more visibility at the higher traffic groups and it's kind of
> mentioned in the FAQ group about it anyhow.
>
>

[hughes, b ] Re: Realistic Looking Water (plane) [8471 days 19 hours and 31 minutes ago]

Fri, 24 Jan 2003 04:11:28 GMT

Yes, many have asked, many have tried, some have succeeded, others have
failed. *sigh*

But anyway... :-)  "realistic" usually means you either need to employ
fresnel reflection and a media or fog or fade_color into the water object.
Or... also use a isosurface instead of a plain plane.

Here's one tutorial: http://www-public.tu-bs.de:8080/~y0013390/pov/water/

POV news groups hint:
It can be much better to ask questions at povray.newusers or povray.general
than in these specific places which are intended for posting the type of
items as per the group name, e.g. a tutorial  :-)
You can get more visibility at the higher traffic groups and it's kind of
mentioned in the FAQ group about it anyhow.

[Optium] Realistic Looking Water (plane) [8471 days 20 hours and 33 minutes ago]

Fri, 24 Jan 2003 03:09:43 GMT

Hello, I'm looking for any suggestions on how to make a realistic looking
water plane. I'm sure someone has probably posted about this in the past,
but I can't find any posts on it as of yet. If anyone has input or a link to
another post like this, I'd greatly appreciate it.

Thanks,
Optium

[Kitsune e] Re: Media [8473 days 5 hours and 43 minutes ago]

Wed, 22 Jan 2003 18:00:16 GMT

Robert Chaffe wrote:
>--
>> how to use media in POV.
>
>Meanwhile, perhaps the following might be a good start.
>
>This one appears to be written for version 3.1 but might be useful anyway:
>http://www.3dluvr.com/intercepto/pov_tuto.htm
>
>--
>Robert Chaffe
>http://www.donovansweb.com/~chaffe/
>

Yes!  This is a very clear tutorial, introducing both the syntax and
advanced methods for using media.  This is exactly what I have been looking
for and I would recommend it to anyone seeking to understand media!  I have
been struggling to control media for a couple months, but this tutorial
cleared up all my questions.

Thanks!

[hughes, b ] Re: How to make 3D letters [8474 days and 33 minutes ago]

Tue, 21 Jan 2003 23:09:44 GMT

"D" <dui### [at] hetnetnl> wrote in message
news:3e2dad67@news.povray.org...
> I have recorded a CD with my (hobby)band and want to design a CD cover.
> My idea is to use 3D letters to write our band name and wrap photographs
> around them.
>
> Does someone have (or knows a location to find) 3D fonts I can use,
> because I'm quite sure they must already excist (as include files).
>
> (I'm a new povray user, but can program C/C++)

Well... you can use any acceptable font file for a text object. TTF's for
example. What might prove difficult is placing images onto the letters,
other than simply plunking them on. UV mapping isn't possible for the text
object. Although, maybe using planar, spherical, toroidal and such would be
enough. You can also place the letters in various ways.

If you are wanting to have more control of the shape of the letters
themselves then you'll need to try something else. Have a look at the Links:
http://www.povray.org/resources/links/3D_Programs/Fonts_and_Font_Utilities/?
sort=alpha#s06_01_07

[D] How to make 3D letters [8474 days 3 hours and 14 minutes ago]

Tue, 21 Jan 2003 20:28:23 GMT

I have recorded a CD with my (hobby)band and want to design a CD cover.
My idea is to use 3D letters to write our band name and wrap photographs 
around them.

Does someone have (or knows a location to find) 3D fonts I can use, 
because I'm quite sure they must already excist (as include files).

(I'm a new povray user, but can program C/C++)

Regards,



Duije

[Txemi Jendrix] RE: moray view type [8547 days 6 hours and 8 minutes ago]

Sat, 9 Nov 2002 17:34:30 GMT

Jeff Kish escribió en el mensaje de noticias
TizNPWJtFVmMWTwAgJSTJ0Z5MjhT@4ax.com...
> Can someone point me to the option or whatever that enables the "view
> type" to become enabled so I can turn the SIDE frame into a camera
> view?

As Ken said, you should post this in 'moray.win'.
You'll get more and faster answers there (I don't
think there is a lot of "traffic" here).

Anyway, what I think you are trying to do is to
to convert you side view to a camera view directly
(making the location and look at of the side view
the location and look at of the camera).
Well, that's not possible in Moray, since
the Top, Front and Side views are orthographic
views and not related to the position and target
of your camera(s).
In the camera view you have to move your camera
to make the view change too.
You can move your camera as any other object
in the other three views to set its location and
look at. Your camera view chages while you
do that, so it's very easy and intuitive.
(You can also enter the numeric values directly
in the location and look at fields of the camera
object).
Hope this helps.
Bye.

Txemi Jendrix
http://www.txemijendrix.com

[Ken] Re: moray view type [8547 days 7 hours and 26 minutes ago]

Sat, 9 Nov 2002 16:16:44 GMT

Jeff Kish wrote:
> 
> Greetings.

Greetings.

> I am going through the moray tutorial (is it OK to ask a question of
> that here?).

It would be better to ask this question in the group called moray.win.
It should be visible in your list of news groups on this server. That
is where the majority of Moray users on this news server hang out and
they should be able to answer your question.

-- 
Ken Tyler

[Jeff Kish] moray view type [8547 days 7 hours and 58 minutes ago]

Sat, 9 Nov 2002 15:45:00 GMT

Greetings.

I am going through the moray tutorial (is it OK to ask a question of
that here?).

It says this: "Use the mouse or the transformation buttons to set the
spotlights position to {-10,0,10}. Now we'll rotate the spotlight,
which is currently facing straight down, to point at the sphere. To
control the orientation of the spot light visually we'll replace the
SIDE view with the 3D view of the SpotCam.

Right click while in the SIDE view. Select View Type and choose the
item SpotCam001. This view shows the scene as seen from the
spotlight's point of view (or illumination). "

But when I right click on the SIDE view all I get for menu choices
are:
enable snap, zoom to fit, zoom, pan, select, redraw, maximize, lock
grid, disable grid.

Can someone point me to the option or whatever that enables the "view
type" to become enabled so I can turn the SIDE frame into a camera
view?

Thanks
Jeff

[normdoering] Re: Can anyone show me the proper syntax for thi... [8547 days 14 hours and 23 minutes ago]

Sat, 9 Nov 2002 09:20:06 GMT

Warp wrote:
>normdoering <nor### [at] yahoocom> wrote:
>> #declare MyFunction = function{pattern {bumps scale 0.2}}
>>  // MyFunction above works...
>
>> #declare MyTest = function
>>  { pigment
>>    { image_map
>>      {png "testHF.png"
>>       map_type 0 interpolate 2
>>      }
>>     }
>>   } // <- this replacement produces an error.
>>     // shapes.inc pops up and marks the bit of code named above
>
>  The macros take functions which return scalars. You are trying to give
>it a function which returns colors, so it won't work.
>  What you need to do is to make a temporary function which will convert
>the color returned by MyTest() to a scalar. For example:
>
>#declare MyTestHeight = function { MyTest(x,y,z).hf }
>
>  Then you can give 'MyTestHeight' as parameter to the macro.

And ".hf" isn't the only dot operator. The others are listed in the
isosurface area. A little re-writting and you could submit two functions to
HF_ macros, one that gives the height information and one for cutting off
unused areas of the square. Maybe the .red, .green and .blue operators
could be used for coding undercuts.

normdoering

[Warp] Re: Can anyone show me the proper syntax for thi... [8548 days 8 hours and 43 minutes ago]

Fri, 8 Nov 2002 14:59:20 GMT

normdoering <nor### [at] yahoocom> wrote:
> #declare MyFunction = function{pattern {bumps scale 0.2}}
>  // MyFunction above works...

> #declare MyTest = function
>  { pigment
>    { image_map
>      {png "testHF.png"
>       map_type 0 interpolate 2
>      }
>     }
>   } // <- this replacement produces an error.
>     // shapes.inc pops up and marks the bit of code named above

  The macros take functions which return scalars. You are trying to give
it a function which returns colors, so it won't work.
  What you need to do is to make a temporary function which will convert
the color returned by MyTest() to a scalar. For example:

#declare MyTestHeight = function { MyTest(x,y,z).hf }

  Then you can give 'MyTestHeight' as parameter to the macro.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[normdoering] Can anyone show me the proper syntax for this... [8548 days 15 hours and 33 minutes ago]

Fri, 8 Nov 2002 08:10:03 GMT

I'm trying to use the HF_ functions in shapes.inc to generate a mesh from a
small .png file.

I simply added a new funtion to the example file given in the include files
demo. When I did, I got an error.



//==============================

#declare MyFunction = function{pattern {bumps scale 0.2}}
 // MyFunction above works...

#declare MyTest = function
 { pigment
   { image_map
     {png "testHF.png"
      map_type 0 interpolate 2
     }
    }
  } // <- this replacement produces an error.
    // shapes.inc pops up and marks the bit of code named above


object {
   HF_Square
    ( MyTest, // MyFunction was here, but I replaced it.
      off,
      off,
      <60,60>,
      on,
      "",
      <0.0, 0.1, 0.0>,
      <1.5, 0.5, 1.5>
    )
   texture {
      pigment {color rgb 1}
      finish {ShinyFinish}
   }
   translate <-3.0, 0.0,-3.2>
}

// ===========
// The error that happens pops up shapes.inc and a line in the
// HFCreate_() macro gets marked. See note below.
// ====
  #local J = 1;
   #while (J<=xRes)
      #local K = 1;
      #while (K<=zRes)
         PArr[J][K],   // <-- this code gets highlited in yellow
         #declare K = K+1;
      #end
      #declare J = J+1;
   #end

//====================================

What do I do to get an image file used as a function?

normdoering

[Tor Olav Kristensen] Re: How to transform a triangle into another [8584 days 23 hours and 49 minutes ago]

Wed, 2 Oct 2002 23:54:05 GMT

Tor Olav Kristensen wrote:
> 
> My first post to this group !
> 
> Peter Popov mentioned in this thread;
> http://news.povray.org/povray.advanced-users/27685/
> (25. September 2002. Subject: Re: Align box to splines)
> - the existence of a macro that transforms a triangle into another one.
> 
> I thought his was an interesting problem, so I just had to try to make
> such a macro. Below are the results.
>...

I just noticed that it was not wise of me to remove the vnormalize()
expressions from the 4 first lines in the Triangle2Triangle_Trans()
macro. Here's how these lines should be:

#local vFx = vnormalize(pA1 - pA0);
#local vLx = vnormalize(pB1 - pB0);
#local vFy = vcross(vFx, vnormalize(pA2 - pA0));
#local vLy = vcross(vLx, vnormalize(pB2 - pB0));


Tor Olav

[Tor Olav Kristensen] How to transform a triangle into another [8585 days and 1 minute ago]

Wed, 2 Oct 2002 23:41:55 GMT

My first post to this group !

Peter Popov mentioned in this thread;
http://news.povray.org/povray.advanced-users/27685/
(25. September 2002. Subject: Re: Align box to splines)
- the existence of a macro that transforms a triangle into another one.

I thought his was an interesting problem, so I just had to try to make
such a macro. Below are the results.

The code shows the macro and how it can be used. I have also shown how
to find a transformation that will transform a pyramid into another one.

Note that the transformation returned by the macro(s) can be used to
transform any POV object (not only triangles and pyramids.)

Comments or questions are welcome.


Tor Olav


// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
// Copyright 2002 by Tor Olav Kristensen
// Email: t o r _ o l a v _ k [ a t ] h o t m a i l. c o m
// http://home.no/t-o-k/povray
// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.5;
#include "colors.inc"
#include "transforms.inc"

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

// Macro for finding the transformation that will transform triangle A
// into triangle B
#macro Triangle2Triangle_Trans(pA0, pA1, pA2, pB0, pB1, pB2)

  #local vFx = pA1 - pA0;
  #local vLx = pB1 - pB0;
  #local vFy = vcross(vFx, pA2 - pA0);
  #local vLy = vcross(vLx, pB2 - pB0);
  #local vFz = vcross(vFx, vFy);
  #local vLz = vcross(vLx, vLy);
  #local TransF = Matrix_Trans(vFx, vFy, vFz, pA0)
  #local TransL = Matrix_Trans(vLx, vLy, vLz, pB0)
  #local InvTransF = transform { TransF inverse }
  #local InvTransL = transform { TransL inverse }
  #local p1F = vtransform(pA1, InvTransF);
  #local p1L = vtransform(pB1, InvTransL);
  #local p2F = vtransform(pA2, InvTransF);
  #local p2L = vtransform(pB2, InvTransL);
  #local Trans = transform { scale <p1L.x/p1F.x, 1, p2L.z/p2F.z> }
  #local SXZ = (p2L - vtransform(p2F, Trans)).x/p2L.z;
  #local Trans = transform { Trans Shear_Trans(x, y, z + SXZ*x) }

  transform { InvTransF Trans TransL }

#end // macro Triangle2Triangle_Trans


// Macro for finding transformation that will transform Pyramid A
// into Pyramid B
#macro Pyramid2Pyramid_Trans(pA0, pA1, pA2, pA3, pB0, pB1, pB2, pB3)

  #local vFx = pA1 - pA0;
  #local vLx = pB1 - pB0;
  #local vFy = vcross(vFx, pA2 - pA0);
  #local vLy = vcross(vLx, pB2 - pB0);
  #local vFz = vcross(vFx, vFy);
  #local vLz = vcross(vLx, vLy);
  #local TransF = Matrix_Trans(vFx, vFy, vFz, pA0)
  #local TransL = Matrix_Trans(vLx, vLy, vLz, pB0)
  #local InvTransF = transform { TransF inverse }
  #local InvTransL = transform { TransL inverse }
  #local p1F = vtransform(pA1, InvTransF);
  #local p1L = vtransform(pB1, InvTransL);
  #local p2F = vtransform(pA2, InvTransF);
  #local p2L = vtransform(pB2, InvTransL);
  #local p3F = vtransform(pA3, InvTransF);
  #local p3L = vtransform(pB3, InvTransL);
  #local Trans =
    transform { scale <p1L.x/p1F.x, p3L.y/p3F.y, p2L.z/p2F.z> }
  #local SXZ = (p2L - vtransform(p2F, Trans)).x/p2L.z;
  #local Trans = transform { Trans Shear_Trans(x, y, z + x*SXZ) }
  #local SZY = (p3L - vtransform(p3F, Trans)).z/p3L.y;
  #local Trans = transform { Trans Shear_Trans(x, y + z*SZY, z) }
  #local SXY = (p3L - vtransform(p3F, Trans)).x/p3L.y;
  #local Trans = transform { Trans Shear_Trans(x, y + x*SXY, z) }

  transform { InvTransF Trans TransL }

#end // macro Pyramid2Pyramid_Trans

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
// Example problem

// Initial position of triangle/pyramid
#declare pA0 = <2, 3, 1>;
#declare pA1 = <4, 3,  1>;
#declare pA2 = <5, 0, -2>;
#declare pA3 = <8, 7, -1>/2;

// Position to transform it into
#declare pB0 = <1, 5, 2>;
#declare pB1 = <-2, -2, -2>;
#declare pB2 = <-2, 3, -1>;
#declare pB3 = <1, 6, -5>/2;

// Indicate where it should end up
sphere { pB0, 0.1 pigment { color Red } }
sphere { pB1, 0.1 pigment { color Green } }
sphere { pB2, 0.1 pigment { color Blue } }
sphere { pB3, 0.1 pigment { color Black } }


#declare pAmid = (pA0 + pA1 + pA2)/3;

#declare RingTexture =
  texture {
    pigment {
      object {
        difference {
          sphere { pAmid, 0.42 }
          sphere { pAmid, 0.37 }
        }
        color White
        color Blue
      }
    }
  }


#declare TriangleA =
  union {
    triangle {
      pA0, pA1, pA2
      texture { RingTexture }
    }
    sphere {
      pAmid, 0.2
      pigment { color Blue + Grey }
    }
  }

TriangleA


#declare TriangleB = 
  object {
    TriangleA
    Triangle2Triangle_Trans(
      pA0, pA1, pA2,
      pB0, pB1, pB2
    )
  }

TriangleB


#declare PyramidA =
  union {
    sphere { pA0, 0.04 }
    sphere { pA1, 0.04 }
    sphere { pA2, 0.04 }
    sphere { pA3, 0.04 }
    cylinder { pA0, pA3, 0.04 }
    cylinder { pA1, pA3, 0.04 }
    cylinder { pA2, pA3, 0.04 }
    pigment { color White*2 } 
  }

PyramidA


#declare PyramidB =
  object {
    PyramidA
    Pyramid2Pyramid_Trans(
      pA0, pA1, pA2, pA3,
      pB0, pB1, pB2, pB3
    )
  }

PyramidB

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

light_source {
  <10, 5, -10>
  color White
  shadowless
}

background { color Gray30 }

cylinder { 0*x, 10*x, 0.03 pigment { color Red } }
cylinder { 0*y, 10*y, 0.03 pigment { color Green } }
cylinder { 0*z, 10*z, 0.03 pigment { color Blue } }

camera {
  location <4, 2, -8>
  look_at <1, 1, 0>
  
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
/*

// Macro for solving system of 3 equations with 3 unknowns
#macro S3E3U(vA, vB, vC, vD)

  (<vdot(vD, vcross(vB, vC)),
    vdot(vA, vcross(vD, vC)),
    vdot(vA, vcross(vB, vD))>/
    vdot(vA, vcross(vB, vC)))

#end // macro S3E3U


// Macro for finding the transformation that will transform triangle A
// into triangle B (Does only work properly on _flat_ triangles)
#macro TriangleToTriangle_Trans(pA0, pA1, pA2, pB0, pB1, pB2)

  #local vX = <pA0.x, pA1.x, pA2.x>;
  #local vY = <pA0.y, pA1.y, pA2.y>;
  #local vZ = <pA0.z, pA1.z, pA2.z>;
  #local v0 = S3E3U(vX, vY, vZ, <pB0.x, pB1.x, pB2.x>);
  #local v1 = S3E3U(vX, vY, vZ, <pB0.y, pB1.y, pB2.y>);
  #local v2 = S3E3U(vX, vY, vZ, <pB0.z, pB1.z, pB2.z>);

  transform {
    matrix <
      v0.x, v1.x, v2.x,
      v0.y, v1.y, v2.y,
      v0.z, v1.z, v2.z,
         0,    0,    0
    >
  }

#end // macro TriangleToTriangle_Trans

*/
// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

[Robert Chaffe] Re: Media [8586 days 22 hours and 58 minutes ago]

Tue, 1 Oct 2002 00:44:28 GMT

"jfmiller" <jfm### [at] hotmailcom> wrote in message
news:3d8a1857@news.povray.org...
> With all dew deference to the work put into the Pov documentation, it
would
> be really helpfull if someone could write a clear and compleate tutorial
on
> how to use media in POV.

Meanwhile, perhaps the following might be a good start.

This one appears to be written for version 3.1 but might be useful anyway:
http://www.3dluvr.com/intercepto/pov_tuto.htm

Here is a wonderful tutorial for realistic water.  The "interior" chapter
has notes on media:
http://www-public.tu-bs.de:8080/~y0013390/pov/water/index.html

--
Robert Chaffe
http://www.donovansweb.com/~chaffe/

[jfmiller] Media [8598 days 5 hours and 10 minutes ago]

Thu, 19 Sep 2002 18:32:55 GMT

With all dew deference to the work put into the Pov documentation, it would
be really helpfull if someone could write a clear and compleate tutorial on
how to use media in POV.

JFMILLER

[Warp] Re: Reflection blur [8630 days 19 hours and 58 minutes ago]

Sun, 18 Aug 2002 03:44:33 GMT

jfmiller <jfm### [at] hotmailcom> wrote:
> I have read of several examples of using texture_map with slightly different
> normals to make a reflection appear blury.  I've tried to replicate this but
> I can't seem to get it to work.  Can someone post some source code or a
> tutorial on how this is done?

http://www.students.tut.fi/~warp/povQandT/languageQandT.html#blurredreflection

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

[jfmiller] Reflection blur [8631 days 4 hours and 25 minutes ago]

Sat, 17 Aug 2002 19:17:30 GMT

Hi all,

I have read of several examples of using texture_map with slightly different
normals to make a reflection appear blury.  I've tried to replicate this but
I can't seem to get it to work.  Can someone post some source code or a
tutorial on how this is done?

Thanks
JFMILLER

[hughes b] Re: Help on doing a plastic lamp shade [8640 days and 24 minutes ago]

Thu, 8 Aug 2002 23:18:29 GMT

"Wade" <Zav### [at] aolcom> wrote in message news:3d52d522@news.povray.org...
> I'd like to learn how make a plastic-marblized lamp shade.

Hi there Wade.

Basically you would use a filtered pigment with a color pattern applied. A
not too technical a lampshade  like that is just:

cone {0,1,y,0.5
texture {
 pigment {marble // pattern needed, could be any
  color_map {
    [0/4 color rgbf <0,0,1,1>]
    [1/4 color rgbf <0,0,1,1>] // sharp boundaries...
    [1/4 color rgbf <1,0,1,1>] // ...by duplicating index
    [2/4 color rgbf <1,0,1,1>]
    [2/4 color rgbf <1,0,0,1>]
    [3/4 color rgbf <1,0,0,1>]
    [3/4 color rgbf <1,1,0,1>]
    [4/4 color rgbf <1,1,0,1>]
    }
 turbulence 0.5 // less for straighter lines... more is gnarled
 scale 0.25 // reduce pattern size for this cone
  }
 }
    finish {ambient 0.2 diffuse 0.5
                specular 0.5 roughness 0.05} // typical plastic appearance
}

Not to get too elaborate or anything. The idea is to filter the light
through colors just like in the real world. If the shade itself isn't
looking lit well enough you can try adding more ambient to the finish to get
it brighter. To get the walls and stuff around the shade to show the colors
better more filter value (4th float in the rgbf vector) could be used but
ambient would need to be lowered then. Opposite if wanted the other way of
course.

There are a number of ways to go about making a lampshade but maybe this is
a start. There are probably several examples already someplace
(www.povray.org search?) but I didn't check for any.

P.S.

You'd have tapped in to more people at povray.general than the two tutorial
groups.

<'netiquette>Also, "multi-posting" isn't looked upon as acceptable, it
leaves the same or similar message to be read again looking like a new
message. Cross-posting at two groups (usually not more), however, can be
done with one message and then not be marked unread when the readers move to
another group.
Simple append the other group name after the first (MS Outlook for example:
Newsgroups: povray.general;povray.text.tutorials).</'netiquette>

All the guidelines can be found at
povray.announce.frequently-asked-questions

[Wade] Help on doing a plastic lamp shade [8640 days 3 hours and 11 minutes ago]

Thu, 8 Aug 2002 20:31:30 GMT

I'd like to learn how make a plastic-marblized lamp shade.

Wade
__________________________________________________________________ Wade
Markham ICQ#: 44258048 Current ICQ status: + More ways to contact me i See
more about me:
__________________________________________________________________

[Francois Labreque] Re: what is moray and megapov? [8641 days 7 hours and 36 minutes ago]

Wed, 7 Aug 2002 16:06:41 GMT

Philip Jensen wrote:
> I've seen both of them mentioned a lot of times here in this group, but what
> is it, and where can I get it?

<short answer>
Moray is a modeller that outputs to POV.  It is available at: 
http://www.stmuc.com/moray/

Megapov is a collection of patches and nifty features built aroung 
POV-Ray 3.1g.  Many of these features have now been included in POV-Ray 
3.5.  It is available at:
http://nathan.kopp.com/patched.htm
</short answer>

> oh yes and is it free?

Yes.  Although you can (and probably should) register Moray to help Lutz 
pay his bills.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   videotron.ca  */}camera{orthographic location<6,1.25,-6>look_at a }

[Philip Jensen] what is movray and megapov? [8641 days 7 hours and 59 minutes ago]

Wed, 7 Aug 2002 15:44:09 GMT

I've seen both of them mentioned a lot of times here in this group, but what
is it, and where can I get it?

oh yes and is it free?

[PovRay] Splines... [8642 days 23 hours and 57 minutes ago]

Mon, 5 Aug 2002 23:45:44 GMT

Does anyone out there know of a good spline tutorial.. I'm thinking this is
where I need to go on my next POV Learning journey... :)

I got a spline editor.. but I would like to know HOW they work before using
it..

Thanks so much.
Dave


--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d+ s:>:+++ a-- C+++(++++) ULU++ P+++$ L++>++++ E+++ W+++(++)$ N+ o>+
K++>++++++ w++>$ O- M-- V-- PS+ PE+++ Y+>++ PGP++>+ t+++(*) 5 X+>++ R>++
tv++(+++) b+++ DI++++ D+ G>+++ e>++ h----() r+++ y++++**
------END GEEK CODE BLOCK------

(David Bates)
Sr. Program Analysist
Sr. Web Design Engineer/Programmer
Cedar Rapids, IA - 52404

[ABX] Re: isomaze tutorial [8648 days 15 hours and 48 minutes ago]

Wed, 31 Jul 2002 07:54:52 GMT

On Wed, 31 Jul 2002 09:40:15 +0200, "Philippe Lhoste" <Phi### [at] GMXnet> wrote:
> Thanks for this source, it is a worthwhile study.

Let me repeat follow original post: I wait for large renders and amazing
animations :-)

ABX

[Philippe Lhoste] Re: isomaze tutorial [8648 days 16 hours and 1 minute ago]

Wed, 31 Jul 2002 07:41:23 GMT

"ABX" <abx### [at] babilonorg> wrote:
> On Mon, 05 Nov 2001 15:44:06 +0100, W³odzimierz ABX Skiba
<abx### [at] babilonorg> wrote:
> > #declare
f_box=function{f_torus_1(x,y,z)|f_torus_2(x,y,z)|f_torus_3(x,y,z)}
>
> to use this script in final 3.5 it is necessary to change this line to
>
> #declare
f_box=function{min(f_torus_1(x,y,z),f_torus_2(x,y,z),f_torus_3(x,y,z))}
>
> ABX

OK, that's *much* better :-)
I was about to write to ask why all I got was an uniform light green image
:-)

Thanks for this source, it is a worthwhile study.

-- #=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=# --
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

[ABX] Re: isomaze tutorial [8648 days 17 hours and 23 minutes ago]

Wed, 31 Jul 2002 06:19:30 GMT

On Mon, 05 Nov 2001 15:44:06 +0100, W³odzimierz ABX Skiba <abx### [at] babilonorg>
wrote:
> #declare f_box=function{f_torus_1(x,y,z)|f_torus_2(x,y,z)|f_torus_3(x,y,z)}

to use this script in final 3.5 it is necessary to change this line to

#declare f_box=function{min(f_torus_1(x,y,z),f_torus_2(x,y,z),f_torus_3(x,y,z))}

ABX

[] Re: include files with references [8671 days 11 hours and 3 minutes ago]

Mon, 8 Jul 2002 12:39:37 GMT

On Mon, 08 Jul 2002 14:22:44 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> The URL could also point to a zip
> including documentation and sample scenes which would have to be unpacked
> by POV-Ray.

And author's favourite MP3 ;-)

ABX

[Christoph Hormann] Re: include files with references [8671 days 11 hours and 20 minutes ago]

Mon, 8 Jul 2002 12:22:44 GMT

"W³odzimierz ABX Skiba" wrote:
> 
> Perhaps it could depend where 'directory/' folder is applied: with URL or with
> file name itself. I mean:

This is exactly what i meant, you need to have two strings, one for the
include file and one for the URL.  The URL could also point to a zip
including documentation and sample scenes which would have to be unpacked
by POV-Ray.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 30 Jun. 2002 _____./\/^>_*_<^\/\.______

[] Re: include files with references [8671 days 11 hours and 48 minutes ago]

Mon, 8 Jul 2002 11:55:10 GMT

On Mon, 08 Jul 2002 13:43:14 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> So would
>
> "http://www.what.ever/directory/file.inc"
>
> make POV-Ray try to #include "file.inc" or "directory/file.inc"?

Perhaps it could depend where 'directory/' folder is applied: with URL or with
file name itself. I mean:

Include(
  "iso_csg.inc" ,
  "http://www-public.tu-bs.de:8080/~y0013390/pov/ic/" ,
  defined( iso_CSG_Inc_Temp )
)

or

Include(
  "pov/ic/iso_csg.inc" ,
  "http://www-public.tu-bs.de:8080/~y0013390/" ,
  defined( iso_CSG_Inc_Temp )
)

ABX

[Christoph Hormann] Re: include files with references [8671 days 12 hours ago]

Mon, 8 Jul 2002 11:43:14 GMT

"W³odzimierz ABX Skiba" wrote:
> 
> > But this would always download the file, even if it is available on the
> > local machine.
> 
> ... with additional apropriate test first :-)
> 

So would

"http://www.what.ever/directory/file.inc"

make POV-Ray try to #include "file.inc" or "directory/file.inc"?

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 30 Jun. 2002 _____./\/^>_*_<^\/\.______

[] Re: include files with references [8671 days 13 hours and 31 minutes ago]

Mon, 8 Jul 2002 10:11:22 GMT

On Mon, 08 Jul 2002 11:54:43 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:

> > I considered this one day and it could be enough to extend file names to
> > accept urls just like http://www.php.net/manual/en/function.include.php.
> 
>
> But this would always download the file, even if it is available on the
> local machine.

... with additional apropriate test first :-)

(and additionaly similiar to
http://www.php.net/manual/en/function.include-once.php)

ABX

[Christoph Hormann] Re: include files with references [8671 days 13 hours and 48 minutes ago]

Mon, 8 Jul 2002 09:54:43 GMT

"W³odzimierz ABX Skiba" wrote:
> 
> I considered this one day and it could be enough to extend file names to
> accept urls just like http://www.php.net/manual/en/function.include.php.
> 

But this would always download the file, even if it is available on the
local machine.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 30 Jun. 2002 _____./\/^>_*_<^\/\.______

[] Re: include files with references [8671 days 13 hours and 58 minutes ago]

Mon, 8 Jul 2002 09:44:46 GMT

On Mon, 08 Jul 2002 11:26:30 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> Interesting, further improvement could be to add an automatic downloading
> function to Povray retrieving the include file from the specified URL in
> such a case.

I considered this one day and it could be enough to extend file names to
accept urls just like http://www.php.net/manual/en/function.include.php.

ABX

[Christoph Hormann] Re: include files with references [8671 days 14 hours and 16 minutes ago]

Mon, 8 Jul 2002 09:26:30 GMT

"W³odzimierz ABX Skiba" wrote:
> 
> Very simple and ready for other improvements addition. If you distribute your
> scripts over world (ie for IRTC) and use include files from other authors you
> can be interested in unioned inclusion control system. Take a look at below
> macro:

Interesting, further improvement could be to add an automatic downloading
function to Povray retrieving the include file from the specified URL in
such a case.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 30 Jun. 2002 _____./\/^>_*_<^\/\.______

[] include files with references [8671 days 14 hours and 34 minutes ago]

Mon, 8 Jul 2002 09:09:10 GMT

Very simple and ready for other improvements addition. If you distribute your
scripts over world (ie for IRTC) and use include files from other authors you
can be interested in unioned inclusion control system. Take a look at below
macro:

example usage:

Include(
  "iso_csg.inc" ,
  "http://www-public.tu-bs.de:8080/~y0013390/pov/ic/" ,
  defined( iso_CSG_Inc_Temp )
)

macro itself:

#version 3.5;
// Include subsystem by ABX (abx### [at] abxartpl) '2002
// Feel free to copy, save and use
// Parameters:
//   IncludeFile - string with name of the file to be included
//   URL         - string link to the page (or directly to zip/pov/inc)
//                 where included file were originally published,
//                 empty string when no place to obtain
//   Included    - boolean result of test whether include file was already
//                 included before, if you can't test it put 'no' there,
//                 usually you can use defined() function to test any of
//                 identifiers from this include file
#macro Include( IncludeFile , URL , Included )
  #if(Included)
    #ifdef(View_POV_Include_Stack)
      #debug concat(IncludeFile," already included\n")
    #end
  #else
    #if(file_exists(IncludeFile))
      #include IncludeFile
    #else
      #debug concat("Warning: ",IncludeFile," is not included. Scripts may not work as
expected becouse\n")
      #debug concat("         identifiers, variables, macros from ",IncludeFile," are
not declared.\n")
      #if(strlen(URL))
        #debug concat("         ",IncludeFile," can be downloaded from ",URL,"\n")
      #end
      #ifdef(View_POV_Include_Stack)
        #debug "         Check that the file is in a directory specifed with a +L
switch\n"
        #debug "         or 'Library_Path=' .INI item. Standard include files are in
the\n"
        #debug "         include directory or folder. Please read your documentation
carefully.\n"
      #end
    #end
  #end
#end

ABX

[Jonathan Wooldridge] Re: Tips & tricks: How speed-up calculations in ... [8711 days 22 hours and 51 minutes ago]

Wed, 29 May 2002 00:52:00 GMT

<jwo### [at] attbicom> wrote:
> > No sooner said than done!
> > // Script without so many locals ("Spam, spam, spam and eggs spam hasn't
got
> > too much spam in it"...)
> > #local C=1000000;
> > #while(C)
> >    do_stuff( C );
> >    do_stuff( C - 1 );
> >    do_stuff( C - 2 );
> >    ...
> >    do_stuff( C - 8 );
> >    do_stuff( C - 9 );
> >    do_stuff( C - 10 );
> >    #local C = C - 10;
> > #end
>
> Are you aware that calling macro usually isn't faster than perform float
> #local in current pov parser ?
>
> ABX

The do_stuff( x - y) statements are place holders, they are not meant to
represent an additional macro call. Think of them as pseudo-code, in order
to discuss the topic. If you had planned to execute a sphere{} instruction a
million times, then replace the do_stuff statements with sphere{} statements
TEN times (for the last guy who pointed out an off-by-one error).

As far as performance between declaring a variable, and calling a macro, I
haven't written anything to test that out.

[] Re: Tips & tricks: How speed-up calculations in ... [8713 days 15 hours and 30 minutes ago]

Mon, 27 May 2002 08:13:11 GMT

On Sat, 25 May 2002 18:38:58 -0700, "Jonathan Wooldridge"
<jwo### [at] attbicom> wrote:
> No sooner said than done!
> // Script without so many locals ("Spam, spam, spam and eggs spam hasn't got
> too much spam in it"...)
> #local C=1000000;
> #while(C)
>    do_stuff( C );
>    do_stuff( C - 1 );
>    do_stuff( C - 2 );
>    ...
>    do_stuff( C - 8 );
>    do_stuff( C - 9 );
>    do_stuff( C - 10 );
>    #local C = C - 10;
> #end

Are you aware that calling macro usually isn't faster than perform float
#local in current pov parser ?

ABX

[Warp] Re: Tips & tricks: How speed-up calculations in ... [8714 days 20 hours and 40 minutes ago]

Sun, 26 May 2002 03:02:45 GMT

Jonathan Wooldridge <jwo### [at] attbicom> wrote:
>     do_stuff( C );
>     do_stuff( C - 1 );
>     do_stuff( C - 2 );
>     ...
>     do_stuff( C - 8 );
>     do_stuff( C - 9 );
>     do_stuff( C - 10 );

  You are doing 11 things there, not 10.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[Jonathan Wooldridge] Re: Tips & tricks: How speed-up calculations in ... [8714 days 22 hours and 5 minutes ago]

Sun, 26 May 2002 01:37:37 GMT

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3ceff8e4@news.povray.org...
> Jonathan Wooldridge <jwo### [at] attbicom> wrote:
> > #local C=C-1;
> > // Do stuff with C
>
> > #local C=C-1;
> > // Do stuff with C
>
>   If you can get rid of those #locals and do only one #local C=C-10 at the
> end of the loop, better.
>

No sooner said than done!

// Script without so many locals ("Spam, spam, spam and eggs spam hasn't got
too much spam in it"...)
#local C=1000000;
#while(C)
    do_stuff( C );
    do_stuff( C - 1 );
    do_stuff( C - 2 );
    ...
    do_stuff( C - 8 );
    do_stuff( C - 9 );
    do_stuff( C - 10 );

    #local C = C - 10;
#end

[Warp] Re: Tips & tricks: How speed-up calculations in ... [8715 days 2 hours and 53 minutes ago]

Sat, 25 May 2002 20:49:41 GMT

Jonathan Wooldridge <jwo### [at] attbicom> wrote:
> #local C=C-1;
> // Do stuff with C

> #local C=C-1;
> // Do stuff with C

  If you can get rid of those #locals and do only one #local C=C-10 at the
end of the loop, better.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

[Jonathan Wooldridge] Re: Tips & tricks: How speed-up calculations in ... [8715 days 3 hours and 13 minutes ago]

Sat, 25 May 2002 20:29:51 GMT

> >
> >  One of the oldest tricks known, loop unrolling, should speed up as
well.
>
> Nobody likes unrolling 1000000 iterations ;-)
>

Loop unrolling isn't about coding every iteration, for that very reason.
Doing an unroll of a loop reduces the number of passes for the loop.

If you have a million iterations, then there is some overhead for each of a
million passes through the loop.
You can reduce this by a factor of ten, by unrolling the loop ten times
within the loop.

Try timing this:

// Unrolled Script
#local C=1000000;
#while(C)
#local C=C-1;
// Do stuff with C

#local C=C-1;
// Do stuff with C

#local C=C-1;
// Do stuff with C

#local C=C-1;
// Do stuff with C

#local C=C-1;
// Do stuff with C

#local C=C-1;
// Do stuff with C

#local C=C-1;
// Do stuff with C

#local C=C-1;
// Do stuff with C

#local C=C-1;
// Do stuff with C

#local C=C-1;
// Do stuff with C

#end

[] new type of spline: sor_spline [8738 days 16 hours and 32 minutes ago]

Thu, 2 May 2002 07:10:33 GMT

Following documentation and some math calculations I have replicated shape of
sor as spline/function. For given height (value along y axis) it returns
radius. Like for other splines heights below first valid point return first
valid radius and above last valid point return last valid radius. Call below
macro with the same set of points as in sor object. NOTE: Macro/function not
validate points! If you want array validation just make sor{} before this
macro and parser will tell you if points are incorrect. I have used the same
symbols as in 6.5.1.12 chapter so reading/investigating source should be easy.
Of course 3.5 compatible. Any comments ?

#macro sor_spline(Array)
  #local N=dimension_size(Array,1);
  #local a=array[N][2];
  #local n=N;
  #while (n)
    #local n=n-1;
    #local a[n][0]=Array[n].u;
    #local a[n][1]=Array[n].v;
  #end
  function(h){
    select(
      h-a[1][1],
      a[1][0],
      #local n=2;
      #while (n<N-1)
        #local b0=a[n-1][0]^2;
        #local b1=a[n][0]^2;
        #local b2=2*a[n-1][0]*(a[n][0]-a[n-2][0])/
                  (a[n][1]-a[n-2][1]);
        #local b3=2*a[n][0]*(a[n+1][0]-a[n-1][0])/
                  (a[n+1][1]-a[n-1][1]);
        #local M00=a[n-1][1]^3;
        #local M01=a[n-1][1]^2;
        #local M02=a[n-1][1];
        #local M10=a[n][1]^3;
        #local M11=a[n][1]^2;
        #local M12=a[n][1];
        #local M20=3*a[n-1][1]^2;
        #local M21=2*a[n-1][1];
        #local M30=3*a[n][1]^2;
        #local M31=2*a[n][1];
        #local M2131=M21-M31;
        #local M1101=M11-M01;
        #local M1202=M12-M02;
        #local M1101_1=M1101-M31*M1202;
        #local M1101_2=M21*M1202-M1101;
        #local A=((b0-b1)*M2131+b2*M1101_1+b3*M1101_2)/
                 ((M00-M10)*M2131+M20*M1101_1+M30*M1101_2);
        #local B=(b2-b3+A*(M30-M20))/M2131;
        #local C=b3-M30*A-M31*B;
        #local D=b1-M10*A-M11*B-M12*C;
        select(
          h-a[n][1],
          (A*h^3+B*h^2+C*h+D)^.5,
        #local n=n+1;
      #end
      a[N-2][0]
      #local n=2;#while(n<N-1))#local n=n+1;#end
    )
  }
#end

ABX

[Mike Williams] Transparency Maps [8745 days 3 hours and 19 minutes ago]

Thu, 25 Apr 2002 20:23:51 GMT

I've added a page on using Poser Transparency Maps to my Poser to POVRay
tutorial <http://www.econym.demon.co.uk/posetut/>.

[Although transparency maps were introduced in Poser 4, there's no
reason why you can't do the same thing in POV when working with Poser 3
models.]

-- 
Mike Williams
Gentleman of Leisure

[Miaou] Re: 2 questions [8760 days 3 hours and 56 minutes ago]

Wed, 10 Apr 2002 19:46:54 GMT

use heigh_field.
Use agate-bozo-wrinkle pattern for casual waves
Draw your own boat wave above. (Layered picture can help making tests)

"Drethon Tolar" <the### [at] yahoocom> a écrit dans le message news:
3c7e4f2c$1@news.povray.org...
> can someone tell me how or where to find
>
> #1 tutorials on image maping?
>
> #2 how to put two textures on an object, ex waves on a lake plus waves due
> to a boat on that lake?
>
> Thanx
>
>

[Frauke Smit] Re: Realistic landscape [8768 days 3 hours and 28 minutes ago]

Tue, 2 Apr 2002 20:14:48 GMT

Try Forrester.

 http://www.dartnall.co.uk/


John Bauman <bau### [at] ptdprolognet> schreef in berichtnieuws
37b728c0@news.povray.org...
> Does anyone know how to create a realistic landscape, with flat
> plateaus(sp?)?
>
> --
> webpage: http://johntb.freeservers.com
> ICQ:20886467 AIM:Qbwiz
> -----BEGIN GEEK CODE BLOCK-----
>  Version: 3.12
> G! d- s--:- a---- C++ ULU++++ P+  L+ E W++ N++ o K- w+
> O! M- V- PS PE+ Y+ PGP- t+@ 5 X R tv+ b++ DI++++ D-
> G e-- h! !r y-
> ------END GEEK CODE BLOCK------
>
>

[] Re: Yeaah! I got it to work!! [8795 days 7 hours and 52 minutes ago]

Wed, 6 Mar 2002 15:51:14 GMT

On Wed, 6 Mar 2002 09:32:35 -0600, "Shay" <sah### [at] simcopartscom> wrote:
> Thank you again, ABX. It seems that you are always waiting in a dark corner
> ready to jump out with a formula the way Ken is with a link.

but.... I have posted link too

> I never went to college, so most of the math I know is self tought. This
> leaves BIG holes in my math knowledge.

I love math. That's why 8th birthday of my dayghter will be 08.08.08 :-)

> The formula you supplied will help a lot, because I will henceforth be
> adding a "weighted" switch to all of my vertex normalizing macros.

I strongly suggest to implement it as function to speed it up:

#include "functions.inc"
#local triangle_area_engine=function{(x+y+z)*(y+z-x)*(x+y-z)*(x+z-y)/16}
#local triangle_area=
  function(x1,y1,z1,x2,y2,z2,x3,y3,z3)
    {sqrt(triangle_area_engine(
        f_r(x2-x1,y2-y1,z2-z1),
        f_r(x3-x2,y3-y2,z3-z2),
        f_r(x3-x1,y3-y1,z3-z1)
    ))};

all you need is to call this function with coordinates of vertices
(be careful - not tested)

it is general advice so I'm crossposting this to text.tutorials with
follow-ups to p.b.i as previously

ABX

[Drethon Tolar] 2 questions [8801 days 8 hours and 3 minutes ago]

Thu, 28 Feb 2002 15:39:24 GMT

can someone tell me how or where to find

#1 tutorials on image maping?

#2 how to put two textures on an object, ex waves on a lake plus waves due
to a boat on that lake?

Thanx

[Warp] Re: Isosurface Tutorial Update [8807 days 13 hours and 35 minutes ago]

Fri, 22 Feb 2002 10:07:35 GMT

Soulstorm <der### [at] gomailcoza> wrote:
> I get that from iso-*surfaces*

  All objects in POV-Ray are surfaces. There are no solid objects.

  (Don't confuse "hollow" with this. It's a completely different context.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

[Soulstorm] Re: Isosurface Tutorial Update [8807 days 13 hours and 46 minutes ago]

Fri, 22 Feb 2002 09:56:25 GMT

OK,

I see now that they do have interiors.

Thanx
-ss-

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3c7602fe@news.povray.org...
> Soulstorm <der### [at] gomailcoza> wrote:
> > one more thing, just for interest sake - is it at all possible to have
> > isosufaces with interiors? for instance a waterblob floating in space
with
> > ior?
>
> > I would suppose not, but it would be nice to know if it can be done...
>
>   Why do you suppose that isosurfaces have no interior?
>
> --
> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb
x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// -
Warp -

[Soulstorm] Re: Isosurface Tutorial Update [8807 days 14 hours and 16 minutes ago]

Fri, 22 Feb 2002 09:26:41 GMT

I get that from iso-*surfaces*
just a guess, though
-ss-

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3c7602fe@news.povray.org...
> Soulstorm <der### [at] gomailcoza> wrote:
> > one more thing, just for interest sake - is it at all possible to have
> > isosufaces with interiors? for instance a waterblob floating in space
with
> > ior?
>
> > I would suppose not, but it would be nice to know if it can be done...
>
>   Why do you suppose that isosurfaces have no interior?
>
> --
> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb
x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// -
Warp -

[Warp] Re: Isosurface Tutorial Update [8807 days 15 hours and 7 minutes ago]

Fri, 22 Feb 2002 08:36:14 GMT

Soulstorm <der### [at] gomailcoza> wrote:
> one more thing, just for interest sake - is it at all possible to have
> isosufaces with interiors? for instance a waterblob floating in space with
> ior?

> I would suppose not, but it would be nice to know if it can be done...

  Why do you suppose that isosurfaces have no interior?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[Warp] Re: surface deformations [8807 days 15 hours and 44 minutes ago]

Fri, 22 Feb 2002 07:58:31 GMT

Soulstorm <der### [at] gomailcoza> wrote:
> I don't think it's the same problem as with bending...

> The normals are created with mathematical formulae, same with the
> primitives - I am sure with the right combination of these two it would be
> quite possible to do true surface deforms. The problem with bending is that
> the mathematics behind bending a mathematical abstract is supposedly very
> complex.

  It *is* basically the same problem as in bending: You need to calculate
the intersection of a ray and a non-linearly transformed surface.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[Soulstorm] Re: Isosurface Tutorial Update [8807 days 15 hours and 46 minutes ago]

Fri, 22 Feb 2002 07:57:14 GMT

This answers my questions about surface deforms!!

one more thing, just for interest sake - is it at all possible to have
isosufaces with interiors? for instance a waterblob floating in space with
ior?

I would suppose not, but it would be nice to know if it can be done...
-ss-
"Mike Williams" <mik### [at] nospamplease> wrote in message
news:WQU### [at] econymdemoncouk...
>
> I've rushed through an update of my Isosurface Tutorial to include the
> isosurface syntax used in POV-Ray 3.5 beta 1.
>
> All the example source files are now available in both MegaPOV and POV
> 3.5b1 formats. The main text now follows 3.5b1 syntax with the
> significant MegaPOV differences highlighted.
>
> Absolute beginners to isosurfaces would benefit by looking through the
> isosurface tutorial pages included in the 3.5b1 documentation before
> digging too deep into my pages.
>
> I'm sure that there are still lots of new tricks that can be done with
> 3.5b1 that were not possible with MegaPOV, and I'll be updating the
> tutorial as I find them.
>
> It's at <http://www.econym.demon.co.uk/isotut/index.htm>
>
> --
> Mike Williams
> Gentleman of Leisure

[Soulstorm] Re: surface deformations [8807 days 16 hours and 32 minutes ago]

Fri, 22 Feb 2002 07:10:36 GMT

Hi Jamie,

Your comment seems to be the most helpful of the lot. It set me thinking -
maybe some formulae for blobs along a sperical surface with some sine
deformations thrown in. hmm...back to work.

btw. for anyone reading this thread there is a nice tutorial on sine
deformations here :
http://www.f-lohmueller.de/pov_tut/loop/povsi3e1.htm

thanks
-ss-

"Jamie Davison" <jam### [at] ntlworldcom> wrote in message
news:MPG.16df6892a2cc2c91989ae1@news.povray.org...
> On Thu, 21 Feb 2002 16:40:50 +0200, Soulstorm wrote...
> > Is it possible in POVRay to do true surface deformations?
> > i.e. not normal maps, but true deforms.
>
> If you knew the formula of the primitive and the formula for the
> deformation, I suspect you could use an isosurface, but as to exactly
> how.  Well, that's beyond my skills.
>
> Bye for now,
>      Jamie.

[Soulstorm] Re: surface deformations [8807 days 16 hours and 46 minutes ago]

Fri, 22 Feb 2002 06:57:10 GMT

Sorry - I still can't find it in the vfaq. Nor can I find
'povray.announce.frequently-asked-questions' which is why I posted the
question. I assume now that the answer is no.

A simple 'yes' or 'no' would have done.

thanks

"W³odzimierz ABX Skiba" <abx### [at] babilonorg> wrote in message
news:em2a7ucas61d8gajilhnm22bnc725n5ssr@4ax.com...
> On Thu, 21 Feb 2002 16:40:50 +0200, "Soulstorm" <der### [at] gomailcoza>
> wrote:
> > Is it possible in POVRay to do true surface deformations?
> > i.e. not normal maps, but true deforms.
>
> look at http://news.povray.org/povray.general/22382/
>
> (is this answered in vfaq?)
>
> ABX

[Soulstorm] Re: surface deformations [8807 days 16 hours and 54 minutes ago]

Fri, 22 Feb 2002 06:48:29 GMT

I don't think it's the same problem as with bending...

The normals are created with mathematical formulae, same with the
primitives - I am sure with the right combination of these two it would be
quite possible to do true surface deforms. The problem with bending is that
the mathematics behind bending a mathematical abstract is supposedly very
complex.

Well - I am not a maths guru, so if I am wrong, it won't surprize me too
much - it would be nice to know though...

-ss-

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3c750e72@news.povray.org...
> W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> : (is this answered in vfaq?)
>
>   It's the same problem as with bending:
>
> http://www.students.tut.fi/~warp/povQandT/languageQandT.html#bending

[Jamie Davison] Re: surface deformations [8808 days 3 hours and 16 minutes ago]

Thu, 21 Feb 2002 20:27:12 GMT

On Thu, 21 Feb 2002 16:40:50 +0200, Soulstorm wrote...
> Is it possible in POVRay to do true surface deformations?
> i.e. not normal maps, but true deforms.

If you knew the formula of the primitive and the formula for the 
deformation, I suspect you could use an isosurface, but as to exactly 
how.  Well, that's beyond my skills.

Bye for now,
     Jamie.

[Warp] Re: surface deformations [8808 days 8 hours and 30 minutes ago]

Thu, 21 Feb 2002 15:12:50 GMT

W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
: (is this answered in vfaq?)

  It's the same problem as with bending:

http://www.students.tut.fi/~warp/povQandT/languageQandT.html#bending

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[] Re: surface deformations [8808 days 8 hours and 38 minutes ago]

Thu, 21 Feb 2002 15:04:49 GMT

On Thu, 21 Feb 2002 16:40:50 +0200, "Soulstorm" <der### [at] gomailcoza>
wrote:
> Is it possible in POVRay to do true surface deformations?
> i.e. not normal maps, but true deforms.

look at http://news.povray.org/povray.general/22382/

(is this answered in vfaq?)

ABX

[Soulstorm] surface deformations [8808 days 9 hours and 1 minute ago]

Thu, 21 Feb 2002 14:42:06 GMT

Is it possible in POVRay to do true surface deformations?
i.e. not normal maps, but true deforms.

Thanks
-ss-

[] Re: Tips & tricks: How speed-up calculations in ... [8818 days 10 hours and 53 minutes ago]

Mon, 11 Feb 2002 12:49:54 GMT

On 11 Feb 2002 07:43:27 -0500, Warp <war### [at] tagpovrayorg> wrote:
> : Nobody likes unrolling 1000000 iterations ;-)
>
>  That's not what loop unrolling means.

Oh, I misunderstand your answer.

>  It means that you take a divisor of the number of loops to perform and
> "unroll" the body of the loop that many times and decrease the loop index by
> that amount.

But this can still cooperate with both my advises.

ABX

[] Re: Tips & tricks: How speed-up calculations in ... [8818 days 10 hours and 58 minutes ago]

Mon, 11 Feb 2002 12:44:44 GMT

On Mon, 11 Feb 2002 13:31:52 +0100, Jérôme Grimbert
<jer### [at] atosorigincom> wrote:
> > Nobody likes unrolling 1000000 iterations ;-)
>
> But what is then the shell for ?

It was general experiment to show: 
"if you have to use loop then use it this way becouse it's faster"

If there is no need to use loop then of course
this experiment has nothing to do.

I hope there are other users who appreciate result of this experiment.

> PS: Given that there is nothing in your loop, what about
> #local C=0;
> #local C=100000;
> Instead ?

What about one line version: 

#local C=1e6;

instead ?

ABX

[Warp] Re: Tips & tricks: How speed-up calculations in ... [8818 days 10 hours and 59 minutes ago]

Mon, 11 Feb 2002 12:43:27 GMT

W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
: Nobody likes unrolling 1000000 iterations ;-)

  That's not what loop unrolling means.
  It means that you take a divisor of the number of loops to perform and
"unroll" the body of the loop that many times and decrease the loop index by
that amount.
  That is, if your loop is something like:

#declare Ind = 1000000;
#while(Ind)
  do_something()
  #declare Ind = Ind-1;
#end

you convert it to something like:

#declare Ind = 1000000;
#while(Ind)
  do_something()
  do_something()
  do_something()
  do_something()
  do_something()
  do_something()
  do_something()
  do_something()
  do_something()
  do_something()
  #declare Ind = Ind-10;
#end

  This should parse faster.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[Jérôme Grimbert] Re: Tips & tricks: How speed-up calculations in ... [8818 days 11 hours and 11 minutes ago]

Mon, 11 Feb 2002 12:31:43 GMT

"W³odzimierz ABX Skiba" wrote:
> 
> On 11 Feb 2002 07:18:33 -0500, Warp <war### [at] tagpovrayorg> wrote:
> > : Any comments ?
> >
> >  One of the oldest tricks known, loop unrolling, should speed up as well.
> 
> Nobody likes unrolling 1000000 iterations ;-)

But what is then the shell for ?
I can use it to generate the 1000000 iteration steps... a big file.
but that's about only 80 megs for a single step of 80 chars.

Upto 2 Giga, there should not be any problem.

PS: Given that there is nothing in your loop, what about

#local C=0;
#local C=100000;

Instead ?

-- 
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 !

[] Re: Tips & tricks: How speed-up calculations in ... [8818 days 11 hours and 18 minutes ago]

Mon, 11 Feb 2002 12:25:17 GMT

On 11 Feb 2002 07:18:33 -0500, Warp <war### [at] tagpovrayorg> wrote:
> : Any comments ?
>
>  One of the oldest tricks known, loop unrolling, should speed up as well.

Nobody likes unrolling 1000000 iterations ;-)

ABX

[Warp] Re: Tips & tricks: How speed-up calculations in ... [8818 days 11 hours and 24 minutes ago]

Mon, 11 Feb 2002 12:18:33 GMT

W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
: Any comments ?

  One of the oldest tricks known, loop unrolling, should speed up as well.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

[] Tips & tricks: How speed-up calculations in loop... [8818 days 12 hours and 4 minutes ago]

Mon, 11 Feb 2002 11:39:01 GMT

Inspired by the result of previous test I've made another benchmark:
How functions speed-up simplest expressions - in this case I wondered what
about loop indexing.

I compared speed of two scripts:

//SCRIPT 1
#local dec=function(N){N-1};
#local C=1000000;
#while(C)
#local C=dec(C);
#end

and

//SCRIPT 2
#local C=1000000;
#while(C)
#local C=C-1;
#end

Note difference: first script use function to decrease value of parameter.
Both scripts were started three times on PII 233 with 128 MB (3.5 b 11).
Result: measuring CPU time first script was little faster then second about:
- kernel time: 5,64%
- user time: 11,00%
- total time: 9,38%

Then I compared the same replacement for increased index of loop.

//SCRIPT 3
#local inc=function(N){N+1};
#local C=0;
#while(C<1000000)
#local C=inc(C);
#end

and

//SCRIPT 4
#local C=0;
#while(C<1000000)
#local C=C+1;
#end

In this case there is no difference in speed. It changed from test to test. It
was around +/- 2%. Not big deal in this case.

Additional note: there was the same number of interations but version with
decreasing was faster (20-30%) than version with increasing (probably becouse
of no additional tokens in loop condition).

Any comments ?

ABX

[Warp] Re: Tips & tricks: How speed-up calculations in ... [8824 days 6 hours and 50 minutes ago]

Tue, 5 Feb 2002 16:52:55 GMT

W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
: external macro       - 1026,47 [s]
: internal macro       -  350,73 [s]

  As I thought.

  This means that if you are using some #included macros in really tight
loops which are taking lots of time to parse, you'd better just copy-paste
the used macros from the include file to the beginning of the current file
to gain parsing speed.

: external function    -  179,62 [s]
: internal function    -  178,68 [s]

  This was also predictable and good to know: Functions in #included files
are not slower than functions in the current file, so they can be used
without worries.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

[] Re: Tips & tricks: How speed-up calculations in ... [8824 days 7 hours and 10 minutes ago]

Tue, 5 Feb 2002 16:32:38 GMT

On Mon, 28 Jan 2002 16:56:02 +0100, W³odzimierz ABX Skiba <abx### [at] babilonorg>
wrote:
> I want to compare speed between macro calculation, inline calculation and
> function calculation. All tests are performed with currrent (10) beta of POV-Ray
> 3.5 for Windows (icl) on PII 233 with 128 MB and. Here are scripts:

Here is result of extended test made after Warp's suggestions:

Total CPU time used was measured in seconds.
The same machine, script and calculation was used.
Every scene was started 3 times. result was averaged.
Two loops as earlier but with max. 1000 so, it was 1.000.000 use of calculation:

external macro       - 1026,47 [s]
internal macro       -  350,73 [s]
calculation on-place -  221,15 [s]
external function    -  179,62 [s]
internal function    -  178,68 [s]

ABX

[] trivial but useful [8824 days 11 hours and 58 minutes ago]

Tue, 5 Feb 2002 11:44:58 GMT

(for 3.5)

Just two simple and trivial functions but added to math.inc are very usefull
(and probably faster in parsing and executing then whole expression or macro):

#local even=function(N){select(int(N/2)-N/2,0,1,0)};
#local odd=function(N){even(N+1)};

and small example to test it:

#macro Test(T)
  #local S=str(T,0,(int(T)=T?0:-1));
  #if(even(T))
    #debug concat( S , " is even.\n")
  #end
  #if(!even(T))
    #debug concat( S , " isn't even.\n")
  #end
  #if(odd(T))
    #debug concat( S , " is odd.\n")
  #end
  #if(!odd(T))
    #debug concat( S , " isn't odd.\n")
  #end
#end

Test(1)
Test(1.5)
Test(2)

ABX

[JRG] Re: Tips & tricks: How speed-up calculations in ... [8830 days 1 hour and 9 minutes ago]

Wed, 30 Jan 2002 22:33:49 GMT

"W³odzimierz ABX Skiba" wrote:
> I will do it. At this moment I fill sick and I'll be absent one week probably
> (depends on doctor's decision).

Does this mean that I'll have to wait some more for those spaghetti?
Hope you feel better soon.

--
#local j=text{ttf"arial""JRG".2,0}#local J=0;#while(J<10)#local R=0;#while
(R<2)#local G=0;#while(G<1)#if(inside(j<R,G.1>))object{j scale.025translate
<R-1G-J/20J/-40+2>pigment{rgb<9J>}}#debug"O"#else#debug" "#end#local G=G+
.025;#end#local R=R+.05;#debug"\n"#end#local J=J+1;#end// JRG

Home: http://digilander.iol.it/jrgpov  //New: Kitchen scene WIP

[] Re: Tips & tricks: How speed-up calculations in ... [8832 days 6 hours and 12 minutes ago]

Mon, 28 Jan 2002 17:30:38 GMT

On 28 Jan 2002 11:59:21 -0500, Warp <war### [at] tagpovrayorg> wrote:
>  You should also compare the speed when the macro is defined in an include
> file instead of the same scene file (in theory it should be much slower).
>  It would also be interesting to see what happens if the function is defined
> in an external include file (AFAIK there should not be speed difference, but
> who knows?).

I will do it. At this moment I fill sick and I'll be absent one week probably
(depends on doctor's decision).

ABX

[Warp] Re: Tips & tricks: How speed-up calculations in ... [8832 days 6 hours and 43 minutes ago]

Mon, 28 Jan 2002 16:59:21 GMT

You should also compare the speed when the macro is defined in an include
file instead of the same scene file (in theory it should be much slower).
  It would also be interesting to see what happens if the function is defined
in an external include file (AFAIK there should not be speed difference, but
who knows?).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[] Tips & tricks: How speed-up calculations in loops [8832 days 7 hours and 46 minutes ago]

Mon, 28 Jan 2002 15:56:35 GMT

Please don't answer with "nothing new. I use it so long". I use it so long, too.
I just want to make benchmark and result is some kind of tips&trick thing.

I want to compare speed between macro calculation, inline calculation and
function calculation. All tests are performed with currrent (10) beta of POV-Ray
3.5 for Windows (icl) on PII 233 with 128 MB and. Here are scripts:

// SCRIPT 1 - Macro calculation

#macro Calc(X,Y)sin(X)+Y+cos(X*Y)^2+1/3#end
#local MaxX=500;
#local MaxY=500;
#local X=0;
#while(X<MaxX)
  #local Y=0;
  #while(Y<MaxY)
    #local D=Calc(X,Y);
    #local Y=Y+1;
  #end
  #local X=X+1;
#end

// SCRIPT 2 - inline calculation

#local MaxX=500;
#local MaxY=500;
#local X=0;
#while(X<MaxX)
  #local Y=0;
  #while(Y<MaxY)
    #local D=sin(X)+Y+cos(X*Y)^2+1/3;
    #local Y=Y+1;
  #end
  #local X=X+1;
#end

// SCRIPT 3 - function calculations

#local Calc=function(X,Y){sin(X)+Y+cos(X*Y)^2+1/3};
#local MaxX=500;
#local MaxY=500;
#local X=0;
#while(X<MaxX)
  #local Y=0;
  #while(Y<MaxY)
    #local D=Calc(X,Y);
    #local Y=Y+1;
  #end
  #local X=X+1;
#end

// RESULTS

// SCRIPT 1 - macro calculations
CPU time used: kernel 20.79 seconds, user 74.22 seconds, total 95.01 seconds

// SCRIPT 2 - inline calculations
CPU time used: kernel 9.74 seconds, user 47.34 seconds, total 57.08 seconds

// SCRIPT 3 - function calculations
CPU time used: kernel 8.95 seconds, user 37.78 seconds, total 46.74 seconds

ABX

[Rune] Re: Particle systems?? [8847 days 1 hour and 30 minutes ago]

Sun, 13 Jan 2002 22:12:28 GMT

"Dennis Milller" wrote:
> Have you "released" it yet or is it still under development?

Still under development...

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Jan 2)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

[JRG] Re: Basic Particle System. [8848 days 1 hour and 39 minutes ago]

Sat, 12 Jan 2002 22:03:47 GMT

Fine. Posted to p.b.s-f. I can write a tutorial if requested.
Cheers.

--
#local j=text{ttf"arial""JRG".2,0}#local J=0;#while(J<10)#local R=0;#while
(R<2)#local G=0;#while(G<1)#if(inside(j<R,G.1>))object{j scale.025translate
<R-1G-J/20J/-40+2>pigment{rgb<9J>}}#debug"O"#else#debug" "#end#local G=G+
.025;#end#local R=R+.05;#debug"\n"#end#local J=J+1;#end// JRG

Home: http://digilander.iol.it/jrgpov  //New: Kitchen scene WIP

[Dennis Milller] Re: Particle systems?? [8848 days 20 hours and 1 minute ago]

Sat, 12 Jan 2002 03:41:29 GMT

Have you "released" it yet or is it still under development?
d.

"Rune" <run### [at] mobilixnetdk> wrote in message
news:3c3e358c@news.povray.org...
> "Dayv" wrote:
> > Can anyone out there offer an explaination of
> > particle systems in laymens' terms?
>
> There's a little bit of information on my own particle system on this
page:
> http://rsj.mobilixnet.dk/3d/anims/particlesystem/particlesystem.html
>
> Don't know if that's what you're looking for though...
>
> Rune
> --
> 3D images and anims, include files, tutorials and more:
> Rune's World:    http://rsj.mobilixnet.dk (updated Jan 2)
> POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
> POV-Ray Webring: http://webring.povray.co.uk
>
>

[Dennis Milller] Re: Basic Particle System. [8848 days 20 hours and 3 minutes ago]

Sat, 12 Jan 2002 03:40:12 GMT

I'm happy with a Mega version for now. Send it on over!
Thanks,
Dennis
"JRG" <jrg### [at] hotmailcom> wrote in message
news:3c3e1970@news.povray.org...
> I've written the basic particle system requested. Still have to write a
little
> example.
> There's only one (quite serious I fear) problem. It always crashes with
the present
> beta (works fine with MegaPov). Surely a bug.
> So, there are two options:
>
> 1) I could post the code 'as is', but it wouldn't be that useful without a
little
> explanation (though it's very simple), and you'd have to use MegaPov (no
particular
> MegaPov feature is used, as I said, it simply crashes with the present
beta for
> Windows.)
>
> 2) I could wait and write a little tutorial to explain how this simple
system works.
>
> Nothing prevents me to post the code first and to write the tutorial
afterwards, if
> you find it fine :)
>
> Would you like the system to handle animations too?
>
>
> --
> #local j=text{ttf"arial""JRG".2,0}#local J=0;#while(J<10)#local R=0;#while
> (R<2)#local G=0;#while(G<1)#if(inside(j<R,G.1>))object{j
scale.025translate
> <R-1G-J/20J/-40+2>pigment{rgb<9J>}}#debug"O"#else#debug" "#end#local G=G+
> .025;#end#local R=R+.05;#debug"\n"#end#local J=J+1;#end// JRG
>
> Home: http://digilander.iol.it/jrgpov  //New: Kitchen scene WIP
>
>
>

[Rune] Re: Particle systems?? [8849 days 22 hours and 58 minutes ago]

Fri, 11 Jan 2002 00:45:00 GMT

"Dayv" wrote:
> Can anyone out there offer an explaination of
> particle systems in laymens' terms?

There's a little bit of information on my own particle system on this page:
http://rsj.mobilixnet.dk/3d/anims/particlesystem/particlesystem.html

Don't know if that's what you're looking for though...

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Jan 2)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

[JRG] Basic Particle System. [8850 days and 58 minutes ago]

Thu, 10 Jan 2002 22:45:04 GMT

I've written the basic particle system requested. Still have to write a little
example.
There's only one (quite serious I fear) problem. It always crashes with the present
beta (works fine with MegaPov). Surely a bug.
So, there are two options:

1) I could post the code 'as is', but it wouldn't be that useful without a little
explanation (though it's very simple), and you'd have to use MegaPov (no particular
MegaPov feature is used, as I said, it simply crashes with the present beta for
Windows.)

2) I could wait and write a little tutorial to explain how this simple system works.

Nothing prevents me to post the code first and to write the tutorial afterwards, if
you find it fine :)

Would you like the system to handle animations too?


--
#local j=text{ttf"arial""JRG".2,0}#local J=0;#while(J<10)#local R=0;#while
(R<2)#local G=0;#while(G<1)#if(inside(j<R,G.1>))object{j scale.025translate
<R-1G-J/20J/-40+2>pigment{rgb<9J>}}#debug"O"#else#debug" "#end#local G=G+
.025;#end#local R=R+.05;#debug"\n"#end#local J=J+1;#end// JRG

Home: http://digilander.iol.it/jrgpov  //New: Kitchen scene WIP

[Dayv] Re: What is wrong with this??? [8850 days 5 hours and 6 minutes ago]

Thu, 10 Jan 2002 18:36:19 GMT

duh... I forgot to close it up!  should have been 8 points!  sigh.  That's
what I get for writing pov code at 2am!

Thanks!
-Dayv


"W³odzimierz ABX Skiba" <abx### [at] babilonorg> wrote in message
news:kboq3uonjmoe0c1aaehn9m4b10o2ad9ml4@4ax.com...
> On Thu, 10 Jan 2002 01:51:33 -0500, "Dayv" <gda### [at] homecom>
wrote:
>
> > Why do I get "error:  Too few points in prism." ??  I said 7 points.. I
see
> > 7 points... what's the deal??
>
> Works fine when you change 6th point with value of 2nd.
>
> analyze comments from 3.5 documentation example, note where is <0,0>
>
> prism {
>    cubic_spline
>    0, 1, 7,
>    <1,-1>, <0,0>, <6,0>, //outer rim; First control is <1,-1> and
>    <6,8>, <0,8>, <0,0>,  //<0,0> is first & last point.
>    <-1,1>,               //Last control of first spline is <-1,1>
>  }
>
> "In the cubic_spline, each sub-prism needs two additional control
points -- one
> at the beginning of each sub-prisms' point sequence to determine the slope
at
> the start of the curve and one at the end. The first point specified is
the
> control point which is not actually part of the spline. The second point
is the
> start of the spline. The sub-prism ends when this second point is
duplicated.
> The next point is the control point of the end of the first sub-prism.
Next is
> the beginning control point of the next sub-prism. The point after that is
the
> first point of the second sub-prism."
>
> ABX

[] Re: What is wrong with this??? [8850 days 14 hours ago]

Thu, 10 Jan 2002 09:43:00 GMT

On Thu, 10 Jan 2002 01:51:33 -0500, "Dayv" <gda### [at] homecom> wrote:

> Why do I get "error:  Too few points in prism." ??  I said 7 points.. I see
> 7 points... what's the deal??

Works fine when you change 6th point with value of 2nd.

analyze comments from 3.5 documentation example, note where is <0,0>

prism {
   cubic_spline
   0, 1, 7,
   <1,-1>, <0,0>, <6,0>, //outer rim; First control is <1,-1> and
   <6,8>, <0,8>, <0,0>,  //<0,0> is first & last point.
   <-1,1>,               //Last control of first spline is <-1,1>
 }

"In the cubic_spline, each sub-prism needs two additional control points -- one
at the beginning of each sub-prisms' point sequence to determine the slope at
the start of the curve and one at the end. The first point specified is the
control point which is not actually part of the spline. The second point is the
start of the spline. The sub-prism ends when this second point is duplicated.
The next point is the control point of the end of the first sub-prism. Next is
the beginning control point of the next sub-prism. The point after that is the
first point of the second sub-prism."

ABX

[Dayv] What is wrong with this??? [8850 days 16 hours and 42 minutes ago]

Thu, 10 Jan 2002 07:00:36 GMT

Why do I get "error:  Too few points in prism." ??  I said 7 points.. I see
7 points... what's the deal??

prism {
        cubic_spline
        0,
        1,
        7,
        <-3, -4>,
        <-3,  3>,
        < 2,  4>,
        < 2,  0>,
        < 3, -4>,
        <-3, -4>,
        < 2,  4>
        pigment {
                color green 1
        }
}

[JRG] Re: Particle systems?? [8853 days 5 hours and 28 minutes ago]

Mon, 7 Jan 2002 18:14:35 GMT

Ok, I will write a little tutorial about it next week (I have an exam on thursday
:-( )

--
#local j=text{ttf"arial""JRG".2,0}#local J=0;#while(J<10)#local R=0;#while
(R<2)#local G=0;#while(G<1)#if(inside(j<R,G.1>))object{j scale.025translate
<R-1G-J/20J/-40+2>pigment{rgb<9J>}}#debug"O"#else#debug" "#end#local G=G+
.025;#end#local R=R+.05;#debug"\n"#end#local J=J+1;#end// JRG

Home: http://digilander.iol.it/jrgpov  //New: Kitchen scene WIP

[Dayv] Re: Particle systems?? [8853 days 17 hours and 40 minutes ago]

Mon, 7 Jan 2002 06:02:33 GMT

Sure!  Like I've said, I'm not very skilled, but I have an insatiable
curiosity.  :)
-Dayv

"JRG" <jrg### [at] hotmailcom> wrote in message
news:3c38ea1c@news.povray.org...
> If you want I can write and provide you a very basic scene to start with.
Do you?
>
>
> --
> #local j=text{ttf"arial""JRG".2,0}#local J=0;#while(J<10)#local R=0;#while
> (R<2)#local G=0;#while(G<1)#if(inside(j<R,G.1>))object{j
scale.025translate
> <R-1G-J/20J/-40+2>pigment{rgb<9J>}}#debug"O"#else#debug" "#end#local G=G+
> .025;#end#local R=R+.05;#debug"\n"#end#local J=J+1;#end// JRG
>
> Home: http://digilander.iol.it/jrgpov  //New: Kitchen scene WIP
>
> "Dayv" <gda### [at] homecom> ha scritto nel messaggio
> news:3c367c3f$1@news.povray.org...
> > Can anyone out there offer an explaination of particle systems in
laymens'
> > terms?  Don't expect to understand them fully enough to be designing my
> > own... seems over my head.  But maybe some background on how the whole
thing
> > works?
> >
> > Thanks,
> > Dayv
> >
> >
>
>

[Dennis Milller] Re: Particle systems?? [8853 days 22 hours and 7 minutes ago]

Mon, 7 Jan 2002 01:36:16 GMT

I'd love to see the same.
Best,
D.

"JRG" <jrg### [at] hotmailcom> wrote in message
news:3c38ea1c@news.povray.org...
> If you want I can write and provide you a very basic scene to start with.
Do you?
>
>
> --
> #local j=text{ttf"arial""JRG".2,0}#local J=0;#while(J<10)#local R=0;#while
> (R<2)#local G=0;#while(G<1)#if(inside(j<R,G.1>))object{j
scale.025translate
> <R-1G-J/20J/-40+2>pigment{rgb<9J>}}#debug"O"#else#debug" "#end#local G=G+
> .025;#end#local R=R+.05;#debug"\n"#end#local J=J+1;#end// JRG
>
> Home: http://digilander.iol.it/jrgpov  //New: Kitchen scene WIP
>
> "Dayv" <gda### [at] homecom> ha scritto nel messaggio
> news:3c367c3f$1@news.povray.org...
> > Can anyone out there offer an explaination of particle systems in
laymens'
> > terms?  Don't expect to understand them fully enough to be designing my
> > own... seems over my head.  But maybe some background on how the whole
thing
> > works?
> >
> > Thanks,
> > Dayv
> >
> >
>
>

[JRG] Re: Particle systems?? [8853 days 23 hours and 21 minutes ago]

Mon, 7 Jan 2002 00:21:48 GMT

If you want I can write and provide you a very basic scene to start with. Do you?


--
#local j=text{ttf"arial""JRG".2,0}#local J=0;#while(J<10)#local R=0;#while
(R<2)#local G=0;#while(G<1)#if(inside(j<R,G.1>))object{j scale.025translate
<R-1G-J/20J/-40+2>pigment{rgb<9J>}}#debug"O"#else#debug" "#end#local G=G+
.025;#end#local R=R+.05;#debug"\n"#end#local J=J+1;#end// JRG

Home: http://digilander.iol.it/jrgpov  //New: Kitchen scene WIP

"Dayv" <gda### [at] homecom> ha scritto nel messaggio
news:3c367c3f$1@news.povray.org...
> Can anyone out there offer an explaination of particle systems in laymens'
> terms?  Don't expect to understand them fully enough to be designing my
> own... seems over my head.  But maybe some background on how the whole thing
> works?
>
> Thanks,
> Dayv
>
>

[Dayv] Particle systems?? [8855 days 19 hours and 34 minutes ago]

Sat, 5 Jan 2002 04:08:31 GMT

Can anyone out there offer an explaination of particle systems in laymens'
terms?  Don't expect to understand them fully enough to be designing my
own... seems over my head.  But maybe some background on how the whole thing
works?

Thanks,
Dayv

[Ken] Re: Intersection tutorial (10-sided die) [8857 days 21 hours and 4 minutes ago]

Thu, 3 Jan 2002 02:38:52 GMT

Jerold Stratton wrote:

> Comments, of course, welcome.

Long time no see. Glad you had a chance to check in with us.

-- 
Ken Tyler

[Jerold Stratton] Intersection tutorial (10-sided die) [8858 days 5 hours and 40 minutes ago]

Wed, 2 Jan 2002 18:02:49 GMT

Yes, a new boring incredibly simple tutorial: making a 10-sided die using
the intersection of planes.

Not sure how long I'm back for, I'm posting this with trn under Mac OS X.
Don't let Steve Jobs fool you, Mac OS X will not *truly* be ready for real
world use until MT-Newswatcher is available for it. I know it's a huge
weight on Simon Fraser's shoulders, but you just have to live with the
times you're born in.

Oh, I suppose I'd better let you know the URL:

http://www.hoboes.com/NetLife/POV/Die10/

Comments, of course, welcome.

Jerry
http://www.godsmonsters.com/

[s1631001] Re: Isosurface Tutorial Update [8892 days 3 hours and 45 minutes ago]

Thu, 29 Nov 2001 19:57:20 GMT

While I was looking at http://www.econym.demon.co.uk/isotut/nfunc2.htm ,
the second item claims to be a quantum-mechanical function. I'm a
physics student myself, and I don't recall ever having seen it; the
image above it, however looks VERY familiar! A 3-d version of an
electron density function. Someone's gotten confused, but don't worry;
it's not you.

Mike Williams wrote:
> 
> I've rushed through an update of my Isosurface Tutorial to include the
> isosurface syntax used in POV-Ray 3.5 beta 1.
> 
> All the example source files are now available in both MegaPOV and POV
> 3.5b1 formats. The main text now follows 3.5b1 syntax with the
> significant MegaPOV differences highlighted.
> 
> Absolute beginners to isosurfaces would benefit by looking through the
> isosurface tutorial pages included in the 3.5b1 documentation before
> digging too deep into my pages.
> 
> I'm sure that there are still lots of new tricks that can be done with
> 3.5b1 that were not possible with MegaPOV, and I'll be updating the
> tutorial as I find them.
> 
> It's at <http://www.econym.demon.co.uk/isotut/index.htm>
> 
> --
> Mike Williams
> Gentleman of Leisure

-- 
signature{
  "Grey Knight"
  contact{
    email "gre### [at] yahoocom"
  }
  site_of_week{
    url "http://mathworld.wolfram.com"
  }
}

[Philip Bartol] Re: brick texture [8899 days 17 hours and 43 minutes ago]

Thu, 22 Nov 2001 06:00:04 GMT

Shawn F. Nerenberg wrote:

>I have the same problem, with a reproduction of the Etemenaki (commonly
>known as the Tower of Babel) Built to scale, it is a rather large
>structure, and I was hoping to keep the bricks to scale, without the
>moire patterns. This isn't a real problem for closeups, but scene shots
>showing the temple compounds are going to look awfully funky. any way to
>work around this without compromising on texture scale?  

I created a Lighthouse a while back.... brick pattern for the round tower. 
The texture works great when closeup, but at a distance it looked way to 
funky...

The solution I came up with was to use some setting in my files for some 
options and assign alternate textures for different items.... for instance, 
if I'm doing a long shot of the whole 100+ foot tower I'm never going to 
get a good brick texture, but a nice granite with the proper colors works 
wonders :D

They had a similar problem when creating the 3rd Myst game (Myst 3: Exile) 
and where able to setup textures based on distance from the camera (feature 
of programming the software they used).... closeup and far away textures 
rather than just one.

PHIL

[] Re: isomaze tutorial [8914 days 15 hours and 8 minutes ago]

Wed, 7 Nov 2001 08:34:31 GMT

On Tue, 6 Nov 2001 21:51:14 -0500, "Dennis Milller" <dhm### [at] mediaonenet>
wrote:

> Sorry, but this would not render for me. I got an error pointing to the
> line:
>
>  function{f_box(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))}
>
>
> Any ideas?

Function f_box() was used in original scene. I renamed this to f_part() within
main part of tutorial. Sorry.

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

[Bob H ] Re: isomaze tutorial [8914 days 19 hours and 44 minutes ago]

Wed, 7 Nov 2001 03:58:49 GMT

"Dennis Milller" <dhm### [at] mediaonenet> wrote in message
news:3be8a298$1@news.povray.org...
> Sorry, but this would not render for me. I got an error pointing to the
> line:
>
>   function{f_box(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))}

Rendered here.  At least, the last full scene portion of the tutorial did.

Bob H.

[Dennis Milller] Re: isomaze tutorial [8914 days 20 hours and 47 minutes ago]

Wed, 7 Nov 2001 02:55:20 GMT

Sorry, but this would not render for me. I got an error pointing to the
line:

  function{f_box(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))}


Any ideas?
thanks,
d.

"W³odzimierz ABX Skiba" <abx### [at] babilonorg> wrote in message
news:is3dutg17gbcfmmh5ij2r05msch59oqus7@4ax.com...
> Here is simple isomaze tutorial for POV 3.5. It is described in 3D. Some
of
> functions (f_torus, f_snoize) are defined in standard include file
> "functions.inc". Sorry for enigmatic sentences but it is my poor English.
I
> expect some isosurface experience from readers :-)
>
> Split 3D space to similiar parts. Simplest part is a box. So, every box
should
> contain the same content but mirrored. And should be smoothly joined by
putting
> connections in the center of the boxes. So, at first lets create simplest
box in
> the center. Centers of the boxes will be joined internally with parts of
> toruses.
>
> <SDL>
>
> #include "stdinc.inc"
>
> #declare Major=.5;
> #declare Minor=.03;
>
> #declare f_torus_1=function{f_torus(x-Major,y,z-Major,Major,Minor)}
> #declare f_torus_2=function{f_torus(x+Major,z,y-Major,Major,Minor)}
> #declare f_torus_3=function{f_torus(y+Major,x,z+Major,Major,Minor)}
>
> #declare
f_part=function{f_torus_1(x,y,z)|f_torus_2(x,y,z)|f_torus_3(x,y,z)}
>
> isosurface{
>   function{f_part(x,y,z)}
>   contained_by{box{-Major Major}}
>   }
>
> </SDL>
>
> Above is base shape. Now we must repeat this in all directions. We can do
it by
> going with all coordinates from any value to <-Major,Major> range. So we
must
> add function for coordinates, increase size of isosurface and change
function.
>
> <SDL>
> #include "stdinc.inc"
>
> #declare Range=3;
> #declare Major=.5;
> #declare Minor=.03;
>
> #declare f_coord=function(coord){coord-(floor(coord)+.5)}
>
> #declare f_torus_1=function{f_torus(x-Major,y,z-Major,Major,Minor)}
> #declare f_torus_2=function{f_torus(x+Major,z,y-Major,Major,Minor)}
> #declare f_torus_3=function{f_torus(y+Major,x,z+Major,Major,Minor)}
>
> #declare
f_part=function{f_torus_1(x,y,z)|f_torus_2(x,y,z)|f_torus_3(x,y,z)}
>
> isosurface{
>   function{f_part(f_coord(x),f_coord(y),f_coord(z))}
>   contained_by{box{-Range Range}}
>   }
> </SDL>
>
> But it is too regular. So let's flip some of the boxes by mirror
coordinates
> around its center. But when and how should be this flipped? Let's control
it by
> noise value for rest of coordinates. To achive constant variation within
whole
> box noise need floor value for coordinates.
>
> <SDL>
> #include "stdinc.inc"
>
> #declare Range=3;
> #declare Major=.5;
> #declare Minor=.03;
>
> #declare f_coord=function(u,v,coord){
>   select(f_snoise3d(10*floor(u),10*floor(v),10*floor(coord)),1,-1)*
>   (coord-(floor(coord)+.5))
> }
>
> #declare f_x=function{f_coord(z,y,x)}
> #declare f_y=function{f_coord(x,z,y)}
> #declare f_z=function{f_coord(y,x,z)}
>
> #declare f_torus_1=function{f_torus(x-Major,y,z-Major,Major,Minor)}
> #declare f_torus_2=function{f_torus(x+Major,z,y-Major,Major,Minor)}
> #declare f_torus_3=function{f_torus(y+Major,x,z+Major,Major,Minor)}
>
> #declare
f_part=function{f_torus_1(x,y,z)|f_torus_2(x,y,z)|f_torus_3(x,y,z)}
>
> isosurface{
>   function{f_part(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))}
>   contained_by{box{-Range Range}}
>   }
> </SDL>
>
> Shape is ready. Now pattern for pigment. At first let's create base 2D
pattern
> within area <0,0><1,1> For smooth results it should be tileable. I choosed
> checkered pattern scaled down to achive equal "squares".
>
> <SDL>
>
> // calc number of rects along x per visible part of torus
> #declare YS=8;
> #declare XS=int(.25*YS*Major/Minor); // visible part
> #declare XS=4*(XS/2=int(XS/2)?XS:XS+1); // whole torus
>
> #declare Pig=pigment{
>   checker
>   color rgb 0 color rgb 1
>   rotate 45*z
>   scale 1/sqrt(2)
>   translate -.5
>   scale <1,.5,1>
>   scale <1/XS,1/YS,1>
> }
>
> </SDL
>
> Now we have to apply this texture to every part of toruses in base box.
>
> <SDL>
> #declare Pig1=pigment{
>   Pig
>   warp{toroidal major_radius Major}
>   translate (x+z)*Major
> }
>
> #declare Pig2=pigment{
>   Pig1
>   matrix<-1,0,0,0,0,1,0,1,0,0,0,0>
> }
>
> #declare Pig3=pigment{
>   Pig1
>   matrix<0,-1,0,1,0,0,0,0,-1,0,0,0>
> }
>
> #declare f_Pig1=function{pigment{Pig1}} // for torus_1
> #declare f_Pig2=function{pigment{Pig2}} // for torus_2
> #declare f_Pig3=function{pigment{Pig3}} // for torus_3
>
> </SDL>
>
> And now hardest thing: We have to choose what pigment should we apply. We
can
> use the same functions as for isosurface. We have to choose one with
smalest
> value.
>
> <SDL>
>
> #declare f_Pig=function{
>
>
select(f_torus_1(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))-f_torus_2(f_x(x,y,z),f_y(
x,y,z),f_z(x,y,z)),
>
>
select(f_torus_1(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))-f_torus_3(f_x(x,y,z),f_y(
x,y,z),f_z(x,y,z)),
>         f_Pig1(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray,
>         f_Pig3(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray
>       ),
>
>
select(f_torus_2(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))-f_torus_3(f_x(x,y,z),f_y(
x,y,z),f_z(x,y,z)),
>         f_Pig2(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray,
>         f_Pig3(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray
>       )
>     )
>   }
>
> </SDL>
>
> finally we can apply pigment to the isosurface
>
> <SDL>
> isosurface{
>   function{f_box(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))}
>   contained_by{box{-Range Range}}
>   pigment{function{f_Pig(x,y,z)}}
> }
> </SDL>
>
> at last we can add a little turbulence to pigments, add turbulenced
pigment as
> modifier to isosurface function and extend base pigment with gradient.
Here is
> whole scene with fog and other things.
>
> <SDL>
> #version 3.5;
>
> #include "stdinc.inc"
>
> global_settings
> {
>   assumed_gamma 1.0
>   noise_generator 2
> }
>
> #declare N=20;
>
> #local Loc=<0, 0, 0>;
> #local Look=Loc+z;
> #local Dir=1.5*z;
> #local Right=x*image_width/image_height;
> #local Angle=15;
>
> camera {
>   perspective
>   location  Loc
>   up        y
>   right     Right
>   look_at   Look
>   angle     Angle
> }
>
> light_source {<-30, 30, -30> color rgb 1 shadowless}
>
> #declare Major=.5;
> #declare Minor=.03;
> #declare YS=8;
> #declare XS=int(.25*YS*Major/Minor);
> #declare XS=4*(XS/2=int(XS/2)?XS:XS+1);
>
> #declare f_torus_1=function{f_torus(x-Major,y,z-Major,Major,Minor)}
> #declare f_torus_2=function{f_torus(x+Major,z,y-Major,Major,Minor)}
> #declare f_torus_3=function{f_torus(y+Major,x,z+Major,Major,Minor)}
>
> #declare PigA=function{pigment{
>   gradient x
>   color_map{
>     [0 color rgb 0]
>     [.5 color rgb 1]
>     [1 color rgb 0]
>   }
> }}
>
> #declare PigB=function{pigment{
>   gradient y
>   pigment_map{
>     [0 color rgb 0]
>     [.5 color rgb 1]
>     [1 color rgb 0]
>   }
> }}
>
> #declare PigC=pigment{function{min(PigA(x,y,z).gray,PigB(x,y,z).gray)}}
> #declare PigD=pigment{color rgb 0}
>
> #declare Pig1=pigment{
>   checker
>   pigment{PigC} pigment{PigD}
>   rotate 45*z
>   scale 1/sqrt(2)
>   translate -.5
>   scale <1,.5,1>
>   scale <1/XS,1/YS,1>
>   warp{toroidal major_radius Major}
>   translate (x+z)*Major
> }
>
> #declare Pig2=pigment{
>   Pig1
>   matrix<-1,0,0,0,0,1,0,1,0,0,0,0>
> }
>
> #declare Pig3=pigment{
>   Pig1
>   matrix<0,-1,0,1,0,0,0,0,-1,0,0,0>
> }
>
> #declare f_Pig1=function{pigment{Pig1}}
> #declare f_Pig2=function{pigment{Pig2}}
> #declare f_Pig3=function{pigment{Pig3}}
>
> #declare
f_box=function{f_torus_1(x,y,z)|f_torus_2(x,y,z)|f_torus_3(x,y,z)}
>
> #declare
>
f_coord=function{select(f_snoise3d(10*floor(x),10*floor(y),10*floor(z)),1,-1
)*(z-(floor(z)+.5))}
>
> #declare f_x=function{f_coord(z,y,x)}
> #declare f_y=function{f_coord(x,z,y)}
> #declare f_z=function{f_coord(y,x,z)}
>
> #declare f_Pig=function{
>
>
select(f_torus_1(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))-f_torus_2(f_x(x,y,z),f_y(
x,y,z),f_z(x,y,z)),
>
>
select(f_torus_1(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))-f_torus_3(f_x(x,y,z),f_y(
x,y,z),f_z(x,y,z)),
>         f_Pig1(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray,
>         f_Pig3(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray
>       ),
>
>
select(f_torus_2(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))-f_torus_3(f_x(x,y,z),f_y(
x,y,z),f_z(x,y,z)),
>         f_Pig2(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray,
>         f_Pig3(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray
>       )
>     )
>   }
>
> #declare f_Pig_Turb=function{pigment{function{f_Pig(x,y,z)}turbulence
2*Minor}}
>
> isosurface{
>
>
function{f_box(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))-Minor*f_Pig_Turb(x,y,z).gra
y/4}
>   contained_by{box{-N N}}
>   pigment{
>     function{f_Pig(x,y,z)}
>     color_map{
>       [0 ForestGreen]
>       [1 GreenYellow]
>     }
>   }
>   rotate <20,30,40>
>   #if(clock_on)
>     rotate<
>       Interpolate(frame_number,initial_frame,final_frame,0,360,0)
>       ,
>       Interpolate(frame_number,initial_frame,final_frame,0,360,1)
>       ,
>       Interpolate(frame_number,initial_frame,final_frame,0,360,2)
>     >
>   #end
> }
>
> background{color GreenYellow/2}
>
> fog {
>   distance N
>   color GreenYellow/2
> }
> </SDL>
>
> I wait for large renders and amazing animations :-)
>
> ABX
> --
> #declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb
1}}
> union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient
}}isosurface{ file://ABX
>
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)
}
> contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient
1}}//POV35

[] isomaze tutorial [8916 days 8 hours and 59 minutes ago]

Mon, 5 Nov 2001 14:44:13 GMT

Here is simple isomaze tutorial for POV 3.5. It is described in 3D. Some of
functions (f_torus, f_snoize) are defined in standard include file
"functions.inc". Sorry for enigmatic sentences but it is my poor English. I
expect some isosurface experience from readers :-)

Split 3D space to similiar parts. Simplest part is a box. So, every box should
contain the same content but mirrored. And should be smoothly joined by putting
connections in the center of the boxes. So, at first lets create simplest box in
the center. Centers of the boxes will be joined internally with parts of
toruses.

<SDL>

#include "stdinc.inc"

#declare Major=.5;
#declare Minor=.03;

#declare f_torus_1=function{f_torus(x-Major,y,z-Major,Major,Minor)}
#declare f_torus_2=function{f_torus(x+Major,z,y-Major,Major,Minor)}
#declare f_torus_3=function{f_torus(y+Major,x,z+Major,Major,Minor)}

#declare f_part=function{f_torus_1(x,y,z)|f_torus_2(x,y,z)|f_torus_3(x,y,z)}

isosurface{
  function{f_part(x,y,z)}
  contained_by{box{-Major Major}}
  }

</SDL>

Above is base shape. Now we must repeat this in all directions. We can do it by
going with all coordinates from any value to <-Major,Major> range. So we must
add function for coordinates, increase size of isosurface and change function.

<SDL>
#include "stdinc.inc"

#declare Range=3;
#declare Major=.5;
#declare Minor=.03;

#declare f_coord=function(coord){coord-(floor(coord)+.5)}

#declare f_torus_1=function{f_torus(x-Major,y,z-Major,Major,Minor)}
#declare f_torus_2=function{f_torus(x+Major,z,y-Major,Major,Minor)}
#declare f_torus_3=function{f_torus(y+Major,x,z+Major,Major,Minor)}

#declare f_part=function{f_torus_1(x,y,z)|f_torus_2(x,y,z)|f_torus_3(x,y,z)}

isosurface{
  function{f_part(f_coord(x),f_coord(y),f_coord(z))}
  contained_by{box{-Range Range}}
  }
</SDL>

But it is too regular. So let's flip some of the boxes by mirror coordinates
around its center. But when and how should be this flipped? Let's control it by
noise value for rest of coordinates. To achive constant variation within whole
box noise need floor value for coordinates.

<SDL>
#include "stdinc.inc"

#declare Range=3;
#declare Major=.5;
#declare Minor=.03;

#declare f_coord=function(u,v,coord){
  select(f_snoise3d(10*floor(u),10*floor(v),10*floor(coord)),1,-1)*
  (coord-(floor(coord)+.5))
}

#declare f_x=function{f_coord(z,y,x)}
#declare f_y=function{f_coord(x,z,y)}
#declare f_z=function{f_coord(y,x,z)}

#declare f_torus_1=function{f_torus(x-Major,y,z-Major,Major,Minor)}
#declare f_torus_2=function{f_torus(x+Major,z,y-Major,Major,Minor)}
#declare f_torus_3=function{f_torus(y+Major,x,z+Major,Major,Minor)}

#declare f_part=function{f_torus_1(x,y,z)|f_torus_2(x,y,z)|f_torus_3(x,y,z)}

isosurface{
  function{f_part(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))}
  contained_by{box{-Range Range}}
  }
</SDL>

Shape is ready. Now pattern for pigment. At first let's create base 2D pattern
within area <0,0><1,1> For smooth results it should be tileable. I choosed
checkered pattern scaled down to achive equal "squares".

<SDL>

// calc number of rects along x per visible part of torus
#declare YS=8;
#declare XS=int(.25*YS*Major/Minor); // visible part
#declare XS=4*(XS/2=int(XS/2)?XS:XS+1); // whole torus

#declare Pig=pigment{
  checker
  color rgb 0 color rgb 1
  rotate 45*z
  scale 1/sqrt(2)
  translate -.5
  scale <1,.5,1>
  scale <1/XS,1/YS,1>
}

</SDL

Now we have to apply this texture to every part of toruses in base box.

<SDL>
#declare Pig1=pigment{
  Pig
  warp{toroidal major_radius Major}
  translate (x+z)*Major
}

#declare Pig2=pigment{
  Pig1
  matrix<-1,0,0,0,0,1,0,1,0,0,0,0>
}

#declare Pig3=pigment{
  Pig1
  matrix<0,-1,0,1,0,0,0,0,-1,0,0,0>
}

#declare f_Pig1=function{pigment{Pig1}} // for torus_1
#declare f_Pig2=function{pigment{Pig2}} // for torus_2
#declare f_Pig3=function{pigment{Pig3}} // for torus_3

</SDL>

And now hardest thing: We have to choose what pigment should we apply. We can
use the same functions as for isosurface. We have to choose one with smalest
value.

<SDL>

#declare f_Pig=function{

select(f_torus_1(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))-f_torus_2(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)),

select(f_torus_1(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))-f_torus_3(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)),
        f_Pig1(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray,
        f_Pig3(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray
      ),

select(f_torus_2(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))-f_torus_3(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)),
        f_Pig2(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray,
        f_Pig3(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray
      )
    )
  }
  
</SDL>

finally we can apply pigment to the isosurface

<SDL>
isosurface{
  function{f_box(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))}
  contained_by{box{-Range Range}}
  pigment{function{f_Pig(x,y,z)}}
}
</SDL>

at last we can add a little turbulence to pigments, add turbulenced pigment as
modifier to isosurface function and extend base pigment with gradient. Here is
whole scene with fog and other things.

<SDL>
#version 3.5;

#include "stdinc.inc"

global_settings
{
  assumed_gamma 1.0
  noise_generator 2
}

#declare N=20;

#local Loc=<0, 0, 0>;
#local Look=Loc+z; 
#local Dir=1.5*z;
#local Right=x*image_width/image_height;
#local Angle=15;

camera {
  perspective
  location  Loc
  up        y
  right     Right
  look_at   Look
  angle     Angle
}

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

#declare Major=.5;
#declare Minor=.03;
#declare YS=8;
#declare XS=int(.25*YS*Major/Minor);
#declare XS=4*(XS/2=int(XS/2)?XS:XS+1);

#declare f_torus_1=function{f_torus(x-Major,y,z-Major,Major,Minor)}
#declare f_torus_2=function{f_torus(x+Major,z,y-Major,Major,Minor)}
#declare f_torus_3=function{f_torus(y+Major,x,z+Major,Major,Minor)}

#declare PigA=function{pigment{
  gradient x
  color_map{
    [0 color rgb 0]
    [.5 color rgb 1]
    [1 color rgb 0]
  }
}}
  
#declare PigB=function{pigment{
  gradient y
  pigment_map{
    [0 color rgb 0]
    [.5 color rgb 1]
    [1 color rgb 0]
  }
}}
  
#declare PigC=pigment{function{min(PigA(x,y,z).gray,PigB(x,y,z).gray)}}
#declare PigD=pigment{color rgb 0}
                   
#declare Pig1=pigment{
  checker
  pigment{PigC} pigment{PigD}
  rotate 45*z
  scale 1/sqrt(2)
  translate -.5
  scale <1,.5,1>
  scale <1/XS,1/YS,1>
  warp{toroidal major_radius Major}
  translate (x+z)*Major
}

#declare Pig2=pigment{
  Pig1
  matrix<-1,0,0,0,0,1,0,1,0,0,0,0>
}

#declare Pig3=pigment{
  Pig1
  matrix<0,-1,0,1,0,0,0,0,-1,0,0,0>
}

#declare f_Pig1=function{pigment{Pig1}}
#declare f_Pig2=function{pigment{Pig2}}
#declare f_Pig3=function{pigment{Pig3}}

#declare f_box=function{f_torus_1(x,y,z)|f_torus_2(x,y,z)|f_torus_3(x,y,z)}

#declare
f_coord=function{select(f_snoise3d(10*floor(x),10*floor(y),10*floor(z)),1,-1)*(z-(floor(z)+.5))}

#declare f_x=function{f_coord(z,y,x)}
#declare f_y=function{f_coord(x,z,y)}
#declare f_z=function{f_coord(y,x,z)}

#declare f_Pig=function{

select(f_torus_1(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))-f_torus_2(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)),

select(f_torus_1(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))-f_torus_3(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)),
        f_Pig1(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray,
        f_Pig3(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray
      ),

select(f_torus_2(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))-f_torus_3(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)),
        f_Pig2(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray,
        f_Pig3(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z)).gray
      )
    )
  }
  
#declare f_Pig_Turb=function{pigment{function{f_Pig(x,y,z)}turbulence 2*Minor}}

isosurface{

function{f_box(f_x(x,y,z),f_y(x,y,z),f_z(x,y,z))-Minor*f_Pig_Turb(x,y,z).gray/4}
  contained_by{box{-N N}}
  pigment{
    function{f_Pig(x,y,z)}
    color_map{
      [0 ForestGreen]
      [1 GreenYellow]
    }
  }
  rotate <20,30,40>
  #if(clock_on)
    rotate<
      Interpolate(frame_number,initial_frame,final_frame,0,360,0)
      ,
      Interpolate(frame_number,initial_frame,final_frame,0,360,1)
      ,
      Interpolate(frame_number,initial_frame,final_frame,0,360,2)
    >
  #end
}

background{color GreenYellow/2}

fog {
  distance N
  color GreenYellow/2
}
</SDL>

I wait for large renders and amazing animations :-)

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

[justin watkins] Going deeper into POV [8922 days 14 hours and 7 minutes ago]

Tue, 30 Oct 2001 09:36:18 GMT

Hello everyone,

I've been using POV-Ray since the early 1990s, and have barely scratched the
surface of what it can do. (I tend to use pencil, paper and a pocket
calculator as a modelling tool, btw). I'd like to systematically go through
the whole feature set, particularly the stuff that sets POV apart from other
3D tools and leads to greater realism. Does anyone have suggestions on the
order in which I should attack things? I'm rather good at spotting typos, so
if anyone is writing advanced documentation that needs to be "tested in the
wild", I'm volunteering :-)

For some examples of my work please visit www DOT wis.co.uk SLASH justin. My
main problem is achieving realism. Further comment and criticism welcome
(off-group please).

Justin Watkins
e: justin.watkins AT merant.com

[Bob H ] Re: Transparent water sphere [8925 days 21 hours and 34 minutes ago]

Sat, 27 Oct 2001 02:08:20 GMT

"Trancequence" <tra### [at] trancequencef2scom> wrote in message
news:3bd9a6a6@news.povray.org...
> Hello, I'm a bit of a newbie at povray, and I was wondering if it's
possible
> to make a sphere of water that you can see text inside... like the old
skool
> demos.

As long as you are talking of just refraction of the text through a clear
sphere, very easily done.

// no camera needed

light_source {<15,20,-10>,1}

background {.5}

plane {y,-2
        pigment {checker rgb <1,1,0>, rgb <0,1,0>}
}

// water sphere with text inside
union {

sphere {
    0,1
        pigment {rgbft <.7,.9,1,.9,.1>} // color and clearness
        normal {wrinkles .2 scale .3} // watery look
        finish {
                ambient 0 diffuse 0 specular .9 roughness .001 // highlights
                reflection .2 //
                }
            interior {
    ior 1.3 caustics 1 // refractive with light interaction
    fade_distance 2 fade_power 1
                        }
 scale 2
}

text {
    ttf "timrom.ttf", "Text", .5, 0
        pigment {rgb 1}
        finish {ambient .2 diffuse .8 specular .3 roughness .01}
 translate <-1,-.25,-.5> scale 1.5
}

 translate 5*z

}


Bob H.

[Trancequence] Transparent water sphere [8926 days 5 hours and 34 minutes ago]

Fri, 26 Oct 2001 18:08:38 GMT

Hello, I'm a bit of a newbie at povray, and I was wondering if it's possible
to make a sphere of water that you can see text inside... like the old skool
demos.

-Trancequence

[anoop] Re: HamaPatch [8927 days 21 hours and 40 minutes ago]

Thu, 25 Oct 2001 02:03:16 GMT

Digger Mole wrote in message <3bd71ace@news.povray.org>...
>Does anyone know where I can find a HamaPatch tutorial in...ENGLISH?
>
www.crosswinds.net/~hamapatch/  , IIRC , in one of it's sections

[Digger Mole] HamaPatch [8928 days 3 hours and 55 minutes ago]

Wed, 24 Oct 2001 19:47:26 GMT

Does anyone know where I can find a HamaPatch tutorial in...ENGLISH?

[Ron Parker] Re: The basics [8929 days 2 hours and 54 minutes ago]

Tue, 23 Oct 2001 20:49:02 GMT

On Tue, 23 Oct 2001 22:27:38 +0200, marabou wrote:
> marc wrote:
> 
>> let me be the first to say "read the manual" then after that try
>> http://twysted.net and look in the tutorials section, if you still need
> 
> i tried this site, but i only found this:
> 
> This is merely a placeholder page, as I construct this site. 
> 
> i there a link correction?

The post you're replying to is over three years old.  It's possible that
the landscape of the World Wide Web has changed a bit since then.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C)bicubic_patch{type 1u_steps 6
v_steps 6R(1)R(3)R(5)R(7)translate 9*z-2pigment{rgb z}}#end#macro _(Y)#local X=
asc(substr(C,Y,1))-65;<mod(X,4)div(X,4)>#end#local O=union{Q("ABEFUQWS")Q(// RON
"WSXTLOJN")}Q("JNKLCGCD")union{O}union{O translate 3*x}light_source{x 1}//PARKER

[marabou] Re: The basics [8929 days 3 hours and 16 minutes ago]

Tue, 23 Oct 2001 20:26:55 GMT

marc wrote:

> let me be the first to say "read the manual" then after that try
> http://twysted.net and look in the tutorials section, if you still need

i tried this site, but i only found this:

This is merely a placeholder page, as I construct this site. 

i there a link correction?

[C J - POV User] Re: About explosion [8932 days 22 hours and 47 minutes ago]

Sat, 20 Oct 2001 00:56:02 GMT

There is a explosive space ring tutorial in my site that uses media. look in
the advanced section, I forget the page number.

--
C.J. - POV User
POV Ray Study Gallery
http://hyperion.spaceports.com/~povstudy/
hou### [at] yahoocom
Hanson Lee <u86### [at] yahoocom> wrote in message
news:3bcd1ee6$1@news.povray.org...
> Anyone know if there's any tutorial for making explosion in POV-ray
without
> using Iso-surface?
>
>
>

[Jamie Davison] Re: About explosion [8935 days 5 hours and 8 minutes ago]

Wed, 17 Oct 2001 18:34:33 GMT

On 17 Oct 2001 14:11:37 -0400, Warp wrote...
> Hanson Lee <u86### [at] yahoocom> wrote:
> : Anyone know if there's any tutorial for making explosion in POV-ray without
> : using Iso-surface?
> 
>   I would be interested in that explosion made using an isosurface...

Subject: Cinematic-Quality explosion (made with PovRay!)
From: "H.E. Day" <hed### [at] fcinet>
Reply-To: Pov### [at] aolcom
Newsgroups: povray.binaries.animations
Date: Sun, 13 Feb 2000 14:01:24 -0800
NNTP-Posting-Host: 206.101.70.199
Message-ID: <38A729B3.EF1E00F2@fci.net>

That should start you off...

Bye for now,
     Jamie.

[Warp] Re: About explosion [8935 days 5 hours and 31 minutes ago]

Wed, 17 Oct 2001 18:11:37 GMT

Hanson Lee <u86### [at] yahoocom> wrote:
: Anyone know if there's any tutorial for making explosion in POV-ray without
: using Iso-surface?

  I would be interested in that explosion made using an isosurface...


-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

[Hanson Lee] About explosion [8935 days 17 hours and 41 minutes ago]

Wed, 17 Oct 2001 06:02:14 GMT

Anyone know if there's any tutorial for making explosion in POV-ray without
using Iso-surface?

[Digger Mole] Image and Bump Mapping [8944 days 3 hours and 50 minutes ago]

Mon, 8 Oct 2001 19:52:28 GMT

Anyone know of tutorials showing how to use image and bump maps, and also
how to make them?
Thanks,
Tim

[Ruy] Re: "Lofting" in POV-Ray [8946 days 23 hours and 27 minutes ago]

Sat, 6 Oct 2001 00:15:51 GMT

"Eli Ewok Brody" <ewo### [at] yahoocom> escreveu na mensagem
news:3b3bbf15@news.povray.org...
> > Take a look at the .inc file on this page -
> > http://members.nbci.com/dvarrazzo/epov.htm
>
>     I am forever indebted to both of you.
>
>     Thank you!
>     -Eli

It's gone! Can it be found anywhere else? I want to be indebted too!

Ruy

[Y] Re: Isosurface Tutorial Update [8971 days 21 hours and 39 minutes ago]

Tue, 11 Sep 2001 02:04:12 GMT

: It's at <http://www.econym.demon.co.uk/isotut/index.htm>
:
: --
: Mike Williams
: Gentleman of Leisure

Thanks Mike ... this is GREAT !!!
--
Y

[Daniel Matthews] Re: Isosurface Tutorial Update [8972 days 1 hour ago]

Mon, 10 Sep 2001 22:42:21 GMT

Thanks!

Mike Williams wrote:
> 
> It's at <http://www.econym.demon.co.uk/isotut/index.htm>
>

[Mike Williams] Isosurface Tutorial Update [8972 days 2 hours and 43 minutes ago]

Mon, 10 Sep 2001 20:59:53 GMT

I've rushed through an update of my Isosurface Tutorial to include the
isosurface syntax used in POV-Ray 3.5 beta 1.

All the example source files are now available in both MegaPOV and POV
3.5b1 formats. The main text now follows 3.5b1 syntax with the
significant MegaPOV differences highlighted.

Absolute beginners to isosurfaces would benefit by looking through the
isosurface tutorial pages included in the 3.5b1 documentation before
digging too deep into my pages.

I'm sure that there are still lots of new tricks that can be done with
3.5b1 that were not possible with MegaPOV, and I'll be updating the
tutorial as I find them.

It's at <http://www.econym.demon.co.uk/isotut/index.htm>

-- 
Mike Williams
Gentleman of Leisure

[Anoop Kumar] Re: Use a vector Image [8986 days 7 hours and 9 minutes ago]

Mon, 27 Aug 2001 16:33:20 GMT

Hi Rahul,

Rahul Pilani wrote in message <3b878de2@news.povray.org>...
>I have an image in both vector and raster format.. which i want to use to
>create an object in pov ray of the same shape as the image.. anybody have
>any idea how do i go about it?

I think it would depend on how complicated your image is and whether you
intend to do all your work in Pov-Ray alone or use help of modellers. It
would help if you could post your message to p.b.i
Among other options:
    1. Heightfield, like Ken said.
    2. certain programs can be used for converting some vector formats like
eps or ai to dxf (or you could trace over and recreate - depending on
complexity); then use 3dwin to convert to pov.
    3. Use it as a background image in a program like Rhino, Hamapatch,
Amapi etc.Trace it and create your object by trial & error.(Incidentally on
the Rhino3d site - www.rhino3d.com, I think - there's a tutorial on
modelling a helmet
using this technique. Rhino demo can be used for around 20 uses with full
saving)
Like I said, there are a few options depending on what format/ how
complicated the model is. Without seeing the image can't really say how
efective the suggestion would be. Sorry.
Hope this helps.

Regards,

-_- Anoop

[Bob H ] Re: Use a vector Image [8988 days 8 hours ago]

Sat, 25 Aug 2001 15:43:01 GMT

"Ken" <tyl### [at] pacbellnet> wrote in message
news:3B87B083.E191F33A@pacbell.net...
>
>
> Rahul Pilani wrote:
> >
> > I have an image in both vector and raster format.. which i want to use
to
> > create an object in pov ray of the same shape as the image.. anybody
have
> > any idea how do i go about it?
> > Rahul Pilani
>
> One possibility is to use your image to create a height_field object.
> It has its limitations but is the only method I can think of off the
> top of my head.

Or he could convert to GIF and then convert to DXF then convert to triangle
mesh.
Nevermind, HF is a better way to go than that.
Hmm, can it be converted to VRML by any chance?  There is a VRML to POV
converter available at http://www.chemicalgraphics.com/paul/

Bob H.

[Ken] Re: Use a vector Image [8988 days 9 hours and 41 minutes ago]

Sat, 25 Aug 2001 14:01:52 GMT

Rahul Pilani wrote:
> 
> I have an image in both vector and raster format.. which i want to use to
> create an object in pov ray of the same shape as the image.. anybody have
> any idea how do i go about it?
> Rahul Pilani

One possibility is to use your image to create a height_field object.
It has its limitations but is the only method I can think of off the
top of my head.

-- 
Ken Tyler

[Rahul Pilani] Use a vector Image [8988 days 12 hours and 6 minutes ago]

Sat, 25 Aug 2001 11:37:06 GMT

I have an image in both vector and raster format.. which i want to use to
create an object in pov ray of the same shape as the image.. anybody have
any idea how do i go about it?
Rahul Pilani

[Warp] Re: Sun thread? [9032 days 14 hours and 26 minutes ago]

Thu, 12 Jul 2001 09:16:34 GMT

Eli Ewok Brody <ewo### [at] yahoocom> wrote:
:     It's obvious an area light - the sun disc isn't a point. The sun is so
: far away, that the light it generates closely aproximates parallel rays,
: though.

  Light rays coming from a light source with a visible area are never
parallel, no matter how far it is.
  It's only when the light source is practically a point light when the
light rays start to be practically parallel. However, the Sun isn't.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

[Eli Ewok Brody] Re: Sun thread? [9032 days 15 hours and 27 minutes ago]

Thu, 12 Jul 2001 08:16:15 GMT

I think that's what I remember seeing.
    It's obvious an area light - the sun disc isn't a point. The sun is so
far away, that the light it generates closely aproximates parallel rays,
though.
    But the atmosphere point was well taken. Even if it was parallel, the
atmosphere bends it in crazy ways.

    Thanks,
    -Eli

[Warp] Re: Sun thread? [9033 days and 50 minutes ago]

Wed, 11 Jul 2001 22:52:37 GMT

Eli Ewok Brody <ewo### [at] yahoocom> wrote:
: how
: far away the lightsource has to be to create parallel rays.

  Sunlight rays are not parallel because the Sun is an area light.

  See:
http://www.students.tut.fi/~warp/povVFAQ/misconceptions.html#simulatingsun

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

[Eli Ewok Brody] Sun thread? [9033 days 1 hour and 15 minutes ago]

Wed, 11 Jul 2001 22:27:39 GMT

I remember, not long ago, coming across a fantastic thread about true
sunlight. I recall it started out as a question about POV limitations
concerning the floating point accuracy ("Do I really have to make the sun 8
light minutes away?"), and quickly turned into a great discussion about how
far away the lightsource has to be to create parallel rays.

    I would really like to see it again (I foolishly failed to save it).
Anybody know?

    Thanks,

    -Eli

[Eli Ewok Brody] Problem with Bicubic Patch [9039 days 10 hours and 13 minutes ago]

Thu, 5 Jul 2001 13:29:32 GMT

All --
    I'm sure this has been a problem before, perhaps even solved before. At
any rate, I am becoming desperate. sPatch objects (eg. Unions of bicubic
patches) do not support world xyz coords. This turns shading into a
nightmare. I've tried lots of combinations - not making it a union, merging
them, assigning textures individually... nothing works. It's possible to
make a triangle mesh out of it, but I have never been impressed by meshes,
and would rather use slightly more resolution independant objects. (The best
being Our Friend the Primitive.)
    What can I do? Is there some bug in POV-Ray? Is there something simple
I'm overlooking?
    And let me just mention that it is truly a pleasure looking through your
posts on the Images group.
    Thanks for your time.
    =Eli
http://I.am/Ewok

[Eli Ewok Brody] Re: "Lofting" in POV-Ray [9046 days and 8 minutes ago]

Thu, 28 Jun 2001 23:34:45 GMT

> Take a look at the .inc file on this page -
> http://members.nbci.com/dvarrazzo/epov.htm

    I am forever indebted to both of you.

    Thank you!
    -Eli

[Ken] Re: "Lofting" in POV-Ray [9050 days 10 hours and 53 minutes ago]

Sun, 24 Jun 2001 12:49:37 GMT

Eli Ewok Brody wrote:
> 
> Hello, all --
> 
> Just wondering if it's at all possible to make a "loft" structure with
> POV-Ray. That is, a spline shape (or number of them) extruded along a spline
> path. All I could find was "prism," which simply extrudes the spline along a
> short, straight path.
> 
> How can I make lofted wood structures?

Take a look at the .inc file on this page -
http://members.nbci.com/dvarrazzo/epov.htm

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Eli Ewok Brody] "Lofting" in POV-Ray [9050 days 11 hours and 18 minutes ago]

Sun, 24 Jun 2001 12:25:06 GMT

Hello, all --

Just wondering if it's at all possible to make a "loft" structure with
POV-Ray. That is, a spline shape (or number of them) extruded along a spline
path. All I could find was "prism," which simply extrudes the spline along a
short, straight path.

How can I make lofted wood structures?

Thank you,

-Eli

[The "D"] Re: Making clouds [9054 days 16 hours and 47 minutes ago]

Wed, 20 Jun 2001 06:55:38 GMT

"Ken" <tyl### [at] pacbellnet> wrote in message
news:3B257062.73277EFC@pacbell.net...
>
>
> jansb000 wrote:
> >
> > Are there tutorials for making clouds?
>
> None that I am aware of.

http://free.prohosting.com/~olana/povray/povray.html

The basic sky tutorial has an excelent method of creating a cloud layer
using a plane.

--
-The "D"
   If you only have a hammer, you tend to
      see every problem as a nail.
      -- Maslow

[Ken] Re: Making clouds [9062 days 22 hours and 12 minutes ago]

Tue, 12 Jun 2001 01:31:01 GMT

jansb000 wrote:
> 
> Are there tutorials for making clouds?

None that I am aware of.

> I need clouds as real objects, not just as a texture in the background. I
> need to move objects through, in front and behind clouds.

There are examples of clouds as objects posted in the two scene-files
groups on this server. A little digging and you should be able to find
something useful...

-- 
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: How do i Make a Realistic lightning bolt [9062 days 22 hours and 13 minutes ago]

Tue, 12 Jun 2001 01:29:39 GMT

jansb000 wrote:
> 
> Can this tuturial or macro be posted again?

Goto - http://www.geocities.com/SiliconValley/Pines/3210/lightnin.html

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[jansb000] Making clouds [9063 days 2 hours and 40 minutes ago]

Mon, 11 Jun 2001 21:02:45 GMT

Are there tutorials for making clouds?

I need clouds as real objects, not just as a texture in the background. I
need to move objects through, in front and behind clouds.

[jansb000] Re: How do i Make a Realistic lightning bolt [9063 days 2 hours and 43 minutes ago]

Mon, 11 Jun 2001 21:00:16 GMT

Can this tuturial or macro be posted again?

"Simen Kvaal" <sim### [at] studentmatnatuiono> wrote in message
news:37f5ddbd@news.povray.org...
>
> >It is in Pov v3.0 format and may require a little bit of work to
> >make it compatible with v3.1. The only thing you will likely have to
> >change is to add a simi colon after all of the declared variables
> >in the file.
>
> Actually, pvengine only generates a warning for this. It still works fine.
I
> usually get lots of warnings due to this just because I've got a bad
habit.
>
>
>

[Warp] Re: Media/Scattering HELP!!! [9066 days and 41 minutes ago]

Fri, 8 Jun 2001 23:01:47 GMT

John Albarelli <joh### [at] smithandmahoneycom> wrote:
: However, when I add media, the place goes black

  Scattering media? Try specifying extinction .01 or so inside it.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

[Bob H ] Re: Media/Scattering HELP!!! [9066 days 2 hours and 51 minutes ago]

Fri, 8 Jun 2001 20:51:37 GMT

E-mailed you, and for anyone else I'll cite this site once again:

http://free.prohosting.com/~olana/povray/povray.html

Bob H.

"John Albarelli" <joh### [at] smithandmahoneycom> wrote in message
news:3b2113b6$1@news.povray.org...
> Help, someone.  I'm trying to make a scene of the inside of a church.  I
> have light sources on the outside, behind some stained glass windows
> (filter_all set to 1 for windows), and I have a light on the interior,
just
> for a little more illumination.  The stained glass pattern is showing up
on
> my floor, just like I expected.  However, when I add media, the place goes
> black, even though the light inside has media_attenuation and
> media_interaction turned off.  Does anyone have a GOOD tutorial on media,
> describing what each variable does, in layman's terms?  thanks.  Oh,
please
> email any responses, if you can.
>
> John
> joh### [at] smithandmahoneycom

[John Albarelli] Media/Scattering HELP!!! [9066 days 5 hours and 38 minutes ago]

Fri, 8 Jun 2001 18:04:38 GMT

Help, someone.  I'm trying to make a scene of the inside of a church.  I
have light sources on the outside, behind some stained glass windows
(filter_all set to 1 for windows), and I have a light on the interior, just
for a little more illumination.  The stained glass pattern is showing up on
my floor, just like I expected.  However, when I add media, the place goes
black, even though the light inside has media_attenuation and
media_interaction turned off.  Does anyone have a GOOD tutorial on media,
describing what each variable does, in layman's terms?  thanks.  Oh, please
email any responses, if you can.

John
joh### [at] smithandmahoneycom

[Wlodzimierz ABX Skiba] no-repeat in mosaic [9144 days 13 hours and 47 minutes ago]

Thu, 22 Mar 2001 09:55:50 GMT

here is my macro and whole sample scene
images just sended to p.b.images

Patterns is array of textures to mix and Patterns[0] is texture of mortar
Length and Width is size of ceil without Mortar

// START ****************************
#version unofficial megapov 0.7;

#include "colors.inc"
#include "woods.inc"

#version unofficial megapov 0.7;

camera
 {
  location  <-4.0, 2, -4.0>
  direction 1.5*z
  right     4/3*x
  look_at   <0.0, 0.0,  0.0>
 }

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

#macro Mosaic(Patterns,Mortar,Length,Width)
  #if(dimensions(Patterns)!=1)
    #warning "list of patterns should be one-dimensional\n"
    #error ""
  #end
  #local Size=dimension_size(Patterns,1);
  #local counter=0;
  #local Finish=no;
  #while(!Finish)
    #if(counter>=Size)
      #local Finish=yes;
    #else
      #if(!defined(Patterns[counter]))
        #local Finish=yes;
      #else
        #local counter=counter+1;
      #end
    #end
  #end
  #if(counter<2)
    #warning "list of patterns should contains more than two patterns\n"
    #error ""
  #end
  #local Size=counter;
  #local
MosaicNoise=function{((Size-1)*noise3d(floor(x),0,floor(z))/Size)+(1/Size)}
  #local
MosaicMortarZ=function{if((z-floor(z))-(Width/(Width+Mortar)),0,MosaicNoise(x,0,
z))}
  #local
MosaicMortarX=function{if((x-floor(x))-(Length/(Length+Mortar)),0,MosaicMortarZ(
x,0,z))}
  #local MosaicOffset=function{MosaicMortarX(x+(floor(z)/2),0,z)}
  #local
MosaicRescale=function{MosaicOffset(x/(Length+Mortar),0,z/(Width+Mortar))}
  texture{
    function{MosaicRescale(x,0,z)}
    texture_map{
      #local counter=0;
      #while(counter<(Size-.5))
        [(counter/Size) Patterns[counter]]
        [((counter+1)/Size) Patterns[counter]]
        #local counter=counter+1;
      #end
    }
  }
#end

#declare List=array[1000]
#declare L=0;
#macro Add(T)
  #declare List[L]=T
  #declare L=L+1;
#end

Add(texture{pigment{color rgb 0}})
#declare counter=0;
#while (counter<31)
  Add(texture{T_Wood1 rotate y*90 translate <1,2,3>*counter scale.2})
  Add(texture{T_Wood10 rotate y*90 translate <4,5,6>*counter scale.2})
  Add(texture{T_Wood11 rotate y*90 translate <7,8,9>*counter scale.2})
  Add(texture{T_Wood13 rotate y*90 translate <1,4,7>*counter scale.2})
  #declare counter=counter+1;
#end

plane{y,-1 Mosaic(List,0.005,4.7,0.075)}

#version unofficial megapov 0.7;

// END ******************************

[Bob H ] Re: I wonder how to do this with tiles with POV [9202 days 5 hours ago]

Tue, 23 Jan 2001 18:42:29 GMT

Hi.  Suggest you ask at povray.general.  People don't frequent this group as
much.

Bob H.

[Bogdan] I wonder how to do this with tiles with POV [9202 days 6 hours and 1 minute ago]

Tue, 23 Jan 2001 17:41:33 GMT

Hi

My problem is (or looks) simple:
I want to make a terrain in POV (using heighfields or primitives)
and then to find a way to cut simple rectangular tiles from this
image (32x32in size) so that i can use them to padd a much greater areea
and it must not be noticeable the terrain is made from rectangular
tiles...

What i did:
I made a scen with a orthographic camera at <k,1*5k,-k>
look_at <0,0,0> then made a mountain and rendered the image at
a 2:1 ratio ie 384x192 512x256 etc
then i cut diamonds from it....

I dont like it...i need rectangular sets of tiles not diamonds 
for my game ...

anybody has any ideea?

Besides that why must i place the camera at 1,5*k on y ? from my
calculations i shoud be at
30 degrees above plane <0,1,0> , 0 but it looks is not...cant figure
that out...but it works

Bogdan

[C J ] [NOTICE] Tutorial writers [9234 days 8 hours and 56 minutes ago]

Fri, 22 Dec 2000 14:46:51 GMT

<Ad>The PRSG is now accepting any and all tutorials, images, and product
reviews (graphics related). The only requirement is to use a parchment
background that I will provide. In return I have a free banner rotation for
all that submit, which is linked to your website. So if you have wanted to
make more room on your site, but still would like to show your work this
maybe for you! </Ad>

PRSG (POV Ray Study Gallery)
www.crosswinds.net/~povstudy

Regards,
C.J. - POV User

[Tom Melly] Re: Rotate around central axis [9235 days 10 hours and 57 minutes ago]

Thu, 21 Dec 2000 12:46:14 GMT

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3a41f228@news.povray.org...
>
> union
> { sphere { <-.5,0,0>, 1 }
>   sphere { <1,0,.5>, 1 }
>   texture { Wood }
>   rotate <0,45,0>
> }
>
>   "Uh... What is the center of this object now? Is it <-.5,0,0>? Is it
> <1,0,.5>? Is it somewhere in the middle? What does the rotation actually
> do to this object?"

Exactly - it was running into this kind of issue with blobs that I realised
a) pov didn't work how I thought it did and b) the notion of objects having
a "center" was wrong.

[Warp] Re: Rotate around central axis [9235 days 11 hours and 31 minutes ago]

Thu, 21 Dec 2000 12:11:48 GMT

Tom Melly <tom### [at] tomandlucouk> wrote:
: Warp's info is the most accurate, but possibly not the most comprehensible
: to a novice.

  What?! What?! That was just outrageous!

  ;)

: The best way, IMHO, to avoid muddles is to always create objects with a
: point that rests at <0,0,0>. It doesn't matter which point (e.g. the center
: of a sphere or its base), just as long as you know which point.

  It's good to know how to rotate around a certain point, which may not
necessarily be <0,0,0>.
  For example, it may be possible that the user wants to rotate the object
first around one point and then around another different point.

: Secondly, always scale, then rotate and finally translate (there are many
: exceptions to this, but you will generally recognise them as exceptions).

  It should be noted that it's not a mandatory rule to have one scale, one
rotate and one translate per object and in that order.
  It's perfectly possible to, for example, first scale, then rotate, than
scale again, then translate and then rotate again. There's practically no
limit in the amount and combinations of transformations.
  Of course it requires experience to handle a complex combination of
transformations.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Warp] Re: Rotate around central axis [9235 days 11 hours and 37 minutes ago]

Thu, 21 Dec 2000 12:06:00 GMT

Tom Melly <tom### [at] tomandlucouk> wrote:
: It's a very common beginners misconception. I suspect because beginners
: start with the simple shapes such as sphere etc.

  This is probable the most common reason.
  It's easy to believe that a beginner (and even a not so beginner) could
think something like this:

  Ok, I make a
sphere
{ <1,2,3>, 1
  texture { Wood }
}
  This means that the center of the sphere is at <1,2,3> and its radius is 1.
  Now I'll rotate it around its center so that I get a rotating ball:

sphere
{ <1,2,3>, 1
  texture { Wood }
  rotate <0,45,0>
}

  Oops! What happened? Why it didn't rotate around its center but it moved
to a totally different place?

  The user has confused the center coordinate of the sphere with the
rotation axis center. It's quite natural to think that the center of the
sphere is the center of the rotation axis.
  However, when the user makes something like this, he will be quite
confused:

union
{ sphere { <-.5,0,0>, 1 }
  sphere { <1,0,.5>, 1 }
  texture { Wood }
  rotate <0,45,0>
}

  "Uh... What is the center of this object now? Is it <-.5,0,0>? Is it
<1,0,.5>? Is it somewhere in the middle? What does the rotation actually
do to this object?"

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Tom Melly] Re: Rotate around central axis [9235 days 12 hours and 40 minutes ago]

Thu, 21 Dec 2000 11:03:08 GMT

"Philippe-H Cadet" <del### [at] videotronca> wrote in message
news:3a41ac3d@news.povray.org...

> As I can see Povray is not vertex based, anyways I goin to try avoid this
> metal illusion
> that a shape or 3d object can have a middle.
>

It's a very common beginners misconception. I suspect because beginners
start with the simple shapes such as sphere etc. which can easily behave as
though they do have a centre (as well as having their position defined with
just one set of co-ordinates).

For me, it wasn't until I started working with blobs that I began to
understand what was going on.

[Philippe-H Cadet] Re: Rotate around central axis [9235 days 16 hours and 35 minutes ago]

Thu, 21 Dec 2000 07:07:41 GMT

>   Just think about a triangle. What is the center of the triangle? Is it
> the average of the vertex points? Is it the intersection of the lines
tangent
> to the sides of the triangle, going through the center of the side? Is it
> the intersection of the middle-angles of the vertex angles? Something
else?
>   Another reason is that it's not even possible to do it with many
objects.
>   How do you calculate the center of a julia object? An isosurface? A
poly?
> What is the center of a plane?

Yes, you are right!
I did not looked at this perspective. I was thinking it was
possible to know the 2d center by the the average of the vertex points or by
calculating
the area for a face and the apply the 2d rotation by the normal centered to
the whole object.
As I can see Povray is not vertex based, anyways I goin to try avoid this
metal illusion
that a shape or 3d object can have a middle.

Philippe

[Philippe-H Cadet] Re: Rotate around central axis [9235 days 16 hours and 59 minutes ago]

Thu, 21 Dec 2000 06:44:14 GMT

>   A translate <0,0,0> does nothing. Absolutely nothing.
>   The 'translate' command does NOT mean "translate to".
>   It means "translate by". Or "add this vector to the current location".
>   That's why you should decide what is the center of the object and then
> do something like this (supposing that you decide that the center of the
> object is located at <1,2,3>):
>
> #declare ObjectCenter= <1,2,3>;
>
> object
> { MyObject
>   translate -ObjectCenter
>   rotate whatever
>   translate ObjectCenter
> }

Ok. I think got it now. For this I assume that when creating the
object, I have to be careful while writing the dimentions. I mean
that in order to perform a rotation on the y axis of the object,
ObjectCenter
has to reflect this intention by it's x or z coordinate.

Because if I have to move object it to the position <0,0,0> (with the
ObjectCenter
vector) and have a perfect rotation on it self,  after a lot of sucessive
translate - rotate - translate.... there can be some errors due to
the fact that the object is not properly centered with the normal
of the rotation I want it to rotate.

Philippe

[Tom Melly] Re: Rotate around central axis [9236 days 7 hours and 46 minutes ago]

Wed, 20 Dec 2000 15:57:04 GMT

"Philippe-H Cadet" <del### [at] videotronca> wrote in message
news:3a3f0841$1@news.povray.org...

Hi Philippe,

As you may have gathered (or not), you have one or two very common
misconceptions to abandon.

Warp's info is the most accurate, but possibly not the most comprehensible
to a novice.

The best way, IMHO, to avoid muddles is to always create objects with a
point that rests at <0,0,0>. It doesn't matter which point (e.g. the center
of a sphere or its base), just as long as you know which point.

Secondly, always scale, then rotate and finally translate (there are many
exceptions to this, but you will generally recognise them as exceptions).

I call this my door rule: 1st you scale your hand to the door-knob, then you
rotate the knob, finally you push or pull (translate) the door.

To see why, try this scene where scale and translate are swapped on
otherwise similiar spheres:

//  start scene
camera{location <0,0,-50> look_at 0}
light_source{<0,0,0> color rgb 1 translate <10, 10, -30>}

sphere{<0,1,0>, 1 scale 10 translate <5,0,0> pigment{rgb<1,0,0>}} // base of
sphere at x = 0, so when scaled it stayed at 0 as 10*0 is still 0
sphere{<0,1,0>, 1 translate <-5,0,0> scale 10 pigment{rgb<0,1,0>}} // base
of the sphere was at x = -5, so when scaled it moved to x=-50 (10*-5)

// end scene

The point to note is that scaling and rotation take place relative to
<0,0,0>. Translation takes place relative to the object. The object itself
has no defined center, nor any special relationship to <0,0,0>. Also, as
Warp said, translation means move all points of the object by this amount,
not to a particular co-ordinate. Therefore "translate <0,0,0>" means "do not
move the object", not "move it to <0,0,0>".

Hope this helps.

[Warp] Re: Rotate around central axis [9236 days 11 hours and 43 minutes ago]

Wed, 20 Dec 2000 12:00:13 GMT

Philippe-H Cadet <del### [at] videotronca> wrote:
: Yes but ObjectCenter. How can I find that if it is not necessary a cube?

  How could povray find it if even you can't find it?
  The center of the object is where you decide it is.

  And no, povray can't calculate a center for the object automatically.
  Why? For many reasons. One of them is that the center of an object may
not be unambiguous.
  Just think about a triangle. What is the center of the triangle? Is it
the average of the vertex points? Is it the intersection of the lines tangent
to the sides of the triangle, going through the center of the side? Is it
the intersection of the middle-angles of the vertex angles? Something else?
  Another reason is that it's not even possible to do it with many objects.
  How do you calculate the center of a julia object? An isosurface? A poly?
What is the center of a plane?

: I thought about translating the global x,y,z axis on the center of the
: object and then after, rotate then translate back the global axis where it
: was before. But the aigain there is no functions that I know to translate
: the global axis.

  I said how to do it, but you didn't believe me:

object
{ MyObject
  translate -ObjectCenter
  rotate whatever
  translate ObjectCenter
}

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Warp] Re: Rotate around central axis [9236 days 11 hours and 53 minutes ago]

Wed, 20 Dec 2000 11:50:13 GMT

Philippe-H Cadet <del### [at] videotronca> wrote:
:         box
:         {
                  ...
:                 translate <0,0,0>
:         }

  A translate <0,0,0> does nothing. Absolutely nothing.

  The 'translate' command does NOT mean "translate to".
  It means "translate by". Or "add this vector to the current location".

  That's why you should decide what is the center of the object and then
do something like this (supposing that you decide that the center of the
object is located at <1,2,3>):

#declare ObjectCenter = <1,2,3>;

object
{ MyObject
  translate -ObjectCenter
  rotate whatever
  translate ObjectCenter
}

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Mick Hazelgrove] Re: Help me. I just downloaded the software... [9236 days 16 hours and 2 minutes ago]

Wed, 20 Dec 2000 07:41:03 GMT

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3a3f5ea2@news.povray.org...

>(I'm tempted to say something sarcastic...)

Congratulations on your self control!

[Philippe-H Cadet] Re: Rotate around central axis [9236 days 22 hours and 7 minutes ago]

Wed, 20 Dec 2000 01:35:46 GMT

> Or if you are simple minded like me
>
> create or translate the object at <0,0,0>
> rotate it
> translate it wherever you need it to go.




Thanks. But maybe there is something I'm missing here.
I tried you solution. When I do create an object at  a n y  place in the 3D
world and then translate it to <0,0,0>, the object should remain at the same
place. It will not be translated to the global center. For sure, if I do a
rotate it will still be rotated  around  the global axis.

Ex:
#declare testbox = object
{
        box
        {
                <-.5+2, -.5+2, -2+2> < .5+2,  .5+2,  2+2>
                pigment { red 0.9 green 0.7 blue 0.7 }
                translate <0,0,0>
        }
}

object{testbox}

By the way, I tried creating objects at <0,0,0> it seems that it is not
precise for the further  transformations. It is really hard to determine the
exact middle of a union object from my point of view.
Hum. I'm not done yet with that problem.

[Philippe-H Cadet] Re: Rotate around central axis [9236 days 22 hours and 34 minutes ago]

Wed, 20 Dec 2000 01:08:30 GMT

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3a3f2399@news.povray.org...
> Philippe-H Cadet <del### [at] videotronca> wrote:
> : Hi. I have tried for months to find a way to rotate an object around it
> : central axis. How can I do that?
>
>   Easy:
>
> translate -ObjectCenter
> rotate whatever
> translate ObjectCenter
>
>   You'll have to define ObjectCenter yourself.

Yes but ObjectCenter. How can I find that if it is not necessary a cube?
Note:
I thought about translating the global x,y,z axis on the center of the
object and then after, rotate then translate back the global axis where it
was before. But the aigain there is no functions that I know to translate
the global axis.

Philippe

[Mick Hazelgrove] Re: Rotate around central axis [9237 days 4 hours and 25 minutes ago]

Tue, 19 Dec 2000 19:17:50 GMT

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3a3f2399@news.povray.org...
> Philippe-H Cadet <del### [at] videotronca> wrote:
> : Hi. I have tried for months to find a way to rotate an object around it
> : central axis. How can I do that?
>
>   Easy:
>
> translate -ObjectCenter
> rotate whatever
> translate ObjectCenter
>

Or if you are simple minded like me

create or translate the object at <0,0,0>
rotate it
translate it wherever you need it to go.

Mick

[Warp] Re: Help me. I just downloaded the software... [9237 days 10 hours and 31 minutes ago]

Tue, 19 Dec 2000 13:12:03 GMT

Jeremy W. <bof### [at] hotmailcom> wrote:
: Could someone teach me the very basics of making 3D images with POV-Ray?
: Like how to use the scripts, make cubes....

  Read the documentation. There's an excellent tutorial there.

  (I'm tempted to say something sarcastic...)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Jeremy W ] Help me. I just downloaded the software... [9237 days 11 hours and 51 minutes ago]

Tue, 19 Dec 2000 11:52:07 GMT

Could someone teach me the very basics of making 3D images with POV-Ray?
Like how to use the scripts, make cubes....

-Jeremy W.

[Warp] Re: Rotate around central axis [9237 days 14 hours and 43 minutes ago]

Tue, 19 Dec 2000 09:00:10 GMT

Philippe-H Cadet <del### [at] videotronca> wrote:
: Hi. I have tried for months to find a way to rotate an object around it
: central axis. How can I do that?

  Easy:

translate -ObjectCenter
rotate whatever
translate ObjectCenter

  You'll have to define ObjectCenter yourself.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Philippe-H Cadet] Rotate around central axis [9237 days 16 hours and 39 minutes ago]

Tue, 19 Dec 2000 07:03:29 GMT

Hi. I have tried for months to find a way to rotate an object around it
central axis. How can I do that? I thought I could with the Matrix keyword
but if the object is not centered at the origin it does not work.

Some guy told me that I could use the vnormalize(...) function but the only
doc that I founded is

vnormalize(A) Normalize vector A. Returns a unit length vector that is the
same direction as A. Formula is vnormalize=A/vlength(A)

Can somebody help me rotate an object around it's own central axis please...
Philippe

[Warp] Re: fire media [9241 days 12 hours and 15 minutes ago]

Fri, 15 Dec 2000 11:27:39 GMT

Jonathan Rafael Ghiglia <j.l### [at] liberoit> wrote:
: the fire looks too clear, even if I
: increase the amount of emission.

  Increase the amount of absorption.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Jonathan Rafael Ghiglia] fire media [9242 days 1 hour and 19 minutes ago]

Thu, 14 Dec 2000 22:23:44 GMT

I made a candle lit with an emission media.
When the background is black the flames look right, but as soon as I
add the candle to my scene the fire looks too clear, even if I
increase the amount of emission. What should I do? 
Should I add absorption or scattering media to the fire ?

[Warp] Re: Translate [9249 days 11 hours and 58 minutes ago]

Thu, 7 Dec 2000 11:45:12 GMT

Jason Scott <fir### [at] hotmailcom> wrote:
: I am making a lamp but whan I goto reanslate it, its not translateing the
: glow

  It's a known limitation and it is being fixed.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Ken] Re: Translate [9249 days 20 hours and 45 minutes ago]

Thu, 7 Dec 2000 02:57:33 GMT

Jason Scott wrote:
> 
> I am making a lamp but whan I goto reanslate it, its not translateing the
> glow and I cant figure out why.  So heres the code. So if you can help me it
> would be a great help.

You need to add a translate statement to the glow statement. Glows
do not translate to the position of the light_source and must be
manualy positioned to match.

P.S. This should have been posted in the unofficial patches group
since this is a feature not supported in the official version of
POV-Ray.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Jason Scott] Translate [9249 days 21 hours and 14 minutes ago]

Thu, 7 Dec 2000 02:28:50 GMT

I am making a lamp but whan I goto reanslate it, its not translateing the
glow and I cant figure out why.  So heres the code. So if you can help me it
would be a great help.

#declare Lamp =
union {
        // The glass part of the light
        sphere {
                <0,0,0>.5
                pigment { rgbt <.25,.25,.25,.5> }
                translate <0,5.15,0>
        }
        // The Metal cap on the light
        sphere {
                <0,.5,0>.125
                texture { GreenMetal }
                scale <2,1,2>
                translate <0,5.15,0>
        }
        // The light pole
        lathe {
                cubic_spline
                9
                <0,0> <.25,0> <.25,.5> <.125,1> <.125,2>
                <.25,3> <.125,4> <.25,4.75> <.5,4.75>
                texture { GreenMetal }
        }
        // The Light Glow
        light_source {
                <0,5.25,0>
                color White
                glow {
                        size .65
                        type 2
                }
        }
}

object { Lamp }
object { Lamp translate <5,0,0> }

--
Jason S

[david sharp] Re: heightfields with i_dat3d [9252 days 19 hours ago]

Mon, 4 Dec 2000 04:43:06 GMT

> For an example, what would the data values be to build a simple four-sided
> pyramid shape?

Is this a pyramid?
////////////////////////////////////////////////
#version unofficial MegaPov 0.6;

#declare S=3; // data sample sizes
#declare myDataArray2=array[S][S]{
 {-2,-2,-2},
 {-2, 1,-2},
 {-2,-2,-2}
}

#declare myDataFunction2 =
function{ "data_2d_1", <1> library "i_dat3d", myDataArray2, <S,1,S>}

isosurface {
     function {(myDataFunction2)}
     contained_by { box {<0,0,0>, <2,2,2>}}
     threshold 0
     max_gradient 4
     pigment{rgb<1,0,0>}

     scale 4
}

camera { location <10, 10, 10> look_at <0,0,0>}

light_source {<10, 120, 150> color 1}

background {color .3}
////////////////////////////////////////////////

"janger" <d_j### [at] hotmailcom> wrote in message
news:3a03bcf0@news.povray.org...
> Anyone help me with generating heightfields using MegaPov and the built-in
> i_dat3d library routines?
> I have no idea how the data points are mapped. I've read the megapov help,
> and it doesn't make it clear to me. Sample data files give me unexpected
> results.
> I've searched the pov site, the net, my mind... just can't make sense of
it
> all.
> For an example, what would the data values be to build a simple four-sided
> pyramid shape?
>
>

[C HARMAN] Re: Pov-Ray and VRML [9269 days 11 hours and 26 minutes ago]

Fri, 17 Nov 2000 12:16:47 GMT

That would be great!
TonyV <tjv### [at] altavistacom> wrote in message
news:3a103939$1@news.povray.org...
> Subject: VRMLizing your POV models
> Dated: March 02, 1999
> From: Tony Vigil
>
> If the messages aren't available to you, I can post the information on a
> website (time permitting).
>
>
> "C_HARMAN" <C_H### [at] tinyworldcouk> wrote in message
> news:3a0988c4@news.povray.org...
> > Hi, Tony,
> >
> > I have been looking for the thread you mentioned, but I can't find it.
> > Could you give me some more detail?(Header, where, when etc.), because I
> am
> > really interested.
> >
> > Thanks,
> >
> > Caroline.
> >
> > TonyV <tjv### [at] altavistacom> wrote in message
> > news:3a033580$1@news.povray.org...
> > > Look in povray.binaries.images
> > >
> > > I posted a thread some time ago regarding Povray to VRML that might be
> of
> > > interest.  It won't create a world that you can walk through exactly -
> > more
> > > of a QuickTime VR, but with complete 360° freedom of rotation in every
> > axis.
> > >
> > > With this method, you could  create portals from one point to another
> > within
> > > your pov-generated scene to allow more freedom of movement.  Best of
> all,
> > > you get to keep all of your pov textures, radiosity & even ISO-stuff!
> > >
> > > I've done one POV-to-VRML scene that had 19 different "stations" that
> > would
> > > have been pitifully slow (if not completely useless) if it was modeled
> in
> > > VRML with the same quality of shape, texture & lighting.
> > >
> > > - Tony
> > >
> > > "C_HARMAN" <C_H### [at] tinyworldcouk> wrote in message
> > > news:3a02a720@news.povray.org...
> > > > Hello everyone,
> > > > Just one question: Does anyone know if it is at all possible to
export
> a
> > > > Pov-Ray scene to VRML?
> > > >
> > > > Thanks,
> > > >
> > > > Caroline
> > > >
> > > >
> > >
> > >
> >
> >
>
>

[TonyV] Re: Pov-Ray and VRML [9273 days 4 hours and 47 minutes ago]

Mon, 13 Nov 2000 18:55:53 GMT

Subject: VRMLizing your POV models
Dated: March 02, 1999
From: Tony Vigil

If the messages aren't available to you, I can post the information on a
website (time permitting).


"C_HARMAN" <C_H### [at] tinyworldcouk> wrote in message
news:3a0988c4@news.povray.org...
> Hi, Tony,
>
> I have been looking for the thread you mentioned, but I can't find it.
> Could you give me some more detail?(Header, where, when etc.), because I
am
> really interested.
>
> Thanks,
>
> Caroline.
>
> TonyV <tjv### [at] altavistacom> wrote in message
> news:3a033580$1@news.povray.org...
> > Look in povray.binaries.images
> >
> > I posted a thread some time ago regarding Povray to VRML that might be
of
> > interest.  It won't create a world that you can walk through exactly -
> more
> > of a QuickTime VR, but with complete 360° freedom of rotation in every
> axis.
> >
> > With this method, you could  create portals from one point to another
> within
> > your pov-generated scene to allow more freedom of movement.  Best of
all,
> > you get to keep all of your pov textures, radiosity & even ISO-stuff!
> >
> > I've done one POV-to-VRML scene that had 19 different "stations" that
> would
> > have been pitifully slow (if not completely useless) if it was modeled
in
> > VRML with the same quality of shape, texture & lighting.
> >
> > - Tony
> >
> > "C_HARMAN" <C_H### [at] tinyworldcouk> wrote in message
> > news:3a02a720@news.povray.org...
> > > Hello everyone,
> > > Just one question: Does anyone know if it is at all possible to export
a
> > > Pov-Ray scene to VRML?
> > >
> > > Thanks,
> > >
> > > Caroline
> > >
> > >
> >
> >
>
>

[Defective] Re: WANTED: a straightforward macro for keepin... [9278 days 5 hours and 13 minutes ago]

Wed, 8 Nov 2000 18:29:36 GMT

I think my brain just exploded!

I may have just worked out a useable method...

The basic idea is this:

If the objects being controlled and the camera are manipulated in
exactly the same way as the camera, they stay lined up.

What I've done is to pick a distance for the camera from the origin
and done all other aiming by rotation.  Then I placed the objects (in
this case, markers for the axes) at the origin and aimed them at where
the camera would be with no rotations.  Next, I rotate them the same
as the camera.  Finally, I translate them to their final locations.

Now I just need to wrap my mind around aiming the camera by
rotation...

I've generated a nifty little animation that demonstrates the
idea...It runs through rotations around X, Y, Z, XY, XZ, YZ and XYZ.

WARNING:  loading up the output in ACDSee and starting a full-speed,
looping slideshow in full screen mode can damage your brain!  :P

Defective O_O

---------------------------------------------------------------------------------------------------------
Sample code follows:

The scene:  (direction markers.pov)
~~~~~~~~~~

#include "metals.inc"
#include "colors.inc"           

global_settings { assumed_gamma 2.2 }

#render concat(  "\nClock: <",str(clock, 5, 2), ">\n")

///////////////////////////////////////////////////////////
#declare VXrot = clock * (
                         (clock < 360)
                       | ((clock >= 1080) & (clock < 1440))
                       | ((clock >= 1440) & (clock < 1800))
                       | ((clock >= 2160) & (clock < 2520))
                         ) ;

#declare VYrot = clock * (
                         ((clock >= 360) & (clock < 720))
                       | ((clock >= 1080) & (clock < 1440))
                       | ((clock >= 1800) & (clock < 2160))
                       | ((clock >= 2160) & (clock < 2520))
                         ) ;

#declare VZrot = clock * (
                         ((clock >= 720) & (clock < 1080))
                       | ((clock >= 1440) & (clock < 1800))
                       | ((clock >= 1800) & (clock < 2160))
                       | ((clock >= 2160) & (clock < 2520))
                         ) ;

///////////////////////////////////////////////////////////

camera { location <0, 0, -50> look_at <0,  0, 0>
        rotate <VXrot, VYrot, VZrot>        
       }

#declare Material  = T_Chrome_1D 

sphere { <0,0,0>,10 texture { T_Chrome_1D } finish { ambient 1} }


   text { 
      ttf "timrom.ttf" "+X" .1, 0
      pigment { Orange } finish { ambient 1 }
      scale 5
      rotate <VXrot, VYrot, VZrot>        
      translate <20, 0, 0>
   }

   text { 
      ttf "timrom.ttf" "+Y" .1, 0
      pigment { Orange } finish { ambient 1 }
      scale 5
      rotate <VXrot, VYrot, VZrot>        
      translate <0, 20, 0>
   }

   text { 
      ttf "timrom.ttf" "+Z" .1, 0
      pigment { Orange } finish { ambient 1 }
      scale 5
      rotate <VXrot, VYrot, VZrot>        
      translate <0, 0, 20>
   }

   text { 
      ttf "timrom.ttf" "-X" .1, 0
      pigment { Orange } finish { ambient 1 }
      scale 5
      rotate <VXrot, VYrot, VZrot>        
      translate <-20, 0, 0>
   }

   text { 
      ttf "timrom.ttf" "-Y" .1, 0
      pigment { Orange } finish { ambient 1 }
      scale 5
      rotate <VXrot, VYrot, VZrot>        
      translate <0, -20, 0>
   }

   text { 
      ttf "timrom.ttf" "-Z" .1, 0
      pigment { Orange } finish { ambient 1 }
      scale 5
      rotate <VXrot, VYrot, VZrot>        
      translate <0, 0, -20>
   }


My INI file:  (direction markers.ini)
~~~~~~~~~~~~

Initial_Clock=0
Final_Clock=2520
Initial_Frame=0
Final_Frame=360
Input_File_Name=direction markers.pov

[C HARMAN] Re: Pov-Ray and VRML [9278 days 6 hours and 33 minutes ago]

Wed, 8 Nov 2000 17:09:24 GMT

Hi, Tony,

I have been looking for the thread you mentioned, but I can't find it.
Could you give me some more detail?(Header, where, when etc.), because I am
really interested.

Thanks,

Caroline.

TonyV <tjv### [at] altavistacom> wrote in message
news:3a033580$1@news.povray.org...
> Look in povray.binaries.images
>
> I posted a thread some time ago regarding Povray to VRML that might be of
> interest.  It won't create a world that you can walk through exactly -
more
> of a QuickTime VR, but with complete 360° freedom of rotation in every
axis.
>
> With this method, you could  create portals from one point to another
within
> your pov-generated scene to allow more freedom of movement.  Best of all,
> you get to keep all of your pov textures, radiosity & even ISO-stuff!
>
> I've done one POV-to-VRML scene that had 19 different "stations" that
would
> have been pitifully slow (if not completely useless) if it was modeled in
> VRML with the same quality of shape, texture & lighting.
>
> - Tony
>
> "C_HARMAN" <C_H### [at] tinyworldcouk> wrote in message
> news:3a02a720@news.povray.org...
> > Hello everyone,
> > Just one question: Does anyone know if it is at all possible to export a
> > Pov-Ray scene to VRML?
> >
> > Thanks,
> >
> > Caroline
> >
> >
>
>

[janger] heightfields with i_dat3d [9282 days 16 hours and 4 minutes ago]

Sat, 4 Nov 2000 07:38:24 GMT

Anyone help me with generating heightfields using MegaPov and the built-in
i_dat3d library routines?
I have no idea how the data points are mapped. I've read the megapov help,
and it doesn't make it clear to me. Sample data files give me unexpected
results.
I've searched the pov site, the net, my mind... just can't make sense of it
all.
For an example, what would the data values be to build a simple four-sided
pyramid shape?

[TonyV] Re: Pov-Ray and VRML [9283 days 1 hour and 42 minutes ago]

Fri, 3 Nov 2000 22:00:32 GMT

Look in povray.binaries.images

I posted a thread some time ago regarding Povray to VRML that might be of
interest.  It won't create a world that you can walk through exactly - more
of a QuickTime VR, but with complete 360° freedom of rotation in every axis.

With this method, you could  create portals from one point to another within
your pov-generated scene to allow more freedom of movement.  Best of all,
you get to keep all of your pov textures, radiosity & even ISO-stuff!

I've done one POV-to-VRML scene that had 19 different "stations" that would
have been pitifully slow (if not completely useless) if it was modeled in
VRML with the same quality of shape, texture & lighting.

- Tony

"C_HARMAN" <C_H### [at] tinyworldcouk> wrote in message
news:3a02a720@news.povray.org...
> Hello everyone,
> Just one question: Does anyone know if it is at all possible to export a
> Pov-Ray scene to VRML?
>
> Thanks,
>
> Caroline
>
>

[Warp] Re: Pov-Ray and VRML [9283 days 11 hours and 28 minutes ago]

Fri, 3 Nov 2000 12:15:02 GMT

C_HARMAN <C_H### [at] tinyworldcouk> wrote:
: Just one question: Does anyone know if it is at all possible to export a
: Pov-Ray scene to VRML?

  Nope.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[C HARMAN] Pov-Ray and VRML [9283 days 11 hours and 50 minutes ago]

Fri, 3 Nov 2000 11:53:04 GMT

Hello everyone,
Just one question: Does anyone know if it is at all possible to export a
Pov-Ray scene to VRML?

Thanks,

Caroline

[Defective] Re: WANTED: a straightforward macro for keepin... [9286 days 5 hours and 23 minutes ago]

Tue, 31 Oct 2000 18:19:37 GMT

On Mon, 30 Oct 2000 08:18:34 +0200, Peter Popov <pet### [at] usanet>
wrote:

>>Now, I keep tripping over these silly little spheres and boxes.
>
>Try using arrows made of cylinders and cones. I think there's a sample
>scene included with POV-Ray and/or an item in the Insert menu in the
>Windows version.

Unfortunately, this method leads to the same problem as the spheres
and boxes.  It creates shapes that distract from the object I'm
working on...

>
>>Now, I'm trying to do this with text.  (I find the little Xs, Ys and
>>Zs less distracting...)  Unfortunately, the letters are just a bit
>>hard to read except from directly in front or back.  I've managed to
>>find a little macro using atan() that allows me to aim objects at a
>>focal point.  (Someone on the POV-Ray Study Forum at Delphi worked it
>>out for aiming eyeballs...)  Problem is that it doesn't work if the
>>camera (and focal point) are on the Z plane and things seem to forget
>>where to look if I get near the Y axis.
>>
>>Anybody got ideas?
>
>Try using John VanSickle's Reorient macro, part of his Throroughly
>Useful Macros package. There's a link to his site on the povray.org
>link section.

This method still requires that I work out the axes to point the
letters along.  I think I've got this worked out now.  But I keep
finding that things like to point the wrong way.  I'm starting to
think that, maybe, there's a bug someplace in PoV...

I've created a little sample scene to test the algorithm and it's
giving me odd results.

The following bit of code draws the axes and places a little yellow
ball at the position indicated by HereItIs.  Then it draws a line
starting at the origin and running through HereItIs.  I haven't quite
worked out how to deal with the ball sitting on the X, Y or Z axis,
but it tells me the angles are right for all other cases.  Just
doesn't seem to draw the line there...

-------------------------------------------------
example code:
-------------------------------------------------

#include "colors.inc"
#include "macs.inc"

	#declare ViewPoint = <50, -50, -50> ;

	camera { location ViewPoint look_at   <0,  0, 0> }

//////////////////////  Draw the axes  /////////////////////

sphere   {<0,0,0>,1             
	 pigment { White } finish { ambient 1 } }
cylinder {<-49,0,0>,<49,0,0>,.05 
	pigment { Red   } finish { ambient 1 } }
cylinder {<0,-49,0>,<0,49,0>,.05 
	pigment { Green } finish { ambient 1 } }
cylinder {<0,0,-49>,<0,0,49>,.05 
	pigment { Blue  } finish { ambient 1 } }

//////////////////////////////////////////////////////////////////

#macro LookHere(from_pos, to_pos)
  #local Dx = to_pos.x - from_pos.x * sgn(to_pos.x) ;
  #local Dy = to_pos.y - from_pos.y * sgn(to_pos.y) ;
  #local Dz = to_pos.z - from_pos.z * sgn(to_pos.z) ;

  #if (Dy)
    #local Ax = degrees(atan2(Dz,Dy)) ;
  #else
    #local Ax = 0 ;
  #end
  
  #if (Dz)
    #local Ay = degrees(atan2(Dx,Dz)) ;
  #else
    #local Ay = 0 ;
  #end
  
  #if (Dx)
    #local Az = degrees(atan2(Dy,Dx)) ;
  #else
    #local Az = 0 ;
  #end

#render concat("Dx: ",str(Dx, 5, 2),"\n",
	"Dy: ",str(Dy, 5, 2),"\n",
	"Dz: ",str(Dz, 5, 2),"\n")
#render concat("Ax: ",str(Ax, 10, 7),"\n",
	"Ay: ",str(Ay, 10, 7),"\n",
	"Az: ",str(Az, 10, 7),"\n\n")

  Reorient(y,<Ax,Ay,Az>)

#end


#declare HereItIs = <10,15,10> ;

sphere   {HereItIs,1 pigment { Yellow } finish { ambient 1 } }

cylinder {<0,0,0>,<0,45,0>.1 
	pigment { Orange } finish { ambient 1 }
	LookHere(<0,0,0>,HereItIs)      }

[Peter Popov] Re: WANTED: a straightforward macro for keepin... [9287 days 17 hours and 22 minutes ago]

Mon, 30 Oct 2000 06:20:33 GMT

On Sun, 29 Oct 2000 03:30:39 -0500, Defective <def### [at] homecom>
wrote:

>My early attempts to keep track of direction involved placing colored
>spheres some distance out along the axes and trying to remember that
>red means X, green means Y and blue means Z.  Of course, this doesn't
>help with positive vs. negative.  So I changed the ones on the
>negative ends to boxes.
>
>Now, I keep tripping over these silly little spheres and boxes.

Try using arrows made of cylinders and cones. I think there's a sample
scene included with POV-Ray and/or an item in the Insert menu in the
Windows version.

>Now, I'm trying to do this with text.  (I find the little Xs, Ys and
>Zs less distracting...)  Unfortunately, the letters are just a bit
>hard to read except from directly in front or back.  I've managed to
>find a little macro using atan() that allows me to aim objects at a
>focal point.  (Someone on the POV-Ray Study Forum at Delphi worked it
>out for aiming eyeballs...)  Problem is that it doesn't work if the
>camera (and focal point) are on the Z plane and things seem to forget
>where to look if I get near the Y axis.
>
>Anybody got ideas?

Try using John VanSickle's Reorient macro, part of his Throroughly
Useful Macros package. There's a link to his site on the povray.org
link section.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

[Defective] WANTED: a straightforward macro for keeping ob... [9288 days 15 hours and 10 minutes ago]

Sun, 29 Oct 2000 08:32:34 GMT

For some time now, I've been trying to find a way to make objects in
my scenes face the camera.  It's not as easy as it sounds.

The background to this:  Whenever I'm working on an object of any
complexity, I like to move the camera around and see what it'll look
like from different angles.  This, of course, means I keep forgetting
which way is up.

My early attempts to keep track of direction involved placing colored
spheres some distance out along the axes and trying to remember that
red means X, green means Y and blue means Z.  Of course, this doesn't
help with positive vs. negative.  So I changed the ones on the
negative ends to boxes.

Now, I keep tripping over these silly little spheres and boxes.

Now, I'm trying to do this with text.  (I find the little Xs, Ys and
Zs less distracting...)  Unfortunately, the letters are just a bit
hard to read except from directly in front or back.  I've managed to
find a little macro using atan() that allows me to aim objects at a
focal point.  (Someone on the POV-Ray Study Forum at Delphi worked it
out for aiming eyeballs...)  Problem is that it doesn't work if the
camera (and focal point) are on the Z plane and things seem to forget
where to look if I get near the Y axis.

Anybody got ideas?

Defective O-O
-----------------------------------------------------------------------------------------------------------

Sample code follows:

The macro:

	#macro LookHere(from_pos)
	  #local dist=ViewPoint - from_pos;
	
	  #local xrot= degrees(atan2(dist.y,-dist.z));
	  #local yrot=-degrees(atan2(dist.x,-dist.z));
	
	  // rotate about the origin  
	  rotate <0,yrot,0>
	  rotate <xrot,0,0>
	  
	  //and move to the desired position
	  translate from_pos
	#end


The application:

	#include "colors.inc"

	#declare ViewPoint = <50, 50, -0.1> ;
		// change parameters of ViewPoint to move both the
		// camera and the point the objects are aimed at.

	camera { location ViewPoint look_at   <0,  0, 0> }

	object { text { ttf "arial.ttf" "+X" .1, 0
		 pigment { White } finish { ambient 1 } scale 3 }
		 LookHere(<15.0, 0.0, 0.0>) }
	object { text { ttf "arial.ttf" "+Y" .1, 0
		 pigment { White } finish { ambient 1 } scale 3 }
		 LookHere(<0.0, 15.0, 0.0>) }
	object { text { ttf "arial.ttf" "+Z" .1, 0
		 pigment { White } finish { ambient 1 } scale 3 }
		 LookHere(<0.0, 0.0, 15.0>) }

	object { text { ttf "arial.ttf" "-X" .1, 0
		 pigment { White } finish { ambient 1 } scale 3 }
		 LookHere(<-15.0, 0.0, 0.0>) }
	object { text { ttf "arial.ttf" "-Y" .1, 0
		 pigment { White } finish { ambient 1 } scale 3 }
		 LookHere(<0.0, -15.0, 0.0>) }
	object { text { ttf "arial.ttf" "-Z" .1, 0
		 pigment { White } finish { ambient 1 } scale 3 }
		 LookHere(<0.0, 0.0, -15.0>) }

	object { text { ttf "arial.ttf" "Origin" .1, 0
		 pigment { White } finish { ambient 1 } scale 3 } }

[C J ] Re: "Section B" Done! [9307 days 6 hours and 36 minutes ago]

Tue, 10 Oct 2000 17:06:59 GMT

Doh!
And it's only been like that fore a few months.....
Doh!


Regards,
C.J.

P.S.-A patch will be released soon!
;)


23yrold3yrold <cba### [at] pangeaca> wrote in message
news:39e0a4bd@news.povray.org...
>
> "C.J. - POV User" <hou### [at] yahoocom> wrote in message
> news:39b4654a$1@news.povray.org...
> > The second part of the "Building the T.S.N. Hensly" is now done and
ready
> > for your feed back!
> >
> > Just remember to play nice!
> > Regards,
>
> Newbie here, saw your site, VERY nice! Quick comment in your gears
tutorial;
> that's how my little sister spells "animation" ;)..........
>
>
> Chris
>
>

[23yrold3yrold] Re: "Section B" Done! [9309 days 6 hours and 57 minutes ago]

Sun, 8 Oct 2000 16:45:49 GMT

"C.J. - POV User" <hou### [at] yahoocom> wrote in message
news:39b4654a$1@news.povray.org...
> The second part of the "Building the T.S.N. Hensly" is now done and ready
> for your feed back!
>
> Just remember to play nice!
> Regards,

Newbie here, saw your site, VERY nice! Quick comment in your gears tutorial;
that's how my little sister spells "animation" ;)..........


Chris

[C J ] Re: "Section B" Done! [9335 days 8 hours and 30 minutes ago]

Tue, 12 Sep 2000 15:12:38 GMT

CW has stated the Ban has been lifted....

C.J.
C.J. <hou### [at] yahoocom> wrote in message
news:39b64349$1@news.povray.org...
> CW is stating they has someone that can clear this up in no time. And the
> spammer originated from another ISP, not server. As they put it, "It  came
> from a BIG ISP!", I guess they did not want to name the Big One....
>
> --

> Pabs <pab### [at] hotmailcom> wrote in message
> news:39B5BFCC.897FEAE3@hotmail.com...
> > "C.J." wrote:
> >
> > > This may be the cause...
> > >
> > > quote from Crosswinds Team:
> > > ====================
> > > "September 5, 2000, 12:55pm Network woes and UUNet
> > > Scott received an email this morning from our backbone provider that
> UUNet
> > > will blackhole (completely cut off) Crosswinds servers if we do not
> > > terminate a person that SPAMMED UUNet customers using a CW url. This
> > > blackhole will begin September 1, 2000. We received the email
September
> 5.
> > > See the problem? ..."
> > >
> > > It seems that the spam originated from another server, but crosswinds
> had
> > > some sort of ad running (weird...).
> > >
> > > CW is dealing with UUNet to resolve the problem.
> >
> > Thanx for the info - hope they deal with the spammer soon
> > --
> > Bye
> > Pabs
> >
>
>

[] lights [9339 days 2 hours and 34 minutes ago]

Fri, 8 Sep 2000 21:08:41 GMT

can anyone tell me how to make a track of lights please

Jason

[C J ] Re: "Section B" Done! [9341 days 10 hours and 28 minutes ago]

Wed, 6 Sep 2000 13:14:49 GMT

CW is stating they has someone that can clear this up in no time. And the
spammer originated from another ISP, not server. As they put it, "It  came
from a BIG ISP!", I guess they did not want to name the Big One....

--
Chris Jokinen
Data-Trak, Inc.
chr### [at] data-trakcom
PH. (800) 453-3972
FAX (409) 297-7725
Pabs <pab### [at] hotmailcom> wrote in message
news:39B5BFCC.897FEAE3@hotmail.com...
> "C.J." wrote:
>
> > This may be the cause...
> >
> > quote from Crosswinds Team:
> > ====================
> > "September 5, 2000, 12:55pm Network woes and UUNet
> > Scott received an email this morning from our backbone provider that
UUNet
> > will blackhole (completely cut off) Crosswinds servers if we do not
> > terminate a person that SPAMMED UUNet customers using a CW url. This
> > blackhole will begin September 1, 2000. We received the email September
5.
> > See the problem? ..."
> >
> > It seems that the spam originated from another server, but crosswinds
had
> > some sort of ad running (weird...).
> >
> > CW is dealing with UUNet to resolve the problem.
>
> Thanx for the info - hope they deal with the spammer soon
> --
> Bye
> Pabs
>

[Pabs] Re: "Section B" Done! [9341 days 19 hours and 50 minutes ago]

Wed, 6 Sep 2000 03:52:42 GMT

"C.J." wrote:

> This may be the cause...
>
> quote from Crosswinds Team:
> ====================
> "September 5, 2000, 12:55pm Network woes and UUNet
> Scott received an email this morning from our backbone provider that UUNet
> will blackhole (completely cut off) Crosswinds servers if we do not
> terminate a person that SPAMMED UUNet customers using a CW url. This
> blackhole will begin September 1, 2000. We received the email September 5.
> See the problem? ..."
>
> It seems that the spam originated from another server, but crosswinds had
> some sort of ad running (weird...).
>
> CW is dealing with UUNet to resolve the problem.

Thanx for the info - hope they deal with the spammer soon
--
Bye
Pabs

[C J ] Re: "Section B" Done! [9342 days 3 hours and 36 minutes ago]

Tue, 5 Sep 2000 20:06:33 GMT

This may be the cause...

quote from Crosswinds Team:
====================
"September 5, 2000, 12:55pm Network woes and UUNet
Scott received an email this morning from our backbone provider that UUNet
will blackhole (completely cut off) Crosswinds servers if we do not
terminate a person that SPAMMED UUNet customers using a CW url. This
blackhole will begin September 1, 2000. We received the email September 5.
See the problem? ..."

It seems that the spam originated from another server, but crosswinds had
some sort of ad running (weird...).

CW is dealing with UUNet to resolve the problem.

Pabs <pab### [at] hotmailcom> wrote in message
news:39B46AC3.10F27F45@hotmail.com...
> "C.J. - POV User" wrote:
>
> > Hmm....
> > a link might help, right?
>
> That depends on whether the server is offline/unavailable
> "The requested URL could not be retrieved
> While trying to retrieve the URL: http://www.crosswinds.net/~povstudy
> The following error was encountered:
>      Connection Failed
> The system returned:
>     (113) No route to host
> The remote host or network may be down. Please try the request again."
>
> Bye
> Pabs
>

[Ken] Re: "Section B" Done! [9342 days 19 hours and 23 minutes ago]

Tue, 5 Sep 2000 04:20:07 GMT

Pabs wrote:

> BTW what does "(113) No route to host" mean anyway.

Probably means one of the internet routers that connects
you to that area of the world or ISP server is not working
right now - <I'm guessing>.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Pabs] Re: "Section B" Done! [9342 days 19 hours and 52 minutes ago]

Tue, 5 Sep 2000 03:50:37 GMT

Ken wrote:

> Pabs wrote:
> >
> > "C.J. - POV User" wrote:
> >
> > > Hmm....
> > > a link might help, right?
> >
> > That depends on whether the server is offline/unavailable
> > "The requested URL could not be retrieved
> > While trying to retrieve the URL: http://www.crosswinds.net/~povstudy
>
> I just tried it and had no problems reaching the site.

Wierd - I just tried it (again) and had the same problem reaching the site.
Must be my connection - can't access crosswinds at all!!!

BTW what does "(113) No route to host" mean anyway.

--
Bye
Pabs

[Ken] Re: "Section B" Done! [9342 days 20 hours and 3 minutes ago]

Tue, 5 Sep 2000 03:39:40 GMT

Pabs wrote:
> 
> "C.J. - POV User" wrote:
> 
> > Hmm....
> > a link might help, right?
> 
> That depends on whether the server is offline/unavailable
> "The requested URL could not be retrieved
> While trying to retrieve the URL: http://www.crosswinds.net/~povstudy

I just tried it and had no problems reaching the site.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Pabs] Re: "Section B" Done! [9342 days 20 hours and 4 minutes ago]

Tue, 5 Sep 2000 03:38:20 GMT

"C.J. - POV User" wrote:

> Hmm....
> a link might help, right?

That depends on whether the server is offline/unavailable
"The requested URL could not be retrieved
While trying to retrieve the URL: http://www.crosswinds.net/~povstudy
The following error was encountered:
     Connection Failed
The system returned:
    (113) No route to host
The remote host or network may be down. Please try the request again."

Bye
Pabs

[C J - POV User] Re: "Section B" Done! [9342 days 20 hours and 25 minutes ago]

Tue, 5 Sep 2000 03:17:24 GMT

Hmm....
a link might help, right?
www.crosswinds.net/~povstudy
Click on
[Tutorials],[POV Advanced]

OK,

C.J. - POV User <hou### [at] yahoocom> wrote in message
news:39b4654a$1@news.povray.org...
> The second part of the "Building the T.S.N. Hensly" is now done and ready
> for your feed back!
>
> Just remember to play nice!
> Regards,
>
>

[C J - POV User] "Section B" Done! [9342 days 20 hours and 27 minutes ago]

Tue, 5 Sep 2000 03:15:22 GMT

The second part of the "Building the T.S.N. Hensly" is now done and ready
for your feed back!

Just remember to play nice!
Regards,

[Chris Huff] Re: glow [9345 days 7 hours and 17 minutes ago]

Sat, 2 Sep 2000 16:26:14 GMT

In article <39b117a0@news.povray.org>, "§FireFly§" 
<fir### [at] hotmailcom> wrote:

> thanx for the lens link but I need to make the glow from the media 
> statement sorry I was not right to the point

This has been asked several times before, look for this thread in 
povray.newusers:
"Heather Pinnix" <hjp### [at] mindspringcom>  Bright Spot aka Fire Fly    
11  00.07.01 3:17 PM

Also, there are several media demo scenes which do this.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

[] Re: glow [9345 days 8 hours and 36 minutes ago]

Sat, 2 Sep 2000 15:07:12 GMT

thanx for the lens link but I need to make the glow from the media statement
sorry I was not right to the point

§FireFly§ <fir### [at] hotmailcom> wrote in message
news:39af15ec@news.povray.org...
> does anyone know how to make a sphere glow I cant figure it out at all???
>
>

[Warp] Re: glow [9346 days 20 hours and 57 minutes ago]

Fri, 1 Sep 2000 02:45:42 GMT

§FireFly§ <fir### [at] hotmailcom> wrote:
: does anyone know how to make a sphere glow I cant figure it out at all???

  You should be more specific about this question.

  Do you mean that the sphere should be bright and seen even in the darkness,
as if it was emitting light by itself (like a led or similar)?
  In this case your answer is setting the ambient value of the object
to 1 or higher.

  Do you mean that the object should glow so that a haze or halo of light
should appear faintly around the object?
  If so, then the method of achieving this is not so easy anymore, nor there
is a unique answer to the question.
  The most obvious method is using an emitting media. Mastering media,
however, takes time and it's not one of the most easy-to-use features in
povray.
  Sometimes it's just enough to fake a glow with a lens flare effect. You
can use some lens flare include file to achieve this, eg:
http://www.geocities.com/ccolefax/lenseffects.html

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[] glow [9346 days 21 hours and 7 minutes ago]

Fri, 1 Sep 2000 02:35:24 GMT

does anyone know how to make a sphere glow I cant figure it out at all???

[C J ] Re: Fire [9350 days 10 hours ago]

Mon, 28 Aug 2000 13:43:09 GMT

I have two tutorials on my site for making fire in POV. One by myself and
another by Tony (forgot his last name...). Both can be found in POV
Advanced, under tutorials.

Hope that helps...
C.J. - POV User
POV Ray Study Gallery
www.crosswinds.net/~povstudy

§FireFly§ <fir### [at] hotmailcom> wrote in message
news:39a84e14@news.povray.org...
> does anyone know where I can get a tutorial for makign fire ????
>
>

[] Fire [9352 days and 34 minutes ago]

Sat, 26 Aug 2000 23:09:08 GMT

does anyone know where I can get a tutorial for makign fire ????

[Ammar Al-Allak] Scattering In POV Ray [9355 days 11 hours and 22 minutes ago]

Wed, 23 Aug 2000 12:20:46 GMT

Hi

Fromt what I understand, wave independent scattering is not physically
accuarate since it doesn't take the wavelength into account, but to be
honest
I don't really understand the principal of that. (Some sort of a detailed
explanation would help!!)

I also need the precise algorithm POV Ray uses for Rayleigh scattering and
how it could be modified so that it becomes Wave dependent.

I need this information asap PLEASE.

Thank you

Ammar

[Ken] Re: Animation Agrivations [9359 days 14 hours and 47 minutes ago]

Sat, 19 Aug 2000 08:55:48 GMT

ryan constantine wrote:
> 
> that's a tough order.  a tutorial i like goes with chris colefax's
> animation include and macro files.  look for it in povray's links or
> check recent posts in all the groups because someone else asked a
> similar question and ken gave the link.

http://www.puzzlecraft.com/cm/ClockMod.html

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[ryan constantine] Re: Animation Agrivations [9359 days 15 hours and 18 minutes ago]

Sat, 19 Aug 2000 08:24:51 GMT

that's a tough order.  a tutorial i like goes with chris colefax's
animation include and macro files.  look for it in povray's links or
check recent posts in all the groups because someone else asked a
similar question and ken gave the link.

Chris wrote:
> 
> Can anyone out there tell where I can find a really good animation tutorial
> for a completey braindead newbie?

[Chris] Animation Agrivations [9359 days 16 hours and 38 minutes ago]

Sat, 19 Aug 2000 07:04:23 GMT

Can anyone out there tell where I can find a really good animation tutorial
for a completey braindead newbie?

[Peter Popov] Re: New Tutorial [9362 days 17 hours and 19 minutes ago]

Wed, 16 Aug 2000 06:24:06 GMT

On Tue, 15 Aug 2000 18:12:03 -0700, Ken <tyl### [at] pacbellnet> wrote:

>My Brothers Opinion of HTML: 
>
>"What a goofy idea. Who would have thought that a primitive text
>formatting language would be a threat to Windows NT and the rest
>of the high-tech world."
>
>(As quoted from his home page)
>
>I tend to agree with him :)

Me too. Yesterday I was able to kill NS and Windows with a simple page
involving nothing but a table with another table in one of it's cells.
Go figure...


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

[Ken] Re: New Tutorial [9362 days 22 hours and 29 minutes ago]

Wed, 16 Aug 2000 01:13:49 GMT

Peter Popov wrote:
> 
> On Mon, 14 Aug 2000 12:33:44 -0700, "C.J."
> <hou### [at] yahoocom> wrote:
> 
> >I guess that will teach me to not HTML and drink.....well maybe.
> 
> Why not, I've had my best results that way. Or do you happen to know
> of any other way to keep your sanity trying to work some simple HTML
> code work under NS?

My Brothers Opinion of HTML: 

"What a goofy idea. Who would have thought that a primitive text
formatting language would be a threat to Windows NT and the rest
of the high-tech world."

(As quoted from his home page)

I tend to agree with him :)

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Peter Popov] Re: New Tutorial [9363 days 3 hours and 59 minutes ago]

Tue, 15 Aug 2000 19:43:25 GMT

On Mon, 14 Aug 2000 12:33:44 -0700, "C.J."
<hou### [at] yahoocom> wrote:

>I guess that will teach me to not HTML and drink.....well maybe.

Why not, I've had my best results that way. Or do you happen to know
of any other way to keep your sanity trying to work some simple HTML
code work under NS?


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

[C J - POV User] Re: New Tutorial [9363 days 20 hours and 11 minutes ago]

Tue, 15 Aug 2000 03:31:35 GMT

There, now it's all fixed. And I only used one chicken....

C.J. - POV User
POV Ray Study Gallery
www.crosswinds.net/~povstudy


C.J. <hou### [at] yahoocom> wrote in message
news:39982e55$1@news.povray.org...
> I went back and looked at the code. Oops! I can not believe I did that. O
> well, I guess I will correct it tonight. Anyway, thanks for pointing it
out,
> I guess that will teach me to not HTML and drink.....well maybe.
>
> Regards,
> C.J. - POV User
>
> P.S. Visual Page 2.0 is made by Symantec, "The Leader in HTML Editors...
or
> something like that." I got it with my Norton System Works(on windows
> because windows doesn't...) and its an earlier "What you see..." editor. I
> also have 1st page, which I like much more, but VP is just faster at
> building the page(s) from a template.
>
>
> Christoph Hormann <Chr### [at] schunteretctu-bsde> wrote in
message
> news:3998233C.F0284BFD@schunter.etc.tu-bs.de...
> >
> >
> > "C.J." wrote:
> > >
> > [...]
> > >
> > > Was the font to small to read?
> > >
> >
> > No, that's not the problem, you have to use the <pre> tag to get text
> formatted
> > as seen in the text editor.  I think there are some other pages on your
> site,
> > that used <pre>.
> >
> > > The code was copied from POV to Notepad, where I did my comments. The
> Indent
> > > that I have in POV should have been intact, but I will look it over
> again.
> > >
> > > I left the greyed sections in, so a new reader (On modeling) can see
> exactly
> > > how the code changes as they progress thru the tutorial. The colored
> > > sections I felt made it a simple issue to note the changes in the
scene,
> > > step-by-step.
> >
> > You seem to use Visual Page 2.0 to build your page, i don't know that
> prog,
> > maybe you should format your Pov-code parts by hand.
> >
> > Christoph
> >
> > --
> > Christoph Hormann <chr### [at] gmxde>
> > Homepage: http://www.schunter.etc.tu-bs.de/~chris/
>
>

[C J ] Re: New Tutorial [9364 days 6 hours and 5 minutes ago]

Mon, 14 Aug 2000 17:37:25 GMT

I went back and looked at the code. Oops! I can not believe I did that. O
well, I guess I will correct it tonight. Anyway, thanks for pointing it out,
I guess that will teach me to not HTML and drink.....well maybe.

Regards,
C.J. - POV User

P.S. Visual Page 2.0 is made by Symantec, "The Leader in HTML Editors... or
something like that." I got it with my Norton System Works(on windows
because windows doesn't...) and its an earlier "What you see..." editor. I
also have 1st page, which I like much more, but VP is just faster at
building the page(s) from a template.

Christoph Hormann <Chr### [at] schunteretctu-bsde> wrote in message
news:3998233C.F0284BFD@schunter.etc.tu-bs.de...
>
>
> "C.J." wrote:
> >
> [...]
> >
> > Was the font to small to read?
> >
>
> No, that's not the problem, you have to use the <pre> tag to get text
formatted
> as seen in the text editor.  I think there are some other pages on your
site,
> that used <pre>.
>
> > The code was copied from POV to Notepad, where I did my comments. The
Indent
> > that I have in POV should have been intact, but I will look it over
again.
> >
> > I left the greyed sections in, so a new reader (On modeling) can see
exactly
> > how the code changes as they progress thru the tutorial. The colored
> > sections I felt made it a simple issue to note the changes in the scene,
> > step-by-step.
>
> You seem to use Visual Page 2.0 to build your page, i don't know that
prog,
> maybe you should format your Pov-code parts by hand.
>
> Christoph
>
> --
> Christoph Hormann <chr### [at] gmxde>
> Homepage: http://www.schunter.etc.tu-bs.de/~chris/

[Christoph Hormann] Re: New Tutorial [9364 days 6 hours and 53 minutes ago]

Mon, 14 Aug 2000 16:49:31 GMT

"C.J." wrote:
> 
[...]
> 
> Was the font to small to read?
> 

No, that's not the problem, you have to use the <pre> tag to get text formatted
as seen in the text editor.  I think there are some other pages on your site,
that used <pre>.

> The code was copied from POV to Notepad, where I did my comments. The Indent
> that I have in POV should have been intact, but I will look it over again.
> 
> I left the greyed sections in, so a new reader (On modeling) can see exactly
> how the code changes as they progress thru the tutorial. The colored
> sections I felt made it a simple issue to note the changes in the scene,
> step-by-step.

You seem to use Visual Page 2.0 to build your page, i don't know that prog,
maybe you should format your Pov-code parts by hand.

Christoph

--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/

[C J ] Re: New Tutorial [9364 days 8 hours and 2 minutes ago]

Mon, 14 Aug 2000 15:41:02 GMT

Christoph,
Thanks, it is hard to get any feed-back on a tutorial (makes you wonder if
you've screwed it all up or lost the reader in the dark).

Was the font to small to read?

The code was copied from POV to Notepad, where I did my comments. The Indent
that I have in POV should have been intact, but I will look it over again.

I left the greyed sections in, so a new reader (On modeling) can see exactly
how the code changes as they progress thru the tutorial. The colored
sections I felt made it a simple issue to note the changes in the scene,
step-by-step.
In Section B (and the rest that follow), the code will be more modular. The
next section will cover, adding more detail to each part of the ship, and
include the engines.

Regards,
C.J. - POV User

Christoph Hormann <Chr### [at] schunteretctu-bsde> wrote in message
news:3997AA9B.F135B08F@schunter.etc.tu-bs.de...
>
>
> "C.J. - POV User" wrote:
> >
> > I just finished the first section of, Building the T.N.S. Hensly. This
> > section covers modeling the general shape of the ship. Let me know what
you
> > think.
> >
>
> Looks quite detailed, how about using non-proportional font type ( <pre>
would
> work quite well) and indention, that would make the code more appealing.
I
> would also consider making it modular, so you don't have to carry around
the
> greyed parts.
>
> Looking forward to the texturing part :-)
>
> Christoph
>
> --
> Christoph Hormann <chr### [at] gmxde>
> Homepage: http://www.schunter.etc.tu-bs.de/~chris/

[Christoph Hormann] Re: New Tutorial [9364 days 15 hours and 28 minutes ago]

Mon, 14 Aug 2000 08:14:53 GMT

"C.J. - POV User" wrote:
> 
> I just finished the first section of, Building the T.N.S. Hensly. This
> section covers modeling the general shape of the ship. Let me know what you
> think.
> 

Looks quite detailed, how about using non-proportional font type ( <pre> would
work quite well) and indention, that would make the code more appealing.  I
would also consider making it modular, so you don't have to carry around the
greyed parts. 

Looking forward to the texturing part :-)

Christoph 

--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/

[C J - POV User] New Tutorial [9365 days 9 hours and 56 minutes ago]

Sun, 13 Aug 2000 13:46:31 GMT

I just finished the first section of, Building the T.N.S. Hensly. This
section covers modeling the general shape of the ship. Let me know what you
think.

It can be found in POV Advance, under tutorials.


Regards,
C.J. - POV User
POV Ray Study Gallery
www.crosswinds.net/~povstudy

[TigerHawk] Re: Tilegen help [9371 days 4 hours and 5 minutes ago]

Mon, 7 Aug 2000 19:37:50 GMT

Thanks!

ryan constantine wrote:

> here it is:
> http://www.gate.net/~shipbrk/
>

[ryan constantine] Re: Tilegen help [9371 days 4 hours and 27 minutes ago]

Mon, 7 Aug 2000 19:16:09 GMT

here it is:
http://www.gate.net/~shipbrk/

TigerHawk wrote:
> 
> Hmmm :( I couldn't find it on pov-links or via dogpile :(
> 
> Tim Soderstrom
> PsiTron / TigerHawk of Nutropik
> 
> ryan constantine wrote:
> 
> > if you want random looking stone or bricks or whatever, check out jeff
> > lee's macro at his web site.  it's really good.  i'm sure there is a
> > link on pov.org's links section.

[TigerHawk] Re: Tilegen help [9371 days 4 hours and 34 minutes ago]

Mon, 7 Aug 2000 19:08:52 GMT

Hmmm :( I couldn't find it on pov-links or via dogpile :(

Tim Soderstrom
PsiTron / TigerHawk of Nutropik

ryan constantine wrote:

> if you want random looking stone or bricks or whatever, check out jeff
> lee's macro at his web site.  it's really good.  i'm sure there is a
> link on pov.org's links section.

[ryan constantine] Re: Tilegen help [9371 days 18 hours and 1 minute ago]

Mon, 7 Aug 2000 05:41:43 GMT

if you want random looking stone or bricks or whatever, check out jeff
lee's macro at his web site.  it's really good.  i'm sure there is a
link on pov.org's links section.

TigerHawk wrote:
> 
> Hmm...I just downloaded tilegen and was hoping to find some help with
> it's function. The scene is below, if you want to take a gander at it.
> The problem I am having is that I want to tile the image (duh), but I
> find that when I smooth the tiles, the seams still show quite well. I
> believe this is because of the nature of the texture (rock, heh :). So
> in a nutshell, is there a way, via TileGen or some other method, to have
> Pov-Ray create tiled image without the seams?
> 
> Thanks for any help you can give,
> 
> Tim Soderstrom
> PsiTron / TigerHawk of Nutropik
> 
> #include "d:\visual\povray\include\TileGen\tilegen.mcr"
> 
> #declare Mortar =
> texture{
>  pigment{ color rgb .25 }
> }
> 
> #declare Stone =
> texture{
>  pigment{ color rgb .65 }
>  normal{ granite .65 }
> }
> 
> #declare GraniteStone =
> texture{
>  crackle
>   texture_map{
>    [0.00 Mortar ]
>    [0.10 Stone ]
>   }
> }
> 
> light_source{
>  <0, 0, -50>
>  color rgb 1
> }
> 
> #declare tile_size = <3, 3>;
> #declare tile_direction = <1, 1>;
> set_tile_camera ()
> texture_tile (GraniteStone, 0)

[TigerHawk] Tilegen help [9372 days and 4 minutes ago]

Sun, 6 Aug 2000 23:38:48 GMT

Hmm...I just downloaded tilegen and was hoping to find some help with
it's function. The scene is below, if you want to take a gander at it.
The problem I am having is that I want to tile the image (duh), but I
find that when I smooth the tiles, the seams still show quite well. I
believe this is because of the nature of the texture (rock, heh :). So
in a nutshell, is there a way, via TileGen or some other method, to have
Pov-Ray create tiled image without the seams?

Thanks for any help you can give,

Tim Soderstrom
PsiTron / TigerHawk of Nutropik

#include "d:\visual\povray\include\TileGen\tilegen.mcr"

#declare Mortar =
texture{
 pigment{ color rgb .25 }
}

#declare Stone =
texture{
 pigment{ color rgb .65 }
 normal{ granite .65 }
}

#declare GraniteStone =
texture{
 crackle
  texture_map{
   [0.00 Mortar ]
   [0.10 Stone ]
  }
}

light_source{
 <0, 0, -50>
 color rgb 1
}

#declare tile_size = <3, 3>;
#declare tile_direction = <1, 1>;
set_tile_camera ()
texture_tile (GraniteStone, 0)

[Alan Nickerson] Re: Area Lights... for a florescent light [9374 days 10 hours and 42 minutes ago]

Fri, 4 Aug 2000 13:00:55 GMT

I'm using MegaPOV 0.5.

I have a union with the light fixture and a light_source that 'looks_like'
tube object that has emission media.

Alan

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-9A0051.13075303082000@news.povray.org...
> In article <39896fcd$1@news.povray.org>, "Alan Nickerson"
> <ani### [at] mathsoftcom> wrote:
>
> > Thanks, I didnt try a high-ambient for the object.
> > I did create a "tube' that glows using an emission media.
>
> Emission media won't emit light(it doesn't illuminate surrounding
> objects), and radiosity in the official version won't see it. If you are
> using MegaPOV, the radiosity should work fine with media.
>
> --
> Christopher James Huff - Personal e-mail: chr### [at] maccom
> TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
> Personal Web page: http://homepage.mac.com/chrishuff/
> TAG Web page: http://tag.povray.org/

[Chris Huff] Re: Area Lights... for a florescent light [9375 days 5 hours and 36 minutes ago]

Thu, 3 Aug 2000 18:06:59 GMT

In article <39896fcd$1@news.povray.org>, "Alan Nickerson" 
<ani### [at] mathsoftcom> wrote:

> Thanks, I didnt try a high-ambient for the object.
> I did create a "tube' that glows using an emission media.

Emission media won't emit light(it doesn't illuminate surrounding 
objects), and radiosity in the official version won't see it. If you are 
using MegaPOV, the radiosity should work fine with media.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

[Alan Nickerson] Re: Area Lights... for a florescent light [9375 days 10 hours and 30 minutes ago]

Thu, 3 Aug 2000 13:12:45 GMT

Thanks, I didnt try a high-ambient for the object.
I did create a "tube' that glows using an emission media.

I'll try the high amiant.

thanks
Alan

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-FFF266.23164002082000@news.povray.org...
> In article <3988a133$1@news.povray.org>, "Alan Nickerson"
> <ani### [at] iversoftcom> wrote:
>
> > I cannot seem to get an Area light to actually emit light as if it was a
> > single row of lights, to simulate a florescent light tube.
>
> The area light feature only affects shadows...for other lighting
> calculations, they are ordinary point lights.
> There are two other ways to do what you want: a string of many point
> lights(slow and memory consuming), or a true area light made by using a
> high-ambient object and turning radiosity on(also slow and memory
> consuming, but can often be better than the other option).
>
> --
> Christopher James Huff - Personal e-mail: chr### [at] maccom
> TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
> Personal Web page: http://homepage.mac.com/chrishuff/
> TAG Web page: http://tag.povray.org/

[Chris Huff] Re: Area Lights... for a florescent light [9375 days 19 hours and 27 minutes ago]

Thu, 3 Aug 2000 04:15:46 GMT

In article <3988a133$1@news.povray.org>, "Alan Nickerson" 
<ani### [at] iversoftcom> wrote:

> I cannot seem to get an Area light to actually emit light as if it was a
> single row of lights, to simulate a florescent light tube.

The area light feature only affects shadows...for other lighting 
calculations, they are ordinary point lights.
There are two other ways to do what you want: a string of many point 
lights(slow and memory consuming), or a true area light made by using a 
high-ambient object and turning radiosity on(also slow and memory 
consuming, but can often be better than the other option).

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

[Bob Hughes] Re: Area Lights... for a florescent light [9375 days 19 hours and 40 minutes ago]

Thu, 3 Aug 2000 04:03:01 GMT

"Alan Nickerson" <ani### [at] iversoftcom> wrote in message
news:3988a133$1@news.povray.org...
| I cannot seem to get an Area light to actually emit light as if it was a
| single row of lights, to simulate a florescent light tube.

To phrase it shortly, they don't do that.  'area_light' is still a point
source when it comes to highlights, etc.  They're simply for shadow
smoothing.
To get the bulb to look right you'll need to use 'media', an emitting one at
that, or simply a high ambient in the bulbs finish statement of a cylinder
object.  Then use it as a 'looks_like' for the area light (you'll still need
the softer shadows).

Bob

[Alan Nickerson] Area Lights... for a florescent light [9376 days 1 hour and 12 minutes ago]

Wed, 2 Aug 2000 22:31:15 GMT

I cannot seem to get an Area light to actually emit light as if it was a
single row of lights, to simulate a florescent light tube.

Alan

[TigerHawk] Re: sPatch & HammaPatch [9391 days 6 hours and 45 minutes ago]

Tue, 18 Jul 2000 16:57:26 GMT

> oh that!?  that's all you wanted to know!?!?  i guess our answers had
> you pretty stumped for a while then.

Hehaehae, yes a bit :) There are things about sPatch that still do stump be, but
that fact that you can do what I thought you couldn't helps alot :) I suppose it
was more my fault because I really had not messed with it enough, but the
tutorials are rather complex and I really just wanted the basics. Oh well :)

Thanks for the help anyways, hehehe (the model is pretty cool, by the way)

Tim Soderstrom
PsiTron / TigerHawk

[ryan constantine] Re: sPatch & HammaPatch [9391 days 15 hours and 2 minutes ago]

Tue, 18 Jul 2000 08:40:56 GMT

oh that!?  that's all you wanted to know!?!?  i guess our answers had
you pretty stumped for a while then.

TigerHawk wrote:
> 
> I found out what I was looking for and I thought I might share it with the
> rest of you:
> 
> My problem was that I simply couldn't add points to an already created
> spline - well, I finally figured out how to do it. It's actually quite
> simple - put the mouse at or near one of the points in your spline, then
> just hit 'A' and you'll get a new point on the spline!
> 
> That makes things oh so much easier and I just wanted to share that tidbit
> (though you probably already knew that ;)
> 
> Tim Soderstrom
> PsiTron / Tigerhawk

[TigerHawk] Re: sPatch & HammaPatch [9391 days 21 hours and 20 minutes ago]

Tue, 18 Jul 2000 02:22:43 GMT

I found out what I was looking for and I thought I might share it with the
rest of you:

My problem was that I simply couldn't add points to an already created
spline - well, I finally figured out how to do it. It's actually quite
simple - put the mouse at or near one of the points in your spline, then
just hit 'A' and you'll get a new point on the spline!

That makes things oh so much easier and I just wanted to share that tidbit
(though you probably already knew that ;)

Tim Soderstrom
PsiTron / Tigerhawk

[TigerHawk] Re: (Off topic) General modelling programs? [9395 days 1 hour and 45 minutes ago]

Fri, 14 Jul 2000 21:57:37 GMT

Heahe, will do!

Happy Tracing!
Tim Soderstrom
PsiTron / TigerHawk

"C.J." wrote:

> No Prob. Let us know how it goes.
>
> C.J. POV User
> www.crosswinds.net/~povstudy

[C J ] Re: (Off topic) General modelling programs? [9395 days 9 hours and 47 minutes ago]

Fri, 14 Jul 2000 13:55:58 GMT

> Blender is going to be Opensource. The will throw away the key system
> with.
> Here in Germany you can buy books that have tutorials on Blender. I
> don't know how the compare to the original ones in pricing and content.
> Marc Schimmler

As of version 1.8 Blender no longer has the C-Key, all features are enabled.
Also version 2.0 is due out in a week or so.


C.J. POV User

[C J ] Re: (Off topic) General modelling programs? [9395 days 9 hours and 49 minutes ago]

Fri, 14 Jul 2000 13:53:35 GMT

No Prob. Let us know how it goes.

C.J. POV User
www.crosswinds.net/~povstudy

[Marc Schimmler] Re: (Off topic) General modelling programs? [9395 days 17 hours and 3 minutes ago]

Fri, 14 Jul 2000 06:40:09 GMT

Ken wrote:
> 
> "Greg M. Johnson" wrote:
> >
> > Is blender really free?
> 
> I believe everything but the manual which they charge for. A lot
> of people complain about the GUI interface being a bit unorthodox
> which requires a long learning curve. Some of the stuff I have
> seen come out if though is pretty impressive.
> 

Information from Linuxtag:

Blender is going to be Opensource. The will throw away the key system
with.
Here in Germany you can buy books that have tutorials on Blender. I
don't know how the compare to the original ones in pricing and content.

Marc

-- 
Marc Schimmler

[TigerHawk] Re: (Off topic) General modelling programs? [9395 days 18 hours and 56 minutes ago]

Fri, 14 Jul 2000 04:46:26 GMT

> You may also want to try 4d Builder, http://www.bitlive.com/
> I have not tried it myself, but they say its good for fast proto-typing of
> 3d games.

Cool, thanks - I'll be sure to check that out (screenshots look pretty nice, I
must say)

Tim Soderstrom
PsiTron / TigerHawk

[C J ] Re: (Off topic) General modelling programs? [9396 days 5 hours and 45 minutes ago]

Thu, 13 Jul 2000 17:57:59 GMT

You may also want to try 4d Builder, http://www.bitlive.com/
I have not tried it myself, but they say its good for fast proto-typing of
3d games.

C.J. POV User
www.crosswinds.net/~povstudy




TigerHawk <tig### [at] sticnet> wrote in message
news:396DE642.D1781201@stic.net...
> Thanks, I'll check them our for sure. To answer your question, the problem
with
> Pov-Ray is that without the actual program, it's nothing more than a
script-like
> file sitting on my HD :) I was looking for something that was easily
useable for
> on-the-fly animations (ie game style, or better put demo style) without
having to
> code a bunch of stuff (though now our coder is thikning of making his own
type of
> modeller, so he's going to be doing a crap load of work anyway, heh :P ).
>
> Thanks for the sites though, I'll be sure to check them out!
>
> Tim Soderstrom
> TigerHawk
>
> Alan wrote:
>
> > TigerHawk <tig### [at] sticnet> wrote in message
> > news:396CF0C9.5556CB42@stic.net...
> > | First, done misunderstand me - Pov-Ray is wonderful and amazing (as is
> > | Moray, btw). But for a current project I am undertaking, I need
> > | something that is more general - for on the fly based rendering so I
> > | need a general format for objects (not scenes, but actual objects).
I've
> > | been hunting around the povray links page and have yet to find
something
> > | that might work for me (aside from sPatch, but I also need more
precise
> > | inorganic objects that can be done in sPatch, but not easily :) so I
was
> > | hoping someone could direct me somewhere to a freeware, or better but,
> > | no cost modeller that can output in more standard file formats (even a
> > | RAW would work :)
> >
> > Have you seen Blender?
> > http://www.blender.nl/
> >
> > Here's a page with a big list of mesh generation software:
> >
http://www-users.informatik.rwth-aachen.de/~roberts/software.html#public_dom
ain
> >
> > I wouldn't worry too much about file formats as you could always convert
them
> > later using, for instance, 3DWin:
> > http://www.stmuc.com/thbaier/
> >
> > If it's non-organic objects you're after, why not use CSG modeling
within
> > POV-Ray itself?
> >
> > Bye.
>

[Greg M Johnson] Re: (Off topic) General modelling programs? [9396 days 6 hours and 22 minutes ago]

Thu, 13 Jul 2000 17:20:32 GMT

Yes, this was my memory. I found the key system so annoying as to be a waste of
time.  Charge me $100 and give me the whole ball or forget it.

Alan wrote:

> Blender recently switched from a 'C-Key' system - whereby features became
> available in the free version some time after they appeared in the 'commercial'
> version - to really free, as in absolutely.  The latest version is v1.8, but
> the all-new v2 is due out soon (they drummed up interest as SIGGRAPH) and this
> will feature all sorts of bits and doings.
>
> I actually haven't used Blender much.  Without documentation easily to hand
> (e.g. POV's excellent help file) it's slightly awkward to learn - for me
> anyway.  But, as Ken has said in this thread, it *is* capable of producing some
> excellent results.  As with anything, it just takes time.
>
> Now, back to my robot...
>
> Bye.
>
> Greg M. Johnson <gre### [at] my-dejanewscom> wrote in message
> news:396DCE60.14839D61@my-dejanews.com...
> | Is blender really free?
> |

[TigerHawk] Re: (Off topic) General modelling programs? [9396 days 6 hours and 49 minutes ago]

Thu, 13 Jul 2000 16:54:11 GMT

> I actually haven't used Blender much.  Without documentation easily to hand
> (e.g. POV's excellent help file) it's slightly awkward to learn - for me
> anyway.  But, as Ken has said in this thread, it *is* capable of producing some
> excellent results.  As with anything, it just takes time.

Blender seems to have great features, but, yes the documentation is weird, and I
don't like the unsizeable window (on my old monitor I could hardly run it). I'm
sure you could make great things with it, I am just saying that I haven't seen
anything great, least not as great as the Pov-Ray IRTC entries (though I think a
few might have actually used Blender....hmmm)

Happy Tracing,
Tim Soderstrom

[Ken] Re: (Off topic) General modelling programs? [9396 days 7 hours and 5 minutes ago]

Thu, 13 Jul 2000 16:38:15 GMT

TigerHawk wrote:
> 
> > I believe everything but the manual which they charge for. A lot
> > of people complain about the GUI interface being a bit unorthodox
> > which requires a long learning curve. Some of the stuff I have
> > seen come out if though is pretty impressive.
> 
> Really? I haven't seem very much in the world of scenes (object maybe) -
> I've seen some neat things, but not on the degree of Pov-Ray - have an eye
> candyish sites I can look at? :) (Though I swear by Pov when it comes to
> raytracing.

I don't maintain blender URLs in my links data base for obvious
reasons - it doesn't interest me.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Alan] Re: (Off topic) General modelling programs? [9396 days 7 hours and 10 minutes ago]

Thu, 13 Jul 2000 16:32:50 GMT

Blender recently switched from a 'C-Key' system - whereby features became
available in the free version some time after they appeared in the 'commercial'
version - to really free, as in absolutely.  The latest version is v1.8, but
the all-new v2 is due out soon (they drummed up interest as SIGGRAPH) and this
will feature all sorts of bits and doings.

I actually haven't used Blender much.  Without documentation easily to hand
(e.g. POV's excellent help file) it's slightly awkward to learn - for me
anyway.  But, as Ken has said in this thread, it *is* capable of producing some
excellent results.  As with anything, it just takes time.

Now, back to my robot...

Bye.

Greg M. Johnson <gre### [at] my-dejanewscom> wrote in message
news:396DCE60.14839D61@my-dejanews.com...
| Is blender really free?
|

[TigerHawk] Re: (Off topic) General modelling programs? [9396 days 7 hours and 44 minutes ago]

Thu, 13 Jul 2000 15:58:32 GMT

> I believe everything but the manual which they charge for. A lot
> of people complain about the GUI interface being a bit unorthodox
> which requires a long learning curve. Some of the stuff I have
> seen come out if though is pretty impressive.

Really? I haven't seem very much in the world of scenes (object maybe) -
I've seen some neat things, but not on the degree of Pov-Ray - have an eye
candyish sites I can look at? :) (Though I swear by Pov when it comes to
raytracing.

Tim Soderstrom
TigerHawk

[TigerHawk] Re: (Off topic) General modelling programs? [9396 days 7 hours and 46 minutes ago]

Thu, 13 Jul 2000 15:56:57 GMT

Thanks, I'll check them our for sure. To answer your question, the problem with
Pov-Ray is that without the actual program, it's nothing more than a script-like
file sitting on my HD :) I was looking for something that was easily useable for
on-the-fly animations (ie game style, or better put demo style) without having to
code a bunch of stuff (though now our coder is thikning of making his own type of
modeller, so he's going to be doing a crap load of work anyway, heh :P ).

Thanks for the sites though, I'll be sure to check them out!

Tim Soderstrom
TigerHawk

Alan wrote:

> TigerHawk <tig### [at] sticnet> wrote in message
> news:396CF0C9.5556CB42@stic.net...
> | First, done misunderstand me - Pov-Ray is wonderful and amazing (as is
> | Moray, btw). But for a current project I am undertaking, I need
> | something that is more general - for on the fly based rendering so I
> | need a general format for objects (not scenes, but actual objects). I've
> | been hunting around the povray links page and have yet to find something
> | that might work for me (aside from sPatch, but I also need more precise
> | inorganic objects that can be done in sPatch, but not easily :) so I was
> | hoping someone could direct me somewhere to a freeware, or better but,
> | no cost modeller that can output in more standard file formats (even a
> | RAW would work :)
>
> Have you seen Blender?
> http://www.blender.nl/
>
> Here's a page with a big list of mesh generation software:
> http://www-users.informatik.rwth-aachen.de/~roberts/software.html#public_domain
>
> I wouldn't worry too much about file formats as you could always convert them
> later using, for instance, 3DWin:
> http://www.stmuc.com/thbaier/
>
> If it's non-organic objects you're after, why not use CSG modeling within
> POV-Ray itself?
>
> Bye.

[Ken] Re: (Off topic) General modelling programs? [9396 days 9 hours and 20 minutes ago]

Thu, 13 Jul 2000 14:23:05 GMT

"Greg M. Johnson" wrote:
> 
> Is blender really free?

I believe everything but the manual which they charge for. A lot
of people complain about the GUI interface being a bit unorthodox
which requires a long learning curve. Some of the stuff I have
seen come out if though is pretty impressive.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Greg M Johnson] Re: (Off topic) General modelling programs? [9396 days 9 hours and 25 minutes ago]

Thu, 13 Jul 2000 14:17:38 GMT

Is blender really free?

Alan wrote:

> Have you seen Blender?
> http://www.blender.nl/
>
> Here's a page with a big list of mesh generation software:
> http://www-users.informatik.rwth-aachen.de/~roberts/software.html#public_domain
>
> I wouldn't worry too much about file formats as you could always convert them
> later using, for instance, 3DWin:
> http://www.stmuc.com/thbaier/
>
> If it's non-organic objects you're after, why not use CSG modeling within
> POV-Ray itself?
>
> Bye.

[Alan] Re: (Off topic) General modelling programs? [9396 days 17 hours and 7 minutes ago]

Thu, 13 Jul 2000 06:36:16 GMT

TigerHawk <tig### [at] sticnet> wrote in message
news:396CF0C9.5556CB42@stic.net...
| First, done misunderstand me - Pov-Ray is wonderful and amazing (as is
| Moray, btw). But for a current project I am undertaking, I need
| something that is more general - for on the fly based rendering so I
| need a general format for objects (not scenes, but actual objects). I've
| been hunting around the povray links page and have yet to find something
| that might work for me (aside from sPatch, but I also need more precise
| inorganic objects that can be done in sPatch, but not easily :) so I was
| hoping someone could direct me somewhere to a freeware, or better but,
| no cost modeller that can output in more standard file formats (even a
| RAW would work :)

Have you seen Blender?
http://www.blender.nl/

Here's a page with a big list of mesh generation software:
http://www-users.informatik.rwth-aachen.de/~roberts/software.html#public_domain

I wouldn't worry too much about file formats as you could always convert them
later using, for instance, 3DWin:
http://www.stmuc.com/thbaier/

If it's non-organic objects you're after, why not use CSG modeling within
POV-Ray itself?

Bye.

[TigerHawk] (Off topic) General modelling programs? [9397 days 1 hour and 13 minutes ago]

Wed, 12 Jul 2000 22:29:37 GMT

First, done misunderstand me - Pov-Ray is wonderful and amazing (as is
Moray, btw). But for a current project I am undertaking, I need
something that is more general - for on the fly based rendering so I
need a general format for objects (not scenes, but actual objects). I've
been hunting around the povray links page and have yet to find something
that might work for me (aside from sPatch, but I also need more precise
inorganic objects that can be done in sPatch, but not easily :) so I was
hoping someone could direct me somewhere to a freeware, or better but,
no cost modeller that can output in more standard file formats (even a
RAW would work :)

Thanks!

Tim Soderstorm
TigerHawk

[TigerHawk] Re: sPatch & HammaPatch [9397 days 1 hour and 21 minutes ago]

Wed, 12 Jul 2000 22:21:46 GMT

Oh, you mean add it on to the END of the cylinder? Not the middle? Yeah, that
makes sense. But what about for more complex objects like heads?

<shrug>

Tim Soderstrom


Peter Cracknell wrote:

> OK I am good at making a big ununderstandable waffle, I'll briefly explain.
> The original model is of 8 points, consisting of two circles of four points
> connected symmetrically by lengths making a cylinder.  The aim is to add 4
> more ponits, a new circle in the middle.  One way would be to using the add
> tool (shortcut A) a four new nodes along the lengths of the cylinder making
> 4 nodes with two lengths each side:
>

[pk] Re: Does anyone just use Povray? [9397 days 2 hours and 11 minutes ago]

Wed, 12 Jul 2000 21:32:11 GMT

Bob Hughes wrote:
> 
> "Phil Clute" <pcl### [at] tiacnet> wrote in message
> news:394C3B7D.75ACE6E0@tiac.net...
> |  I sometimes use sPatch or Leveller for things that would be
> | time consuming to do without a modeller, but whenever I decide to use
> | one I feel like "Ugh, I have to argue with a dumb modeller again...".
> | Whenever I use a modeller I have to chase objects all over the place,
> | "a little to the left, no not that way! Oh I'm moving the wrong screen
> | again...I didn't mean to do that! UNDO!"
> | With code it's
> | sphere{<1,3.5,2>,0.5
> |        pigment{Blue}
> | }
> | ...Done.
> 
> A perfect description.  I could not have put it a better way.
Well... that's why i mostly use moray for doing the model itself, and
the scene, usually, but you know, there are fields for translation,
rotation and scaling in Moray's gui.
And, uh for scripting&weird effects in pov(or mostly megapov), that's
definitely hand code 8)
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...

[GWJ] Re: Tornado help [9397 days 2 hours and 48 minutes ago]

Wed, 12 Jul 2000 20:54:53 GMT

Thanks for the advice. I checked out the tornado.pov and have some ideas. If
I come up with anything I'll post. Greg.


"Bob Hughes" <per### [at] aolcom?subject=PoV-News:> wrote in message
news:396bf8a3@news.povray.org...
> "Ken" <tyl### [at] pacbellnet> wrote in message
> news:396BF4FA.B78EF1D8@pacbell.net...
> |
> | I cheated by using a bozo pattern with phase applied and kept the
> | distance to the camera far enough away that you couldn't see any
> | details.
>
> Well, oddly enough, the media I tried to do it with kept looking like it
was
> fitted to a surface instead of being filled into the 3D shape.
> I just happened to think, I used 'sphere_sweep' in MegaPov after that
other
> pov script I made, it does a good elephants trunk kind of funnel.  Not
sure if
> I also posted that there or not.  If you need to ask anything more just
speak
> up Greg.
>
> Bob
>
>
>

[ryan constantine] Re: sPatch & HammaPatch [9397 days 2 hours and 58 minutes ago]

Wed, 12 Jul 2000 20:44:31 GMT

i just emailed you.

TigerHawk wrote:
> 
> > There are two ways I have experimented with to achieve this, though
> > obviously not as fast or easy as they could be.  THe first is simply to move
> > one of the points towards the middle and extrude downwards - this does not
> > work if you already have a large cylinder though.  The second you many not
> > be aware of is creating another circle, placing it in the middle and
> > attaching all the nodes the joining lines.  It does mean you have to
> > manually re create the piece in the centre and right click all the nodes in,
> > but it does work.  Maybe a good suggestion would be a function whereby the
> > number of extrusions can be multiplied by a factor, to complicate/more
> > populate the mesh without manually doing it.  Well I hope thats not too much
> > of a mess.
> 
> Hmm...what I don't understand is how one can add the circle to the others? If
> you have 2 circles joined together:
> 
> ------      <-circle
> |      |       <-joining points
> |      |
> ------      <- circle
> 
> How can you fuse the third on?  Because there is already a nicely created series
> of patches. That's what I am having trouble with, adding things like that to go
> from simplistic to complex. I'm 'kinda' following both of you, but not really :)
> (ryan: I wouldn't mind seeing your spatch portion of your model if that okay).
> Anyways, I hope HamaPatch solves some of these problems (though right now, and
> no offense to the author, I prefer sPatch because it doesn't crash and I can
> change the grid colors :)
> 
> Happy tracing,
> 
> Tim Soderstrom
> TigerHawk

[Peter Cracknell] Re: sPatch & HammaPatch [9397 days 6 hours and 27 minutes ago]

Wed, 12 Jul 2000 17:15:39 GMT

OK I am good at making a big ununderstandable waffle, I'll briefly explain.
The original model is of 8 points, consisting of two circles of four points
connected symmetrically by lengths making a cylinder.  The aim is to add 4
more ponits, a new circle in the middle.  One way would be to using the add
tool (shortcut A) a four new nodes along the lengths of the cylinder making
4 nodes with two lengths each side:

-----
|  |  |
|  |  |
-----

TO:

-----
|  |  |
* * *
|  |  |
-----

Where the *'s are new nodes.  Simply then just join these nodes up
horizontally (after creating them vertically).  Thats the best I can do to
explain it.

Peter Cracknell

www.petecracknell.co.uk


TigerHawk <tig### [at] sticnet> wrote in message
news:396CA29C.64EC9553@stic.net...
> > There are two ways I have experimented with to achieve this, though
> > obviously not as fast or easy as they could be.  THe first is simply to
move
> > one of the points towards the middle and extrude downwards - this does
not
> > work if you already have a large cylinder though.  The second you many
not
> > be aware of is creating another circle, placing it in the middle and
> > attaching all the nodes the joining lines.  It does mean you have to
> > manually re create the piece in the centre and right click all the nodes
in,
> > but it does work.  Maybe a good suggestion would be a function whereby
the
> > number of extrusions can be multiplied by a factor, to complicate/more
> > populate the mesh without manually doing it.  Well I hope thats not too
much
> > of a mess.
>
> Hmm...what I don't understand is how one can add the circle to the others?
If
> you have 2 circles joined together:
>
> ------      <-circle
> |      |       <-joining points
> |      |
> ------      <- circle
>
> How can you fuse the third on?  Because there is already a nicely created
series
> of patches. That's what I am having trouble with, adding things like that
to go
> from simplistic to complex. I'm 'kinda' following both of you, but not
really :)
> (ryan: I wouldn't mind seeing your spatch portion of your model if that
okay).
> Anyways, I hope HamaPatch solves some of these problems (though right now,
and
> no offense to the author, I prefer sPatch because it doesn't crash and I
can
> change the grid colors :)
>
> Happy tracing,
>
> Tim Soderstrom
> TigerHawk
>

[TigerHawk] Re: sPatch & HammaPatch [9397 days 6 hours and 47 minutes ago]

Wed, 12 Jul 2000 16:56:06 GMT

> There are two ways I have experimented with to achieve this, though
> obviously not as fast or easy as they could be.  THe first is simply to move
> one of the points towards the middle and extrude downwards - this does not
> work if you already have a large cylinder though.  The second you many not
> be aware of is creating another circle, placing it in the middle and
> attaching all the nodes the joining lines.  It does mean you have to
> manually re create the piece in the centre and right click all the nodes in,
> but it does work.  Maybe a good suggestion would be a function whereby the
> number of extrusions can be multiplied by a factor, to complicate/more
> populate the mesh without manually doing it.  Well I hope thats not too much
> of a mess.

Hmm...what I don't understand is how one can add the circle to the others? If
you have 2 circles joined together:

------      <-circle
|      |       <-joining points
|      |
------      <- circle

How can you fuse the third on?  Because there is already a nicely created series
of patches. That's what I am having trouble with, adding things like that to go
from simplistic to complex. I'm 'kinda' following both of you, but not really :)
(ryan: I wouldn't mind seeing your spatch portion of your model if that okay).
Anyways, I hope HamaPatch solves some of these problems (though right now, and
no offense to the author, I prefer sPatch because it doesn't crash and I can
change the grid colors :)

Happy tracing,

Tim Soderstrom
TigerHawk

[Philippe Debar] Re: Does anyone just use Povray? [9397 days 10 hours and 53 minutes ago]

Wed, 12 Jul 2000 12:49:26 GMT

"ryan constantine" <rco### [at] yahoocom> wrote in message
news:394D4A98.F4A094E1@yahoo.com...
> by complicated i mean a single model that can't be put together with
> functions, macros, or randomization. trees, grass etc. are complicated,
> but i don't think of them as the same kind of models. to me they are
> more like environmental constructs (which make the surroundings of where
> a model goes). clouds and skies are another example of things that are
> complicated, but don't fit into my personal view of a model. of course,
> anyone that can make any of the above items realistically, has praise
> from me.


I'd rather speak of each person preference and ability to use one tool or
the other. For the same model, you will find people who prefer (for whatever
reason) to use different tools. I believe in an user-tool-model relation
rather then just model-tool.


Also, I do not get the usage / type of model -> type of tool relationship
you are explaining. I understand a type of model (+person) -> tool
relationship. Trees and grass and clouds clearly do present the same kind of
difficulties to model when compared to (for example) a camera and hence a
similarity of tools / techniques. But I do not believe it is because these
objects are or aren't the focus of a scene.


Povingly,


Philippe

[Peter Cracknell] Re: sPatch & HammaPatch [9397 days 12 hours and 42 minutes ago]

Wed, 12 Jul 2000 11:01:11 GMT

I see what you mean and I think it would be good to *ask* for it - not that
I think the SPatch creator is about.  Would be what you mean where for
example you create a cylinder - two joint circles and then you want another
circle in the middle, making three joint circles - a cylinder that can be
twisted.

ie

------      <-circle
|      |       <-joining points
|      |
------      <- circle

TO

------
|     |
-----
|     |
------

There are two ways I have experimented with to achieve this, though
obviously not as fast or easy as they could be.  THe first is simply to move
one of the points towards the middle and extrude downwards - this does not
work if you already have a large cylinder though.  The second you many not
be aware of is creating another circle, placing it in the middle and
attaching all the nodes the joining lines.  It does mean you have to
manually re create the piece in the centre and right click all the nodes in,
but it does work.  Maybe a good suggestion would be a function whereby the
number of extrusions can be multiplied by a factor, to complicate/more
populate the mesh without manually doing it.  Well I hope thats not too much
of a mess.

Peter Cracknell

www.petecracknell.co.uk

TigerHawk <tig### [at] sticnet> wrote in message
news:396BC9AC.413CF118@stic.net...
> I am haivng trouble trying to figure things out with these type of
> modelers. Here is the problem I am having (or rather what I would like
> to see happen):
>
> The thing the discouraged me from sPatch was that you couldn't fuse
> points onto an already created circle. Since loops are supposed to be of
> 3 OR 4 points, if you had a 3 point loop, adding another point seems
> fine, but it doesn't appear to be possible. The reaosn I need this is
> because I like to start simply and work up to complexity. For example,
> if I were to create say a face, or rather a head, I would start with
> what an artist (well an artist using paper :) would probably do - that
> is make the outline of the head (verticle and horizontal loops). The
> problem is that I can't seem to add lines and loops to those loops. I
> thought HammaPatch might help, but, unforatunately, it seems to be
> pretty much beta right now (it runs SSSLLLOOOWW on my machine :( and is
> unstable)
>
> Any help would be very apreciative. I was hoping to find a program that
> could do organic surfaces not only for Pov-Ray but for other exports as
> well (for use in say a Scene Demo for objects).
>
> Happy Tracing,
>
> Tim Soderstrom
> TigerHawk
>
>

[Bob Hughes] Re: Tornado help [9397 days 18 hours and 54 minutes ago]

Wed, 12 Jul 2000 04:48:35 GMT

"Ken" <tyl### [at] pacbellnet> wrote in message
news:396BF4FA.B78EF1D8@pacbell.net...
|
| I cheated by using a bozo pattern with phase applied and kept the
| distance to the camera far enough away that you couldn't see any
| details.

Well, oddly enough, the media I tried to do it with kept looking like it was
fitted to a surface instead of being filled into the 3D shape.
I just happened to think, I used 'sphere_sweep' in MegaPov after that other
pov script I made, it does a good elephants trunk kind of funnel.  Not sure if
I also posted that there or not.  If you need to ask anything more just speak
up Greg.

Bob

[Ken] Re: Tornado help [9397 days 19 hours and 5 minutes ago]

Wed, 12 Jul 2000 04:37:59 GMT

Bob Hughes wrote:

> Yep, media used of course so it's not easy to adjust.
> There's a "tornado.pov for dust-devils, etc." posted to
> povray.text.scene-files on April 18th of this year.
> Maybe that will help.  Not easy to describe.
> 
> Bob

I cheated by using a bozo pattern with phase applied and kept the
distance to the camera far enough away that you couldn't see any
details.

-- 
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: Tornado help [9397 days 19 hours and 7 minutes ago]

Wed, 12 Jul 2000 04:36:07 GMT

ryan constantine wrote:
> 
> i think bob hughes was working on one a while ago.  he was only lukewarm
> about his results and i think he may have been the only person to ever
> try.  check his pics and animations in the appropriate ng's and his web
> site.

When I was a releatively new user to the program I tried to make an
animated tornado but my results were less than spetacular. I did
manage to get it to suck up a row of trees and tear down a wire
fence line as it passed by :)
 I may revisit this idea some day but I really have nothing to offer
someone else starting out that would prove useful.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Bob Hughes] Re: Tornado help [9397 days 19 hours and 7 minutes ago]

Wed, 12 Jul 2000 04:35:51 GMT

"ryan constantine" <rco### [at] yahoocom> wrote in message
news:396BF3EF.868BAF45@yahoo.com...
| i think bob hughes was working on one a while ago.  he was only lukewarm
| about his results and i think he may have been the only person to ever
| try.  check his pics and animations in the appropriate ng's and his web
| site.

Yep, media used of course so it's not easy to adjust.
There's a "tornado.pov for dust-devils, etc." posted to
povray.text.scene-files on April 18th of this year.
Maybe that will help.  Not easy to describe.

Bob

[ryan constantine] Re: Tornado help [9397 days 19 hours and 13 minutes ago]

Wed, 12 Jul 2000 04:29:54 GMT

i think bob hughes was working on one a while ago.  he was only lukewarm
about his results and i think he may have been the only person to ever
try.  check his pics and animations in the appropriate ng's and his web
site.

GWJ wrote:
> 
> Can anyone give me a quick pointer or two on creating "realistic" tornados?
> TIA, Greg.

[ryan constantine] Re: sPatch & HammaPatch [9397 days 19 hours and 16 minutes ago]

Wed, 12 Jul 2000 04:27:13 GMT

i use spatch and did the fuselage of my xwing model in it.  if you look
at the nose i did, you'll see that i built the cutout into the model. 
for the rear of the fuselage, however, i converted it to a solid mesh
and then did the cutouts with csg.  in my original fuselage, all of the
cutouts were csg, but they created holes.  so in my second version, i
built in as many cutouts as i felt would be prudent.  so let's take the
nosecone as an example.  i already had the thing made, in particular,
the main center sweep and so i had to figure out how to make the
cutout.  first step was deleting the patches in the area to be worked
on.  this actually deleted more than i needed because it left other
patches lacking nodes.  so next i filled in the areas affected by this
and built the sweep back up to the point where there was a hole where
the cutout was supposed to go.  then i added the cutout.  somethimes, i
would have three or four nodes, but no patch would emerge.  when that
would happen, i would just subdivide what i thought the patch should be;
usually just making a straight line run from one side to the other. 
this would usually generate two three point patches and solve the
problem.  i'm sorry this is kind of hard to follow.  if you think it
would help, i could email you my fuselage spatch file.  oh, one last
thing, use layers extensively.  if you need nodes to line up put not
affect each other, that's the best way to do it (two layers).

TigerHawk wrote:
> 
> I am haivng trouble trying to figure things out with these type of
> modelers. Here is the problem I am having (or rather what I would like
> to see happen):
> 
> The thing the discouraged me from sPatch was that you couldn't fuse
> points onto an already created circle. Since loops are supposed to be of
> 3 OR 4 points, if you had a 3 point loop, adding another point seems
> fine, but it doesn't appear to be possible. The reaosn I need this is
> because I like to start simply and work up to complexity. For example,
> if I were to create say a face, or rather a head, I would start with
> what an artist (well an artist using paper :) would probably do - that
> is make the outline of the head (verticle and horizontal loops). The
> problem is that I can't seem to add lines and loops to those loops. I
> thought HammaPatch might help, but, unforatunately, it seems to be
> pretty much beta right now (it runs SSSLLLOOOWW on my machine :( and is
> unstable)
> 
> Any help would be very apreciative. I was hoping to find a program that
> could do organic surfaces not only for Pov-Ray but for other exports as
> well (for use in say a Scene Demo for objects).
> 
> Happy Tracing,
> 
> Tim Soderstrom
> TigerHawk

[TigerHawk] sPatch & HammaPatch [9397 days 22 hours and 12 minutes ago]

Wed, 12 Jul 2000 01:30:30 GMT

I am haivng trouble trying to figure things out with these type of
modelers. Here is the problem I am having (or rather what I would like
to see happen):

The thing the discouraged me from sPatch was that you couldn't fuse
points onto an already created circle. Since loops are supposed to be of
3 OR 4 points, if you had a 3 point loop, adding another point seems
fine, but it doesn't appear to be possible. The reaosn I need this is
because I like to start simply and work up to complexity. For example,
if I were to create say a face, or rather a head, I would start with
what an artist (well an artist using paper :) would probably do - that
is make the outline of the head (verticle and horizontal loops). The
problem is that I can't seem to add lines and loops to those loops. I
thought HammaPatch might help, but, unforatunately, it seems to be
pretty much beta right now (it runs SSSLLLOOOWW on my machine :( and is
unstable)

Any help would be very apreciative. I was hoping to find a program that
could do organic surfaces not only for Pov-Ray but for other exports as
well (for use in say a Scene Demo for objects).

Happy Tracing,

Tim Soderstrom
TigerHawk

[TigerHawk] Re: Does anyone just use Povray? [9398 days and 9 minutes ago]

Tue, 11 Jul 2000 23:34:16 GMT

I kinda disagree here, or at least leave it to preference. I have seen some amazing
IRTC stuff that was done 'by hand', or so they say. I personally am into Moray at
the moment, for that very reason, but I think complicated objects are entirely
possible by hand. I just don't have that much patience :)

Tim Soderstrom
TigerHawk

ryan constantine wrote:

> by complicated i mean a single model that can't be put together with
> functions, macros, or randomization.  trees, grass etc. are complicated,
> but i don't think of them as the same kind of models.  to me they are
> more like environmental constructs (which make the surroundings of where
> a model goes).  clouds and skies are another example of things that are
> complicated, but don't fit into my personal view of a model.  of course,
> anyone that can make any of the above items realistically, has praise
> from me.
>

[GWJ] Tornado help [9398 days 3 hours and 59 minutes ago]

Tue, 11 Jul 2000 19:44:06 GMT

Can anyone give me a quick pointer or two on creating "realistic" tornados?
TIA, Greg.

[Ian Witham] Re: Does anyone know a "look at" formula? [9402 days 16 hours and 53 minutes ago]

Fri, 7 Jul 2000 06:50:13 GMT

Thanks Chris!

--

Ian

Inkwell: Ian's Homepage
http://www.topcities.com/cartoon/inkwell/index.htm
Chris Huff <chr### [at] maccom> wrote in message
news:chrishuff-6B4CF8.10544904072000@news.povray.org...
> In article <3961f398@news.povray.org>, "Ian Witham"
> <ian### [at] hotmailcom> wrote:
>
> > If I have an object centred on the origin which I say is "looking"
> > straight down the +z axis for instance, what is a formula to rotate
> > this object so that it is "looking" at another given vector?
> >
> > I hope to use this formula to have each object on a 3d spline facing the
> > next, if you see what I'm getting at.
>
> Try the Reorient() macro:
> http://www.erols.com/vansickl/macs.htm
>
> --
> Christopher James Huff - Personal e-mail: chr### [at] maccom
> TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
> Personal Web page: http://homepage.mac.com/chrishuff/
> TAG Web page: http://tag.povray.org/

[Chris Huff] Re: Does anyone know a "look at" formula? [9405 days 7 hours and 48 minutes ago]

Tue, 4 Jul 2000 15:54:38 GMT

In article <3961f398@news.povray.org>, "Ian Witham" 
<ian### [at] hotmailcom> wrote:

> If I have an object centred on the origin which I say is "looking" 
> straight down the +z axis for instance, what is a formula to rotate 
> this object so that it is "looking" at another given vector?
> 
> I hope to use this formula to have each object on a 3d spline facing the
> next, if you see what I'm getting at.

Try the Reorient() macro:
http://www.erols.com/vansickl/macs.htm

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

[Ian Witham] Does anyone know a "look at" formula? [9405 days 9 hours and 18 minutes ago]

Tue, 4 Jul 2000 14:24:24 GMT

If I have an object centred on the origin which I say is "looking" straight
down the +z axis for instance, what is a formula to rotate this object so
that it is "looking" at another given vector?

I hope to use this formula to have each object on a 3d spline facing the
next, if you see what I'm getting at.

--

Ian

Inkwell: Ian's Homepage
http://www.topcities.com/cartoon/inkwell/index.htm

[Bob Hughes] Re: Making a sun [9408 days 1 hour and 32 minutes ago]

Sat, 1 Jul 2000 22:10:50 GMT

I left out the actual 'light_source', which would just go at a infinite enough
distance, say around 999999*z and then also rotate same as the wood pattern
(Sun).

[Bob Hughes] Re: Making a sun [9408 days 1 hour and 50 minutes ago]

Sat, 1 Jul 2000 21:52:28 GMT

"Zilvah" <zil### [at] onlineno> wrote in message
news:395e44ae$1@news.povray.org...
|
| Making a glowing spot on a sky_sphere

Hmm, now that presents a problem about diffusing light if it goes with a light
as well, since sky_sphere is all ambient and no diffuse it's pretty useless
for spreading the light onto it.  So you have to go with pigment pattern only
(well, a light can still be used) which is simply something like:

camera {location -5*z
        look_at 0
}

plane {y,-1.01 pigment {rgb 1}}

sky_sphere {

pigment {wood color_map { // sun sky
 [0.05 color rgb <1,1,.95>*1.5] // this index is size of sun
 [0.055 color rgb <1,1,.9>*1.25] // this one starts the fade out edge of sun
 [0.15 color rgb <.8,.9,1>]
 [0.25 color rgb <.6,.7,.9>]
 [1.00 color rgb <.3,.6,.9>]
} rotate <-15,5,0>} // places sun (raise or lower x for altitude, y for
left/right)
pigment {gradient y color_map { // horizon sky
 [0.05 color rgbf <.8,.6,.7,.1>] // this index is size of sun
 [0.15 color rgbf <.5,.7,1,.33>]
 [0.25 color rgbf <.6,.7,.9,.5>]
 [1.00 color rgbf <.3,.6,.9,1>]
} }

}

You will obviously want to change colors to your liking for the situation
needed.  Hope that's what you were looking to do.

Bob

[Zilvah] SV: Making a sun [9408 days 4 hours and 22 minutes ago]

Sat, 1 Jul 2000 19:21:18 GMT

Bob Hughes <per### [at] aolcom?subject=PoV-News:> skrev i
meldingsnyheter:395dfa0b@news.povray.org...
> There are several ways I'd say.  Kind of depends on what kind of Sun.  A
> simple ambient disc or just colored spot on the inside of a sphere or
> sky_sphere.  A sphere itself with media properties or just textured
surface.
> Lots of ways.
> The spot on inside of a sky sphere would be done using a wood pattern
color
> map then rotated into place with perhaps a gradient y pattern layered over
or
> under that (filter used in the upper layer).
> A media Sun would be best for outer space scenes probably.
> What is the intended use?
>
> Bob
>
> "Zilvah" <zil### [at] onlineno> wrote in message
news:395defd3@news.povray.org...
> | Anyone knows how to make a sun in POV-Ray?
>
>
>

Making a glowing spot on a sky_sphere

[Bob Hughes] Re: Making a sun [9408 days 9 hours and 40 minutes ago]

Sat, 1 Jul 2000 14:02:51 GMT

There are several ways I'd say.  Kind of depends on what kind of Sun.  A
simple ambient disc or just colored spot on the inside of a sphere or
sky_sphere.  A sphere itself with media properties or just textured surface.
Lots of ways.
The spot on inside of a sky sphere would be done using a wood pattern color
map then rotated into place with perhaps a gradient y pattern layered over or
under that (filter used in the upper layer).
A media Sun would be best for outer space scenes probably.
What is the intended use?

Bob

"Zilvah" <zil### [at] onlineno> wrote in message news:395defd3@news.povray.org...
| Anyone knows how to make a sun in POV-Ray?

[Bob Hughes] Re: Does anyone just use Povray? [9408 days 9 hours and 48 minutes ago]

Sat, 1 Jul 2000 13:55:01 GMT

"Zilvah" <zil### [at] onlineno> wrote in message
news:395dedbd$1@news.povray.org...
|
| P.S. Anyone knows where I can find PolyRay? Their homepage is a 404...

This should get you there since I just checked it:
http://pages.infinit.net/gollum/polyray/poly1.htm

Bob

[Zilvah] Making a sun [9408 days 10 hours and 24 minutes ago]

Sat, 1 Jul 2000 13:19:15 GMT

Anyone knows how to make a sun in POV-Ray?
Zilvah

[Zilvah] SV: Does anyone just use Povray? [9408 days 10 hours and 32 minutes ago]

Sat, 1 Jul 2000 13:10:21 GMT

Bob Hughes <per### [at] aolcom?subject=PoV-News:> skrev i
meldingsnyheter:395d37b9@news.povray.org...
> "Aaron Gillies" <aar### [at] mindspringcom> wrote in message
> news:395d1abb@news.povray.org...
> | The only thing that no one has mentioned is the great feeling you get
when
> | you see a bunch of ASCII code that you typed into an editor transformed
into
> | a 3-D scene by POV-Ray.
>
> So true.  And showing such files to people that have no knowledge of such
> things can almost be as much fun.
> I've seen, and done, a few renders using syntax (script, whatever) as text
> objects.  Makes for a sort of mind behind the face of POV-Ray.
>
> Bob
>
>
>

I've tried out a lot of 3D Editors that use script like POV-Ray, but none of
those has been so easy to use as POV-Ray has... When I first got POV-Ray, I
really liked it, and wondered if there were other programs that used
script... I've stumbled across a few, the latest one being a program that
used Python... The results were really good, but it took forever to learn
and to use the "language"...
I'd say POV-Ray is the best...

Zilvah

P.S. Anyone knows where I can find PolyRay? Their homepage is a 404...

[Bob Hughes] Re: Does anyone just use Povray? [9408 days 23 hours and 29 minutes ago]

Sat, 1 Jul 2000 00:13:45 GMT

"Aaron Gillies" <aar### [at] mindspringcom> wrote in message
news:395d1abb@news.povray.org...
| The only thing that no one has mentioned is the great feeling you get when
| you see a bunch of ASCII code that you typed into an editor transformed into
| a 3-D scene by POV-Ray.

So true.  And showing such files to people that have no knowledge of such
things can almost be as much fun.
I've seen, and done, a few renders using syntax (script, whatever) as text
objects.  Makes for a sort of mind behind the face of POV-Ray.

Bob

[Aaron Gillies] Re: Does anyone just use Povray? [9409 days 1 hour and 33 minutes ago]

Fri, 30 Jun 2000 22:10:03 GMT

The only thing that no one has mentioned is the great feeling you get when
you see a bunch of ASCII code that you typed into an editor transformed into
a 3-D scene by POV-Ray.

Aaron

"Phead" <sco### [at] d0gznetnospam> wrote in message
news:394b9bea$1@news.povray.org...
> Hey, Im using Moray, and Ive noticed alot of talk about Pov code. Does
> anyone just use Povray for modelling? Isn't that pretty hard to visualize?
>
>

[Steven Jones] Re: Does anyone just use Povray? [9417 days 2 hours and 31 minutes ago]

Thu, 22 Jun 2000 21:11:29 GMT

Point taken.  I use Rhino for stuff like that.

[Warp] Re: Does anyone just use Povray? [9417 days 11 hours and 40 minutes ago]

Thu, 22 Jun 2000 12:02:46 GMT

Steven Jones <ste### [at] tsncc> wrote:
: I couldn't agree more Ken!  Moray generates Pov code so everything you can
: do in Moray can be done in Pov code alone.

  Only in theory.
  I would like to see you making a complicated model of a human head made with
bicubic patches by hand.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Josh English] Re: Trigonometry [9418 days and 10 minutes ago]

Wed, 21 Jun 2000 23:32:37 GMT

Given any triangle with vertices A,B, and C, and their opposing sides, a,b,and
c, the Law of Sines states: (The Points and their angles are refered to by the
same capital letters, the lengths of the sides are in lower case)
(sin A)/a = (sin B)/b = (sin C)/c.
The Law of cosines states:

a^2 = b^2 + c^2 -2bc cos A
b^2 = a^2 + c^2 -2ac cos B
c^2 = a^2 + b^2 -2ab cos C.

in POV-Ray terms, cos A can be found with vdot(B-A,C-A)/a,c. (In the vdot, use
the position vectors, not the angles at those points. Maybe I should have been
clearer.)

Josh

Jerry wrote:

> In article <394D6897.E18734FB@global2000.net>, Andrea Ryan
> <ary### [at] global2000net> wrote:
>
> >How about putting information about the law of sines and the law of cosines
> >on the page?  They will work with any triangle, not just right triangles.
> >The law of cosines is really just the Pythagorean theorem with a correction
> >factor.
>
> Because I don't remember anything about them whatsoever? :*)
>
> If you can explain them to me, and I find them useful, I will be happy
> to add a second chapter to my page.
>
> Jerry

--
Josh English
eng### [at] spiritonecom
"May your hopes, dreams, and plans not be destroyed by a few zeros."

[Steven Jones] Re: Does anyone just use Povray? [9418 days 2 hours and 15 minutes ago]

Wed, 21 Jun 2000 21:28:06 GMT

I couldn't agree more Ken!  Moray generates Pov code so everything you can
do in Moray can be done in Pov code alone.

[Tony Micklus] Re: Trigonometry [9419 days 11 hours and 42 minutes ago]

Tue, 20 Jun 2000 12:00:24 GMT

If you are talking about what I think you are the laws are as follows

S = O/H
C = A/H
T =  O/A

S - Sine, C - Cosine, T - Tangent, O - Opposite, A - Adjacant, H -
Hypotinuse

Jerry wrote in message ...
>In article <394D6897.E18734FB@global2000.net>, Andrea Ryan
><ary### [at] global2000net> wrote:
>
>>How about putting information about the law of sines and the law of
cosines
>>on the page?  They will work with any triangle, not just right triangles.
>>The law of cosines is really just the Pythagorean theorem with a
correction
>>factor.
>
>Because I don't remember anything about them whatsoever? :*)
>

[Jerry] Re: Trigonometry [9420 days 4 hours and 58 minutes ago]

Mon, 19 Jun 2000 18:44:44 GMT

In article <394D6897.E18734FB@global2000.net>, Andrea Ryan 
<ary### [at] global2000net> wrote:

>How about putting information about the law of sines and the law of cosines
>on the page?  They will work with any triangle, not just right triangles.
>The law of cosines is really just the Pythagorean theorem with a correction
>factor.

Because I don't remember anything about them whatsoever? :*)

If you can explain them to me, and I find them useful, I will be happy 
to add a second chapter to my page.

Jerry

[Tony Micklus] Re: Does anyone just use Povray? [9420 days 10 hours and 4 minutes ago]

Mon, 19 Jun 2000 13:38:54 GMT

I have experimented with modellers. I tend to build my complicated objects
in POV-Ray as CSGs or Blobs. On occasion I will use SPatch. I have used
Moray v3.X and I don't get along with it very well. When it comes to
landscapes I use an old commercial program called VistaPro. It makes awsome
heightfields. It is a program I have played with since before I was a
Pov-Ray user.

Phead wrote in message <394b9bea$1@news.povray.org>...
>Hey, Im using Moray, and Ive noticed alot of talk about Pov code. Does
>anyone just use Povray for modelling? Isn't that pretty hard to visualize?
>
>

[Gail Shaw] Re: Does anyone just use Povray? [9420 days 17 hours and 16 minutes ago]

Mon, 19 Jun 2000 06:27:04 GMT

Phead wrote in message <394b9bea$1@news.povray.org>...
>Hey, Im using Moray, and Ive noticed alot of talk about Pov code. Does
>anyone just use Povray for modelling? Isn't that pretty hard to visualize?
>


I tend to model primarily in POV switching to sPatch or Moray only for
odder shapes (generally made of bezier patches). none of my
scenes have been done completely in a modeller and objects made
outside of povray are generally in the minority. As for how I visualize, I
find a graph book and a sharp pencil are essential.

Gail
********************************************************************
* gsh### [at] monotixcoza              * Reality.dat not found         *
* http://www.rucus.ru.ac.za/~gail/ * Attempting to reboot universe *
********************************************************************
* The best way to accelerate Windows NT is at 9.8 m/s^2      *
********************************************************************

[Andrea Ryan] Re: Trigonometry [9420 days 23 hours and 9 minutes ago]

Mon, 19 Jun 2000 00:34:18 GMT

How about putting information about the law of sines and the law of cosines
on the page?  They will work with any triangle, not just right triangles.
The law of cosines is really just the Pythagorean theorem with a correction
factor.
Brendan Ryan

Jerry wrote:

> I uploaded some of the trig formulas I keep forgetting, and put a simple
> tutorial around them.
>
> http://www.hoboes.com/html/NetLife/POV/Trig/
>
> Comments welcome, especially if I got something wrong :*)
>
> Jerry

[ryan constantine] Re: Does anyone just use Povray? [9421 days 1 hour and 29 minutes ago]

Sun, 18 Jun 2000 22:13:31 GMT

by complicated i mean a single model that can't be put together with
functions, macros, or randomization.  trees, grass etc. are complicated,
but i don't think of them as the same kind of models.  to me they are
more like environmental constructs (which make the surroundings of where
a model goes).  clouds and skies are another example of things that are
complicated, but don't fit into my personal view of a model.  of course,
anyone that can make any of the above items realistically, has praise
from me.

Warp wrote:
> 
> ryan constantine <rco### [at] yahoocom> wrote:
> : but for anything complicated, a modeller is the only
> : way to go.
> 
>   Well, it depends on your definition of "complicated".
>   For complicated generation of objects (trees, grass, galaxies...) modellers
> are not very good unless they specifically support those.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Phead] Re: Realistic landscape [9421 days 5 hours and 37 minutes ago]

Sun, 18 Jun 2000 18:06:14 GMT

I like Terragen, but I dont think it will export, so you're stuck with a
background image or image map.


"John Bauman" <bau### [at] ptdprolognet> wrote in message
news:37b728c0@news.povray.org...
> Does anyone know how to create a realistic landscape, with flat
> plateaus(sp?)?
>
> --
> webpage: http://johntb.freeservers.com
> ICQ:20886467 AIM:Qbwiz
> -----BEGIN GEEK CODE BLOCK-----
>  Version: 3.12
> G! d- s--:- a---- C++ ULU++++ P+  L+ E W++ N++ o K- w+
> O! M- V- PS PE+ Y+ PGP- t+@ 5 X R tv+ b++ DI++++ D-
> G e-- h! !r y-
> ------END GEEK CODE BLOCK------
>
>

[Phead] Re: Does anyone just use Povray? [9421 days 5 hours and 38 minutes ago]

Sun, 18 Jun 2000 18:04:43 GMT

"Warp" <war### [at] tagpovrayorg> wrote in message
news:394cefef@news.povray.org...


Those are some really nice images and good examples of using/not using a
modeler. Thanks!

[Warp] Re: Does anyone just use Povray? [9421 days 7 hours and 52 minutes ago]

Sun, 18 Jun 2000 15:51:11 GMT

Phead <sco### [at] d0gznetnospam> wrote:
: Hey, Im using Moray, and Ive noticed alot of talk about Pov code. Does
: anyone just use Povray for modelling? Isn't that pretty hard to visualize?

  It depends. I seldom use moray, although I have made something with it.
  For example this image I made completely with moray:

http://www.students.tut.fi/~warp/pics/Schoolfood.jpg

  Usually I code everything by hand. An example:

http://www.students.tut.fi/~warp/pics/Class.jpg

  In most of my best images I make some objects with a modeller (moray or
spatch or a model made by someone else) and the rest by hand.
  For example in this image:

http://www.students.tut.fi/~warp/pics/Spacedog_3.jpg

the sorcerer is made with moray, his hand is made with blob sculptor and
everything else is made by hand (or automatically created by povray, like
the heightfield).

  Sometimes I also use some include files (mostly made by Chris Colefax) as
well. For example in this image:

http://www.students.tut.fi/~warp/pics/Starship.jpg

the galaxy background is created with Chris' galaxy include file while the
spaceship is made by hand.

  In this image:

http://www.students.tut.fi/~warp/pics/Spacedog_6.jpg

the head of the character was made with spatch, the background was created
with Chris' lens flare include, and everything else is made by hand.

  I seldom do anything 100% with moray (or any other modeller). Only when
I need some (usually organic-looking) object that's too difficult to make
by hand I use some modeller to make that object.

  How do I "visualize" the scene when coding? Well, I imagine the coordinate
system in my head and figure out the coordinates of a certain point in space
by looking at this 3D space in my head. The I make a test render and see
how much did it go wrong and fine-tune the values.
  It's not that hard. Requires just a bit of practice.

  Why I do this? Because I'm a coder and I like the freedom povray gives to
me when making a scene. I can easily make a while-loop to create several
copies of the object or use some other specialized algorithms to do what
I want. With a modeller I can't usually do this.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Warp] Re: Does anyone just use Povray? [9421 days 8 hours and 14 minutes ago]

Sun, 18 Jun 2000 15:28:19 GMT

ryan constantine <rco### [at] yahoocom> wrote:
: but for anything complicated, a modeller is the only
: way to go.

  Well, it depends on your definition of "complicated".
  For complicated generation of objects (trees, grass, galaxies...) modellers
are not very good unless they specifically support those.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Phead] Re: Does anyone just use Povray? [9421 days 8 hours and 25 minutes ago]

Sun, 18 Jun 2000 15:18:07 GMT

> I try to prevent undue stress by only going looking at other peoples stuff
> when I'm in the mood to see some neat things once again.  However I'm
still
> learning to close the web browser before an attack of manic-depression
comes
> on.
> In all sincerity, I turn off the TV or at least change channels if I sense
too
> much 3D "goodness" being shown (more difficult to leave a theatre) or I
fear
> I'll become a permanent mindless spectator instead of any kind of
participant.
>
> Bob


hahahah.. good answer!

[Bob Hughes] Re: Does anyone just use Povray? [9421 days 17 hours and 9 minutes ago]

Sun, 18 Jun 2000 06:33:41 GMT

"Phead" <sco### [at] d0gznetnospam> wrote in message
news:394c554b@news.povray.org...
|
| Hey and also, I recently checked out the winners of the raytracing
| competition.  Man, those are some spectacular images and anims.  It does one
| of two things - it either inspires, or depresses.  Personally, I really
| don't think I have the patience to model Windor Castle or anything, but for
| my simple work, I am well inspired. Great job to all who submit!

I try to prevent undue stress by only going looking at other peoples stuff
when I'm in the mood to see some neat things once again.  However I'm still
learning to close the web browser before an attack of manic-depression comes
on.
In all sincerity, I turn off the TV or at least change channels if I sense too
much 3D "goodness" being shown (more difficult to leave a theatre) or I fear
I'll become a permanent mindless spectator instead of any kind of participant.

Bob

[Bob Hughes] Re: Does anyone just use Povray? [9421 days 17 hours and 17 minutes ago]

Sun, 18 Jun 2000 06:25:36 GMT

"Phil Clute" <pcl### [at] tiacnet> wrote in message
news:394C3B7D.75ACE6E0@tiac.net...
|  I sometimes use sPatch or Leveller for things that would be
| time consuming to do without a modeller, but whenever I decide to use
| one I feel like "Ugh, I have to argue with a dumb modeller again...".
| Whenever I use a modeller I have to chase objects all over the place,
| "a little to the left, no not that way! Oh I'm moving the wrong screen
| again...I didn't mean to do that! UNDO!"
| With code it's
| sphere{<1,3.5,2>,0.5
|        pigment{Blue}
| }
| ...Done.

A perfect description.  I could not have put it a better way.

[Phead] Re: Does anyone just use Povray? [9421 days 18 hours and 51 minutes ago]

Sun, 18 Jun 2000 04:51:23 GMT

Hey thanks for the replies.  I think I will stick with Moray awhile, but
check the code out at times too.

Hey and also, I recently checked out the winners of the raytracing
competition.  Man, those are some spectacular images and anims.  It does one
of two things - it either inspires, or depresses.  Personally, I really
don't think I have the patience to model Windor Castle or anything, but for
my simple work, I am well inspired. Great job to all who submit!


"Phead" <sco### [at] d0gznetnospam> wrote in message
news:394b9bea$1@news.povray.org...
> Hey, Im using Moray, and Ive noticed alot of talk about Pov code. Does
> anyone just use Povray for modelling? Isn't that pretty hard to visualize?
>
>

[Ken] Re: Does anyone just use Povray? [9421 days 20 hours and 25 minutes ago]

Sun, 18 Jun 2000 03:17:30 GMT

Phead wrote:
> 
> Hey, Im using Moray, and Ive noticed alot of talk about Pov code. Does
> anyone just use Povray for modelling? Isn't that pretty hard to visualize?

  As the official "Link Master" around here I have visited the pages
of just about every modeller ever made with support for POV-Ray and
most of the utility programs as well. I have downloaded and tried a
good many of them too. Like the others however I am hopelessly addicted
to typing my scenes out into a text based editor.
 With the addition of while loops and math operators in POV-Ray v3.0
the scene description language became that much more powerful and
there is not much if anything you can't do in plain text that you
can do with a GUI modelling program.
 There are however many people that stick to modellers alone and
put out some terrific work. It really depends on what you are
comfortable with and what makes you the most productive. As one
person mentioned they switched from Moray to text to learn more
about the code. This will help you understand POv-Ray's features
better and it will also allow you to use features that Moray has
no support for. It wouldn't hurt to try both and see what works
best for you.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Phil Clute] Re: Does anyone just use Povray? [9421 days 20 hours and 45 minutes ago]

Sun, 18 Jun 2000 02:57:28 GMT

> Hey, Im using Moray, and Ive noticed alot of talk about Pov code. Does
> anyone just use Povray for modelling? Isn't that pretty hard to visualize?
> 

I started with Moray but then I decided that I should learn how the
code works to understand Moray better... I never went back. As others
mentioned I sometimes use sPatch or Leveller for things that would be
time consuming to do without a modeller, but whenever I decide to use
one I feel like "Ugh, I have to argue with a dumb modeller again...".
Whenever I use a modeller I have to chase objects all over the place,
"a little to the left, no not that way! Oh I'm moving the wrong screen
again...I didn't mean to do that! UNDO!"
With code it's 
sphere{<1,3.5,2>,0.5
       pigment{Blue}
}
...Done.

-- 
Phil
...coffee?...yes please! extra sugar,extra cream...Thank you.

[ryan constantine] Re: Does anyone just use Povray? [9421 days 21 hours and 8 minutes ago]

Sun, 18 Jun 2000 02:34:46 GMT

i started on pov code, and for simple things i'll still use it, or to
modify moray code into megapov i'll use it. but for complex objects,
like the xwing i'm STILL working on- with over 1100 objects- there is no
way i could keep track of them without moray.  for those who haven't
used it for years, it is quite a good modeller right now in v3.2.  v3.3
is in the works now with several additions planned.  and using moray is
just a lot quicker in general.  there are things i would use plain
vanilla pov for.  things like isosurfaces, experiments in a specific
technique (which many povers do as can be seen in the images ng), and
things like that.  but for anything complicated, a modeller is the only
way to go.

Phead wrote:
> 
> Hey, Im using Moray, and Ive noticed alot of talk about Pov code. Does
> anyone just use Povray for modelling? Isn't that pretty hard to visualize?

[Bob Hughes] Re: Does anyone just use Povray? [9422 days 6 hours and 17 minutes ago]

Sat, 17 Jun 2000 17:25:21 GMT

"PoD" <pod### [at] merlinnetau> wrote in message
news:394BB63C.B5A1C65D@merlin.net.au...
| Phead wrote:
| >
| > Hey, Im using Moray, and Ive noticed alot of talk about Pov code. Does
| > anyone just use Povray for modelling? Isn't that pretty hard to visualize?
|
| I tried Moray a few times years ago.
| Only used POV code since.

Likewise here.  I have sPatch and hamaPatch and even a few Zip files of Moray
along with whatever else is in all these Zips, all sitting idle mostly (until
someone asks about them).  I started out on a store-bought modeler called 3D
Design Plus 2.0 years ago but that didn't last.  When I found out about
Polyray, and then POV-Ray, that was the end of the GUI for me.
As far as visualisation goes seems to me there's a lot involved in a modeler
ap too, all that positioning of point vertexes, lines and shapes isn't exactly
automatic you know  :-)

Bob

[Mick Hazelgrove] Re: Does anyone just use Povray? [9422 days 6 hours and 45 minutes ago]

Sat, 17 Jun 2000 16:58:16 GMT

Same here, can't stand modellers, with the possible exception of Hammapatch

Mick

"Phead" <sco### [at] d0gznetnospam> wrote in message
news:394b9bea$1@news.povray.org...
> Hey, Im using Moray, and Ive noticed alot of talk about Pov code. Does
> anyone just use Povray for modelling? Isn't that pretty hard to visualize?
>
>

[PoD] Re: Does anyone just use Povray? [9422 days 7 hours and 2 minutes ago]

Sat, 17 Jun 2000 16:40:56 GMT

Phead wrote:
> 
> Hey, Im using Moray, and Ive noticed alot of talk about Pov code. Does
> anyone just use Povray for modelling? Isn't that pretty hard to visualize?

I tried Moray a few times years ago.
Only used POV code since.

PoD.

[Phead] Does anyone just use Povray? [9422 days 8 hours and 2 minutes ago]

Sat, 17 Jun 2000 15:40:26 GMT

Hey, Im using Moray, and Ive noticed alot of talk about Pov code. Does
anyone just use Povray for modelling? Isn't that pretty hard to visualize?

[sighmoan] Re: Trigonometry [9426 days 12 hours and 56 minutes ago]

Tue, 13 Jun 2000 10:46:19 GMT

"Jerry" <jer### [at] acusdedu> wrote in message
news:jerry-80E32C.08260912062000@news.povray.org...
> I uploaded some of the trig formulas I keep forgetting, and put a simple
> tutorial around them.
>
> http://www.hoboes.com/html/NetLife/POV/Trig/
>
> Comments welcome, especially if I got something wrong :*)

Looks great, but those auto-run Quicktime movies gave IE conniption fits. I
thought my browser had crashed and was about to try Ctrl+Alt+Delete! Could
you at least fix them so they load, but don't run?

--
simon [is sorry he ever complained about animated GIFs ;) ]

[Jerry] Trigonometry [9427 days 8 hours and 17 minutes ago]

Mon, 12 Jun 2000 15:26:08 GMT

I uploaded some of the trig formulas I keep forgetting, and put a simple 
tutorial around them.

http://www.hoboes.com/html/NetLife/POV/Trig/

Comments welcome, especially if I got something wrong :*)

Jerry

[C J (C Jokinen)] POV Ry Study Gallery [9428 days 1 hour and 13 minutes ago]

Sun, 11 Jun 2000 22:29:47 GMT

Uploaded a simple tutorial that looks at some of the features of the 
camera. Good for New POV Users.Look for "CameraFX" in POV Basic page 2.
Also added a "POV Basic Quiz" to my new feature called quiz. This is a 
Just for fun test of your POV Knowledge. Try it out and let me know what 
you think.


-- 
C.J. - Pov User.
E-Mail: hou### [at] yahoocom
website: www.crosswinds.net/~povstudy
forum: www.delphi.com/povraytth/start

[Markus Becker] Re: Tutorial en castellano [9431 days 15 hours and 33 minutes ago]

Thu, 8 Jun 2000 08:09:58 GMT

Ali Mohammad wrote:
> 
> Babelfish is pretty useful--it can translate

It's useful, but the results generally are just
ridiculous.

Markus

[Ken] Re: Saving as an image [9434 days 4 hours and 4 minutes ago]

Mon, 5 Jun 2000 19:38:33 GMT

scsa316 wrote:
> 
> hey!  one more question...once i have an image i like, how do i save it as a
> jpg or gif image instead of a pov image?  TIA

When POV-Ray renders and image to the screen there is also an image
being stored in the directory where the .pov file you are rendering
is located. Depending on which platform of POV-Ray you are using
this might be a .tga, .png, or .bmp image file. POV-Ray does not
have built in support for outputting either .jpg or .gif. You will
have to locate the image on your hard drive and covert it using
any standard image processing program like PhotoShop of PSP.

May I make a couple of suggestions ?

Take some time to read the VFAQ. It was written by a few of us that
frequent these groups and covers many of the most frequently asked
questions asked by our new visitors -

http://www.students.tut.fi/~warp/povVFAQ/

Additionally the questions you are asking should be taken to the
group -povray.newusers- rather than posting them in this group.
Please take the time to subscribe to

povray.announce.frequently-asked-questions

and read through the various messages posted there. Especialy
read the message I posted "Welcome to the POV-Ray News Groups."
You will find a lot of good information in there that will
help you get more out of using the groups on this server and
it will also direct you to information on getting the most
out of using POV-Ray.

Enjoy,

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[scsa316] Saving as an image [9434 days 4 hours and 16 minutes ago]

Mon, 5 Jun 2000 19:26:27 GMT

hey!  one more question...once i have an image i like, how do i save it as a
jpg or gif image instead of a pov image?  TIA

~*~Lady Lex~*~

[Ken] Re: hello [9434 days 7 hours and 11 minutes ago]

Mon, 5 Jun 2000 16:32:14 GMT

scsa316 wrote:
> 
> hi! i am very new to POV ray and am amazed at the things i see done with
> it....i have 2 questions though... once i download macros what do i do with
> them so that i may use them and when i download a modle, where do i go from
> there?  Any help appreciated.  TIA!
> 
> ~*~Lady Lex~*~

Hi,

 On my home page I have a large collection of Macro files and a great
many of the files in the .zip have an example of how to use them
included. Follow the first link in my sig.

 As far as models are concerned it depends on what type of model you
are talking about. If it is a POV-Ray model in a .pov or .inc file
you can simply include it in your scene file. If it is in another
format such as .dxf or .3ds then you will need to convert it into
a format that POv-Ray can recogonize. This is usually done by a
3rd party software which will convert the model into a union or
mesh of triangles. Two very good utilities for this are 3DWin
and Crossroads -

http://www.stmuc.com/thbaier/
http://www.europa.com/~keithr/crossroads/

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[scsa316] hello [9434 days 7 hours and 31 minutes ago]

Mon, 5 Jun 2000 16:12:03 GMT

hi! i am very new to POV ray and am amazed at the things i see done with
it....i have 2 questions though... once i download macros what do i do with
them so that i may use them and when i download a modle, where do i go from
there?  Any help appreciated.  TIA!

~*~Lady Lex~*~

[david sharp] Re: Isosurface Tutorial updated [9440 days 7 hours and 58 minutes ago]

Tue, 30 May 2000 15:44:56 GMT

Moon47 <rdm### [at] earthlinknet> wrote
> Very good tutorial in deed... More than i need to know right now, but all
> very fun and interesting all the same...
> That said... I have a question...?
> Why is there such a difference w/ the vers. 0.4 & 0.5... Namely w/ the
> ridgedMF,hetroMF, & ridge functions...?

Probably because the POV noise function was fixed for 0.5.
Those functions use noise intensively.

[Moon47] Re: Isosurface Tutorial updated [9440 days 18 hours and 20 minutes ago]

Tue, 30 May 2000 05:23:03 GMT

Very good tutorial in deed... More than i need to know right now, but all
very fun and interesting all the same...
That said... I have a question...?
Why is there such a difference w/ the vers. 0.4 & 0.5... Namely w/ the
ridgedMF,hetroMF, & ridge functions...?

I will post an example of the "ridge" function in p.b.i...

Mike Williams wrote:

> 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

[C J (C Jokinen)] POV Ray Study Gallery [9442 days 1 hour and 31 minutes ago]

Sun, 28 May 2000 22:11:22 GMT

I have finished the rebuild of the POV Ray Study Gallery. Added new 
features and a new POV Custom Tutorial called "Saga of the Leaf" by 
Enderwiggens. This tutorial covers advanced animation of wind blown 
leaves. Very Cool! I must warn you that it does dabble in Basic and C a 
little farther into it.

-- 
C.J. - Pov User.
E-Mail: hou### [at] yahoocom
website: www.crosswinds.net/~povstudy
forum: www.delphi.com/povraytth/start

[Nathan Kopp] Re: Cartoon Tut! [9444 days 22 hours and 7 minutes ago]

Fri, 26 May 2000 01:35:43 GMT

DEPerere <per### [at] infomaniakch> wrote...
>
> I've noticed that with find_edges, shadowed surfaces can take the color
> set in PIGMENT_STATEMENTS. When DEPTH_THRESH is set to a little value,
> instead the single colored line of the edge, we have a big colored area.
> Setting a high value fix this problem, but another can arise. We may
> loose some edges.

Keep the value low, but not that low.  In your example, increasing the value
to 5 or 6 solved the problem of the large grey areas, while keeping the
edges.

> See my post on p.b.i. I used Ionic5 to illustrate the DEPTH_THRESH
> problem, in B/W.

See my reply in p.b.i for a further explanation.

-Nathan

[DEPerere] Re: Cartoon Tut! [9445 days 1 hour and 17 minutes ago]

Thu, 25 May 2000 22:26:12 GMT

Nathan Kopp a écrit:
> 
> H.E. Day <The### [at] hedayfreeserverscom> wrote ...
> >     The "10000" is the "distance differential" (DD).  This is used to
> >     determine if there is an edge between two overlapping surfaces.
> >     In this case, I have effectively turned it off.  It seems to
> >     have a lot of trouble with curved surfaces.
> 
> Please describe the problems that you ran into.
> 

I've noticed that with find_edges, shadowed surfaces can take the color
set in PIGMENT_STATEMENTS. When DEPTH_THRESH is set to a little value,
instead the single colored line of the edge, we have a big colored area.
Setting a high value fix this problem, but another can arise. We may
loose some edges.

See my post on p.b.i. I used Ionic5 to illustrate the DEPTH_THRESH
problem, in B/W.

DEPerere

[H E Day] Re: Cartoon Tut! [9445 days 6 hours and 36 minutes ago]

Thu, 25 May 2000 17:06:32 GMT

> Thanks for the tutorial HE. :) Please post some examples.

There's a anim in p.b.i that shows how this turned out.  It's titled:
"Futurama space ship"
Good luck!


--
H.E. Day

[Nathan Kopp] Re: Cartoon Tut! [9445 days 19 hours and 9 minutes ago]

Thu, 25 May 2000 04:33:37 GMT

H.E. Day <The### [at] hedayfreeserverscom> wrote ...
>     The "10000" is the "distance differential" (DD).  This is used to
>     determine if there is an edge between two overlapping surfaces.
>     In this case, I have effectively turned it off.  It seems to
>     have a lot of trouble with curved surfaces.

Please describe the problems that you ran into.

>     The next two 1s' determine edge line width. Setting the first to
>     anything over 1 causes thick, black lines. Setting the second has
>     no effect. (Note to Chris Huff, if you're reading this, could you
>     make the line sharpness factor work on lines of 1 or less?  Being
>     able to have lines of less than 1 width would be nice too. :)

That's a possibility, though it might be difficult.  Lines less than one
pixel in width generally run into aliasing problems.

-Nathan

[Tony[B]] Re: Cartoon Tut! [9446 days and 9 minutes ago]

Wed, 24 May 2000 23:34:08 GMT

Thanks for the tutorial HE. :) Please post some examples.

[H E Day] Cartoon Tut! [9446 days 17 hours and 36 minutes ago]

Wed, 24 May 2000 06:06:36 GMT

MAKING FUTURAMA TYPE CARTOON EFFECTS WITH POV-RAY

PART ONE:

 The first thing to do is to create a model.  Once this is
 finished you need to texture the model correctly for a
 cartoon style.  This is accomplished by using the following
 finish statement, or something much like it.

 finish {ambient 1 diffuse .5 brilliance 0}

 This will make the color bright, yet still allow it to
 interact with light sources.  The brilliance statement
 sets the "sharpness" of the highlights. 1 is normal, 0 is
 perfectly sharp.  I recommend that you use a number between
 0 and .1 when making cartoons.


PART TWO:

 The next thing needed is to add a "find edges" statement.
 Put this at the to of your .pov file.
 One that works rather well is:

 #version unofficial MegaPov 0.5;
 global_settings {
 max_trace_level 40
 post_process { overwrite_file
 find_edges{10000,.05,1,1,1,rgb 0}
 }
    }

    Things to note:
    The "10000" is the "distance differential" (DD).  This is used to
    determine if there is an edge between two overlapping surfaces.
    In this case, I have effectively turned it off.  It seems to
    have a lot of trouble with curved surfaces.

    The ".05" id the "normal differential" (ND).  This is used to
    determine if there is an edge is square corners and the like.
    I set it pretty low to make up for the absence of the "DD"

    The "1" next to the ".05" is the "color differential" (CD) used
    to add edges around different patches of color.  I set it to 1,
    turning it off.

    The next two 1s' determine edge line width. Setting the first to
    anything over 1 causes thick, black lines. Setting the second has
    no effect. (Note to Chris Huff, if you're reading this, could you
    make the line sharpness factor work on lines of 1 or less?  Being
    able to have lines of less than 1 width would be nice too. :)

    The "rgb 0" is the color of the edges. 'Nuff said.

PART THRICE:

 Render!  The only suggestions I have are to exaggerate shapes.  Also,
 pure, bright colors work best.  Good luck!

--
H.E. Day
<><

[Tony[B]] Re: Isosurface Tutorial updated [9447 days and 20 minutes ago]

Tue, 23 May 2000 23:22:33 GMT

Superb tutorial. Thank you.

[Martial] Re: Isosurface Tutorial updated [9458 days 7 hours and 39 minutes ago]

Fri, 12 May 2000 16:04:15 GMT

Mike Williams a écrit :
> 
> I've substantially updated my isosurface tutorial at
> <http://www.econym.demon.co.uk/isotut>.

It's a very great tools to works !
Thanks * 1000*1000 

-- 
Martial !-)
mailto:Mar### [at] wanadoofr
http://martial.rameaux.free.fr

[Gail Shaw] Re: Isosurface Tutorial updated [9459 days 12 hours and 14 minutes ago]

Thu, 11 May 2000 11:28:41 GMT

Mike Williams wrote in message ...
>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.



Looks very nice.

For trivia, I think the func_11 is the density function for electrons in the
d orbital
of an atom. My physics is a tad rusty so I could be wrong.

Gail
********************************************************************
* gsh### [at] monotixcoza              * Reality.dat not found         *
* http://www.rucus.ru.ac.za/~gail/ * Attempting to reboot universe *
********************************************************************
* The best way to accelerate Windows NT is at 9.8 m/s^2      *
********************************************************************

[Warp] Re: Isosurface Tutorial updated [9460 days 13 hours and 58 minutes ago]

Wed, 10 May 2000 09:44:50 GMT

Btw, the quartic saddle at http://www.econym.demon.co.uk/isotut/builtin4.htm
is missing the function definition.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Warp] Re: Isosurface Tutorial updated [9460 days 14 hours and 41 minutes ago]

Wed, 10 May 2000 09:01:45 GMT

This tutorial is excellent.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Mike Williams] Isosurface Tutorial updated [9460 days 17 hours ago]

Wed, 10 May 2000 06:43:00 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

[Jerry] Re: centering text [9466 days 4 hours and 32 minutes ago]

Thu, 4 May 2000 19:11:05 GMT

In article <391169D5.9C54F7F9@iez.com>, Thomas Lehmann 
<tle### [at] iezcom> wrote:

>Hi,
>
>is there any way to center a text of any font in a
>bounding box ?

You need to use megapov, basically. There are two ways of doing it.

1. The font can be centered on itself. I believe this is only left-right 
centering, but then the center of the image is at x=0 and you can move 
it where you want. I think you simply add the keyword 'center', but 
check the docs.

2. If you want to center verticaly as well as horizontally, the megapov 
includes Ron Parker's "Object Bounds" which gives you the bounding box 
of an object. Create your text object and assign it to a variable:

myText = text { .... }
myTextMin = min_extent(myText);
myTextMax = max_extent(myText);
object { myText
   translate <(myTextMax.x-myTextMin.x)/2,
      (myTextMax.y-myTextMin.y)/2,
      0>
}

should center your object vertically and horizontally. From there, you 
can move it where you need it. You can also use the extents to scale 
your text object to a specific height and/or width, so as to fit exactly 
inside a desired object.

Jerry

[Warp] Re: centering text [9466 days 11 hours and 7 minutes ago]

Thu, 4 May 2000 12:35:56 GMT

Thomas Lehmann <tle### [at] iezcom> wrote:
: is there any way to center a text of any font in a
: bounding box ?

  Yes, using MegaPov.
http://nathan.kopp.com/patched.htm

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Thomas Lehmann] centering text [9466 days 11 hours and 29 minutes ago]

Thu, 4 May 2000 12:13:58 GMT

Hi,

is there any way to center a text of any font in a
bounding box ?

Thomas

[Peter Popov] Re: HEEELP! [9471 days 15 hours and 41 minutes ago]

Sat, 29 Apr 2000 08:02:13 GMT

On Tue, 25 Apr 2000 20:13:07 +0200, "Zilvah" <mor### [at] yahoocom>
wrote:

>I would REALLY appreciate it if someone would teach me and give me lessons
>over e-mail or IRC, or even ICQ!

Sorry about last night, the darn modem dropped again. The solution is
in povray.text.scene-files, called "For Zilvah".


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

[Zilvah] Re: HEEELP! [9472 days 4 hours and 24 minutes ago]

Fri, 28 Apr 2000 19:18:55 GMT

Ken <tyl### [at] pacbellnet> wrote in message
news:39064B21.CFE34AAA@pacbell.net...
>
>
> Peter Popov wrote:
>
> > The povray.newusers group on this server is a great place to start,
> > too.
>
> As well as the online POV-Ray tutorials listed in the tutorials section
> at - http://www.povray.org/links/
>
> --
> Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
> http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

That's too basic, IMHO (the newusers group)

[Ken] Re: HEEELP! [9474 days 21 hours and 52 minutes ago]

Wed, 26 Apr 2000 01:51:08 GMT

Peter Popov wrote:

> The povray.newusers group on this server is a great place to start,
> too.

As well as the online POV-Ray tutorials listed in the tutorials section
at - http://www.povray.org/links/

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

[Peter Popov] Re: HEEELP! [9474 days 22 hours and 24 minutes ago]

Wed, 26 Apr 2000 01:18:42 GMT

On Tue, 25 Apr 2000 20:13:07 +0200, "Zilvah" <mor### [at] yahoocom>
wrote:

>I would REALLY appreciate it if someone would teach me and give me lessons
>over e-mail or IRC, or even ICQ!
                             ^^^

Sure thing. I am usually online from about 10 p.m. to 3 a.m. EEST.
Send me an authorisation request if you want to. I have over 40 POV
users on my contact list, we might as well share some contacts :)

The povray.newusers group on this server is a great place to start,
too.

Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

[Zilvah] HEEELP! [9475 days 5 hours and 30 minutes ago]

Tue, 25 Apr 2000 18:12:56 GMT

I'm still what you may call a newbie..

I¨'ve read the Documentation required for POV-Ray, and understand most of
it, except the part beyond splines, including that...

I'm also lost at the #functions, and need help with the math stuff too...

I would REALLY appreciate it if someone would teach me and give me lessons
over e-mail or IRC, or even ICQ!

I could really use the help..

Zilvah
ICQ: 49665027
E-Mail: mor### [at] yahoocom

[Chris Huff] Re: Isosurface tutorial [9490 days 22 hours and 11 minutes ago]

Mon, 10 Apr 2000 01:32:02 GMT

In article <38F12D48.C366F9FB@hotmail.com>, Pabs <pab### [at] hotmailcom> 
wrote:

> Sorry - what about if I want to use a gif/tga, just like in a proper hf -
> what pigment should I use for this

Use an image map in the pigment...just don't forget to turn on 
interpolation.
#declare imagePigmentFn =
function {
    pigment {
        image_map {png "image.png"
            map_type 0
            interpolate 2
        }
        rotate x*90 // because image_maps are projected in the xy plane
    }
}

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Web page: http://chrishuff.dhs.org/

[Pabs] Re: Isosurface tutorial [9490 days 22 hours and 19 minutes ago]

Mon, 10 Apr 2000 01:23:53 GMT

> #declare CrackleFn =
> function {
>     pigment {crackle ramp_wave
>         color_map {[0 rgb 0][1 rgb 1]}
>     }
> }
> function {y}

Sorry - what about if I want to use a gif/tga, just like in a proper hf -
what pigment should I use for this

[Pabs] Re: Isosurface tutorial [9493 days 22 hours ago]

Fri, 7 Apr 2000 01:43:12 GMT

Thanks heaps

[Chris Huff] Re: Isosurface tutorial [9494 days 8 hours and 5 minutes ago]

Thu, 6 Apr 2000 15:37:41 GMT

In article <38EBF909.A986DE48@hotmail.com>, Pabs <pab### [at] hotmailcom> 
wrote:

> You wouldn't happen to know anything about isosurface heightfeilds BTW.

Start with a plane and a pigment function:
#declare CrackleFn =
function {
    pigment {crackle ramp_wave
        color_map {[0 rgb 0][1 rgb 1]}
    }
}
function {y}

And subtract the pigment function from the plane function, so it is 
raised depending on the value of the pigment. There are two ways to do 
this, one which allows overhangs and separated pieces of the height 
field(because it makes the pattern function dependant on y):
function {y - CrackleFn(x,y,z)}

and one which behaves like the usual height field, with no overhangs:
function {y - CrackleFn(x,0,z)}

In the isosurface, use a threshold of 0 and bound with a box from 
<0,0,0> to <1,1,1> if you want to make a direct substitution for a 
height_field primative.
isosurface {
    function {y - CrackleFn(x,0,z)}
    threshold 0
    eval
    contained_by {box {<0,0,0>, <1,1,1>}}
}

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Web page: http://chrishuff.dhs.org/

[Pabs] Re: Isosurface tutorial [9494 days 21 hours and 3 minutes ago]

Thu, 6 Apr 2000 02:39:37 GMT

You wouldn't happen to know anything about isosurface heightfeilds BTW.

[Robert Jefferson] Re: Isosurface tutorial [9497 days 22 hours and 54 minutes ago]

Mon, 3 Apr 2000 00:49:10 GMT

very good pigment stuff

--
-----------------------------------------------------
Click here for Free Video!!
http://www.gohip.com/freevideo/

"Warp" <war### [at] tagpovrayorg> wrote in message
news:38e78958@news.povray.org...
>   Not bad.
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Warp] Re: Isosurface tutorial [9498 days 5 hours and 48 minutes ago]

Sun, 2 Apr 2000 17:54:33 GMT

Not bad.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

[Mike Williams] Isosurface tutorial [9499 days 13 hours and 53 minutes ago]

Sat, 1 Apr 2000 09:49:41 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