vitos, I probably belong to the camp of people that you are trying to appeal to, i.e. I am interested in your project, and more generally the aspect of simulating space flight in FG, I do know C++, I am able to build FG from sources, I know how to create patches and I also usually do know my way around the FG code base.
The thing is however, that your whole approach of making your case is flawed and deemed to cause confusion among fellow contributors.
There's nothing to be gained at all by being overly negative and bitching around or by contiuous thread hijacking or forum trolling.
All of us have come here because we share a certain passion for FlightGear, but also a passion for our own projects and personal interests. Like you do obviously.
Now, if you want to show that you are serious about your project, you should concentrate on what's possible right now, rather than concentrating on all those things that aren't possible.
This is much harder to do than vice versa!
The local weather project, but also the bombable addon, can serve as excellent role models here, both projects manage to work around existing FG limitations, while still highlighting how FlightGear would need to be modified in order to become better usable for a certain use case. The wiki is an excellent tool here.
Modeling certain aspects of space flight in FlightGear isn't all that far fetched from, there are many shared requirements, some others would even be generally useful and improve FG, such as e.g. fixing FG's internal atmosphere model, something that almost certainly would also be helpful for the local weather project.
You are more likely to accomplish your goals by seeing things from a wider perspective.
So, I'd really suggest to concentrate on common requirements, things that may make FlightGear better in general, rather than just for a specific use case, such as simulating space flight:
When you do a mailing list search, you'll actually see that there have been LOTS of talks in the past about coming up with a better scenery engine, and providing a way to eventually replace the existing engine completely.
Some of these postings were written by Curtis Olson or Tim Moore, i.e. major fgfs "celebraties" Tim Moore even started collecting ideas using the wiki apparently.
Curt himself mentioned being supportive of the idea to provide an interface, similar to the existing FDM interface, so that an alternate scenery engine could eventually be developed in parallel with the existing engine, in a "plug and play" fashion. All of this can be easily found doing a simple mailing list search.
According to fredb's youtube channel and his postings here, FredB is another fgfs core developer who is quite interested in this and currently working on this, too.
So you have a number of FG core developers who have expressed an interest in improving and possibly replacing the existing scenery engine eventually. Translation: this
is the shared and common requirement!
Don't think in too simple and narrow-minded terms like "space flight", think broader!
A number of other C++ developers have recently expressed an interest in revamping the FG scenery engine and exchanged some ideas about this (notably psadro_gm and Zan).
And then there are the folks who are obviously interested in splace flight particularly and who'd also expressed offers to contribute to your project.
So, I really don't see where your problem is. There are enough
skilled people interested in this aspect of FG, yet you keep on bashing everything scenery related.
It would be better to collect all ideas and requirements and see what the common requirements
REALLY are. So that things can hopefully be prioritized.
Disabling the existing scenery engine shouldn't be difficult at all. I am pretty sure that it would take only a single mail to the developers and ask them how they'd go about quickly and easily disabling terrain rendering in FlightGear because you are interested in exploring alternative engines.
Given that Curt, Tim, Fred and some others have expressed an interest in this alreadyin the past, it should be a nobrainer actually.
Maybe, your whole problem is that you expect someone to do all the work for you?
Obviously, you should be able to build FG from sources, knowing some C or C++ can be helpful sure.
But apart from that, it shouldn't be too difficult to patch FG and make it stop loading tiles, at all. After all, it's not really "new features", it's about disabling existing code...
You said already that you know Nasal and C, I don't know if you are a Linux user and able to build FG from sources, but you should seriously consider looking into this if you are serious about your idea.
I think you need to start thinking outside the box: In FlightGear, one of the easiest way not to render any terrain is simply REMOVING the corresponding scenery tiles, or using a custom/empty scenery setup. That should make quite a difference already, simply because of the reduced scenery complexity. Have you actually tried this already?
In other words, you'd end up with a sphere rendered with just water, without the tile manager loading any terrain at all. That'd be the first and simplest step to "disable scenery" in FG to continue with your experiments. More options can be explored by looking into $FG_SRC/Scenery, i.e.:
http://gitorious.org/fg/flightgear/blob ... ilemgr.cxxBut really, I wouldn't even be surprised if somebody responded with a patch to disable the existing scenery engine once you manage to make your case in a civilized fashion
*.
Yet, you somehow don't seem to listen to anybody beside yourself. So, just to quote someone you'll hopefully listen to:
viewtopic.php?f=6&t=12005&start=15#p124427vitos wrote:You simply want to bite some too big piece at once. It's useless to make big list of tasks until we can not solve one vital task what blocks solving of any next problem in that list entirely.
Almost half a year ago, Thorsten came up with some neat workarounds and suggested specific methods to deal with FG's existing limitations while still pursuing your experiments:
viewtopic.php?f=6&t=12005&start=30#p125050Thorsten wrote:I don't think we need any new engine - from a Celestia perspective, Earth is just a textured sphere with a normalmap and a reflection shader - nothing we couldn't render and place into the scenery even from nasal. So I'd basically work on just loading a new, very large model, because that's all we need, and ask to deactivate all features in the skydome which assume you're close to surface - with the atmospheric scattering, I don't think there are any.
Celestia in addition has 'virtual textures' to display the truly hires textures - but again, you can chop a model of a sphere into bits and just load the ones you see from a simple Nasal script - so assuming you can use the hires Celestia Earth textures, it doesn't even require any modification to the core to get an Earth model in - all can be done from Nasal.
I haven't tried anything yet, but I'm fairly certain the problem is much simpler than we thought.
And he even provided more good tips:
viewtopic.php?f=6&t=12005&start=30#p125083You mentioned:
viewtopic.php?f=6&t=12005&start=30#p125079vitos wrote:There is problems what current terrain engine matter of. You need to switch it off somehow completely to avoid lags on high altitudes anyway. I do not even know if it's possible, engine can be linked to other code in many different places what could need some reactions of it or so.
For a very long time, FlightGear used to support the "draw-otw" property, which disabled "out of the window" rendering completely. I previously illustrated how terrain rendering itself could be disabled simply by removing the corresponding scenery tiles, or by preventing them from being loaded.
Having an option to generally disable terrain rendering might be useful for a whole number of reasons, so I don't think that introducing a corresponding optional property would be a problem at all.
There are many people interested in this aspect of FG, some of whom are even currently working on FlightGear scenery (TerraGear):
viewtopic.php?f=6&t=12005&start=45#p137855So, you got some good feedback already. The question remains if/how you are going to use this to its best potential?
*: The following SimGear patch will disable terrain rendering in a very blunt fashion, by rendering ocean tiles instead, I am getting between 100-150 fps at 500.000 ft altitude, the same could be achieved by using a property, so that things can be toggled on demand:
- Code: Select all
diff --git a/simgear/scene/tgdb/ReaderWriterSTG.cxx b/simgear/scene/tgdb/ReaderWriterSTG.cxx
index f79638b..20ebb41 100644
--- a/simgear/scene/tgdb/ReaderWriterSTG.cxx
+++ b/simgear/scene/tgdb/ReaderWriterSTG.cxx
@@ -56,7 +56,7 @@ osgDB::ReaderWriter::ReadResult
ReaderWriterSTG::readNode(const std::string& fileName,
const osgDB::ReaderWriter::Options* options) const
{
- osg::Node* result = TileEntry::loadTileByFileName(fileName, options);
+ osg::Node* result = TileEntry::loadTileByFileName(fileName, options, false);
// For debugging race conditions
#ifdef SLOW_PAGER
sleep(5);
diff --git a/simgear/scene/tgdb/TileEntry.cxx b/simgear/scene/tgdb/TileEntry.cxx
index 6c7c54c..f901a0d 100644
--- a/simgear/scene/tgdb/TileEntry.cxx
+++ b/simgear/scene/tgdb/TileEntry.cxx
@@ -173,7 +173,7 @@ struct Object {
osg::Node*
TileEntry::loadTileByFileName(const string& fileName,
- const osgDB::ReaderWriter::Options* options)
+ const osgDB::ReaderWriter::Options* options, const bool load_tiles)
{
std::string index_str = osgDB::getNameLessExtension(fileName);
index_str = osgDB::getSimpleFileName(index_str);
@@ -299,7 +299,7 @@ TileEntry::loadTileByFileName(const string& fileName,
// obj_load() will generate ground lighting for us ...
osg::Group* new_tile = new osg::Group;
- if (found_tile_base) {
+ if (found_tile_base && load_tiles) {
// load tile if found ...
opt->setCalcLights(true);
obj_load( object_base.str(), new_tile, true, opt.get());
diff --git a/simgear/scene/tgdb/TileEntry.hxx b/simgear/scene/tgdb/TileEntry.hxx
index 7aec5d1..e07042f 100644
--- a/simgear/scene/tgdb/TileEntry.hxx
+++ b/simgear/scene/tgdb/TileEntry.hxx
@@ -106,7 +106,7 @@ public:
* Transition to OSG database pager
*/
static osg::Node* loadTileByFileName(const std::string& index_str,
- const osgDB::ReaderWriter::Options*);
+ const osgDB::ReaderWriter::Options*, const bool load_tiles=true);
/**
* Return true if the tile entry is loaded, otherwise return false
* indicating that the loading thread is still working on this.