Re: [Flightgear-devel] Instrument Making
HI Anyone know who looks after this site: http://www.seedwiki.com/wiki/flight_gear/volunteer_opportunities.cfm?wpid=213106 It says if anyone can help out - does anyone know if this is still required? Regards, Shelton. This email was sent from Netspace Webmail: http://www.netspace.net.au ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument Making
On November 2, 2005 03:04 am, Buchanan, Stuart wrote: > Does anyone know what the performance hit of using a > 3D instrument (say the ASI) rather than the standard > 2-D one is? From a quick look, most of the instruments > work by simply shifting the needle texture slightly > forward from the back-face. I have been considering > using the 3-D instruments for my changes to the C182, > but backed off in case the performance hit was > unacceptable. > > -Stuart Polycount has very little effect on performance. The biggest hit on performance is texture, in particular the alpha in the texture. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] wish list for next release
On November 1, 2005 12:43 pm, Andy Ross wrote: > Erik Hofman wrote: > > Ampere K. Hardraade wrote: > > > A texcopy function that allows one to copy one part of the texture > > > to another would be useful. > > > > Although it would be doable, one problem with this is that the textures > > themselves are stored in video memory so updating them isn't as easy as > > it sounds. > > And the APIs are complicated. Traditional (1.1) OpenGL can only do > this to and from the framebuffer, not between textures. What I meant was copying one part of the texture to another part of the same texture. Sorry for the confusion. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Status on Multiplayer
Hi Guys I have just recently got FG working and it has turned out to be a pleasant suprise - anyway just wondering what the status on Multiplayer is. Regards, Shelton. This email was sent from Netspace Webmail: http://www.netspace.net.au ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Major slowdown since yesterday
On Wednesday 02 November 2005 14:19, Martin Spott wrote: > Martin Spott wrote: > > I experience a significant slowdown in the frame rate since my last > > build yesterday. As the only significant change in CVS is the AI > > traffic on EHAM I assume the slowdown is related to that. > > I'm very sorry for that confusion. The simple reason was that I > accidentially enabled shadows for this setup and I didn't notice, > > Martin. Hi Martin, Thanks for clarifying. :-) Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 31, Issue 5
On Wed, 02 Nov 2005 12:00:09 -0600, you wrote: >the aircraft >are in the base package so if you wanted a gage from an aircraft that wasn't >in the >base package you would have to download the whole aircraft to get maybe one >gage. This is the issue I have experienced with downloading aircraft. It would be better if aircraft did not share gauges but either used their own or from a central repository. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SEGV with ATIS
> Are you using the separate alut package from OpenAL CVS? I'm using the alut in openal cvs (under alut/ directory), yes. Pigeon. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument Making
> From: "Buchanan, Stuart" > > Does anyone know what the performance hit of using a > 3D instrument (say the ASI) rather than the standard > 2-D one is? There is possibly a slight difference between running 2D vs 3D cockpits, depending on the detail of the cockpit, but we aren't talking about that. Basically no. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument Making
> From: "Innis Cunningham" > > Hi All > Now that I have been converted to 3D instrument making > I am wundering if we should start an instrument repository > like we have for the Aircraft and Scenery.This way a panel > could be built quite quickly as people would not have to > start from scratch every time. There are a few in there already. While on this subject, my experience is in building a 3D panel you have a lot of little gauage and instrument models that end up being duplicates of others with only minor changes and new textures. For example you might take an altimiter ac3d file, rename it, change the face texture, delete a needle, recalibrate the properties and now you have a manifold pressure guage. I always thought that a great deal more work could be done with 3D instruments if it was possible to specify textures in xml configurations similar to the 2D. Now with recent changes to the model animation subsystem I believe we can. This means that if we had a few generic gauge or instrument ac3d models each with a collection of needles and knobs (that could be selected by the configurer, right in the same model file as the guage or instrument), one could build an instrument or guage strictly with XML and a graphics program like gimp, similar to how the 2D panel modeling works. No AC3D or Blender required. I haven't tried doing this, but I can't see why it would not work. Best regards, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument Making
AJ MacLeod writes On Wednesday 02 November 2005 01:53, Innis Cunningham wrote: > Now that I have been converted to 3D instrument making > I am wundering if we should start an instrument repository > like we have for the Aircraft and Scenery. I do quite like the idea in some respects, but to be honest I don't think it's really necessary... > For this to work each instrument would have to be totally > self contained like the instruments in the 747 and hunter > and a few others that don't come to mind. And that's why I don't think it's necessary - for my Lightning cockpit, I've been able to make use of the Hunter instruments (which I'm guessing have family ties with the p51 instruments?) to get me started. Because I have a strange attraction to dials and gauges, and a plentiful supply of cockpit photos I took for the purpose, I've made a fairly complete set of my own, but I could equally just have borrowed any or all of the Hunter ones. My point exactly and if you added what you have done that is less someone else has to do.And the reason for the separate repository is that not all the aircraft are in the base package so if you wanted a gage from an aircraft that wasn't in the base package you would have to download the whole aircraft to get maybe one gage. Cheers, AJ Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument Making
Dave Martin writes On Wednesday 02 November 2005 01:53, Innis Cunningham wrote: > Hi All > Now that I have been converted to 3D instrument making > I am wundering if we should start an instrument repository > like we have for the Aircraft and Scenery.This way a panel > could be built quite quickly as people would not have to > start from scratch every time. > For this to work each instrument would have to be totally > self contained like the instruments in the 747 and hunter > and a few others that don't come to mind. > The Beech b1900d system would appear not to be able to > be used in this way because all the instruments use only a couple > of texture sheets which would appear to me to mean you could > not take an instrument in isolation and use it in another panel without > having to modify it.Please correct me if I am wrong on this. > > Anyway thems is my thoughts what do you think Sounds like a good idea. I don't know if you'd be interested in finishing them, but I have a set of fairly generic 3D GA instruments that I made (IIRC, they mainly need animating) No thanks Dave I am up to my ears in 737 instruments at the moment. Let me know, cheers. -- Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument Making
"Buchanan, Stuart"writes --- Innis Cunningham <[EMAIL PROTECTED]> wrote: > Now that I have been converted to 3D instrument > making > I am wundering if we should start an instrument > repository > like we have for the Aircraft and Scenery. The data CVS tree has a Aircraft/Instruments-3d subdirectory with files/directories for some 3-dimensional instruments - is this what you mean? The idea with the repository would be the same as the aircraft and scenery repositories so most of the stuff can be taken out of the DATA directory download to keep it as trim as possible and to allow people to download exactly what they want. I was wondering about adding things like yokes, pedals, throttles to it, but haven't got around to it yet. Certainly it would make life easier when creating a cockpit to just define their location rather than placing them directly into the model in AC3D. I certainly think that having hardware items to access makes the job of modeling a lot easier if you don't have to reinvent the wheel everytime.But for the time being I was just thinking of the instruments Does anyone know what the performance hit of using a 3D instrument (say the ASI) rather than the standard 2-D one is? From a quick look, most of the instruments work by simply shifting the needle texture slightly forward from the back-face. I have been considering using the 3-D instruments for my changes to the C182, but backed off in case the performance hit was unacceptable. When I was doing 2D panels I was assured that there was very little hit on the frame rates if any.I guess it is the total number of surfaces in the model that determines the frame rate.So I would think you could make a pretty detailed light aircraft panel without affecting the frame rate. When I was working on the A380 with Ampere Hardraade we tried to keep the count under 1 surfaces. Also I think we have the ability to turn off various sections of the model so that things that can't be seen from the current view point can be turned off.Someone correct me if this is wrong. -Stuart Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Major slowdown since yesterday
Martin Spott wrote: > I experience a significant slowdown in the frame rate since my last > build yesterday. As the only significant change in CVS is the AI > traffic on EHAM I assume the slowdown is related to that. I'm very sorry for that confusion. The simple reason was that I accidentially enabled shadows for this setup and I didn't notice, 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
Re: [Flightgear-devel] SEGV with ATIS
Pigeon writes: > > Hi all, > > Running fgfs cvs, starting up normally at KSFO. Bringing up the radio > dialog and switching COM1 to the ATIS frequency. Sometimes I get: > > > ERROR - mismatch between ATC .wav and .vce file in ATCVoice.cxx > > Offset + length: 2890 exceeds rawdata size: 0 > > > And sometimes it segvs, with a backtrace that looks like this: > > > #0 0x404e5927 in memcpy () from /lib/libc.so.6 > #1 0x080ee52d in FGATCVoice::WriteMessage (this=0xac0efc8, > message=0xb4a , [EMAIL PROTECTED], > [EMAIL PROTECTED]) > at ATCVoice.cxx:173 > #2 0x080c7f6b in FGATC::Render (this=0xe6b9550, [EMAIL PROTECTED], > [EMAIL PROTECTED], repeating=true) at basic_string.h:717 > #3 0x080c88a2 in FGATIS::Update (this=0xe6b9550, dt=0.125) at > atis.cxx:78 > #4 0x080a98a8 in FGATCMgr::update (this=0xaf93ba0, > dt=0.025001) > at stl_list.h:169 > #5 0x0805354d in fgMainLoop () at globals.hxx:279 > #6 0x08089235 in GLUTidle () at fg_os.cxx:114 > #7 0x400ab5c2 in glutMainLoop () from /usr/lib/libglut.so.3 > #8 0x08055800 in fgMainInit (argc=2, argv=0xb5c4) at main.cxx:1007 > #9 0x08051c2a in main (argc=2890, argv=0xb4a) at bootstrap.cxx:193 > Hmm, I think that line 79 of src/ATC/ATCVoice.hxx should be changed from unsigned int rawDataSize; to int rawDataSize; I think that this should avoid the seg fault when the sanity check is failing ( well, I can't think of any other reason OTOH ;-) ), but I'm not sure why your sound data buffers are empty. It seems that the .wav file is not loading properly, but that's more Erik's area so I'll leave it to him ;-) Excellent multiplayer map you've done BTW :-) Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument Making
On Wednesday 02 November 2005 01:53, Innis Cunningham wrote: > Now that I have been converted to 3D instrument making > I am wundering if we should start an instrument repository > like we have for the Aircraft and Scenery. I do quite like the idea in some respects, but to be honest I don't think it's really necessary... > For this to work each instrument would have to be totally > self contained like the instruments in the 747 and hunter > and a few others that don't come to mind. And that's why I don't think it's necessary - for my Lightning cockpit, I've been able to make use of the Hunter instruments (which I'm guessing have family ties with the p51 instruments?) to get me started. Because I have a strange attraction to dials and gauges, and a plentiful supply of cockpit photos I took for the purpose, I've made a fairly complete set of my own, but I could equally just have borrowed any or all of the Hunter ones. Although Syd's work on the b1900, citiation and beaver cockpits is exemplary (and I'm never likely to equal it) I do think it's a good idea for people to make instruments self contained if they don't mind working that way for the reasons you suggest. > Anyway thems is my thoughts what do you think I don't think there's really a need to maintain a special repository as such - since they're all GPL'd one can easily just use any suitable instrument from an existing FG aircraft. Having said that, if someone did go ahead with the idea, I'd be very happy to submit all the ones I've done. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] build break with some .cpp to .cxx renames
Erik, Thanks! Based on your advice, I did: ls *.cpp multiplaymgr.cpptiny_xdr.cpp rm *.cpp to remove the links I'd created then I removed the files you mentioned with: rm -f ./deps/tiny_xdr.Po rm -f ./deps/multiplaymgr.Po rerunning make in src/FlightGear/src/MultiPlayer then worked with no problems. A general make of all of flightgear also worked with no problems. Thanks, again! Ima > make[3]: *** No rule to make target `multiplaymgr.cpp', needed by > `multiplaymgr.o'. Stop. > make: *** No rule to make target `tiny_xdr.cpp', needed by > `tiny_xdr.o'. Stop. Yes, I noticed that too. It's a gcc dependency problem. In the Multiplayer directory s a hidden directory called .deps which contains a file called tiny_xdr.tpO (or something like that). You could edit that file and replace every instance of hpp by hxx and every instance of cpp by cxx and run make again. You could also remove the .deps directory (or run make clean) and run autogen.sh and configure again. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SEGV with ATIS
Pigeon wrote: Hi all, Running fgfs cvs, starting up normally at KSFO. Bringing up the radio dialog and switching COM1 to the ATIS frequency. Sometimes I get: ERROR - mismatch between ATC .wav and .vce file in ATCVoice.cxx Are you using the separate alut package from OpenAL CVS? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] SEGV with ATIS
Hi all, Running fgfs cvs, starting up normally at KSFO. Bringing up the radio dialog and switching COM1 to the ATIS frequency. Sometimes I get: ERROR - mismatch between ATC .wav and .vce file in ATCVoice.cxx Offset + length: 2890 exceeds rawdata size: 0 And sometimes it segvs, with a backtrace that looks like this: #0 0x404e5927 in memcpy () from /lib/libc.so.6 #1 0x080ee52d in FGATCVoice::WriteMessage (this=0xac0efc8, message=0xb4a , [EMAIL PROTECTED], [EMAIL PROTECTED]) at ATCVoice.cxx:173 #2 0x080c7f6b in FGATC::Render (this=0xe6b9550, [EMAIL PROTECTED], [EMAIL PROTECTED], repeating=true) at basic_string.h:717 #3 0x080c88a2 in FGATIS::Update (this=0xe6b9550, dt=0.125) at atis.cxx:78 #4 0x080a98a8 in FGATCMgr::update (this=0xaf93ba0, dt=0.025001) at stl_list.h:169 #5 0x0805354d in fgMainLoop () at globals.hxx:279 #6 0x08089235 in GLUTidle () at fg_os.cxx:114 #7 0x400ab5c2 in glutMainLoop () from /usr/lib/libglut.so.3 #8 0x08055800 in fgMainInit (argc=2, argv=0xb5c4) at main.cxx:1007 #9 0x08051c2a in main (argc=2890, argv=0xb4a) at bootstrap.cxx:193 Pigeon. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] build break with some .cpp to .cxx renames
Ima Sudonim wrote: I have co'ed all plib/simgear/flightgear files from CVS a few minutes ago. I am running autogen.sh and configure before flightgear. However I am still getting a build break on the renamed files make[3]: *** No rule to make target `multiplaymgr.cpp', needed by `multiplaymgr.o'. Stop. make: *** No rule to make target `tiny_xdr.cpp', needed by `tiny_xdr.o'. Stop. Yes, I noticed that too. It's a gcc dependency problem. In the Multiplayer directory s a hidden directory called .deps which contains a file called tiny_xdr.tpO (or something like that). You could edit that file and replace every instance of hpp by hxx and every instance of cpp by cxx and run make again. You could also remove the .deps directory (or run make clean) and run autogen.sh and configure again. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument Making
On Wednesday 02 November 2005 11:34, Dave Martin wrote: > Sounds like a good idea. > > I don't know if you'd be interested in finishing them, but I have a set of > fairly generic 3D GA instruments that I made (IIRC, they mainly need > animating) > > Few bits of eye-candy: > > http://www.cyfinity.com/fgfs/3dins2.jpg (shows bezel glasses) > > http://www.cyfinity.com/fgfs/3dins2.jpg (sun on glass) > > http://www.cyfinity.com/fgfs/kx155.jpg (radio stack) > > Unfortunately, if you try to use textures to show digital instruments you > get results like this: > > http://www.cyfinity.com/fgfs/navcomerror.jpg Should read 120.50 and 118.85 > etc but we never found a way to fix this. > > For eg: The B1900 instruments now utilise 2d panel elements to render the > digits, hence you can't easily seperate 2d and 3d elements. > > Anyway, when I finally gave up my project (ran out of time and have none > now), I'd done a full-panel mockup of the instruments I had made: > > http://www.cyfinity.com/temp/3dkitmockupfinal.jpg > > I *think* the models and .xml files might still be kicking around on > another system (or even worse) a backup CD!! *somewhere*. If someone is > genuinely interested in working with them, I'll look them out and put them > somewhere they can be grabbed (assuming they still exists) > > Let me know, cheers. > > > -- Dave Martin > > http://museum.bounce-gaming.net Last screenshot corrected link: http://www.cyfinity.com/fgfs/3dkitmockupfinal.jpg -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] build break with some .cpp to .cxx renames
I have co'ed all plib/simgear/flightgear files from CVS a few minutes ago. I am running autogen.sh and configure before flightgear. However I am still getting a build break on the renamed files make[3]: *** No rule to make target `multiplaymgr.cpp', needed by `multiplaymgr.o'. Stop. make: *** No rule to make target `tiny_xdr.cpp', needed by `tiny_xdr.o'. Stop. They both build if I create symbolic links with the old names as follows: ln -s tiny_xdr.cxx tiny_xdr.cpp ln -s multiplaymgr.cxx multiplaymgr.cpp source='multiplaymgr.cxx' object='multiplaymgr.o' libtool=no \ depfile='.deps/multiplaymgr.Po' tmpdepfile='.deps/multiplaymgr.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src - I/Users/ima/Desktop/FlightGear/fgdev9.9/include -g -O2 -D_REENTRANT - c -o multiplaymgr.o `test -f 'multiplaymgr.cxx' || echo './'`multiplaymgr.cxx source='tiny_xdr.cxx' object='tiny_xdr.o' libtool=no \ depfile='.deps/tiny_xdr.Po' tmpdepfile='.deps/tiny_xdr.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src - I/Users/ima/Desktop/FlightGear/fgdev9.9/include -g -O2 -D_REENTRANT - c -o tiny_xdr.o `test -f 'tiny_xdr.cxx' || echo './'`tiny_xdr.cxx the MultiPlayer Makefile has the following: libMultiPlayer_a_SOURCES = multiplaymgr.cxx multiplaymgr.hxx mpplayer.cxx mpplayer.hxx m pmessages.hxx tiny_xdr.cxx tiny_xdr.hxx Any ideas what's going wrong? I am using Mac os x 10.4 and gcc 4.0.0 Thanks! Ima In this repspect the following files have been renamed in src/ Multiplayer: tiny_xdr.[ch]pp has become tiny_xdr.[ch]xx multiplaymgr.[ch]pp has become multiplaymgr.[ch]xx ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument Making
On Wednesday 02 November 2005 01:53, Innis Cunningham wrote: > Hi All > Now that I have been converted to 3D instrument making > I am wundering if we should start an instrument repository > like we have for the Aircraft and Scenery.This way a panel > could be built quite quickly as people would not have to > start from scratch every time. > For this to work each instrument would have to be totally > self contained like the instruments in the 747 and hunter > and a few others that don't come to mind. > The Beech b1900d system would appear not to be able to > be used in this way because all the instruments use only a couple > of texture sheets which would appear to me to mean you could > not take an instrument in isolation and use it in another panel without > having to modify it.Please correct me if I am wrong on this. > > Anyway thems is my thoughts what do you think Sounds like a good idea. I don't know if you'd be interested in finishing them, but I have a set of fairly generic 3D GA instruments that I made (IIRC, they mainly need animating) Few bits of eye-candy: http://www.cyfinity.com/fgfs/3dins2.jpg (shows bezel glasses) http://www.cyfinity.com/fgfs/3dins2.jpg (sun on glass) http://www.cyfinity.com/fgfs/kx155.jpg (radio stack) Unfortunately, if you try to use textures to show digital instruments you get results like this: http://www.cyfinity.com/fgfs/navcomerror.jpg Should read 120.50 and 118.85 etc but we never found a way to fix this. For eg: The B1900 instruments now utilise 2d panel elements to render the digits, hence you can't easily seperate 2d and 3d elements. Anyway, when I finally gave up my project (ran out of time and have none now), I'd done a full-panel mockup of the instruments I had made: http://www.cyfinity.com/temp/3dkitmockupfinal.jpg I *think* the models and .xml files might still be kicking around on another system (or even worse) a backup CD!! *somewhere*. If someone is genuinely interested in working with them, I'll look them out and put them somewhere they can be grabbed (assuming they still exists) Let me know, cheers. -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Compile Error
Sam Ingarfield - VK6HSI wrote: ...both openal and alut are installed But there's no '-lalut' reference the linker line: ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstructure -lsgenvironment -lsgthreads -lpthread -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm -lopenal -ldl -lm -lpthread That suggests you need to run autogen.sh and configure again in the FlightGear tree. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Compile Error
...both openal and alut are installed Sam Ingarfield Student, Western Australia Erik Hofman wrote: Sam Ingarfield - VK6HSI wrote: Evening - I am currently trying to compile FlightGear - SimGear, openl, plib etc have compiled without any errors whatsoever, but for some strange and obscure reason that i can't figure, the FG compile spits this out - /root/SimGear-0.3.8/simgear/sound/soundmgr_openal.cxx:74: undefined reference to `alutInit' OpenAL in CVS has split up the OpenAL main library and alut. You can find alut in the root of the OpenAL source repository. Erik ___ 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] Instrument Making
--- Innis Cunningham <[EMAIL PROTECTED]> wrote: > Now that I have been converted to 3D instrument > making > I am wundering if we should start an instrument > repository > like we have for the Aircraft and Scenery. The data CVS tree has a Aircraft/Instruments-3d subdirectory with files/directories for some 3-dimensional instruments - is this what you mean? I was wondering about adding things like yokes, pedals, throttles to it, but haven't got around to it yet. Certainly it would make life easier when creating a cockpit to just define their location rather than placing them directly into the model in AC3D. Does anyone know what the performance hit of using a 3D instrument (say the ASI) rather than the standard 2-D one is? From a quick look, most of the instruments work by simply shifting the needle texture slightly forward from the back-face. I have been considering using the 3-D instruments for my changes to the C182, but backed off in case the performance hit was unacceptable. -Stuart ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
