On the subject of stars and starfields, how do you make little stars show
up?

Ideally in my mind I think (a) all stars should take up no more than one
pixel (unless using focal blur :-)), and (b) all stars in a pixel would
contribute to to the intensity of that pixel.


Yeah, I know that's not now raytracing works, but it seems it's almost
exactly like what goes on making Vista Buffers so I'm guessing it's
implementable.

Yeah, I also know this won't work with reflections, etc. but I don't see too
many reflective enough items to show stars anyway.


Or am I thinking about this in the wrong way?

Post a reply to this message

there are two "correct" solutions coming into my mind:
1) Render the image in a very (I said VERY!) high resolution and scale down,
   wich is of course the same as render many rays to the same pixel.

2) Do forward raytracing and hope that you didn't set a to low recursion level...

Post a reply to this message

"ron_ivi" <nomail@nomail> wrote in
news:web.3d6bc301b4c1e988cd0d0b840@news.povray.org 

> On the subject of stars and starfields, how do you make little stars
> show up?

I was alsow thinking about this problem.
Imho - primitive "pivel" would be very useful.
syntax :

pixel {
  CENTER
  color
  TRANSFORMS
}

i.e.
pixel { <1e5,0,0>  <.1, .1, 1>*.8  rotate y*24 rotate z*143 }

will give nice star.

How to implement it ? quite simple.
1. take coordinates after all transforms, i.e. A=<100,250,380>
2. project it into screen, to get i.e. P=<12.0001, 10.05> pixel. So this 
point is almost at center of pixel <12,10> in output image.
3. round screen cordinates (P), to P'=<12.0,10.0>
4. reverse-project it - find point more close to A, that projected on 
screen gives A'. i.e. P'=<101,245,380>

The intersection test of 'pixel' is same as sphere with radius==epsilon (or 
some tolerance value)

There are 2 problems :
- pixel will disapera when strong AA is on
- too many small pixels without AA will make strange effect


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Here's a starfield I just used.  I shoudda increased the number of stars....

background{rgb 0}
#declare RRR=seed(123);
#declare n=0;
#while(n<3000)
sphere{500000*<
        sgn(rand(RRR)-0.5)*(0.15+rand(RRR)),
        sgn(rand(RRR)-.5)*(0.15+rand(RRR))+.5,
        sgn(rand(RRR)-0.5)*(0.15+rand(RRR))>
        ,1000 pigment{rgb 1} finish{diffuse 0 ambient 1}}
#declare n=n+1;
#end

Post a reply to this message

On 27 Aug 2002 17:20:44 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> pixel {
>   CENTER
>   color
>   TRANSFORMS
> }
> The intersection test of 'pixel' is same as sphere with radius==epsilon (or 
> some tolerance value)

If this is the same as sphere then why to implememnt it at all ?
It should be very simple to write macro where according to camera location,
transformation and imagesizes you can create sphere with correct finish and
location to be considered as "point" object. You can use for calculations
macros posted by me at http://news.povray.org/povray.text.scene-files/23663/

ABX

Post a reply to this message

ron_ivi wrote:
>On the subject of stars and starfields, how do you make little stars show
>up?
>
>Ideally in my mind I think (a) all stars should take up no more than one
>pixel (unless using focal blur :-)), and (b) all stars in a pixel would
>contribute to to the intensity of that pixel.
>
>
>Yeah, I know that's not now raytracing works, but it seems it's almost
>exactly like what goes on making Vista Buffers so I'm guessing it's
>implementable.
>
>Yeah, I also know this won't work with reflections, etc. but I don't see too
>many reflective enough items to show stars anyway.
>
>
>Or am I thinking about this in the wrong way?
>

I would have thought that (especially for animation) the stars should be
sampled by at least two pixels across the diameter. Since the angular
resolution of the image will be known (for a particular field of view and
linear resolution) it's trivial to work out what the diameter of a
spherical or circular star should be to cover two pixels if the distance
from the star to the camera is known.

I have made many scenes where reflection of a starfield is involved. I'm
still puzzled as to what's wrong with just placing a lot of
spheres/discs/triangles a very great distance from the camera. I find it
looks good whilst preserving speed and simplicity.

Post a reply to this message

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> How to implement it ? quite simple.

Oh, yes, very simple...why don't you explain how to project it onto all 
the different camera types? Taking camera normals into account?


> 4. reverse-project it - find point more close to A, that projected on 
> screen gives A'. i.e. P'=<101,245,380>

What is the point of this? What do you do with this reverse-projected 
point? Treat it as an intersection? Or some kind of atmospheric effect, 
like a glow?


> The intersection test of 'pixel' is same as sphere with radius==epsilon (or 
> some tolerance value)

Why even bother? The chances of a ray hitting the sphere are vanishingly 
slow, so might as well not intersect with it at all. It would just slow 
things down.

