Hi Adrian,
On Wed, Dec 12, 2012 at 10:12 PM, Adrian Musceac wrote:
As most of you know, the main performance issues come from having to
repeatedly sample terrain elevation for a large number of points.
This is done though and osg::NodeVisitor, which traverses all nodes within the
scenegraph
On Friday, December 14, 2012 13:09:54 Stuart Buchanan wrote:
Hi Adrian,
I haven't looked at your code, and I'm sure you've already taken care
of this, but:
The use of the SG_NODEMASK_TERRAIN_BIT by the random trees and buildings
is probably due to my ignorance when writing the code, and I
Hi Adrian,
you are doing an excellent job at marketing your product ;-)
As I do not have the time to proof you wrong, you deserve the chance to
proof me wrong! I'll shut up now and stop objecting against merging your
code. I won't be able to merge it myself before we enter the feature
freeze
Am 13.12.2012 16:28, schrieb geneb:
Um, no he's not. He just happens to be a contributor like the rest of us.
:) There is no herder for the Free Range Cats that make up the FlightGear
project. :)
How disappointing ;-)
Frankly, I think your addition to FlightGear is fantastic and a needed
On Friday, December 14, 2012 18:09:04 Torsten Dreyer wrote:
Hi Adrian,
you are doing an excellent job at marketing your product ;-)
As I do not have the time to proof you wrong, you deserve the chance to
proof me wrong! I'll shut up now and stop objecting against merging your
code. I
On 14 Dec 2012, at 16:09, Torsten Dreyer wrote:
As I do not have the time to proof you wrong, you deserve the chance to
proof me wrong! I'll shut up now and stop objecting against merging your
code. I won't be able to merge it myself before we enter the feature
freeze but probably someone
On 14 Dec 2012, at 17:27, James Turner wrote:
As I said to Adrian offline, I know there's plenty of code already checked
in, of a similar quality / design / pattern to his submission, but I'd like
to set a higher standard for new code than what we had previously.
And it case it wasn't
On Fri, 14 Dec 2012, James Turner wrote:
On 14 Dec 2012, at 17:27, James Turner wrote:
As I said to Adrian offline, I know there's plenty of code already checked
in, of a similar quality / design / pattern to his submission, but I'd like
to set a higher standard for new code than what we
On Thursday, December 13, 2012 01:03:45 Vivian Meazza wrote:
Don't we need radar altitude for buildings etc. for radar altimeters, but
probably not trees?
A radar altimeter needs to sample both the terrain and hard objects on
it.
However, I watch this work with interest: I think it might
Hi
replying to multiple posts here, I'll try to collect and answer to some
arguments.
First: I totally agree that our current nav/comm radio implementation is
far from being realistic w.r.t. propagation of the radio signal close to
or on the ground. This should be improved.
I spent an hour
Hi Torsten,
Regardless of the fact that you support or not the inclusion of this new radio
code, I have to clear up some statements which are wrong. See below.
I spent an hour or two reviewing your code and I still think your
implementation should not be merged into the code base. Let me
In some cases, the used algorithm is plain wrong as we
know by definition (ICAO rules) the propagation of the radio signal.
Um... I would like to understand this statement. The algorithm has a physics
model in. I am no expert in radio propagation, but after doing a bit of
reading, by usual FG
On Thu, 13 Dec 2012, Adrian Musceac wrote:
Please forgive my my clear words - it's not my intention to offend anybody.
No offence taken. I understand your pain/gain argument and we agree to
disagree on that. The pain is now taken care of, the gain is present.
You are one of the project
On Wed, 12 Dec 2012 23:03:45 -, Vivian wrote in message
001201cdd8bc$f5eb6b30$e1c24190$@lineone.net:
Don't we need radar altitude for buildings etc. for radar
altimeters, but probably not trees?
..at some stage, tree canopies will be dense enough to mask
the ground, or give double
On Thu, 13 Dec 2012 16:29:49 +0200, Adrian wrote in message
201212131629.50248.kanto...@gmail.com:
On Thursday, December 13, 2012 15:04:16 Renk Thorsten wrote:
Somewhat related to the above - *if* the radio propagation model
could be shown to be more realistic - what framerate loss
On Thursday, December 13, 2012 12:44:00 Torsten Dreyer wrote:
Hi
- Performance
The most important limiting factor for radio propagation on VHF and up
is question line of sight or obscured by terrain.
Hi again Torsten,
Apologising for keeping this subject up, but I rather enjoy technical
On Wednesday, December 12, 2012 09:16:50 Renk Thorsten wrote:
My suggestion is to include this feature, leave it off, and let anyone
interested turn it on.
+1
There may be many reasons to reject code, but they roughly fall into two
categories: 1) the idea itself which is coded is not
Adrian wrote
-Original Message-
From: Musceac [mailto:kanto...@gmail.com]
Sent: 12 December 2012 22:12
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Real-Time Radio Propagation
On Wednesday, December 12, 2012 09:16:50 Renk Thorsten wrote:
My suggestion
On Tuesday, December 11, 2012 00:40:16 Torsten Dreyer wrote:
Hi,
let me chime in here with a personal note, hoping it's not offending
anybody.
Hi Torsten, and thanks for your detailed message. Let me explain below why
realistic radio propagation should be inside Flightgear, and aleviate
On Tue, 11 Dec 2012 14:20:58 +0200
Adrian Musceac wrote:
My suggestion is to include this feature, leave it off, and let anyone
interested turn it on.
I can't comment on the actual code, but from the repeated detailed descriptions
of what it actually does, I think it would be a very great
I'm not a developer here, I just maintain one of the mirror sites.
I would like to comment here a bit.
Over the years I've seen several folks who contributed lots to the
project leave after disputes over one thing or another.
I'd hate to see this lead to something like that!
I personally
My suggestion is to include this feature, leave it off, and let anyone
interested turn it on.
+1
There may be many reasons to reject code, but they roughly fall into two
categories: 1) the idea itself which is coded is not acceptable or 2) the
actual implementation is not acceptable
Hi,
let me chime in here with a personal note, hoping it's not offending
anybody.
Although I like having accurate and detailed computation of our
real-world simulation, I'm not really a friend of the radio propagation
code with the level of detail given. Please let me explain why that is
the
23 matches
Mail list logo
