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