Poll Orbiter Galaxy - figuring out why it isn't used

[jedidia]

[ame="http://www.orbithangar.com/searchid.php?ID=4942"]Orbiter Galaxy[/ame] tried to address the oft-voiced call for interstellar travel, and to provide an easily usable framework in which to put custom systems. It has undergone a break in developement, but I'm slowly thinking of picking it up again. On the other hand, I'm thinking about not picking it up again at all, and use the generator for something entirely different.

The reason for this thought is that Orbiter Galaxy doesn't get used, as far as I can see. While not finished, the last iteration provided solid functionality on the three major features: providing a realistic (allthough not flawless) 3-d star map with about 100'000 of the closest stars in addition to a whole galaxy of procedurally generated ones, enabling flying from a source star to a target star using conventional drive, a Warp-MFD or a built in TDIP (teleportation device for impatient people), as well as providing a fully functional framework to drop custom systems for orbiter into it, thereby enabling connectivity betwen them.

The somewhat sobering fact is, in the time elapsed since developement went onhold, as far as I can tell not a single custom system supported Orbiter Galaxy, which is in my eyes a pretty strong sign that it doesn't get used at all. So, before going on, or even deciding wheather to go on, I want to find out why, despite many demands for interstellar flight, the add-on is so overwelmingly unpopular, to have a more solid basis to plan further work on.

So, please answer the poll, and post your thoughts about how the addon could be improved to get more use.

 

[Pyromaniac605]

I think it isn't used too often because it had a few too many issues, from the last version I used, I remember I had a lot of trouble just getting it to work, and then it took far too long to load the systems and after all of that the planets weren't particularly interesting and I never really felt the need to explore them.

Sorry if I'm sounding a bit harsh, but considering that you posted I assume you want the truth.

 

[Artlav]

Try aggressive advertising.
Unless found by accident or by a pre-know keyword search on OH, no one would even know OG exists.

 

[jedidia]

I assume you want the truth.

certainly. It seems that most of your issues are linked to matters of texture export, is that correct?

Unless found by accident or by a pre-know keyword search on OH, no one would even know OG exists.

The developement thread was pretty popular back in the day, so I would have assumed that at least solar system developers would pick it up from there, and my hope was that it would get more and more popular as more and more custom systems emerged to populate the galaxy with more interesting things... but that never happened. Maybe I should do a seperate poll for developers why they didn't add support to their systems...
To kick it off again, a bit of advertisement will probably be in order.

 

[Pyromaniac605]

certainly. It seems that most of your issues are linked to matters of texture export, is that correct?

That's correct, if you could somehow speed up the texture exporting process, that'd be a great improvement. :thumbup:

As for advertisement have you considered making a signature image to put in your forum signature that shows up on all your posts? That seems to be a good way to advertise addons on the forums.

 

[Linguofreak]

Orbiter Galaxy tried to address the oft-voiced call for interstellar travel, and to provide an easily usable framework in which to put custom systems. It has undergone a break in developement, but I'm slowly thinking of picking it up again. On the other hand, I'm thinking about not picking it up again at all, and use the generator for something entirely different.

The reason for this thought is that Orbiter Galaxy doesn't get used, as far as I can see. While not finished, the last iteration provided solid functionality on the three major features: providing a realistic (allthough not flawless) 3-d star map with about 100'000 of the closest stars in addition to a whole galaxy of procedurally generated ones, enabling flying from a source star to a target star using conventional drive, a Warp-MFD or a built in TDIP (teleportation device for impatient people), as well as providing a fully functional framework to drop custom systems for orbiter into it, thereby enabling connectivity betwen them.

The somewhat sobering fact is, in the time elapsed since developement went onhold, as far as I can tell not a single custom system supported Orbiter Galaxy, which is in my eyes a pretty strong sign that it doesn't get used at all. So, before going on, or even deciding wheather to go on, I want to find out why, despite many demands for interstellar flight, the add-on is so overwelmingly unpopular, to have a more solid basis to plan further work on.

So, please answer the poll, and post your thoughts about how the addon could be improved to get more use.

For my own part, it's that I wasn't playing Orbiter much when the project started, was attracted to it by other possibilities than use in Orbiter (though that would definitely be a major plus, if I ever get back to Orbiter), and was never an addon developer in the first place. Also, more recently, without seeing the development thread showing up in the "Latest Posts" box from time to time, I'd forgotten about it.

 

[Wishbone]

Most successful add-ons are plug-n-play experience. If there are too many steps involved in getting the add-on to work, people use other add-ons.

 

[Artlav]

if you could somehow speed up the texture exporting process, that'd be a great improvement.

Not quite feasible, it would necessarily take time to make anything non-trivial.

Maybe make a library of pre-generated textures, for use on slower computers and waitless users?

 

[Pyromaniac605]

Not quite feasible, it would necessarily take time to make anything non-trivial.

