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

Post a reply to this message

Cousin Ricky wrote on 08/02/2017 14:08:
> 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
>

It seems very interesting.
I hope to see soon some examples,
Paolo

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> I have extracted some of the data fields from the Yale Bright Star
> Catalogue and converted them to SDL.

Thanks Richard! Great way to use the data. All of it impressive work.

Bob

Post a reply to this message

On 2017-02-08 09:08 AM (-4), Cousin Ricky wrote:
> 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.

POV-Ray 3.7.1 beta 3 works fine with this module.

Post a reply to this message

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

Cousin Ricky <ric### [at] yahoocom> wrote:

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

Has anyone to date used the catalogue to generate a fairly realistic spherical
sky shell or a flat image useful for uv-mapping a sphere?

I'd like to be able to incorporate this into the solar system scene I've worked
on, if I get the time to focus on it, and I have another project where I'd like
to be able to look up from a given position on earth at a certain angle at a
given date and time and see a reasonably accurate view.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Has anyone to date used the catalogue to generate a fairly realistic spherical
> sky shell or a flat image useful for uv-mapping a sphere?

Does anyone here know [how to contact] this chap?
https://www.youtube.com/watch?v=bvpEWuxBBRw

Post a reply to this message

Am 1/14/20 8:38 PM, also sprach Bald Eagle:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> 
> 
> Does anyone here know [how to contact] this chap?
> https://www.youtube.com/watch?v=bvpEWuxBBRw
> 
How many Geoff Dallimore(s) can there be?  Google thinks you want the
UK patent attorney, who looks like the guy in the thumbnail on youtube.

If you comment on the video, I'm pretty sure he'll get an email.  Or you 
can try his contact form: http://xpatent.co.uk/contact/

-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> I have extracted some of the data fields from the Yale Bright Star
> Catalogue and converted ...

Hum when it comes time to generate a view if this library,
if your library is in 3D points, not ra dec, you'll save thousands of trig
functions, and the time.

seta(1,146180222.862047,-139516389.855953,-37392435.96208,5.1);
seta(2,65647206.128445,-80763375.119065,-16312013.815614,4.7);
seta(3,135031719.98319,-145513040.060053,-31389042.949954,5.3);

times 10,000,000 = miles, and there's your distance.

I already made a bright star catalog converted to pov, in 3D points, if anyone
is interested.

Post a reply to this message

"Melody" <nomail@nomail> wrote:

> I already made a bright star catalog converted to pov, in 3D points, if anyone
> is interested.

Yes, that would be a very useful thing, indeed.
Are there comments of any sort to assist in highlighting the various
constellations, or is it just bare-bones at the moment?

I still have to wrap my head around the ephemerides and the orbital elements to
be able to position everything where it needs to be at the proper times...

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Melody" <nomail@nomail> wrote:
>
> > I already made a bright star catalog converted to pov, in 3D points, if anyone
> > is interested.
>
> Yes, that would be a very useful thing, indeed.
> Are there comments of any sort to assist in highlighting the various
> constellations, or is it just bare-bones at the moment?
>
> I still have to wrap my head around the ephemerides and the orbital elements to
> be able to position everything where it needs to be at the proper times...

Constellation boundaries points is another set of points.
Got it all in 3 languages.

POV
http://trueinnerbeing.x10host.com/charts/planetarium45.zip

JS
http://trueinnerbeing.x10host.com/charts/jtarium232full-opac.zip
http://trueinnerbeing.x10host.com/charts/jtarium.html
(ctrl-F8 titles are links to APOD)

OpenGL
http://trueinnerbeing.x10host.com/code/gamemode.zip
http://trueinnerbeing.x10host.com/code/code.html

all to grok really, is that camera matrix is "inverted"
and you just pipe everything thru the world matrix.

Post a reply to this message

POV
http://trueinnerbeing.x10host.com/planetarium45.zip

JS
http://trueinnerbeing.x10host.com/jtarium232full-opac.zip

maybe those?

well I should have checked the links, server is being finicky.
I can ftp /charts/ links, browser says not there.

Post a reply to this message

"Melody" <nomail@nomail> wrote:
> POV
> http://trueinnerbeing.x10host.com/planetarium45.zip


here's the fleet,

http://news.povray.org/povray.binaries.images/attachment/%3Cweb.485747fce7b65d90d361a0c10%40news.povray.org%3E/fleet05.
png

using the glow function for the stars, (too much glow)
and type for the color.

so you want to go star trek, then, I got many models.

Post a reply to this message

"Melody" <nomail@nomail> wrote:
> POV
> http://trueinnerbeing.x10host.com/planetarium45.zip

Yes, that worked.

When trying to run pld.pov, I get:

Parse Error: Cannot pass uninitialized identifier to non-optional LValue.
at File: megatime.inc Line: 80 Col: 17

/////////////////////////////////////////////////////////////// AutoDate
MegaPov
//#version unofficial MegaPov 1.21;
#version 3.63;