I really don't see how this is a good idea. POV is a raytracer, and this 
isn't a raytracing primitive. And why just pixels? Why not lines, 
circles, polygons, etc...and what about antialiasing? If everything is 
unantialiased, it won't be very useful.
It might make sense as a post-process filter working in image space, 
since it is really 2D drawing on top of the image.

Really, the best thing I can think of would be:
Somehow tell POV to use a higher minimum antialiasing sampling on parts 
of the image that hit a certain object (the sky object).
Use "super-bright" colors (with components > 1) for the stars, make the 
stars about the size of a pixel.
Clip colors after doing the antialiasing filter, as some kind of flag or 
render option if you prefer it that way.

The minimum supersampling makes it more likely a pixel gets hit, the 
clipping change allows the star to contribute the proper amount to the 
pixel.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in
news:chr### [at] netplexaussieorg 

>> How to implement it ? quite simple.
> Oh, yes, very simple...why don't you explain how to project it onto
> all the different camera types? Taking camera normals into account?

it will use same alghoritm as vista buffer - to project 'pixels' on 
view-plane
 
>> 4. reverse-project it - find point more close to A, that projected on
>> screen gives A'. i.e. P'=<101,245,380>
> What is the point of this? What do you do with this reverse-projected 
> point? Treat it as an intersection? Or some kind of atmospheric
> effect, like a glow?

> Why even bother? The chances of a ray hitting the sphere are
> vanishingly slow, so might as well not intersect with it at all. It
> would just slow things down.

the point of finding P' is that RAY will hit this very small sphere, 
because one of rays (for point A') will go straight throug center of sphere
 
> I really don't see how this is a good idea. POV is a raytracer, and
> this isn't a raytracing primitive. And why just pixels? Why not lines,
> circles, polygons, 

'pixels' will be very useful for stars. This name mabe isn't good. 
In short - this would be primitive simmilar to sphere, _but_ it will act 
diffrent in anti-aliasing.

While using typical sphere { } generatet with macro that will make it i.e.  
1 pixel wide - this sphere will disapear when strong AA is used.

> unantialiased, it won't be very useful.

only stars

> It might make sense as a post-process filter working in image space, 
> since it is really 2D drawing on top of the image.

the point is to draw it behind image, but You are right - this alsow can be 
drawn in post-process.
This is one of reasons while im trying to develop output file 
(.programming) that will contain many informations like i.e. Z/distance of 
point - to determinate is this point a background.
 
> Really, the best thing I can think of would be:
> Somehow tell POV to use a higher minimum antialiasing sampling on
> parts of the image that hit a certain object (the sky object).
> Use "super-bright" colors (with components > 1) for the stars, make
> the stars about the size of a pixel.
> Clip colors after doing the antialiasing filter, as some kind of flag
> or render option if you prefer it that way.

btw. after all - I think that post-processing is WRONG for starts - think 
about simple plane + statrs scene - it will render ok, but add 
  sphere { 0 10 finish { reflection .7 } pigment { color rgb 1 } }
the sphere will NOT reflect stars at it should


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

On 29 Aug 2002 02:26:43 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> it will use same alghoritm as vista buffer - to project 'pixels' on 
> view-plane

"The vista buffer can only be used with perspective and orthographic cameras"

> 'pixels' will be very useful for stars. This name mabe isn't good. 
> In short - this would be primitive simmilar to sphere, _but_ it will act 
> diffrent in anti-aliasing.

why ?

> While using typical sphere { } generatet with macro that will make it i.e.  
> 1 pixel wide - this sphere will disapear when strong AA is used.

If you make sphere one pixel size it will not disapear.

> > unantialiased, it won't be very useful.
>
> only stars

why to make primitive to only one purpose while you can for example make
spherical mapping of enviroment on sky_sphere

ABX

Post a reply to this message

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> it will use same alghoritm as vista buffer - to project 'pixels' on 
> view-plane

The vista buffer only works with 2 camera types. And with those, I don't 
think it works with camera normals or certain camera transformations.


> > Why even bother? The chances of a ray hitting the sphere are
> > vanishingly slow, so might as well not intersect with it at all. It
> > would just slow things down.
> 
> the point of finding P' is that RAY will hit this very small sphere, 
> because one of rays (for point A') will go straight throug center of sphere

If you already know the adjusted location of the point, why bother 
testing for an intersection with a tiny sphere at that location?


> btw. after all - I think that post-processing is WRONG for starts - think 
> about simple plane + statrs scene - it will render ok, but add 
>   sphere { 0 10 finish { reflection .7 } pigment { color rgb 1 } }
> the sphere will NOT reflect stars at it should

How will it reflect your "pixel" primitive? That isn't any improvement.

Adjusting the antialiasing algorithm and using high-brightness spheres 
or textures (or something like glows) seems like a better idea to me.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message