Topic: Galaxy Generator.

[Recon]

   Well, after a bit of effort I got to my first goal, which was a class structure that could load some data and render one star. Now I start on phase 2, which is generating planets/moon's and as much other information as I can.
   Got a couple of questions,

1.I was planing to use the star.txt list from celestia for the basic star map, it's got planty , about 100,000. was wondering how people felt about that. comments welcome .
2.There is also a dead open source project that I found called mostly-harmless, that is exactly what I need. It's got so much stuff in it I want to use. you can check it out at http://sourceforge.net/projects/mostlyharmless/. I plan to strip out the database stuff but leave as much of it intact as possible. Was wondering what people thoughts where on that.

So,
   Stage 2 is getting the generator working. give it a star and a bit of general info and generate planets and moons with orbits and as much other stuff as I can come up with.
   Stage 3 is getting a simple render class working to get all this stuff moving.
   Stage 4 is making it look cool.

I hope it gets easier, lol, had a few dark moments already dealing with Crystal Space. So whoever is in charge of  precursor's let me know what you think as coding is moving along.

Regards

[contingencyplan]

Initial impression: Looks pretty, but 100% unusable, as it's licensed under the GPL. This makes it incompatible with the current LGPL license for Precursors. Unless somebody says differently, I would avoid looking at their source code when developing your implementation - since the licenses are incompatible, we want the stuff you're working on to be done as cleanroom as possible (at least as far as the MostlyHarmless project is concerned). Check with morgul, but I don't see a problem with contacting the author and seeing about getting him to either turn the project over to you (a HUGE undertaking, but possible) or to relicense the project or current code as LGPL-compatible (preferably the LGPL itself). But get morgul's approval before doing so.

Good to see progress, though - keep up the good work!

[Morgul]

