Exporting firmament to game engine

addition: The best way would be being able to export images of the dome to use it as a sky dome/box from within a game engine. If it is possible to do this automatically while both programs are running, it would be perfect.

How exactly will be using starry sky in game engine - just like texture or no? If just like texture, then you need create a "big screenshot" and use it. If not then you need write renderer for starry sky (and here need C++).

If you need static skybox images, (5 or 6 cube faces), you should be able to write a script that freezes time, and walks through the 5-6 views and stores images which you may just have to crop into squares (which can likewise be scripted). For a moving skydome/box, it's indeed much more difficult. If your GE happens to be Unity, I'd be interested to follow!

I will need both version. At first, I just need a texture for the sky box in the cry engine. Therefore I need 5 images (perfectly) attached to each other. The first image should exactly end, where the second begins.
What do you suggest me to do to achieve this?

And second, I will need the position data of the sun, the moon and a few planets on specific locations on the earth in specific past times. What class handles this information/ Which interface of your API should I use, to get these informations?

Later on, I have to reload all these data with given place and time during runtime of the cry engine application. What do you suggest? I consider writing a module for Stellarium, which uses sockets to communicate with the other application. Is there a smarter solution to reach my goal or what would you do?

Thanks so much for your support!

For the first task, have a look at the scripting language, some examples exist. Something like "stop time, set perspective projection, set 90° vertical field-of-view, look east, snap, look north, snap, look west, snap, look south, snap, look up, snap" with constant filenames should be reasonably simple to develop. Depending on whether the skybox should show or hide the landscape horizon, you will also obviously switch that and fog before the first snap, also think about labels, etc., also switch away the bottom menu line. Image cropping to 1:1 can then be scripted from the shell with e.g. ImageMagick. From Unity I know you have to load the skybox textures with the "clamp" setting to hide the seams. There may be a problem with the dynamic eye adaptation, though, which simulates brightness differences when sun or moon (or another bright source) is in the view. It should be switchable, but I am not sure.

If you just need planet positions (numerically, highly accurate), you can also find them from NASA's Horizons website, I am pretty sure that's also scriptable with a request packed in an URL or such.

The final task will be much harder, but a plugin that provides an online skybox image generation functionality (for several games engines? [hint, hint]) would be simply superb! Unfortunately I have no idea how to link two programs that could share textures as they are created on the graphics card, so they may at least have to be buffered in system memory. But such a program could also be enhanced to become a remote control application (so that GUI panels could be shown on another screen or such, nice for projections). If you intend to go that way, see what Qt5 will offer, Stellarium will sooner or later have to upgrade again!

HTH, Georg

Thanks for the help again.

Since I need the data of e.g. Sirius my investigation showed that NASA Horizons only provides planetary (and more) data of our solar system and not of other stars etc. and is therefore not useful for this task.

So, there is no easy chance for me to get the exact data into the game engine. I will at first start implementing the screenshot thing.

Hi!

You may try to visualize the Yale Bright Star Catalog (all naked-eye stars, and some more, total about 9000; available online) as particle system on a sphere that surrounds the camera. That seems reasonably fast and has no distortion or tiling artifacts. Of course, things like stellar proper motion & precession must be implemented, and orientation of the sphere according to latitude and sidereal time. It just depends what you want to do. The fastest development certainly should be the 5 static skybox tiles.

It turned out that the 5 static skybox tiles are not accurate enough and I have to visualize the firmament exporting the data of stellarium or using the Yale Bright Star Catalog.

"Of course, things like stellar proper motion & precession must be implemented"

I was wondering, if I can query the Yale Bright Start Catalog (or the SIMBAD database stellarium is using?) itself for a specific time. In our scientific application, the time changes only on demand rather than changing in real time, so querying the catalog everytime the user wants to change the time is ok. This seems simpler to me than calculating it on my own.

I can´t find any sources explaning how to use the Yale Bright Star Catalog. Google doesn´t help me much with this. Thus, I could not find out how to query it and if it´s possible to query positions for a specific date or if I have to calculate the positions based on their velocity.

Any hints or ideas how to go on with this? Your help so far is highly appreciated!

Stellarium uses several catalogs, the most important being Hipparcos. SIMBAD can be queried for specific object queries, but not for the single tiny dimmer stars.

The BSC just lists the 9000 or so brightest (including all naked-eye) stars with coordinates, proper motions, spectral class etc. I recommended it as it seems you want to show naked-eye stars in a game engine, maybe in some cultural heritage or archaeo-astronomical visualisation application, so the BSC should have all the stars you ever need.

I don't know your background, maybe you need some intro in astronomical coordinate systems, astro navigation, some other general concepts? Maybe attend some public observatory or local planetarium course? Use any textbook on astro computing (e.g. Meeus: Astronomical Algorithms (but avoid the German edition, there are too many errors in the numbers!), Montenbruck&Pfleger or books by Peter Duffet-Smith (sp?; don't have them, but they seem popular in the US)).

It depends what you regard easier, a system requiring online queries of databases about objects from a static catalog, or a standalone script of ~250 lines (?) that do the computing, plus 9000 lines of text for the star catalog.

HTH, G.

I don´t know, if I got you right. There are online databases which I can utilize for the position on a specific time? I thought if I use an online catalog, I need to compute the positions from scratch anyway, because it is the same catalog that I can download. Correct me if i am wrong.

Your assumptions are right, the purpose is for aechaeo-astronomical visualization. I don´t have any background in astronomical coordinate system or algorithms, but I have a Computer Science background. My time provided to implement the solution is short. Therefore my thought was, that it is way too complicated for me to compute the correct position at the specific time from scratch.

Therefore the only solution for me seems to be the following:
Find the correct class/method in stellarium, where the final position of the stars are set on the sphere (Alt/Az) and sending this data to my other program (via network, saving files on HDD and reading them from the other program or something like that as a prototype). All stars have the same texture as far as I can see, so I can re-visualize the stars in the engine from the position data. I don´t need specific astronomical knowledge to achieve this last approach, is that right? I have the bad feeling that I´m missing something fundamentally.

Maybe all of my approaches are too time-consuming to do on my own. If you can give me a hint to estimate the amount of work necessary for which approach, that would be great. Maybe it´s simply not possible to do this in less than 150h work. Than we have to reconsider the basic approach or resign.

Hmmm, sounds like competition or collaboration. PM me please with more exact details of what this system should be able to demonstrate.

Georg Zotti
Gesellschaft für Archäoastronomie