Project Orbiter Galaxy

[jedidia]

You should probly do some options on witch planets will have terrain. Like i don't particuarly like Earthlike planets with random terrain as the oceans get terrain and it dosn't feel right on the shore line.

is planed.

Witch reminds me i've noticed that all the Earthlike planets have about 50% ocean and 50% land even if the data sais the have 100% ocean or 1% ocean.

Yeah, the texture generator isn't entirely accurate with the hydrosphere setting, as can be expected. You can't exactly predict these things when generating a texture, you can just direct it in a general direction...

 

[IgnoreThisBarrel]

I also hope there will be UMmu compatibility for habitable planets by adding a permanent-base CFG file. I can't wait until base generation is worked in, if it is

 

[ghostrunner01]

Really cool idea. But when I try to run it i get Irrlicht.dll missing. Where can I get this dll or do I need to install something else?

 

[IgnoreThisBarrel]

Really cool idea. But when I try to run it i get Irrlicht.dll missing. Where can I get this dll or do I need to install something else?

My Irrlicht.dll is in my main Orbiter directory, it comes with Orbiter Galaxy 6.0.0.

Also, planet subtypes would allow for more texture variety (right now One Faced planets are rather dull).

 

[ghostrunner01]

Oh, I thought 6.0.4 patch was standalone.

 

[jedidia]

I also hope there will be UMmu compatibility for habitable planets by adding a permanent-base CFG file. I cant' wait until base generation is worked in, if it is

UMMU compatible habitable planets will probably be in the next patch. Bases... will take a while!

Also, planet subtypes would allow for more texture variety (right now One Faced planets are rather dull).

Well, no. The next version will contain several more subtypes, but that doesn't mean that every subtype is neccessarily supported by the texture generator. After all the solar system generator and the texture generator started as completely different projects by completely different people, so we're lucky that they use largely the same types at all.
Artlav is working on more types and more variety for existing ones, but we don't automatically get a new texture subset just because I add a new type to the planetary generator. He's got a lot more work with it than I do...

Oh, I thought 6.0.4 patch was standalone.

a PATCH is never a standalone, by definition of the word And we're mixing up version numbers here, it's 0.6.04 currently.

 

[jedidia]

Next patch could take a bit longer... I'm having much more fun with Orulex than expected :lol:

So far, the quiet, cracked surface with occasional snowhills of an ice planet on a sunny day:

 

[Stevodoran]

whenever i select save to cache or to folder it crashes. And i have the patch

 

[jedidia]

whenever i select save to cache or to folder it crashes. And i have the patch

Does it crash or does it freeze? If it freezes, that's completely normal. It'll stay frozen until the textures have finished exporting, which can take a while.

If you find yourself on desktop immediately after clicking the save button, something is not going as it should. Set the generation method to CPU (0) in your OGalaxy.cfg and see if that helps.

 

[jedidia]

I stopped Orulex support for now, to wait for a new Orulex version, which Artlav said would be possible to tailor to Orbiter Galaxy's needs...

I.E, terrain matching the textures! That would be a giant leap in quality for Orbiter Galaxy, but it will take a while. I'll just finish up the left over loose ends of the current version, throw up a patch during the next days, and move on to developement of version 0.7.
There'll be terrain support once the new Orulex version is finished which will probably be a long time before I get finished with the overhaul of the starmap and system generator. Not sure when yet, though, but man, I'm looking forward to it!

 

[donatelo200]

I agree we do need a new Orulex version befor we add complete orulex terrain. By the way the terrain in your screene looks really nice.:thumbup:

 

[IgnoreThisBarrel]

I agree we do need a new Orulex version befor we add complete orulex terrain. By the way the terrain in your screene looks really nice.:thumbup:

