|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|