On 20/10/2010 2:02 AM, John VanSickle wrote:
>     When I need a starry background in POV-Ray, I use an assortment of
> randomly-placed triangles.

I use pentangles but get slagged off for using star shaped stars. Ah well!

-- 

Best Regards,
	Stephen

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> On 10/15/2010 8:48 PM, Florin Andrei wrote:
> > I am trying to render an astronomy object, with stars as a background. This is
> > fine as a static image, but I'm having tremendous issues when doing an
> > animation. Basically, I can't find a solution to the simple problem of having
> > the exact same image (starfield) for all frames, when the camera is moving.
> > Looks like, no matter what, the starfield background is randomly built anew for
> > each frame. This is not good. I want the starry background to be exactly the
> > same in each frame, fully static relative to the moving camera.
> >
> > I tried to paint Starfield1 on a box (or plane) and have the box move with the
> > exact same speed as the camera:
> >
> > http://pastebin.com/raw.php?i=4KZL7jcG
> >
> > povray from_mars.pov +W1920 +H1080 -visual DirectColor +A0.1 +AM2
> >
> > Well, no, each frame the stars are painted again, randomly. :(
> >
> > How do I make the starfield completely static for all frames when the camera is
> > moving?
>
>     When I need a starry background in POV-Ray, I use an assortment of
> randomly-placed triangles. There are other approaches, but I prefer this
> because I like to use objects that model the simulated objects as
> closely as possible. Stars, from the sightseeing viewpoint, are just
> ultra-bright objects that are just close enough to appear as points of
> light.
>     The trick is to place the stars so that at least one pixel but no
> more than four pixels overlap the star's silhouette on the computer
> screen. This will give a point of light, especially when anti-aliasing
> is used.
>
>      Use the following code:
>
> #local sB=sqrt(3)/min(image_height,image_width)/sCamZ;
> #local pA=< 0,          sB*2/3,1>*100000;
> #local pB=< sB/sqrt(3),-sB/3,  1>*100000;
> #local pC=<-sB/sqrt(3),-sB/3,  1>*100000;
>
> #local S0=seed(4);
> #local cC=16;
> #local sC=.5/cC;#while(sC<=1)
> mesh {
> #local iI=0; #while (iI<1600/cC*sCamZ*sCamZ)
>    #local vAng=<rand(S0),rand(S0),rand(S0)>*360;
>    #if
> (vdot(vrotate(z,vAng),vCamD)>sCamZ/vlength(<sCamR/2,sCamU/2,sCamZ>) |
> AllStars)
>      triangle { vrotate(pA,vAng), vrotate(pB,vAng), vrotate(pC,vAng) }
>    #end
> #local iI=iI+1; #end
>    no_shadow
> pigment { rgb
> <max(0,-(sC-1)*2),min(sC*4,-(sC-1)*4),max(0,(sC-.25)*4)>*.2+.8 }
> finish { ambient 1 diffuse 0 }
>
> //  scale Beyond
>    translate pCamL
> }
> #local sC=sC+1/cC;#end
>
> A number of parameters are used here that you'll need to define first:
>
> * AllStars: If true, forces all stars to be made. When false prevents
> creation of off-camera stars
> * Beyond: This is commented out because you may not need it. If any of
> the stars appear in front of other objects in your scene, take out the
> slashes and set Beyond to some value that puts the stars beyond all of
> the other scene objects.
> * cC: This sets the number of shades of color the stars will have. Stars
> will range in color from reddish to bluish.
> * pCamL: The location setting of your camera.
> * sCamR: The length of the right parameter of the camera. If you didn't
> specify a right vector in the camera, use a value of 4/3 here.
> * sCamU: The length of the up parameter of the camera. If you didn't
> specify this parameter in the camera statement, use 1 here.
> * sCamZ: The length of the direction vector in your camera. If you
> specify the angle in your camera, then set this value equal to
> cot(radians(angle)/2)*4/3. If you didn't specify either direction or
> angle, use 1 here.
> * vCamD: The normalized value of the direction vector in your camera
>
> Hope this helps,
> John

Really? Macros for a simple starfield? It can be done much easier with a
sky_sphere. I'm not using the standard stars.inc starfield, I'm using my own
texture. Paste the code into your scene and delete your previous background
sphere/box/sky_sphere/whatever.
sky_sphere {
//These first three are white stars.
  pigment {
    bozo scale 0.01
    color_map { [0.9 color rgb 0] [0.95 color rgb 1] }
  }
  pigment {
    bozo scale 0.005
    color_map { [0.89 color rgb 0 transmit 1] [0.9 color rgb 1] }
  }
  pigment {
    bozo scale 0.003
    color_map { [0.89 color rgb 0 transmit 1] [0.9 color rgb 1] }
  }
//These next three are blue stars.
  pigment {
    bozo scale 0.009
    color_map { [0.89 color rgb 0 transmit 1] [0.895 color rgb <0, 0.5, 1>] [0.9
color rgb 1] }
  }
  pigment {
    bozo scale 0.004
    color_map { [0.89 color rgb 0 transmit 1] [0.895 color rgb <0, 0.5, 1>] [0.9
color rgb 1] }
  }
  pigment {
    bozo scale 0.002
    color_map { [0.89 color rgb 0 transmit 1] [0.895 color rgb <0, 0.5, 1>] [0.9
color rgb 1] }
  }
//These next two are red stars.
  pigment {
    bozo scale 0.003
    color_map { [0.89 color rgb 0 transmit 1] [0.895 color rgb <1, 0.5, 0>] [0.9
color rgb 1] }
  }
  pigment {
    bozo scale 0.001
    color_map { [0.89 color rgb 0 transmit 1] [0.895 color rgb <1, 0.5, 0>] [0.9
color rgb 1] }
  }
//Now it's time for nebulae.
  pigment {
  granite scale 2 color_map {   [0 color rgb 0 transmit 1][0.7 rgb <0.1, 0, 0.7>
transmit 0.8 ] } }
  pigment {
  wrinkles scale 2 color_map {   [0 color rgb 0 transmit 1][0.8 rgb <0.1, 0.7,
0.2> transmit 0.7 ] } }
  pigment {
  bozo scale 1 turbulence 2 octaves 100 color_map {   [0.5 color rgb 0 transmit
1][1 rgb <0.7, 0.2, 0.1> ] } }
//And now the bigger stars again so they aren't dimmed by the nebulae.
  pigment {
    bozo scale 0.01
    color_map { [0.9 color rgb 0 transmit 1] [0.95 color rgb 1] }
  }
  pigment {
    bozo scale 0.009
    color_map { [0.89 color rgb 0 transmit 1] [0.895 color rgb <0, 0.5, 1>] [0.9
color rgb 1] }
  }
}

Post a reply to this message

> John VanSickle<evi### [at] hotmailcom>  wrote:
>> On 10/15/2010 8:48 PM, Florin Andrei wrote:
>>> I am trying to render an astronomy object, with stars as a background. This is
>>> fine as a static image, but I'm having tremendous issues when doing an
>>> animation. Basically, I can't find a solution to the simple problem of having
>>> the exact same image (starfield) for all frames, when the camera is moving.
>>> Looks like, no matter what, the starfield background is randomly built anew for
>>> each frame. This is not good. I want the starry background to be exactly the
>>> same in each frame, fully static relative to the moving camera.
>>>
>>> I tried to paint Starfield1 on a box (or plane) and have the box move with the
>>> exact same speed as the camera:
>>>
>>> http://pastebin.com/raw.php?i=4KZL7jcG
>>>
>>> povray from_mars.pov +W1920 +H1080 -visual DirectColor +A0.1 +AM2
>>>
>>> Well, no, each frame the stars are painted again, randomly. :(
>>>
>>> How do I make the starfield completely static for all frames when the camera is
>>> moving?
>>
>>      When I need a starry background in POV-Ray, I use an assortment of
>> randomly-placed triangles. There are other approaches, but I prefer this
>> because I like to use objects that model the simulated objects as
>> closely as possible. Stars, from the sightseeing viewpoint, are just
>> ultra-bright objects that are just close enough to appear as points of
>> light.
>>      The trick is to place the stars so that at least one pixel but no
>> more than four pixels overlap the star's silhouette on the computer
>> screen. This will give a point of light, especially when anti-aliasing
>> is used.
>>
>>       Use the following code:
>>
>> #local sB=sqrt(3)/min(image_height,image_width)/sCamZ;
>> #local pA=<  0,          sB*2/3,1>*100000;
>> #local pB=<  sB/sqrt(3),-sB/3,  1>*100000;
>> #local pC=<-sB/sqrt(3),-sB/3,  1>*100000;
>>
>> #local S0=seed(4);
>> #local cC=16;
>> #local sC=.5/cC;#while(sC<=1)
>> mesh {
>> #local iI=0; #while (iI<1600/cC*sCamZ*sCamZ)
>>     #local vAng=<rand(S0),rand(S0),rand(S0)>*360;
>>     #if
>> (vdot(vrotate(z,vAng),vCamD)>sCamZ/vlength(<sCamR/2,sCamU/2,sCamZ>) |
>> AllStars)
>>       triangle { vrotate(pA,vAng), vrotate(pB,vAng), vrotate(pC,vAng) }
>>     #end
>> #local iI=iI+1; #end
>>     no_shadow
>> pigment { rgb
>> <max(0,-(sC-1)*2),min(sC*4,-(sC-1)*4),max(0,(sC-.25)*4)>*.2+.8 }
>> finish { ambient 1 diffuse 0 }
>>
>> //  scale Beyond
>>     translate pCamL
>> }
>> #local sC=sC+1/cC;#end
>>
>> A number of parameters are used here that you'll need to define first:
>>
>> * AllStars: If true, forces all stars to be made. When false prevents
>> creation of off-camera stars
>> * Beyond: This is commented out because you may not need it. If any of
>> the stars appear in front of other objects in your scene, take out the
>> slashes and set Beyond to some value that puts the stars beyond all of
>> the other scene objects.
>> * cC: This sets the number of shades of color the stars will have. Stars
>> will range in color from reddish to bluish.
>> * pCamL: The location setting of your camera.
>> * sCamR: The length of the right parameter of the camera. If you didn't
>> specify a right vector in the camera, use a value of 4/3 here.
>> * sCamU: The length of the up parameter of the camera. If you didn't
>> specify this parameter in the camera statement, use 1 here.
>> * sCamZ: The length of the direction vector in your camera. If you
>> specify the angle in your camera, then set this value equal to
>> cot(radians(angle)/2)*4/3. If you didn't specify either direction or
>> angle, use 1 here.
>> * vCamD: The normalized value of the direction vector in your camera
>>
>> Hope this helps,
>> John
>
> Really? Macros for a simple starfield? It can be done much easier with a
> sky_sphere. I'm not using the standard stars.inc starfield, I'm using my own
> texture. Paste the code into your scene and delete your previous background
> sphere/box/sky_sphere/whatever.

Your code still suffers from the same effect as the standard sky 
pigments. That problem is that it relies on sub-pixel details to do it's 
magic.
If you rotate the camera or see it in a moving reflective surface, the 
stars will flicker wildly from frame to frame.
It will also change, possibly quite a lot, whenever you change the 
dimention of your image, as the pixel to sub-pixel relation will change.

Also, as it have 14 layers, your texture is particularly slow to render.

Whenever you have a mobile camera, and that that camera is subjected to 
change t's orientation during an animation, you just can't rely on any 
pigment or texture that is based on fine grained sub-pixel details to work.

What you need are stars that are guaranteed to always remain visible 
from frame to frame, and thus, need to be at least as whide as a pixel, 
or a little larger.
Your proposition with a bozo scaled as low as 0.001 will just don't work.



Alain

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:

> > John VanSickle<evi### [at] hotmailcom>  wrote:
> >> On 10/15/2010 8:48 PM, Florin Andrei wrote:
> >>> I am trying to render an astronomy object, with stars as a background. This is
> >>> fine as a static image, but I'm having tremendous issues when doing an
> >>> animation. Basically, I can't find a solution to the simple problem of having
> >>> the exact same image (starfield) for all frames, when the camera is moving.
> >>> Looks like, no matter what, the starfield background is randomly built anew for
> >>> each frame. This is not good. I want the starry background to be exactly the
> >>> same in each frame, fully static relative to the moving camera.
> >>>
> >>> I tried to paint Starfield1 on a box (or plane) and have the box move with the
> >>> exact same speed as the camera:
> >>>
> >>> http://pastebin.com/raw.php?i=4KZL7jcG
> >>>
> >>> povray from_mars.pov +W1920 +H1080 -visual DirectColor +A0.1 +AM2
> >>>
> >>> Well, no, each frame the stars are painted again, randomly. :(
> >>>
> >>> How do I make the starfield completely static for all frames when the camera is
> >>> moving?
> >>
> >>      When I need a starry background in POV-Ray, I use an assortment of
> >> randomly-placed triangles. There are other approaches, but I prefer this
> >> because I like to use objects that model the simulated objects as
> >> closely as possible. Stars, from the sightseeing viewpoint, are just
> >> ultra-bright objects that are just close enough to appear as points of
> >> light.
> >>      The trick is to place the stars so that at least one pixel but no
> >> more than four pixels overlap the star's silhouette on the computer
> >> screen. This will give a point of light, especially when anti-aliasing
> >> is used.
> >>
> >>       Use the following code:
> >>
> >> #local sB=sqrt(3)/min(image_height,image_width)/sCamZ;
> >> #local pA=<  0,          sB*2/3,1>*100000;
> >> #local pB=<  sB/sqrt(3),-sB/3,  1>*100000;
> >> #local pC=<-sB/sqrt(3),-sB/3,  1>*100000;
> >>
> >> #local S0=seed(4);
> >> #local cC=16;
> >> #local sC=.5/cC;#while(sC<=1)
> >> mesh {
> >> #local iI=0; #while (iI<1600/cC*sCamZ*sCamZ)
> >>     #local vAng=<rand(S0),rand(S0),rand(S0)>*360;
> >>     #if
> >> (vdot(vrotate(z,vAng),vCamD)>sCamZ/vlength(<sCamR/2,sCamU/2,sCamZ>) |
> >> AllStars)
> >>       triangle { vrotate(pA,vAng), vrotate(pB,vAng), vrotate(pC,vAng) }
> >>     #end
> >> #local iI=iI+1; #end
> >>     no_shadow
> >> pigment { rgb
> >> <max(0,-(sC-1)*2),min(sC*4,-(sC-1)*4),max(0,(sC-.25)*4)>*.2+.8 }
> >> finish { ambient 1 diffuse 0 }
> >>
> >> //  scale Beyond
> >>     translate pCamL
> >> }
> >> #local sC=sC+1/cC;#end
> >>
> >> A number of parameters are used here that you'll need to define first:
> >>
> >> * AllStars: If true, forces all stars to be made. When false prevents
> >> creation of off-camera stars
> >> * Beyond: This is commented out because you may not need it. If any of
> >> the stars appear in front of other objects in your scene, take out the
> >> slashes and set Beyond to some value that puts the stars beyond all of
> >> the other scene objects.
> >> * cC: This sets the number of shades of color the stars will have. Stars
> >> will range in color from reddish to bluish.
> >> * pCamL: The location setting of your camera.
> >> * sCamR: The length of the right parameter of the camera. If you didn't
> >> specify a right vector in the camera, use a value of 4/3 here.
> >> * sCamU: The length of the up parameter of the camera. If you didn't
> >> specify this parameter in the camera statement, use 1 here.
> >> * sCamZ: The length of the direction vector in your camera. If you
> >> specify the angle in your camera, then set this value equal to
> >> cot(radians(angle)/2)*4/3. If you didn't specify either direction or
> >> angle, use 1 here.
> >> * vCamD: The normalized value of the direction vector in your camera
> >>
> >> Hope this helps,
> >> John
> >
> > Really? Macros for a simple starfield? It can be done much easier with a
> > sky_sphere. I'm not using the standard stars.inc starfield, I'm using my own
> > texture. Paste the code into your scene and delete your previous background
> > sphere/box/sky_sphere/whatever.
>
> Your code still suffers from the same effect as the standard sky
> pigments. That problem is that it relies on sub-pixel details to do it's
> magic.
> If you rotate the camera or see it in a moving reflective surface, the
> stars will flicker wildly from frame to frame.
> It will also change, possibly quite a lot, whenever you change the
> dimention of your image, as the pixel to sub-pixel relation will change.
>
> Also, as it have 14 layers, your texture is particularly slow to render.
>
> Whenever you have a mobile camera, and that that camera is subjected to
> change t's orientation during an animation, you just can't rely on any
> pigment or texture that is based on fine grained sub-pixel details to work.
>
> What you need are stars that are guaranteed to always remain visible
> from frame to frame, and thus, need to be at least as whide as a pixel,
> or a little larger.
> Your proposition with a bozo scaled as low as 0.001 will just don't work.
>
>
>
> Alain

No, it doesn't flicker wildly between frames. In fact it is almost
flicker-proof. Some of the smaller stars flicker, but you can comment out the
smaller stars if you absolutely cannot tolerate flickering at all.

Post a reply to this message

On Sat, 30 Apr 2011 02:49:26 +0200, Alain <aze### [at] qwertyorg> wrote:


>> Really? Macros for a simple starfield? It can be done much easier with a
>> sky_sphere. I'm not using the standard stars.inc starfield, I'm using  
>> my own
>> texture. Paste the code into your scene and delete your previous  
>> background
>> sphere/box/sky_sphere/whatever.
>
> Your code still suffers from the same effect as the standard sky  
> pigments. That problem is that it relies on sub-pixel details to do it's  
> magic.
> If you rotate the camera or see it in a moving reflective surface, the  
> stars will flicker wildly from frame to frame.
> It will also change, possibly quite a lot, whenever you change the  
> dimention of your image, as the pixel to sub-pixel relation will change.
>
> Also, as it have 14 layers, your texture is particularly slow to render.
>
> Whenever you have a mobile camera, and that that camera is subjected to  
> change t's orientation during an animation, you just can't rely on any  
> pigment or texture that is based on fine grained sub-pixel details to  
> work.
>
> What you need are stars that are guaranteed to always remain visible  
> from frame to frame, and thus, need to be at least as whide as a pixel,  
> or a little larger.
> Your proposition with a bozo scaled as low as 0.001 will just don't work.
>
>
>
> Alain

How about:


sky_sphere{ pigment { crackle form  <1,0,0>
                       color_map { [0 rgb 1]
                                   [.1 rgb 0]
                                 }
                       scale .05
                     }
           }

-- 
-Nekar Xenos-

Post a reply to this message