RE: [Flightgear-devel] Panels, Properties, and FDMs

[Jon Berndt]

> You might want to take a look at the code yourself,  I don't have the answers
> off the top of my head.  But one suggestion:  How about enhancing the
> interface by allowing the JSBSim-side to FGFS-side property mappings to be
> defined in the JSBSim configuration file?

If we are talking about the same thing, I think this has a lot of appeal, and I've been
thinking about something like this for about a week or two. I'll post some thoughts on 
it
when I git some time. I'm about ready to make a major commit into CVS that will change 
all
aircraft models and bump up the config file version number a notch.

Jon


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Panels, Properties, and FDMs

[Jim Wilson]

Jon S Berndt said:

> For JSBSim (and I imagine, YASim, and others), our turbine model (for 
> example) features various temperatures that can be reported on a panel 
> display. For any unique aircraft, as well, there will be some 
> arbitrary number of engines, with controls associated with each 
> engine. In JSBSim, at least, we have associated properties with each 
> engine control.
> 
> I had wondered at one point whether properties would make it very 
> simple to hook up various FDM parameters with associated 
> FlightGear-side panel objects -- also (I assumed) referenced via 
> properties.
> 
> I suspect now that this has a not-so-simple answer, and it will be 
> plain to see here that this is an area I am not at all familiar with.
> 
> If I was to create an FDM for a hypothetical aircraft (call it the 
> X-100) powered by six turbojets, I would of course like to have a 3D 
> model and a panel for it. I suspect that I could not simply code up 
> the definition for the panel, and link up the "live" panel components 
> with the associated JSBSim-side properties. Correct? Even if this was 
> possible, it would then (I expect) preclude other FDMs from using the 
> panel model, and this is bad. I haven't looked at the FGInterface code 
> in a while, but I suspect that that is where the handoff occurs, from 
> JSBSim-side properties to FlightGear-side properties. True?
> 
> If true, is this optimal? Does it provide for good a plug-and-play 
> design approach? Is there a better way? Is there a FAQ? :-)
> 

You might want to take a look at the code yourself,  I don't have the answers
off the top of my head.  But one suggestion:  How about enhancing the
interface by allowing the JSBSim-side to FGFS-side property mappings to be
defined in the JSBSim configuration file?

Best,

Jim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Apple compilers

[Jonathan Polley]

Oops, I also use gcc 3.3 under MacOS X 10.3.3
On May 25, 2004, at 6:17 PM, Jonathan Polley wrote:
Jon,
I couldn't find a reference to it in stdlib.h, or anywhere else in 
/usr/include.

Jonathan Polley
On May 25, 2004, at 3:45 PM, Jon S Berndt wrote:
I'm not an Apple guy, so I can't test this for sure, but can someone 
tell me if it is still true that some Apple compilers that are used 
by FlightGear developers still do not have this function:

inline char* gcvt (double value, int ndigits, char *buf)
??
Thanks,
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Apple compilers

[Jonathan Polley]

Jon,
I couldn't find a reference to it in stdlib.h, or anywhere else in 
/usr/include.

Jonathan Polley
On May 25, 2004, at 3:45 PM, Jon S Berndt wrote:
I'm not an Apple guy, so I can't test this for sure, but can someone 
tell me if it is still true that some Apple compilers that are used by 
FlightGear developers still do not have this function:

inline char* gcvt (double value, int ndigits, char *buf)
??
Thanks,
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] Apple compilers

[Jon S Berndt]

I'm not an Apple guy, so I can't test this for sure, but can someone 
tell me if it is still true that some Apple compilers that are used by 
FlightGear developers still do not have this function:

inline char* gcvt (double value, int ndigits, char *buf)
??
Thanks,
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Fwd: Fw: [Flightgear-devel] OpenGL/DirectX wrapper]

[William Earnest]

 Original Message 
Subject:Fw: [Flightgear-devel] OpenGL/DirectX wrapper
Date:   Tue, 25 May 2004 12:46:48 -0700
From:   Chris Brady <[EMAIL PROTECTED]>
Reply-To:   Chris Brady <[EMAIL PROTECTED]>
Organization:   alt.software inc
To: <[EMAIL PROTECTED]>

- Original Message -
*From:* Chris Brady 
*To:* Arnt Karlsen  ; FlightGear developers
discussions 
*Cc:* [EMAIL PROTECTED] 
*Sent:* Tuesday, May 25, 2004 12:37 PM
*Subject:* Re: [Flightgear-devel] OpenGL/DirectX wrapper
Hi:
You are welcome to link to our page.  There are no issues with this
technology and it has been in use for many years.
Chris Brady,  Silicon Valley, 408.777.8811 www.altsoftware.com

**
Visit ALT at InfoSecurity Canada 2004 June 1-3 in Toronto, ON
**

- Original Message -
*From:* Arnt Karlsen 
*To:* FlightGear developers discussions

*Cc:* [EMAIL PROTECTED] 
*Sent:* Thursday, May 06, 2004 12:53 PM
*Subject:* Re: [Flightgear-devel] OpenGL/DirectX wrapper
On Thu, 06 May 2004 14:57:57 +0200, Erik wrote in message
<[EMAIL PROTECTED] >:
 >
 > Hi,
 >
 > I found a wrapper that lets OpenGL programs use the DirectX API
 > without any change. It's using Mesa (it's even included in 
