Project Orbiter Galaxy

[IgnoreThisBarrel]

D'oh! Apparently when editing my config file I changed the texture type rather than the generation processor thing.

Testing it in CPU mode, brb.

And it worked!

Now if only there was a more efficient way to generate textures *cough cough*

Although I think that may be a problem for Orbiter's core...

 

[jedidia]

And it worked!

That means that for some strange reason, the fallback from GPU on CPU doesn't work on your machine. I'd say with some certainty that it's related to your graphics card. Are you expieriencing longer export times now than before?

Now if only there was a more efficient way to generate textures *cough cough*

Actually there is... but it costs around 300 bucks

Artlav's monster of a graphics card shoves out a level 8 texture in 30 seconds. My CPU needs about 10 minutes :beathead:

Although I think that may be a problem for Orbiter's core...

Rather for a graphics client. It would theoretically be possible to plug the whole texture generator, including terrain, into the OGLA-client and load on demand. But that might be a lot of work, and there's only one who can do it...

 

[dumbo2007]

Ah yes the one !!

 

[IgnoreThisBarrel]

What about that thing Spaceway Artlav made a while back? it can create realistic-looking textures in an extremely short amount of time.

Also, I use an Nvidia card, so maybe that has something to do with it...

 

[Artlav]

In other words,Textures for rocky planets without atmospheres get exported as a black mess.

Which is surprising, as they are the simpliest of the lot, but not mysterious, as that indicates some fine incompatibility.

Barrel, there should be a shader.log created after a GPU-enabled generation run, can you post it?

What about that thing Spaceway Artlav made a while back? it can create realistic-looking textures in an extremely short amount of time.

The generator is one and the same, the difference is that in Spaceway there is a dynamic Level Of Details system (think Orulex), which essentially only makes the textures for things you currently see. Thus you get an illusion of slowly-loading Lv32 textures.

In Orbiter galaxy, however, the entire planetary texture have to be made at once, for every planet. That's way more than Spaceway does, and so takes way more time.

 

[jedidia]

thanks for dropping by :tiphat:

As it seems, the flashing unresponsive window after GPU generation is quite a common problem, although so far I have only heard of cases where the generator falls back on the CPU. Can you reproduce it on your machine?

 

[IgnoreThisBarrel]

Ah, that makes sense.

Shader.log, not much to it. Or so it appears.

prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:
prog[0]:
prog[1]:

---------- Post added at 20:18 ---------- Previous post was at 15:53 ----------

Been playing around with this. Very fun, although texture generation takes a while, as previously complained about.

Anyway, I have three suggestions.
1) UMmu "permanent bases" so that planets flagged as habitable are UMmu breathable.
2) The possible generation/use of "rings" for planets, gas giant or otherwise.
3) Having a folder with several "star" textures colorized to various star spectral types (O,B,A,F,G,K,M,D, black hole) which automatically replace the current star.dds with the star.dds for the spectral type of the star in the system you're going to.

 

[IgnoreThisBarrel]

And I made the star textures! Just in case you decide to use that idea.

 

[donatelo200]

The G and F class stars are a little to yellow. G stars would have a tiny itsy bitsy hint of yellow and F stars would just be plain white. Other than that those star colors are correct.

 

[IgnoreThisBarrel]

The G and F class stars are a little to yellow. G stars would have a tiny itsy bitsy hint of yellow and F stars would just be plain white. Other than that those star colors are correct.

Yeah, I was having a hard time with those, seeing as how all the textures for our sun are all completely white.

 

[Pyromaniac605]

I've been having some trouble, I follow the instructions in the Quickstart in the manual, but when I press map the window opens and does nothing but freeze itself and Orbiter.
Are you supposed to run the Orbitergalaxy file?

Darren

 

[IgnoreThisBarrel]

I've been having some trouble, I follow the instructions in the Quickstart in the manual, but when I press map the window opens and does nothing but freeze itself and Orbiter.
Are you supposed to run the Orbitergalaxy file?

Darren

No. The map window doesn't freeze, but rather takes a while to load. On my comp it's between 15 and 45 seconds.

 

[dumbo2007]

Well....I travelled to the Gl 905 system (with 11 planets) now and the textures generated in about 5 mins...here are a few screens :

Some of the moons and planets were black. I used the default settings after applying patch 0.6.2

 

[IgnoreThisBarrel]

If some of them are black go into the Orbiter Galaxy config file and change it from GPU mode to CPU mode.

 

[dumbo2007]

