On 2017-02-08 08:08 AM (-5), Cousin Ricky wrote:
> I have extracted some of the data fields from the Yale Bright Star
> Catalogue and converted them to SDL. [snip]
>
>
http://lib.povray.org/searchcollection/index2.php?objectName=BrightStar5&contributorTag=Cousin%20Ricky

I have uploaded BrightStar5 version 1.1, which has indexes on the data 
arrays.  The seek macros run *much* faster now.

Post a reply to this message

On 2/8/2017 8:08 AM, Cousin Ricky wrote:
> I have extracted some of the data fields from the Yale Bright Star 
> Catalogue and converted them to SDL.  This catalog contains all 
> nighttime stars of magnitude 6.5 and brighter (roughly all nighttime 
> stars visible to the naked eye), plus a few dimmer ones.  The 
> BrightStar5 module includes more data fields than the include file 
> Rarius published a while back, including catalog designations and color 
> data.  Macros are included for star coloration and Bayer designation 
> labels.  You can also seek individual stars by Bayer, Draper, Flamsteed, 
> or SAO designations.
> 
> Rarius stated that the catalog is in the public domain.  I could not 
> determine the intellectual property status from the published sources, 
> and in the process of trying to find out, I ended up having a very nice 
> phone conversation with one of the authors, Dr. Warren!
> 
> The 5th edition of the catalog, as it stands, is in a preliminary state. 
>   (The primary author died in 2007.)  There is no projected date for 
> final publication.
> 
> POV-Ray 3.7.1 beta 2 will crash hard with this module.  Think Bayer 
> designations, and if you've been following p.beta-test, you'll know 
> exactly why it crashes.  Some of the 3.7.1 alphas (including some 2015 
> vintages) also crashed, but 3.7.0 works fine.  The latest master passes, 
> so everything should be fine when beta 3 is released.
> 
>
http://lib.povray.org/searchcollection/index2.php?objectName=BrightStar5&contributorTag=Cousin%20Ricky

> 

The fuzzy circles don't look so great. I don't know if anything can be 
done to improve them however. In video games, stars are often reduced to 
1 pixel. But I don't think in POVray there's an easy way to make a star 
exactly 1 pixel big. Maybe with some trigonometry?


Mike

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:
But I don't think in POVray there's an easy way to make a star
> exactly 1 pixel big. Maybe with some trigonometry?

I worked that out obtain a constant-apparent-width cylinder for a bounding box,
and a Dupin cyclide for orbital trajectories.
Obtaining a constant 1-pixel width is pretty trivial with the orthographic
camera, since with the default camera, IIRC, 1 POV-unit = 1 pixel.

Post a reply to this message

Le 10/02/2018 à 04:23, Bald Eagle a écrit :
> Mike Horvath <mik### [at] gmailcom> wrote:
> But I don't think in POVray there's an easy way to make a star
>> exactly 1 pixel big. Maybe with some trigonometry?
> 
> I worked that out obtain a constant-apparent-width cylinder for a bounding box,
> and a Dupin cyclide for orbital trajectories.
> Obtaining a constant 1-pixel width is pretty trivial with the orthographic
> camera, since with the default camera, IIRC, 1 POV-unit = 1 pixel.

not really.
Unless your default camera is
...
  up image_height*y
  right image_width*x
...
but that's not the camera you get from

camera{ orthographic }

|| up: 0.000, 1.000, 0.000
|| right: 1.330, 0.000, 0.000
|| location: 0.000, 0.000, 0.000
|| direction: 0.000, 0.000, 1.000

Post a reply to this message

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

> not really.
> Unless your default camera is
> ...
>   up image_height*y
>   right image_width*x
> ...
> but that's not the camera you get from
>
> camera{ orthographic }
>
> || up: 0.000, 1.000, 0.000
> || right: 1.330, 0.000, 0.000
> || location: 0.000, 0.000, 0.000
> || direction: 0.000, 0.000, 1.000

Well, then I guess I didn't remember correctly  ;)

I vaguely recalled this discussion:
http://news.povray.org/povray.advanced-users/thread/%3Cweb.5845a06cc97737fcc437ac910%40news.povray.org%3E/

So modifying that so Pixel "size" is described in POV-units, then we could have

#macro Zoom (PixelSize)
camera {
 orthographic
 location <0, 0, -PixelSize>
 look_at  <0, 0, 0>
 right (x*image_width )*PixelSize
 up    (y*image_height)*PixelSize
 }
#end


(I haven't entirely determined what the best camera-to-lookAt distance is to
avoid some weird things happening)

Post a reply to this message

I kinda wish there were a POV-Ray object that would be guaranteed to 
always be 1 pixel big.

Mike



On 2/10/2018 5:14 PM, Bald Eagle wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
>> not really.
>> Unless your default camera is
>> ...
>>    up image_height*y
>>    right image_width*x
>> ...
>> but that's not the camera you get from
>>
>> camera{ orthographic }
>>
>> || up: 0.000, 1.000, 0.000
>> || right: 1.330, 0.000, 0.000
>> || location: 0.000, 0.000, 0.000
>> || direction: 0.000, 0.000, 1.000
> 
> Well, then I guess I didn't remember correctly  ;)
> 
> I vaguely recalled this discussion:
>
http://news.povray.org/povray.advanced-users/thread/%3Cweb.5845a06cc97737fcc437ac910%40news.povray.org%3E/
> 
> So modifying that so Pixel "size" is described in POV-units, then we could have
> 
> #macro Zoom (PixelSize)
> camera {
>   orthographic
>   location <0, 0, -PixelSize>
>   look_at  <0, 0, 0>
>   right (x*image_width )*PixelSize
>   up    (y*image_height)*PixelSize
>   }
> #end
> 
> 
> (I haven't entirely determined what the best camera-to-lookAt distance is to
> avoid some weird things happening)
> 
> 
> 
>

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:
> I kinda wish there were a POV-Ray object that would be guaranteed to
> always be 1 pixel big.

