[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Melchior Franz wrote: > Update of /var/cvs/FlightGear-0.9/data/Models/Airport > In directory baron:/tmp/cvs-serv27845 > Modified Files: > beacon.xml beacon.ac Jon, are you going to update the respective entry in our database ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
* Jon Stockill -- Sunday 29 May 2005 20:38: > Martin Spott wrote: > > Melchior Franz wrote: > > > Modified Files: > > > beacon.xml beacon.ac > > > > Jon, are you going to update the respective entry in our database ? > > [...] there are database entries for the objects in the base package just > so everything ties up the model isn't actually stored in the database. So > we've nothing to change unless the path or filename changes. For those who care: these changes to the beacon solve one of the recently discussed problems with hanging FDM: The beacon is a quite expensive structure. It consists of about 1000 vertices and 950 triangles, all on the same spot. When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Quite a waste of effort, for the fraction of a second that it takes to pass the beacon. With these changes most of the 950 faces are invisible to the ground cache. There's only a simple invisible pyramid instead for intersection tests. This does, of course mean that you can't fly between the rails through the beacon any more ... ;-) The rumour goes that fixes for the other crash/hang problems are already done, too, and will soon be applied. (And they work quite well so far. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
* Jon Stockill -- Sunday 29 May 2005 21:02: > Melchior FRANZ wrote: > > With these changes most of the 950 faces are invisible to the ground cache. > > There's only a simple invisible pyramid instead for intersection tests. > Is this something that people should consider for any high poly > structures then? For similar objects, yes. But you won't easily find something similar. The ground cache doesn't consider a big area, only about the size of the aircraft AFAIK. The Nimitz, for example, has 2071 faces (Only a bit more than twice as much as the beacon! :-) But if you fly over it, only a few hundred vertices end up in the ground cache at the same time. Because of the small size of a beacon, all the 950 went into the cache in one go. In less verbosity: this technique does only make sense for objects with high face *density*, not high face *number*. I could be wrong, of course ... m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml , 1.8,
* Frederic Bouvier -- Sunday 29 May 2005 21:32: > Melchior FRANZ a écrit : > > >In less verbosity: this technique does only make sense for objects with high > >face > >*density*, not high face *number*. > > > The beacon has a lot of vertical, or near vertical, faces. I saw them when I edited it in Blender. But how is this relevant? If the FDM stuttered before, and doesn't now? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
* Melchior FRANZ -- Sunday 29 May 2005 21:23: > * Jon Stockill -- Sunday 29 May 2005 21:02: > > Melchior FRANZ wrote: > > > With these changes most of the 950 faces are invisible to the ground > > > cache. > > > There's only a simple invisible pyramid instead for intersection tests. > > > Is this something that people should consider for any high poly > > structures then? > > For similar objects, yes. But you won't easily find something similar. Bah. Now that Mathias considers it a good idea ... I've loaded a few objects from $FG_ROOT/Models/Airport/ into Blender and, yes, some of them could use that method, too: tacan.ac, tower.ac, radar.ac do also have detailed pylons that could be made hot transparent, and replaced by a simpler structure for intersection tests. There may be some more in the object db, but most objects in CVS are already quite simple, so there wouldn't be much performance gain to expect. (cow.ac ? :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Martin Spott wrote: Melchior Franz wrote: Update of /var/cvs/FlightGear-0.9/data/Models/Airport In directory baron:/tmp/cvs-serv27845 Modified Files: beacon.xml beacon.ac Jon, are you going to update the respective entry in our database ? It's not in there. Though there are database entries for the objects in the base package just so everything ties up the model isn't actually stored in the database. So we've nothing to change unless the path or filename changes. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Melchior FRANZ wrote: For those who care: these changes to the beacon solve one of the recently discussed problems with hanging FDM: The beacon is a quite expensive structure. It consists of about 1000 vertices and 950 triangles, all on the same spot. When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Quite a waste of effort, for the fraction of a second that it takes to pass the beacon. With these changes most of the 950 faces are invisible to the ground cache. There's only a simple invisible pyramid instead for intersection tests. This does, of course mean that you can't fly between the rails through the beacon any more ... ;-) The rumour goes that fixes for the other crash/hang problems are already done, too, and will soon be applied. (And they work quite well so far. :-) Is this something that people should consider for any high poly structures then? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Melchior FRANZ a écrit : In less verbosity: this technique does only make sense for objects with high face *density*, not high face *number*. The beacon has a lot of vertical, or near vertical, faces. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
> Melchior FRANZ wrote: > > > For those who care: these changes to the beacon solve one of the recently > > discussed problems with hanging FDM: The beacon is a quite expensive > > structure. > > It consists of about 1000 vertices and 950 triangles, all on the same spot. > > When you fly over a beacon, the ground cache has to eat all these triangles, > > which makes the FDM stutter or even hang. Quite a waste of effort, for the > > fraction of a second that it takes to pass the beacon. With these changes > > most of the 950 faces are invisible to the ground cache. There's only a > > simple invisible pyramid instead for intersection tests. This does, of > > course > > mean that you can't fly between the rails through the beacon any more ... > > ;-) > > The rumour goes that fixes for the other crash/hang problems are already > > done, too, and will soon be applied. (And they work quite well so far. :-) > > Is this something that people should consider for any high poly > structures then? Is the "ground cache" for the benefit of the FDM? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
> From: "Jon Berndt" > > > Melchior FRANZ wrote: > > > > > For those who care: these changes to the beacon solve one of the recently > > > discussed problems with hanging FDM: The beacon is a quite expensive > > > structure. > > > It consists of about 1000 vertices and 950 triangles, all on the same > > > spot. > > > When you fly over a beacon, the ground cache has to eat all these > > > triangles, > > > which makes the FDM stutter or even hang. Quite a waste of effort, for the > > > fraction of a second that it takes to pass the beacon. With these changes > > > most of the 950 faces are invisible to the ground cache. There's only a > > > simple invisible pyramid instead for intersection tests. This does, of > > > course > > > mean that you can't fly between the rails through the beacon any more ... > > > > > > The rumour goes that fixes for the other crash/hang problems are already > > > done, too, and will soon be applied. (And they work quite well so far. > > > > Is this something that people should consider for any high poly > > structures then? > > Is the "ground cache" for the benefit of the FDM? > In a way you could say that, but I think that these things get called an "FDM issue", because any time the plane stops it is blamed on the FDM. More accurately, the above describes a situation where the program is getting hung up waiting for scenery related I/O and/or data crunching. To answer your question, the "ground cache" is for the benefit of the pilot. :-) Best regards, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Montag 30 Mai 2005 03:55, Jim Wilson wrote: > To answer your question, the "ground cache" is for the benefit of the > pilot. :-) I could not say that better!!! :) Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
* Jon Berndt -- Monday 30 May 2005 00:26: > > Melchior FRANZ wrote: > > > When you fly over a beacon, the ground cache has to eat all these > > > triangles, > > > which makes the FDM stutter or even hang. > Is the "ground cache" for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just called it "FDM stuttering" because this is what the user sees (and because the ground-cache code is in the FDM/ directory :-) But the FDM only stuttered, because it wasn't called in time, because of unfortunate groundcache/beacon interaction. And that wasn't really a bug, either. Neither in the beacon, nor in the ground cache. Just a detail that had to be tuned for better performance. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
> Still, I didn't mean to blame the problems on the > FDMs. I just called it "FDM stuttering" because this is what the user sees > (and because the ground-cache code is in the FDM/ directory :-) But the FDM > only stuttered, because it wasn't called in time, because of unfortunate > groundcache/beacon interaction. The groundcache/beacon interaction was only effecting the Yasim FDM, correct? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
* Dave Culp -- Monday 30 May 2005 09:27: > The groundcache/beacon interaction was only effecting the Yasim FDM, correct? I've only tested it with YASim (bo105, b1900d) where I saw it before, but not after "fixing" it. I can't say if it happened with JSBSim, although I use both regularly. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
> > Is the "ground cache" for the benefit of the FDM? > > The FDMs are currently the only users of the groundcache, and yes, they > benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been > done before Mathias implemented the ground cache. And probably it would have > been a big performance problem to constantly do intersection test with the > whole tile. Still, I didn't mean to blame the problems on the FDMs. I just What I was curious about was if per-wheel contact point checking was being done when it doesn't need to be done - that is, when the aircraft isn't even close to the ground? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Jon Berndt wrote: Is the "ground cache" for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just What I was curious about was if per-wheel contact point checking was being done when it doesn't need to be done - that is, when the aircraft isn't even close to the ground? I'm not certain the area that the ground cache covers, but I suspect it has applications beyond just contact points. ISTR Lee was wanting to know ground elevation a distance ahead of the aircraft for the terrain following mode of the TSR2s autopilot - could this be used? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Mon, 30 May 2005 08:50:43 +0200, Melchior wrote in message <[EMAIL PROTECTED]>: > * Jon Berndt -- Monday 30 May 2005 00:26: > > > Melchior FRANZ wrote: > > > > When you fly over a beacon, the ground cache has to eat all > > > > these triangles, which makes the FDM stutter or even hang. > > > Is the "ground cache" for the benefit of the FDM? > > The FDMs are currently the only users of the groundcache, and yes, > they benefit from it. A lot. Per-wheel/contact-point ground awareness > hadn't been done before Mathias implemented the ground cache. And > probably it would have been a big performance problem to constantly do > intersection test with the whole tile. Still, I didn't mean to blame > the problems on the FDMs. I just called it "FDM stuttering" because > this is what the user sees (and because the ground-cache code is in > the FDM/ directory :-) But the FDM only stuttered, because it wasn't > called in time, because of unfortunate groundcache/beacon interaction. > And that wasn't really a bug, either. Neither in the beacon, nor in > the ground cache. Just a detail that had to be tuned for better > performance. :-) ..so we need it on the ground, and "immediately before impact". ;o) ..if we disable it at altitude, how much time do we need to load it "immediately before impact" ? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Monday 30 May 2005 13:21, Jon Stockill wrote: > Jon Berndt wrote: > >>>Is the "ground cache" for the benefit of the FDM? > >> > >>The FDMs are currently the only users of the groundcache, > >> and yes, they benefit from it. A lot. > >> Per-wheel/contact-point ground awareness hadn't been done > >> before Mathias implemented the ground cache. And probably > >> it would have been a big performance problem to constantly > >> do intersection test with the whole tile. Still, I didn't > >> mean to blame the problems on the FDMs. I just > > > > What I was curious about was if per-wheel contact point > > checking was being done when it doesn't need to be done - > > that is, when the aircraft isn't even close to the ground? > > I'm not certain the area that the ground cache covers, but I > suspect it has applications beyond just contact points. ISTR > Lee was wanting to know ground elevation a distance ahead of > the aircraft for the terrain following mode of the TSR2s > autopilot - could this be used? > > Jon Hello Jon, well remembered:) I did give some thought to look-ahead algorithms and I think it would be possible to come up with a rolling max/min type algorithm that would only need one look-ahead sample per frame to get a good straight-line TF target agl. Gets much more complicated if turning, of course:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
> On Monday 30 May 2005 13:21, Jon Stockill wrote: > > I'm not certain the area that the ground cache covers, but I > > suspect it has applications beyond just contact points. ISTR > > Lee was wanting to know ground elevation a distance ahead of > > the aircraft for the terrain following mode of the TSR2s > > autopilot - could this be used? > > > > Jon > > Hello Jon, > > well remembered:) I did give some thought to look-ahead > algorithms and I think it would be possible to come up with a > rolling max/min type algorithm that would only need one > look-ahead sample per frame to get a good straight-line TF > target agl. > > Gets much more complicated if turning, of course:) > > LeeE If you are using look-ahead algorithms for terrain following (i.e. modeling a LANTIRN pod or something) this should only be enabled when it is actually used - probably not many models need that. Certainly, the C-172 does not. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Montag 30 Mai 2005 08:50, Melchior FRANZ wrote: > The FDMs are currently the only users of the groundcache, and yes, they > benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't > been done before Mathias implemented the ground cache. And probably it > would have been a big performance problem to constantly do intersection > test with the whole tile. Still, I didn't mean to blame the problems on the > FDMs. I just called it "FDM stuttering" because this is what the user sees > (and because the ground-cache code is in the FDM/ directory :-) But the FDM > only stuttered, because it wasn't called in time, because of unfortunate > groundcache/beacon interaction. And that wasn't really a bug, either. > Neither in the beacon, nor in the ground cache. Just a detail that had to > be tuned for better performance. :-) That approach to have croase objects for intersection tests and detaild ones for views is really a ood one. May be one can have models for a very low level of detail for that case. Anyway, I am thinking and started playing with that ground cache being structured in an octree. That will make the lookup time about log(n) instead of n if n is the number of triangles in the cache. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Montag 30 Mai 2005 14:21, Jon Stockill wrote: > I'm not certain the area that the ground cache covers, but I suspect it > has applications beyond just contact points. ISTR Lee was wanting to > know ground elevation a distance ahead of the aircraft for the terrain > following mode of the TSR2s autopilot - could this be used? Hmm, not really. The problem that cache solves is the lookup time when doing queries for altitude computations or in the future intersection tests with whatever (May be crashes with power lines?). If you do that test once for each timeframe and only at one place per aircraft, you can well, and you even have to, traverse the whole scenegraph to get that information. The time to traverse the whole scenegraph is too high if you want to know that information for many points and for different informations like the locations for the wires on the carrier. So the trick is to build a as small as possible subset of the scenegraph and do queries there. The smaller the cache is, the better are the response times. So for that reason, I don't think that this is usable for this task at the moment. What you will need for that will be more something similar like the groundcache covering a much bigger area. But instead of putting every surface into that cache, one could preselect the objects depending on the distance and its size, that is ignore too small ones. And additionally, one should simplyfy the surfaces to some bigger ones if they are far away. A structure like that might recycle and/or share some code with the groundcache. And such a structure can probably be well used for an improoved implementation of radar contacts. That problem is a typical LOD algorithm, I expect to find magnitudes of publications about such and fast algorithms. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