Mesa 3.1
 > and later) and hence is Freeware:
 >
 > http://www.altsoftware.com/products/opengl-directx.html
 >
 > It might be a good idea to put a link on the FlightGear page.

..I can only see legal problems, Microsoft "I.P." etc litigation,
I mean, they _can_ pull another SCOeme on us, say for
"threatening their flight sim biz" or "for infringing on their API",
just check http://groklaw.net/ .
.._everything_ else can be fixed.  And, their stereoscopic 3d
and graphics kits looks cool.  ;-)
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...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.
--
Bill Earnest  [EMAIL PROTECTED]  Linux Powered   Allentown, PA, USA
Computers, like air conditioners, work poorly with Windows open.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

RE: [Flightgear-devel] Next scenery rebuild.

[Roger Andreassen]

- There should no longer be any wildly oscillating runway surfaces.
- There should be no runway surfaces with abrupt cliffs in them.
Sorry to barge in, I have to strange ones: ENDU and ENNK. Has the above 
mention something to do with these?

- We have added beautifully modeled rotating beacons, wind socks, and 
control towers to most airports that have them.  The location of these 
items are stored in Robin's database, so if the position of these items are 
wrong, we can submit fixes for them.

Again, I'm being selfish by keeping it domestic: I miss Bodø and Svalbard 
(Longyearbyen), ENBD and ENSB respectively. Is an airport gone in Robin's 
database does it mean there's no chance to output the scenery?

If it's in early stages I'd like to air ideas as they pop up. Thanks for the 
time and effort put into this, just *wow*.

- In the new build I have chopped up long polygon edges so that they can 
follow the underlying terrain shape much better.  Now we can have land 
cover divisions (or roads) through complex terrain without adding unsightly 
artifacts.  In the process of doing this work, I found/fixed a couple bugs 
in our polygon handling.

Does anyone know how this compares to MS Flightsim's scenery? I know that 
for the Norwegian fjords they have to build "stairs" near mountains, that 
means in the bottom of a fjord the sealevel was at 300 ft in the old days 
(gone days). I know FlighGear is different but just how different, to a 
non-geek like me. :-)

Does anyone know how this compares to MS Flightsim's scenery? I know that 
for the Norwegian fjords they have to build "stairs" near mountains, that 
means in the bottom of a fjord the sealevel is 300 ft or more. I know 
FlighGear is different but just How Different, to a non-geek like me. :-)

Btw here's the best footage I could find of the control tower at ENGM. I 
think they looked at something else. ;-)

http://www1.airpics.com/viewclean.php?imgid=34462
Regards,
Roger Andreassen
(norsk)
_
MSN Messenger http://www.msn.no/messenger Den korteste veien mellom deg og 
dine venner

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Panels and instruments

[Jim Wilson]

Harald said:

> 
> Hi,
> 
> I am working on something that could perhaps help designing panels.
> While looking at the xml definition
> of panels I saw that 2d panels are defined in their own file and
> included with a  tag.
> On the other way the 3d panels are included in the plane model/animation
> .xml file.
> I find this a bit strange, we can have multiple 2d panels for one
> aircraft but only one 3d panel for
> aircrafts with 3d panels (or if we want more we must duplicate the .xml
> plane model).
> Can't we have a  tag that would work the same as 2d panels (and
> that file would include all 
> the  of the instruments) ?
> 
> Anyway you can see some screenshots the editor I am working on here
> http://www.chez.com/tipunch/fgpanel/
> 

Because they are just models.  You can select or deselect, make groups of them
and select or deselect those, etc.  Take a good look at the model doc.  

Then look at some configs (747 comes to mind) that "select" objects based on
certain conditions.  To reference the instrument models in animation specs
just add a  tag to inside the  tag.  You should then be able to
refer to the model for that instrument as an object using that name in an
 tag in your animation specs.  Same for grouping.  If you take a
look at David Megginson's pa28-161 you'll see this nicely organized.

The panel3d tag is just a kluge to map the 2D rendering to a poly in the 3D
view.  The 3D methods are as if not more flexible and intuitive for what you
describe.

Best,

Jim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Georegistered imagery

[Curtis L. Olson]

Corrubia, Stacie K wrote:
Thank you for the quick reply!
Is a circle with a 4.5mi radius small enough to model without bogging down the system? 
 We have a NVIDIA Quadro FX 1000 video graphics card.
The answer to this really depends on your texture / dem resolution.
So I should be able to bring in my high resolution imagery and be able to orient it 
and place it at the correct Lat/Lon?  Great!
There is a tool in the terragear suite called "photo" which can be used 
to "cut" a photo or texture into the scenery.  In the same subdirectory 
there is a perl script called "chop.pl" which can chop larger textures 
down into sub pieces that are within a card's maximum texture size 
(probably on the order of 4096x4096 for your card.)