Yes thanks!!...all the moons and planets have textures now...I set a minimum level of 7 and it took about 20 minutes to generate the textures for the Barnard star system...trying hard to reach the habitable world now with the DG :thumbup:

 

[jedidia]

So it's definitaly an incompatibility issue between the TexGen library and some graphics cards. Please make sure you got the latest drivers, and if the problem persists, post exactly what graphics cards you're using. Artlav will need that to fix the issue.

I set a minimum level of 7 and it took about 20 minutes to generate the textures for the Barnard star system

That's pretty fast for CPU generation at so high levels (I assume your max level was set to 8?).

@IgnoreThisBarrel: Thanks a lot for the textures, yes, I'm certainly going to implement that functionality. Just didn't get around to it for this release...

@Pyromaniac: That shouldn't happen. The map takes a few seconds to load the first time, but Orbiter shouldn't hang up. Make sure you're using this add-on on Orbiter 2010p1.

Please try on a clean install and see if the problem persists. If not, go through your modules one by one and see which causes the behaviour. If you find out, please let me know.

If it doesn't work even on a clean install, we have another interesting phenomenon for which I have no explanation...

 

[dumbo2007]

Well I am trying with maximum settings now :

About 20 mins since I started and 2 large texture files of about 16 MB have been written and one 32MB tex too...window still minimized :

//window resolution
1024x768
//current galaxy
MilkyWay
//default hotspots-file
Default
//Max texture level/min texture level (8 is limit!)
8,8
//Min radius for max texture level/max radius for min texture level(km)
5000,500
//always use at least this texture level for earth-like planets (0 to use textures by size) 
8
//don't use higher than this texture level for gas giants (0 to use textures by size)
7
//use this texture level for asteroids
3
//Max/Min number of asteroids in an asteroid belt
10,5
//Number of systems to keep in cache 
2
//Max Distance in lightyears for system Switch and time propagation (use 0 to disable time propagation)
0.1
//Safety margin to estimated time of deceleration burn (days)
30
//Method of Texture Generation (CPU = 0, GPU = 1. GPU has to support fragment shaders)
0
//Simplified textures (0 = full textures, 1 = simplified. Later is strongly recommended if textures are generated on the CPU)
0

Still churning ...1 core constantly at about 100, the other one is about 90 on average.....I was wondering if this can be made faster on machines with more cores...like say on the i7 perhaps 6 textures can be generated in parallel as they are not interdependent (I assume).

 

[IgnoreThisBarrel]

Ah the Barnard's star system is wonderful in the default seed settings! I love the habitable planet!

Anyway, I have another idea: would it be possible to "mark" which planets you're going to visit so only they are given much of texture generating time?

Like "marked" planets are their set level, while "un-marked" planets are level 2 or 3.

And then, would it be possible to mark planets while you were already in the system they were in, generate the textures, and finally reload the scenario?

 

[jedidia]

About 20 mins since I started and 2 large texture files of about 16 MB have been written and one 32MB tex too...window still minimized :

You are running an all-out, max-resolution generation with FULL textures on the CPU? you'll wait for the better part of the day for this to finish! :blink:

Anyway, I have another idea: would it be possible to "mark" which planets you're going to visit so only they are given much of texture generating time?

Like "marked" planets are their set level, while "un-marked" planets are level 2 or 3.

And then, would it be possible to mark planets while you were already in the system they were in, generate the textures, and finally reload the scenario?

It would be a doable of course, but I'd imagine that to be even more tedious. The best bet is to get a good GPU (hey it's christmass soon, I'm already saving up money for the occasion...)

It would also be a problem because a Lvl3 looks already silly if you see it on a close moon, so moons of marked planets would have to be exported at higher levels too.

I'd say you're better off with making some room on your harddrive (I just kicked Mass Effect, 5 Gigs freed for system textures, yay! Where are those compatible custom systems? ), and raising your cache size, at least if you plan to revisit any of the systems.

 

[IgnoreThisBarrel]

You are running an all-out, max-resolution generation with FULL textures on the CPU? you'll wait for the better part of the day for this to finish! :blink:



It would be a doable of course, but I'd imagine that to be even more tedious. The best bet is to get a good GPU (hey it's christmass soon, I'm already saving up money for the occasion...)

It would also be a problem because a Lvl3 looks already silly if you see it on a close moon, so moons of marked planets would have to be exported at higher levels too.

It's at this point I wish you could "reload" certain parts of the Orbiter process while running a scenario. *cough cough* Martin or anybody with the Orbiter source code *cough cough* Although that might be a programming impossiblity or at least terribly inconvenient.

And just to clarify, by GPU do you mean a graphics card?