Board index FlightGear Development Spaceflight

Earthview - an orbital terrain rendering engine [v2.0]

Discussion about development and usage of spacecraft

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby Thorsten » Sat Mar 24, 2012 10:33 am

But it's possible very that to time of real beginning of "Apollo" project FG will become too sophisticated, and it will become impossible to make it, not even mention Mars flight project.


I don't think so. Flightgear is very modular as far as including FDMs or so is concerned, so in principle we could even fly the Orbiter FDM if we had it. As far as rendering is concerned, it's really not an issue if things are basically defined in an Earth-centered or a Sun-centered coordinate system. In shader coding, there are routinely 4 or 5 different coordinate systems appearing anyway.

We can easily define the whole solar system in sun-centered coordinates and transform it to earth-centered just before rendering - this is no trouble at all for any rendering engine which does several coordinate transformations anyway. There is no conceptual problem here.

About MP issues, I simply don't know. I am not familiar with the MP protocol, and I don't ever use MP in the first place, but there have been advances recently in terms of low resolution models being used for MP and AI planes.
Thorsten
 
Posts: 10097
Joined: Mon Nov 02, 2009 8:33 am

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby vitos » Sat Mar 24, 2012 10:48 am

Thorsten wrote in Sat Mar 24, 2012 10:33 am:Flightgear is very modular as far as including FDMs or so is concerned, so in principle we could even fly the Orbiter FDM if we had it. As far as rendering is concerned, it's really not an issue if things are basically defined in an Earth-centered or a Sun-centered coordinate system. In shader coding, there are routinely 4 or 5 different coordinate systems appearing anyway.


Okeedokee.

Thorsten wrote in Sat Mar 24, 2012 10:33 am:About MP issues, I simply don't know. I am not familiar with the MP protocol, and I don't ever use MP in the first place, but there have been advances recently in terms of low resolution models being used for MP and AI planes.


I suppose it's not about quality of models, since models renders on client side and glitches comes with any type of model. It's something in net packages transfer, and it's very strange since only tens of parameters is translated while network allows to transfer dosens of it simultaneously. Maybe it could be easier to get network part from other Open Source project, some game with multiplayer, without fixing current multiplayer network part.
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 583
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby Hooray » Sat Mar 24, 2012 2:36 pm

Hooray, going to moon is *not* primarily a rendering question - it is a question of the numerical stability of the FDM.


Yes, I was only referring to rendering actually. Sorry for not mentioning this: I don't think FG's current FDMs should even be considered actually - because they were designed with completely different requirements in mind.

On the other hand, it is already easy enough to interface FG to other/external FDMs and you can even create your own pseudo FDM in scripting space. So, yes - I was really thinking in terms of compromises to get this going. I don't know enough about JSBSim (or FDMs in general) to tell if (or how) JSBSim could be adapted to be really usable here though.

But I also don't think that the FDM issue qualifies as a "core" FlightGear problem (like vitos mentioned), due to the "plugin" nature of FDM support in FlightGear.

I do agree with the points you made regarding earth-centered rendering.
And yes, there's at least one FG core developer currently working on this. And it's also the same guy who is working on the HLA effort, which would also address multiplayer issues. I am not convinced that we should even try fixing/replacing the current MP protocol therefore.

Vitos, I read your comments and it is getting clear to me that we are disagreeing (again), so I am going to refrain from posting further responses, because that would not help this thread (knowing you, knowing me) - which is about something that we obviously both care about.

You know obviously a lot about 3D modeling and aircraft design, I am on the other hand only really familiar with coding and software design (unlike you, I have never developed a complete aircraft model or an FDM from scratch).

So I think it's only natural that we have different opinions because of differing backgrounds. However, a number of people have proven that the aircraft/scenery department is NOT the problem here (yourself included), you keep suggesting that the FlightGear core code is the bottleneck and needs fixing (and a number of dedicated people to work on this). Knowing some of the code in question, I can only reiterate my earlier points that once you got the FDM accuracy sorted, there are not any real showstoppers to keep pursuing the approach that Thorsten has come up with, many of the issues could be worked around by disabling some features or by making them more configurable using properties.

Finally, like Thorsten mentioned already there is someone working on this part of FlightGear - the same clever guy who did the OSG port and who's considered among all contributors to be a real rendering specialist. His work also touches the multiplayer system, too. So, I am trying to say: even if you don't agree with the points I made, someone else is already working on improving the core code. In the meantime, there shouldn't be anything stopping us from appreciating Nasal-space workarounds.
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: 11267
Joined: Tue Mar 25, 2008 8:40 am

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby vitos » Sat Mar 24, 2012 4:12 pm