I snipped this out of something I wrote last April, and haven't tested it out
tonight in a scene all by itself, but it gives you the broad strokes.


Location is the camera location.
(So do
#declare Location = <0, 0, -10>;
camera { ... location Location  ...}
)
Vector is the center of the object you want to be 1 pixel.
The macro returns the radius of a sphere/cylinder so it is a pixel wide.
you can work the rest out from there.

// Minimum radius for solid visibility is (Z/image_width)*Aspect
// Minimum radius for threshold visibility is (Z/image_width)

#macro MinRad (Vector)
   #local Aspect = image_width/image_height;
   #local Dist = vlength (Vector-Location);
   #local M = (0.5*Aspect)/tan(radians(Angle/2));
   #local ZA = Dist/M;
   #local Rad = (ZA/image_width)*Aspect;
   Rad
#end // end macro MinRad

Post a reply to this message

On 2/10/2018 9:44 PM, Bald Eagle wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> I kinda wish there were a POV-Ray object that would be guaranteed to
>> always be 1 pixel big.
> 
> I snipped this out of something I wrote last April, and haven't tested it out
> tonight in a scene all by itself, but it gives you the broad strokes.
> 
> 
> Location is the camera location.
> (So do
> #declare Location = <0, 0, -10>;
> camera { ... location Location  ...}
> )
> Vector is the center of the object you want to be 1 pixel.
> The macro returns the radius of a sphere/cylinder so it is a pixel wide.
> you can work the rest out from there.
> 
> // Minimum radius for solid visibility is (Z/image_width)*Aspect
> // Minimum radius for threshold visibility is (Z/image_width)
> 
> #macro MinRad (Vector)
>     #local Aspect = image_width/image_height;
>     #local Dist = vlength (Vector-Location);
>     #local M = (0.5*Aspect)/tan(radians(Angle/2));
>     #local ZA = Dist/M;
>     #local Rad = (ZA/image_width)*Aspect;
>     Rad
> #end // end macro MinRad
> 
> 

Interesting. Would it work better with a cube oriented to face the 
camera? I suppose the perspective distortion might make the cubes look 
weird if they're toward the edges of the image. But spheres would end up 
looking distorted too.


Mike

Post a reply to this message

On 2/10/2018 10:22 PM, Mike Horvath wrote:
> Interesting. Would it work better with a cube oriented to face the 
> camera? I suppose the perspective distortion might make the cubes look 
> weird if they're toward the edges of the image. But spheres would end up 
> looking distorted too.
> 
> 
> Mike
> 

E.g. a true "one-pixel" POV-Ray object would not be distorted by 
perspective, which I think is realistic since stars are so distant and 
tiny that visual perspective has no effect on their perceived 
dimensions/brightness.


Mike

Post a reply to this message

On 2018-02-09 10:28 PM (-4), Mike Horvath wrote:
> The fuzzy circles don't look so great. I don't know if anything can be
> done to improve them however. In video games, stars are often reduced to
> 1 pixel. But I don't think in POVray there's an easy way to make a star
> exactly 1 pixel big. Maybe with some trigonometry?

Yes, of course they can be improved!  The purpose of the demo was merely 
to demonstrate how to use the data.  I consider attempting a realistic 
sky beyond the scope of the demo.

This works if you are representing the stars as actual objects:

----------[BEGIN CODE]----------
#version 3.7;

global_settings { assumed_gamma 1 }

#declare Cam_angle = 60;
#declare RSky = 10000; // arbitrary distance to the stars
#declare R = RSky * tan (radians (Cam_angle / 2)) / image_width;

camera
{ location 1.64 * y
   look_at <0.5, 2.64, 2.5>
   angle Cam_angle
}

plane { y, 0 pigment { checker } }

#include "brightstar5.inc"

#default { finish { ambient 0 diffuse 0 emission 1 } }
union
{ #for (I, 0, BSC5_N - 1)
     #if (BSC5_Data [I] [BSC5_HD] != BSC5_NO_DATA)
       sphere
       { RSky * y, R
         pigment { rgb BSC5_fn_Brightness (BSC5_Data [I] [BSC5_MAG], 0) }
         rotate
         < 90 - BSC5_Data [I] [BSC5_DEC],
           -15 * BSC5_Data [I] [BSC5_RA],
           0
         >
       }
     #end
   #end
   rotate <0, 120, 71.7>
}
-----------[END CODE]-----------

I disregarded image_height in the formula because the POV-Ray camera 
considers only image_width for its field angle.  Also note that if the 
camera is significantly distant from the origin, you will need to make 
appropriate adjustments.

Note that with a diameter of 1 pixel, an adaptive anti-aliasing trace 
will miss quite a few stars.  To avoid this, you'll need to either use 
+A0.0 (slow), or use a diameter slightly larger than 1 pixel (times 
sqrt(2) should do).  As far as using boxes instead of spheres, I don't 
think it would be worth the effort.

If Orion looks strangely oriented in the above code, it's because I'm 
stargazing from the northeast Caribbean.

Yes, there is some distortion as you move away from the center of the 
image, as explained in the knowledge base:
   http://wiki.povray.org/content/Knowledgebase:Misconceptions#Topic_3

The orthographic camera will preserve the star shape, but the star 
positions will still be distorted, for the reason you learned in 4th 
grade geography.  Also, the orthographic camera would be quite awkward 
to use if you are rendering, say, a landscape.

A sky sphere would use a different formula, but the math would be similar.

Post a reply to this message