Maybe make a library of pre-generated textures, for use on slower computers and waitless users?

I wouldn't consider myself waitless, I just don't feel that I should have to wait longer than it take for a Commodore 64 to load a game off of a cassette tape for what are honestly mostly sub-par textures to load.

 

[orb]

I downloaded it once, but I've never installed in Orbiter, because: "I'm not interested in interstellar flight in orbiter anyways!", so I can't say anything about neither its interface, nor the texture export speed (whatever it means), or whether it's hard to use.

 

[jedidia]

I just don't feel that I should have to wait longer than it take for a Commodore 64 to load a game off of a cassette tape for what are honestly mostly sub-par textures to load.

Problem is, they're not loaded, they're generated and written to disk. It runs fairly fast on GPU, though the GPU export has some troubles Artlav hasn't been able to resolve, for the simple reason that he doesn't have a model of every GPU to try it out on...
Anyways, the only way to make the textures faster would be GOD (generate on demand... I just made that up, and it sounds cool... anyways, generating them the way procedural textures are usually generated).

That's not possible with the current setup... Artlav, purely theoretical question, how hard would it be to give Orulex the option of generating the terrain with the textures, so they don't have to be exported? It's the only possible way I see of avoiding texture export to file.

And this is of course another problem: Everything texture-wise was done by Artlav, for which I am very gratefull, since otherwise the project wouldn't have come to be in the first place. It has the backdraw that I can't fix the issues with it, though, since I'm horribly unqualified for any higher kind of math and coding...

Maybe make a library of pre-generated textures, for use on slower computers and waitless users?

It crossed my mind, but that would mean a huge download package and would make the whole thing look totally generic. I figured that once 5 to 10 custom system support OG it wouldn't be so much of a problem anymore, since they can be loaded pretty much instantly and usually also look better. However, that never happened. Maybe I should search a few custom systems, write bare bones config files for them and pack them all together in one huge solar system add-on pack for Orbiter Galaxy (with permission of the authors, of course, and I wish everyone a happy 15 GB download...).

As for advertisement have you considered making a signature image to put in your forum signature that shows up on all your posts? That seems to be a good way to advertise addons on the forums.

Yap, that wouldn't be such a bad idea...

 

[Artlav]

I wouldn't consider myself waitless, I just don't feel that I should have to wait longer than it take for a Commodore 64 to load a game off of a cassette tape for what are honestly mostly sub-par textures to load.

Loading is the wrong word. The textures are made, pixel by pixel, each time a new solar system is visited for the first time.
That needs a lot of computational resources.

That's not possible with the current setup... Artlav, purely theoretical question, how hard would it be to give Orulex the option of generating the terrain with the textures, so they don't have to be exported? It's the only possible way I see of avoiding texture export to file.

Essentially, Spaceway, so not a problem in itself.
The problem is in getting the textures into Orbiter.
There is no way in Orbiter to load a planetary texture at run time, whole or partially.
And Orulex only works up close, it does not replace the actual textures you'd see from orbit.

Then, it does not solve the core problem of a slow system - the texture would still take time to generate, only it would happen right in front of the player's eyes, with jerks in FPS and visual reshaping of terrain/texture.
Many people won't like that.

It crossed my mind, but that would mean a huge download package and would make the whole thing look totally generic.

Maybe make a horse move - the texture bank would be procedurally generated, so no downloads are needed.
Only instead of waiting for them to generate while you fly, you just leave the PC running overnight, and use the accumulated resource later, instantly loading.

Like a battery - you'd generate a bank of generic-ish new textures, and when you visit a solar system, some of them are taken and copied into the game.

 

[orb]

Like a battery

I think "cache" word fits better.

 

[jedidia]

The problem is in getting the textures into Orbiter.
There is no way in Orbiter to load a planetary texture at run time, whole or partially.
And Orulex only works up close, it does not replace the actual textures you'd see from orbit.

right, I forgott about that...
But I was thinking in a more direct line anyways: Orulex more or less creates a "virtual planet", I.E. a planet around the planet, which is handeled as a vessel. The textures would be rendered on that virtual planet, while the actual orbiter planet has no textures at all. I think it would be pretty similiar to the way Orulex already works, just that range would have to be extended. And there would have to be multiple instances, so a moon wouldn't just be a gray blob... hmmm... I'm beginning to see the problem. Buildup on procedural planets is a task for hi-end machines, that won't change in a while I think, but probably integrating the whole thing into orbiter will bring a whole lot of additional speed penalties. You think it would be a lot slower than in spaceways?

A hybrid solution might also be workable, with textures exported on level 3 or 4 (which works fairly fast even on CPU) and the higher levels generated on the fly by Orulex when one is sufficiently close. That might solve the multiple instances problem, but would again put in a generation time of about 10 minutes on CPU for a larger system, I would guesstimate.