Agreed! Flying through those canals would be really fun! (Assuming there's an atmosphere and the canals are above the collision-detection sphere).

 

[jedidia]

Well, that terrain won't be in, since in order to generate the terrain matching the textures Orulex will have to work with the exact same functions the texture generator works.

None the less, if you want to fly around on that terrain, you may replace any terrain cfg file with this:

seed        =3756       //Microtexture and microterrain noise seed
sbcrater    =500        //Surface base craters ridge height
microtexture=1          //Microtexturing
microtex_lev=40e3          //Microtexture level
belowsphere =0         //Below sphere terrain
altlimit    =800000      //Meters to cutoff
blendlimit  =400000      //Meters from altlim to cutoff start
glhmaplevel =9          //Max global heightmap level
glhmapop    =3          //Global heightmap operator
glhmapflag  =0          //Global heightmap flag
speccol     =0.3 0.3 0.3      //Surface reflection color
specpow     =35          //Surface reflection power
ospeccol    =0 0 0      //Water reflection color
ospecpow    =0          //Water reflection power

function=  1 2 1 1 3 10000 ridge+ -1* 4000* 8000+ 500 600 trim 1 1 1 1 3 20000 perlin+ 1000* 1000 sealevel 1000- + 1 1 1 3 6000 perlin 4000* 1800 sealevel 1800- +

That'll generate the terrain from the picture for you.

 

[Wishbone]

Jedidia, a couple of questions:

1. Do the generated planets have truly random atmospheres?

2. Since I am integrating Sutton-Graves convective and Tauber-Sutton radiative heat flux formulas into Precession MFD, and these formulae can be adapted to almost any atmosphere, is there any way to learn the composition of the planet's atmo? (I know, it can be entered manually, but that's a chore I'd better avoid).

 

[jedidia]

1. Do the generated planets have truly random atmospheres?

Currently, more or less. The atmospheres are randomly composed out of molecules that get retained by the gravity. The lighter a molecule, the bigger the chances of it occuring. That's all there currently is, but the atmosphere model will get revised a good deal for the next version.

2. Since I am integrating Sutton-Graves convective and Tauber-Sutton radiative heat flux formulas into Precession MFD, and these formulae can be adapted to almost any atmosphere, is there any way to learn the composition of the planet's atmo?

errr... inversing the polarity of the field coil, maybe? :lol:

I don't quite get what you want to do... Atmospheric composition isn''t part of the orbiter parameters, so There's no unified standard for that kind of thing. If I understood that correctly, you want your MFD to find out what atmospheric composition a planet has? Like, a general scientific solution that lets you calculate the composition? I don't think that's possible...

 

[IgnoreThisBarrel]

What if there was a folder in the config directory (like the Terrain folder for Orulex) with composition parameters for certain planets?

 

[Columbia42]

What if in the orbiter config parameters there was a section that look something like this:
AtmoComp = N, O, H, etc with N standing for nitrogen, o for oxygen, h for helium or hydrogen, etc. Numbers would be entered for those values, e.g.
AtmoComp = 0.7, 0.1, 0.1, 0.05, 0.05. Each number is the percent in decimal value of a certain chemical in the atmosphere.

 

[jedidia]

Hmmm... like, a standard for addon developers to have access to atmospherical densities, be it for generated or custom systems? Doesn't sound like a bad Idea, but not much point in it as long as UMMU doesn't support it. And DanSteph seems to have orphaned his addons a bit, it seems. Maybe somebody will have to make a UMMU successor sooner or later...

 

[Wishbone]

I can always access the density through the API, mind you. What I'm asking for is atmospheric composition (% molecular nitrogen, oxygen, carb dioxide etc.) since convection and radiative heating go differently in different gas mixtures (especially taking into account dissociation), for instance radiative heat flux is more of a problem on Mars than on Earth. A line or a section in a CFG/ini file would suit me just fine, as long as its location/format are consistent (e.g. always in a certain folder, name corresponds to the Gbody name of Orbiter API, decimal period is always used).

 

[jedidia]

Ok, let's see if I get this right:

The wish is for a standard system to define atmosphere compositions, so add-ons that want to use them may use them.

The question is, why stop there? why not also provide data like temperature range? Or, once OG 0.7 is out, lithosphere and hydrosphere composition? A standard for all kinds of thinkable additional parameters?

The outcome would be pretty close to what the .ogs format currently is, since it provides all the data to Orbiter Galaxy to display the planet parameters. There's even already a function in there to output one, which is called when you save a system to a folder. It wouldn't be any problem to also output them to a default directory for add-ons to read in, and custom system developers have to write up their own anyways if they want to integrate a system into Orbiter Galaxy.

I could even wrap the reader into a source and header file, with my datatypes, so add-on devs don't have to write their own every time. They could integrate the function and would get ALL available data on the star, every planet and every moon. Kind of a lite SDK.

Would that be a satisfiable solution, or would you like to keep things more simple?

Of course, the OGS is about to get a heavy extension for 0.7, and so is the reader, and the data types. It might be better to wait for that, or to be prepared to get your add-ons to the newest state once 0.7 is out...
By the way, I have no clue about what heat flux is...