General Question Doubt about the future Orbiter

[BruceJohnJennerLawso]

Okay, I feel the need to weigh in here:

Yes, Orbiter development does need to move forward, and yes, that will be troublesome for some users, but we all know that our good Doctor is very good at creating solid, efficient software. I don't anticipate this version of Orbiter running that much slower on a typical machine than Orbiter 2010 does now.

If Orbiter 2014, 2015 or whatever is problematically slow for a lot of people, I will continue to maintain my work for the (then) outdated Orbiter 2010 version. Even if the new version of Orbiter is too slow for most computers, the latest beta version without terrain should work well on pretty much any modern machine.

I do sympathize with those who cant afford to buy new hardware just for a new version; IMHO Orbiter should always be a lightweight, fast program when run out-of-the-box. (ie without add-ons) New features shouldn't detract from its ease of use on hardware with a wide variety of performance abilities.

 

[4throck]

A 4GB RAM, 32bit machine with a low end Nvidia GT640 graphics can run FSX well with all settings on high, Rome 2 decently, etc, etc.
Google Earth also runs quite well, and it has both terrain and imagery down to cm resolutions... and loads entirely online!
Don't see how the next Orbiter could have any trouble running on such a normal PC.

From my perspective, very few people have gaming rigs, and I just don't see that much people upgrading their PCs today. It's mostly laptops these days.
So there will certainly be a gap between the machines of some developers / enthusiasts and the general public.



Anyway, it's the community that decides what to use.

Now most people can use the DX9 client with no problems, but fewer use the DX11. That can certainly tell something about what hardware is used.
If the next version doesn't run, people will keep using the previous one. It has always been like that.

 

[martins]

I don't expect the next version of Orbiter to require more RAM than the current release. 2GB usable RAM is probably plenty (although I haven't tested this specifically).

It will require considerably more hard drive space to store the elevation maps and higher resolution textures. For the Earth textures I'm currently preparing I would tentatively guess around the order of 100GB. I may split the textures into blocks so that people can selectively download only what they are interested in, although no decision has been made yet.

Edit: CPU requirements should also be similar to current version. The elevation support and higher resolution textures should not impact significantly on frame rate. However, a minimum of two cores will be more essential than in the current version, because the second thread is now not only used to load the textures, but also to construct the surface mesh patches from elevation data.

 

[Izack]

For example u can look at Outerra which is 32bit, require about 600 mb of RAM and can render terrain of a very good quality... or SpaceEngine which doesn't require Gbs of RAM for its terrain too.

I don't know about Outerra, but Space Engine doesn't need a huge space because its terrain is not based on data, but generated procedurally. Take a look at Earth in Space Engine - modest data size and fairly terrible appearance of terrain in comparison with its fictional planets.

 

[Glider]

I don't know about Outerra, but Space Engine doesn't need a huge space because its terrain is not based on data, but generated procedurally.

Doesn't change anything. The only difference is that u have texture generated by shader in case of procedural planet, while in case of Earth u have same kind of texture loaded from disk. Same size in RAM.

Take a look at Earth in Space Engine - modest data size and fairly terrible appearance of terrain in comparison with its fictional planets.

Thats because it doesn't blend heightmap data with procedural data. Procedurally u can have as good resolution as u want while real heightmap data is limited by disk space, HDD speed and resolution of tools used to measure that real data. Outerra uses both real data and fractals to get much better result (but thats the engine focused only on Earth, while SpaceEngine is focused more on stuff without existing heightmaps), for example:
http://www.outerra.com/procedural/demo2.html

or

http://www.outerra.com/shots/lu10.jpg

and all this terrain uses much less than 1gb of RAM and only a 18 Gb Earth texture data for all kinds of tetxures. No need for 100s of Gbs . If u have a version of direct3d/opengl that can run fractal shaders of course, because this kind of details in realtime is possible only with GPU texture generators.

 

[Zachstar]

I don't expect the next version of Orbiter to require more RAM than the current release. 2GB usable RAM is probably plenty (although I haven't tested this specifically).

It will require considerably more hard drive space to store the elevation maps and higher resolution textures. For the Earth textures I'm currently preparing I would tentatively guess around the order of 100GB. I may split the textures into blocks so that people can selectively download only what they are interested in, although no decision has been made yet.

Edit: CPU requirements should also be similar to current version. The elevation support and higher resolution textures should not impact significantly on frame rate. However, a minimum of two cores will be more essential than in the current version, because the second thread is now not only used to load the textures, but also to construct the surface mesh patches from elevation data.

Seems quite reasonable in my opinion.

I am sorry if this has already been asked and/or answered. However is there any possibility of procedural generation of terrain for those who rather not download the terrain pack?

 

[Artlav]

I am sorry if this has already been asked and/or answered. However is there any possibility of procedural generation of terrain for those who rather not download the terrain pack?

Technically, it is straightforward to do, Orulex does that to Earth - Lv6-Lv8 heightmap gets augmented with procedural details at no noticeable additional CPU or HDD cost.

As far as i understand Martin's system, he translates a heightmap elevation data into a mesh. At this point one can insert procedural detail adding.
I.e. interpolate Lv14 data from an Lv8 tile it's located inside, and add known perlin noise.
So, there should be a possibility.

 

[dansteph]

I have no doubt that Martin will make it users friendly as it said above and that mean also mid or low end computer as usual (in this case maybe without terrain or simplified terrain as it will be certainly optional packs as hi res textures)