Of course, most of all working into that direction would depend upon wheather you have time and interest to take things further. As I understand it SpaceWays and OGLA are pretty much on hold for a longer time now.

Maybe make a horse move - the texture bank would be procedurally generated, so no downloads are needed.

Thought about that too, but I wonder if that would be much more convenient for the average user than the current method. Would need another poll, I guess.

 

[Artlav]

right, I forgott about that...
But I was thinking in a more direct line anyways: Orulex more or less creates a "virtual planet", I.E. a planet around the planet, which is handeled as a vessel. The textures would be rendered on that virtual planet, while the actual orbiter planet has no textures at all.

Bad idea as well.

Even from orbit it would look very 2003ish:
http://orbides.1gb.ru/orbf/ob-110913-1.jpg

And from over 1-2 Mm it does not work at all.
http://orbides.1gb.ru/orbf/ob-110913-2.jpg

No way to fix this without altering the rendering engine - Orbiter was not designed for such abuse.

Buildup on procedural planets is a task for hi-end machines, that won't change in a while I think, but probably integrating the whole thing into orbiter will bring a whole lot of additional speed penalties. You think it would be a lot slower than in spaceways?

Orulex is a compromised hack into a different rendering engine, so GPU side will be slower. On the other head, there would be much less CPU work, so it might end up faster.
No way to tell.

A hybrid solution might also be workable, with textures exported on level 3 or 4 (which works fairly fast even on CPU) and the higher levels generated on the fly by Orulex when one is sufficiently close. That might solve the multiple instances problem, but would again put in a generation time of about 10 minutes on CPU for a larger system, I would guesstimate.

And add another level of cumbersome and bug-prone software? Orulex is not perfect and can no longer be improved.
That is in addition to the rendering issues i pointed above.

Of course, most of all working into that direction would depend upon wheather you have time and interest to take things further. As I understand it SpaceWays and OGLA are pretty much on hold for a longer time now.

Spaceway is in a burst of development right now, and fallout from that would reach Orbiter too - Videnie was updated yesterday with a few fixes, for example.
So don't hesitate to ask.

Thought about that too, but I wonder if that would be much more convenient for the average user than the current method. Would need another poll, I guess.

Options. There should be options for all levels of performance. That could be the low-end one.
Even a cellphone can generate these textures, it's only a question of time.

 

[jedidia]

No way to fix this without altering the rendering engine

Altering the rendering engine, that would basically mean embedding the feature directly into a graphics client, if that would even help. Then the whole thing gets blown quite absurdly out of proportion... Pre-generated will have to be the option for those who can't bear the generating-times, then. Wouldn't be too hard to put in, and if people give it a day and a night and a 50 or so Gigabytes of disk space it might not even look too generic. Urk. I seriously don't think that anyone would bother under the circumstances, but I can provide the option...

I have to confess, though, that I don't quite get what's going on in the second screenshot there.

Spaceway is in a burst of development right now, and fallout from that would reach Orbiter too - Videnie was updated yesterday with a few fixes, for example.
So don't hesitate to ask.

That's nice to know. If I decide to get this thing on the road again, I guess what I'd need the most is the bugs ironed out of the GPU-generation (mostly the black texture bug on some cards and the "no noise" Bug on other cards, like mine, which strangely don't happen in spaceways, which will make them pretty hard to hunt down...), and maybe that Orulex version that can be fed with the parameters to produce terrain according to the texture we once talked about. The Orulex microtextures would at least take some pressure of the texture generation, as level 6 with Orulex usually looks pretty decent. But I'm in no hurry as of yet, currently I'm just checking needs and possibilities.

Anyways, the other point that got a lot of votes but wasn't discused was the interface (well, alot of votes compared to the number of voters so far, anyways). I'm a bit surprised about that, as I tried to make it as userfriendly as possible, but of course any interface is always perfectly intuitive to the guy who wrote it. So I need some input on what should be changed from the people who voted on the clunky interface. Bring on the suggestions, that at least is something I could change by myself and pretty much to anything people want it to...

 

[Ragtag]

Project Rag Tag Fleet was looking at OG it to use in conjunction with our Star Gates for transport between systems. One of our dev team members is looking closely at it but, so far a number of issues and desires have somewhat stalled the effort.

 

[jedidia]

Project Rag Tag Fleet was looking at OG it to use in conjunction with our Star Gates for transport between systems.

Might be a bit tricky to do as a standalone, but I probably could integrate an interface that lets people define custom "jumppoints".

 

[Izack]

It simply did not work on my machine, due to (apparently) hardware issues. I am very interested in interstellar flight in Orbiter, and would have been using it if it would actually agree with my hardware, but alas, it does not.

 

[Ragtag]

Might be a bit tricky to do as a standalone, but I probably could integrate an interface that lets people define custom "jumppoints".

It was/is Captain Rodolpus working with it. I'm not sure he comes around here so you would have to go over to the Fleet forum and talk to him about what was wanted and what the problems were.