Well, if the world generator will never be a part of the precursors client (and the two will never share code) this is fine. (To be clear, so long as this is going to be a separate application, there's no concern here.) However, if the plan is to imbed this into the precursors client then we'll need to talk about things.

[Recon]

Well, got a good bit of stage 2 done, I got Stargen working and it's producing planet data, here is a example of some output ( note this is a subset of the info generated )

Planet 8
   Distance from primary star:  4.685   AU
   Mass:                        6.712   Earth masses
   Surface gravity:             1.16    Earth gees
   Surface pressure:            0.059   Earth atmospheres
   Surface temperature:         -273.15 degrees Celcius
   Equatorial radius:           15341.8 Km
   Density:                     2.652   grams/cc
   Eccentricity of orbit:       0.047
   Escape Velocity:             18.68   Km/sec
   Molecular weight retained:   0.00 and above
   Surface acceleration:        1137.17 cm/sec2
   Axial tilt:                  19      degrees
   Planetary albedo:            0.151
   Length of year:              3143.21 days
   Length of day:               14.21   hours
   Boiling point of water:      35.3    degrees Celcius
   Hydrosphere percentage:      0.00
   Cloud cover percentage:      0.00
   Ice cover percentage:        0.16

this is quite a bit of info. Unfortunately it does not generate moons and I think that is what I will look into next. I did a little bit of work on rendering the info, very basic but here are some pictures.

A quick look at a sun and a few planets


A closer look at some planets



for them moment I am going to do some work on getting it to generate moons and maybe some work on creating custom materials for the planets as I am using material pinched from celestia at the moment and that does not give me much variety.

Now, I have been trying to not do any development on rendering these planets and the brings us the the whole GLP/LGPL issue. I went ahead and used stargen as it saves me a lot of time doing work that has already been done in the GPL community.

The question now is, is precursors interested in using any of this? as precursors is LGPL including the code is out, but it should be possible to use the data generated. I am going to look into getting it to create world files. The idea being that it can generate world files that can be used in precursors ( this is why I am trying not to do any work on rendering as the code would not be useful later.). The world files should be quite small, as they should only contain text. then if we code a loader/Render in CEL it would seem like a nice solution. I would appreciate some feedback on this.

On a side note, I have already run into scale problems ( lighting appears to stop working at 100,000 units from the origin, 3 of my planets are past this even in my seriously squashed up model . This is still a hard technical problem we need to over come. and the discussion of it has seemed to miss the point, the problem is not storing large numbers, it is rendering objects that are far apart in crystal-space.   

Anyway, look forward to and comments

Regards 

[whitelynx]

Well, got a good bit of stage 2 done, I got Stargen working and it's producing planet data, here is a example of some output ( note this is a subset of the info generated )

First off, great work so far! It's starting to really look like a solar system!

Now, I have been trying to not do any development on rendering these planets and the brings us the the whole GLP/LGPL issue. I went ahead and used stargen as it saves me a lot of time doing work that has already been done in the GPL community.

The question now is, is precursors interested in using any of this? as precursors is LGPL including the code is out, but it should be possible to use the data generated. I am going to look into getting it to create world files. The idea being that it can generate world files that can be used in precursors ( this is why I am trying not to do any work on rendering as the code would not be useful later.). The world files should be quite small, as they should only contain text. then if we code a loader/Render in CEL it would seem like a nice solution. I would appreciate some feedback on this.

I'm not yet sure which method I'd prefer... whatever happens, we can't include GPL code in Precursors, but aside from that, we're free to do pretty much whatever works best. I'm still not entirely sure which one to suggest, although generating world files and storing them does seem to be the preferable method, since then we can edit the resulting world files to add buildings and other such features. One thing we really need to think about, though, is how we're going to handle LOD and landing on planets. I know there's been some other discussion on this, but the dev team needs to make a final decision as to how we're going to implement things so that we know what data we'll need.

On a side note, I have already run into scale problems ( lighting appears to stop working at 100,000 units from the origin, 3 of my planets are past this even in my seriously squashed up model . This is still a hard technical problem we need to over come. and the discussion of it has seemed to miss the point, the problem is not storing large numbers, it is rendering objects that are far apart in crystal-space.

Actually, large numbers are the problem, since that's what CS has a problem with. :P The trick as far as solar systems go is simply to use a different coordinate system. We don't need to use 1 unit = 1 meter or even 1 unit = 1 km; we can use 1 unit = 1 au if we want. Try to find units that work well for the solar systems. We can worry later about how we're going to fit ships into it. (right now, my guess is that we'll end up having to use render-to-texture for the solar system and plaster that on a skybox or something... we'll see)

[Caenus]

Why not set a galactic coordinate base by having the radius of the star be 1 galactic unit?  admittedly this only works for a universe with a bunch of identical stars, but at least it gets you moving in the right direction.

[whitelynx]

Well, let's just choose the radius of an arbitrary, yet well-known star... maybe Betelgeuse, Antares, or Aldebaran... maybe Morgul can come up with a good star for this, seeing as he's familiar with all the different races and where they are located in the galaxy.

[Caenus]

Why not start with Sol?

It's the easiest to map (as we have the most data on it).

[Recon]

Well, lets try explain this scale issue better and get some detailed solutions on digital paper. 

   The issue
         Any mesh over 100,000 units from the origin will not render. 

   Best solution I'v heard so far. Take any object(mesh) that is over say 75000 units from the origin and remove it's mesh. then draw a scaled 2D picture of it on the sky  box.( at this range 99% of objects will be to small to see)   

  Just upping the scale we use so the solar system fits in 100,000 wont work as smaller objects (like ships )  will then be to small to draw . Example the sun is about 1,400,000 km in diameter, if we make this one unit in crystal space , A ship 1K long will be 0.0000001 units big. I have not checked this but I am sure that lots of things in crystal space will break at this scale. and our solar system will still be much bigger that our 100,000 limit.

So , here is a quick musing on a possible system

Several Cordinate systems using different scales

       1)a X,Y,Z system , with the origin at the players current location. Used to keep track of meshes and objects close to the the player.(maybe out to 10,000km with 1m units)

       2)a Right Ascension/Declination/Distance, with the origin at the players current location Used to draw faraway object in 2d on the sky box. ( this probably in AU's )

       3)And a galactic cord system that is based from some arbitrary origin.Used to initialise the first two. and also to allow navigation from star system to star system ( probably in light years ), also needed to locate 2 different players and workout if they are close to each other.

Please feel free point out problems with this as I think I already see several. But it is something to think about.

Regards
 

[Morgul]

Actually, I don't think CS breaks with things that small. A test needs to be done.

[whitelynx]

Well, CS could very well break with that unless the object was at 0,0,0. Keep in mind, float is much more accurate near 0 than anywhere else; at 0, you may be able to accurately represent the number 0.00000001, but make that 1000.00000001 and all of a sudden it will drop the trailing digits.

I agree with Recon's proposed coordinate systems, except I don't think coordinate system number 2 is necessary... Moving things around in RA/Dec/Dist space is a bit more complicated than I'd like, and doesn't give us much advantage... we need rectangular coords for rendering (even to the skybox) so it'd be easier to convert to the galactic scale (number 2) and manipulate the numbers there. I'd personally rather change all of the stars' coordinates in the data files to be rectangular coords, centered around the galactic core, so that we have a relatively even distribution across the coordinate system, and use the int-based fixed-point data type discussed earlier to work with that in code. We can use fixed-point math to calculate the size of the impostor that needs to be rendered and to calculate its coordinates on the skybox, and then convert those numbers to float for the actual rendering. Shouldn't be too difficult, and lets us keep track of coordinates on a galactic scale relatively easily.

A system like this will give us a very nice way of splitting things up across different servers. (each node server handles one solar system)

[contingencyplan]

Skimmed over - kudos to Recon for figuring all of this out. You'll fit in well with us, I can tell :-).

In terms of technical merit, all looks good to me. Then again, I'm a little stressed out, so I can't say much more on it right now. Fucking semester ending and all.

[Recon]

   Moving things around in RA/Dec/Dist space is a bit more complicated than I'd like, and doesn't give us much advantage... we need rectangular coords for rendering (even to the skybox) so it'd be easier to convert to the galactic scale (number 2)

I actualy disagree here, I think the RA/Dec/Dist is exactly the system we need. while rectangular cordiantes are easy to understand they require lots of calcualtions. as for the sky box , the simplest and quickest way I can think of doing it is using a sphere instead of 6 planes. Then do a orthagraphical projection onto a flat material. If there is a simpler way to do this I dont know it.

think we should only go to rectangilar cords when things have to be rendered in Crystal Space. But I will know more about this in a couple of weeks when I try code a skybox

Still the MASSIVE question regarding a thin or thick client to be answered. This is the biggest outstanding design question as it affects everything!!!! the sooner we have a answer to this the better.
 

regards


 

[Rosencrantz]

   Moving things around in RA/Dec/Dist space is a bit more complicated than I'd like, and doesn't give us much advantage... we need rectangular coords for rendering (even to the skybox) so it'd be easier to convert to the galactic scale (number 2)

I actualy disagree here, I think the RA/Dec/Dist is exactly the system we need. while rectangular cordiantes are easy to understand they require lots of calcualtions. as for the sky box , the simplest and quickest way I can think of doing it is using a sphere instead of 6 planes. Then do a orthagraphical projection onto a flat material. If there is a simpler way to do this I dont know it.
 

Just to play devil's advocate here. How does RA/Dec/Dist require less calculations? What specific calculations are you referring to? How many conversions to and from rectangular need to be done, and what about re-deriving equations of motion and translation if you aren't going to convert?

In short, What specifically are the benefits gained? And what is the range of use of these coordinates?

(FYI, I'm all for changing coordinate systems if it makes the calculations significantly eaiser).

[Recon]

   Moving things around in RA/Dec/Dist space is a bit more complicated than I'd like, and doesn't give us much advantage... we need rectangular coords for rendering (even to the skybox) so it'd be easier to convert to the galactic scale (number 2)

I actualy disagree here, I think the RA/Dec/Dist is exactly the system we need. while rectangular cordiantes are easy to understand they require lots of calcualtions. as for the sky box , the simplest and quickest way I can think of doing it is using a sphere instead of 6 planes. Then do a orthagraphical projection onto a flat material. If there is a simpler way to do this I dont know it.
 

Just to play devil's advocate here. How does RA/Dec/Dist require less calculations? What specific calculations are you referring to? How many conversions to and from rectangular need to be done, and what about re-deriving equations of motion and translation if you aren't going to convert?

In short, What specifically are the benefits gained? And what is the range of use of these coordinates?

(FYI, I'm all for changing coordinate systems if it makes the calculations significantly eaiser).

Well , to be clear I am advocating the RA/Dec/Dist method for the sky box, not for everything. meshs have to have cordinates. as stuff on the sky box not likley to move much we dont realy have to worry much about those calcualtions. I will know more in a week or so.

 

[whitelynx]

Actually, even skyboxes have to be done in rectangular coordinates. _Everything_ that goes on the screen is rendered by Crystal Space, including the skybox, so no matter what, everything needs to be converted to rect coords before we give it to the engine. Even if we're rendering stuff to a texture, that should be done through CS, as it is many times more optimized and well-tested than any way we could come up with to do the same thing.