Project Orbiter Galaxy

[jedidia]

EDIT: WHOO! It worked!!! I set my options for CPU texture generation and it worked! All the textures look good! Now I can fully enjoy this awesome addon!

err... I hate to break it to you, but you could do that already before. The CPU generation always worked flawlessly, it's just an awfull lot slower.

The black textures on rocky planets you are reporting are a known issue on some GPUs, and can be fixed by adding these two lines at the end of your config file (leave no empty lines between!):

//Fix for black textures of planets without atmospheres (set to 1 if you have black textures)
1

@Axel: I think I found your problem! am I right to assume that you are running orbiter in fullscreen? that always was a problem under windows 7, and the problem seems to have worsened now that I switched to directX, it's producing a CTD for me too (probably now the directX devices of Orbiter and Orbiter Galaxy engage in a standoff when running fullscreen. The whole thing is quite a hack, after all). If you are running fullscreen, please switch to windowed mode, and you should be fine!

 

[Axel]

@jedidia
Im your man, your beta-tester :lol:.
Jep you are right, i normally use orbiter in fullscreen. Now in windowed mode it works!!! Thank you! But im using not windows7, i have winXP32, directx9c. ATI 4870 with catalyst.

 

[jedidia]

Thanks a lot, that means that Fullscreen is now off-limits for all windows versions, due to the switch to directX.

 

[Linguofreak]

It is possible, but you wouldn't be able to export textures. The switch to DirectX happened because of conflicts between Artlavs texture generator and Orbiter Galaxy, after all...

I've got an NVidia card on my laptop here. Wasn't the problem primarily with ATI's?

I assumed that, since this is an orbiter add-on, you'd expect directX compatibility anyways, since Orbiter is directX, after all.

Well, I suppose that's true for operating on Windows. Orbiter doesn't really work on Linux/Wine without OGLAClient, though, so on this machine Orbiter is OpenGL.

Another thing would be if you want to use only the standalone app, but for astronomical purposes there are way better aplications out there, and I don't quite see what else you'd want to use it for.

So far I've only used the standalone app, actually. IIRC I was fairly busy around the time you released the plugin, and the combination of a means of generating random stars in the parts of the galaxy far away from the sun, using real stars near the sun, and the possibility of having my FTL charts implemented for links means that I don't have to write a program with all three features myself. The possibility of exploring things in Orbiter is just a (big!) bonus.

Then again, there's the option of running it on OpenGL WITH texture export, but with the status display disabled... that would work. I can put that in as an option for the next patch!

By the way, do you still have your FTL tables around? I'm working on implementing the jumppoint system, I could some data (made up a quick dirty table myself, but with very unsatisfying results...).

I do.

Essentially, you have five mass ranges:

Class     Mass range     (Very) Approximate Spectral Class
5          0.04-0.26        Low M
4          0.24-0.61        High M
3          0.59-0.93        K
2          0.91-1.23        G
1          1.21-1.73        F
0          1.71-4.23        A

To determine if a link exists between two stars, you find the two mass classes and make a lookup in this table:

	0	1	2	3	4	5
0	26.5000	13.9130	9.2401	7.0091	5.2030	3.7487
1		16.0000	10.6261	8.0605	5.9834	4.3110
2			12.2200	9.2696	6.8809	4.9577
3				10.6600	7.9130	5.7013
4					9.1000	6.5565
5						7.5400

If the distance (in lightyears) between the two stars is within 15 percent of the distance found in the table, a connection exists, otherwise, no connection exists.

You don't have to implement the following (EDIT: Well, technically, you don't have to implement any of it, since it's your program), since IIRC you're just using only one member of a binary to simplify things:

Close binaries (I haven't quite determined the threshold, but I'm going to say those orbiting closer than 3 (maybe 5) AU of each other qualify as "close" for the purposes of my link equations), get counted as a single star and get checked both for the mass of each star and the combined mass of the binary. Other binaries are counted as separate stars.

 

[jedidia]

wow, you just made post 666 in this thread! :headbang:

I've got an NVidia card on my laptop here. Wasn't the problem primarily with ATI's?

Nope, the problem is Orbiter Galaxy and Artlavs texture generator banging each others head about the context when both run in OpenGL. It's still possible to run them parallel, and I can even do a makeshift status display that just updates everytime a texture has finished, so the drawback won't be too hard. I just can't claim the surface while the generator is rendering on the GPU, or it'll render somewhere out in the green... Then again, unless you have a pretty good card (for laptop standards, anyways), you'll have to export via CPU, in which case it doesn't really matter.