#declare Time = date("%H:%M:%S")
#declare Date = date("%B %d %Y")
////////////////////////////////////////////////////////////// TimeZone
#declare DST = 1;
#declare GMT = 0;
#declare TimeZone = -6 + DST;
#declare JulianDate = julian(val(date("%Y")),val(date("%m")),val(date("%d")));
#declare ctime = j2ctime(JulianDate);

j2datetime(JulianDate)


presumably that needs to be updated to use datetime()
http://wiki.povray.org/content/Reference:Numeric_Expressions
#local CurrentTime = datetime(now); // current date and time as a string


I will fiddle with it as time allows.
Very nice little site you have.   Lots of very interesting information.
I need whatever vitamins you take   :D

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Melody" <nomail@nomail> wrote:
> > POV
> > http://trueinnerbeing.x10host.com/planetarium45.zip
>
> Yes, that worked.
>
>
> I will fiddle with it as time allows.
> Very nice little site you have.   Lots of very interesting information.
> I need whatever vitamins you take   :D
lol

Don't know if the last one posted. Version 3.63 or Mega POV for date.
That will not run. thought you just wanted the data. to run that you need maps.

 http://trueinnerbeing.x10host.com/maps1.zip
but that link is not working yet. is there another place?
10 meg for the maps

3 sub dirs
clouds
maps
sats

Post a reply to this message

One thing you can't do without is the ability to easily sort and rewrite text
files to your needs. One of those "vitamins" that give u a boost to what you can
get done, why there is something like Poseray. Got data and can't use it? No
problem. Even without Poseray, you'd do it DIY.

Post a reply to this message

I see that Flam_Bayer.inc is not in 3D. That's used in java script, which can
generate a library view in a split sec, it doesn't have to use trig.
Could be quickly rewritten to any format you want.

ra dec is simple, just get the right order.
#local v = <cos(radians(ra))*cos(radians(dec)),
sin(radians(dec)),
sin(radians(ra))*cos(radians(dec))>;

dec * -1

if you want to y+ down output

Post a reply to this message

On 2020-01-14 9:20 PM (-4), Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> A sky sphere would use a different formula, but the math would be similar.
> 
> Has anyone to date used the catalogue to generate a fairly realistic spherical
> sky shell or a flat image useful for uv-mapping a sphere?
> 
> I'd like to be able to incorporate this into the solar system scene I've worked
> on, if I get the time to focus on it, and I have another project where I'd like
> to be able to look up from a given position on earth at a certain angle at a
> given date and time and see a reasonably accurate view.

I had been thinking about this around the beginning of the year, but the 
more I pondered, the more complications there seemed to consider.  How 
bright?  How to deal with dynamic range?  What resolution?  In general, 
how would I make one tool that would apply across various scales and 
lighting conditions?  (Similar considerations are why I haven't put 
beverage materials in the CoffeeMug include file.)

I just punted in despair, figuring each project might require a somewhat 
specialized solution, but I didn't notice the new thread activity until now.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> I just punted in despair, figuring each project might require a somewhat
> specialized solution, but I didn't notice the new thread activity until now.

Well, I think that something like the sunpos include file is mostly what I'm
looking for.

Given a longitude and latitude, a date, and an hour of the day, create a
celestial sphere.  Make it so that no matter what, each star is at least 1 pixel
wide.

I'm primarily interested in the geometry - the proper alignment.

"Look - that notch in that rock at Stonehenge really DOES line up with Rigel at
midnight on the winter solstice..."

------------------------


Aside from that, you could add some sort of mechanism that allows the _USER_ to
tweak the catalogue.

So - whatever array you use to do the basic stuff, and then maybe a user array
that modifies the values or sets some flags before rendering.


That way someone could highlight a star with an object{} (torus, [under]line,
arrow, etc), put a text label, change the apparent size, replace the simple
sphere for the star with a fancy object{}, or apply a multiplier to the star's
brightness/color.

I'd probably start with like 10 stars or a few constellations, and give it a
whirl, and then get some user feedback before doing anything bigger.

Post a reply to this message

Le 08/02/2017 à 14:08, Cousin Ricky a écrit :
> 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.
> 
Thanks for that, and ulterior versions (1.1.1).

I currently have a strange interest on constellations, is there a way to
have them nicely drawn as the sample for Orion ?


I tried to have a look at the include files, and the sample scene, but
I'm afraid the data to connect the stars as per the constellation is
missing and hard coded for orion in the sample.

Post a reply to this message

On 2020-07-16 12:36 PM (-4), Le_Forgeron wrote:
> Le 08/02/2017 à 14:08, Cousin Ricky a écrit :
> 
> I currently have a strange interest on constellations, is there a way to
> have them nicely drawn as the sample for Orion ?

A general procedure would not be straightforward.  I chose Orion 
specifically because it is on the celestial equator, and would not 
require a fancy map projection.  I had not considered map projection 
within the scope of the module, as different persons would have 
different needs.

> I tried to have a look at the include files, and the sample scene, but
> I'm afraid the data to connect the stars as per the constellation is
> missing and hard coded for orion in the sample.

There is no official set of constellation lines.  It is up to the 
imagination of the person drawing the chart.

Post a reply to this message