Celestia Forums

Is it possible to align a dsc nebula mesh to a star or to another nebula?

I made a cmod model of a "line", made a dsc nebula file and I want to connect two stars. It works for one star but I have to align somehow the "line" mesh to reach the other star.

Can it be done?

Yes.

I've done it by specifying the appropriate xyz coordinates inside the CMOD mesh itself. I had to write a (Fortran) program to translate RA and Dec into Celestia's internal xyz coordinates, though, which is not at all straight forward. It's been a while since I've looked at it, but I know that it'd take some work to make it general purpose enough for someone else to use. It's written to be compiled by gfortran and run under Cygwin.

However, as you might already know, the easiest way to draw lines between stars is to create a replacement for Celestia's own asterisms.dat. It contains lists of star names, so no xyz or RA,Dec values have to be calculated. You can specify the name and location of your own asterisms file in Celestia's configuration file (celestia.cfg) which is in Celestia's home directory. I dunno if you can use that method to specify several different files.

Thanks for your reply! You mentioned it a year ago and I made a special asterisms file then to create an interstellar route. Unfortunately Celestia 1.7 64 bit limited the visibility of asterisms to a few light years, so it is useless now.

Is there a general equation to make the conversion?

If I correctly understand the problem I need the position (RA, Dec, Distance) of star "A" relative to Earth, and I need the position of star "B" relative to Earth to establish the Axis and Angle parameters of the dsc file which connects them with a mesh?

Or the cmod parameters are different from the Axis/Angle parameters?

Excel tables can make the calculations?

Sorry, I can't help with that.

As I mentioned, I wrote a command-line Fortran program to do most of the hard work. I've attached a Zip containing a generic version. I think the executable will work under most 64 bit versions of Windows. Essentially, you provide it with a .CSV containing RA,Dec and Distances of the endpoints plus the desired color for each of the routes that you want to see. It creates a .CMOD and .DSC for that set of routes.

See the included routes_readme.txt for details.

(1.7MB expands to 4.7MB)

Here are a couple of screengrabs showing the results of the test.csv which is included.

Here's a split screen view showing some inter-star routes and inter-galactic routes as defined in test.csv



Here's a closeup of routes leaving Alpha Centauri. Routes are not drawn if the viewpoint is within about 1/2 LY of the target star.

Selden, whoa, thanks, you are a genius!

You provide the best and brightest replies and solutions!



Added after 26 minutes 58 seconds:
(Sorry for being over the top. )

Here's a rather different approach, which I think might be a lot more convenient, since it's rather small and should be usable by anyone who has a copy of Celestia v1.6.1 or later. It should work under all operating systems, although I've only verified it under Windows 7.

nroutes.celx, provided below, uses Celestia itself to create the route .cmod, so no additional software is needed: neither a Fortran compiler nor Cygwin runtime libraries, for example.

https://www.classe.cornell.edu/~seb/celestia/files/nroutes.zip (9KB expands to 15KB)

Like routes.f, nroutes.celx reads a .csv file to define the routes, but instead of having to calculate the RA, Dec and distances yourself, you specify object names which are known to Celestia and the script extracts their coordinates from Celestia to create the .cmod file.

For example, a line in the the .csv file specifying a route between Alpha Centauri and Sirius could look like this:

ALF Cen,Sirius,1.0,1.0,0.0, alpha cen to sirius

The names can be any of the synonyms known to Celestia for any of its objects.

A tradeoff is that the structure of the .csv is much more restrictive, and the script does not try to verify that you've entered the correct names or used the right line format. Either the script or Celestia will crash if the data is too badly messed up. In principle a lot of error detection could be added, but I just didn't feel like spending the time on it. Maybe some future version could do that. Or maybe someone else could make the appropriate changes to the script. Anyhow, see the accompanying readme file for details.

Thanks, I use your previous program, I made a lot of routes already.

Added after 7 minutes 33 seconds:
I was able to create a 1 billion (1000000000) light years long route with pinpoint accuracy.

Using one doesn't mean you can't use the other. You can have several different CMODs (Nebula objects) for different sets of routes, for example.

Added after 9 minutes 38 seconds:
The accuracy is only double precision (64 bits) floating point relative to the position of the Sun. If you define routes between stars that are located in a distant galaxy, for example, the placement of the endpoints won't be as accurate as for the endpoints of routes between stars in our own neighborhood. On the other hand, that same limitation applies to the positions defined in STC and DSC files, although Celestia does use 128 bits for its internal calculations. I suspect the two will combine to make the endpoints go directly to the distant Star positions. I'm not sure how the limited precision used internally by graphics cards affects the endpoint positions of the CMOD model, though.

Yes, you are right, but I just love the new toy...so I don't have time for the second one.

Added after 4 minutes 6 seconds:
I was able to connect Sol with a fictional star in the Pegasus DI galaxy, and it seemed accurate enough.

Added after 3 minutes 41 seconds:
I used a small nebula dsc file at the end of the one billion lightyears line, and it was also OK, the line connected nicely.

Oh, the Fortran program does have a limitation that I didn't bother to mention: it's limited to 10,000 routes in a single model. I hope that won't be a problem.

The CELX script is limited by the amount of memory it can allocate dynamically as it reads in the routes and builds the tables of colors and locations. I dunno what that limit might be.