Re: [Flightgear-devel] Open Scene Graph
Arnt Karlsen wrote: On Fri, 15 Oct 2004 09:07:26 -0500, Curtis wrote in message [EMAIL PROTECTED]: For what it's worth I am very interested in OSG. One of the lead OSG developers and I have some interesting connections. He is a strong interest in flight simulation, and I think we could get help when we needed it and possibly assistance with new feature development in OSG if we needed. It would be no small task to switch over from plib to OSG, but I think if we can figure out a way to do it, we will be better off in the long run. There are strong indications that plib will eventually catch up with the current state of computer graphics, but it may not be for months or years ... ..I read all this as _if_ their license ever threatens to bite us, we can easily drag them over into using the GPL. ;-) Less difficult would be they switch to the actual LGPL. Then you'd be free to link directly and release under GPL if you like. BTW, I'm new here. Need to update to 0.9.6 before I say anything about the actual software - it may fix some things I saw in 0.9.5. BTW2, you guys might consider using bittorrent to help bandwidth :-) Thanks, Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Ray Tracing (was: OpenRT)
And I thought joining this mailing list would get me into something different. ;-) Ray tracing is not ready for real-time flight simulation. I'm speaking from experience here. I used to be on the same mailing list as those OpenRT guys. I also wrote the renderer behind rtChess: http://www.newimage.com/~rhk/rtchess/ Which BTW, is available for download (the game) and comes with docs. Be sure you right-click to drag the board around. Use the Space-bar for options menu. Unlike most chess games, you can probably beat this one. I've been working the realtime ray tracing (RTRT) stuff for years, and it's always been real soon now for gaming performance. My library can easily render as many polygons as you can fit in RAM at a couple FPS (requires undersampling) on my 700MHz AMD. It's about 40% faster now than when we wrote rtChess. As with many things, there is one tiny piece of code that consumes 90% of the time and I've worked really hard on that. When I get around to releasing it (probably GPL) some assembly guru *might* get a bit more performance out of it. Because RT is point sampled, the render time is mostly a function of the number of pixels rather than the number of polygons. The time complexity is very good WRT scene size (think log n). A few objects can be handled really really fast on a modern processor. Unfortunately, using 1000s of objects brings log(n) up to where things are rather slow. Going to millions of objects just cuts it in half again. GPUs are not currently able to handle the data structures and recursive algorithms required to get scene scalability, nor do they use double precision. Eric Haines once asked me to estimate when RTRT will be really feasible - I estimated 2012 and so did he. That doesn't take into account the brick wall we see now with power density and no 4GHz pentiums and all that... Multi-core is great for RT. Multi-threading is one of the features I need to add (done before but removed) because it scales nearly optimally with more CPUs. I could probably (openRT too) load the entire FGFS scenery database and render it at 1FPS given enough RAM. Unfortunately that doesn't mean you'll be flying in a ray traced plane any time soon. -Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] [PATCH] classifying development status of aircraft extending fgrun
I'm not big on XML (done HTML before) but this: maturityalpha/maturity doesn't seem right. I would expect something more like: modeltag maturity=alpha /modeltag Where modeltag would encompase the whole model definition. Again, I'm not really familiar with just how bloated XML is supposed to be but if this is how you define a property of something it seems more wasteful than I ever thought. An even more complex thing would be to allow: modeltag bunch of stuff... maturity = alpha less developed part of model /maturity /modeltag Again, I'm no authority and I don't even know if this second thing makes sense in this context. Thanks, Paul Boris Koenig wrote: Ampere K. Hardraade wrote: whereas level can be anything between pre-alpha,alpha,pre-beta,beta and done Of course running something like fgfs --min-maturity=alpha --show-aircraft should not return any aircraft right now, as none of the current aircraft definition files in your base-package is using the required maturity/maturity tag - but you can easily give it a try by adding something like maturityalpha/maturity to abitrary aircraft ($FG_ROOT/data/Aircraft/.../*-set.xml) files. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aerial images
Actually, my grass is green all summer, and so are most of my neighbors and most businesses. I'm in Michigan and we have no shortage of water so people like to keep things green. I sometimes tell my wife not to water so much and that it's OK to let it brown a little, but it's still green. Look at the blue marble images from NASA and you'll see that the midwest is much greener than other parts of the US. There are really maybe 2 months when the wild grassy areas really turn brown at all around here. -Paul Erik Hofman wrote: It's actually quite understandable. Grass is green in spring. In the other seasons grass is mostly brown or yellow. Only in places like The UK and The Netherlands where there can be quite some rain even during the summer grass _might_ stay green a little longer. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Cloud Rendering
Has anyone looked into better cloud rendering in FGFS? There was some great work done by Mark Harris for his Ph.D. over at: http://www.markmark.net/ I couldn't remember his name, so I googled for 'cloud rendering' and his site was at the top of the list. It looks really impressive, and similar to something I saw in a Game Developer article by a MSFS guy. Mark provides source code under a free license. If that's not GPL compatible enough, perhaps someone could work out something with him for FGFS? It's just an integration problem right? ;-) Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Cloud Rendering
Melchior FRANZ wrote: * Paul Kahler -- Sunday 14 November 2004 15:57: It's just an integration problem right? ;-) No. A problem of fixing his code that is in SimGear already. Your are hereby invited to submit patches. :-} I just knew my message would result in my nomination to do the job :-) I suggested it to the list because I don't have time for such a big job. I might have time to make improvements though if it's already working to some extent. After I get my new PC (before year end) I may just start poking around in the code. Don't hold your breath though, if someone else wants to look at it, don't wait for me. Thanks, Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C++ question
It sounds to me like you should just drop the virtual function
declaration in the abstract A class (or make it non-virtual). It
serves no purpose other than trying to enforce your design on the
subclasses. Since you require the foo() function to take a parameter of
the subclass type, only a B can foo a B, and only a C can foo a C. Let
us not use complex language constructs (templates for example) just to
allow the compiler to check that you're following your own convention.
Put a comment in the base class that defines this requirement on
subclasses and call it a day. OTOH, if generic code is going to tell an
X to foo another X (somehow knowing they are the same type) this might
not work. H. I think another option is to declare A:foo(A p1) and
then have the B class explicitly cast the parameter p1 to a B inside
B:foo when using the B-specific functionality of the parameter. I don't
know how to do templates, so this is what I might do until it got too
ugly.
Hope that helps,
Paul
On Sat, 2005-01-15 at 15:12 +0100, Christian Mayer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
can someone help me to solve thise problem:
Imagine I've got this class hierachy:
class A
{
virtual bool foo( A bar ) = 0;
}
class B : A
{
bool foo( B bar )
{
...
}
}
int main( void )
{
B foobar;
}
this won't compile as my class B is still abstract as I didn't provide a
bool foo( A bar ) member.
But I only want class A to be an interface that tells everybody what to
expect from it's derivated classes. And one of these things is, that
every child must have a member that is called foo and has one
parameter of the type of the child itself.
How do I achieve that?
The only workaround I can come up with is, that I have:
class B
{
friend bool foo( class B, class B );
}
bool foo( class B bar1, class B bar2 )
{
...
}
I this doesn't guarantee me, that every child of A must have a foo
function...
Thanks,
Christian
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] STL help requested
When you write your case-insensitive compare function '0-9' are ascii 48-57 'a-z' are ascii 97-172 'A-Z' are ascii 65-90 by masking off the 32 bit, you make all letters upper case while moving the numbers to the range 16-25. Now you want the numbers to come after the letters, so you could toggle the 64 bit and get: '0-9' = 80-89 'A-Z' = 1-26 'a-z' = 1-26 So if c is an ascii character, x = ((c ~32)^64) would be a value that compares with the properties you seek. You'll still need to write a function to compare strings while using this character mapping. Hope it helps, Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
I thought you were simply looking for code portability. You must never send a binary stucture across a network. Even if you get the sizes correct, you'll have endian problems when running different architectures (PC vs Mac). You must manually ship the data bytes in a defined order and reconstruct it at the other end. At that point, it doesn't matter what the padding or for different compilers (or the order) is because you won't be sending the padding - just the data. Never block transfer a structure by providing a pointer and size, there is simply no way for that to work cross-platform. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
So the data should include a flag to tell what endian form it is, and the code should be written to support both ways? Image file formats specify and endianness in the specification, not the files. If it's in the files, then you'd need code to handle both ways... On Sun, 2005-03-27 at 09:28 -0500, Norman Vine wrote: Paul Kahler writes: Never block transfer a structure by providing a pointer and size, there is simply no way for that to work cross-platform. Please That this isn't true is amply demonstrated by all the images that get passed around the net :-) All one needs to do is make sure that the endian order of the data is well defined ! There are many ways to do this perhaps the easiest is to just use a 'magic' cookie at the beginning of the data structure *or* have a well defined structure that insures a certain endian order is imposed on the creator. Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..any estimates on SW rendering?, was: World Wind as moving map display
On Mon, 2005-04-18 at 23:17 +0200, Arnt Karlsen wrote: ..not yet, I'm scheeming a renderfarm stunt; some new 2'nd hand HW shop here says they got 200 Celeron 850's handy, so that got me thinking about picking this: http://tldp.org/HOWTO/BogoMips/x29.html#AEN54 sweet spot for a wee while. ;o) ..now this 200 node farm would need about 40, 50 to 60kWe, which I would like to feed off a genset or 2 burning gas which I would make off pelletized sewer sludge in my trusty old thermochemical gasifier. ;o) ..now, a 320,000 BogoMips rig running on poo for half a day, oughtta be able to do flyable software rendering for FlightGear at 1600x1200? ;o) ..what else can I do with this stunt rig, make our new global scenery? I guess it's time to do that ray-traced FGFS after all. But you don't have enough bandwidth for that. Perhaps 5 years out someone will have one of those new 16 processor/32 core AMD boxes laying around. That might do the job. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] realistic scenery
On Wed, 2005-04-20 at 08:16 -0700, Andy Ross wrote: Oliver C. wrote: How does X-Plane 8.1 solve that? It's not that terribly hard: store the texture mesh (2D, from the land use data) and polygon mesh (3D, from the elevation data) separately and do an intersection test when generating them (or even at load time). If the textures are allowed to overlap, you'll need to do multipass stuff or use a multitexture renderer, obviously. Another (somewhat lossy) option is to just create new texture maps from the originals. Take 2 scenery triangles (that share an edge) of roughly the same size and create a square/rectangular texture to cover them with whatever resolution you need. Then fill this texture by sampling the originals. Not all your samples will come from the same texture in the original, but when you're done, FG won't have the added complexity. There are lots of ways to do the sampling, but simply grabbing the nearest texel would be the simplest first attempt and will likely be necessary for more complex methods. It's a little lossy but keeps the complexity in the scenery generation rather than the renderer. If you've got higher resolution imagery than you want in your textures, it starts to become the perfect solution because the losses vanish as this ratio increases. -Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..any estimates on SW rendering?, was: World Wind as moving map display
Arnt Karlsen wrote: On Sat, 23 Apr 2005 11:27:01 -0400, Paul wrote in message [EMAIL PROTECTED]: I guess it's time to do that ray-traced FGFS after all. ..tell me more. But you don't have enough bandwidth for that. .. how much do I need? One 1024x768x24 image is what? 2.25MB Even at a slow 15fps that's 33 MB per second or 266Mbps plus overhead. Besides, there's no way something like that could be integrated in the time available before your stunt. I just like to think out loud sometimes. Sorry. -Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New 3d clouds
I think the old implementation has some features that the new one is missing. Of course the new one is better integrated with FG, so that's a big plus. I'd leave them both for now. On a related note, I seem to recall MS having some patents on cloud rendering. They had an article in game developer a while back that discussed it. I think they implemented the Mark Harris method or something very much like it (or did he do it for them?). Anyway, as long as Marks contribution is in FGFS I don't think anyone can claim any proprietary ownership of his methods :-) -Paul K. On Sun, 2005-04-24 at 08:43 -0700, Andy Ross wrote: Erik Hofman wrote: I have added the new 3d clouds code from Harald Johnson to CVS. Should we then remove the previous implementation? Ultimately, there is only space for one cloud implementation; if the existing clouds3d stuff isn't going to be the current target of development, it is only complicating things by being present. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: Eliminating jitter
On Thu, 2005-04-28 at 08:03 -0700, Andy Ross wrote: So the local cockpit coordinates get double-transformed to the centroid and back, losing precision in the process. That comes out to roughly 1 part in a million at single precision, which over a ~1km tile can be as much as a few millimeters, which is several pixels of screen space in a small cockpit. What's wrong with just using double precision? If it's because this math is done on the video card then fine. In ray tracing I switched to doubles over 5 years ago and measured only a tiny penalty which was more than made up for by the reduction of artifacts. Single precision is so 20th century. -Paul K ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On Mon, 2005-06-20 at 18:53 +0200, Harald JOHNSEN wrote: Ampere K. Hardraade wrote: Finally, is there a potential for this technique of generating shadow to be used on generating the effects of spot lights (eg. landing light, taxi light, logo light, etc.)? You are a genius, forget my previous reply. We can't lighten pixels from the framebuffer because of the low precision (8 bits) but we can of course darken them. Algo (works better at full night) : 1) render the scene and all non emissive geometry with a 'day' ambient term 2) render all lights (or emissive geometry) and update the stencil buffer ( stencil := 1) 3) render a quad on screen to darken everything where stencil == 0 with 1 3 the scenery goes dark/black as usual with 2 the scenery in light stay illuminated Its quasi free, simple, support a million (fake) spot light ;) Oh does that sound like a bad hack. What happens to objects that have specular highlights? Would the illumination be as if the sun were shining rather than the spotlight? Lighting is important, but this doesn't seem like it's physically correct at all. OTOH, fake lighting is better than no lighting ;-) Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] optimisation of FlightGear code
Based on several months of following this list I would guess that most of the CPU time in FGFS is spent in rendering the scenery. Just look at the recent reports of frame rate dropping with the addition of 3d clouds. Or perhaps people are limited by the graphics hardware? It sounds like the FDM and anything else can actually run acceptably on rather old hardware. Given that, and the trend toward dual core processors, it seems like splitting out the rendering into its own thread (if its not already) would make sense in the near future. Optimizing the rendering code would probably be a good thing even for us single-core folks, which is probably most everyone. -Paul On Mon, 2005-07-04 at 19:05 +0100, Jim Campbell wrote: Hi folks, Hopefully I would like to start a discussion of Flightgear code optimisation. My first thoughts are that fgfs divides logically into a number of sub-systems: a) Flight Dynamics Modelling (FDM) b) Exterior View c) Cockpit input and output ie joystick controls,switches and displays. d) Motion system but for time being I am going to disregard the last!! These sub-systems could be physically separated into processes (programs, threads - whatever you like to call them) and inter-linked with IPC eg tcp/ip, Unix sockets,etc. This would enable: 1) a critical block analysis (CBA) to be run on each sub-system to identify the most frequently used code which can then be optimised by any number of techniques. eg compiler optimisation,manual optimisation, re-writing in a more efficient language (without wishing to start a flame war, C++ and Object Orientated languages may be ideal for code development but I know of no object orientated hardware so they may not get the best out of the available hardware.) 2) running the different sub-systems on different inter-linked computers and indeed on different hardware (Intel is not famed for its floating point arithmetic so FDM may be better on PowerPC,UltraSPARC etc but there is a great range of graphics hardware which makes Linux/Intel flexible for view and cockpit). 3) tuning the frame rate of individual sub-systems (the FDM itself may benefit from different and variable frame rate for the lateral and rotational elements of the aerodynamical derivative integrations) These are just my first thoughts without tracking through every line of code as yet so maybe some of this has already been done? I dont want to repeat things that have already been chewed over so any ideas would be welcome. cheers Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Rutan and Scaled Composites [was code optimization]
YASim is perfectly happy with asymmetric aircraft, FWIW. Andy Has anyone tried to model the Boomerang? Thats the most asymmetric thing I've seen. Or any other Rutan aircraft for that mater? I once downloaded a Velocity and a Starship for MSFS and they were really fun to fly - not sure if the dynamics were correct at all because they really wanted to fly in a way thats hard to describe. OTOH I have read that canards really do like to fly compared to other aircraft. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Rutan and Scaled Composites [was code optimization]
On Sat, 2005-07-09 at 09:51 -0700, Andy Ross wrote: Paul Kahler wrote: I once downloaded a Velocity and a Starship for MSFS and they were really fun to fly - not sure if the dynamics were correct at all because they really wanted to fly in a way thats hard to describe. OTOH I have read that canards really do like to fly compared to other aircraft. The trick of the canard is that you can arrange things such that the canard surface stalls before the main wing. Because it is forward of the c.g., this causes a downward pitch, thus saving the pilot from a main wing stall. It's not quite stall proof, because it only applies to near-steady-state changes, but it will save a dumb pilot who pulls back too hard on the yoke. Oops. I know how they work. What I meant is that the ones I tried in MSFS really wanted to climb. You really had to cut the power all the way back if you wanted to get on the ground, and even then it takes some time. I've read that the real planes exhibit this behavior, but I was wondering if the models I tried exaggerated it. In case any canard fans haven't seen these: The Cozy Jet was at Oshkosh last year: http://www.eracer.org/ezhangar/cozyjetindex.html And then there's the guy who put a Mozda rotary on a LongEze and used a ducted fan instead of a reduction gear: http://www.bridgingworlds.com/DUCKT.HTM How hard would it be to simulate variations like these before they built them? And how accurate would such a simulation be? The duct seems like something that probably hasn't been simulated before and wouldn't be easy :-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Fedora Core 4
Hi, I'm looking to build FGFS on FC4-x86_64. I looked at the instructions at: http://www.flightgear.org/cvsResources/anoncvs.html It sounds reasonable, but I can't just yum install plib. Is there a repository with a suitable package? A link to instructions on using non-standard repositories would also be helpful ;-) Rinse and repeat the question for SimGear. This will be my first real dive into building nontrivial software on Linux. If I get it built and running, how big a job would it be to package it (and I suppose Plib and SimGear) so others can just yum install flightgear? I recall reading that there is an old RPM out there somewhere, but it's not current, probably not 64bit, and apparently not in the default repositories. Thanks, Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] One bug with multiplayer...
On Sat, 2005-07-16 at 22:44 +0300, Vassilii Khachaturov wrote: On a side note, while testing the multiplay mode, robitabu on #flightgear irc and I have discovered the Instant Replay is also sent to all other players. Kind of a nice feature when you want to show people stuff, but also probably something you don't want all the time... :) That's pretty cool! it's pretty harmless though, isn't it? also, when people want to see others' action a lot, and one is lazy to do takeoffs/landings all the time, this can be a nice alternative to the boring AIs in single-player --- fly a nice circuit one time, and loop it via the network to the others. Is it possible to run FGFS as a screen saver? I think prerecorded flights would make a really interesting screen saver. At our local EAA meetings (chapter13) they sometimes do slide shows before the meeting and I always thought having FGFS up there might be cool. Either a screen saver mode or a really long recorded demo would fit the bill. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns in Viewport
All this multiplayer chat stuff has me thinking game. It would probably be more in line with simulation if chatting took place on a simulated radio. You'd not only have to be close enough to someone, but you'd have to be on the same frequency in order to talk to them. The idea of having little on-screen identifiers might be OK as long as it can be turned off. I really like that FGFS focuses on simulation and not game play. If you want to be highly realistic, mutiplayer voice chat with proper radio frequencies would be ideal. Bandwidth might be a problem for large groups, but small ones should be no problem. Of course it's much more complicated too ;-) On Wed, 2005-07-20 at 09:12 +0200, Roberto Inzerillo wrote: Hi, what about a callsign identifier being displayed for each MultiPlayer airplane in the viewport of FGFS (and maybe a keyboard shortcut or an option menu for enabling/disabling the callsign visibility)? I'm thinking about something like the City-Popup discussed earlier in the ML. So we know who's the pilot flying the airplane we have around :-) It will be very usefull when multiplayer chat system will be available for team flight coordination. Airplanes still do not have other distinctive visual dientifier so a bunch of c172 look all the same. The future MP Networking code will of course have other kind of features and possibility but right now it seems to be the simplest way to identify other users in VFR. have a nice day, Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Explicit Texture Paths Committed -- not good --
On Tue, 2005-09-13 at 16:40 -0700, Andy Ross wrote: This is benign. The plib loader strips off the leading directories on the texture file name for you and uses its own path for texture lookup. I would presume that most of these things are added not by the model authors, but by the software they are using. Other than the potentially embarassing information leakage (it exposes the author's file hierarchy), this isn't really a problem. Yes, but it's sloppy. It's information that doesn't belong there. Anyone wanting to import or process that data will have to add this path stripping to their code. Better to remove it. Didn't your mother ever make you clean your room? :-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
On Wed, 2005-09-14 at 17:09 -0500, Curtis L. Olson wrote: The problem is with all the [EMAIL PROTECTED] and [EMAIL PROTECTED] mail. These addresses can't be avoided and are a huge spam attracter for the two flightgear co-list admins. But just to be clear, I'm not trying to solve a spam problem by nuking our mailing lists. Spam avoidence (for the list admins) was only one of the possible motivations for moving to forum based communication. This may be too late now unless the address changes. Get the email address off the web pages. Just where do you think the spammers are getting the address from? My ISP has some form of spam blocking, but I receive about 1 spam every month or two. I think the reason for this is that my email address isn't posted in plain text anywhere on the net. It is there of course (on my contact page), just not in machine readable form. This may not be practical for FG. I dunno, just a thought. -Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in moving-average filter?
On Fri, 2005-09-16 at 04:41 +0100, Lee Elliott wrote:
Hello List,
I think there's a small bug in the moving-average filter in
...
xmlauto.cxx
else if (filterType == movingAverage)
{
output.push_front(output[0] +
(input[0] - input.back()) /
(samples - 1));
unsigned int i;
for ( i = 0; i output_list.size(); ++i ) {
output_list[i]-setDoubleValue( output[0] );
}
output.resize(1);
}
I'm not trying to flame, but why would you be using a moving average
filter? That's the most complicated filter I've ever seen - it calls
other functions! I always liked the simplicity of a low pass filter:
output += (measurement - output) * gain;
Using floats, doubles, or fixed point of course.
No need to call a function either, just in-line it where you need it.
Want fast convergence on startup? Just sweep the gain from 1.0 down to
whatever the steady state value needs to be. I bet this is nothing new -
it's probably in the code under else if (filterType == IIRfilter) or
something.
So why do people use moving average filters? Why does FGFS?
Thanks,
Paul
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Digitrak and three axis gyro
On Wed, 2005-09-14 at 20:35 -0400, Steve Knoblock wrote: The Digitrak is described as employing gyroscopic rate sensors are installed so as to sense motion about each of the major axes (roll, yaw and pitch). I assume they mean there is a spinning gryo around which three sensors are arranged, to sense motion in each axis, pitch, roll and yaw. The sensors report how much the aircraft has moved around the gyro for each axis. Gyroscopic rate sensors measure rotation rate around a single axis with respect to whatever they're mounted on. To measure 3 axis motion requires a minimum of 3 sensors. There are no gimbals or spinning objects (vibrating parts yes). Tracking orientation with them requires integrating the signals in a rotating reference frame. You also need an absolute reference because the integrated signals will drift. Here's something google turned up: http://www.smalltimes.com/document_display.cfm?section_id=76document_id=7451 From what I can see of the various default instruments in FlightGear, the only source of roll angle from an instrument is the attitude indicator or indirectly, the turn coordinator, which the Digitrak does not use. I conclude that to model the Digitrak fully, I would need to create C code to represent this three axis gyro using the gyro.*** code that the attitude indicator depends on. I have a little experience with C, but not much. I nearly understand how the attitude indicator works with the gyro model, but I still have to many questions to comprehend all it is doing. I also assume that using /orientation/roll-angle is the best substitute currently available. I would appreciate any help with this and please correct me if I am wrong in any of this. The only way to really know what the Digitrak is doing is to know what it's really doing ;-) I think the Digitrak would make an interesting contribution to FlightGear. It would, but you may be limited to just a visual representation and some other autopilot code. It would be really hard to know exactly what their software is doing without access to source code. -Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