But speaking about 8GB of RAM I don't think this could happen anyway, FsX and other simulators (and games) can achieve pretty good result without needing so much RAM. It may require some (optional) HDD space but 10-40GB are very cheap yet.

Dan

 

[Phoenix]

For the Earth textures I'm currently preparing I would tentatively guess around the order of 100GB. I may split the textures into blocks so that people can selectively download only what they are interested in, although no decision has been made yet.

I have a 10GB monthly download limit, so for me, a maximum of around 5GB per block would be ideal. For others, however, it might be less.

I am glad the next Orbiter will still work on my 4 year old dual-core laptop. Great!

 

[4throck]

I may split the textures into blocks so that people can selectively download only what they are interested in, although no decision has been made yet.

For local datasets the most flexible approach would be custom meshes.
Those can be optimized and have infinite level of detail (in both geometry and textures).

We only need a way to make them fit the global L9 or L10 terrain/textures.
It will be necessary to completely replace the global terrain in order to have a flat landing area, an elevated pad, etc, etc.
As long as the collision/landing system is the same for the local and global meshes , it would work and be quite seamless.

 

[DeadlyCZ]

I wouldn't mind high HDD space and/or RAM requirement, but I hope that video card requirement won't be higher :/ My laptop's discrete video card died, so I'm running on an integrated one (granted, it's intel HD 3000 so not so bad), but orbiter is one of the few games/sims it can run... Upgrading RAM is a matter of pocket money, and HDD space isn't expensive either, but it would ruin me if I had to buy a new laptop / computer :/
Anyways, it really looks great and I am looking forward to it!

 

[Qapla]

I always thought Orbiter was going to be the seed of something like Elite with online trading, maybe one day but I doubt it.

1 thing id like to see Orbiter have is the ability to tap into the same thing x-plane has where all trees, buildings, fences are downloaded as small "sets" so when you fly around you see real 3D terrain objects, its pretty amazing, I added my house and about 5,000 other houses and lots of other people have done the same and it looks reall impressive in the sim, I only ever used it for that i never once flew to an airport lol

 

[jedidia]

1 thing id like to see Orbiter have is the ability to tap into the same thing x-plane has where all trees, buildings, fences are downloaded as small "sets" so when you fly around you see real 3D terrain objects, its pretty amazing, I added my house and about 5,000 other houses and lots of other people have done the same and it looks reall impressive in the sim, I only ever used it for that i never once flew to an airport lol

This is already possible with the current version. Was even possible with Orbiter 2006. Well, not by direct streaming, but you can still do it.

 

[Qapla]

This is already possible with the current version. Was even possible with Orbiter 2006. Well, not by direct streaming, but you can still do it.

Can you explain how?

 

[meson800]

Can you explain how?

A module can be created which adds vessels with meshes around the current camera location fairly easily. I remember there was a module that added small asteroids in LEO around the focus vessel, but I can't seem to find it right now. It created debris on the fly that looked something like [ame="http://www.orbithangar.com/searchid.php?ID=4863"]this addon[/ame]

To add 3D terrain, one would have to have a collection of meshes, such as trees and foliage in this [ame="http://www.orbithangar.com/searchid.php?ID=591"]addon[/ame], house models, cars, etc. Then, a module could be created to randomly (or directed by some terrain map) place the models on the ground around the focus vessel.

 

[Qapla]

A module can be created which adds vessels with meshes around the current camera location fairly easily. I remember there was a module that added small asteroids in LEO around the focus vessel, but I can't seem to find it right now. It created debris on the fly that looked something like this addon

To add 3D terrain, one would have to have a collection of meshes, such as trees and foliage in this addon, house models, cars, etc. Then, a module could be created to randomly (or directed by some terrain map) place the models on the ground around the focus vessel.

ah ok thanks, I thought he meant its possible to import data from places like openstreetmap, I think thats the direction orbiter needs to go in and the future of all flight sims.

 

[meson800]

I thought he meant its possible to import data from places like openstreetmap

Obviously it isn't at the moment because no one has made that type of module, but that is the beauty of the Orbiter API and programming in general. Something like an openstreetmap importer is possible; someone just has to program it. Nothing in Orbiter core is preventing it from being created.

In fact, here is a short thread about the idea from a while ago.

 

[jedidia]

ah ok thanks, I thought he meant its possible to import data from places like openstreetmap

Would also be possible to code up, but really, what's the point? Orbiter isn't a flight sim... it's a space sim. That kind of work for a barely used feature just isn't justifiable...

I could even do without the terrain if it was only earth in question. I barely ever see much places there. It's the other bodies that I really want the terrain for. There's not much data about Mars on openstreetmaps, last time I checked.

 

[Qapla]

Would also be possible to code up, but really, what's the point? Orbiter isn't a flight sim... it's a space sim. That kind of work for a barely used feature just isn't justifiable...

I could even do without the terrain if it was only earth in question. I barely ever see much places there. It's the other bodies that I really want the terrain for. There's not much data about Mars on openstreetmaps, last time I checked.

If it takes a lot of work then I agree its not worth it, but if its just a little bit of code needed its well worth it is all im saying. I dont use earth much either its just a big launch and landing pad but its also an eye sore, I feel like im playing FS95 until I get into orbit, in fact FS95 looks way better, id just like to see Orbiter get a big facelift thats all, it deserves to look better.

 

[jedidia]

id just like to see Orbiter get a big facelift thats all, it deserves to look better.

And with the terrain implementation in the next version, it will. Here's to waiting for tuesday