Re: [Flightgear-devel] Cloud altitudes in shader?
If you want to know the altitude, you need to have the matrix that transforms from the current view position/orientation to the earths center. And you need to transform from cartesian space into the earth ellipsoid. The best you can do is to do this per vertex. And even that is way too much computation for that single altitude that you can just set when you set up the geometry. The most efficient method is probably to set up a 4 vector plane equation that represents the sea level altitude horizontal plane in object coordinates. This plane needs to be updated when the cloud object moves significantly by the cpu code. In the shader you can then compute the distance to the plane in the usual way. That would give an altitude per vertex which would be even exact per fragment by correct interpolation. If you only need the altitude per cloud, put that scalar value in a uniform. That somehow seems way too complicated. We're currently rendering clouds to 45 km, my private hack does 75 km, in my wildest dreams I am speculating about 250 km, cloud altitude is always below 30 km - all these numbers are way smaller than the Earth radius, so a local Cartesian system and the first term of the Taylor expansion in curvature will always be enough to any sane accuracy. I have now a scheme that does seem to do the trick - high stuff and stuff towards the sun glows properly before lower stuff and stuff away from the sun. http://www.flightgear.org/forums/viewtopic.php?f=47t=14755start=15#p147240 The idea is: * compute the relative vector between eye position and vertex * get its z-component as altitude difference * pass the eye position altitude as uniform * add eye altitude to relative altitude - this is the uncorrected vertex altitude * use the known distance to correct for curvature to get the actual altitude (it's probably off by a few percent, but who cares?) I have the feeling there should be an even simpler way to do it, but after coordinate-system-crawling for 5 hours yesterday I'm simply not in the mood to try to find out. What derailed me for a while is that the shader doesn't do numerics to high accuracy - the small difference of two individually large numbers doesn't compute very well (I know it's a bad problem), and that screwed things up for a while, and so I thought the scheme itself was flawed, but I think I sorted that out as well. So, thanks for the input to everyone! * Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] G115; Was Aircraft issues: dg101g, Lightning
Which motor aircraft do you use for towing ? Given the above figures I suspect you're using the Piper Cub, right ? Did you ever try the Grob G115 ? I've never flown that one, neither in RL nor in FG, but I *guess* it's probably the closest in performance and FDM credibiliy to commonly used towing aircraft. I tried it today and as far as I can tell from a simple setup with mouse-control only I'd say the G115 behaves sufficiently reasonable. BUT I'm _very_ surprised: Don't these birds have neither a speed indicator nor engine gauges on the pilots side of the panel ? Hi Martin, the DG-101G comes with a drag robot - I don't do multiplayer, so I couldn't test aerotow over MP, I just tried to hang behind the robot which itself was flying quite reasonably - just my glider was bouncing around wildly. Without MP, I don't think I have a chance to test aerotow from the other side, or is that implemeted somewhere? Cheers, * Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud altitudes in shader?
On Wed, Jan 11, 2012 at 8:09 AM, Thorsten Renk wrote: I have now a scheme that does seem to do the trick - high stuff and stuff towards the sun glows properly before lower stuff and stuff away from the sun. http://www.flightgear.org/forums/viewtopic.php?f=47t=14755start=15#p147240 Very beautiful! The idea is: * compute the relative vector between eye position and vertex * get its z-component as altitude difference * pass the eye position altitude as uniform * add eye altitude to relative altitude - this is the uncorrected vertex altitude * use the known distance to correct for curvature to get the actual altitude (it's probably off by a few percent, but who cares?) Rather than passing in the eye position as a uniform, why not pass in the cloud altitude instead? Is this simply to avoid needing to modify the C++ code? -Stuart -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud altitudes in shader?
Rather than passing in the eye position as a uniform, why not pass in the cloud altitude instead? Is this simply to avoid needing to modify the C++ code? I thought uniforms are things which are per frame constant in the scene and apply to all objects the same way - i.e. I pass light attenuation (scattering) or terminator position as uniforms to the shader. I don't see that cloud altitude falls into that category - it is constant per cloud, but not per frame throughout the whole scene, I have clouds with very different altitudes floating around. It seems on would need to pass it the same way as, say, the top, middle and bottom shade parameters on a per cloud basis. Either there's something I do not understand here, but I decided to pass eye altitude largely because that is a constant per frame for the whole scene and I understand what I am doing with it. * Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud altitudes in shader?
On Wed, Jan 11, 2012 at 9:16 AM, Thorsten Renk wrote: Rather than passing in the eye position as a uniform, why not pass in the cloud altitude instead? Is this simply to avoid needing to modify the C++ code? I thought uniforms are things which are per frame constant in the scene and apply to all objects the same way - i.e. I pass light attenuation (scattering) or terminator position as uniforms to the shader. I don't see that cloud altitude falls into that category - it is constant per cloud, but not per frame throughout the whole scene, I have clouds with very different altitudes floating around. It seems on would need to pass it the same way as, say, the top, middle and bottom shade parameters on a per cloud basis. I think they are constant per object. However, it may be that the interaction between the 3D clouds C++ code and the effects files makes it difficult to set them per-cloud without modifying the C++ code. Once the 2.6.0 release is out the door and the new Impostor code is committed, I'll see if I can add it. -Stuart -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 69, Issue 7
On 11/01/2012 10:08, flightgear-devel-requ...@lists.sourceforge.net wrote: I tried it today and as far as I can tell from a simple setup with mouse-control only I'd say the G115 behaves sufficiently reasonable. BUT I'm_very_ surprised: Don't these birds have neither a speed indicator nor engine gauges on the pilots side of the panel ? Finally I've found out that the pilot-viewpoint and -model must be sitting on the wrong side in FlightGear's G-115, because the real G-115 Tutor is supposed to be flown solo from the right seat Hey Martin, The latest update on the G115 is 2009. It is therefore logical that the last of my new aircraft is not in it. For the position of the driver, check with Nav (John Stockill). He is the author of the panel and is an instructor on this aircraft type. So I think qui'il knew what he was doing. Regards Emmanuel -- BARANGER Emmanuel http://helijah.free.fr -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ccmake problems with flightgear git latest
Hi all, I had the same issue. It's quite odd. Git status was showing my tree as unmodified but I had to do the same thing (clone a new copy) with simgear otherwise it was not finding OSG in /usr/include. I think it was only looking in /usr/local/include for some reason. Cheers, Vik On 12/06/2011 12:51 AM, Sid Boyce wrote: A new clone of flightgear sorted that problem out. Regards Sid. On 05/12/11 23:38, Sid Boyce wrote: [ FindOpenSceneGraph.cmake:130 ] Failed to parse version number, please report this as a bug CMake Error at /usr/share/cmake/Modules/FindOpenSceneGraph.cmake:199 (message): ERROR: Version 3.0.0 or higher of the OSG is required. Version .. was found. Call Stack (most recent call first): CMakeLists.txt:194 (find_package) # rpm -q OpenSceneGraph OpenSceneGraph-3.0.1-55.x86_64 I had the same problems with simgear until I did the latest git pull. openSUSE cmake-2.8.6-3.4.x86_64 Help appreciated. Regards Sid. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ccmake problems with flightgear git latest
On Wednesday 11 January 2012 13:27:04 Viktor Radnai wrote: I had the same issue. It's quite odd. Git status was showing my tree as unmodified but I had to do the same thing (clone a new copy) with simgear otherwise it was not finding OSG in /usr/include. I think it was only looking in /usr/local/include for some reason. If git status showed nothing, there could still be generated files covered by .gitignore which had to be cleared like some cmake cache. You can see them with git status --ignored To bring back your working directory to the pristine state in the repository, you can use git clean which removes all files that git doesn't know about. git clean -x would clean even those which mach rules in .gitignore On 12/06/2011 12:51 AM, Sid Boyce wrote: A new clone of flightgear sorted that problem out. Regards Sid. On 05/12/11 23:38, Sid Boyce wrote: [ FindOpenSceneGraph.cmake:130 ] Failed to parse version number, please report this as a bug CMake Error at /usr/share/cmake/Modules/FindOpenSceneGraph.cmake:199 (message): ERROR: Version 3.0.0 or higher of the OSG is required. Version .. was found. Call Stack (most recent call first): CMakeLists.txt:194 (find_package) # rpm -q OpenSceneGraph OpenSceneGraph-3.0.1-55.x86_64 I had the same problems with simgear until I did the latest git pull. openSUSE cmake-2.8.6-3.4.x86_64 -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ccmake problems with flightgear git latest
Thanks for that. One of these days I'll actually learn git I promise :) Unfortunately I already nuked the old tree so I can't figure out what was left over that was causing the error. Cheers, Vik On 01/11/2012 01:50 PM, Stefan Seifert wrote: On Wednesday 11 January 2012 13:27:04 Viktor Radnai wrote: If git status showed nothing, there could still be generated files covered by .gitignore which had to be cleared like some cmake cache. You can see them with git status --ignored To bring back your working directory to the pristine state in the repository, you can use git clean which removes all files that git doesn't know about. git clean -x would clean even those which mach rules in .gitignore -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release 2.6.0 git/fgdata aircraft maintenance
Just created a merge request #130 for fgdata. Eric On 01/10/2012 06:23 PM, Stuart Buchanan wrote: On Tue, Jan 10, 2012 at 5:14 PM, Eric van den Berg wrote: Is indeed JSBSIM and that did the trick. Engine running! Great. Will you be committing a fix to fgdata, or do you need someone else to do that? -Stuart -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS texures (Was: Improving random trees
Hi, On Sunday, January 01, 2012 11:41:22 Mathias Fröhlich wrote: I think then, computing mipmaps for any texture file on the CPU in the loader thread should globally improove the situation. Also avoiding the compression already in the files should help every use case. Except that the on disk memory consumption is higher. Well and except that the database loader has more work to do on the CPU. Ok, checked in is a log message that checks for image formats that depend on OpenGL extensions not required to be present. That should at least help people running drivers providing those extensions to see when they use texture files that do not work fo all. Greetings Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reminder for the release process for version 2.6.0
Hi everybody, in less than one week we will pass the outer marker for our release of FlightGear 2.6.0: the creation of the release branches in our git repositories. A good time to read the final checklist: * All features work as desired? * All major bugs fixed? (http://code.google.com/p/flightgear-bugs/issues/list?q=-Type%3DFeatureRequest) * All aircraft in FGDATA checked in? * No console debug messages? The EOBT (estimated-off-branch-time?) for our branches is 0800UTC on January, 17th. I'll announce the precise time the evening before that day. Please note that during that short period of 1-2 hours, everybody with commit rights is requested to _NOT_ push anything to our repositories. Go flying, hug your kids, have a beer at the pub - whatever you like. Just stay away from gitorious.org/fg. Please fasten your seat belts, fold away the table in front of you and turn off all your electronic devices. Thanks for flying FlightGear! Torsten on behalf of the entire release crew. Am 17.11.2011 23:57, schrieb Torsten Dreyer: Hi everybody, after some very active weeks of development in the core and data, we are slowly but steadily heading into the next release. This will be version 2.6.0 to be released in February 2012. Please note that - the next feature-freeze state will be entered on December, 17th - one month from now. - the release branch is to be created on January, 17th - two month from now. - the release should be ready by February, 17th - three month from now. (More details here: http://wiki.flightgear.org/index.php/Release_Plan) Those of you who are working on new features or major changes, please make sure you code is in the repositories by Dec., 17th. Thanks for your cooperation and all the excellent and hard work! Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ads Models with current OSG
Hi, does anybody have the same problem? Several Messages: Unknown Chunk: ***UNKNOWN*** (0xA08A) in fgfs output. Seems to be a diagnostic from the 3DS loader within OSG. I get this (and messy views) with current OSG, fgfs, fgdata choosing for instance aircraft MD11 or airport EHAM . Greetings Olaf -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ads Models with current OSG
On 11.01.2012 23:15, Olaf Flebbe wrote: Hi, does anybody have the same problem? Several Messages: Unknown Chunk: ***UNKNOWN*** (0xA08A) in fgfs output. Seems to be a diagnostic from the 3DS loader within OSG. I get this (and messy views) with current OSG, fgfs, fgdata choosing for instance aircraft MD11 or airport EHAM . Yes, see here: http://code.google.com/p/flightgear-bugs/issues/detail?id=543 It's an AI aircraft causing it (MD11), so it's visible frequently. Maybe someone could fix the model - or check why OSG doesn't like the model. cheers, Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
