> 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