Hooray wrote in Sat Mar 24, 2012 2:36 pm:So, I am trying to say: even if you don't agree with the points I made, someone else is already working on improving the core code. In the meantime, there shouldn't be anything stopping us from appreciating Nasal-space workarounds.


Heh. There is nothing stopping You from trying that workarounds. But, if You interested, I would reccomend You to read about N-1 Soviet Moon rocket, to know which approach is not work in rocket science.

And You gotta know that, since "Vostok" project is some workaround on itself, that I had went that way only because I had no choice. If I could have friends enough to make completely new Open Source space simulator then of course I would chose that way, it would free us from a lot of unfunny conversations at least :)

Tricks never will give You more than some small percent of what it could be in full glory. You cant have girlfriend on change :D
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 583
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby Tuxklok » Sat Mar 24, 2012 5:01 pm

vitos wrote in Sat Mar 24, 2012 4:12 pm:Tricks never will give You more than some small percent of what it could be in full glory.

Even if that was true..the fact is something, even if not perfect, is almost always better than nothing. You cannot achieve your 'full glory' if you never start anything at all. Many great things started off as something less than perfect, often more hack than not, but they actually do something and generate interest and ideas and can improve and evolve over time to become better.
The Austria Scenery Project - more info
fg-scenery-tools - gitorious | videos
fgcomgui - Open source, cross platform, gui front end for fgcom. more info

More random musings and doings can be found on my personal site. (work in progress)
User avatar
Tuxklok
 
Posts: 1326
Joined: Tue Apr 21, 2009 6:04 pm
Location: Orlando, FL
Callsign: Tuxklok / N1292P
OS: GNU/Linux

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby vitos » Sat Mar 24, 2012 5:19 pm

Tuxklok wrote in Sat Mar 24, 2012 5:01 pm:You cannot achieve your 'full glory' if you never start anything at all. Many great things started off as something less than perfect, often more hack than not, but they actually do something and generate interest and ideas and can improve and evolve over time to become better.


Well, I had made something. You can read "Vostok" topic to see how it had evolved in time.

There is no "something" in rocketry. There is "go" and "no go".

That topic is "go" for example. But it does not mean that whole space program is "go" in Flight Gear.
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 583
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby Thorsten » Sat Mar 24, 2012 7:17 pm

There is no "something" in rocketry. There is "go" and "no go".


There was Mercury before Gemini before Apollo, and there was a reason to that (sorry to vitos, I am much more familiar with the US space program).

Right now, we can get into low orbits, and we can do some very basic orbital maneuvering (I did a raising of the orbit to 800 km, and today I did an injection into a circumpolar orbit which is just barely possible to 300 km, and I wonder if one can reach a retrograde stable orbit at all). So we are in the Mercury phase. Next thing we want to demonstrate is that we can synchronize orbits with other objects, that we can dock at a space station and that we can do more sophisticated orbital maneuvering and reach higher orbits. That's Gemini, and we are not there yet.

On the way, sometimes we change technology. The Mercury program had a much weeker launch vehicle than the Apollo program. The space suits changed quite dramatically, and so did the amount of control given to the Astronauts. So the something is - we can demonstrate that we reach a goal, we can formulate clearly what is needed for the next step, and we find the support by demonstrating that our next step is reachable. No one designed the Saturn V before the Mercury program and decided to skip Gemini.

Don't see it as a hack, see it as a module which serves its purpose for now - we can always replace it if we need a better one.
Thorsten
 
Posts: 10097
Joined: Mon Nov 02, 2009 8:33 am

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby vitos » Sat Mar 24, 2012 7:59 pm

Thorsten wrote in Sat Mar 24, 2012 7:17 pm:There was Mercury before Gemini before Apollo, and there was a reason to that (sorry to vitos, I am much more familiar with the US space program).


Project Merucry was not "something". It was project Mercury, and it was "go" more or less. Right now I would want to know why it drops to 1fps here sometimes still, with every option off, with Earthview started or stopped. If reality would drop to 1 frame per second to one of Brave Seven then we would have one more guy in clinic and long delay of any manned space program.
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 583
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby Hooray » Sun Mar 25, 2012 12:53 am

vitos wrote in Sat Mar 24, 2012 7:59 pm:Right now I would want to know why it drops to 1fps here sometimes still, with every option off, with Earthview started or stopped.


