Re: [Flightgear-devel] FG git (was Sport Model)
On 07/06/2007 01:12 AM, Pigeon wrote: >> For quite a while I've been using git to keep track of FlightGear >> files. Using git instead of CVS is like having a sports car instead >> of a skateboard. > > All good :) :-) > I notice you're hosting git over http, which is usually much slower > than using git-daemon. Yes, git-daemon has many advantages. I went with http strictly as a stopgap. The http price is very low for me, and the folks who sell this http service don't sell git-daemon service. > I have mine setup at: > > git://pigeond.net/flightgear/flightgear.source.git/ Would you be interested in pulling the sport branch into that repository? > For those interested I also have gitweb at http://pigeond.net/git/ Ah, very useful. (I have a private gitweb, but I'm not in a position to export it to the world.) Last month there were a lot of people asking questions about the CVS logs. I reckon many of those questions could have been answered very conveniently via a look at the gitweb. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG git (was Sport Model)
> For quite a while I've been using git to keep track of FlightGear > files. Using git instead of CVS is like having a sports car instead > of a skateboard. All good :) I've been doing the same thing for FG and SG (and fgms if that matters). >time git-pull http://www.av8n.com/repo/fgs/.git origin:origin >## less than a minute >time git-pull http://www.av8n.com/repo/fgs/.git sport:sport I notice you're hosting git over http, which is usually much slower than using git-daemon. I have mine setup at: git://pigeond.net/flightgear/flightgear.source.git/ For those interested I also have gitweb at http://pigeond.net/git/ Pigeon. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 787 Seg fault
On 07/06/2007 12:39 AM, Innis Cunningham wrote: > A quick check of my system would indicate that the > file fglrx_dri.so or anything starting with fglrx is not > present on my system. That's the end of that story. Time for a new story. Suggestion: Recompile all of FG with debugging symbols turned on, if they are not already. Hint: make clean CXXFLAGS="-g" ./configure make Then run fgfs under gdb. When it dies, use the "where" command to get a stack trace. Study the stack trace and/or submit it to this list. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 787 Seg fault
Thanks John A quick check of my system would indicate that the file fglrx_dri.so or anything starting with fglrx is not present on my system.My understanding of Linux is not strong but from what I can recall fglrx is connected with the ATI graphics drivers and I am using Nvidia.The thing is I have not had this problem with any other aircraft in the cvs that I have tried so far. John Denker writes > >On 07/05/2007 10:04 PM, Innis Cunningham wrote: > > would just like to know how I fix it. > >Basic idea: The problem is in the fglrx_dri.so module >that is part of the X11 system. (It is not part of >FlightGear.) I don't know the details, but I get the >impression it makes wild memory references, so that >almost any symptom is possible. > >Procedure: > >## Find the thing: > locate fglrx_dri.so > >## Hope there is only one, or if multiple ones, >## hope they all symbolic_link to the same place. >## >## In any case, find out which one is being loaded >## by your X server. Reading the X server logs >## should help. I have no idea where the X server >## logs are on your system; your man pages should >## say. > > >## Go to the appropriate directory > cd $wherever > >## Make an archival copy: > cp fglrx_dri.so fglrx_dri.so.orig > >## Make a patched version: > sed s/_ZNSt6vectorIiSaIiEE7reserveE/_ZNSt6vectorIiSaIiEE7reserveX/ \ > fglrx_dri.so.orig > fglrx_dri.so > >## Restart your X server. > >## As the saying goes, it might not work right, but it >## ought to work different now. Thanks for your help Cheers Innis _ Advertisement: Search for local singles online at Lavalife http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%26a%3D29555&_t=764581033&_r=email_taglines_Search&_m=EXT - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NavOps (was: Programming "Style")
On 7/5/07, Andy Ross <[EMAIL PROTECTED]> wrote: Thomas Förster wrote: > which reminds me of: > The Zen of Python (by Tim Peters) > Probably a bunch of good ideas for every language. Yup, great advice. Pity python forgot about it: Hehe, something similar came to mind here too, but you beat me to it. :-) Greetings from Kalamazoo, MI after a day of driving with 4 adults and 4 kids in a single minivan! One highlight from the day is that we stopped in to tour the NavOps submarine simulator in Gary, IN. Neat stuff, they are building a full size mockup of a couple rooms of a "peaceful/humanitarian" submarine. The goal of the simulator mission is to do interesting missions ... such as save the whales from the oil spill. It is intended as a tool to trick 5th graders into learning lots of math and science concepts while they are having fun. And it seems to work really well. The math/science test scores in that local school district seem to take a big jump at 5th grade ... has some higher ups wondering what's going on over there. :-) The plan is to add 6 FlightGear stations to the cooperative simulation so that the various missions can have some sort of air support. Neat stuff! (Sorry to hijack the code styling thread ...) Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Computer with HP48G
On Thu, 2007-07-05 at 11:23 -0300, Thiago Drechsel wrote: > Does anybody know a good program that emulates a Flight Computer (e.g > E6B) on HP48G? > > I know this question isn't related to FG, but with so many aviation > fans, I think I can find a good answer :-) > > Thanks in advance. > > > Thiago Oh, an E6B... The only way to go is http://www.ben.com/flying/e6b/ Ron - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sport Model (was: altitude above 61831 feet) (was: AWOS) (was: instrument flags) (was: various other things)
On 7/5/07, Csaba Halász <[EMAIL PROTECTED]> wrote: > Hi John! > > Impressive list of features, thanks. > During my IFR flights I also noted the barber-pole and the localizer > service volume issues, nice to see them fixed. The whole atmospheric > thing sounds terribly important, too, but I lack knowledge to judge > that. I too find the vast majority of this feature list *very* desirable. I have been using FlightGear as a sort of serious self-study in preparation for the time when I can afford to get my private pilot certificate, and in my "ground school" self study, I have noticed these areas where FG could improve, and I'm pleased to see this fine work, which I hope finds its way into CVS. -- Hans Fugal Fugal Computing - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sport Model (was: altitude above 61831 feet) (was: AWOS) (was: instrument flags) (was: various other things)
Hi John! Impressive list of features, thanks. During my IFR flights I also noted the barber-pole and the localizer service volume issues, nice to see them fixed. The whole atmospheric thing sounds terribly important, too, but I lack knowledge to judge that. -- Csaba - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fancy lvalues in c++
On 7/6/07, John Denker <[EMAIL PROTECTED]> wrote: > Attached is a simplified, somewhat academic example to illustrate > what I'm talking about. Would be a lot better if it worked for any number of arguments. Looks nice, though. Variable arguments using "..." don't work with references and I couldn't come up with any other solution. Something like a "GetFirstElements(some->list, &xx, &yy, &zz)", while not that elegant, but could work. > manifestly thread-safe Wouldn't count on that, unless the list copy constructor is thread-safe (don't think so). Also, copying a whole list just to get the first two elements is a waste of resources. -- Csaba - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 787 Seg fault
On 07/05/2007 10:04 PM, Innis Cunningham wrote: > would just like to know how I fix it. Basic idea: The problem is in the fglrx_dri.so module that is part of the X11 system. (It is not part of FlightGear.) I don't know the details, but I get the impression it makes wild memory references, so that almost any symptom is possible. Procedure: ## Find the thing: locate fglrx_dri.so ## Hope there is only one, or if multiple ones, ## hope they all symbolic_link to the same place. ## ## In any case, find out which one is being loaded ## by your X server. Reading the X server logs ## should help. I have no idea where the X server ## logs are on your system; your man pages should ## say. ## Go to the appropriate directory cd $wherever ## Make an archival copy: cp fglrx_dri.so fglrx_dri.so.orig ## Make a patched version: sed s/_ZNSt6vectorIiSaIiEE7reserveE/_ZNSt6vectorIiSaIiEE7reserveX/ \ fglrx_dri.so.orig > fglrx_dri.so ## Restart your X server. ## As the saying goes, it might not work right, but it ## ought to work different now. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 787 Seg fault
Hi John John Denker writes On 07/05/2007 09:49 PM, Innis Cunningham wrote: > And the fix is.??? http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11124.html That's a little bit terse; if you need more details, please ask again. Was not trying to be terse would just like to know how I fix it. Cheers Innis _ Advertisement: Crowded House Time on Earth catch them live in the USA! http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=800&referral=hotmailtagline&URL=http://music.ninemsn.com.au/compIntro.aspx?compId=2416 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 787 Seg fault
On 07/05/2007 09:49 PM, Innis Cunningham wrote: > And the fix is.??? http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11124.html That's a little bit terse; if you need more details, please ask again. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 787 Seg fault
Thanks Hans Hans Ulrich Niedermann writes > >Innis Cunningham wrote: > > > I get a segmentation fault during aircraft loading of the 787 from > > cvs is anyone else seeing this. At the cli all I get is > > segmentation fault(core dump) any ideas. > > Its on Ubuntu 7.04 > >The issue with fglrx_dri.so and _ZNSt6vectorIiSaIiEE7reserveEm manifests >itself like that. And the fix is.??? Cheers Innis _ Advertisement: Make shopping exciting. Find what you want at www.eBay.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Frover%2Eebay%2Ecom%2Frover%2F1%2F705%2D10129%2D5668%2D323%2F4%2F%3Fid%3D6&_t=763807330&_r=email_taglines_EBAY&_m=EXT - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fancy lvalues in c++
On 07/05/2007 12:59 PM, Andy Ross wrote:
References can be lvalues, so it's possible to write functions whose
returned valued can be assigned.
True.
The examples are usually pretty
academic, but consider a sparse 2D array with a method like
int& element(int x, int y);
You can use this thing as element(3, 4) to get the value, but you can
also use:
array->element(3, 4) = 12345;
to *set* the value. Cute, huh? And utterly worthless.
Agreed. That example is academic and not a high-value item.
OTOH, the existence of a straw man does not preclude the
existence of somewhat more worthwhile instances.
I've seen code where lvalue-valued functions were put to
good use. In one case that springs to mind, the actual
application was more complicated, but an easy way to
appreciate the idea is:
Group(xx, yy) = some->list;
I'm sure some people will take this as evidence of my perversely
incompetent programming technique ... except that I didn't write
the code in question. It was designed by two of my friends, each
of whom had recently served as a representative to the ISO C++
standardization committee.
Attached is a simplified, somewhat academic example to illustrate
what I'm talking about.
/
// list-to-elements
//
#ifdef DOCUMENTATION
Objective: We want to assign:
Group(xx, yy) = foo;
where the RHS is a two-element list; we want the first element of the
list to be assigned to xx, and the second element of the list to be
assigned to yy. We want to do this in one statement, so that nothing
needs to be recomputed (or stored by the creature on the RHS), to make
it manifestly thread-safe.
We do not want to require any predeclared relationship between xx and
yy; we just put them together on the fly.
This sort of list-to-elements assignment is routine and natural
in perl. There are several ways of doing it in C++.
This way is reasonably convenient.
#endif /* DOCUMENTATION */
using namespace std;
#include
#include
typedef list LI;
class Group {
int* xptr;
int* yptr;
public:
// no default constructor:
Group();
// Constructor using two ints:
inline Group(int& xx, int& yy){
xptr = &xx;
yptr = &yy;
}
// Assignment operator, assigning from a list:
inline const LI& operator= (const LI& _rhs) {
LI rhs(_rhs);
if (rhs.size() > 0) {
*xptr = rhs.front();
rhs.pop_front();
}
if (rhs.size() > 0){
*yptr = rhs.front();
rhs.pop_front();
}
return _rhs;
}
};
int main(){
LI foo;
foo.push_back(123);
foo.push_back(456);
int xx(1);
int yy(2);
Group(xx, yy) = foo;
cout << xx << ", " << yy << endl;
}
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Sport Model (was: altitude above 61831 feet) (was: AWOS) (was: instrument flags) (was: various other things)
A few minutes ago, I explained how in environment.cxx, the model of the atmosphere could be extended up above 100,000 feet. Everything I said was true, but it was not the whole story. As I have pointed out previously, the model of the atmosphere in environment.cxx is bogus. By that I mean it contravenes the laws of physics. The problems are *not* noticeable if you confine your flying to -- sea-level airports, and/or -- ISA standard-day conditions of temperature and barometric pressure. Meanwhile, I continue to try to make FlightGear usable as a procedures trainer. In particular, consider the following small scenario: -- You are approaching an airport situated thousands of feet above sea level. -- There is non-ISA barometric pressure, even at nearby sea-level locations. -- There is non-ISA temperature. -- On approach, you tune up the AWOS (not ATIS) to get the relevant QNH i.e. "altimeter setting". -- Upon landing, you find that your altimeter agrees with field elevation, because the model of the air-column is correct, the altimeter is correct, and the ATIS algorithm is correct. Relative to the current CVS FG, this requires major modifications to several modules, including (but definitely not limited to) Environment/environment.cxx, Airports/apt_loader.cxx, and ATC/*.cxx, especially ATC/atis.cxx. (I fixed the altimeter months ago, and this is reflected in the current CVS.) If you want to have all these features, the easiest way is to pull down a copy of the _Sport Model_ of FG. (For details on this, see the "git" section, below. This is not meant to be a fork, as explained below.) Here is a partial list of the features current available in the _Sport Model_. 1:: Gremlins cause instruments and systems to fail at random times. The pilot gets to choose the MTBF. 2:: On the HSI, the heading card stops turning when "directional gyro" is not serviceable. (This is the hsi as used in the c182 and many other light aircraft.) 3:: On the HSI, the GS needle goes to the top (not the middle) when not serviceable. The previous behavior was a pilot-killer. 4:: On the HSI, the GS needle shows a flag (barber pole) when not serviceable. The previous behavior was a pilot-killer. 5:: On the HSI, the CDI needle shows a flag when not serviceable. The previous behavior was a pilot-killer. 6:: On the plain Nav head, the GS needle shows a flag when not serviceable. The previous behavior was a pilot-killer. 7:: On the plain Nav, the head CDI needle shows a flag when not serviceable. The previous behavior was a pilot-killer. 8:: AWOS is available at AWOS locations. (Previously only ATIS was implemented.) 9:: ATIS phraseology now more nearly conforms to international standard METAR pattern, and therefore to usual FAA practice.(*) Items marked with a (*) are fully implemented in the /text/ of the ATIS message, but the voiced version of the message is degraded by limitations of the FGFS built-in text-to-speech system. 10:: ATIS now reports sky condition.(*) 11:: ATIS now reports multiple layers of clouds, not just the lowest layer.(*) 12:: ATIS now takes field elevation into account when calculating sky condition and ceiling. 13:: ATIS now reports dewpoint.(*) 14:: ATIS now can handle negative quantities (temperature and dewpoint).(*) 15:: ATIS can now report report fractional-mile visibility.(*) 16:: ATIS now uses magnetic (not true) wind directions, as it should. 17:: ATIS generates correct runway number and suffix (nine right, one one left). 18:: ATIS can be received on nav frequencies, not just comm. 19:: Nothing bad happens if the same ATIS is tuned up on more than one receiver. 20:: ATIS can be updated at times other than at the top of the hour. 21:: ATIS listens for an "attention" signal, and responds changes in the weather by issuing a new ATIS message (somewhat like a "special observation"). 22:: ATIS volume now responds to radio volume setting. 23:: Area-related services (i.e. approach radar) are handled more-nearly consistently with radio-frequency related services. 24:: ATIS sequence-letter generation has been fixed. 25:: ATIS messages are now in the property tree, so they can be read e.g. via the http interface. 26:: The "clock" in the panel (as used in the default C172 and many other GA aircraft) can now be used as a resettable timer. Among other uses, this is useful for timing approaches. 27:: In the ambient pressure profile (which is the basis of aircraft altimetry), non-ISA temperature and pressure are supported, as required by the laws of physics. 28:: The altimeter now works up to much higher altitudes. 29:: Many enhancements to the X52 joystick interface. See Docs/README.X52 30:: The location-in-air popup can now be used without
Re: [Flightgear-devel] Flight Computer with HP48G
Sorry, I didn't understand that you need it for HP48G. Sorry. 2007/7/6, woodyst <[EMAIL PROTECTED]>: > I found this one that runs in linux: > > http://linux.softpedia.com/get/GAMES-ENTERTAINMENT/Simulation/jE6-B-15761.shtml > > 2007/7/6, woodyst <[EMAIL PROTECTED]>: > > Try this: http://www.navfltsm.addr.com/ve6b.zip > > > > I downloaded it from http://www.navfltsm.addr.com/ that is an > > excellent navigation tutorial. There is a reference to it in fgfs's > > manual. > > > > It's for windows but if you are a linux user like me you can execute > > it with wine. > > > > woodyst. > > > > 2007/7/5, Thiago Drechsel <[EMAIL PROTECTED]>: > > > Does anybody know a good program that emulates a Flight Computer (e.g E6B) > > > on HP48G? > > > > > > I know this question isn't related to FG, but with so many aviation fans, > > > I > > > think I can find a good answer :-) > > > > > > Thanks in advance. > > > > > > > > > Thiago > > > > > > - > > > This SF.net email is sponsored by DB2 Express > > > Download DB2 Express C - the FREE version of DB2 express and take > > > control of your XML. No limits. Just data. Click to get it now. > > > http://sourceforge.net/powerbar/db2/ > > > ___ > > > Flightgear-devel mailing list > > > Flightgear-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > > > > > > > > -- > > Woodyst. > > > > > -- > Woodyst. > -- Woodyst. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument-altimeter unable to indicate altitude above 61831 feet
On 07/05/2007 06:57 PM, gh.robin wrote:
When i opened that topic , it was to know if we could hope any FG update to
get an altitude instrument which can be able to indicate more than 61000 ft.
We have had a lot of discussion on it , but nothing which could give the right
answer.
Do we have to stay with that limitation => 61000 ft ?
No, we do not.
Back on 06/19/2007 03:20 PM, I sent a message Gérard off list, including
a patch to fix this, extending the existing model to over 100,000 feet.
Apparently the message got lost somehow.
Do we have to conclude that FG altitude instruments is unable to give the
right value?
As I explained on-list, there is nothing wrong with the altimeter.
I fixed the altimeter months ago.
The problem is in the model of the atmosphere, in environment.cxx,
where it computes the ambient pressure.
I will have more to say about this anon, but for now, here is
the patch again. It applies to today's CVS (offset one line).
--- src/Environment/environment.cxx 2007/06/19 18:58:22 1.1
+++ src/Environment/environment.cxx 2007/06/19 19:03:22
@@ -48,43 +48,50 @@
// Atmosphere model.
-// Copied from YASim Atmosphere.cxx, with m converted to ft, degK
-// converted to degC, Pa converted to inHG, and kg/m^3 converted to
-// slug/ft^3; they were then converted to deltas from the sea-level
-// defaults (approx. 15degC, 29.92inHG, and 0.00237slugs/ft^3).
-
-// Original comment from YASim:
-
-// Copied from McCormick, who got it from "The ARDC Model Atmosphere"
-// Note that there's an error in the text in the first entry,
-// McCormick lists 299.16/101325/1.22500, but those don't agree with
-// R=287. I chose to correct the temperature to 288.20, since 79F is
-// pretty hot for a "standard" atmosphere.
+// Calculated based on the ISA standard day, as found at e.g.
+// http://www.av8n.com/physics/altimetry.htm
-// Elevation (ft), temperature factor (degK), pressure factor (inHG)
+// Each line of data has 3 elements:
+// Elevation (ft),
+// temperature factor (dimensionless ratio of absolute temp),
+// pressure factor (dimensionless ratio)
static double atmosphere_data[][3] = {
- { 0.00, 1.00, 1.000 },
- { 2952.76, 0.98, 0.898 },
- { 5905.51, 0.96, 0.804 },
- { 8858.27, 0.94, 0.719 },
- { 11811.02, 0.92, 0.641 },
- { 14763.78, 0.90, 0.570 },
- { 17716.54, 0.88, 0.506 },
- { 20669.29, 0.86, 0.447 },
- { 23622.05, 0.84, 0.394 },
- { 26574.80, 0.82, 0.347 },
- { 29527.56, 0.80, 0.304 },
- { 32480.31, 0.78, 0.266 },
- { 35433.07, 0.76, 0.231 },
- { 38385.83, 0.75, 0.201 },
- { 41338.58, 0.75, 0.174 },
- { 44291.34, 0.75, 0.151 },
- { 47244.09, 0.75, 0.131 },
- { 50196.85, 0.75, 0.114 },
- { 53149.61, 0.75, 0.099 },
- { 56102.36, 0.75, 0.086 },
- { 59055.12, 0.75, 0.075 },
- { 62007.87, 0.75, 0.065 },
+ { -3000.00, 1.021, 1.1133 },
+ { 0.00, 1.000, 1. },
+ { 2952.76, 0.980, 0.8978 },
+ { 5905.51, 0.959, 0.8042 },
+ { 8858.27, 0.939, 0.7187 },
+ { 11811.02, 0.919, 0.6407 },
+ { 14763.78, 0.898, 0.5697 },
+ { 17716.54, 0.878, 0.5052 },
+ { 20669.29, 0.858, 0.4468 },
+ { 23622.05, 0.838, 0.3940 },
+ { 26574.80, 0.817, 0.3463 },
+ { 29527.56, 0.797, 0.3034 },
+ { 32480.31, 0.777, 0.2649 },
+ { 35433.07, 0.756, 0.2305 },
+ { 38385.83, 0.752, 0.2000 },
+ { 41338.58, 0.752, 0.1736 },
+ { 44291.34, 0.752, 0.1506 },
+ { 47244.09, 0.752, 0.1307 },
+ { 50196.85, 0.752, 0.1134 },
+ { 53149.61, 0.752, 0.0984 },
+ { 56102.36, 0.752, 0.0854 },
+ { 59055.12, 0.752, 0.0741 },
+ { 62007.87, 0.752, 0.0643 },
+ { 65000.00, 0.752, 0.0557 },
+ { 68000.00, 0.754, 0.0482 },
+ { 71000.00, 0.758, 0.0418 },
+ { 74000.00, 0.761, 0.0362 },
+ { 77000.00, 0.764, 0.0314 },
+ { 8.00, 0.767, 0.0273 },
+ { 83000.00, 0.770, 0.0237 },
+ { 86000.00, 0.773, 0.0206 },
+ { 89000.00, 0.777, 0.0179 },
+ { 92000.00, 0.780, 0.0156 },
+ { 95000.00, 0.783, 0.0135 },
+ { 98000.00, 0.786, 0.0118 },
+ { 101000.00, 0.789, 0.0103 },
{ -1, -1, -1 }
};
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Computer with HP48G
I found this one that runs in linux: http://linux.softpedia.com/get/GAMES-ENTERTAINMENT/Simulation/jE6-B-15761.shtml 2007/7/6, woodyst <[EMAIL PROTECTED]>: > Try this: http://www.navfltsm.addr.com/ve6b.zip > > I downloaded it from http://www.navfltsm.addr.com/ that is an > excellent navigation tutorial. There is a reference to it in fgfs's > manual. > > It's for windows but if you are a linux user like me you can execute > it with wine. > > woodyst. > > 2007/7/5, Thiago Drechsel <[EMAIL PROTECTED]>: > > Does anybody know a good program that emulates a Flight Computer (e.g E6B) > > on HP48G? > > > > I know this question isn't related to FG, but with so many aviation fans, I > > think I can find a good answer :-) > > > > Thanks in advance. > > > > > > Thiago > > > > - > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > ___ > > Flightgear-devel mailing list > > Flightgear-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > > > -- > Woodyst. > -- Woodyst. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Computer with HP48G
Try this: http://www.navfltsm.addr.com/ve6b.zip I downloaded it from http://www.navfltsm.addr.com/ that is an excellent navigation tutorial. There is a reference to it in fgfs's manual. It's for windows but if you are a linux user like me you can execute it with wine. woodyst. 2007/7/5, Thiago Drechsel <[EMAIL PROTECTED]>: > Does anybody know a good program that emulates a Flight Computer (e.g E6B) > on HP48G? > > I know this question isn't related to FG, but with so many aviation fans, I > think I can find a good answer :-) > > Thanks in advance. > > > Thiago > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- Woodyst. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.9.11-pre1: Some weird behaviors on reset
Hi Hans, > I'm on OS X, though not using the XCode patches (just stock flightgear > with the fixes I discussed in an earlier thread for compilation and > linking). I tried to reproduce these issues in fg/plib CVS (which is > as close to pre1 as I get at the moment), see below. I would have > also tried it in linux, but I don't have a linux box handy this week > or the next. Thanks for your report, and I appreciate your trying to test this on linux box. I think the patches you've applied were enough to discuss this. Only the patch I applied other than we've discussed is the one that fixed the problem that the sun is not rendered correctly. This is the issue on 0.9.10 and it might be already fixed. plus this patch doesn't affect anything about these problems. >> 1) an aircraft is under a carrier when resetting flightgear (with >> Shift-ESC). 100% reproducible > (snip) > I do see the same thing. I'm not even roughly familiar with carrier > operations in FG, but might it be that the carrier moved? In any case > this doesn't sound like an OS X issue. Right, but I don't think this is because the carrier moved since the aircraft was right under the carrier. It happens only on pre1, but not on 0.9.10 or fg-CVS/OSG. >> 2) Resetting let you see the "flying instruments." - seen only twice >> http://macflightgear.sourceforge.net/home/development-notes/ >> devnote-jul-03-2007/ > (snip) > I haven't been able to reproduce this, but it looks pretty spectacular > in your screenshot. :) Yeah, I was a bit excited when I saw it for the first time like "wow, this can be an easter egg." but It's not safe to fly without these instruments, plus I don't think I can control the flying instruments :-p >> 3) Several resets give you tons of "DList stack overflow" - 100% >> reproducible (snip) > I haven't been able to reproduce this (I tried c172p - I reset it > about 15 times). Perhaps it's a bug that's been fixed since > 0.9.11-pre1. Very glad to hear that. I used the fg-0.9.11-pre1 tar ball (from the web site), SimGear-0.3.11-pre1 tar ball (from its site), and PLIB/CVS-HEAD. If you tried this with the latest source files of flightgear on the PRE_OSG_PLIB branch (and these are not OS X specific things), then some of thes can be fixed on the next pre release. I'll test these with the latest source on the PRE_OSG_PLIB branch, maybe some time in the next week. Tat - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument-altimeter unable to indicate altitude above 61831 feet
On Mon 18 June 2007 10:06, Stefan Seifert wrote: > John Denker wrote: > > If you want to know exactly why FGFS poops out at approximately > > 62,000 feet, look at line 88 of Environment/environment.cxx > > > >You can contrast that with the ISA table that goes up to 278,000 > >feet as found e.g. at the top of > > http://www.av8n.com/physics/altimetry.htm > > Just for my understanding: this table is only used for instrumentation, > isn't it? > Both JSBSim and YASim have their own atmosphere models including such > tables where JSBSim goes up to 259186ft and YASim to 18900m (62008ft). > > Reminds me that I should test again, if it's still possible to reach > Earth orbit and do interstellar travel with an F-16 ;) Maybe this got > better in newer JSBSim versions. But it's pretty strange, since JSBSim > should be the FDM to do this right with the table up to 260Kft... > > Nine > > Hello everybody, Tell me if i am wrong, When i opened that topic , it was to know if we could hope any FG update to get an altitude instrument which can be able to indicate more than 61000 ft. We have had a lot of discussion on it , but nothing which could give the right answer. Do we have to stay with that limitation => 61000 ft ? Do we have to conclude that FG altitude instruments is unable to give the right value? Or is it only a bug which could be solved ? Thanks for the answer -- Gérard - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.9.11-pre1: Some weird behaviors on reset
I'm on OS X, though not using the XCode patches (just stock flightgear with the fixes I discussed in an earlier thread for compilation and linking). I tried to reproduce these issues in fg/plib CVS (which is as close to pre1 as I get at the moment), see below. I would have also tried it in linux, but I don't have a linux box handy this week or the next. On 7/3/07, Tatsuhiro Nishioka <[EMAIL PROTECTED]> wrote: > Hi forks, > > I'm working on building 0.9.11-pre1 on Mac OS X. > Though I've successfully built it last night, I've encountered some > strange behaviors including: > > 1) an aircraft is under a carrier when resetting flightgear (with > Shift-ESC). 100% reproducible > I've tested it with p51d, c172p, and A6M2 for 0.9.10 on Nimitz. None > of them can be on the deck on reset. > There was a discussion on carrier - sea level issue, so this might > have something to do with that. I do see the same thing. I'm not even roughly familiar with carrier operations in FG, but might it be that the carrier moved? In any case this doesn't sound like an OS X issue. > 2) Resetting let you see the "flying instruments." - seen only twice > Right after a reset, Instruments on c172p fly away. I don't know it > happens on different aircraft. I haven't tested it with > other aircraft yet. (you can see the images from: > http://macflightgear.sourceforge.net/home/development-notes/devnote-jul-03-2007/ I haven't been able to reproduce this, but it looks pretty spectacular in your screenshot. :) > > 3) Several resets give you tons of "DList stack overflow" - 100% > reproducible > When I reset FlightGear (by pressing Shift-ESC) 4 or 5 times, tons of > "WARNING: DList stack overflow!" > messages come up. It happened with p51d, c172p, and maybe some other > planes. I haven't been able to reproduce this (I tried c172p - I reset it about 15 times). Perhaps it's a bug that's been fixed since 0.9.11-pre1. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (addressing especially Ralf)
Sebastian Bechtold schrieb:
>>
>>
>>
...
> -want- to break the current concept of texture display. I don't want
> to break anything else, but I definitely want to break this. It's all
> about breaking this ;).
>
> I want to use large patches of texture which are applied to the ground
> mesh, completely ignoring the materials of the triangles. All I need
> is to place them correctly, so that a road which is drawn onto
> a texture file which represents a certain area in the world apperes
> at the correct place in the simulator.
>
> ...
>
> Cheers,
>
> Sebastian
>
>
Hi all,
Sebastian's plan to make the ground texturing independend from the mesh
(triangles) seems to be a very good way to improve the FG scenery.
If I understand it right, nothing would be changed from the actual state
in those regions of the world where no special development has taken
place, you just have the familiar "standard" ground textures.
But in selected areas scenery designers could create special textures
and they will be drawn elevation-mesh independent instead of the basic
triangle associated textures. You could place whatever you like -
improved FG basic textures, selfcreated ones or even photorealistic ones.
We should have something like my good old Fly! II sim had implemented -
an automatic texture converter where you give the lat/lon coordinates of
ie all 4 corners (to avoid projection problems) of your custom texture
and the process splits your texture into the right sub-sizes, ie fitting
to the given mesh-triangle sizes - which would make the code-changes
much easier as the display would use nearly the same routines as now.
And the process should be able to create "soft" overlapping ("merging")
of the new and old regions (if wished).
So this could be a pretty easy produre for pure users - create a
groundtexture, small or big, run the programm with the right coordinates
and get the result after some time plugged into the FG scenery system.
And there should nearly no performance loss as the work is not done
while running the sim - FG only has to watch where "special" regions are
to be displayed.
Just my thoughts about it, there might be a lot of more practicable
solutions, but doing some improving work on ground textures display
should be supported.
Regards
Georg EDDW
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
On 07/05/2007 05:26 PM, Andy Ross wrote: > But, all that being said: yes, you found a bug. The > spans-are-too-wide problem* is caused by a sign bug when calculating > the "extra" amount to distribute between spanned cells. Fixed in CVS. Thank you for fixing the bug. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to, the terrain mesh? (addressing especially Tim Moore)
Tim Moore wrote: > This is going to be messy; you're going to have to dive into the code of > FlightGear, SimGear, and probably TerraGear too. > > The terrain mesh created by TerraGear has texture coordinates that are > appropriate for the surface texture in each triangle. You're either > going to have to generate alternate meshes -- with a more uniform > texture coordinate scheme -- from TerraGear, or you're going to need to > use OpenGL TexGen stuff to generate the appropriate texture coordinates > at runtime. Remember that all the geometry is in earth-centric > coordinates :) > > So, I don't mean to be discouraging because I think this is ultimately > the right approach in terms of bumping up terrain detail and > implementing terrain and texture LOD, but you have a lot of hacking > ahead of you. Then it should be so. I'd really like to help making FlightGear better, and of course I want to improve the things which, in my option, need it most. Since this one is quite high on my list of ideas for improvements, and nobody else seems to work on it, I want to do it. Or at least try it. I believe you when you say that it is going to be complicated, but wouldn't it be boring if it wasn't ? I have to admit that at the moment, I have not the slightest idea about any coordinates and stuff, but I'm willed to learn :). (And well, maybe I shouldn't present myself as being so helpless with this. Ok, I'm completely new to the FlightGear source code and also to 3D programming, but I think I'm at least not the asolutely worst programmer in the world, I found that I can read and understand the FlightGear code a lot faster than I expected before, and I know how to use a few development tools to untangle it and get a picture of how everything works together. Again, I think this should be possible with some help from others.) Cheers, Sebastian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
John Denker wrote: > 4) I did not snipe. I did not sneer. I reported the facts as I > observed them. If observations conflict with your expectations, > what should I do? John, please. You asked for a new feature that already exists, and when corrected immediately reported that it doesn't work and isn't used, despite the fact that it does and is. You even hid behind (no joke) a grammar excuse (as if "colspan" and "rowspan" are so different that one couldn't possibly be an example of the other, or that you couldn't think to grep for just "span"). When told that the core of the "columns too small" problem was your use of an explicit width and height, you bizarrely claimed that it wasn't, in clear contradiction to reality. At any of those steps, an appropriate response might have plausibly included the phrase "thank you", or at least "OK, but...". Instead, it's been one one redirection after another. I tell you one thing (*correct* advice, it should be noted) and am immediately hit back with a counterclaim. Basically, you've been a jerk from the beginning to end of this process and frankly I don't really want to work with you. Your contributions aren't valuable enough to be worth the emotional effort. Some jerks can prosper in collaborative projects because of the utility of their work (c.f. Melchior, Mathias, maybe me if I still count as a core developer). You aren't in that league, honestly, and you might find that a little humility would produce better service. But, all that being said: yes, you found a bug. The spans-are-too-wide problem* is caused by a sign bug when calculating the "extra" amount to distribute between spanned cells. Fixed in CVS. Andy * As distinct from the layout-is-too-narrow problem you reported earlier, or the "there are no spans" non-problem you originally reported. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (addressing especially Ralf)
Hi, the graphic at the end of your steps should be no or very small problems. To make "pseudo aerial photographs" can be done very easy. Your idea sounds good now - but one curious question I have: when it really works at runtime, we could do something like the livery-changing for the textures? As an example, when we have rain - the runway will look wet? When it's snowing, the landscape will be white? Good luck HHS --- Sebastian Bechtold <[EMAIL PROTECTED]> schrieb: > > > > Message: 8 > > Date: Thu, 05 Jul 2007 17:12:49 +0200 > > From: Ralf Gerlich <[EMAIL PROTECTED]> > > Subject: Re: [Flightgear-devel] How to apply > different texturing to > > the terrain mesh? > > To: FlightGear developers discussions > > > > Message-ID: <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset=us-ascii > > > > Hello Sebastian! > > > > Sebastian Bechtold wrote: > > > >> > [...] but my plan would, for example, make it > possible > >> > to render markings onto them, or draw softly > rounded curves. > >> > > > > I'm specifically interested in the "markings" part > (although I'm also > > curious at how you want to implement softly > rounded curves without > > breaking the current concept of texture display). > > > I -want- to break the current concept of texture > display. I don't want > to break anything else, but I definitely want to > break this. It's all > about breaking this ;). > > I want to use large patches of texture which are > applied to the ground > mesh, completely ignoring the materials of the > triangles. All I need > is to place them correctly, so that a road which is > drawn onto > a texture file which represents a certain area in > the world apperes > at the correct place in the simulator. > > > This might require information which is currently > not in the scenery > > files, such as the actual position of the > centerline and width of the > > linear features. The triangles don't represent > this information anymore, > > however it is available from the scenery sources > (e.g. the scenery > > database). In general, making this information > available in a suitable > > format shouldn't be a technical problem (maybe one > of available manpower > > for implementing the stuff required, but that only > means that it may > > take longer). > > > Exactly this is the idea. I have already talked with > Martin about this > off-list. The plan would be to include the raw > (meaning not > compiled/digested > into the .btg files) vector data into a scenery file > and auto-generate > the textures using this data. Then you could achieve > things like > road markings and smooth curves with some more or > less simple > 2D graphics programming. But however - first, I have > to realise this > texture mapping stuff. Without that, all further > thoughts about how > to generate the textures are useless. > > Another possibility - at least for simple roads - > would be to add a > > centerline to the road texture and make TerraGear > create an appropriate > > texture mapping similar to how it is done > currently in genapts for the > > taxiways. Unfortunately, the part of TerraGear > which creates the texture > > coordinates does not know anymore that the polygon > it is currently > > operating on originally was a linear feature > (blown up according to its > > width to a polygon). So this approach might > require some reorganisation > > of the TerraGear architecture. Given that the > current architecture is > > quite complex (mainly due to the fact that the > task at hand is complex) > > I don't think this is feasible without risking to > break anything to a > > larger extent. > > > That's one reason why I don't want to touch > terragear. The second is > that I would like to make it possible to modify the > ground textures > without having to regenerate the scenery. > > When we're discussing about runtime creation of > textures we might also > > get into discussing blending of ground textures. > In that case, we should > > keep in mind that in reality not all types of > landcovers actually blend > > into each other. > > > > When flying overhead forest areas - especially > dense forest - these > > typically do not blend with surrounding > agricultural or greenland areas, > > at least not in "civilised" areas where man tends > to create sharp > > corners by land usage. That's actually not related > to this specific > > discussion, but I wanted to note that before I > forget. > > > Yeah, I know. But well, that's more an artistic > question, not so much a > technical one. And as said by you (and also by me > above), it's not > related to this > first step of the plan. But anyway, you are surely > right. I have quite a > number > of thoughts about how to create realistic looking > "pseudo aerial > photographs". > If I should ever be successful with step 1, I'll > come back to you with > these. > > Cheers, > > Sebastian > > --
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (addressing especially Ralf)
> > Message: 8 > Date: Thu, 05 Jul 2007 17:12:49 +0200 > From: Ralf Gerlich <[EMAIL PROTECTED]> > Subject: Re: [Flightgear-devel] How to apply different texturing to > the terrain mesh? > To: FlightGear developers discussions > > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > Hello Sebastian! > > Sebastian Bechtold wrote: > >> > [...] but my plan would, for example, make it possible >> > to render markings onto them, or draw softly rounded curves. >> > > I'm specifically interested in the "markings" part (although I'm also > curious at how you want to implement softly rounded curves without > breaking the current concept of texture display). > I -want- to break the current concept of texture display. I don't want to break anything else, but I definitely want to break this. It's all about breaking this ;). I want to use large patches of texture which are applied to the ground mesh, completely ignoring the materials of the triangles. All I need is to place them correctly, so that a road which is drawn onto a texture file which represents a certain area in the world apperes at the correct place in the simulator. > This might require information which is currently not in the scenery > files, such as the actual position of the centerline and width of the > linear features. The triangles don't represent this information anymore, > however it is available from the scenery sources (e.g. the scenery > database). In general, making this information available in a suitable > format shouldn't be a technical problem (maybe one of available manpower > for implementing the stuff required, but that only means that it may > take longer). > Exactly this is the idea. I have already talked with Martin about this off-list. The plan would be to include the raw (meaning not compiled/digested into the .btg files) vector data into a scenery file and auto-generate the textures using this data. Then you could achieve things like road markings and smooth curves with some more or less simple 2D graphics programming. But however - first, I have to realise this texture mapping stuff. Without that, all further thoughts about how to generate the textures are useless. > Another possibility - at least for simple roads - would be to add a > centerline to the road texture and make TerraGear create an appropriate > texture mapping similar to how it is done currently in genapts for the > taxiways. Unfortunately, the part of TerraGear which creates the texture > coordinates does not know anymore that the polygon it is currently > operating on originally was a linear feature (blown up according to its > width to a polygon). So this approach might require some reorganisation > of the TerraGear architecture. Given that the current architecture is > quite complex (mainly due to the fact that the task at hand is complex) > I don't think this is feasible without risking to break anything to a > larger extent. > That's one reason why I don't want to touch terragear. The second is that I would like to make it possible to modify the ground textures without having to regenerate the scenery. > When we're discussing about runtime creation of textures we might also > get into discussing blending of ground textures. In that case, we should > keep in mind that in reality not all types of landcovers actually blend > into each other. > > When flying overhead forest areas - especially dense forest - these > typically do not blend with surrounding agricultural or greenland areas, > at least not in "civilised" areas where man tends to create sharp > corners by land usage. That's actually not related to this specific > discussion, but I wanted to note that before I forget. > Yeah, I know. But well, that's more an artistic question, not so much a technical one. And as said by you (and also by me above), it's not related to this first step of the plan. But anyway, you are surely right. I have quite a number of thoughts about how to create realistic looking "pseudo aerial photographs". If I should ever be successful with step 1, I'll come back to you with these. Cheers, Sebastian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
On 07/05/2007 04:48 PM, Andy Ross wrote: > John Denker wrote: >> Yes, I tried it. It looks terrible. >> >> It still appears to be miscalculating by a factor of 3 the required column >> width. > > A factor of 3? Dunno, it looks fine to me, and I can verify that it > fixes your problem with shrinking columns. Whether you choose to > believe me or not is, of course, up to you. > > I suspect this is a now a new bug report. Can you explain this > problem for me (maybe with a screenshot or two) so that I can help > you? Or are you happier to sneer and snipe and make me beg for > details? > > Basically: check the ego at the door, John. Most of us here would > actually like to help you (evening if helping you means encouranging > you to use the layout manager instead of 1984-era hand-drawn dialogs). > Spitting in our faces and playing ridiculous semantic games just isn't > productive. 1) Here is the requested jpg: http://www.av8n.com/fly/fgfs/weather.jpg You can see that the text in this example would have fit in one column, let alone three. 2) If you ever want such a jpg, you do not need to beg. Asking politely would have been sufficient. 3) Why the snotty remark about 1984-era layouts? This line of discussion because I tried to help out by taking the old weather.xml layout -- which I had nothing to do with writing -- and convert it to the new standards. If this conversion effort offends you, please explain why. 4) I did not snipe. I did not sneer. I reported the facts as I observed them. If observations conflict with your expectations, what should I do? I just report the facts as I see them, as you can see from the jpg. 5) People on this list have been sniping and spitting on me for months. I have tried not to reciprocate. Some people seem to be able to dish it out but not take it. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
John Denker wrote: > Yes, I tried it. It looks terrible. > > It still appears to be miscalculating by a factor of 3 the required column > width. A factor of 3? Dunno, it looks fine to me, and I can verify that it fixes your problem with shrinking columns. Whether you choose to believe me or not is, of course, up to you. I suspect this is a now a new bug report. Can you explain this problem for me (maybe with a screenshot or two) so that I can help you? Or are you happier to sneer and snipe and make me beg for details? Basically: check the ego at the door, John. Most of us here would actually like to help you (evening if helping you means encouranging you to use the layout manager instead of 1984-era hand-drawn dialogs). Spitting in our faces and playing ridiculous semantic games just isn't productive. Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
On 07/05/2007 03:40 PM, Andy Ross wrote: > Putting one word in each column only happens looks better because of > the details of your layout and the length of your strings. Not true. > Let the > layout manager pick the size, that's what it's there for. Just remove > the width and height lines and all will be well. No, not all is well. > Have you actually tried removing those two lines yet? I promise you > it works. Yes, I tried it. It looks terrible. It still appears to be miscalculating by a factor of 3 the required column width. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
John Denker wrote: > Andy Ross wrote: > > Here's the problem. You're giving your dialog a fixed size, then > > asking it to display something that doesn't quite fit. > > On my syste, with the default style, it should fit with room left > over. The working version makes this particularly clear. > > Why do you say it doesn't quite fit? Because I ran layout-test and watch it shrinking the size of the columns, then wondered why and discovered that you are giving the dialog an explicit size. That's just plain wrong in a layout dialog, unless you are attempting to do something fancy. An explicit width means "make the dialog exactly this big". If you happen to give your table more content than it can fit, it takes the difference and subtracts it equally from each column. The "working" version just happens to look better because of the details of your layout; the extra width gets sunk into columns that happen not to need it, instead of spread evenly across the colspan range. The table code doesn't understand any of that and just shrinks all columns equally. Had you picked different strings to put in those columns, it might have looked equally bad or worse. Have you actually tried removing those two lines yet? I promise you it works. Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
On 07/05/2007 03:40 PM, Andy Ross wrote: > Here's the problem. You're giving your dialog a fixed size, then > asking it to display something that doesn't quite fit. On my syste, with the default style, it should fit with room left over. The working version makes this particularly clear. Why do you say it doesn't quite fit? - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
John Denker wrote: > Compare: >http://www.av8n.com/fly/fgfs/weather.xmlworks >http://www.av8n.com/fly/fgfs/weather.xmlbroken > > The difference between them is simple, and is attached below. > The working file contains a working colspan. The broken > file contains a second colspan that significantly distorts > the table. Here's the problem. You're giving your dialog a fixed size, then asking it to display something that doesn't quite fit. So it's shrinking the columns evenly, and things look wrong: > > > weather > 840 > 570 Putting one word in each column only happens looks better because of the details of your layout and the length of your strings. Let the layout manager pick the size, that's what it's there for. Just remove the width and height lines and all will be well. Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
On Thursday 05 July 2007 15:39, Thomas Förster wrote: > Am Donnerstag 05 Juli 2007 14:21 schrieb Vivian Meazza: > You need the trafficmanager for testing the ground radar? Else turning it > off should be perfectly ok... > > > Yesterday, before Durk's latest upload, FG here was running for about 10 > > mins before it reliably crashed when running traffic- manager > > It crashed reliably? Under which circumstances, i.e. what cmdline options > etc. It would be nice to know the 'recipe for reproduction'. > Okay should be fixed now. I saw a compiler warning this morning, while preparing a new patch and asked Thomas to investige, before proceeding with that patch. As it turns out, the crash was not introduced by Thomas' new code, but merely uncovered inconsistency in the existing "getter" functions in FGAirport. FGAirport::getId() was returning a copy (whereas the nearly identical getName() is returning a reference). Thanks to Melchior's valgrind report, I also found a rather obscure (in terms of calling sequence) initialization bug in TrafficRecord. Should be fixed now as well. New stuff is committed. Cheers, Durk - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
On 07/05/2007 02:15 PM, Andy Ross wrote: > Can you provide a case where it doesn't? Compare: http://www.av8n.com/fly/fgfs/weather.xmlworks http://www.av8n.com/fly/fgfs/weather.xmlbroken The difference between them is simple, and is attached below. The working file contains a working colspan. The broken file contains a second colspan that significantly distorts the table. >> Grep tells me there are zero instances of it being used in >> CVS/gui/dialogs. > > Your grep, apparently, is lying to you. Check autopilot.xml, it uses > a rowspan Forgive me for dangling an antecedent. I find zero instances of colspan, which is the feature I needed. So the final score is: rowspan: 1 colspan: 0 === --- weather.xmlbroken 2007-07-05 14:54:27.0 -0400 +++ weather.xmlworks2007-07-05 14:29:38.0 -0400 @@ -736,9 +736,18 @@ 1 - 3 12 - Boundary transition depth + Boundary + + + 2 + 12 + transition + + + 3 + 12 + depth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh?
> Your thread title is misleading, Sorry, but I don't think so. The title describes my intentions pretty well. > what you really want to do is to add > layers, so to add some geometry drapped around the terrain. No, I don't I want to do that. I want to do what I've been talking about in my posting. Best regards, Sebastian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
John Denker wrote: > Yes, the feature is documented, and there is some code to > implement it (in GUI/layout.cxx) ... but it doesn't work > reliably. Sometimes it works, sometimes it doesn't. Can you provide a case where it doesn't? I can't promise or prove the lack of bugs, only fix the ones that are reported. > Grep tells me there are zero instances of it being used in > CVS/gui/dialogs. Your grep, apparently, is lying to you. Check autopilot.xml, it uses a rowspan for the "Speed with XXX" entries to vertically center the input field between the two lines. Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
On 07/05/2007 12:13 PM, Andy Ross wrote: > Use the "rowspan" and "colspan" properties. Check Docs/README.layout > for details. Yes, the feature is documented, and there is some code to implement it (in GUI/layout.cxx) ... but it doesn't work reliably. Sometimes it works, sometimes it doesn't. Grep tells me there are zero instances of it being used in CVS/gui/dialogs. I suspect the code has not been thoroughly tested. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Programming "Style"
Thomas Förster wrote: > which reminds me of: > The Zen of Python (by Tim Peters) > Probably a bunch of good ideas for every language. Yup, great advice. Pity python forgot about it: > There should be one-- and preferably only one --obvious way to do it. > If the implementation is hard to explain, it's a bad idea. Read and internalize those, and then teach list comprehensions to a C programmer. The more curmudgeonly I get, the more I think everyone should just be coding in Nasal... Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Programming "Style" (was: Today's CVS)
> Sane code > would just use a set_element() function and be done with it instead of > using a design element that even good, productive programmers don't > always recognize. The older I get, the more C++ looks like a > terrible, terrible mistake. which reminds me of: The Zen of Python (by Tim Peters) Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! Probably a bunch of good ideas for every language. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
Ralf Gerlich wrote: > Maybe that's a dumb question (which would be embarassing, because I > typically think of myself as a good C++ programmer), but why use a > reference in the return type anyway instead of the "real thing"? If a > copy is created anyway, the "&" doesn't have any advantage, or am I > missing something? References can be lvalues, so it's possible to write functions whose returned valued can be assigned. The examples are usually pretty academic, but consider a sparse 2D array with a method like int& element(int x, int y); You can use this thing as element(3, 4) to get the value, but you can also use: array->element(3, 4) = 12345; to *set* the value. Cute, huh? And utterly worthless. Sane code would just use a set_element() function and be done with it instead of using a design element that even good, productive programmers don't always recognize. The older I get, the more C++ looks like a terrible, terrible mistake. Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh?
Sebastian Bechtold wrote: >> >> >Hello Heiko, > >I don't want to throw away the material information which >defines things like the bumpines. As I've tried to explain, I would >like to do the whole thing as uninvasive as possible. >I'm pretty aware of the fact that as an absolute newbie here, >I'm not in a position that allows me to change or break existing >stuff. > >Thus, my plan is not to do so. > >All I want to do is implementing an alternative system for >how textures are applied to the terrain triangles. You won't >lose the ground properties (friction, bumpiness etc.) defined >by the materials with that, since they are defined independent >of the textures. Triangles with the material "road" will still >behave like roads, but my plan would, for example, make it possible >to render markings onto them, or draw softly rounded curves. >Both things are not possible with the current method (at least >not without throwing millions of additional triangles at the problem >and regenerate the terrain mesh to apply each and every change). > >My envisioned ideal solution would make it possible to toggle this >feature with a command line parameter or config file entry. If you >don't want it, just don't enable it, and you'll get exactly the same >thing as you get right now. I don't yet know enough about how >the program works to appreciate if this is possible (for me) or not, >but at the moment, I don't see a serious show stopper. I hope I made >this more clear now. > >With best regards, > >Sebastian > > Your thread title is misleading, what you really want to do is to add layers, so to add some geometry drapped around the terrain. I've started to generate geometry from airport nodes to generate taxiways some time ago but did not have time to work a lot on that recently. Once you have the geometry of whatever you want this should be renderable with an adequat polygon offset. HJ. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh?
Hi, O.k. It wasn't so clear for me what really was your idea yesterday. Better road textures, better ground textures - sounds very good! Greetings HHS If this could be possible it would be very fine --- Sebastian Bechtold <[EMAIL PROTECTED]> schrieb: > > > > Message: 2 > > Date: Wed, 4 Jul 2007 19:31:30 +0200 (CEST) > > From: Heiko Schulz <[EMAIL PROTECTED]> > > Subject: Re: [Flightgear-devel] How to apply > different texturing to > > the terrain mesh? > > To: FlightGear developers discussions > > > > Message-ID: > <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset=iso-8859-1 > > > > Hi, > > > > Hmmm sounds like the flat textures which MSFS > > has... > > I like the way it is, because with the material > you > > have some informations about bumbiness and so > on... > > > > So much as I know, someone is working on the > > possibility to change the terrain easily ( I think > > Frederic Bouvier ) > > > > So I'm not sure about if this is a good idea... > Hello Heiko, > > I don't want to throw away the material information > which > defines things like the bumpines. As I've tried to > explain, I would > like to do the whole thing as uninvasive as > possible. > I'm pretty aware of the fact that as an absolute > newbie here, > I'm not in a position that allows me to change or > break existing > stuff. > > Thus, my plan is not to do so. > > All I want to do is implementing an alternative > system for > how textures are applied to the terrain triangles. > You won't > lose the ground properties (friction, bumpiness > etc.) defined > by the materials with that, since they are defined > independent > of the textures. Triangles with the material "road" > will still > behave like roads, but my plan would, for example, > make it possible > to render markings onto them, or draw softly rounded > curves. > Both things are not possible with the current method > (at least > not without throwing millions of additional > triangles at the problem > and regenerate the terrain mesh to apply each and > every change). > > My envisioned ideal solution would make it possible > to toggle this > feature with a command line parameter or config file > entry. If you > don't want it, just don't enable it, and you'll get > exactly the same > thing as you get right now. I don't yet know enough > about how > the program works to appreciate if this is possible > (for me) or not, > but at the moment, I don't see a serious show > stopper. I hope I made > this more clear now. > > With best regards, > > Sebastian > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 > express and take > control of your XML. No limits. Just data. Click to > get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > __ Yahoo! Clever: Frage stellen und einen von 44 iPods gewinnen! www.yahoo.de/better - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian Bechtold wrote: >> Message: 2 >> Date: Wed, 4 Jul 2007 19:31:30 +0200 (CEST) >> From: Heiko Schulz <[EMAIL PROTECTED]> >> >> Hi, >> >> Hmmm sounds like the flat textures which MSFS >> has... >> I like the way it is, because with the material you >> have some informations about bumbiness and so on... > ... > Thus, my plan is not to do so. > > All I want to do is implementing an alternative system for > how textures are applied to the terrain triangles. You won't > lose the ground properties (friction, bumpiness etc.) defined > by the materials with that, since they are defined independent > of the textures. Triangles with the material "road" will still > behave like roads, but my plan would, for example, make it possible > to render markings onto them, or draw softly rounded curves. > Both things are not possible with the current method (at least > not without throwing millions of additional triangles at the problem > and regenerate the terrain mesh to apply each and every change). > I have been thinking about this approach as the way to go for all terrain texturing in the future. The 2d terrain overlay textures would be rendered at runtime at whatever resolution is necessary to look good. I wouldn't apply this scheme to airports, which would be special insets. > My envisioned ideal solution would make it possible to toggle this > feature with a command line parameter or config file entry. If you > don't want it, just don't enable it, and you'll get exactly the same > thing as you get right now. I don't yet know enough about how > the program works to appreciate if this is possible (for me) or not, > but at the moment, I don't see a serious show stopper. I hope I made > this more clear now. This is going to be messy; you're going to have to dive into the code of FlightGear, SimGear, and probably TerraGear too. The terrain mesh created by TerraGear has texture coordinates that are appropriate for the surface texture in each triangle. You're either going to have to generate alternate meshes -- with a more uniform texture coordinate scheme -- from TerraGear, or you're going to need to use OpenGL TexGen stuff to generate the appropriate texture coordinates at runtime. Remember that all the geometry is in earth-centric coordinates :) So, I don't mean to be discouraging because I think this is ultimately the right approach in terms of bumping up terrain detail and implementing terrain and texture LOD, but you have a lot of hacking ahead of you. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGjRwweDhWHdXrDRURApOFAJ9JI370wHEMEgp+qFC2Cwv4iJAqwACcD0eS 6z2IG49inoQ5jukNnk05kNw= =dIjC -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
John Denker wrote: > Here's the scenario: Suppose you have a nice table with rows and > columns. Most of the rows have many narrow columns, but one or two > rows have a lesser number of wider columns. The existing layout > manager has no idea how to handle this AFAICT. Use the "rowspan" and "colspan" properties. Check Docs/README.layout for details. Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
Ralf Gerlich wrote: > "const string&" would only make sense if a string was returned which is > typically stored in the object and should _not_ be copied, e.g. in a > getter-method. Or rather: I was wondering why a getter method would have to return a reference to a local variable, until I looked at the source code properly and found out that this thing is actually delegating the call to FGAirport, in which getId() returns a simple string. So maybe it would also be a good idea to have that return "const string&" as well. Might save a few copying operations (even though FGAirport::getId is probably inlined anyway in most cases, just not here due to the delegation). I consider this "const T&" thing good practice if all you want is read only access to a member variable via a getter method and the type of the member might otherwise require copies to be created. Cheers, Ralf - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
Am Donnerstag 05 Juli 2007 17:12 schrieb Ralf Gerlich: > "const string&" would only make sense if a string was returned which is > typically stored in the object and should _not_ be copied, e.g. in a > getter-method. And exactly thats the case here :-) Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh?
Hello Sebastian! Sebastian Bechtold wrote: > [...] but my plan would, for example, make it possible > to render markings onto them, or draw softly rounded curves. I'm specifically interested in the "markings" part (although I'm also curious at how you want to implement softly rounded curves without breaking the current concept of texture display). This might require information which is currently not in the scenery files, such as the actual position of the centerline and width of the linear features. The triangles don't represent this information anymore, however it is available from the scenery sources (e.g. the scenery database). In general, making this information available in a suitable format shouldn't be a technical problem (maybe one of available manpower for implementing the stuff required, but that only means that it may take longer). Another possibility - at least for simple roads - would be to add a centerline to the road texture and make TerraGear create an appropriate texture mapping similar to how it is done currently in genapts for the taxiways. Unfortunately, the part of TerraGear which creates the texture coordinates does not know anymore that the polygon it is currently operating on originally was a linear feature (blown up according to its width to a polygon). So this approach might require some reorganisation of the TerraGear architecture. Given that the current architecture is quite complex (mainly due to the fact that the task at hand is complex) I don't think this is feasible without risking to break anything to a larger extent. When we're discussing about runtime creation of textures we might also get into discussing blending of ground textures. In that case, we should keep in mind that in reality not all types of landcovers actually blend into each other. When flying overhead forest areas - especially dense forest - these typically do not blend with surrounding agricultural or greenland areas, at least not in "civilised" areas where man tends to create sharp corners by land usage. That's actually not related to this specific discussion, but I wanted to note that before I forget. Cheers, Ralf - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
Hi! Thomas Förster wrote: > The reason is a wrong return type on FGAirport::getId(). Should be const > string& instead of string (which does a local copy that is then referenced in > FGAirportDynamics::getId()) Maybe that's a dumb question (which would be embarassing, because I typically think of myself as a good C++ programmer), but why use a reference in the return type anyway instead of the "real thing"? If a copy is created anyway, the "&" doesn't have any advantage, or am I missing something? "const string&" would only make sense if a string was returned which is typically stored in the object and should _not_ be copied, e.g. in a getter-method. Am I missing something? Cheers, Ralf - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
Am Donnerstag 05 Juli 2007 16:49 schrieb Reagan Thomas:
> It's crashing on a memory access violation (segfault) on line 111 in
> sg_path.cxx "if ( p[0] != sgDirPathSep ) {"
>
> 'p' is an invalid pointer at that point, causing the exception. The
> following screencap shows the IDE debug info, include call stack trace:
> http://139.78.95.188/flightgear/temp/vccrashdebug.gif
Thanks for the info.
Looks to me, that the reason is exactly the FGAirportDynamics::getId()
returning an invalid string& as suspected:
void XMLLoader::load(FGAirportDynamics* d) {
FGAirportDynamicsXMLLoader visitor(d);
SGPath parkpath( globals->get_fg_root() );
parkpath.append( "/AI/Airports/" );
parkpath.append( d->getId() ); <==
parkpath.append( "parking.xml" );
...
The reason is a wrong return type on FGAirport::getId(). Should be const
string& instead of string (which does a local copy that is then referenced in
FGAirportDynamics::getId())
Thomas
--
PhD Student, Dept. Animal Physiology, HU Berlin
Tel +49 30 2093 6173, Fax +49 30 2093 6375
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
Vivian Meazza wrote:
> Hi all,
>
> I've just done a clean download of CVS-HEAD data and source. It
> compiles under MSVC8, but crashes after a few seconds of running. No
> error messages that I can see.
>
> The fix is in preferences.xml:
>
>
> false
> false
>
>
> Yesterday, before Durk's latest upload, FG here was running for about
> 10 mins before it reliably crashed when running traffic- manager -
> long enough to test the ground radar. I don't think that is the same
> bug as I had before where I could see the traffic
> manager instantiating ac just before crashing.
>
> To re-iterate - this is definitely a clean download, and the crash is
> avoidable. This appears to be a MSVC8-only bug, since I am sure that
> dozens of Linux folks out there would have reported it. Perhaps it is
> uniquely a problem here - anyone else seeing it?
>
> Vivian
>
>
>
I was able to reproduce Vivian's symptoms and narrow it down with a bit
of debug info. My tests:
1. Lastest source from CVS head
2. Compiled with optimisation for speed "/O2"
3. Ran it from fgrun 3 times with "
true" and had it crash all 3 times
within 3 to 15 seconds of the sim finishing full initialisation
4. Ran it from fgrun 3 times with "
false" letting it run from 3 minutes
to 7 minutes with no crashes before closing it.
5. Ran it with "TraffMan" enabled in debug mode from within the VC8 IDE
and found the following:
It's crashing on a memory access violation (segfault) on line 111 in
sg_path.cxx "if ( p[0] != sgDirPathSep ) {"
'p' is an invalid pointer at that point, causing the exception. The
following screencap shows the IDE debug info, include call stack trace:
http://139.78.95.188/flightgear/temp/vccrashdebug.gif
We'll keep discussing it in IRC and report any new findings here.
--
Reagan Thomas
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC "aircraft"
On Thu, 5 Jul 2007 10:15:35 +0200 Holger Wirtz <[EMAIL PROTECTED]> wrote: > Vivian, Syd, Csaba, > > On Thu, Jul 05, 2007 at 08:52:29AM +0100, Vivian Meazza wrote: > [ATC] > > Whoa there! Csaba is indeed doing some wonderful work on the "ground radar". > > Right now it's very much based around the ATC "aircraft". Perhaps it could > > go somewhere else in the data structure, but we're not at that stage yet. > > Please leave it there for now. It's not very big, and I'm sure it isn't > > doing any harm! > > Hey, that's really great!. Please don't remove this "aircraft" because > it is a really nice tool in combination with my ATC radio (coming > soon!). > > As an add-on it would be great if there would be a COM1 on the display > which uses the properties under /instrumentation/comm. > > Regards, Holger > OK I"ll leave it , I didnt think anyone else used it ... Cheers Syd&Sandy <[EMAIL PROTECTED]> - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flight Computer with HP48G
Does anybody know a good program that emulates a Flight Computer (e.g E6B) on HP48G? I know this question isn't related to FG, but with so many aviation fans, I think I can find a good answer :-) Thanks in advance. Thiago - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh?
> > Message: 2 > Date: Wed, 4 Jul 2007 19:31:30 +0200 (CEST) > From: Heiko Schulz <[EMAIL PROTECTED]> > Subject: Re: [Flightgear-devel] How to apply different texturing to > the terrain mesh? > To: FlightGear developers discussions > > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=iso-8859-1 > > Hi, > > Hmmm sounds like the flat textures which MSFS > has... > I like the way it is, because with the material you > have some informations about bumbiness and so on... > > So much as I know, someone is working on the > possibility to change the terrain easily ( I think > Frederic Bouvier ) > > So I'm not sure about if this is a good idea... Hello Heiko, I don't want to throw away the material information which defines things like the bumpines. As I've tried to explain, I would like to do the whole thing as uninvasive as possible. I'm pretty aware of the fact that as an absolute newbie here, I'm not in a position that allows me to change or break existing stuff. Thus, my plan is not to do so. All I want to do is implementing an alternative system for how textures are applied to the terrain triangles. You won't lose the ground properties (friction, bumpiness etc.) defined by the materials with that, since they are defined independent of the textures. Triangles with the material "road" will still behave like roads, but my plan would, for example, make it possible to render markings onto them, or draw softly rounded curves. Both things are not possible with the current method (at least not without throwing millions of additional triangles at the problem and regenerate the terrain mesh to apply each and every change). My envisioned ideal solution would make it possible to toggle this feature with a command line parameter or config file entry. If you don't want it, just don't enable it, and you'll get exactly the same thing as you get right now. I don't yet know enough about how the program works to appreciate if this is possible (for me) or not, but at the moment, I don't see a serious show stopper. I hope I made this more clear now. With best regards, Sebastian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
Am Donnerstag 05 Juli 2007 14:21 schrieb Vivian Meazza: > Hi all, > > I've just done a clean download of CVS-HEAD data and source. It compiles > under MSVC8, but crashes after a few seconds of running. No error messages > that I can see. > > The fix is in preferences.xml: > > > false > false > You need the trafficmanager for testing the ground radar? Else turning it off should be perfectly ok... > Yesterday, before Durk's latest upload, FG here was running for about 10 > mins before it reliably crashed when running traffic- manager It crashed reliably? Under which circumstances, i.e. what cmdline options etc. It would be nice to know the 'recipe for reproduction'. > - long enough > to test the ground radar. I don't think that is the same bug as I had > before where I could see the traffic manager instantiating ac just before > crashing. I got a compiler warning about "taking the address of a local var" (or the like) in dynamics.cxx (getId). Try if changing the return type of FGAirport::getId() to const string& (instead of string as is now) remedies the problem. If so, this is fixed with the next patch. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Today's CVS
Hi all, I've just done a clean download of CVS-HEAD data and source. It compiles under MSVC8, but crashes after a few seconds of running. No error messages that I can see. The fix is in preferences.xml: false false Yesterday, before Durk's latest upload, FG here was running for about 10 mins before it reliably crashed when running traffic- manager - long enough to test the ground radar. I don't think that is the same bug as I had before where I could see the traffic manager instantiating ac just before crashing. To re-iterate - this is definitely a clean download, and the crash is avoidable. This appears to be a MSVC8-only bug, since I am sure that dozens of Linux folks out there would have reported it. Perhaps it is uniquely a problem here - anyone else seeing it? Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 787 Seg fault
Innis Cunningham wrote: > I get a segmentation fault during aircraft loading of the 787 from > cvs is anyone else seeing this. At the cli all I get is > segmentation fault(core dump) any ideas. > Its on Ubuntu 7.04 The issue with fglrx_dri.so and _ZNSt6vectorIiSaIiEE7reserveEm manifests itself like that. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC "aircraft"
Vivian, Syd, Csaba, On Thu, Jul 05, 2007 at 08:52:29AM +0100, Vivian Meazza wrote: [ATC] > Whoa there! Csaba is indeed doing some wonderful work on the "ground radar". > Right now it's very much based around the ATC "aircraft". Perhaps it could > go somewhere else in the data structure, but we're not at that stage yet. > Please leave it there for now. It's not very big, and I'm sure it isn't > doing any harm! Hey, that's really great!. Please don't remove this "aircraft" because it is a really nice tool in combination with my ATC radio (coming soon!). As an add-on it would be great if there would be a COM1 on the display which uses the properties under /instrumentation/comm. Regards, Holger -- # ## ## Holger Wirtz Phone : (+49 30) 884299-40 ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70 ## ## ## Stresemannstr. 78E-Mail: [EMAIL PROTECTED] ## ## ## ## ### 10963 Berlin # ## ## ## GERMANY WWW : http://www.dfn.de GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC "aircraft"
Syd > Sent: 05 July 2007 01:03 > To: flightgear-devel@lists.sourceforge.net > Subject: [Flightgear-devel] ATC "aircraft" > > > Hi all , > I'd like to remove my ATC "aircraft" from CVS , thought I'd > try for some feed back first It's not an aircraft , and > was only meant to view and track the various multiplayers at > an airport. Csaba is turning it into something more advanced > , and so probably has a different folder for it I hope > :) Anyway , with another flood of new aircraft , I thought it > might be wise to remove it and make a tiny bit more room. > > And on another note , thanks , Melchior , for continuing to > keep a watchful eye on the code despite the never ending > barrage of fan mail.I know I wouldnt want the job :) Cheers > Whoa there! Csaba is indeed doing some wonderful work on the "ground radar". Right now it's very much based around the ATC "aircraft". Perhaps it could go somewhere else in the data structure, but we're not at that stage yet. Please leave it there for now. It's not very big, and I'm sure it isn't doing any harm! Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] who's committed
Hi all, a very big Thank You to all of you (and particularly to Melchior), who reviewed and commited so much contributions (including mine). Maik John Denker schrieb am 05.07.2007 02:47: > On 07/04/2007 02:57 PM, Melchior FRANZ wrote: > >> There are 20 other people with commit permissions. >> > > That may be narrowly true as written, but it is misleading. > > Here are some observations concerning the 1000 most recent > commits to the "data" tree: > ... 100.0 percentile > 503 mfranz > ... 49.7 percentile > 167 vmmeazza > ... 33.0 percentile > 131 sydadams > ... 19.9 percentile > 102 martin > ...9.7 percentile >45 curt > ...5.2 percentile >... > The corresponding observations for the "source" tree are: > ... 100.0 percentile > 545 mfranz > ... 45.5 percentile > 119 frohlich > ... 33.6 percentile >92 fredb > ... 24.4 percentile >90 curt > ... 15.4 percentile >56 ehofman > ...9.8 percentile >40 durk > ...5.8 percentile >... - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
