Re: [Flightgear-devel] Now Rembrandt here...
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. Okay, just to be sure, I've now also compared what I see to the IAR-80 on Vinson video by Fred and to the Cub flying around Kufstein video by HHS. I'm seeing a number of issues: 1) The shadows around the aircraft have a ragged egde. That I understand is a function of the shadow map size. I can't go beyond 4096, I get an error on the console trying to go higher - but 4096 works fine with acceptable framerates, the edge is just a limit of my GPU and that is okay. 2) I see shadows flickering (I tried the Cub cockpit for comparison) when I'm in level flight where they shouldn't move - the effect is a bit like a shadow cast by a candle flickering in the wind. In Heiko's video that is sometimes visible (he doesn't fly straight much, and when the shadows actually move the effect is masked). I've never seen it in Fred's videos - is it not there, or just not in the video? Personally, I find that flickering maddening - I've ended my test flight after 5 minutes because I was starting to get a headache. 3) On my box, all three panels in the screen edges show the same image - not so on Fred's videos - is this the intended behaviour? 4) Fred's IAR-80 video has the camera circling around an IAR-80 parked on the Vinson. I tried to do this as well, but for me the effect comes out very differently. The amount of shadow I see depends on the angle of the view axis with the sunlight direction - under some angles I see dark shadows, under some angles I see no shadows at all whereas in the video the shadows behave as expected, i.e. they stay the same independent of view angle. Under some angles (sun in my back) I also get a whiteout of bright textures. I haven't seen this issue in any of the videos, but it likewise looks very unrealistic - I watch an object, and as I overfly it, the shadow goes away... (Needless to say, I've switched any lightfield rendering scheme which would interfere off... Also, most tests I've done with FGData master rather than my customized branch) As I said earlier, I respect the amount of work which has gone into that very much and I'm also aware that this is brand new technology with some quirks to be sorted out. But at least I can't really work with it or fly the state which is on my system. So - since it's not working here - can I help in any way to pin down the issues and so help you fixing them? Cheers, * Thorsten -- 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
Re: [Flightgear-devel] airport list
On 11 Apr 2012, at 20:48, gap...@gapalp.net wrote: 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: Uh, the findClosest (and related FGPositioned functions) use the spatial index, which is probably not what you want - since they're a bit slower. What exactly *do* you want? The current query functions support querying by position or by ident (possibly a partial ident). If you're looking for a flat list of all the airport IDs, that may not actually be exposed right now in C++, but would be trivial to add. James -- 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
Re: [Flightgear-devel] Now Rembrandt here...
On 12 Apr 2012, at 08:24, Renk Thorsten wrote: 3) On my box, all three panels in the screen edges show the same image - not so on Fred's videos - is this the intended behaviour? This is the important one - it means the multiple render targets isn't working, so you have no chance of seeing anything sensible with Rembrandt. (As I understand it) James -- 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
Re: [Flightgear-devel] Now Rembrandt here...
Thorsten wrote: 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. Okay, just to be sure, I've now also compared what I see to the IAR-80 on Vinson video by Fred and to the Cub flying around Kufstein video by HHS. I'm seeing a number of issues: 1) The shadows around the aircraft have a ragged egde. That I understand is a function of the shadow map size. I can't go beyond 4096, I get an error on the console trying to go higher - but 4096 works fine with acceptable framerates, the edge is just a limit of my GPU and that is okay. 2) I see shadows flickering (I tried the Cub cockpit for comparison) when I'm in level flight where they shouldn't move - the effect is a bit like a shadow cast by a candle flickering in the wind. In Heiko's video that is sometimes visible (he doesn't fly straight much, and when the shadows actually move the effect is masked). I've never seen it in Fred's videos - is it not there, or just not in the video? Personally, I find that flickering maddening - I've ended my test flight after 5 minutes because I was starting to get a headache. 3) On my box, all three panels in the screen edges show the same image - not so on Fred's videos - is this the intended behaviour? 4) Fred's IAR-80 video has the camera circling around an IAR-80 parked on the Vinson. I tried to do this as well, but for me the effect comes out very differently. The amount of shadow I see depends on the angle of the view axis with the sunlight direction - under some angles I see dark shadows, under some angles I see no shadows at all whereas in the video the shadows behave as expected, i.e. they stay the same independent of view angle. Under some angles (sun in my back) I also get a whiteout of bright textures. I haven't seen this issue in any of the videos, but it likewise looks very unrealistic - I watch an object, and as I overfly it, the shadow goes away... The disappearing shadow was caused by the sun camera and range animation and was fixed a while back - can you confirm that you are using the very latest fg/sg/fgdata? And it's probably worth checking that you have the very latest nVidia drivers. It looks to me as if you are pushing the very limits of your GPU; I think you might have to accept that you are not going to be able to use the added facilities provided by Rembrandt. Vivian Vivian -- 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
Re: [Flightgear-devel] Now Rembrandt here...
On Thu, 2012-04-12 at 09:01 +0100, James Turner wrote: On 12 Apr 2012, at 08:24, Renk Thorsten wrote: 3) On my box, all three panels in the screen edges show the same image - not so on Fred's videos - is this the intended behaviour? This is the important one - it means the multiple render targets isn't working, so you have no chance of seeing anything sensible with Rembrandt. (As I understand it) Also I see that --prop:/sim/rendering/no-16bit-buffer=true falls back to 8-but normal buffers. That might be just a bit to low for normal buffers. Erik -- 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
Re: [Flightgear-devel] Now Rembrandt here...
On Thu, 2012-04-12 at 10:29 +0200, Erik Hofman wrote: On Thu, 2012-04-12 at 09:01 +0100, James Turner wrote: On 12 Apr 2012, at 08:24, Renk Thorsten wrote: 3) On my box, all three panels in the screen edges show the same image - not so on Fred's videos - is this the intended behaviour? This is the important one - it means the multiple render targets isn't working, so you have no chance of seeing anything sensible with Rembrandt. (As I understand it) Also I see that --prop:/sim/rendering/no-16bit-buffer=true falls back to 8-but normal buffers. That might be just a bit to low for normal buffers. And it looks that way, Replacing GL_RGBA8 with GL_RGBA16 removes the flickering and still got me a working system. Erik -- 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
Re: [Flightgear-devel] Now Rembrandt here...
The disappearing shadow was caused by the sun camera and range animation and was fixed a while back - can you confirm that you are using the very latest fg/sg/fgdata? And it's probably worth checking that you have the very latest nVidia drivers. FG, SG and FGData are pulled and compiled as of yesterday noon, should be recent enough. The driver is somewhat older - as with anything which works fine on my computer, I'm reluctant to fiddle with it because on past occasions I have found myself struggling for a few days just to restore the previous state of the system when an update went wrong, and I simply don't have the time. It looks to me as if you are pushing the very limits of your GPU; I think you might have to accept that you are not going to be able to use the added facilities provided by Rembrandt. I have no problem with that (modulo the concerns I expressed yesterday) - I'm just trying to determine how my time is best spent. If there's a consensus that my GPU isn't up to the job, then I'll extend my atmosphere rendering framework for non-Rembrandt rendering and if anyone wants it in Rembrandt someone else has to port it because I can't develop something when I can't see the results. If Rembrandt can be made to work on my machine, then I can write stuff within the Rembrandt framework at some point. That's all there is to it. Cheers, * Thorsten -- 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
Re: [Flightgear-devel] Now Rembrandt here...
On Thu, 2012-04-12 at 10:35 +0200, Erik Hofman wrote: On Thu, 2012-04-12 at 10:29 +0200, Erik Hofman wrote: On Thu, 2012-04-12 at 09:01 +0100, James Turner wrote: On 12 Apr 2012, at 08:24, Renk Thorsten wrote: 3) On my box, all three panels in the screen edges show the same image - not so on Fred's videos - is this the intended behaviour? This is the important one - it means the multiple render targets isn't working, so you have no chance of seeing anything sensible with Rembrandt. (As I understand it) Also I see that --prop:/sim/rendering/no-16bit-buffer=true falls back to 8-but normal buffers. That might be just a bit to low for normal buffers. And it looks that way, Replacing GL_RGBA8 with GL_RGBA16 removes the flickering and still got me a working system. even GL_RGB16 works. Erik -- 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
Re: [Flightgear-devel] updates to nav.dat.gz
On Wed, 11 Apr 2012 10:48:46 +0200, Christian wrote in message 20120411084846.02ffa1456...@mail.sigmos.de: Xplane's WorldEditor (WED), an opensource program, ..under the GPL like FlightGear? In that case we can simply shanghai it into the FG tool suite. :o) 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 -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...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. -- 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
Re: [Flightgear-devel] Now Rembrandt here...
De: James Turner On 12 Apr 2012, at 08:24, Renk Thorsten wrote: 3) On my box, all three panels in the screen edges show the same image - not so on Fred's videos - is this the intended behaviour? This is the important one - it means the multiple render targets isn't working, so you have no chance of seeing anything sensible with Rembrandt. (As I understand it) Glad to see someone else if able to make the correct diagnosis :) If the internal buffer are not correct, lighting equations done in the ambient, sunlight and fog pass will work on bogus inputs. I'll add that you get that either if an effect not converted to Rembrandt is used, or if the default shader has a build error and OSG fallback to fixed functions. So if the lightfield or the skydome is not enabled, check the console for a shader build error. Regards, -Fred -- 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
Re: [Flightgear-devel] Now Rembrandt here...
De: Erik Hofman e...@ehofman.com On Thu, 2012-04-12 at 10:35 +0200, Erik Hofman wrote: On Thu, 2012-04-12 at 10:29 +0200, Erik Hofman wrote: On Thu, 2012-04-12 at 09:01 +0100, James Turner wrote: On 12 Apr 2012, at 08:24, Renk Thorsten wrote: 3) On my box, all three panels in the screen edges show the same image - not so on Fred's videos - is this the intended behaviour? This is the important one - it means the multiple render targets isn't working, so you have no chance of seeing anything sensible with Rembrandt. (As I understand it) Also I see that --prop:/sim/rendering/no-16bit-buffer=true falls back to 8-but normal buffers. That might be just a bit to low for normal buffers. And it looks that way, Replacing GL_RGBA8 with GL_RGBA16 removes the flickering and still got me a working system. even GL_RGB16 works. For all the buffers or only the normal buffer ? You're not supposed to have multiple render target of different element size. RGBA8 = 32bits, as well as RG16. What is your card brand and model ? I came across a blog post that compares multiple ways to compress the normals in an 8bit texture and I will try that shortly. Regards, -Fred -- 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
Re: [Flightgear-devel] Now Rembrandt here...
On Thu, 2012-04-12 at 10:43 +0200, Erik Hofman wrote:
even GL_RGB16 works.
And therefore I propose this patch.
Erik
diff --git a/src/Main/renderer.cxx b/src/Main/renderer.cxx
index 1c6e77b..1c5ea0a 100644
--- a/src/Main/renderer.cxx
+++ b/src/Main/renderer.cxx
@@ -65,6 +65,7 @@
#include osgViewer/Renderer
#include simgear/math/SGMath.hxx
+#include simgear/screen/extensions.hxx
#include simgear/scene/material/matlib.hxx
#include simgear/scene/material/EffectCullVisitor.hxx
#include simgear/scene/material/Effect.hxx
@@ -735,7 +736,7 @@ void buildDeferredBuffers( flightgear::CameraInfo* info, int shadowMapSize, bool
if (normal16)
info-addBuffer(flightgear::RenderBufferInfo::NORMAL_BUFFER, buildDeferredBuffer( 0x822C /*GL_RG16*/, 0x8227 /*GL_RG*/, GL_UNSIGNED_SHORT, osg::Texture::CLAMP_TO_BORDER) );
else
-info-addBuffer(flightgear::RenderBufferInfo::NORMAL_BUFFER, buildDeferredBuffer( GL_RGBA8, GL_RGBA, GL_UNSIGNED_SHORT, osg::Texture::CLAMP_TO_BORDER) );
+info-addBuffer(flightgear::RenderBufferInfo::NORMAL_BUFFER, buildDeferredBuffer( GL_RGB16, GL_RGB, GL_UNSIGNED_SHORT, osg::Texture::CLAMP_TO_BORDER) );
info-addBuffer(flightgear::RenderBufferInfo::DIFFUSE_BUFFER, buildDeferredBuffer( GL_RGBA8, GL_RGBA, GL_UNSIGNED_BYTE, osg::Texture::CLAMP_TO_BORDER) );
info-addBuffer(flightgear::RenderBufferInfo::SPEC_EMIS_BUFFER, buildDeferredBuffer( GL_RGBA8, GL_RGBA, GL_UNSIGNED_BYTE, osg::Texture::CLAMP_TO_BORDER) );
@@ -1356,7 +1357,10 @@ FGRenderer::buildDeferredPipeline(flightgear::CameraGroup* cgroup, unsigned flag
osg::GraphicsContext* gc)
{
CameraInfo* info = new CameraInfo(flags);
- buildDeferredBuffers( info, _shadowMapSize, !fgGetBool(/sim/rendering/no-16bit-buffer, false ) );
+
+bool gl_ext_texture_rg = SGIsOpenGLExtensionSupported(GL_ARB_texture_rg)
+ !fgGetBool(/sim/rendering/no-16bit-buffer, false );
+ buildDeferredBuffers( info, _shadowMapSize, gl_ext_texture_rg );
osg::Camera* geometryCamera = buildDeferredGeometryCamera( info, gc );
cgroup-getViewer()-addSlave(geometryCamera, false);
--
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
Re: [Flightgear-devel] Now Rembrandt here...
On Thu, 2012-04-12 at 11:02 +0200, Frederic Bouvier wrote: De: Erik Hofman e...@ehofman.com even GL_RGB16 works. For all the buffers or only the normal buffer ? I only tested the normal buffer. You're not supposed to have multiple render target of different element size. RGBA8 = 32bits, as well as RG16. What is your card brand and model ? It's a NVidia GeForce 9600GT I came across a blog post that compares multiple ways to compress the normals in an 8bit texture and I will try that shortly. That might be a good idea, at least to save texture memory. Erik -- 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
Re: [Flightgear-devel] Now Rembrandt here...
De: Erik Hofman e...@ehofman.com On Thu, 2012-04-12 at 11:02 +0200, Frederic Bouvier wrote: What is your card brand and model ? It's a NVidia GeForce 9600GT I think Emilian has the same card and I don't think he had these problems. Maybe it's a good idea to collect user experience with Rembrandt on a Wiki page ? Regards, -Fred -- 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
Re: [Flightgear-devel] Now Rembrandt here...
The driver is somewhat older - as with anything which works fine on my computer, I'm reluctant to fiddle with it because on past occasions I have found myself struggling for a few days just to restore the previous state of the system when an update went wrong, and I simply don't have the time. I don't think it will change anything as NVidia is not making driver updates for this model of GPU for a long time. Regards, -Fred -- 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
Re: [Flightgear-devel] Now Rembrandt here...
On Thu, 2012-04-12 at 11:24 +0200, Frederic Bouvier wrote: De: Erik Hofman e...@ehofman.com On Thu, 2012-04-12 at 11:02 +0200, Frederic Bouvier wrote: What is your card brand and model ? It's a NVidia GeForce 9600GT I think Emilian has the same card and I don't think he had these problems. Maybe it's a good idea to collect user experience with Rembrandt on a Wiki page ? I'm using Linux, maybe that's the difference? BTW today there was a driver update but that didn't change anything regarding this 'problem'. Erik -- 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
Re: [Flightgear-devel] Now Rembrandt here...
De: Erik Hofman On Thu, 2012-04-12 at 11:24 +0200, Frederic Bouvier wrote: De: Erik Hofman e...@ehofman.com On Thu, 2012-04-12 at 11:02 +0200, Frederic Bouvier wrote: What is your card brand and model ? It's a NVidia GeForce 9600GT I think Emilian has the same card and I don't think he had these problems. Maybe it's a good idea to collect user experience with Rembrandt on a Wiki page ? I'm using Linux, maybe that's the difference? BTW today there was a driver update but that didn't change anything regarding this 'problem'. Updates are now for newer cards -Fred -- 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
Re: [Flightgear-devel] Now Rembrandt here...
On Thu, 2012-04-12 at 11:35 +0200, Frederic Bouvier wrote: De: Erik Hofman On Thu, 2012-04-12 at 11:24 +0200, Frederic Bouvier wrote: De: Erik Hofman e...@ehofman.com On Thu, 2012-04-12 at 11:02 +0200, Frederic Bouvier wrote: What is your card brand and model ? It's a NVidia GeForce 9600GT Updates are now for newer cards Hm, according to this site the 195.36.24 driver does support GL_ARB_texture_rg for Linux: http://feedback.wildfiregames.com/report/opengl/device/GeForce%209600% 20GT But I still have version 173.14.22 Erik -- 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
Re: [Flightgear-devel] Now Rembrandt here...
On Thu, 2012-04-12 at 11:31 +0200, Erik Hofman wrote: On Thu, 2012-04-12 at 11:24 +0200, Frederic Bouvier wrote: De: Erik Hofman e...@ehofman.com On Thu, 2012-04-12 at 11:02 +0200, Frederic Bouvier wrote: What is your card brand and model ? It's a NVidia GeForce 9600GT I think Emilian has the same card and I don't think he had these problems. Maybe it's a good idea to collect user experience with Rembrandt on a Wiki page ? I'm using Linux, maybe that's the difference? Ah the 32-bit drivers don't support this extension while the 64-bit drivers do. Erik -- 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
Re: [Flightgear-devel] FGbuild for MS Windows
Hi John, zconf.h is taken care off, Ok, that is good, but could you please shared what you did. I think you mentioned finding something about editing zconf.h... Found what, where... what edits did you do? This is to just HELP the NEXT person that stumbles over this... And may even get one of the 'maintainer' to put a more permanent 'fix' online so there is no next time ;=)) pui vs. pu In MY 3rdparty\lib directory they are - pu.lib and pu_d.lib, and puaux.lib and puaux_d.lib for Release and Debug respectively... In unix/linux they are libplibpu.a and libplibpuaux.a... But I guess pui.lib is also possible... puaux vs.puAux, is that significant? I hope you know normally the windows system does NOT care about CaSe ;=)) so these are the same... there is no pu.lib or puaux.lib. Rubbish! But as you sort of point out, that could be pui.lib and puiaux.lib in your environment... If msvc can not find a library then it will say that! It didn't, so it found somethings, but it just missing a function link - puaList()... And when it misses one library function like this it will usually report a LONG list of 'missing'... As to finding it/them have you tried in - 3rdparty\lib dir pu*.lib /s If not, even dir c:\pu*.lib /s ;=)) will take a little longer, but will get you there... unless it is on another logical drive... wasn't able to track down the log file, where would you find it... Again, in the 'build' directory you have chosen in CMake do - dir *.log /s should get you there... In my case, my build directory is - C:\FG\10\flightgear\build and it is found in - ...build\src\Main\fgfs.dir\Debug and ...build\src\Main\fgfs.dir\Release You need to find it so you can CHECK exactly what plib libraries msvc link.exe is using when building fgfs.exe... Also, as a suggestion, I would not bother yet about building the Debug configuration, and concentrate on building the Release configuration... Now when you get the pu*.lib story straight, you can manually modify CMakeCache.txt before loading the CMAke GUI, or fix them directly in the GUI... [configure] then [generate], then back into msvc... HTH. Regards, Geoff. -- 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
Re: [Flightgear-devel] Now Rembrandt here...
I came across a blog post that compares multiple ways to compress the normals in an 8bit texture and I will try that shortly. That might be a good idea, at least to save texture memory. This blog entry is now cited as reference in the Rembrandt wiki page. -Fred -- 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
Re: [Flightgear-devel] Now Rembrandt here...
On Thursday 12 April 2012 11:24:23 Frederic Bouvier wrote: De: Erik Hofman e...@ehofman.com On Thu, 2012-04-12 at 11:02 +0200, Frederic Bouvier wrote: What is your card brand and model ? It's a NVidia GeForce 9600GT I think Emilian has the same card and I don't think he had these problems. Maybe it's a good idea to collect user experience with Rembrandt on a Wiki page ? Regards, -Fred -- 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 I've got an 8600GT non mobile, and it works just fine(minus the perf hit with shadows on, due to the huge vertex number in the suncamera scene). I'm using the latest driver 253.40 as of yesterday. Might be a good idea to update the drivers. On Linux they support any cards from the 6xxx series up with this branch of drivers, while fx and older are supposed to use the older driver series. HTH, Emilian -- 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
Re: [Flightgear-devel] FGbuild for MS Windows
Hi Geoff, Hi Geoff, A quick reply on the zconf.h fix At line 287 change #ifdef 1 to #ifdef 0; info from tutorial on building FG with MSVC 10 Express describes the change. Bunch of todo's need my attention today, probably won't get back to this until late this evening or tomorrow to digest your entire email. From: Geoff McLane ubu...@geoffair.info To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Thursday, April 12, 2012 4:09:59 AM Subject: Re: [Flightgear-devel] FGbuild for MS Windows Hi John, zconf.h is taken care off, Ok, that is good, but could you please shared what you did. I think you mentioned finding something about editing zconf.h... Found what, where... what edits did you do? This is to just HELP the NEXT person that stumbles over this... And may even get one of the 'maintainer' to put a more permanent 'fix' online so there is no next time ;=)) Thanks for the detailed discussion John-- 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
Re: [Flightgear-devel] airport list
I did note the results were slow. It can take up to 5 - 10 seconds to generate the list. I am looking for a list of ICAOs that branch out from one's current airport withina radius. The below method returns what I want, albeit a bit slow. A listing of ICAOs would be OK, but generating a job with a destination 5000 miles away wouldn't make much sense for most user's amount of time they have to spend in a flying session without being able to save their progress. So I am thinking more of regional jobs that could be completed in 30 minutes to a few hours dependent on the aircraft. Thus the concept of using a list of all ICAOs within x radius of the airport one is grounded at to use with the generation of the random job. Of course it could all be configurable by the user too. I entertained using the apt.dat file or a custom xml file but wanted to try some of the built-in functions first. gapalp gap...@gapalp.net Original Message Subject: Re: [Flightgear-devel] airport listFrom: James Turner zakal...@mac.comDate: Thu, April 12, 2012 3:59 amTo: FlightGear developers discussionsflightgear-devel@lists.sourceforge.netOn 11 Apr 2012, at 20:48, gap...@gapalp.net wrote: 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:Uh, the findClosest (and related FGPositioned functions) use the spatial index, which is probably not what you want - since they're a bit slower.What exactly *do* you want? The current query functions support querying by position or by ident (possibly a partial ident).If you're looking for a flat list of all the airport IDs, that may not actually be exposed right now in C++, but would be trivial to add.James--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 listFlightgear-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/flightgear-devel -- 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
Re: [Flightgear-devel] airport list
On 12 Apr 2012, at 14:54, gap...@gapalp.net wrote: I did note the results were slow. It can take up to 5 - 10 seconds to generate the list. I am looking for a list of ICAOs that branch out from one's current airport within a radius. The below method returns what I want, albeit a bit slow. A listing of ICAOs would be OK, but generating a job with a destination 5000 miles away wouldn't make much sense for most user's amount of time they have to spend in a flying session without being able to save their progress. So I am thinking more of regional jobs that could be completed in 30 minutes to a few hours dependent on the aircraft. Thus the concept of using a list of all ICAOs within x radius of the airport one is grounded at to use with the generation of the random job. Of course it could all be configurable by the user too. I entertained using the apt.dat file or a custom xml file but wanted to try some of the built-in functions first. Aha. So what you actually want it all *sensible* airports within a certain NM cut-off. Where sensible means, likely to generate cargo - no grass/gravel strips, or, well, maybe, depending on the kind of cargo you're modelling - northern Canadian or remote Australian supply runs? You can generate what you need in a single call, possibly creating a new AirportFilter subclass to implement the size criteria. The call you need is: FGPositioned::findWithinRange Passing in your desired cutoff in *nautical miles*, and a suitable filter object. For a filter object, subclass FGAirport::AirportFilter or FGAirport::HardSurfaceFilter, and extend it to reject / pass airports you deem unsuitable for your cargo traffic. For examples of subclassing these, look at MapAirportFilter, MetarAirportFilter or AirportInfoFilter. Note that 'findWithinRange' is generally used in the simulator for ranges *less* than 1000nm, at which point the performance is 'fast enough' - if you start to increase the range to 2000nm, I don't know how it will perform - let me know! Any other questions, just ask. James -- 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
[Flightgear-devel] another segfault
Hi folks, I've been updating the CitationX , and suddenly Im getting this error and the program segfaults. calc_bearing is not a finite number : Speed nanpos : nan, nanwaypoint 43.8071, 11.2006 waypoint name rotateSegmentation fault I've been trying for days to figure out what I changed to cause this but not even close yet. I can start any other aircraft with no errors , only the CitationX. I've been adding the NavDisplay , but I've also added this to the Bravo with no errors . Has anyone else seen this ? The error message comes from /AIModel/AIAircraft.cxx , but that hasn't helped me solve the problem . Syd -- 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
Re: [Flightgear-devel] airport list
Great! I will work with FGPositioned::findWithinRange to see what I can come up with that's hopefully more efficient. gapalp gap...@gapalp.net Original Message Subject: Re: [Flightgear-devel] airport listFrom: James Turner zakal...@mac.comDate: Thu, April 12, 2012 10:08 amTo: FlightGear developers discussionsflightgear-devel@lists.sourceforge.netOn 12 Apr 2012, at 14:54, gap...@gapalp.net wrote: I did note the results were slow. It can take up to 5 - 10 seconds to generate the list. I am looking for a list of ICAOs that branch out from one's current airport within a radius. The below method returns what I want, albeit a bit slow. A listing of ICAOs would be OK, but generating a job with a destination 5000 miles away wouldn't make much sense for most user's amount of time they have to spend in a flying session without being able to save their progress. So I am thinking more of regional jobs that could be completed in 30 minutes to a few hours dependent on the aircraft. Thus the concept of using a list of all ICAOs within x radius of the airport one is grounded at to use with the generation of the random job. Of course it could all be configurable by the user too. I entertained using the apt.dat file or a custom xml file but wanted to try some of the built-in functions first.Aha. So what you actually want it all *sensible* airports within a certain NM cut-off. Where sensible means, likely to generate cargo - no grass/gravel strips, or, well, maybe, depending on the kind of cargo you're modelling - northern Canadian or remote Australian supply runs?You can generate what you need in a single call, possibly creating a new AirportFilter subclass to implement the size criteria. The call you need is:FGPositioned::findWithinRangePassing in your desired cutoff in *nautical miles*, and a suitable filter object. For a filter object, subclass FGAirport::AirportFilter or FGAirport::HardSurfaceFilter, and extend it to reject / pass airports you deem unsuitable for your cargo traffic. For examples of subclassing these, look at MapAirportFilter, MetarAirportFilter or AirportInfoFilter.Note that 'findWithinRange' is generally used in the simulator for ranges *less* than 1000nm, at which point the performance is 'fast enough' - if you start to increase the range to 2000nm, I don't know how it will perform - let me know!Any other questions, just ask.James--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 listFlightgear-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/flightgear-devel -- 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
[Flightgear-devel] Now Rembrandt here...
The amount of shadow I see depends on the angle of the view axis with the sunlight direction - under some angles I see dark shadows, under some angles I see no shadows at all Hi Thorsten, I have the same bug when the skydome scattering shader is enable. Are you sure you have disable skydome scattering shader ? Cheers, Clément -- 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
Re: [Flightgear-devel] another segfault
Am 12.04.2012 16:50, schrieb syd adams: I've been updating the CitationX , and suddenly Im getting this error and the program segfaults. calc_bearing is not a finite number : Speed nanpos : nan, nanwaypoint 43.8071, 11.2006 waypoint name rotateSegmentation fault The segfault should be gone with latest Git. Just the result of the AIAircraft calling a hard exit - which isn't a good idea for a number of reasons. Now, you'll probably only get a bunch of error messages in the console (or another segfault somewhere else :) ). But the question for the root cause triggering the error message remains. Seems like some AI aircraft is missing a way point. Disabling AI traffic might avoid the issue. But if it really depends on some aircraft modification (like introducing the NavDisplay), then it could be the result of an ugly memory issue. If you can reproduce this, it's probably best if you provided your modified aircraft files (here or in the bug tracker) and someone starts digging with a debugger... cheers, Thorsten -- 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
Re: [Flightgear-devel] FGbuild for MS Windows
Hi, Really ? Do you manage to build 64bit executables with VS Express ? Yes. Does it come with a 64bit compiler ? No. But the Windows SDK 7.1 for 64Bit comes with the VS 2010 64 Bit compiler and integrates with the VS Express environment. I just downloaded your 64Bit 3rdParty for VS2010 and compiled osg, simgear and flightgear with it. Works. Best regards, Olaf -- 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
Re: [Flightgear-devel] Now Rembrandt here...
Thorsten, I'll add that you get that either if an effect not converted to Rembrandt is used, or if the default shader has a build error and OSG fallback to fixed functions. So if the lightfield or the skydome is not enabled, check the console for a shader build error. Another possibility is that an extension check fails for you : extension-supportedGL_ARB_texture_rg/extension-supported Try to locate that line in Effects/model-default.eff and Effects/terrain-default.eff and remove it or comment it out Regards, -Fred -- 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
Re: [Flightgear-devel] Now Rembrandt here...
1) The shadows around the aircraft have a ragged egde. That I understand is a function of the shadow map size. I can't go beyond 4096, I get an error on the console trying to go higher - but 4096 works fine with acceptable framerates, the edge is just a limit of my GPU and that is okay. 2) I see shadows flickering (I tried the Cub cockpit for comparison) when I'm in level flight where they shouldn't move - the effect is a bit like a shadow cast by a candle flickering in the wind. In Heiko's video that is sometimes visible (he doesn't fly straight much, and when the shadows actually move the effect is masked). I've never seen it in Fred's videos - is it not there, or just not in the video? Personally, I find that flickering maddening - I've ended my test flight after 5 minutes because I was starting to get a headache. Here is a video with a steady view to see shadow stability. http://youtu.be/JtEXIn2yL94 I also added 3 different sequences with different levels of filtering. Filtering is not yet configurable but is selectable in the sunlight shader with simple code modification. Regards, -Fred -- 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
Re: [Flightgear-devel] airport list
Wow, this works better, is simpler code, and is much faster! Plus it will be easy to allow the user to pass configurations such as range and airport type as mentioned, to suit GA planes or heavies. AirportInfoFilter filter; double maxRange = 300.0; FGPositioned::List results = FGPositioned::findWithinRange(globals-get_aircraft_position(), range, filter); FGPositioned::sortByRange(results, globals-get_aircraft_position()); string dest[results.size()]; for (unsigned int i=0; i results.size(); i++) { dest[i] = results[i]-ident(); }gapalpgap...@gapalp.net
Original Message
Subject: Re: [Flightgear-devel] airport list
From: gap...@gapalp.net
Date: Thu, April 12, 2012 1:09 pm
To: "FlightGear developers discussions"
flightgear-devel@lists.sourceforge.net
Great! I will work with FGPositioned::findWithinRange to see what I can come up with that's hopefully more efficient. gapalp gap...@gapalp.net Original Message Subject: Re: [Flightgear-devel] airport listFrom: James Turner zakal...@mac.comDate: Thu, April 12, 2012 10:08 amTo: FlightGear developers discussionsflightgear-devel@lists.sourceforge.netOn 12 Apr 2012, at 14:54, gap...@gapalp.net wrote: I did note the results were slow. It can take up to 5 - 10 seconds to generate the list. I am looking for a list of ICAOs that branch out from one's current airport within a radius. The below method returns what I want, albeit a bit slow. A listing of ICAOs would be OK, but generating a job with a destination 5000 miles away wouldn't make much sense for most user's amount of time they have to spend in a flying session without being able to save their progress. So I am thinking more of regional jobs that could be completed in 30 minutes to a few hours dependent on the aircraft. Thus the concept of using a list of all ICAOs within x radius of the airport one is grounded at to use with the generation of the random job. Of course it could all be configurable by the user too. I entertained using the apt.dat file or a custom xml file but wanted to try some of the built-in functions first.Aha. So what you actually want it all *sensible* airports within a certain NM cut-off. Where sensible means, likely to generate cargo - no grass/gravel strips, or, well, maybe, depending on the kind of cargo you're modelling - northern Canadian or remote Australian supply runs?You can generate what you need in a single call, possibly creating a new AirportFilter subclass to implement the size criteria. The call you need is:FGPositioned::findWithinRangePassing in your desired cutoff in *nautical miles*, and a suitable filter object. For a filter object, subclass FGAirport::AirportFilter or FGAirport::HardSurfaceFilter, and extend it to reject / pass airports you deem unsuitable for your cargo traffic. For examples of subclassing these, look at MapAirportFilter, MetarAirportFilter or AirportInfoFilter.Note that 'findWithinRange' is generally used in the simulator for ranges *less* than 1000nm, at which point the performance is 'fast enough' - if you start to increase the range to 2000nm, I don't know how it will perform - let me know!Any other questions, just ask.James--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 listFlightgear-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/flightgear-devel --
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
--
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