Use the system monitor and the OSG on screen stats to check where this is happening: http://wiki.flightgear.org/Howto:_Use_t ... em_monitor

Also, for testing purposes, you could remove aircraft-specific Nasal code to check if the problem persists or not, to see if the problem is related to aircraft-specific Nasal scripts. To check the performance overhead of the EarthView code, you can add systime() calls to the beginning and end of all main loops/functions, which would tell you how much time is spent there. You can use setprop to publish the timing info via the property tree.
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: 11267
Joined: Tue Mar 25, 2008 8:40 am

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby jonsberndt » Sun Mar 25, 2012 3:28 am

Thorsten wrote in Sat Mar 24, 2012 10:12 am:Hooray, going to moon is *not* primarily a rendering question - it is a question of the numerical stability of the FDM. At distances of a million kilometers, even small rounding errors tend to become very large over time. Most people are likely not to sit 3 days in front of their computer but do the trip in fast-forward time. Yet the spacecraft is in vacuum, there is *no* damping force for any tumbling or other motion, so you have to ensure that the spacecraft motion is accurately computed across a really large distance in fast-forward time without you emerging in wildly spinning motion. At the same time, you have to solve a multi-body gravitational problem to some accuracy. Mars is worse by about two orders of magnitude.

I'm not convinced that JSBSim is up to that out of the box.

...



I think there's pretty good odds that you're right on that. :-) It's certainly not something I expect to ever address!

Jon
Jon S. Berndt
Development Coordinator
JSBSim Project
http://www.JSBSim.org
http://www.facebook.com/jsbsim
User avatar
jonsberndt
 
Posts: 205
Joined: Tue Aug 07, 2007 1:44 am
Location: Westminster, Colorado

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby omega95 » Sun Mar 25, 2012 5:28 am

jonsberndt wrote in Sun Mar 25, 2012 3:28 am:Hooray, going to moon is *not* primarily a rendering question - it is a question of the numerical stability of the FDM. At distances of a million kilometers, even small rounding errors tend to become very large over time. Most people are likely not to sit 3 days in front of their computer but do the trip in fast-forward time. Yet the spacecraft is in vacuum, there is *no* damping force for any tumbling or other motion, so you have to ensure that the spacecraft motion is accurately computed across a really large distance in fast-forward time without you emerging in wildly spinning motion. At the same time, you have to solve a multi-body gravitational problem to some accuracy. Mars is worse by about two orders of magnitude.

I'm not convinced that JSBSim is up to that out of the box.


Well, can we come up with a new space-specific Flight Dynamics Model for it then? I mean, FG started with UUIC... YASim and JSBSim came up later, right? (Sorry, if I'm interfering in this, I'm just really interested in Astronautical Science) As there's absolutely no medium up there, we won't have to worry about the metrics (DATCOM model), just the propulsion and weights. Basically, it should keep going straight and maintain speed when you get it to go in a direction. Then, you have to consider gravitational fields due to other bodies in space, like planets, the planets' moons, the Sun and possibly asteroids. I know that many space craft use other gravitational fields along with accurate propulsion to maximize acceleration. For example, the GRAIL project includes 2 satellites on a trans-lunar flight which is not exactly a straight trip.. It uses the earths gravitational field in the last orbit to shoot itself out in that direction.

Such space flights would be pretty neat in FlightGear but would require immense planning and you'd need to do a lot of research before you can do a space trip. And if you're determined, sitting 3 days in front of a computer isn't really a problem here... (Well, it starts turning out as a problem when you do stuff like what the GRAIL project does... 3 months to the moon! Takes a lot of time but REALLY efficient in terms of fuel)

And like the scenery switches to orbital terrain after a certain altitude, we could switch to this new "SFDM" (Space Flight Dynamics Model) after a certain altitude too, or maybe even less but have it's effect based on medium density around you.

It'd be pretty easy to do something like this with Nasal, but a separate Hard Coded SFDM would be much better.

Btw, I'd like to know if not being able to go past 150 km (without EarthView) is JSBSim's "fault"... As I can easily go over that with a UFO... :|

Cheers. :)
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby Thorsten » Sun Mar 25, 2012 6:40 am

Btw, I'd like to know if not being able to go past 150 km (without EarthView) is JSBSim's "fault"... As I can easily go over that with a UFO...


No, it's the fault of a Flightgear atmosphere definition. The patch in the first post shows how to add a 'space' layer and remove the restriction. The ufo FDM simply doesn't feel any atmosphere effects, that's why it flies fine to higher altitudes, but the lack of atmosphere still causes rendering artefacts.

