Board index FlightGear Development New features

future scalabilty mobile dev./ Res. based texture packs?

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

future scalabilty mobile dev./ Res. based texture packs?

Postby rico001 » Tue Sep 30, 2014 6:09 pm

I had thought of an idea to have texture packs for scenery customized for the display setting you choose. This way we would all have optimal textures for our computers. The main installer could have multple resolutions for a single airport to save space.
Last edited by rico001 on Thu Oct 02, 2014 4:55 pm, edited 2 times in total.
rico001
 
Posts: 65
Joined: Wed Oct 17, 2007 6:14 pm

Re: Proposal -scene Resolution Texture Packs based on displa

Postby Thorsten » Wed Oct 01, 2014 5:33 am

May I ask what problem this is intended to solve? I'm not aware of any really large scenery textures, and reducing overall memory occupancy by half a percent doesn't strike me as something I would invest much effort into.
Thorsten
 
Posts: 11374
Joined: Mon Nov 02, 2009 8:33 am

Re: Proposal -scene Resolution Texture Packs based on displa

Postby rico001 » Wed Oct 01, 2014 8:39 pm

Thanks for the feedback/questions;
I was thinking about the load times and hard drive space as well. I started noticing that for FG 3.0 the blue-ray disks were going to be available to store textures.

I was thinking mostly about the DDS Question; but was also wondering how textures for mobile devices works, If I can I'll relabel the thread.
DDS/ compression questions .

Portable device scalability such as android.
Hard drive space problems with non-optimal scenery (32GB) when only have 8gb?
Would load times be too long?


Thorsten wrote in Wed Oct 01, 2014 5:33 am:May I ask what problem this is intended to solve? I'm not aware of any really large scenery textures, and reducing overall memory occupancy by half a percent doesn't strike me as something I would invest much effort into.
rico001
 
Posts: 65
Joined: Wed Oct 17, 2007 6:14 pm

Re: future scalabilty mobile dev./ Res. based texture pacts

Postby Thorsten » Thu Oct 02, 2014 7:52 am

Hard drive space problems with non-optimal scenery (32GB) when only have 8gb?
Would load times be too long?


The whole terrain texture pack is 282 MB, I don't think that's a hog for any of the contemporary storage devices in the age where 8 GB memory sticks are handed out as gifts... The bulk of the terrain size is the vertex data of the elevation and landcover mesh, compared to the size of that (I think the total 2.0 World Scenery is some 90 GB), textures are a small correction (in fact, 0.3% of the size...).

I don't know about loading times, but again, the vertex mesh would take the majority, not the terrain textures.
Thorsten
 
Posts: 11374
Joined: Mon Nov 02, 2009 8:33 am

Re: future scalabilty mobile dev./ Res. based texture pacts

Postby Hooray » Thu Oct 02, 2014 9:36 am

You do have a point about mobile/embedded devices though, such as Android/IPhone, gaming consoles like the Playstation/Wii or even just the Rasberry PI, but as has been previously pointed out by others, there are additional challenges when it comes to supporting such platforms, beyond "just" resources - for details, see: http://wiki.flightgear.org/Howto:Optimi ... le_devices

As you'll see, we've had a number of end users, as well as contributors, interested in supporting such use-cases at some point, but this certainly is a multi-year effort, especially formalizing data and code dependencies is something that's been overdue for years, and that's really only just getting fixed/addressed recently - part of this is being addressed by initializing Nasal earlier and by making subsystems better runtime-configurable, and -on demand- even optional.

The whole FGCanvas effort is just the tip of the iceberg here, but it is actively being worked on by several contributors and core developers. My estimation would be that we're roughly 1-2 release cycles away from making that happen. Once that is the case, we can explore running a subset of FlightGear on certain devices, and re-adding certain features as we go: http://wiki.flightgear.org/FGCanvas

Overall, these efforts will help improve FlightGear over time, regardless of any particular use-case, but these are run-time scenarios for which FG was never designed, which is why it's taken so long to support certain features properly.

You are obviously invited to add your own ideas and thoughts to the wiki.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11469
Joined: Tue Mar 25, 2008 8:40 am

Re: future scalabilty mobile dev./ Res. based texture pacts

Postby Thorsten » Thu Oct 02, 2014 10:11 am

Okay, I am just not getting it for whatever reason.

Can anyone explain to me in simple terms why the primary obstacle in running FG on a mobile device are terrain textures, so after finally merging the mess in the texture folders to a unified texture pack, we should go back to maintaining two (or more)? What is the actual problem this would solve?
Thorsten
 
Posts: 11374
Joined: Mon Nov 02, 2009 8:33 am

Re: future scalabilty mobile dev./ Res. based texture pacts

Postby Hooray » Thu Oct 02, 2014 10:26 am

I didn't say anything like that, in fact I even pointed out that terrain textures are certainly far from being the "primary obstacle" like you put it now - also, I personally don't believe in maintaining different sets of textures around, simply because of the manpower/automation required to make this happen - which hasn't worked for FG so far. However, we've seen other efforts where people where interested in "modding" FlightGear to some extent by supporting custom texture packs. Personally, I believe that some kind of run-time scheme would be better, where textures would be dynamically adjusted as required during the initialization process - understandably, that may not work too well for resource-limited devices like an Android/IPhone device.
As can be seen in my previous response (and the links I posted there), I am quite aware that there are many other issues, beyond "just" scenery and aircraft complexity - even without any textures being loaded, and with just "wireframe" being active, FlightGear -in its current form- would not run too well on such devices.
As you know, I've done this recently on an Intel GMA based NetBook, and performance even in the aforementioned "FGCanvas" (FlightGear subset) mode was not overly impressive even when just flying across sea (=zero scenery). Thus, I do believe that there are quite a few lower-hanging fruits/issues that we need to tackle first, before we look again at textures.

And even then, having a separate texture set may not be the best option from a workload standpoint, unless maintenance can be scripted/automated to some degree - otherwise, I would consider exposing a few more OSG internals to FG so that textures can be dynamically resized on demand during initialization, maybe along with an option to serialize everything to an on-disk cache (i.e. the usual space/time trade-off).
But fgdata maintenance always has been a huge challenge for FG, and formalizing data/code dependencies there is even more necessary than in the C++ code, because most contributors are not primarily coders, so tend to do/use "whatever works", without taking into consideration other, important, use-cases.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11469
Joined: Tue Mar 25, 2008 8:40 am


Return to New features

Who is online

Users browsing this forum: No registered users and 1 guest