The scenery tutorial seemed to cover DEMs and vector maps but not imagery files and 
their placement.  Are they handled in the same way?
It's similar.  The basic ideas is that you run the various "prep" tools 
to chop up and place the data in the correct intermediate format.  The 
you run the "fgfs-construct" utility to assemble all the pieces of a 
particular tile.  There are also some wrapper scripts for leveraging 
multiple machines to build a lot of tiles quickly.

The GIS software I have available is pretty flexible in terms of output formats so I hope to create georegistered products directly compatible with the Flight Gear environment.  

On another note is there a way to maintain object annotations (i.e. oak tree, brick building, concrete road, etc) within the system?  
 

Our scene graph allows you to name any sub branch.  Most of the 3d 
object loaders preserve any of these labels that are stored in the 3d 
file.  That may or may not be helpful depending on what you want to do 
with these labels at run time.

Regards,
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt 
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

RE: [Flightgear-devel] Georegistered imagery

[Corrubia, Stacie K]

Thank you for the quick reply!

Is a circle with a 4.5mi radius small enough to model without bogging down the system? 
 We have a NVIDIA Quadro FX 1000 video graphics card.  

So I should be able to bring in my high resolution imagery and be able to orient it 
and place it at the correct Lat/Lon?  Great!  The scenery tutorial seemed to cover 
DEMs and vector maps but not imagery files and their placement.  Are they handled in 
the same way?  The GIS software I have available is pretty flexible in terms of output 
formats so I hope to create georegistered products directly compatible with the Flight 
Gear environment.  

On another note is there a way to maintain object annotations (i.e. oak tree, brick 
building, concrete road, etc) within the system?  
 
Stacie

-Original Message-
From: Curtis L. Olson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 9:23 AM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Georegistered imagery


Corrubia, Stacie K wrote:

>Is it possible to bring in either raw or TIFF imagery to the flight gear environment?
>

Yes, it's possible, although we don't have good facilities built in for 
paging high volumes of textures.  This is ok if you want to do a small 
demo area, but you'd have problems currently doing large areas.  This is 
something I'd like to fix some day, but it hasn't risen high enough on 
my todo list yet.

> The imagery has been georegistered and is part of a set of stereo pair images used 
> to create 3-D models and DEMs.  Can the imagery data (as well as 3-models and high 
> resolution DEMs (3 meter DEMs) be overlaid on an existing lower resolution dataset 
> already  in the environment?
>
You can populate the environment with custom 3d objects.  You can use your own DEM 
data if you like and give it a higher priority than other data sources.  Currently we 
are using SRTM 3 arcsec data for the North and South America, Europe, Asia, and Africa.

Feel free to contact me on or off line if you have more specific questions.

Regards,

Curt.
-- 
Curtis Olsonhttp://www.flightgear.org/~curt 
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Georegistered imagery

[Jon Stockill]

Corrubia, Stacie K wrote:
Is it possible to bring in either raw or TIFF imagery to the flight
gear environment? The imagery has been georegistered and is part of a
set of stereo pair images used to create 3-D models and DEMs.  Can
the imagery data (as well as 3-models and high resolution DEMs (3
meter DEMs) be overlaid on an existing lower resolution dataset
already  in the environment?
Now I've stopped drooling and repeatedly saying "3 meters!" I'll reply :-)
All the flightgear scenery is preprocessed using the tools available
at www.terragear.org. If you're wanting to create high resolution 
scenery then this is where you'll need to start. There's a tutorial
here:

http://www.terragear.org/docs/scenery-tutorial/fg-scenery-tutorial.html
That will cover the basics. The code for the positioning of photographic 
images is very under-developed, and not really in a usable state yet. It 
can be made to work reasonably effectively but imposes a very high load 
on the graphics subsystem as flightgear does not yet support texture paging.

--
Jon Stockill
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Georegistered imagery

[Curtis L. Olson]

Corrubia, Stacie K wrote:
Is it possible to bring in either raw or TIFF imagery to the flight gear environment?
Yes, it's possible, although we don't have good facilities built in for 
paging high volumes of textures.  This is ok if you want to do a small 
demo area, but you'd have problems currently doing large areas.  This is 
something I'd like to fix some day, but it hasn't risen high enough on 
my todo list yet.

The imagery has been georegistered and is part of a set of stereo pair images used to 
create 3-D models and DEMs.  Can the imagery data (as well as 3-models and high 
resolution DEMs (3 meter DEMs) be overlaid on an existing lower resolution dataset 
already  in the environment?
You can populate the environment with custom 3d objects.  You can use your own DEM 
data if you like and give it a higher priority than other data sources.  Currently we 
are using SRTM 3 arcsec data for the North and South America, Europe, Asia, and Africa.
Feel free to contact me on or off line if you have more specific questions.
Regards,
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt 
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] Georegistered imagery

[Corrubia, Stacie K]

Is it possible to bring in either raw or TIFF imagery to the flight gear environment? 
The imagery has been georegistered and is part of a set of stereo pair images used to 
create 3-D models and DEMs.  Can the imagery data (as well as 3-models and high 
resolution DEMs (3 meter DEMs) be overlaid on an existing lower resolution dataset 
already  in the environment?  

Thanks.




___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel