Re: [Flightgear-devel] No Rembrandt here...
The first line says it all. Okay... so what does it mean? I'd first try to reduce the size of the shadow map : --prop:/sim/rendering/shadows/map-size=1024 No success, problem persists. or reduce the window size : --geometry=800x600 to reduce the memory footprint. Same as above, problem persists. Also when I use small shadow map in addition to 800x600 window no success (leaving aside the fact that Flightgear running in a window of less than a quarter of my screen isn't really thrilling...) . You have a laptop right ? Maybe you have shared memory between the CPU and the GPU (NVidia calls that TurboCache) and you didn't reserve enough memory for the GPU. This is a BIOS setting. Allocate the more you can to the GPU and retry. Can't do - this is a SONY VAIO laptop, which means you don't get to set anything relevant in the BIOS unless you start hacking it. :-( Somehow I have the feeling that this isn't a memory problem though. Experimenting with Earthview, I can load a sphere textured with 5 4096x4096 and 11 2048x2048 texture sheets allright without bothering with any smart texture management in addition to a normal Flightgear scenery and it works just fine - going through the numbers, that's quite a lot of raw data to be stored somewhere. My GPU isn't exactly new, but given what cloud and weather I can run and what others get as framerates out of the same scene, it is still rather competitive and probably better than what most people in the forum run (i.e. those who don't invest in a dedicated high-end GPU). Plus, so far with one exception (landmass effect at high quality) pretty much everything so far ran just fine out of the box with very acceptable framerates. So, I have a feeling that Rembrandt might be going to leave a lot of folks with blank screens at this point. I don't want to be negative here, maybe it is a trivial problem, but this isn't really a shader which I don't really need to see, this gives me an unusuable Flightgear. Cheers, * Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
On Tue 10 Apr 2012 10:23:23 PM CEST, ThorstenB wrote: Am 10.04.2012 21:08, schrieb Martin Spott: And there's still one thing to consider: Having one central set of apt./nav.dat files in the Base Package still doesn't address the trend of the FlightGear project and Scenery development proceeding asynchronously. But to be honest, it neither works with central terrasync scenery. We could never push any updates (such as introducing terrasync scenery with the new EDDF runway) without immediately breaking consistency with all previously released FG versions (= their base packages). And we cannot expect all users to run the same FG version - or to even update their FG setups (base packages) on the same day. A bunch of Linux distros still haven't switched to FG 2.6.0... As far as I know terrasync uses svn. So for every release we could fork a new branch which is automatically selected by the terrasync client. This would prevent all version conflicts and issues. Since we somehow hard-code navigation data into the generated scenery tiles, it really makes sense to couple them closely. Terrasync already syncs a global /Models directory, so terrasync scenery can use newer or updated models. We could do the same for nav data. I'd be happy to extend terrasync to sync another global directory, i.e. /Nav (or /Nav810, /Nav850) and then extend FG to consider these directories first, before defaulting to (old) nav/airport/airway data from the base package - which then would only need to match the (old) base package scenery (i.e. before the users pulls terrasync data for the first time). This would avoid consistency issues, unless the nav data format itself changes - like it will with the 810/850 change. But this seems a less frequent event - hopefully not happening every 3 months or every year. It wouldn't help with any individual, regional scenery projects though: these could still rely on different, conflicting versions of nav data - and we can only load one version into FG. But we probably don't need to (nor could, maybe neither should ;-) ) address this anyway... Beside serving a global nav.dat/apt.dat through terrasync, we could extend fgfs with the possibility to load custom scenery specific nav.dat. For example through patch files which are applied to the terrasync nav.dat when fgfs starts. cheers, Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Best Regards, scosu -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No Rembrandt here...
On Wed, 2012-04-11 at 06:25 +, Renk Thorsten wrote: The first line says it all. Okay... so what does it mean? I'd first try to reduce the size of the shadow map : --prop:/sim/rendering/shadows/map-size=1024 No success, problem persists. or reduce the window size : --geometry=800x600 to reduce the memory footprint. Same as above, problem persists. Also when I use small shadow map in addition to 800x600 window no success (leaving aside the fact that Flightgear running in a window of less than a quarter of my screen isn't really thrilling...) . In fact I have the same problem with a AMD-X2/3Ghz with 2Gb memory and a GeForce 9600GT: fgfs --enable-rembrandt --prop:/sim/rendering/shadows/map-size=1024 --geometry=800x60 RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cd6 Warning: RenderStage::runCameraSetUp(State) Pbuffer does not support multiple color outputs. Erik -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No Rembrandt here...
On Wed, 2012-04-11 at 06:25 +, Renk Thorsten wrote: The first line says it all. Okay... so what does it mean? I'd first try to reduce the size of the shadow map : --prop:/sim/rendering/shadows/map-size=1024 No success, problem persists. or reduce the window size : --geometry=800x600 to reduce the memory footprint. Same as above, problem persists. Also when I use small shadow map in addition to 800x600 window no success (leaving aside the fact that Flightgear running in a window of less than a quarter of my screen isn't really thrilling...) . Maybe this may help developers, it's about the same message: http://forum.openscenegraph.org/viewtopic.php?t=8905 Erik -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No Rembrandt here...
De: Erik Hofman On Wed, 2012-04-11 at 06:25 +, Renk Thorsten wrote: The first line says it all. Okay... so what does it mean? It means that a required Framebuffer Object failed to setup and the fallback isn't OK for Rembrandt. I'd first try to reduce the size of the shadow map : --prop:/sim/rendering/shadows/map-size=1024 No success, problem persists. or reduce the window size : --geometry=800x600 to reduce the memory footprint. Same as above, problem persists. Also when I use small shadow map in addition to 800x600 window no success (leaving aside the fact that Flightgear running in a window of less than a quarter of my screen isn't really thrilling...) . Maybe this may help developers, it's about the same message: http://forum.openscenegraph.org/viewtopic.php?t=8905 This issue is related to iOS and OGL ES, that is a bit different. There is the concept of implicit attachment in OSG, so INCOMPLETE_ATTACHMENT shouldn't occur if an attachment was missing in the first place. I am thinking of an explicit attachment that failed silently. There is a way to increase the OSG log level, but I don't remember it for the moment. I have to make guess as I don't have a card that exhibit that issue. You can try to edit fg/src/Main/renderer.cxx and change GL_DEPTH_COMPONENT32 to GL_DEPTH_COMPONENT24. You may also try to add the --bpp=32 option to the fgfs command line. Last, make sure that you didn't enable multithreading in preferences.xml (AutomaticSelection or something else) Plus, so far with one exception (landmass effect at high quality) pretty much everything so far ran just fine out of the box with very acceptable framerates. So, I have a feeling that Rembrandt might be going to leave a lot of folks with blank screens at this point. I don't want to be negative here, maybe it is a trivial problem, but this isn't really a shader which I don't really need to see, this gives me an unusuable Flightgear. Be sure I value your feedback, but we are exploring new lands here. There is not so much OSG deferred rendering example or real application around, so please be forgiving. And I don't think Flightgear is unusable for anybody. The Rembrandt renderer is optional and the classical/2.6 renderer should work for everybody. Regards, -Fred -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No Rembrandt here...
Be sure I value your feedback, but we are exploring new lands here. There is not so much OSG deferred rendering example or real application around, so please be forgiving. And I don't think Flightgear is unusable for anybody. The Rembrandt renderer is optional and the classical/2.6 renderer should work for everybody. Sorry if that came across the wrong way. I am well aware of this - I am probably more worried about aircraft and/or scenery being converted and committed at this stage than about project Rembrandt as such, since the default renderer is working just fine. What also bothers me is the attitude I've come across with other people (not you!) which goes like 'Don't bother writing something for the 2.6 renderer because Rembrandt will be there.' - which sounds more like replacement than optional. I'm also observing statements being made in the forum by various people - some are rather cautious, others raise expectations for a release which may backfire badly if there turn out to be issues with many cards. So I'm not writing this out of the blue. Personally, I can live without shadows if my GPU turns out not to support this at all in the end - but I can't really if all aircraft at night use Rembrandt in a non-optional way and all I get to see with default rendering is darkness. And so on. I'll explore your suggestions and let you know what happens. Cheers, * Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
ThorstenB wrote: But to be honest, it neither works with central terrasync scenery. We could never push any updates (such as introducing terrasync scenery with the new EDDF runway) without immediately breaking consistency with all previously released FG versions (= their base packages). And we cannot expect all users to run the same FG version - or to even update their FG setups (base packages) on the same day. A bunch of Linux distros still haven't switched to FG 2.6.0... But we can't guarantee backwards compatibility forever for future world scenery releases. The main problem I currently see is a different one however... Terrasync already syncs a global /Models directory, so terrasync scenery can use newer or updated models. We could do the same for nav data. I'd be happy to extend terrasync to sync another global directory, i.e. /Nav (or /Nav810, /Nav850) and then extend FG to consider these directories first, before defaulting to (old) nav/airport/airway data from the base package - which then would only need to match the (old) base package scenery (i.e. before the users pulls terrasync data for the first time). Now, it's good to see these issues getting some attention, but that is not the only issue we are facing: Taxiway signs are distributed via terrasync as stg entries. apt.dat 850 contains the taxiway definitions along with the rest of the airport data. What we do now in genapts850 is to convert the sign format from apt.dat to stg and write the corresponding files. No problem so far (and we always get the correct hight for the signs along the way). If a user wants to edit the signs, he can do it in stg, but that is a one way road. Ideally the edits should go back to upstream so everyone can profit from them. But there is no (official) way back from stg to apt.dat. I was in this situation yesterday and hacked together a quick script to be able to convert the signs. Xplane's WorldEditor (WED), an opensource program, BTW, is perfectly able to create airport layouts, signs and taxiway routes. All of this is read and written back to apt.dat. So our general question should be how to handle this situation in the most optimal way. Should we continue implementing our own xml versions of the apt.dat entries or should we rather try to read as many properties as possible directly from an apt.dat file? And how do we secure the exchange of data between stg and apt.dat? This topic is very complex and I'm sure i forgot many other important aspects, but this is just what i'm currently thinking about. Chris -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
The same applies to shipping modified apt.dat files with the Base Package as long as use-custom-scenery-data flag wasn't established as default. Noticed yesterday that the preferences.xml in fgdata does not contain the use-custom-scenery-data part anymore? Is that intentional? Shared models get now loaded from fgdata again (with current git). Oliver -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No Rembrandt here...
On Wed, 2012-04-11 at 10:18 +0200, Frederic Bouvier wrote: I have to make guess as I don't have a card that exhibit that issue. You can try to edit fg/src/Main/renderer.cxx and change GL_DEPTH_COMPONENT32 to GL_DEPTH_COMPONENT24. You may also try to add the --bpp=32 option to the fgfs command line. Last, make sure that you didn't enable multithreading in preferences.xml (AutomaticSelection or something else) None of these seems to help but when I apply the attached patch (as suggested by http://markmail.org/message/yfuz7je43bdzt6h2) at least the warnings are gone and I see the scenery (but not yet perfect). Erik diff --git a/src/Main/renderer.cxx b/src/Main/renderer.cxx index a4848d3..9f4ed10 100644 --- a/src/Main/renderer.cxx +++ b/src/Main/renderer.cxx @@ -761,9 +761,9 @@ osg::Camera* FGRenderer::buildDeferredGeometryCamera( flightgear::CameraInfo* in camera-setRenderTargetImplementation( osg::Camera::FRAME_BUFFER_OBJECT ); camera-setViewport( new osg::Viewport ); attachBufferToCamera( info, camera, osg::Camera::DEPTH_BUFFER, flightgear::GEOMETRY_CAMERA, flightgear::RenderBufferInfo::DEPTH_BUFFER ); -attachBufferToCamera( info, camera, osg::Camera::COLOR_BUFFER0, flightgear::GEOMETRY_CAMERA, flightgear::RenderBufferInfo::NORMAL_BUFFER ); -attachBufferToCamera( info, camera, osg::Camera::COLOR_BUFFER1, flightgear::GEOMETRY_CAMERA, flightgear::RenderBufferInfo::DIFFUSE_BUFFER ); -attachBufferToCamera( info, camera, osg::Camera::COLOR_BUFFER2, flightgear::GEOMETRY_CAMERA, flightgear::RenderBufferInfo::SPEC_EMIS_BUFFER ); +attachBufferToCamera( info, camera, osg::Camera::COLOR_BUFFER, flightgear::GEOMETRY_CAMERA, flightgear::RenderBufferInfo::NORMAL_BUFFER ); +attachBufferToCamera( info, camera, osg::Camera::COLOR_BUFFER, flightgear::GEOMETRY_CAMERA, flightgear::RenderBufferInfo::DIFFUSE_BUFFER ); +attachBufferToCamera( info, camera, osg::Camera::COLOR_BUFFER, flightgear::GEOMETRY_CAMERA, flightgear::RenderBufferInfo::SPEC_EMIS_BUFFER ); camera-setDrawBuffer(GL_FRONT); camera-setReadBuffer(GL_FRONT); -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No Rembrandt here...
Thorsten wrote: -Original Message- From: Renk [mailto:thorsten.i.r...@jyu.fi] Sent: 11 April 2012 09:33 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] No Rembrandt here... Be sure I value your feedback, but we are exploring new lands here. There is not so much OSG deferred rendering example or real application around, so please be forgiving. And I don't think Flightgear is unusable for anybody. The Rembrandt renderer is optional and the classical/2.6 renderer should work for everybody. Sorry if that came across the wrong way. I am well aware of this - I am probably more worried about aircraft and/or scenery being converted and committed at this stage than about project Rembrandt as such, since the default renderer is working just fine. What also bothers me is the attitude I've come across with other people (not you!) which goes like 'Don't bother writing something for the 2.6 renderer because Rembrandt will be there.' - which sounds more like replacement than optional. I'm also observing statements being made in the forum by various people - some are rather cautious, others raise expectations for a release which may backfire badly if there turn out to be issues with many cards. So I'm not writing this out of the blue. Personally, I can live without shadows if my GPU turns out not to support this at all in the end - but I can't really if all aircraft at night use Rembrandt in a non-optional way and all I get to see with default rendering is darkness. And so on. I'll explore your suggestions and let you know what happens. Ah the dangers of forums! Whether or not an aircraft is converted to Rembrandt depends on the aircraft developer. Personally, I have taken the route of adding a Rembrandt version to the inventory and leaving a version still fully compatible with 2.6.0. This is by way of being a test-bed for Rembrandt. So far it has taken several weeks, and most of it is just eye-candy. This is partly my learning curve, partly bugs, and not least the sheer size of the task. I think that you are quite right to express your concerns. I suppose in the future there might be aircraft or scenery developed purely for Rembrandt (and that would be a poor decision by the developer), but at the moment I cannot see why your fears would be realised while Rembrandt remains optional. Vivian -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No Rembrandt here...
Vivian, or anyone else with optional-Rembrandt experience, feel free to add some instructions on how to make an aircraft support both renderers to http://wiki.flightgear.org/Project_Rembrandt#Porting_aircraft So we can forward aircraft devs to that (once Rembrandt is stable/complete). Cheers, Gijs -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No Rembrandt here...
Hi Erik, De: Erik Hofman On Wed, 2012-04-11 at 10:18 +0200, Frederic Bouvier wrote: I have to make guess as I don't have a card that exhibit that issue. You can try to edit fg/src/Main/renderer.cxx and change GL_DEPTH_COMPONENT32 to GL_DEPTH_COMPONENT24. You may also try to add the --bpp=32 option to the fgfs command line. Last, make sure that you didn't enable multithreading in preferences.xml (AutomaticSelection or something else) None of these seems to help but when I apply the attached patch (as suggested by http://markmail.org/message/yfuz7je43bdzt6h2) at least the warnings are gone and I see the scenery (but not yet perfect). With this patch you are trading a bug for a bug. Assigning the same attachment to three buffers as the same effect than assigning three different values to the same variable. Regards, -Fred -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No Rembrandt here...
On Wed, 2012-04-11 at 13:35 +0200, Frederic Bouvier wrote: Hi Erik, With this patch you are trading a bug for a bug. Assigning the same attachment to three buffers as the same effect than assigning three different values to the same variable. I was already afraid something like that was happening. Erik -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No Rembrandt here...
On Wed, 2012-04-11 at 13:35 +0200, Frederic Bouvier wrote: Hi Erik, With this patch you are trading a bug for a bug. Assigning the same attachment to three buffers as the same effect than assigning three different values to the same variable. I was already afraid something like that was happening. Try --prop:/sim/rendering/no-16bit-buffer=true although the symptoms were a bit different Regards, -Fred -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No Rembrandt here...
On Wed, 2012-04-11 at 14:15 +0200, Frederic Bouvier wrote: On Wed, 2012-04-11 at 13:35 +0200, Frederic Bouvier wrote: Hi Erik, With this patch you are trading a bug for a bug. Assigning the same attachment to three buffers as the same effect than assigning three different values to the same variable. I was already afraid something like that was happening. Try --prop:/sim/rendering/no-16bit-buffer=true although the symptoms were a bit different Yes! that works. Erik -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGbuild for MS Windows
Do I have to create my own unistd.h? Or do we have a replacement that works with VS? Where would I find a copy? 4 lowlevel.cxx 4c:\fgbuild\dependencies\3rdparty\include\zconf.h(289): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory 4 sg_binobj.cxx 3c:\fgbuild\dependencies\3rdparty\include\zconf.h(289): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory 4c:\fgbuild\dependencies\3rdparty\include\zconf.h(289): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory 4 Generating Code. John - Original Message - From: castle 64 castle...@comcast.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Tuesday, April 10, 2012 9:47:00 PM Subject: Re: [Flightgear-devel] FGbuild for MS Windows OK, disregard the previous msg. got a SimGear build started but it failed. Enough fun for one day, will attack the error msgs tomorrow.. John - Original Message - From: castle 64 castle...@comcast.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Tuesday, April 10, 2012 9:04:50 PM Subject: Re: [Flightgear-devel] FGbuild for MS Windows OK, got through the configure and generate operations with CMake version is 2 dot 7 dot 0 ignoring: ^C:/fgbuild/simgear/.git;\\.gitignore;Makefile.am;~$; Library installation directory: lib 3rdparty files located in C:/fgbuild/dependencies BOOST_ROOT is C:/fgbuild/dependencies/boost_1_44_0 apr-1-config not found, implement manual search for APR Could NOT find LIBSVN (missing: LIBSVN_LIBRARIES LIBSVN_INCLUDE_DIR) Missing libsvn, unable to enable SVN in SimGear Configuring done Generating done however, doesn't appear a VS solution file (.sln) has been created in the Simgear directory or it was placed somewhere else and can't find it Not sure what to include by way of commands or logs to help show what happened. John Something is still not corrrect. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGbuild for MS Windows
reply to self have your morning coffee before engaging the brain. ;-) found the note on editing zconf.h. Simgear build and install completed; onto to flightgear John - Original Message - From: castle 64 castle...@comcast.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Wednesday, April 11, 2012 6:46:18 AM Subject: Re: [Flightgear-devel] FGbuild for MS Windows Do I have to create my own unistd.h? Or do we have a replacement that works with VS? Where would I find a copy? 4 lowlevel.cxx 4c:\fgbuild\dependencies\3rdparty\include\zconf.h(289): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory 4 sg_binobj.cxx 3c:\fgbuild\dependencies\3rdparty\include\zconf.h(289): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory 4c:\fgbuild\dependencies\3rdparty\include\zconf.h(289): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory 4 Generating Code. John - Original Message - From: castle 64 castle...@comcast.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Tuesday, April 10, 2012 9:47:00 PM Subject: Re: [Flightgear-devel] FGbuild for MS Windows OK, disregard the previous msg. got a SimGear build started but it failed. Enough fun for one day, will attack the error msgs tomorrow.. John - Original Message - From: castle 64 castle...@comcast.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Tuesday, April 10, 2012 9:04:50 PM Subject: Re: [Flightgear-devel] FGbuild for MS Windows OK, got through the configure and generate operations with CMake version is 2 dot 7 dot 0 ignoring: ^C:/fgbuild/simgear/.git;\\.gitignore;Makefile.am;~$; Library installation directory: lib 3rdparty files located in C:/fgbuild/dependencies BOOST_ROOT is C:/fgbuild/dependencies/boost_1_44_0 apr-1-config not found, implement manual search for APR Could NOT find LIBSVN (missing: LIBSVN_LIBRARIES LIBSVN_INCLUDE_DIR) Missing libsvn, unable to enable SVN in SimGear Configuring done Generating done however, doesn't appear a VS solution file (.sln) has been created in the Simgear directory or it was placed somewhere else and can't find it Not sure what to include by way of commands or logs to help show what happened. John Something is still not corrrect. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No Rembrandt here...
Hi Thorsten, I think that is what we have for now. You can do better by increasing your shadow map size to 8192 or 16384, but at the 16384 resolution my performance goes into the tank, and at 8192, there are still many shadow artifacts due to lack of resolution. (clearly blocky/xelated/aliasing edges, something that looks like z-buffer fighting for objects further way, etc.) Hopefully this will improve with future tuning. I'd love to be able to overfly the SFO terminal at 1000' for instance and have solid shadows on the AI aircraft, solid shadows on the light poles, solid shadows from the terminal building, etc. I'm hoping that will ultimately be possible. Otherwise, just getting one good clear shadow of our own aircraft onto the ground and onto ourselves would be a good 90% solution. Curt. On Wed, Apr 11, 2012 at 7:52 AM, Renk Thorsten thorsten.i.r...@jyu.fiwrote: Try --prop:/sim/rendering/no-16bit-buffer=true although the symptoms were a bit different Same here, this sort of works up to the 4096 map size. I do see shadows and lights at night at KSFO, but the shadows are very... restless - they seem to flicker quite a bit, and all in all the light I get to see depends very much on the view angle - is that normal? The grainy shadow edge seems to be a function of the map size, it gets a lot worse when I go to 1024... Thanks for the fix in any case! Cheers, * Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGbuild for MS Windows
Hi, The wiki writeup did not talk about using glut or FLTK or whatever for the graphics. The fgfs build failed. 13 Creating library C:/fgbuild/projects/msvc100/FlightGear/src/Main/Debug/fgfs.lib and object C:/fgbuild/projects/msvc100/FlightGear/src/Main/Debug/fgfs.exp 13LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library 13FGPUIDialog.obj : error LNK2019: unresolved external symbol public: void __thiscall puaList::setTopItem(int) (?setTopItem@puaList@@QAEXH@Z) referenced in function public: virtual void __thiscall fgList::update(void) (?update@fgList@@UAEXXZ) 13property_list.obj : error LNK2001: unresolved external symbol public: void __thiscall puaList::setTopItem(int) (?setTopItem@puaList@@QAEXH@Z) 13FGPUIDialog.obj : error LNK2019: unresolved external symbol public: int __thiscall puaList::getTopItem(void)const (?getTopItem@puaList@@QBEHXZ) referenced in function public: virtual void __thiscall fgList::update(void) (?update@fgList@@UAEXXZ) 13property_list.obj : error LNK2001: unresolved external symbol public: int __thiscall puaList::getTopItem(void)const (?getTopItem@puaList@@QBEHXZ) 13C:\fgbuild\projects\msvc100\FlightGear\src\Main\Debug\fgfs.exe : fatal error LNK1120: 2 unresolved externals 15-- Rebuild All started: Project: ALL_BUILD, Configuration: Debug Win32 -- 15 Build all projects 15 Building Custom Rule C:/fgbuild/flightgear/CMakeLists.txt 15 CMake does not need to re-run because C:\fgbuild\projects\msvc100\FlightGear\CMakeFiles\generate.stamp is up-to-date. 16-- Skipped Rebuild All: Project: INSTALL, Configuration: Debug Win32 -- 16Project not selected to build for this solution configuration 17-- Skipped Rebuild All: Project: PACKAGE, Configuration: Debug Win32 -- 17Project not selected to build for this solution configuration == Rebuild All: 13 succeeded, 1 failed, 3 skipped == Any suggestion where to look? ATM I'm clueless . :-( John 13 Creating library C:/fgbuild/projects/msvc100/FlightGear/src/Main/Debug/fgfs.lib and object C:/fgbuild/projects/msvc100/FlightGear/src/Main/Debug/fgfs.exp 13LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library 13FGPUIDialog.obj : error LNK2019: unresolved external symbol public: void __thiscall puaList::setTopItem(int) (?setTopItem@puaList@@QAEXH@Z) referenced in function public: virtual void __thiscall fgList::update(void) (?update@fgList@@UAEXXZ) 13property_list.obj : error LNK2001: unresolved external symbol public: void __thiscall puaList::setTopItem(int) (?setTopItem@puaList@@QAEXH@Z) 13FGPUIDialog.obj : error LNK2019: unresolved external symbol public: int __thiscall puaList::getTopItem(void)const (?getTopItem@puaList@@QBEHXZ) referenced in function public: virtual void __thiscall fgList::update(void) (?update@fgList@@UAEXXZ) 13property_list.obj : error LNK2001: unresolved external symbol public: int __thiscall puaList::getTopItem(void)const (?getTopItem@puaList@@QBEHXZ) 13C:\fgbuild\projects\msvc100\FlightGear\src\Main\Debug\fgfs.exe : fatal error LNK1120: 2 unresolved externals 15-- Rebuild All started: Project: ALL_BUILD, Configuration: Debug Win32 -- 15 Build all projects 15 Building Custom Rule C:/fgbuild/flightgear/CMakeLists.txt 15 CMake does not need to re-run because C:\fgbuild\projects\msvc100\FlightGear\CMakeFiles\generate.stamp is up-to-date. 16-- Skipped Rebuild All: Project: INSTALL, Configuration: Debug Win32 -- 16Project not selected to build for this solution configuration 17-- Skipped Rebuild All: Project: PACKAGE, Configuration: Debug Win32 -- 17Project not selected to build for this solution configuration == Rebuild All: 13 succeeded, 1 failed, 3 skipped == Any suggestion where to look? ATM I'm clueless . :-( John-- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGbuild for MS Windows
On Wed, 11 Apr 2012, castle...@comcast.net wrote: found the note on editing zconf.h. Simgear build and install completed; onto to flightgear John \o/ g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Buying desktop hardware and installing a server OS doesn't make a server-class system any more than sitting in a puddle makes you a duck. [Cipher in a.s.r]-- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGbuild for MS Windows
Hi John, 1: unistd.h Yes I ran across the missing 'unistd.h' in zconf.h recently, but I thought my problem was in FG, but maybe also SG... The FIX is simple I think... somewhere there is a 'config.h' - one I know about is in FG\util\fgadmin\src - which has - #define HAVE_UNISTD_H 1 This causes zconf.h to look for 'unistd.h' Find that file, and change that line to #undef HAVE_UNISTD_H There are several other things defined in that file which are also 'wrong' but do not cause any problems since they are not used... Should not be necessary to modify zconf.h, but that is another way around this problem ;=)) 2: puaList = missing PLIB - puAux.lib In the CMake GUI scroll down, down and check the PLIB library libraries found... PLIB_PUAUX_LIBRARY - should be blank PLIB_PUAUX_LIBRARY_DEBUG - should be like c:\fgbuild\dependencies\3rdparty\lib\puauxd.lib PLIB_PUAUX_LIBRARY_RELEASE - should be like c:\fgbuild\dependencies\3rdparty\lib\puaux.lib PLIB_PUI_LIBRARY - should be blank PLIB_PUI_LIBRARY_DEBUG - should be like c:\fgbuild\dependencies\3rdparty\lib\pud.lib PLIB_PUI_LIBRARY_RELEASE - should be like c:\fgbuild\dependencies\3rdparty\lib\pu.lib And each of the other PLIB items should point to each of the other plib libraries... You can also open and check the file fgfs.log written by MSVC10 and check exactly WHAT libraries are presently being linked to fgfs.exe... find the bin\link.exe line... it is a BIG list... If not this, then not sure... Aside from the above ???.log files, another file you can post somewhere is the CMakeCache..txt... it gives LOTS of information, and with a view of its contents we may be able to help you better... Regards, Geoff. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGbuild for MS Windows
Thanks Geoff, zconf.h is taken care off, looked in the libraries and puAux.lib and pu.lib are there. Here is an extract from the CMakecache.txt file. //Path to a library. PLIB_LIBRARIES:FILEPATH=PLIB_LIBRARIES-NOTFOUND //The PLIB_PUAUX library PLIB_PUAUX_LIBRARY:FILEPATH=optimized;C:/fgbuild/dependencies/3rdParty/lib/puAux.lib;debug;C:/fgbuild/dependencies/3rdParty/lib/puAux.lib //Path to a library. PLIB_PUAUX_LIBRARY_DEBUG:FILEPATH=PLIB_PUAUX_LIBRARY_DEBUG-NOTFOUND //Path to a library. PLIB_PUAUX_LIBRARY_RELEASE:FILEPATH=C:/fgbuild/dependencies/3rdParty/lib/puAux.lib //The PLIB_PUI library PLIB_PUI_LIBRARY:FILEPATH=optimized;C:/fgbuild/dependencies/3rdParty/lib/pui.lib;debug;C:/fgbuild/dependencies/3rdParty/lib/pui.lib //Path to a library. PLIB_PUI_LIBRARY_DEBUG:FILEPATH=PLIB_PUI_LIBRARY_DEBUG-NOTFOUND //Path to a library. PLIB_PUI_LIBRARY_RELEASE:FILEPATH=C:/fgbuild/dependencies/3rdParty/lib/pui.lib looks slightly different ( pui vs. pu and puaux vs.puAux, is that significant?) there is no pu.lib or puaux.lib. wasn't able to track down the log file, where would you find it or is there an option in the CMake script to specify location Ugggh, hate being a newbie and just when I was getting comfortable with the GNU make system ;-) John - Original Message - 2: puaList = missing PLIB - puAux.lib In the CMake GUI scroll down, down and check the PLIB library libraries found... PLIB_PUAUX_LIBRARY - should be blank PLIB_PUAUX_LIBRARY_DEBUG - should be like c:\fgbuild\dependencies\3rdparty\lib\puauxd.lib PLIB_PUAUX_LIBRARY_RELEASE - should be like c:\fgbuild\dependencies\3rdparty\lib\puaux.lib PLIB_PUI_LIBRARY - should be blank PLIB_PUI_LIBRARY_DEBUG - should be like c:\fgbuild\dependencies\3rdparty\lib\pud.lib PLIB_PUI_LIBRARY_RELEASE - should be like c:\fgbuild\dependencies\3rdparty\lib\pu.lib And each of the other PLIB items should point to each of the other plib libraries... You can also open and check the file fgfs.log written by MSVC10 and check exactly WHAT libraries are presently being linked to fgfs.exe... find the bin\link.exe line... it is a BIG list... If not this, then not sure... Aside from the above ???.log files, another file you can post somewhere is the CMakeCache..txt... it gives LOTS of information, and with a view of its contents we may be able to help you better... Regards, Geoff. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] airport list
I figured out how to use FGAirport::findClosest to accomplish what I needed:static SGConstPropertyNode_ptr latn = fgGetNode("/position/latitude-deg", true);static SGConstPropertyNode_ptr lonn = fgGetNode("/position/longitude-deg", true);SGGeod pos;FGAirport* apt = NULL;AirportInfoFilter filter;double maxRange = 1.0;pos = SGGeod::fromDeg(lonn-getDoubleValue(), latn-getDoubleValue());apt = FGAirport::findClosest(pos, maxRange, filter);string id = apt-ident();The above results in id being the single nearest ICAO. Throw this in a loop and iterate the pos lonn/lat the amount of the loop iterator, put the results in an array, then choose a random ICAO from the array using rand(). Then you have a list of ICAOs N, S, E, and W from your current location. The longer the loop or the greater the iterator, the further away the ICAOs go. For example:for (float i=.1; i 5; i = i + .1) { pos = SGGeod::fromDeg(lonn-getDoubleValue(), latn-getDoubleValue() + i); apt = FGAirport::findClosest(pos, maxRange, filter); string id = apt-ident(); dest[x] = id; x = x + 1; }In the above dest[] will contain 50 ICAOs. Some will be duplicates since a .1 increment in latitude may result in the same airport being the nearest. But that can be tweaked to one's need.gapalpgap...@gapalp.net
Original Message
Subject: [Flightgear-devel] airport list
From: gap...@gapalp.net
Date: Mon, April 09, 2012 6:34 pm
To: "FlightGear Development" flightgear-devel@lists.sourceforge.net
I just started playing around in FlightGear development and wanted to intro myself. You all have a great piece of software here and I am enjoying it. I come from years of flight simming in other programs and doing some small commercial work in them. My day job involves corporate app development. My hobbies are astronomy, flight simming, and coding.Anyway, I am playing around with a cargo manager for FG. I have run into needing to pull an airport list to use in a random cargo job generator. Airinfo() and navinfo() don't appear to do it for me. Any way to get the list using an available C++ function? Just a list of ICAOs would be a start. Or will I need to read/parse through the apt.dat file?Thanks and I look forward to some coding fun :)gapalpgap...@gapalp.net --
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