Well, can we come up with a new space-specific Flight Dynamics Model for it then?


Yes, we can do that. But I repeat, the issues are not the equations of motion - they're easy to write down and code. The problem is to solve them numerically in a long-term stable way so that fast-forward in time works, and Nasal (being tied to graphical frames) is particularly troublesome for this task.

But as a next step, I would suggest that the AI system is expanded to allow to place AI objects in a stable orbit with orbital parameters to be determined in the AI scenario xml. Then we need the instruments to display such information and the tools to in-simulation calculate launch windows, orbital intercept points, the time window for tilting the orbital plane, and these things.

In other words, we need the instruments to do precise orbital maneuvering around earth before even thinking to leave earth orbit, because if we can't compute a launch trajectory to ISS, we can't compute the ejection trajectory to moon or any correction burns either. Having a deep space FDM right now is useless for us, because we can't even test it in a reasonable way.
Thorsten
 
Posts: 10097
Joined: Mon Nov 02, 2009 8:33 am

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby vitos » Sun Mar 25, 2012 7:00 am

Hooray wrote in Sun Mar 25, 2012 12:53 am:Use the system monitor and the OSG on screen stats to check where this is happening


Aha. What can I say? There is glitches in most of systems here and there, but problem is in graphics. It takes more then second to account next scene. And one thing is important: when I set it on pause, then, after some time, it starts to render paused scene very fast. It's not an issue in my videocard performance, there is problem in way it accounts next scene graphics, since not so many things changes in stable flight with Earthview on. It possible that lag caused by reaccounting all lighting very exactly any frame, and, since there is a lot of surfaces in "Vostok", it takes long time to do so, but why it not sets to glitchy 1fps regime right from beginning then, and why it runs at other speeds in orbital flight sometimes, as 4fps or even 15fps? So, there is serious problem in graphics, in OSG itself or blocks that uses it. Maybe it's not clears video memory fast enough, maybe something else. As I had mentioned previously, that problem surely will arise later then more things will be added in FG, not in spaceflight only, but all over da house.

Maybe someone will turn from dreaming about space flights future to fixing that.

By the way, it's one of points because of what things as space flight is needed, even if all seems to be ok without it. Such futuristic things is very useful for checking out problems that will arise later, to fix it before all around would become too complicated.
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 583
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby Hooray » Sun Mar 25, 2012 3:07 pm

The problem is to solve them numerically in a long-term stable way so that fast-forward in time works, and Nasal (being tied to graphical frames) is particularly troublesome for this task.


Yes, that's true (but that would also apply to other FDMs such as YaSim or JSBSim) - one would need to run the "SFDM" decoupled from the frame rate to get better and more deterministic accuracy, i.e. by using a separate process (or a Nasal worker thread) and by only synchronizing the FDM outputs at FG frame rate, so that the FDM computations would be run separately, but FlightGear would read the FDM outputs (such as velocities, position, orientation) at frame rate from "global" variables that are written to by the worker thread (at much higher rates) - that way, the accuracy of the FDM computations would not be affected by your frame rate anymore.

FlightGear's simulation time property would then need to be linked to another global variable that is read by the worker thread to determine the time speed-up factor.

Thorsten wrote:But as a next step, I would suggest that the AI system is expanded to allow to place AI objects in a stable orbit with orbital parameters to be determined in the AI scenario xml.


Yes, this makes absolutely sense. But I am not sure if you even need to expand the C++ AI system: you could just as well use a Nasal script (think tanker.nas) to do exactly that - but you would also need to decouple the placement-computations from the actual visualization code to ensure better accuracy, which then uses the results from the worker thread rather than being framerate-limited.
The script's main loop code would just run at frame rate and copy the results back into the main FG property tree where the 3D model could be positioned and animated properly.

As you know, many of the more complex AI scenarios are no longer directly based on Durk's original AI scenario system, but instead use Nasal scripts to handle the logic and only use the C++ code as low level work horses.

I mean, there's a fixed set of required parameters to set up an object for LEO or GEO.
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: 11267
Joined: Tue Mar 25, 2008 8:40 am

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby vitos » Sun Mar 25, 2012 5:45 pm

Hooray wrote in Sun Mar 25, 2012 3:07 pm:or a Nasal worker thread


I would really want to look on guy who could start to make highly precise celestial dynamics on base of unmantained second level interpreter language in situation of free choice. It's not personal, it's professional interest.

Image
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 583
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 0 guests