I still have to test this with OGLA, though... I hope they don't start banging each others heads too.

IIRC I was fairly busy around the time you released the plugin, and the combination of a means of generating random stars in the parts of the galaxy far away from the sun, using real stars near the sun, and the possibility of having my FTL charts implemented for links means that I don't have to write a program with all three features myself.

So what are you using it for? Authoring? role-playing scenarios?

I do.

Great, thanks. I'll put them in and see what comes out... I had the basic concept still in mind, so I've already written a parser for a fully modifiable table. It will be possible to define mass classes, tolerances and ranges for each class, so you can experiment around with them if you want to.

And you could make up some numbers for the larger classes. Orbiter Galaxy goes up to 120...

 

[ghostrunner01]

err... I hate to break it to you, but you could do that already before. The CPU generation always worked flawlessly, it's just an awfull lot slower.

The black textures on rocky planets you are reporting are a known issue on some GPUs, and can be fixed by adding these two lines at the end of your config file (leave no empty lines between!):

//Fix for black textures of planets without atmospheres (set to 1 if you have black textures)
1

!

Um, no nothing worked. I went through and tried every single option in that config file a few days ago with no new results. After the update CPU generation has worked but GPU still doesn't even with the fix on 1.

 

[donatelo200]

Everything works for me now. Generating systems with GPU takes 5 minutes.

 

[jedidia]

Um, no nothing worked. I went through and tried every single option in that config file a few days ago with no new results.

That is most peculiar... when set to CPU, there never should have been a context collision. Thanks for the info anyways, maybe I'll get behind what was going on there some day.

After the update CPU generation has worked but GPU still doesn't even with the fix on 1.

Just as interesting. It seems that there are multiple problems that cause rocky planets to fail, but as I said in the patch description, GPU texture generation is still far from being ironed out.

Everything works for me now. Generating systems with GPU takes 5 minutes.

If you're going with the default texture settings, that seems to indicate that your GPU still has to fall back on the main processor, which wouldn't be a surprise since it reported errors. I'll ask Artlav to pass a flag to the update callback so users get better feedback on wheather or not their card is actually working or wheather it is just relegating the job to the CPU. Until then, you can measure times for exporting the same system on CPU and GPU to see if your card actually works.

Anyways, it's nice to see it working again.

 

[Linguofreak]

So what are you using it for? Authoring? role-playing scenarios?

World building with an ill-defined goal. It might go into a book someday, but most of the writing I do doesn't get beyond a few pages.

 

[jedidia]

If the distance (in lightyears) between the two stars is within 15 percent of the distance found in the table, a connection exists, otherwise, no connection exists.

just wondering, is this +- 15% or +- 7.5%?

---------- Post added at 07:22 PM ---------- Previous post was at 11:23 AM ----------

I have a first implementation of your table going, with +- 15% tolerance on the distance. Seems to give quite nice results, but reaching a certain star by manual route planing is hell with the heat turned up!

Let's put together some functions to search for a route. That will be a pretty interesting challenge, a nice change to the boring compilation of the chemtable...

 

[Wishbone]

What do you mean by a route? Are you looking for the shortest route from one star to another (a straight line is the shortest route) or for something completely different?

 

[Linguofreak]

just wondering, is this +- 15% or +- 7.5%?

+- 15%.

I have a first implementation of your table going, with +- 15% tolerance on the distance. Seems to give quite nice results, but reaching a certain star by manual route planing is hell with the heat turned up!

Let's put together some functions to search for a route. That will be a pretty interesting challenge, a nice change to the boring compilation of the chemtable...

One thing that I've been doing is exporting the data to yEd format. That allows you to make a nice graph of things that might be a bit less tangled. (Though it tends to get more tangled the more stars you involve).

---------- Post added at 15:36 ---------- Previous post was at 15:26 ----------

What do you mean by a route? Are you looking for the shortest route from one star to another (a straight line is the shortest route) or for something completely different?

No. We're creating a graph out of a bunch of stars based on masses and distances, and then looking for the shortest route between two stars on that graph. By the rules we're using to create the graph, for instance, the shortest route between the Sun and Alpha Centauri goes through Sirius, which is hardly the shortest route when just going through space normally.

 

[jedidia]

