Re: [Flightgear-devel] Urgent Help Needed: About Multihead Display
Hi, On Wednesday 21 December 2005 08:39, Dai Qiang wrote: I have solved the problem just now :) Ok, so I will not dig deeper. Thanks Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
Hi, On Saturday 14 January 2006 19:07, Ampere K. Hardraade wrote: That was a suggestion. I current am not working on any document regarding the graphic engine, so I have nothing to share. However, I along with several others, are working on a document regarding the architecture of FG. If you have concrete plans, you need to put them in a document so those people who want to help can understand what you are trying to do, then make addition or proposal modifications to some of your ideas. Well not that concrete. :) It is just that I have already a plan in my desk if we want to do that. A plan which has prooven good in an other projekt. I have for example a list of things just required to be done before. I believe it is out of discussion that the ac reader must just work like the plib one does. The idea is to get the design and analysis done before writing a single line of code. For a project as big as FlightGear, writing design reports should not be an option; it should be a must. Well, a scenegraph is a scenegraph - more or less. At least in this direction. There is nothing I know of you can do with plib you cannot do with osg. There are aprioriate callbacks in osg so that you can implement the animation infrastructure like we have it with ssg*. So there is not much design to do in this area. Given that the precautions are are all satisfied, that is - all required loaders for osg work like expected, - we have an additional loader for the scenery files - we have a good tri/quad striper for osg geometries. - we have a short proof of concept to see how this interacts with pui and most important - *we* have *decided* to do that(!) then, I think the plan would be as follows: - build up a very thin envelope around the ssg* calls just taking scenegraph independent datastructure which could be translated to the aprioriate scenegraph. The best case is here that the datatypes are scenegraph independent but fit directly into the ssg functions directly. That is how I designed that vectors this discussion started from. Consequently no copying needs to be done. The envelope calls will be inlined and optimized away. - From that point we will not have any direct ssg call in the sources except in that envelop classes. - Now we can provide a set of envelop classes with osg as backend. - Now see how we can integrate our direct OpenGL calls into that stuff to make it work with both envelopes. - Past that we can play with that and can even easily go back if there are some unsolvable problems (I do not expect them). - If osg turns out the way to go, one can remove the ssg envelopes and may remove the indirections through the osg envelope. - Now you are really free to just use the cool features osg provides. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
Hi, On Sunday 15 January 2006 12:54, Christian Mayer wrote: (BTW: my diploma thesis [= roughly a masters thesis] was the creation of cache oblivious matrix operations in C++ using the space filling Peano curve; I could beat the Intel Math Kernel Library in optimal cache use - und even performance wise when I used only x87 instructions :) I put the code and the thesis at http://tifammy.sf.net/ Space filling curves have very interesting properties for high performance computing - not only for cache efficiency but also for partitioning of problems for parallel computers / clusters) Sounds interresting. Downloaded that matrix kernels. ... let's see what I can make use of :) What did you study? Yep, I believe that this small vector set will even provide more performance since it will just work with all ss?g* functions natively. Instead of that horrible mix of sg* and simgear point3d datatypes we have at the moment, which do not interface well and thus needs masses of hand coded copies from one datatype to the other. You can just use such a thing as a drop in replacement for any sg type. At the times I did active FGFS development I also didn't like the many different vector classes. Yep, the aim is that you have an intuitive usable thing you can use directly with the scenegraph. It might be interesting to offer the use of SSE values internally. This could give a little performance boost for modern IA-32 processors. Well, wait for gcc 4.2. There is much work going on in the direction of autovectorization. The tree optimization infrastructure has brought many improovments for optimizations. But a patch which has arrived yesterday in the svn head revision makes now definitly use of that. Richard Günther has yesterday checked in a patch which makes gcc see that array elements of the same array with different indices cannot alias. This now opens the door to do autovectorizations for small arrays. There is a tunable maximum array length of 4, but first tests with 16 for the typical transform matrices have shown that gcc now uses some addp[sd]'s instead of the unpacked versions ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
Hi, On Sunday 15 January 2006 13:18, Christian Mayer wrote: Technomathematik (= applied mathematics) Karlsruhe? Mathematician from Tübingen, did numerical analysis, mostly timestepping. Oh, I've just seen that I didn't link the thesis yet. Should be there under documentation in a few minutes Thanks! It might be interesting to offer the use of SSE values internally. This could give a little performance boost for modern IA-32 processors. Well, wait for gcc 4.2. gcc isn't the only compiler though. :) For the IA-32 are at least the MSVC++ and the Intel ICC important, too. And my expericence (with ICC) are, that the vectorisation does only work for loops. The code of my thesis uses recursions and explicitly coded operations. The ICC wansn't able to auto vectorise any of those. Ok, interresting. I heared that MSVC does vectorization for some time. But as long as I am that used to unix in contrast to windows, MSVC is not an option for me :) ICC is something I play with at some times. But I never tried how it vectorizes. Also the gcc development is much more interresting since you can watch that development including the internal comments. With closed compilers you can see marketing headlines which mostly do not have any technical relevance ... ... 'see now you have only two clicks to refactor whatever' :) Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
Hi, On Sunday 15 January 2006 13:33, Christian Mayer wrote: Numerics is also the stuff that I do most (as well as lots of fluid dynamics). Ok, so you are actually writing on your PHD? Ok, interresting. I heared that MSVC does vectorization for some time. I've only used the .NET 2003 version (i.e. 7.1 IIRC). And that couldn't do any vectorisation. It could use the scalar SSE instructions instead of the x87 though (they are faster for the Pentium 4; my Pentium M was a bit slower) Ok, just the scalar ones is not something really interresting ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
Hi Aem, sorry for that noise, As Christian started to reply in german, I thought that we have private mails Sorry! Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SEVERE bug with latest CVS changes
On Tuesday 24 January 2006 19:58, Curtis L. Olson wrote: Could we get this fixed ASAP, I'd like to be able to do VOR/ILS navigation again! Curt, my fault. Comming up with a patch in a few minutes ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SEVERE bug with latest CVS changes
Hi, On Tuesday 24 January 2006 22:50, Frederic Bouvier wrote: Curt, my fault. Comming up with a patch in a few minutes ... Curt, Mathias, I commited a fix in CVS Well that one is really nice. I prepared that patch in this minute and read that mail. Then I did a cvs up to see what you did. What I got is: RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/sound/soundmgr_openal.cxx,v retrieving revision 1.20 retrieving revision 1.21 Merging differences between 1.20 and 1.21 into soundmgr_openal.cxx simgear/sound/soundmgr_openal.cxx already contains the differences between 1.20 and 1.21 ... so you must have thought *exactly* the same :) Thanks! Greetings -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SEVERE bug with latest CVS changes
Hi, On Tuesday 24 January 2006 23:00, Frederic Bouvier wrote: and what about declaring SGReference'd class destructor as protected and SGSharedPtrT as friend ? That way, it will not be possible to call delete explicitely. Not sure, but I believe this is not sufficient since the SGReferenced d'tor will be called from the derived class d'tor. If that one is public, I believe that we can still delete the derived one. But sure, would be good to have. Still thinking about that ... greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAVAIDS ???
On Tuesday 24 January 2006 22:45, Jon Stockill wrote: Jon Stockill wrote: So with any luck I should have a full update of all the navaids in the database with correct elevations by this weekend. It seems I don't have any luck at the moment. I've just discovered that when using the null fdm I'm not getting updates to /position/ground-elev-m any more. So I can't actually retrieve the terrain elevation. Is there somewhere else in the property tree I could read this from? Jon, I have added that to the todo list. :) But not until tomorrow ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/AIModel AIBase.cxx,1.45,1.46 AIBase.hxx,1.46,1.47 AIManager.cxx,1.60,1.61 AIManager.hxx,1.31,1.32 AIMultiplayer.cxx,NONE,1.1 AIMulti
Hi, On Thursday 09 February 2006 16:01, Martin Spott wrote: Nice to see ongoing development in this area. Didn't Mathias Froehlich participate in this effort !? Well, yes and no. ... not at this patch we now have in cvs which is problematic in some sense. At least in the sense that if will again change the network packet format in an incompatible way. And in a way that will need an other such change in the next step. For that packet format change mess I asked for not applying that paticular patch we have now in cvs. At ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/multiplayer-20060124/ is an other interim patch on the way to a better multiplayer feature which now moves really steady. The network packet format there is still horrible, the implementation is not ready for production and we are still working on a network packet format which is compact and flexible. That patch is also the one which most people on the multiplayer server use - at least at the time I was there ... My aim was to avoid too much incompatible network packet format changes and I was waiting for a basic stable and sufficient packet format definition before I wanted to have a new public release in cvs. Therefore I did not want a new official cvs release yet, the current cvs code just slipped through in some way ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Help ! on a Run-Time Error !
On Sunday 12 February 2006 19:12, Melchior FRANZ wrote: Yes, and I say it the last time: your sound isn't working. Either the openal lib is too old, or the driver for your sound card, or Well, yes. But is that a reason for flightgear to quit? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Global data positional lookup
Hi, On Friday 17 February 2006 01:51, David Luff wrote: I'm considering the problem of looking up global data at the moment (eg. how many navaids are within x miles of point p). So far I've only implemented this in a very crude manner, by indexing a map of navaid pointers using FG bucket number, and then traversing all the navaids in the user's bucket and concentric rings of buckets out from the user to the required distance. This works, but is somewhat ugly, and requires more navaids / buckets to be checked than may be necessary due to the non-square bucket size and potential for non-centered position of the user within a bucket. I'm sure there must be a better way, and I'm sure Norman has posted links on this subject to the list before, but I can't find them, and can't seem to find a good method. Anyone got any ideas? Hierarchical bounding boxes or octrees or something like that. Having that would be beneficial for the groundcache too. Ok, thinking loud: May be it is possible to build a quadtree for the earths surface. No clue if you *really* gain something vs the 3d approach appart from having fun thinking about that problem :) Other question: With the available tools the bucket indexed map is a good choice for that thing. Does it really hurt to use your current approach? How often are these navid lookups required per frame and how long does this take? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Global data positional lookup
On Sunday 19 February 2006 19:44, Christian Mayer wrote: As my last post to this topic was probably a bit cryptic for some I've looked in the net a bit and have found: Hehe, not really cryptic. Rather interresting! http://taltos.pha.jhu.edu/htm/ Probably we can use their software directly - or use their algorithm to partition the earth in such a way that we can cheaply query points (like navaids, METAR stations, ...) on the earth. Ok, a 'triangular quadtree' :) Should not be too hard to implement. I have some time during the next days ... Your note was that well done that it appeared that you will come up with an apprioriate solution in a few minutes ... :) At least it made me believe that you already have something more or less ready to share ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Resigning as patch committer.
Hi Erik, On Tuesday 21 February 2006 13:20, Erik Hofman wrote: I have finally made the decision not to commit any patches from others anymore. I think I've done my time over the last few years but this accident this morning alone has cost me more than half a day. Thanks for all your work! Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Error in SGMisc class? I don't see it ...
On Monday 27 February 2006 04:44, Jon S. Berndt wrote:
Stupid me. I worded the problem incorrectly. Obviously, the
problem is with
a compile of the FlightGear test program, with the definition or use of
min.
Here's the offensive code in /usr/local/include/simgear/math/SGMisc.hxx
=== start ===
#ifndef SGMisc_H
#define SGMisc_H
#include cmath
templatetypename T
class SGMisc {
public:
static T pi() { return T(3.1415926535897932384626433832795029L); }
static T min(const T a, const T b)
=== end ===
The last line, above, is the culprit. As before, the errors are:
SGMisc.hxx:28: error: expected unqualified-id before const
SGMisc.hxx:28: error: expected `)' before const
SGMisc.hxx:28: error: expected `)' before const
The rest of the errors (lots of them), likewise involve min.
Jon
P.S. What is the test-up application, anyhow? Can we avoid compiling that?
Or, is it needed?
Yes it is needed and used.
It is a handy and typesafe way to program a min or max function.
You know exactly what type the input arguments are and which the output
arguments are.
What you can do when you want a float max is
SFMiscfloat::max(b, a)
You don't get ambiguities and you dont get whatever min/max is defined in the
global namespace you dont know about which types are used when it is really
defined.
What brakes, but that brakes anyway if you do includes in the wrong order, is
that a prevously defined min/max macro will disturb the
declaration/implementation of the SGMisc min/max as it would disturb that for
every other min/max declaration/implementation like the std::min/std::max
functions for example too.
I bet that you defined such a macro and past that include SGMath.h
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: terminate called after throwing an instance of 'std::string'
On Wednesday 01 March 2006 13:41, Chris Metzler wrote: Yes, this is definitely the way to solve this problem. After all, nobody gets truly worked up about dumbass things like vim vs. emacs or anything like that! Two ways from my point of view: Either you care for an agreement of a common editor for *all* projects *I* am working on. That includes flightgear, kde and what I do at work. Not to forget the projects I will pick up in the future ... If you are able to convince all those people to use your favorite editor of your choice with your tab size, I will switch over to that single editor for all those projects. Since I do not believe that this is a realistic approach in any sense, I will use the editor of my choice which I can use for all those projects I work on. And as long as that is the case, I think not using tabs is the way you can solve this issues in the real world. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP related segfaults
AJ, On Friday 03 March 2006 00:18, AJ MacLeod wrote: OK, we had a nice number on the MP server tonight and have a few more MP bugs... I have sent a small point fix to simgears properties to Curt. That one will fix what you reported below. But what additional bugs did you find? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP related segfaults
Please tell my if there is still something wrong. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Next FlightGear Release - upcoming.
On Thursday 09 March 2006 17:59, Curtis L. Olson wrote: 3. Any other major issues? That mouse wrapping issue reported by Jean-Yves Lefort in an other thread these hours. I noticed that too, will look into ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fix mouse view regression
On Thursday 09 March 2006 21:19, Jean-Yves Lefort wrote: This change actually breaks the view mode with PU_USE_GLUT (at least for me). It was working properly before the change; now the view jumps whenever the mouse reaches a screen edge. Checked in a fix which at least fixed that form me. Please give it a try. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI objects with hardened surface not possible? Dave Culp?
On Saturday 11 March 2006 01:44, Georg Vollnhals wrote: Of course the ship-model is hardened when put into the scenery as a static object. It also works when I make a moving ship-object with fixed direction (see listed XML-file at the bottom of this message). Also creating a flight-plan and let the ship fly at ground-level works very fine and impressive. But I cannot get a hardened and landable surface. May be anyone (Dave Culp?) can answer whether it is possible to create flightplan-models with hardened surface? I hope I am allowed to answer too :) Well flightplans are ignored by the AICarrier that is true. Also AIAircraft do not contribute to the ground computaitions. Carriers have their own 'flightplan'. Vivian has coded the typical 'stay in an operation box' 'flightplan' for the carrier. So it is not easy to make that work with flightplans. I believe that AIModels will need a SGSubsystem which could either be something interpreting usual flightplans or that carrier box thing or may be a nasal subsystem, so that every AIModel can behave like the author scripted in nasal without hardcoding that in c++. For the solidness we will need IMO a hierarchical bounding box collider which is updated instead of rebuilt at each update(). The presence of movable objects like the carrier and the need to keep aircraft on the deck even if the carrier turns, this must be done with special care for these movements. Any yes I know that this does not yet work right, but this is not due to the way the FDM 'see' the carrier surface move rather than a usual problem of viscosous friction models in all our FDM's. For this current short term problem. I believe that it would be possible to make ship's surfaces solid and make ships but not carriers follow flightplans. An other alternative would be to move that solid tag into AIBase ... Let's see ... ... but not in this current release cycle. Please remeind me past the pending release ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [BUG] (-?) buried others' multiplayer model (Sopwith Camel)
Vasili, On Friday 17 March 2006 01:38, Vassilii Khachaturov wrote: I was trying the MP feature the first time since the smoothing via the AI models had been implemented. There was another person, in the Sopwith Camel, on the CVS development server channel, at the airport. For some reason, it was rendered as half-buried, with its engine running. Screenshot at http://www.tarunz.org/~vassilii/Images/fg/sopwith-buried.jpg I don't know if it is a general altitude reporting thing, or a problem with that particular model. I am running today's CVS. I believe I know where to look for. Put on my todo list :) Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [BUG] bo105 model as an AI representing another player
On Sunday 19 March 2006 16:37, Melchior FRANZ wrote: * Vassilii Khachaturov -- Sunday 19 March 2006 16:22: Yes, you are right, no /rotors/... there. Can you (or whatever other patching powers that be that are responsible for the MultiPlayer/... stuff (Mathias?)) please add the helicopter properties I let the MP masters do that if they feel like it. I just wonder what we are going to do with n1 and n2 for 10 turbines. Will these 20 properties somehow affect MP animations? Ideally, it should be up to the aircraft to decide which properties it sends, but it looks as if this is planned. Yes, I fully agree. That n* where just there when I got the prevous attempts to transmit some properties. I did not (yet?) get to the point where this is negotiated with the aircraft configuration. There is also something missing for that. Oliver Schröder had some very nice ideas and partly code for the protocol together with his server implementation. So the protocol would negotiate property-id's with the feeder flightgear instance. That way we could even eliminate this current 'hardcoding'. I was waiting for his code to integrate this stuff then. Sadly I have not heared much from him during the past few weeks. Also we have since a few weeks again and again a 'pending release' , I wanted initially just have a more or less stable packet format established before we push out a next release. Melchior, I wonder why the bo is not able to fly without properties :). Seriously: Which ones do you need? greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] KSFO scenery to cvs data?
Hi, Shall we update the KSFO tile in cvs with the data available in the world scenery? Or which copy is the /master/ copy here? The problem I try to solve is that multiplayer clients should all use the exactly same scenery data. Otherwise multiplayer aircraft having installed different scenery than the other players will magically move above or below ground for others. greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal for 1.0
On Thursday 06 April 2006 15:07, Vivian Meazza wrote: I think that this provides a sensible migration route to OSG, if that is the way we are going, otherwise it seems a good proposal in its own right. Apart True, I have most of that parts of ssg that are required by flightgear simgear reimplemented using osg nodes below. That is not yet ready for use, but that might be a useful way to go. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: FlightGear/src/Instrumentation wxradar.cxx,1.6,1.7 wxradar.hxx,1.4,1.5
On Monday 17 April 2006 16:50, Alex Romosan wrote: the header itself might not change that often, but the time-stamp definitely changes every time you reinstall plib To avoid changing timestamps of unchanged files you can use export INSTALL='/usr/bin/install -p' ./configure --whatever at configury time. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] Very minor fix
Hi, On Sunday 23 April 2006 10:01, Pigeon wrote: In the quest of fixing the FGFS-simply-exiting-with-no-sound-device issue, i found a crash in fgExitCleanup, because the FGMultiplayMgr isn't created yet at that point. Thanks, is applied! Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [PATCH] No sound device fixes
On Sunday 23 April 2006 14:43, Melchior FRANZ wrote: * Pigeon -- Sunday 23 April 2006 14:31: It would be, IMHO, good, if we're not creating the sound manager, and the FGFX and FGVoiceMgr if either we couldn't find a sound device we could use or we want to disable sound completely. The voice manager doesn't need a device. It can send the messages over network to a computer which *has* a sound device. One could only avoid adding the subsystem if the user didn't enable the feature at all. Not that it would buy us anything: the subsystem does only burn cyclyes for an if (!foo) return; That's all, and the reason for it is that I considered to make it possible to activate the voice subsystem even after the init phase (via dialog). What again were the advantages? The advantage of his attached patch is that flightgear does not just crash if for some reason no sound device is found. Applied, Thanks! Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] sound on 737-300
On Sunday 23 April 2006 20:15, Justin Smithies wrote: just recompiled cvs version of FG and for some strange reason i have no sound on the 737-300 , the volume is up , and if i try other models like the 747 they work ok. Only thing changed is FG being updated from the cvs. Strange. Any ideas ? Ok, on part of the last patch I checked in for Pigeon to prevent flightgear just crashing if there is no sound device seemed to be responsible for that. It still does not crash even if I unload the sound module. So I expect that the still present part of his patch is sufficient ... Please try again. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] LinuxTag ...
Hi, Last week we had a booth at the LinuxTag in Wiesbaden Germany. We had installed a 3 panel view that attracted many people. We installed a second flightgear computer, the multiplayer server and the google map attached to that multiplayer server. All of them equipped with the refined custom scenery from the area of Wiesbaden and the lake of Constance. Pictures from the booth are on Ralf Gerlichs http://www.custom-scenery.org/Real_Photos.229.0.html. There were some interresting talks to many people including professional flightsimulation people as well as people from the press. One was with Kristian Kissling from the german Linux Magazin. He did now a news entry at http://www.linux-community.de/ and he asked us for support when he writes the next publication about FlightGear. I promised to help giving a more correct picture from Flightgear than the past publication gave ... It was a great place to meet people I otherwise just know from the mailing list! Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplay Jitter Problem with dual models flying in formation
On Monday 08 May 2006 21:37, Martin Spott wrote: Mathias Fröhlich wrote: If I find time, I have this on my ever growing todo list - no promise here ... We're always busy keeping Mathias' TODO-list serialized :-) :) Many interresting things to do ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] F-14 anyone?
On Tuesday 09 May 2006 07:29, flying.toaster wrote: To answer Mathias Fröhlich kind offer, I have a few docs myself (mainly Aerofax volume on the Tomcat), and I am using Airliners.net quite intensely. Photos are as important as good drawings when you want to go into detail. If I get stuck somewhere, I will surely get back to you. Was just a second hint if that first offer slipped through your hands ... Looking forward to that model. BTW: I have also some data about the F-14's longitudinal axis control systems. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPL licensing question.
On Tuesday 06 June 2006 18:52, Curtis L. Olson wrote: Here's a question for all you amateur lawyers and GPL experts out there. Let's say that someone wants to create a proprietary aircraft within the FlightGear system, and then distribute a larger system that includes FlightGear + that aircraft. In my view, the FlightGear GPL license covers our source code, but not content created with or used by that code (except for things like the base package which is explicitely licensed as GPL.) Is it possible that someone could lay claim to any newly created proprietary content (3d models, artwork, panels, etc.) by way of the GPL? Even if FlightGear is happy to allow people to create proprietary aircraft, could someone upstream in plib or zlib or openal land somehow file a complaint? To me this is analogous to Microsoft demanding all documents created and owned by a company just because they created and edited them with Microsoft Word. I just don't see that ever happening. But I wonder what others think about this issue from a legal point of view. From my point of view that is the same with gcc. The compiler is GPL, but the programs compiled with gcc do not need to be gpl. The runtime libraries used by gcc compiled codes is a little less than LGPL. I think that you can do properitary aircraft with flightgear. The only restriction could be that no GPL configuration files are referenced. I think of standard electrical systems for example. If the 'larger system' provider does modifications to flightgears sources he must publish the sources with his modifications. We are then free to incorporate them into our tree. I am not aware of any possible claims from third party libs like zlib ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] collision avoidance
Hi, On Sunday 11 June 2006 06:53, Mick - wrote: I've managed to get Mathias' suggestion of using get_elevation_m but with strange AGL values. I used calc_gc_lon_lat from simgear/math/polar3d.hxx for getting the latitude/longitude from x-meters away, then feeding the resulting lat/lon values into get_elevation_m, but it seems this might not be correct (result is not wgs84?). When flying over the ocean, I get an varying AGL value of 10-20ft. With this said, could you suggest an alternative? I have tried that out. That what you describe works here. The ocean surface is not exactly at 0m elevation. It varies between 0m elevation and about -1m. That is normal since the vertices are at exactly 0m, the triangle surfaces must be beond that somewhere in the middle. May be our maximum altitude value bites you. You may need to set that to something similar than the aircrafts altitude. The problem is that the down direction for the lookup is not perpandicular to the geodetic earths surface but directed towards the earths center ... Additionally, could you please suggest how I could use the bounding box method? Well, that depends on what you need. Hierarchical bounding boxes is something different than I suggest. It helps for a different problem. If you need that, I have not understood what you need. Collision avoidance can be meant with not hitting the ground. I expect that you need that. Collisions can also happen with other aircraft/whatever in 3D. If this is what you need than, the elevation value is not aprioriate for you. For that problem it is best to use hierarchical bounding boxes. The scenegraph already has some (poor) hierarchical bounding box structure in it. If you need that it might be a good starting point to reuse that. If you have further problems, feel free to ask. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tower patch
On Sunday 11 June 2006 21:09, Melchior FRANZ wrote: Yes. And there was no commit since this crash happened, so the line can't have moved. Sorry, I didn't investigate, because I have ATC always turned off because of the flakiness, and I just returned to that mode. I thought Dave would soon come up with a fixed/rewritten version, anyway. :-) True? Is he working on that? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tower patch
On Sunday 11 June 2006 21:36, Melchior FRANZ wrote: He said so. We just need to release 1.0 next week, and ... :-) * David Luff -- Thursday 20 April 2006 00:04: | But tower.cxx is the only thing I'm working on at the moment - I want | it fixed and stable before 1.0 as much as you guys, because otherwise in | retropect there wouldn't have been much point in writing it to start | with. Ah, ok. Thanks ... Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] collision avoidance
On Monday 12 June 2006 07:15, Mick - wrote: Through observation, I found that my calculated agl value (as discussed in my previous post) was close to that of /position/ground-elev-ft when using the current lat/lon values instead of those from Point3D calc_gc_lon_lat( const Point3D orig, double course, double dist ). I did this in an attempt to compare against the /position/ground-elev-ft value. The resulting value was close but not the same. Having converted between feet and meters, and degrees and radians for the purpose of the calculations, would this have resulted in the slight difference in value? Ok, what is 'slight' in that case? With my limited avionics knowledge, I assumed that: (altitude-ft - ground-elev-ft) = altitude-agl-ft. Again, this is something I want to verify instead of assuming. So is it (somewhat) correct to assume that subtracting the current altitude from my calculated agl would give me the the altitude-agl-ft? That should be ok. Anyway, I have attached the quick hack that I used to test that and the past material changes. That might serve as a starting point for you. It takes the aircraft's position (not the view position!) does an additional ground query at that location and computes an additional location 10 meters away in the direction of your view. There is also an additional ground query. Both are printed to stdout ... Hope that helps Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ? src/FDM/OpenFDM Index: configure.ac === RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v retrieving revision 1.116 diff -u -r1.116 configure.ac --- configure.ac 5 Apr 2006 19:52:52 - 1.116 +++ configure.ac 12 Jun 2006 06:13:18 - @@ -439,6 +439,14 @@ fi AM_CONDITIONAL(ENABLE_JPEG_SERVER, test x$ac_cv_header_simgear_screen_jpgfactory_hxx = xyes) +dnl Check for installed OpenFDM +AC_CHECK_HEADER(OpenFDM/OpenFDMConfig.h) +AM_CONDITIONAL(ENABLE_OpenFDM_FDM, \ + [ test x$ac_cv_header_OpenFDM_OpenFDMConfig_h = xyes ] ) +if test x$ac_cv_header_OpenFDM_OpenFDMConfig_h = xyes ; then +AC_DEFINE([FG_ENABLE_OPENFDM_FDM], 1, [Define for no logging output]) +fi + AC_LANG_POP dnl Check for system installed zlib @@ -519,6 +527,7 @@ src/FDM/JSBSim/models/atmosphere/Makefile \ src/FDM/JSBSim/models/propulsion/Makefile \ src/FDM/LaRCsim/Makefile \ + src/FDM/OpenFDM/Makefile \ src/FDM/SP/Makefile \ src/FDM/UIUCModel/Makefile \ src/FDM/YASim/Makefile \ Index: src/FDM/Makefile.am === RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/Makefile.am,v retrieving revision 1.7 diff -u -r1.7 Makefile.am --- src/FDM/Makefile.am 22 Nov 2004 10:10:33 - 1.7 +++ src/FDM/Makefile.am 12 Jun 2006 06:13:18 - @@ -4,8 +4,14 @@ SP_DIR = endif +if ENABLE_OpenFDM_FDM +OpenFDM_DIR = OpenFDM +else +OpenFDM_DIR = +endif + SUBDIRS = Balloon JSBSim LaRCsim UIUCModel YASim \ - $(SP_DIR) ExternalNet ExternalPipe + $(SP_DIR) $(OpenFDM_DIR) ExternalNet ExternalPipe noinst_LIBRARIES = libFlight.a Index: src/FDM/flight.hxx === RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/flight.hxx,v retrieving revision 1.13 diff -u -r1.13 flight.hxx --- src/FDM/flight.hxx 11 Jun 2006 13:34:19 - 1.13 +++ src/FDM/flight.hxx 12 Jun 2006 06:13:20 - @@ -433,7 +433,10 @@ FG_PARACHUTE = 9, // Driven externally via a serial port, net, file, etc. - FG_EXTERNAL = 10 + FG_EXTERNAL = 10, + + // OpenFDM. Reads JSBSim legacy and new files. + FG_OPENFDM = 11 }; // initialization Index: src/Main/Makefile.am === RCS file: /var/cvs/FlightGear-0.9/source/src/Main/Makefile.am,v retrieving revision 1.68 diff -u -r1.68 Makefile.am --- src/Main/Makefile.am 14 May 2006 12:22:53 - 1.68 +++ src/Main/Makefile.am 12 Jun 2006 06:13:20 - @@ -9,6 +9,13 @@ SP_FDM_LIBS = endif +if ENABLE_OpenFDM_FDM +OpenFDM_LIBS = $(top_builddir)/src/FDM/OpenFDM/libFGOpenFDM.a \ + -lOpenFDMJSBReader -lOpenFDMeasyxmlXML -lOpenFDMXML -lOpenFDM +else +OpenFDM_LIBS = +endif + if WITH_THREADS THREAD_LIBS = -lsgthreads $(thread_LIBS) else @@ -74,6 +81,7 @@ $(top_builddir)/src/FDM/LaRCsim/libLaRCsim.a \ $(top_builddir)/src/FDM/UIUCModel/libUIUCModel.a \ $(SP_FDM_LIBS) \ + $(OpenFDM_LIBS) \ $(top_builddir)/src/GUI/libGUI.a \ $(top_builddir)/src/Autopilot/libAutopilot.a \ $(top_builddir)/src/Input/libInput.a \ Index: src/Main/fg_init.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v retrieving revision 1.165 diff -u -r1.165 fg_init.cxx --- src/Main/fg_init.cxx 10 Jun 2006 22:24:05 - 1.165 +++ src/Main/fg_init.cxx 12 Jun 2006 06:13:20 - @@ -88,6 +88,9
Re: [Flightgear-devel] [RFC] HUD
On Friday 16 June 2006 10:18, Erik Hofman wrote: Melchior FRANZ wrote: * Erik Hofman -- Friday 16 June 2006 09:51: I think it's best to use the default functions supplied by the system libraries (in this case lrintf() ? ) lrintf is c99 according to the man page, and so it roundf(). (int)rintf() then? Hmm, I doubt this will be faster than the ASM code. You know, just put the code in fastmath.[ch]xx and deal with it later. Well, I doubt that fastmath is useful these days anyway. I would never use these functions for serious computations, since I doubt that they will pass any IEEE test. Compilers do a pretty good job, selecting the right asm code for that stuff. Also I would trust libm and compilers much more in terms of accuracy, behavour in corner situations and even speed. For those few computations the fastmath functions are used now, I believe that you will not even notice a change in framerates if you compute the required results twice with the most expensive function you can find compared to the fastmath stuff. Also these fastmath implementations are not aliasing safe in any way. You can expect an optimizing compiler to completely missoptimize most of the fastmath functions. I would vote for removing that fastmath stuff completely and using standard ones. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear cvs compile errors with gcc 3.3.6
Hi,
On Friday 16 June 2006 14:30, Joacim Persson wrote:
From talking to others on IRC I understand the cvs version of simgear
builds
fine with gcc 4, but with gcc 3.3.6 I get these compile errors added below.
Is there a simple workaround for this?
Given the error message, I could imagine a that the attached patch helps.
Can you please tell me if that patch helps?
... I tested with gcc-4.1.1 and gcc-3.2.3 which are both happy with the actual
code. Can you help me testing with gcc-3.3.6?
:-/
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
Index: simgear/scene/material/mat.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/material/mat.cxx,v
retrieving revision 1.29
diff -u -r1.29 mat.cxx
--- simgear/scene/material/mat.cxx 11 Jun 2006 13:30:59 - 1.29
+++ simgear/scene/material/mat.cxx 16 Jun 2006 22:38:18 -
@@ -317,6 +317,15 @@
}
}
+SGMaterialGlyph* SGMaterial::get_glyph (const string name) const
+{
+ mapstring, SGSharedPtrSGMaterialGlyph ::const_iterator it;
+ it = glyphs.find(name);
+ if (it == glyphs.end())
+return 0;
+
+ return it-second;
+}
Index: simgear/scene/material/mat.hxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/material/mat.hxx,v
retrieving revision 1.23
diff -u -r1.23 mat.hxx
--- simgear/scene/material/mat.hxx 11 Jun 2006 13:30:59 - 1.23
+++ simgear/scene/material/mat.hxx 16 Jun 2006 22:38:18 -
@@ -207,10 +207,7 @@
/**
* Return pointer to glyph class, or 0 if it doesn't exist.
*/
- SGMaterialGlyph * get_glyph (const string name) const {
-mapstring, SGSharedPtrSGMaterialGlyph ::const_iterator it = glyphs.find(name);
-return it != glyphs.end() ? it-second : 0;
- }
+ SGMaterialGlyph * get_glyph (const string name) const;
protected:
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
On Saturday 17 June 2006 10:05, Erik Hofman wrote: Mathias Fröhlich wrote: I would never use these functions for serious computations, since I doubt that they will pass any IEEE test. They are not designed for that either. It can be useful for sound processing and color adjustments where very high precision isn't necessary. I use it for instance for gamma correction on my O2. It does give me a framerate improvement. Well, but gamma correction happens often. At ervery frame width times height pixels times number of colors. That are easily more than 1e6 operations a second. I can hard imagine an operation in flightgear that happens that often, dominates the computation time *and* that does not require some minimum accuracy. I for myself would not use them for the HUD. Too few invocations (that is: potential speedup) compared to the subtle problems that can arise. For the sound stuff, I do not even see, if sound is disabled or enabled, so I can hard imagine to see the improovement of the fastmath functions from the sound subsystem. Performance is a critical subject to me. But IMO the possible advantages of the fastmath functions are too few compared to the possible problems. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear cvs compile errors with gcc 3.3.6
On Saturday 17 June 2006 01:11, Joacim Persson wrote: On Sat, 17 Jun 2006, Mathias Fröhlich wrote: Given the error message, I could imagine a that the attached patch helps. Can you please tell me if that patch helps? Compiled without a warning on mat.cxx now. (Was that all? Couldn't handle that method as inline?) I believe I know what the problem is: At the time of implementation there must be more available then just the forward decl of that SGGlyphMaterial. Sad that the others tolerate that code ... I will check that in now, thanks for the feedback ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Hi Erik, On Saturday 17 June 2006 10:54, Erik Hofman wrote: Mathias Fröhlich wrote: Performance is a critical subject to me. But IMO the possible advantages of the fastmath functions are too few compared to the possible problems. I've never advocated using these routines for FMD's or anything like that since it could get messy really quick. But tests using the fastmath routines have revealed a considerable speed increase when compared with the C library functions solely because they are lossy and imperfect. If you feel that they should be used, can you care for them and make them alias safe? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
On Saturday 17 June 2006 14:54, Erik Hofman wrote: Mathias Fröhlich wrote: If you feel that they should be used, can you care for them and make them alias safe? Not at this time, I've got other things on my prioritylist. Ok, the ones in fastmath.hxx are easy to fix, I have already prepared a checkin for that. The ones in the fastmath.cxx look really ugly to fix. If we would have no different compiler than gcc I would have suggested to add a special compile flag to fastmath.cxx to avoid gcc optimizing too much away. But we also have to support other compilers ... So I have to note that many of these functions are expected to be misscompiled by modern compilers that care for alias sets like current gcc's do. Anyway, you still try to sell to me that (in case of fast_fabs for example) it is faster to take a floating point value probably already being loaded in the fpu push it into memory reload it into the integer unit do some bit fiddling push it back into memory and reload it into the floating point unit to do further computations with that is faster than just take the fpu register and execute a fabs operation on that? Seriously, I *can* think of fast_atan's polynomials being faster than a full blown correct functioin. But those simple fabs, sign or neg function implemented in the header cannot even be faster than the cpu builtin assembler instructions usually available on current cpu's. Also, in presence of sse instructions forcing that fist legacy i386 fpu instruction in that assembler snipet will not make it faster (unloading from sse unit, loading to legacy fpu, in contrast to do the same directly in the sse unit ...). Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
On Saturday 17 June 2006 22:06, Jon S. Berndt wrote:
In file included from ../../simgear/math/SGMath.hxx:32,
from ../../simgear/math/point3d.hxx:54,
from ../../simgear/math/sg_types.hxx:41,
from sg_socket.hxx:39,
from socktest.cxx:6:
../../simgear/math/SGQuat.hxx:134:35: macro min requires 2
arguments, but only 1 given
Here is the offending code for the first error:
/// Create a quaternion from the angle axis representation where the
angle /// is stored in the axis' length
static Squat fromAngleAxis(const SGVec3T axis)
{
T nAxis = norm(axis);
if (nAxis = SGLimitsT::min())
return SGQuat(1, 0, 0, 0);
T angle2 = 0.5*nAxis;
return fromRealImag(cos(angle2), T(sin(angle2)/nAxis)*axis);
}
Is it legal to call a min function with no arguments? The compiler
doesn't seem to think so, at least.
Perfectly legal.
That is a static member of SGLimitsT that is basically the same than
std::numeric_limits. That in turn has a min static member.
On windows, you have that nasty windows.h header defining a min and max macro
that will interfere with the ISO C++ standard.
Dig into the windows headers, there is a way to avoid windows.h defining that
macro.
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
On Saturday 17 June 2006 22:15, Jon S. Berndt wrote: This is under Cygwin, so it's a little surprising. I've been compiling this way for years and this is the first I've seen of it. Is this a relatively new change in the code? About a year or so ... It is not the first time I hit this nasty defines. But I can never remember what needs to be done to get rid of them. With the lack of a win system here, you have to dig yourself ... greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
On Saturday 17 June 2006 22:24, Georg Vollnhals wrote: I could not compile SimGear CVS under CYGWIN for a short time due to this error. Will now try to make the changes recommended. Thank you Jon for making it public. There is a #define that saves windows.h from defining the min and max macro. Either grep for them in cgwin's includes or use google ... May be we can include that in a generic simgear header? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear compile error: min function
On Saturday 17 June 2006 22:44, Georg Vollnhals wrote: I am just trying to find that needle but I am blind! But not giving up for the next hour. Ok, google tells me that #define NOMINMAX or equivalently CPPFLAGS=-DNOMINMAX ./configure --whatever-you-like does the trick. Tell me if this is ok ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Hi,
... was offline, sorry.
On Saturday 17 June 2006 23:28, Erik Hofman wrote:
You know, I did a quick grep in the source code for fast_ and only found
it to be used in simgear/sound/xmlsound.cxx (namely fast_log10 and
fast_log). Maybe we can get rid of them after all.
In that time, I have tried to fix fastmath.cpp to compile correctly.
My suggestion would be to keep the transcendent functions and correct them to
make them compile correct.
I have also removed the functions that are very most likely slower than the
libm implementations from the header.
Can you/somebody help me please and double check the attached patch if I have
converted them correctly before I check that in?
I have *not* done any tests with this functions against the libm ones. In fact
I do not know what error is acceptable for the fast implementation.
What do you think?
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
Index: simgear/math/fastmath.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/math/fastmath.cxx,v
retrieving revision 1.8
diff -u -r1.8 fastmath.cxx
--- simgear/math/fastmath.cxx 16 Jun 2006 09:29:54 - 1.8
+++ simgear/math/fastmath.cxx 19 Jun 2006 17:03:05 -
@@ -35,20 +35,20 @@
* This function is on avarage 9 times faster than the system exp() function
* and has an error of about 1.5%
*/
-static union {
-double d;
-struct {
+double fast_exp(double val) {
+const double a = 1048576/M_LN2;
+const double b_c = 1072632447; /* 1072693248 - 60801 */
+
+union {
+ double d;
+ struct {
#if BYTE_ORDER == BIG_ENDIAN
int i, j;
#else
int j, i;
#endif
-} n;
-} _eco;
-
-double fast_exp(double val) {
-const double a = 1048576/M_LN2;
-const double b_c = 1072632447; /* 1072693248 - 60801 */
+ } n;
+} _eco;
_eco.n.i = (int)(a*val + b_c);
@@ -61,30 +61,30 @@
*/
double fast_exp2( const double val )
{
-int e;
-double ret;
-
-if (val = 0) {
-e = int (val);
-ret = val - (e - 1);
-
+union {
+ double d;
+ struct {
#if BYTE_ORDER == BIG_ENDIAN
-((*((int *) ret)) = ~(2047 20)) += (e + 1023) 20;
+int i, j;
#else
-((*(1 + (int *) ret)) = ~(2047 20)) += (e + 1023) 20;
+int j, i;
#endif
+ } n;
+} ret;
+
+if (val = 0) {
+int e = int (val);
+ret.d = val - (e - 1);
+ret.n.i = ~(2047 20);
+ret.n.i += (e + 1023) 20;
} else {
-e = int (val + 1023);
-ret = val - (e - 1024);
-
-#if BYTE_ORDER == BIG_ENDIAN
-((*((int *) ret)) = ~(2047 20)) += e 20;
-#else
-((*(1 + (int *) ret)) = ~(2047 20)) += e 20;
-#endif
+int e = int (val + 1023);
+ret.d = val - (e - 1024);
+ret.n.i = ~(2047 20);
+ret.n.i += e 20;
}
-return ret;
+return ret.d;
}
@@ -96,7 +96,12 @@
float result, tmp;
float mp = 0.346607f;
-result = *(int*)val;
+union {
+float f;
+int i;
+} v;
+v.f = val;
+result = v.i;
result *= 1.0/(123);
result = result - 127;
@@ -115,27 +120,14 @@
result = val + 127 - tmp;
result *= (123);
-*(int*)result = (int)result;
-return result;
-}
-
-
-
-/**
- * While we're on the subject, someone might have use for these as well?
- * Float Shift Left and Float Shift Right. Do what you want with this.
- */
-void fast_BSL(float x, register unsigned long shiftAmount) {
-
- *(unsigned long*)x+=shiftAmount23;
-
+union {
+float f;
+int i;
+} v;
+v.i = (int)result;
+return v.f;
}
-void fast_BSR(float x, register unsigned long shiftAmount) {
-
- *(unsigned long*)x-=shiftAmount23;
-
-}
/*
@@ -148,20 +140,28 @@
*/
float fast_pow(const float f, const int n)
{
-long *lp,l;
-lp=(long*)(f);
-l=*lp;l-=0x3F80l;l=(n-1);l+=0x3F80l;
-*lp=l;
-return f;
+union {
+float f;
+int i;
+} v;
+v.f = f;
+v.i -= 0x3F80l;
+v.i = (n-1);
+v.i += 0x3F80l;
+return v.f;
}
float fast_root(const float f, const int n)
{
-long *lp,l;
-lp=(long*)(f);
-l=*lp;l-=0x3F80l;l=(n-1);l+=0x3F80l;
-*lp=l;
-return f;
+union {
+float f;
+int i;
+} v;
+v.f = f;
+v.i -= 0x3F80l;
+v.i = (n-1);
+v.i += 0x3F80l;
+return v.f;
}
Index: simgear/math/fastmath.hxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/math/fastmath.hxx,v
retrieving revision 1.9
diff -u -r1.9 fastmath.hxx
--- simgear/math/fastmath.hxx 17 Jun 2006 16:04:28 - 1.9
+++ simgear/math/fastmath.hxx 19 Jun 2006 17:03:05 -
@@ -45,10 +45,6 @@
float fast_acos(const float val);
float fast_atan(const float val);
-void fast_BSL(float x, register unsigned long
Re: [Flightgear-devel] altitude agl
On Monday 19 June 2006 22:45, Curtis L. Olson wrote: Melchior FRANZ wrote: We have /position/altitude-agl-ft in the property tree (-0.1946648994 ft). But what the (old) HUD code uses for RadioAltimeter is /position/altitude-ft - /position/ground-elev-ft = 6.202537 Clearly, the 6 ft make more sense than any negative number. What why is altitude-agl-ft wrong? I'd need the 6.202537 in the property tree. How would I call it? /position/correct-altitude-agl-ft, or what? :-} m. /position/altitude-agl-ft = -0.1946648994 /position/altitude-ft = 4527.586407 /position/ground-elev-ft = 4521.38387 Could this have been introduced early on as a hack to compensate for a difference between the wheel contact point and some aircraft reference point higher up on the aircraft structure? It looks pretty suspect to me. Which FDM did you try? I know there is a subtle difference between JSBSim and YASim. I agree that these three properties should fit together. I will look into that. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altitude agl
On Monday 19 June 2006 23:23, Melchior FRANZ wrote: YASim (j3cub in KUFO). The one I expected :) Try that attached patch. Andy safes an on ground trim routine by just starting an aircraft with zero agl in the sense of 'all gear contact points are exactly zero meters above ground'. Starting from this situation the aircraft just drops into its springs. This kind of agl is also set into the FGInterface agl routine from YASim. If you would ask me, I would like to have it in a consistent way, but may be we should ask Andy about such a change? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Index: src/FDM/YASim/YASim.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/YASim.cxx,v retrieving revision 1.34 diff -u -r1.34 YASim.cxx --- src/FDM/YASim/YASim.cxx 1 Mar 2006 22:59:58 - 1.34 +++ src/FDM/YASim/YASim.cxx 19 Jun 2006 21:39:13 - @@ -371,13 +371,13 @@ double lat, lon, alt; sgCartToGeod(s-pos, lat, lon, alt); _set_Geodetic_Position(lat, lon, alt*M2FT); -_update_ground_elev_at_pos(); +double groundlevel_m = get_groundlevel_m(lat, lon, alt); +_set_Runway_altitude(groundlevel_m*SG_METER_TO_FEET); +_set_Altitude_AGL((alt-groundlevel_m)*SG_METER_TO_FEET); // UNUSED //_set_Geocentric_Position(Glue::geod2geocLat(lat), lon, alt*M2FT); -_set_Altitude_AGL(model-getAGL() * M2FT); - // useful conversion matrix float xyz2ned[9]; Glue::xyz2nedMat(lat, lon, xyz2ned); ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Fwd: general FSweekend info Nov 2006]
On Friday 23 June 2006 17:08, Curtis L. Olson wrote: This looks like it could be an interesting event if anyone is in the neighborhood. Does anyone want to look into organizing a FlightGear presence there? No really a presence, but I will be there together with Martin. So, looking forward to meet some of you! Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Helicopter: First Impressions
On Saturday 24 June 2006 00:29, Maik Justus wrote: - ground effect Look into Mathias' ground cache. This should make it quite easy to get the necessary altitudes quickly. I will have a look on this. Is this used in yasim? Yes it is. There is an api in FGInterface which can be used to get agl values in a small environment from the aircraft. There is just a small cache containing the scenery triangles a few meters around the aircraft. Feel free to ask if there are some problems. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
On Wednesday 21 June 2006 13:03, Christian Mayer wrote: These functions can be great - when you know in advance (1) the number range, (2) the required error range and that you are (3) in a very tight loop that is (4) performance critical. So I'd leave them in. Yes, but I doubt that I will identify an *inner* *loop* making use of transcendental functions that are that unimportant for the physics that I would consider using these functions. If you want to keep them, please help me and review that patch I have posted a few days ago. Please *verify* that the remaining functions do about the right thing past converting them to something that is not even misscompiled. If nobody helps here, I will finally remove them in a few days. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MIL-STD-1878B -- Aircraft Display Symbology
On Saturday 01 July 2006 09:38, Melchior FRANZ wrote: * Mathias Fröhlich -- Saturday 01 July 2006 09:28: So you are currently redoing the hud geometries? Possiblty some of it. But first I wanted to have the source that the original author reportedly used, because I hoped that this would make the messy code easier to understand. Not sure yet if this will be the case. I have already looked into that some time ago. I believe I understand more or less what is done there. I just did not want to open that task with one person. :) What do you think about putting that stuff into the scenegraph instead of doing OpenGL calls directly? I don't care much, but I welcome every improvement that someone else does. More work for me isn't an option, especially since the scenegraph isn't one of my domains. Ok, lets coordinate our work :) Well, the reason I ask is that I would like to improove flightgears internal structures and interfaces so that we have less things to reimplement when we add support for an other scenegraph api. OpenSceneGraph is a good candidate. But a well separated api will help integration of DirectX as an alternative on windows for the case redmond will stop support for OpenGL like they tried several times in the past years ... I have on my local disk already code that makes use of osg with the exception of the hud, the panel the clouds and the shadows. It is faster than ssg in most cases and I believe we can make look flightgear better with a better and maintained scenegraph. If we can base the hud on a restricted scenegraph api (well ssg is sufficient - ssg is restricted in itself :) and if we could reuse some SGAnimations that already can read properties will help definitely much. I don't know if we can get that far, but may be we can use external models that are used for the hud symbology and plug them together with animations? But at least getting rid of the direct opengl calls is something useful. An other option for the hud would be to merge the hud with the render_area_2d implementation. It is definitely some kind of that. Also the symbology described in the pdf you mention is not limited to the hud. It appears to be used for such mfd's too ... Well, I have to leave now and will be away until probably sunday evening. Next week is also a bit tight for me, so I cannot help much until in two weeks, I believe. But I would like to contribute to that project ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MIL-STD-1878B -- Aircraft Display Symbology
On Saturday 01 July 2006 10:20, Melchior FRANZ wrote: * Mathias Fröhlich -- Saturday 01 July 2006 09:28: What do you think about putting that stuff into the scenegraph [...] BTW: this is already doable via render-to-texture. Unfortunately, I can't find the reason why the contents appear quite dark and the settings that work well on the 2D/3D HUD don't work there. I would like to get rid of the direct opengl calls in the hud. Drawing the hud with some kind of multi stage rendering is an other different thing we can think about. See the remark in the other mail. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MIL-STD-1878B -- Aircraft Display Symbology
On Saturday 01 July 2006 10:20, Melchior FRANZ wrote: BTW: this is already doable via render-to-texture. Unfortunately, I can't find the reason why the contents appear quite dark and the settings that work well on the 2D/3D HUD don't work there. And keep in mind, that our rendertexture implementation just does *not* work on any dri driver and on any ati driver. Only nvidia cards support what rendertexture's current implementation needs. So relying on nvidia for such a central thing like the hud is not a good idea IMO. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MIL-STD-1878B -- Aircraft Display Symbology
On Saturday 01 July 2006 10:36, Melchior FRANZ wrote: * Mathias Fröhlich -- Saturday 01 July 2006 10:30: I would like to get rid of the direct opengl calls in the hud. Drawing the hud with some kind of multi stage rendering is an other different thing we can think about. See the remark in the other mail. OK, so I shall stop any further work on the HUD? No problem. Done. Would have been nice if you had spoken up a little sooner. We are discussing the HUD now since a long time. Sorry, I do not want that you stop working on that. What do you already have that is not checked in? What has happened up to now was not critical to that point. And even then, almost everything can propably be reused, even if there are direct opengl calls. I hooked in at the time it appeared to me that you started changing the geometry, that is the point that is important ... I think it is an improovement what you do. So no need to stop ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MIL-STD-1878B -- Aircraft Display Symbology
On Saturday 01 July 2006 10:44, Melchior FRANZ wrote: But it's not finished, and I'm not sure if I want to waste more time. Why 'waste time'? What do you have and what do you still need to do in your opinion? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MIL-STD-1878B -- Aircraft Display Symbology
On Monday 03 July 2006 08:23, Melchior FRANZ wrote: You apparently missed that I had started to work on a new HUD implementation in src/Instrumentation/HUD/. It is based on the old HUD, but heavily changed, cleaned up, extended. I spent at least 20 hours work on that, and you didn't bother to tell me sooner what your plans were, although I talked about this effort in several emails during the last weeks. This was the poorest timing that one could have thought of. This new code still requires several more hours of work. Tapes don't currently work for the F16, everything needs more cleanup etc. A few FIXMEs to fix, some TODOs to do. But now that I know that you are working on yet another implementation, I consider every minute spent on mine a waste of time. I don't like to work for the waste bin. No, I am not working on an other implementation. I have expressed that it would be very nice if the direct OpenGL calls could be put into the scenegraph. There is not wasted work here. The old code needs to be cleaned up anyway. I doubt that this should be implemented from scratch in one pass. I would more favour an incremental change, may be on top of what you have now. I have also told you that relying *entirely* on RenderTexture is not a good idea. Just because it does not work on *many* OpenGL cards. If you have either some code that prerenders the hud there is no big conceptiual difference if you either render that to a texture and pin that texture onto a surface. Or if you set up some clipping planes and an aprioriate transformation matrix and render the lines directly into the framebuffer. Melchior, calm down a bit ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MIL-STD-1878B -- Aircraft Display Symbology
On Monday 03 July 2006 09:08, Melchior FRANZ wrote: OK, but how should I go on with the broken F16 tape?! Mathias will probably change that anyway, so is it worth spending time to fix it now? To make that clear: I very much agree with Mathias plans, at least so far as I know them. Putting the HUD elements into the scenegraph is certainly a good thing. But I don't know how HUD items shall be drawn after that. Not directly with gl* drawing commands, but how else? By moving textures around? This will never allow the flexibility that we currently have. Or by just using line drawing wrappers that can easily be switched from plib to osg or anything else, but basically do the same that they did before? In the latter case fixing the tape would be worthwhile, in the former not. I am not sure about that. That depends on what they really do. And I doubt that I will be really sure about that without a cleaned up codebase. The velocity vector for example is something that can easily go directly into a leaf node that is just transformed by some properties that may not yet exist. Some text elements that can be reused for several things can be implemented with some leaf nodes. Some ladders can be implemented with a fixed part and a movable arrow part. A scenegraph can be looked at in an other way to factor out some commonly used elements. As a first step to factor out something I tend to clean up things. That is at least my way of doing this. Anyway, the more parts we can sensilbly factor out into small modular chunks, the fewer parts must be reimplemented when we put an other scenegraph below that code. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MIL-STD-1878B -- Aircraft Display Symbology
On Monday 03 July 2006 14:09, Erik Hofman wrote: Melchior FRANZ wrote: * Erik Hofman -- Monday 03 July 2006 13:45: What you could do right now is committing the new HUD code [...] ... but I should probably do that anyway, just so we have concrete code to discuss, and maye even to work on. It should just be noted Agreed. that this is still unfinished, and should be treated with caution. There are many things that I had considered too ugly to commit, and there are a number of modifications to be expected. That's fine, you've already made sure none of the existing models will be affected. That's how I thought about it. Either by submitting patches between us or by using cvs for that task. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mp and animations
On Saturday 01 July 2006 18:05, Josh Babcock wrote: Is there some property that plane modelers can use to do LOD and turn off certain animations on aircraft that are being flown remotely? Planes like the bo105 with complex animations look pretty funny when they are not being flown locally, with doors missing, rotor blades all in one spot etc. It would be nice to have some property to key on and just present a low-LOD version of a plane when it is being viewed as a remote mp aircraft. I hoped that the bo105 will look correct with the current release? The network packets include as much additional properties as fit into the one udp packet. They just need to have a unique number assigned in FGMultiplayMgr::sIdPropertyList. For the LOD as such, that is a problem where we can stand help from the scenegraph. Did I already note that osg has built in support for Imposters? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MIL-STD-1878B -- Aircraft Display Symbology
On Monday 03 July 2006 21:37, Melchior FRANZ wrote: But before that we should really have a plan. I for one am against using animations and textures for HUD symbols, and also against a mixture of two techniques. An inhomogenous solution will cause nothing but problems, starting with different color/brightness. And textures are IMHO unsuitable for drawing tapes. The question would then only be, how to draw lines if not with gl* commands, and how to transfer that into the scenegraph?! Fred already told you how you can put that into the scenegraph. But one thing to think about is what I already noted in a prevous mail: May be we can implement a special leaf node that provides some vector drawing primitives like lines or something like that. Something similar is already in render_area_2d.cpp. On top of that base implementation, a library of hud primitives can be provided. I believe that many parts that are useful for a hud can be reused for mfd's. The key is that the base implementation might move into a scenegraph dependent simgear directory. The hud parts just use them. I can think of a thin layer around the opengl calls to paint lines, line strips, triangles, quads and such. That wrapper should also manage how state changes need to be done so that there is a minimal set of state changes and that the scenegraph is aware of them. Does anybody have directx experience how such simple primitives are rendered in immidiate mode? To see if this path is worthwhile, it would be good to see the cleaned up code ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MIL-STD-1878B -- Aircraft Display Symbology
On Monday 03 July 2006 22:18, Melchior FRANZ wrote: To see if this path is worthwhile, it would be good to see the cleaned up code ... I hope I can commit tomorrow. But the drawing code didn't change much at all. My changes are mostly about cleaning up the classes, removing redundant code, replacing the hard-coded getters with input channels from the property system, new XML file layout and file loading, and such things. I only started to think about rewriting the tape code. That's when I searched for the mil-std. But changing the line drawing parts with ssgVtxTable and mounting all together to a branch of the scenegraph shouldn't be that hard. True ... Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in mp-visibility of planes?
Hi, On Wednesday 05 July 2006 19:14, Maik Justus wrote: I think there is a bug in fg. I sometimes can not see the other planes (with fg0.9.10, not tested on cvs version) when using the multiplayer mode. It seems, that if there is one other player using a 3D model which can not be found on my computer, my computer do not display the planes of any player joining the game later, either if they using a 3D model installed on my pc. That should not happen. And there is another bug. If someone left the game, the plane is displayed on my computer for ever. Maybe it's possible to use a time flag, when the last position update for a plane was received. If this flag is older than a threshold, the plane could be deleted? Also that should not stay that long. There is a timeout of 10 seconds that an aircraft is kept in the scene even if the network packets do no longer arrive. Can you verify if this is still the case with the cvs version? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MIL-STD-1878B -- Aircraft Display Symbology
On Tuesday 04 July 2006 18:14, Melchior FRANZ wrote: * Erik Hofman -- Monday 03 July 2006 13:45: What you could do right now is committing the new HUD code [...] Done. It can be activated via /sim/hud/visibility[1] and can be used at the same time as the old HUD (/sim/hud/visibility[0]). It's not identical, but in the end it should (almost) be. There's not much to see, though. The only somewhat nice feature is the blinking g-load label (-1G 2G). TODO: - make tape work - fix the alternative turn-bank-indicator (it's also broken in the old HUD, but is nowhere used :-) - fix ladder properties - implement the other general and aircraft specific HUD configs - more cleanup - ... Thanks Melchior, I did not yet find time to look into that. And I doubt that I will find this weekend. I will be, together with Martin Spott, in Vichy for this weekend... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD updates
On Friday 07 July 2006 06:06, Melchior FRANZ wrote: * Lee Elliott -- Friday 07 July 2006 00:48: I see you have done away with the test on ilcanclaw for the energy worm in hud_ladr.cxx [...] I have only commented it out for now, because it belongs to the special FDMs (SP_FDM) and has low priority. It was only used by the ADA FDM, whatever that is. If possible then I'll re-activate it and fix it if it breaks the worm. Well, if we have a hud system that can be fed with arbitrary properties, providing that acceleration marker should be ok IMO. In that case the SP_FDM stuff can go entirly away: If an FDM set's some additional properties, these properties are available for the intruments. BTW: is sombody out there maintaining the SP_FDM? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD updates
On Friday 07 July 2006 12:36, Erik Hofman wrote: Mathias Fröhlich wrote: BTW: is sombody out there maintaining the SP_FDM? I'm not sure about the ADA FDM but I would not want to see the ACMS FDM yanked since it has been (and can be) used to playback the information stored on the Flight Data Recorder (black box). Not completely yanked, just get rid of those various ifdefs that enable special features in the HUD or instrumentation only for SP_FDM. I think those features n the HUD shoulod be available for every FDM. The input values sould have an arbitrary property as input. The question for a maintainer is because of some coorination that might be required if that is changed. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD updates
Erik, On Friday 07 July 2006 23:13, Erik Hofman wrote: So, basically, no I won't maintain the ACMS FDM but lets keep it available anyhow. Ack. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers
Hi, On Wednesday 26 July 2006 19:20, Melchior FRANZ wrote: We had talked about abstracting out the raw gl-commands into just one file, and then to use plib wrappers to plug the HUD into the scene graph. The plib wrappers could eventually get replaced by osg wrappers. The abstraction is still a goal, and so is plugging the HUD into the scene graph. But I think now that using plib/osg wrappers is a bad idea. This would prevent us from using some gl features for absolutely no good reason (e.g. line width, clipping, ...). And finally, ogl *is* a standard, while neither plib nor osg are. So why leaving the standard? Raw gl-code can still be plugged into the scene graph via callbacks, and the only thing that the wrappers would buy us is management of state changes for performance reasons. But the HUD code doesn't change that much, and this can be done manually, too. Why exactly would we want to limit ourselves? :-} Because it is not a limitation but rather a gain. A *well* *done* and *well* *supported* scenegraph will help you some much more than you probably can imagine now. In fact, a proper design - like a well done scenegraph provides - will enable such features in a much less error prone and more efficient way. Also a *supported* scenegraph that is developed further will make use of improovements in OpenGL that an unsupported one like plib's ssg will never see. ssg forces you to do many things yourselves in a probably less efficient way with direct OpenGL calls, that can be done with a smarter implementation without such direct OpenGL commands. There is nothing in OpenGL you cannot do with osg. But there is nowerdays nearly everything from current OpenGL features - even some basic ones like clip planes - that is missing in ssg, so that you need to implement that yourselves ... Having that will be much more of a gain that a limitation ... So why should we limit ourselves in the long term with ssg? Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers
Melchior, On Thursday 27 July 2006 09:58, Melchior FRANZ wrote: * Mathias Fröhlich -- Wednesday 26 July 2006 22:49: Because it is not a limitation but rather a gain. A *well* *done* and *well* *supported* scenegraph will help you some much more than you probably can imagine now. You completely miss the point: we are using ssg! There was no decision made to switch to osg. So, if we switch to ssg wrappers first, we lose capabilities, that we may or may not get back later. I don't accept that and object. In fact, a proper design - like a well done scenegraph provides You miss the point. We are using ssg! So why should we limit ourselves in the long term with ssg? Fact is: we are using ssg. We may or may not switch to osg later. There has *no* decision been made, so we can't rip out stuff now that osg may provide later. The way to go is: - formal decision to switch to osg (or at least to start working on it) - generate osg branch in cvs - parallel development In the osg branch you can do with the HUD what you like. But not in the current, *SSG* branch. I believe that you miss the point. The point is that we can, without loosing features, with a sensible design, prepare getting rid of ssg. As allmost allways, building sensible structures is a win even if no switch will happen. Just blocking that is not a good idea. ... did you ever look at the sceens of csp.sf.net? Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers
On Saturday 29 July 2006 14:28, Frederic Bouvier wrote: Vassilii Khachaturov wrote : I once proposed a compatible ssg extension : http://frbouvi.free.fr/plib/nsssg.html I was able to use it with flightgear without code change except to support the new features ( like multi texturing and environment mapping ). The code still exist but stalled after it was ignored by the plib team and further developments ( like shaders ) were lost in a disk crash. Fred, is the code you refer to newer than the state-of-the art plib, or does it require an excessive merge? maybe you could fork plib into a simgear subdir and have a configure option to pick it up, if chosen? This code was written in summer 2004 and left untouched since then. But I am afraid plib didn't changed that much too. Code is here : http://frbouvi.free.fr/plib/ Hmm, I don't know if it is better to improove ssg and take it into our tree or if we should leave that work to somebody specialized to scenegraphs. Given the good work of Robert Osfield, Don Burns et. al. for osg. I tend to spend our work switching over to osg instead of redoing that ourself ... I have thought often about a thin scenegraph abstraction layer for some structural nodes. That could help us much when we need/want to switch to an other scenegraph. At least for a transition time we could have a ssg and an osg version in parallel without disturbing people willing to have the settled down and feature complete ssg build. Later such a layering could be beneficial if Redmond decides to cut OpenGL support completely like they tried several times in the past. ... I am curious what this years siggraph brings. I think of abstractions for Group/Transform nodes. Just to be able to plug together the scenegraph from flightgear's sources. Animations are scenegraph specific and shoudl be scenegraph specific. Animations will just need a pointer to a property. The aprioriate scenegraph callback objects/code can be entirely scenegraph specific and does not need to be abstracted. That code is only installed in the model scenegraph as a postprocessing step to model loading. What we will need is some cairo/glitz like 2d api to draw the HUD and do some MFD's. I believe that this is even more apprioriate for such rendering areas like issuing raw OpenGL commands. With such an abstraction we are open to map that to an immediate more rendering pass to a texture or if this is used to build up a part of the scenegraph in case we do not have RenderTexture available. ... btw: I fear that osg already has way better render to texture code that will find a kind of off screen buffer on almost every graphics card ... Also Camera nodes must be accessible from within flightgear. Whenever we need an other direct access to the scenegraph we can extend the abstraction layer. For those struggling with performance issues with abstraction layers, I can only tell that almost everything is done directly on the scenegraph. For example the performance critical cull and draw operations will not even know that there is an abstraction layer. Animations will be scenegraph specific and therefore not critical. Plugging together the scenegraph at load time will have some theoretical penalty that I doubt that it is measurable. Implementing that will be possible without branching and without the burden to do regular merges. It is designed from ground up to be able to do that. We can incrementally refactor what we have with ssg and provide the aprioriate abstractions that can definitely be used with osg and most probably be used with DirectX (Fred, you you have experience with DirectX?). As a first step I would like to refactor some code heading to that goal. You can alternatively call that cleanup, cleanup that is most likely sensible anyway. And such cleanup is the origin of that thread. Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] moving hotspots?
On Tuesday 01 August 2006 15:44, Sexauer, Steve wrote: Is it possible to have hotspots on moving objects like the stick throttle? Picking on 3d objects in not yet implemented, but could be done in principle. It is something on my todo list that is not yet done ... Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in mp-visibility of planes?
Hi Maik, On Monday 31 July 2006 23:49, Maik Justus wrote: Also that should not stay that long. There is a timeout of 10 seconds that an aircraft is kept in the scene even if the network packets do no longer arrive. Can you verify if this is still the case with the cvs version? yes, I have the same problem with the cvs version. For cvs I am using msvc express while 9.10 I used the compiled windows file. I have tried to reproduce that with my local linux boxes on mpserver02.flightgear.org. But I can not reproduce any of that problems. If a MP client leaves the server it stays online for 10 seconds and then disappears. If an unknown model enters the scene it does not appear in the scene. But the next known model shows up. In this case I need some help on windows. I have somebody on my short range radar :) Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fatal error when switching views
On Friday 11 August 2006 19:07, Dave Culp wrote: Just some info here on how to reproduce the fatal error when switching views. 1) Take off from some place where you don't have the terrain. 2) switch to next view by hitting the V key I get this: Attempting to schedule tiles for bogus lon and lat = (-1000,0) This is a FATAL error. Exiting! As long as I stay in cockpit view I'm fine, and can look around and see water, as I expect. Ok, thanks! I have got that reported now at least 3 times but without something I can reproduce reliably. I will try to reproduce that one this weekend. Thanks! Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] crash in groundnetwork
Hi, while debugging Maik's multiplayer problems, Olaf and I experienced some problems in groudnetwork.cxx. At the end of the FGGroundNetwork::trance() there are two pop_back's where the second one poped an non existent last entry from the routesStack vector. We tried to avoid poping in that case by an if (!routesStack.empty()) guard in from of that pop_back. But with that we got some other problems in FGTaxiRoute::next() ... If we revert groundnetwork.cxx to the previous revision, those problems were gone. Any ideas? Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in mp-visibility of planes?
Hi Maik, On Sunday 13 August 2006 21:15, Maik Justus wrote: I still have this problem. Can you tell me, where in the source the 10 seconds timeout are tested? Then I can try, to find more detailed information. That would be great! That happens around line 420 in src/MultiPlayer/multiplaymgr.cxx. Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in groundnetwork
Hi Durk, On Saturday 12 August 2006 00:32, Durk Talsma wrote: Btw, where did you experience these problems (which airport), and how did they manifest themselves? Program crashes? I've been running recent versions of FlightGear using the EHAM groundnetwork, and hadn't seen any problem yet. It's possible that it's something that only shows up at KSFO (which I haven't tested so much yet). Yes that was at KSFO. Flightgear died just at startup in that code. We had active multiplayers enabled. BTW, I predict that if you used the routesStack.emty() guard, the progam was crashing in TaxiRoute.next(), because the (nodes.size() == (routes.size()) +1 condition was not met anymore. I did include a test for this condition, but since it was always true on my system, I commented it out. My estimate is that the solution is fairly easy, and I'll probably have something by Tuesday (I'll be out of town on the weekend). Thanks! Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to turn off managed-view?
On Wednesday 16 August 2006 22:30, Melchior FRANZ wrote: Shouldn't the old style of view the default property and the new managed-view the one which is selectable? No. I would vote for the old stuff too! Also a generic, aircraft independent, disable switch for that unusual view would be great. What I have in mind here is what we had at the LinuxTag booth in Wiesbaden. We had multiple views where you don't want to have any automatic view management. I that case you want to manage the views just by moving your real head. For such a thing it would be really great to disable that without stepping through many aircraft and disable them one by one. Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to turn off managed-view?
On Thursday 17 August 2006 00:51, Melchior FRANZ wrote: Ok, why? Because I like it and think it should be active by default. FlightGear aircraft are property of their creators -- they decide (as long as no sacred rules are violated). Everyone is free to modify his/her copy, to fork it, or even to create their own, better aircraft. From my point of view this is a total misfeature. We could use some more helicopters. What about you?! Any contribution around the corner? Don't mix up independent things Mechior ... If there was a poll (which is not the case), then I would have to say: 5 people welcomed it. *Nobody* has complained about it so far. You didn't argue at all, just imply a sacred rule that doesn't exist. Mathias had the most ridiculous argument: the 100 rich guys with panorama or multi-screen setup, or head-trackers shouldn't have to turn it off. I'm very depressed and sad to cause this pain to that 0.0001% minority, and you can call me old-fashioned, but somehow I think that doing what I consider desirable for 99.% of users is right. No, if you want to present flightgear in an environment where this stuff does not make sense at all and where people expect a somehow well done and working presentation, you don't want to additionally fiddle with that stuff. But anyway can we have a maser switch to get rid of that once for ever in every aircraft? Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RTT issue with ATI cards (3d clouds)
On Saturday 19 August 2006 16:27, Christopher HORLER wrote: On Saturday 19 August 2006 00:19, Jocelyn Couetdic wrote: I did some quick and dirty debugging in the RenderTexture class (using the TestRenderTexture program), and find out, that the reason it doesn't work, is that neither GLX_SGIX_fbconfig, or GLX_SGIX_pbuffer extensions are supported by the ATI GLX implementation : You're wrong (last entry below) fglrxinfo -x cut for clarity glx server extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig No, he is not wrong. You should not look into the server extensions nor into the client extensions. The only valid thing is (well, I had to learn that the hard way :) GLX extensions that is in effect what the client *and* the server understands. Here you don't have what you need for rendertexture. I suffer from the same problem. And I can see two ways to go: Either - implement FBO's in rendertexture, or - support me with switching to osg, they already have that including much more ... Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RTT issue with ATI cards (3d clouds)
On Saturday 19 August 2006 20:28, Frederic Bouvier wrote: Mathias Fröhlich a écrit : - support me with switching to osg, they already have that including much more ... How could we do that ? Can you share what you already done ? I am out until at least next sunday evening. Past that more about that. Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RTT issue with ATI cards (3d clouds)
On Saturday 19 August 2006 17:02, Christopher HORLER wrote: No, he is not wrong. You should not look into the server extensions nor into the client extensions. The only valid thing is (well, I had to learn that the hard way :) GLX extensions that is in effect what the client *and* the server understands. Here you don't have what you need for rendertexture. I suffer from the same problem. Apologies Not a problem! Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fatal error when switching views
David, On Friday 11 August 2006 19:07, Dave Culp wrote: Just some info here on how to reproduce the fatal error when switching views. 1) Take off from some place where you don't have the terrain. 2) switch to next view by hitting the V key I get this: Attempting to schedule tiles for bogus lon and lat = (-1000,0) This is a FATAL error. Exiting! As long as I stay in cockpit view I'm fine, and can look around and see water, as I expect. I tried hard to reproduce that with flightgear compiled with glut and sdl. I cannot yet reproduce that. I know that there are several reports about that, but I do not yet have an idea why this happens. I am still thinking about that ... Anyway, I am out until next sunday, before that I will not have any access to a computer. Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS:
On Monday 28 August 2006 16:20, Martin Spott wrote: Frederic Bouvier wrote: Selon Martin Spott : cc-3234 CC: ERROR File = ../../../simgear/scene/model/persparam.cxx, Line = 9 Explicit specialization of function SGPersonalityParameterdouble::getNodeValue must precede its first use. SGPersonalityParameterdouble::getNodeValue( SGPropertyNode *props, Any suggestion ? What your documentation is saying about this error ? If I were able to tell you what's going on here, then I would have posted a patch and not this ERROR message ;-) Martin, is this fixed with the now inserted forward decl? If not I might have an idea. Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in mp-visibility of planes?
Maik, On Thursday 24 August 2006 19:23, Maik Justus wrote: Hi, to whom I have to address this patch to get it into simgear-cvs? To me is perfectly ok. I was offline for some days. Riding mountainbike in the alps ... Now catching up my mail backlog ... Will show up soon. I believe that the other problem you reported is independent of that timestamping problem. greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Scheduling tile at bogous lon and lat = (-1000, 0)
Hi, I have checked in something that I expect fixes that problem with Scheduling tile at bogous lon and lat = (-1000,0) Since I still cannot reproduce that. Can you help me and report if that message is gone with your favourite reproducable testcase. Thanks! Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in mp-visibility of planes?
Hi Fred,
Before I check in that.
I know Olaf has an improoved timestamping implementation for win32.
Did he already send that to you?
Greetings
Mathias
On Sunday 20 August 2006 16:44, Maik Justus wrote:
Hi Matthias,
Mathias Fröhlich wrote:
Hi Maik,
On Sunday 13 August 2006 21:15, Maik Justus wrote:
I still have this problem. Can you tell me, where in the source the 10
seconds timeout are tested? Then I can try, to find more detailed
information.
That would be great!
That happens around line 420 in src/MultiPlayer/multiplaymgr.cxx.
Greetings
Mathias
The problem is, that the elapsed time is queried in this way
long stamp = timestamper.get_seconds();
but the timestamper update is calculated this way (file timestamp.cxx
(simgear)):
void SGTimeStamp::stamp() {
#if defined( WIN32 ) !defined(__CYGWIN__)
unsigned int t;
t = timeGetTime();
seconds = 0;//-- comment by Maik: this is the
problem
usec = t * 1000;
#elif defined( HAVE_GETTIMEOFDAY )
struct timeval current;
struct timezone tz;
// sg_timestamp currtime;
gettimeofday(current, tz);
seconds = current.tv_sec;
usec = current.tv_usec;
#elif defined( HAVE_GETLOCALTIME )
SYSTEMTIME current;
GetLocalTime(current);
seconds = current.wSecond;
usec = current.wMilliseconds * 1000;
#elif defined( HAVE_FTIME )
struct timeb current;
ftime(current);
seconds = current.time;
usec = current.millitm * 1000;
// -dw- uses time manager
#elif defined( macintosh )
UnsignedWide ms;
Microseconds(ms);
seconds = ms.lo / 100;
usec = ms.lo - ( seconds * 100 );
#else
# error Port me
#endif
}
For MSVC the seconds are allways zero, all the elapsed time is stored in
usec. After splitting the elapsed time into usec and seconds and
removing the #if defined( WIN32 ) !defined(__CYGWIN__) sections
alls seems
to work well (see enclosed diff for simgear). Please add it to CVS.
Maik
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer chat patch
On Saturday 23 September 2006 18:47, Buchanan, Stuart wrote: Hi All, I've written a patch to the MP code that allows text-based chat within the simulator. It provides the following: 1) Improved MP property handling. The MP code no-longer assumes all properties are floats. Props now turn at the correct RPM, and the MP message format now supports strings and integers. 2) MP chat. Users can type messages that are displayed to all users within MP range. The messages are displayed within a dialog box, and optionally to the screen using the current Nasal message system. This allows the messages to be TTS'd by festival. Currently the patch is intentionally simple. There are a couple of obvious enhancements that could be made once this is committed: A) Frequency specific transmissions. Currently everyone in the MP range hears all transmissions. It would be better to restrict users to transmitting/receiving on their current COM1 frequency. The source code requirements for this are already present in this patch (the /sim/multiplay/transmission-freq-hz property is exported), but the Nasal code is not. B) Quick-phrases. Typing while flying is not particularly efficient. A tree of phrases with click-to-say navigation would be easier to use. The patch is available from http://www.nanjika.co.uk/flightgear/chat.tar.gz We may want to increment the MP protocol version for this, but I'll leave that to other's discretion. As always, comments are welcome. Nice patch! But anyway: You will actually double the amount of memory that is transmitted for one property. While it is good to be able to send different typed properties, I think we can, with the current scheme, store the properties type in the static property configuration where we also store the id to property path mapping. This way we can avoid sending additional data on each property which must be known on both sides anyway. In the longer term, I would like to have a dynamic property path/property type negotiation that is done at the start of a connection. That way we will build up that currently static 'id to path' map at connection start and send only the property values in the fast path. Can you update your patch to avoid transmitting the type? Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer: feature request
On Friday 08 September 2006 19:45, Buchanan, Stuart wrote: Two suggestions off the top of my head. 1) Write a MP proxy to run on an additional machine which broadcasts the position data to the slaves and passes through the master's position data to the MP server. Doesn't sound too unreasonable though I'm not going to volunteer! Architecturally this is nice, as from the MP server's perspective there is a single aircraft. 2) Write/enhance an I/O protocol to pass the /ai/models/multiplayer[] tree to the slaves. You'll need to decide how many MP a/c to display at once. Please don't just send the whole tree. We need to distinguish between properties that are required to display a model correct and between properties that are only there for whatever reason. It would be good if we could just use the same mechanisms to push the local main aircraft over the line and for that thing you don't want to push the whole property tree below / over the line ... Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer chat patch
Hi, On Sunday 24 September 2006 18:19, Buchanan, Stuart wrote: You will actually double the amount of memory that is transmitted for one property. That is true. However, transmitting the chat strings is going to represent a much bigger increase in message size, though I've restricted the chat size to 128 characters per message. I should have highlighted this in my original patch just in case we're worried about bandwidth. Yep, but the chat messages will happen every now and than. The properties will be sent at each step. So this will hurt much more than the chat messages. In the longer term, I would like to have a dynamic property path/property type negotiation that is done at the start of a connection. Me too, but re-writing the message format seemed quite sufficient for the moment :) So, if we just store the type with that map, we do not even need to change the message format. - All old properties are floats. - The old code ignores id's that it does not know about. - The updated code will interpret old style floats correctly. So, in this case there is no need to increase the protocol version. Did I miss something? Can you update your patch to avoid transmitting the type? Yes, but I can't provide any guarantee as to when I'll get it done. Not a problem. Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer chat patch
On Saturday 30 September 2006 16:57, Buchanan, Stuart wrote: Any chance this could be committed sometime, or objections raised? Yes, I will do so this weekend. I would like to double check that it does not break the current protocol ... Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer chat patch
Stuart, I have problems applying that patches. I am not sure why but patch claims: patch: Only garbage was found in the patch input. Could you rediff that only with cvs diff -u instead of cvs diff -u -p -8 -w I would expect that this helps Thanks! On Sunday 01 October 2006 11:26, Buchanan, Stuart wrote: Thanks. I've only been able to test the recent minor changes on a single computer, so a bit or paranoia would be good. If you need another person to help, let me know. I'll be on IRC. Thanks! Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C182 patch
Hi Stuart, On Monday 02 October 2006 21:24, Buchanan, Stuart wrote: I've been working on an update to the c182. Improvements over previous version: - Increase in texture resolution and improved textures. Now has a nice blue pin-stripe down the side. - Minor model improvements - pitot tube, wing struts, exhausts, cowl-flaps, re-size of controls. Available from http://www.nanjika.co.uk/flightgear/c182.tar.gz Those with long memories may recognize this as pretty much the same patch I submitted months ago, but without a pilot model. I think the current CVS c182 has Dos line-endings, which I believe have caused people problems in the past. Can whoever commits this run a quick dos2unix on the .xml and .ac files please. Done, Thanks. I have done that with two steps, first check in the new changes and then change the line endings in a second separate commit. You may copy away your current model in your cvs checkout to avoid many useless conflicts on the next update. Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C182 patch
On Sunday 08 October 2006 12:52, Stuart Buchanan wrote: I think you may have missed some of the changes. From a quick flight and diff, I think the changes from c182.diff have still to be merged in. They change the following files c182-set.xml Models/c182-dpm.xml Panels/c182s-3d-panel.xml I think so too. Sorry. Is now applied. Thanks again Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in mp-visibility of planes?
Maik,
sorry for the long delay. The weather these days was too good to stay
inside :)
On Friday 06 October 2006 21:31, Maik Justus wrote:
@Mathias Fröhlich
Did you looked on this?
Yes, but I expect that the problem is something different.
We have at the moment a more or less crappy port/host handling for multiplayer
packets.
I think that must be cleaned up anyway.
At best I think that the multiplayermanager recieve code should move into
Network/multiplayer.cxx. Also the configuration of the appropriate sockets
can then happen in the same file.
I would expect that this would help much.
My guess is that your own computer will broadcast your own position packets to
a network where your own computer is already attached to. So you will see the
same plane twice.
May be the broadcast setting is implemented somehow different in plib's win32
code.
Can you tell me if removing the broadcast flag from the plib socket will help
(attached patch)?
Greetings
Mathias
Index: src/MultiPlayer/multiplaymgr.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/MultiPlayer/multiplaymgr.cxx,v
retrieving revision 1.10
diff -u -r1.10 multiplaymgr.cxx
--- src/MultiPlayer/multiplaymgr.cxx 10 Oct 2006 05:17:07 - 1.10
+++ src/MultiPlayer/multiplaymgr.cxx 10 Oct 2006 05:34:10 -
@@ -201,7 +201,6 @@
return false;
}
mSocket-setBlocking(false);
- mSocket-setBroadcast(true);
if (mSocket-bind(rxAddress.c_str(), rxPort) != 0) {
perror(bind);
SG_LOG( SG_NETWORK, SG_ALERT,
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Scenery/Objects/w130n30/w123n37
On Saturday 14 October 2006 12:08, Martin Spott wrote: Mathias Froehlich wrote: Update of /var/cvs/FlightGear-0.9/data/Scenery/Objects/w130n30/w123n37 In directory baron:/tmp/cvs-serv537/Scenery/Objects/w130n30/w123n37 Modified Files: sutro-fb.ac The maintainers of the FlightGear Scenery Objects Database are usually very happy to recieve a copy of such changed files, as this DB in fact is the primary source for Scenery objects in FG. Just a reminder, I'll pick it from CVS now. Cheers, Thanks, I did not realize that the /master/ source is outside that cvs. Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OpenSceneGraph
Hi, I had worked now for some time on an OSG port of flightgear. At the moment many things are already working. - Scenery and 3d models are there. - Animations work mostly as expected. - The usual lights including the vasi are there. - The 3d panel is displayed and interactive. - The sky looks as usual - including stars and the 2d clouds. - The HUD's. - The usual menus. What is missing so far are - The shadows - The 3d clouds - The lightning and rain code - The render surface instruments On my notebook, where I do much of the development, I get improved frame rates up to a factor of two. Depending on the model and daytime. The rain stuff as well as the render surface stuff is nothing too complicated and already available in osg, but that needs to be done and tested. There is a replacement for our shadows in osg available. Also an improved shadow toolkit is in the works by the osg guys - I believe we should make use of that in the longer term. The 3d clouds are something to think about. osg can assist here but I need to think about that. We will need some small updates to the current OSG version. That is: An updated rgb loader that does not crash on some of our rgb files. An updated ac3d loader - we will need that to get our models right. Ok, long talk - what to do? I would like to check that into our cvs. The usual way would be to create a cvs branch and do that work on that branch. In this case it would be good if we could avoid changes in the HEAD branch that touches anything visible. In some private mails with Curt he directed me to an other scheme: Create a branch for the old plib/ssg code and do the osg stuff on HEAD. In this case we would have the plib/ssg stuff still available in that branch for those of us who need the well tested old stuff. We could safe some final merging if we do it in this way. Thougths/Comments - where should I check in? Well, two screenshots of that are at ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/OpenSceneGraph-20061024 Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenSceneGraph
Hi, On Wednesday 25 October 2006 16:48, Frederic Bouvier wrote: I am eager to see it in CVS. It seems natural that the flow of innovation goes to HEAD and branches are used for freezing functionalities and doing maintenance release. Many big projects are doing like that, gcc for instance. It should be easier to do that because doing branch merging can be risky at a large scale. It is better not to rely on it and accept the idea of doing things twice if a bug appears in a branch and the trunk. So, IMO, we should create a pre-1.0 branch now, fix the more embarrassing bugs ( and missing features ) in that branch and let the innovation go in HEAD. Ok. I hope Curt is not thinking about duplicating the repository like it was done for version 0.8.0 :-) BTW: I presume only SSG has been replaced and PUI/PUAUX/JS are still needed. right ? Yep. I believe that we should import them into SimGear... Greetings Mathias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