What do you mean by a route? Are you looking for the shortest route from one star to another (a straight line is the shortest route) or for something completely different?

Completely different. It's like a traveling salesman problem, just that you are only allowed to use a certain number of the available points and the used points must be a certain distance apart that varies depending on the points themelfes... :facepalm:

I'm not quite sure yet how to solve it. Going brute force and creating a tree branching with all possible combinations until you find one is one possibility, but the trees might get humongous. Not to mention that it'll eat a lot of computing power.

 

[Columbia42]

Forgive me if the issue has already been resolved in a previous post but I don't really see the point of the FTL charts.

 

[Wishbone]

Naah, the TSP is finding the cheapest route that visits all the stars to sell your warez, right now you're talking about pathfinding - a single vertex-to-vertex route. A* algorithm is reasonably good for that.

 

[jedidia]

Forgive me if the issue has already been resolved in a previous post but I don't really see the point of the FTL charts.

They're the baseline for the jumppoint system that's going to be implemented in version 0.7, so nothing that is of immediate concern or use to you

Naah, the TSP is finding the cheapest route that visits all the stars to sell your warez, right now you're talking about pathfinding - a single vertex-to-vertex route. A* algorithm is reasonably good for that.

Yeah, it's not really a TSP. The similarity to a pathfinding problem is large, but not quite the same, as the connection between the vertices changes with every vertice you advance, i.e. you can't use a "best-first" aproach (at least not on short distances, the problem gets somewhat different on long distances, since the nodes are not even known and the generator has to generate them first) because there's not really a way to tell which the best is, as the distance between the nodes is only relevant insofar as it shows wheather or not there is actually a connection between them. A route of two jumps that carry you over hundreds of lightyears is more efficient than a route of 3 jumps that take you to the target on a straight path.

After thinking about it some more, I think it will be most efficient (for short distances) to have a branching model progressing simultaniously from the origin and from the target, searching for matches of connectible vertices in the results. As soon as there is a match found in the branch originating at the point of origin and the branch originating at the target, the task is finished. I won't even run into a halting problem since the number of vertices in current memory is limited (to a maximum of 27'000), so as soon as there are none left that haven't been incorporated into a branch, the short distance solution has failed.

For the long distance solution, The key should be finding nodes that allow for long jumps. The locations where they can potentially be located is more or less limited, but since those locations and their nodes all have to be generated first it'll still be a whole lot of number crunching. Reducing the tolerance on the distances would lead to a cmore closely defined search area, but would also make it less probable to find an actual connection. Calculating long distance jumps will be a rather costly undertaking processor-wise any way you turn it, For higher mass-classes there might be millions of nodes that have to be created and checked.

Once a convienient long jump has been found, reaching those from the origin and the target will be done with the short range solution, or, if those nodes are still too far away from those points, with another long-jump solution in between, that will at least be a lot more limited in area.

The short-range solution promises to find the most efficient route (one of thos that require the least jumps) pretty fast, but I have no idea how the long-range solution will perform...

 

[Wishbone]

Let me clarify a bit: does the graph remain the same as the player moves from vertex to vertex? If so, we are in the realm of A-Star algorithms, plenty of work has been put into the algorithmic side of graph traversal, no need to invent anything now. The complexity is bearable, although the algorithm itself is not parallelizable (at least I haven't been able to). My next questions are: what is the distribution of degrees of vertices, and is simple Euclidean distance a good approximation of the distance/cost between two vertices? A-Star don't tax memory much...

P.S. How many nodes per graph are supposed to be there?

 

[jedidia]

A* is not really aplyable (at least as I understand it... I have no expierience whatsoever with pathfinding) because there is no cost for distance between the nodes (jumps are immediate, no matter the distance). The cost is in the number of nodes neccessary to complete the journey. With my current short range solution, whichever path gets found first is also the least costly, so it doesn't seem to be a bad way to do it. I have no idea how my long-range pathfinding will perform, however. There the problem is that I don't even have any nodes to start with, and I have to calculate the position where it's most likely that such a node might happen to be, generate the location, rinse and repeat if there happened to be no such node there...

 

[Wishbone]

Then, simple BFS is your solution...

 

[jedidia]

Yeah, that's basically what I have now (after googling the term... hell, I'm such a n00b), just that starting at the point of origin and at the target simultaniously should lead to fewer iterations in most cases (not if the solution would have been found in the first few nodes that are checked, but most of the time it won't be that way...)