[Flightgear-devel] Texture cache (was: Adventures in dds)
Hi. Inspired by the talk in the dds thread about cloud performance and other things, I did some quick grepping through the source about textures. I found out FG/SG has at least 5 different way of storing textures: 1. FGTextureManager in FG's Cockpit/panel.*, which at least tries to keep track of texture files which are loaded and should not load them again. This is used in some instruments and 2d panel? 2. Effects (SG: scene/material/TextureBuilder.*) have their own texture cache which reloads textures only if their parameters in effect file changes. Seems to reload the texture if e.g. clamping changes? 3. Material library (scene/material/mat.*) which handles the materials.xml. This one seems to use TextureBuilder so it might load the iamges only once, if all parameters are the same. 4. Individual pointer in subsystems. At least sky elements, splash screen, maybe trees and clouds etc use these. Texture pointers are stored inside the class and they are not exposed for other systems to use. 5, maybe worst: osg plugins which load 3d models seem to load textures directly and store them... somewhere. So no caching, if two models use the same texture it gets always loaded, no matter what. I think the problem with local weather could be that the models are always re-loaded and that's why the osg plugin re-loads the textures too... I checked some models in Models/Weather and they do point to the textures. I think this is quite a big mess currently. I think there should be only one place to store the images (maybe just the images, even if other texturing parameters change?) which should be used everywhere and the textures should be exposed so that the same image can be used in effects or animations or wherever necessary. Any thoughts on this and how to solve it? - Lauri Peltonen, Zan -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Mipmaps (was: Adventures in dds)
Shouting again from the back row, but I want to point out that pregenerated mipmaps is not something dds specific, it can be done with any texture format. It's just about storing them. Like in http://www.ogre3d.org/tikiwiki/img/wiki_up/MipMap_Example_STS101.jpg . Of course dds has the pro side that it is loaded directly into memory, no uncompressing is required. With e.g. png and the storing method above, the image needs to be decompressed properly to allow using the mipmaps. But it is possible. If we figured out a format to store mipmaps and how to use them in FG, it would allow using many more better filters for them, which might increase graphics quality a lot, just like was seen in the dds screenshots. And at the same time could allow for better compression (but slower loading times maybe) to save HD space if that is necessary. Also one thing point mentioning is that DDS format might not be supported on older hardware. And I think FG is supposed to support also older hardware. For reference, the dds loader source: http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgPlugins/dds/ReaderWriterDDS.cpp?rev=3017 Zan -- Lauri Peltonen lauri.pelto...@gmail.com -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Simple atmospheric scattering shader for skydome
Hi, I made this patch some time ago, and seems like it is working quite fine, so I though if it might be possible to add to git (if nothing more, then maybe for future reference)? It does two things. First I modified the skydome code to be more configurable so that the precision could be increased (number of rings and bands). Then I implemented the O'Neil's scattering shader to showcase the scattering. I know that for the proper effect, terrain and other objects should use the same shader, but that is probably future work. Anyways, here are links to patches and effects. The flightgear patch only makes clearcolor black, so that space is dark instead of gray. http://users.tkk.fi/~lapelto2/fgfs/scatter/scatter-simgear.patch http://users.tkk.fi/~lapelto2/fgfs/scatter/scatter-flightgear.patch http://users.tkk.fi/~lapelto2/fgfs/scatter/skydome.eff http://users.tkk.fi/~lapelto2/fgfs/scatter/skydome.frag http://users.tkk.fi/~lapelto2/fgfs/scatter/skydome.vert Screenshots can be found from the forum thread: http://www.flightgear.org/forums/viewtopic.php?f=47&t=11274&p=117965#p117965 And the command line to run the shader, it needs some properties set: fgfs --prop:/sim/rendering/mie=0.003 --prop:/sim/rendering/rayleigh=0.0003 --prop:/sim/rendering/dome-density=0.5 --prop:/sim/rendering/scattering-shader=1 The non-shader version should look just like it used to, but on some occasions I think the sunset effect is a bit misplaced. I didn't touch that code, so was it always like that? Can someone verify? Cheers, Zan -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simple atmospheric scattering shader for skydome
Hi. Nice to see my shader brought up some discussion :) First, Vivian, I tried to see your screenshots, but the link wasn't working (server down or something?) so I cannot comment them right now. And I didn't mean the bug with sun reflection on the water being misplaced from the real shader, but sometimes it seems like the sunset effect on the (non shader) skydome is someting like 90 degrees to the left. I'm not sure if it always was like that or did I change something or am I just seeing things. It looks like the brightest spot of the horizon is not where the sun is, but to the left. If someone can confirm (with old version & my version if possible), would be much appreciated. Second, Erik, I tried not to change the old behaviour but I needed to move some code around to get better precision in the skydom model. I hope everything works like it did with the non shader version, I didn't quite understand all the equations but the code should not change those. Only behaviour that I did change is the clear color in FG from fog color to black. I don't see anything changing near the ground, but the effect near space is better :) Other topics, mie and rayleigh coefficients are exposed, but maybe I shuold expose the wavelength dependency too, because that is what affects the sky color the most. The idea is that some code in FG/SG would write the proper coefficients depending on weather conditions to make different looking skies. I also uploaded the python code I used for evaluating the shader and calculating the scale coefficients etc. It is here: http://users.tkk.fi/~lapelto2/fgfs/scatter/scatter.py I can also write a wiki article on the subject should it be necessary. In the future, I'd like to see this shader as a post processing effect applied over all rendered objects so we would get a consistent look and feel everywhere. And also, I didn't think about getting this to the next release, it's too late for that. But maybe to the one after that, so we have time to test things first. Wbr, Zan -- Lauri Peltonen -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268
Hi all! At last I had time to look at the black sky problem which resulted every time visibility was < 1000 meters (or feet?). Anyways, I found the problem. Indeed I changed the clear color to be black to make space look better. But what I didn't know was that the whole sky (dome and stars etc) is optimised away if visibility is less than that 1000 units. So the solution is either change the clear color to what it was, or make it ramp linearly to black or something with altitude. Or change simgear/scene/sky.cxx around line 117 (repaint method), there is a if ( effective_visibility > 1000.0 ) { ... } else { // turn off sky disable(); } so taking that condition away would solve the problem. What would be the best solution, what do you think? Zan -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New environment properties (Was: A collection of issues)
> Is there a way of putting things to the GPU such that they're only > computed once per frame? You can use opengl calls to calculate matrices etc, but then you don't know if they are really calculated on the GPU or on the CPU by the driver. There are things like Cuda to do maths on the GPU, but that's anotehr story, and most likely does not work in this context. > For instance, for every cloud vertex we compute > the eye position by multiplying zero with the inverse model view matrix - > although it doesn't change from vertex to vertex! That's a few thousand > matrix multiplications per frame which we actually don't really need to > do. The normal way to do things like this is to calculate the matrix on the CPU, e.g. in the clouds' update code do it with OSG. Then bind that matrix to an uniform in the shader, so it is used by every cloud/cloudlet, whatever the rendering unit is. If you know what you need to calculate, it is most likely quite straightforward to add the code and binding. Though I'm not sure if "inverse model view matrix" etc. are available like that on the C++/OSG/CPU side, might need some other ways to do the calculation. If they are, the same calculation can be transfered very easily. Zan -- Lauri Peltonen lauri.pelto...@gmail.com -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of 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-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Hi. > Here is a random thought: what if the polygon data was painted onto a raster > texture (of some "sufficient" resolution) in correct bottom up order, rather > than being clipped. Then at the end of the process we figure out how to > extract the resulting polygons from the raster image. This would completely > eliminate the polygon clipping (although not for the airport generation I > guess) but would require solving another difficult problem. I've been thinking that we should use integers (or "fixed point") for vertices when processing scenery. With sufficiently long integers (say, 32 or even 64 bits on newer machines?) the precision could be in millimeter level, even on a world scale. At least if I calculated correctly ;) The pro side would be that all calculations on integers are well defined, and degenerate cases would be easier to detect, without using any epsilons. I don't know whether the clippers support that, but at least some do work on integers only. Any comments on this? Lauri, a.k.a Zan -- Lauri Peltonen lauri.pelto...@gmail.com -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [Rembrandt] the plan
Hi all. > 3. define an XML format for describing the two possible rendering pipelines > (the current and new). The format will introduce optional elements (such as > shadows, ambient occlusion, glow). I want to point out my work on my "newcameras" branch: https://gitorious.org/~zan/fg/zans-flightgear/commits/newcameras which allows user to define the rendering pipeline in preferences.xml. It does not (yet?) have everything Rembrandt's pipeline needs, but most likely is easily enhanced to support those things. Basically this version adds support for multiple camera passes, texture targets, texture formats, passing textures from one pass to another etc, while preserving the standard rendering line if user wants that. I wish this work could be extended (or maybe even I can extend it ;) to handle the Rembrandt camera system. This will not solve all problems in the merge, but some of them. Cheers, Lauri, "Zan" P.s. anyone know how to reply in the thread, when having the daily digest of this list? -- Lauri Peltonen lauri.pelto...@gmail.com -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] for tangent vectors running even if they should not
Hi all. I just noticed an old "bug" still existing in (my!) old code. I currently have no possibility to git pull the latest code and do a merge request, so maybe someone could do this little change to the code: In simgear/scene/material/EffectGeode.cxx, around line 73. All tangent generators currently run for every model using tag, even if the value is not stored. So maybe modifying the code to look like this would fix it: if(geometry && _effect.valid()) { if(_effect->getGenerator(Effect::TANGENT)>=0 || _effect->getGenerator(Effect::BINORMAL>=0 || _effect->getGenerator(Effect::NORMAL)>=0) { // Generate tangent vectors for the geometry ... ... } } } Currently there might be no significant change, as only generators available are for tangent vectors AFAIK, but this might come in handy later if more generators are added. Cheers, Lauri -- Lauri Peltonen lauri.pelto...@gmail.com -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Atmosphere temperature model
Hi! First of all I'd like to say hi to all as this is my first message to this list! Hi :) Then, when messing around with fg, I noticed that the current atmosphere model is somewhat correct only on troposphere (around 12km or so), and I think some aircrafts we have can go higher than that. So I did some improvements on that function. At low altitudes it behaves (almost) like the old one. It also has latitude dependency, and it should behave quite well up to 85km. Of course, that is a bit overkill. However, I have the patch attached, it was done againts the latest git version with "git diff". I hope it is correctly done. I also plotted some altitude-temperature curves at different latitudes (0, 37 and 80 degrees). They can be seen here http://users.tkk.fi/~lapelto2/fgfs_temperature.jpg . The source cites some references I used so the accuracy could be examined. Lauri -- Lauri Peltonen lauri.pelto...@gmail.com diff --git a/src/Environment/environment.cxx b/src/Environment/environment.cxx index dfb8824..7887fbb 100644 --- a/src/Environment/environment.cxx +++ b/src/Environment/environment.cxx @@ -38,7 +38,7 @@ #include "environment.hxx" - + // Atmosphere model. @@ -119,6 +119,7 @@ _setup_tables () void FGEnvironment::_init() { elevation_ft = 0; +latitude_deg = 0; visibility_m = 32000; temperature_sea_level_degc = 15; temperature_degc = 15; @@ -160,6 +161,7 @@ void FGEnvironment::copy (const FGEnvironment &env) { elevation_ft = env.elevation_ft; +latitude_deg = env.latitude_deg; visibility_m = env.visibility_m; temperature_sea_level_degc = env.temperature_sea_level_degc; temperature_degc = env.temperature_degc; @@ -358,6 +360,12 @@ FGEnvironment::get_elevation_ft () const return elevation_ft; } +double +FGEnvironment::get_latitude_deg () const +{ + return latitude_deg; +} + void FGEnvironment::set_visibility_m (double v) { @@ -477,6 +485,20 @@ FGEnvironment::set_elevation_ft (double e) } void +FGEnvironment::set_latitude_deg (double alt) +{ + latitude_deg = alt; + + // Latitude affects temperature, so recalc everything + // that depends on temp + _recalc_alt_temperature(); + _recalc_alt_dewpoint(); + _recalc_alt_pressure(); + _recalc_density(); + _recalc_relative_humidity(); +} + +void FGEnvironment::set_altitude_half_to_sun_m (double alt) { altitude_half_to_sun_m = alt; @@ -540,7 +562,8 @@ void FGEnvironment::_recalc_sl_temperature () { // If we're in the stratosphere, leave sea-level temp alone - if (elevation_ft < 38000) { + // (a little smaller to also work correctly at poles!) + if (elevation_ft < 28000) { temperature_sea_level_degc = (temperature_degc + 273.15) / _temperature_degc_table->interpolate(elevation_ft) - 273.15; @@ -550,11 +573,84 @@ FGEnvironment::_recalc_sl_temperature () void FGEnvironment::_recalc_alt_temperature () { - if (elevation_ft < 38000) { + // This should calculate troposphere temperature + // quite accurately. + // In real life tropopause is different elevation in south and north + // but the difference is quite small. + // Info from: http://www.ux1.eiu.edu/~cfjps/1400/atmos_struct.html + // and: http://eospso.gsfc.nasa.gov/eos_homepage/for_scientists/data_products/OurChangingPlanet/PDF/Page_05_new.pdf + + // take the absolute value of lat for simplicity + double lat = (latitude_deg < 0) ? -latitude_deg : latitude_deg; + + // Using simple interpolation instead of the real curve + double tropopause = 51562; // Default tropopause at -30 < lat < 30 + if(lat > 60) { +tropopause = 31250 - 104.1 * (lat - 60); + } else if(lat > 30) { +tropopause = 51562 - 677.1 * (lat - 30); + } + + // This is quite good estimation for elevations below ~35000 + // We need to calculate this for all elevations above this! + double e = elevation_ft; + if(e > tropopause) e = tropopause; + + if(e <= 35000) + { temperature_degc = (temperature_sea_level_degc + 273.15) * -_temperature_degc_table->interpolate(elevation_ft) - 273.15; - } else { -temperature_degc = -56.49; // Stratosphere is constant + _temperature_degc_table->interpolate(e) - 273.15; + } + else + { +// at equator tropopause is much higher than 35000 so new estimation :) +// Using lapse rate of 6,5 degC / km +// use the temp @ 35000 as a starting point +temperature_degc = (temperature_sea_level_degc + 273.15) * + _temperature_degc_table->interpolate(35000) - 273.15 - 0.00208 * (e - 35000); + } + + // At this point the temperature below tropopause is calculated :) + // Continue with upper levels + + if(elevation_ft > tropopause) + { +// tropopause is not really constant, so estimate different lapse rates +doub
Re: [Flightgear-devel] Atmosphere temperature model
> You could have saved yourself a lot of work by posting a question > before writing all this code. I don't mind that, because it was just fun to do that. And I wasn't going to do a temperature model in the first place, but somehow ended up doing that :) > The code to do all this has existed for years. A nice table-driven > implementation. It does this and more (notably linking the _pressure_ > versus height dependence to the temperature). Pressure is kinda > important for realistic altimetry, engine performance, et cetera. > Let me know if you are interested in this. If you mean the table at the top of environment.cxx, yeah I noticed it. And I use it like before up to 35000ft. I don't know what was the reason to not use it over that altitude for temperature, it seems to be quite nice up to 10ft. See http://users.tkk.fi/~lapelto2/fgfs_temp_graph.jpg . I also notice that it is used to model pressure at all altitudes. Or do you have some other table system than that? I was mostly doing this to add the latitude dependency to the temperature curves. I'm sure no one would notice that when flying, but it seemed like a nice thing to do. In any case, the current -56 degC at altitudes over 38000 is horrible, and we should either model using the table or something similar to my system, depending on the accuracy wanted. I don't know if any aircraft can/should fly in those high altitudes, and if their modeling takes temperature into account. Lauri -- Lauri Peltonen lauri.pelto...@gmail.com -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Allow use of external shaders in 3d clouds and trees
Hi. These two patches allow use of external shaders as the tree and 3d cloud shaders. The shaders are Shaders/3dcloud.{frag|vert} and Shaders/tree.{frag|vert}. If the shader files are not found, the original shaders included in the source are used. This makes testing modifications to the shaders easier and faster. End users should see no difference when using this. Also attached are the original shaders to be put into Shaders/. Lauri Peltonen (Zan) -- Lauri Peltonen --- simgear/scene/sky/newcloud.cxx.old 2009-09-26 22:42:37.0 +0300 +++ simgear/scene/sky/newcloud.cxx 2009-09-27 13:56:48.0 +0300 @@ -171,6 +171,8 @@ osg::Texture2D *tex = new osg::Texture2D; tex->setWrap( osg::Texture2D::WRAP_S, osg::Texture2D::CLAMP ); tex->setWrap( osg::Texture2D::WRAP_T, osg::Texture2D::CLAMP ); +tex->setFilter( osg::Texture::MIN_FILTER, osg::Texture::LINEAR_MIPMAP_LINEAR ); +tex->setFilter( osg::Texture::MAG_FILTER, osg::Texture::LINEAR_MIPMAP_LINEAR ); tex->setImage(osgDB::readImageFile(texture, options.get())); StateAttributeFactory* attribFactory = StateAttributeFactory::instance(); @@ -199,11 +201,19 @@ alphaFunc->setFunction(AlphaFunc::GREATER,0.05f); program = new Program; baseTextureSampler = new osg::Uniform("baseTexture", 0); -Shader* vertex_shader = new Shader(Shader::VERTEX, vertexShaderSource); + +Shader* vertex_shader = new Shader(Shader::VERTEX); +string source = osgDB::findDataFile("Shaders/3dcloud.vert"); +if(source == "") vertex_shader->setShaderSource(vertexShaderSource); +else vertex_shader->loadShaderSourceFromFile(source); program->addShader(vertex_shader); program->addBindAttribLocation("usrAttr1", CloudShaderGeometry::USR_ATTR_1); program->addBindAttribLocation("usrAttr2", CloudShaderGeometry::USR_ATTR_2); -Shader* fragment_shader = new Shader(Shader::FRAGMENT, fragmentShaderSource); + +Shader* fragment_shader = new Shader(Shader::FRAGMENT); +source = osgDB::findDataFile("Shaders/3dcloud.frag"); +if(source == "") fragment_shader->setShaderSource(fragmentShaderSource); +else fragment_shader->loadShaderSourceFromFile(source); program->addShader(fragment_shader); material = new Material; // Don´t track vertex color --- simgear/scene/tgdb/TreeBin.cxx.orig 2009-09-26 22:46:33.0 +0300 +++ simgear/scene/tgdb/TreeBin.cxx 2009-09-26 20:37:33.0 +0300 @@ -338,12 +338,21 @@ alphaFunc->setFunction(AlphaFunc::GEQUAL,0.33f); program = new Program; baseTextureSampler = new osg::Uniform("baseTexture", 0); -Shader* vertex_shader = new Shader(Shader::VERTEX, - vertexShaderSource); + +Shader* vertex_shader = new Shader(Shader::VERTEX); +string source = osgDB::findDataFile("Shaders/tree.vert"); +if(source == "") vertex_shader->setShaderSource(vertexShaderSource); +else vertex_shader->loadShaderSourceFromFile(source); + program->addShader(vertex_shader); -Shader* fragment_shader = new Shader(Shader::FRAGMENT, - fragmentShaderSource); + +Shader* fragment_shader = new Shader(Shader::FRAGMENT); +source = osgDB::findDataFile("Shaders/tree.frag"); +if(source == "") fragment_shader->setShaderSource(fragmentShaderSource); +else fragment_shader->loadShaderSourceFromFile(source); + program->addShader(fragment_shader); + material = new Material; // Don´t track vertex color material->setColorMode(Material::OFF); uniform sampler2D baseTexture; varying float fogFactor; void main(void) { vec4 base = texture2D( baseTexture, gl_TexCoord[0].st); vec4 finalColor = base * gl_Color; gl_FragColor.rgb = mix(gl_Fog.color.rgb, finalColor.rgb, fogFactor ); gl_FragColor.a = finalColor.a; } 3dcloud.vert Description: application/fluid uniform sampler2D baseTexture; varying float fogFactor; void main(void) { vec4 base = texture2D( baseTexture, gl_TexCoord[0].st); vec4 finalColor = base * gl_Color; gl_FragColor = mix(gl_Fog.color, finalColor, fogFactor ); } varying float fogFactor; void main(void) { float numVarieties = gl_Normal.z; float texFract = floor(fract(gl_MultiTexCoord0.x) * numVarieties) / numVarieties; texFract += floor(gl_MultiTexCoord0.x) / numVarieties; float sr = sin(gl_FogCoord); float cr = cos(gl_FogCoord); gl_TexCoord[0] = ve
Re: [Flightgear-devel] Allow use of external shaders in ...
Hi Stuart. > I'm currently working on improvements to the 3D clouds, including some > changes/bug-fixes to the shaders. > Are you planning some enhancements to the shaders yourself? If so, > we should coordinate to make sure we don't waste any effort. I've mostly played around with the shaders, not done anything really usefull yet. Except porting the water2 shader, which still needs new textures... For the clouds, I tried some improvement regarding the sunset effect, but it's just a small thing and not even very good yet. I'll wait to see what you have in mind before doing anything more with them. I'm also going to make some new cloud textures, but I guess that is never waste of effort, as there can't be too many textures :) I was thinking about making 2d clouds use shaders too. I've only barely looked at the code and it may take some time before I get it to work. I'll send the patch here when I have something done. Or if someone is/was already working on this, I'd like to hear about it. - Lauri -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] A "light cone" effect, dev version
Hi! I made an example of a "light cone" effect. It is a post processing effect, that makes an object illuminate everything inside of it. It would be usefull for landing lights or similar objects. This version uses blending, but the final version should use stencil buffer, once/if we get effects to support them. Because of the blending, the lighting value is 1.5 * the value of the underlying pixel. This means that during night, the light will not be very visible... I found no way to overcome this without the whole cone/model becoming visible. One way to cheat this is to add the object multiple times, since the lighting cumulates. Also fog does not work correctly. Attached is the effect file. I also had to make simple vertex and fragment shaders to get the effect working. Also, I attached an example of the cone model and its xml. Two screenshots from during the development is here: http://users.tkk.fi/~lapelto2/fgfs/fgfs-light.png and http://users.tkk.fi/~lapelto2/fgfs/fgfs-light2.png I hope someone finds this dev version usefull, maybe after the release we can get a "real" one :) Lauri ("Zan" on IRC) -- Lauri Peltonen lauri.pelto...@gmail.com light-cone.eff Description: Binary data light-cone.vert Description: Binary data light-cone.frag Description: Binary data light-cone.ac Description: Binary data light-cone.ac Effects/light-cone Cone -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Stencil operations for effects and new "light cone"
Hi! The attached patch adds support for stencil operations in effects. Patches are for simgear's scene/material/Effect.cxx and flightgear's Main/CameraGroup.cxx. I did them with "cvs diff " against latest CVS version. Hope that is correct way. The format of stencil operations in effect file is following: ... ... ... ... ... ... Where function can be never, always, less, less-or-equal, equal, not-equal, greater-or-equal or greater. Value is the reference value used in stencil operations and mask is the stencil bit mask. Stencil-fail, z-fail and pass are stencil operations if stencil test fails or stencil-test passes but z-test fails or both passes. Possible functions are zero, keep, replace, increase, decrease, invert, increase-wrap and decrease-wrap. I think one has to know something about stencil buffers to use this ;) I also added a new general tag 1 0 0 1 that allows only writing to certain channel (in this example only to red and alpha channel. As an example, I attached new version of the light-cone.eff I posted few days ago. This one does the same thing but with stencil operations. The .ac model used with this should be almost transparent or it will be too bright. This version has some issue if there is more than 5 light models simultaneously. I don't know if this is a OSG issue about rendering orders or something? But please test and comment. Lauri, a.k.a. Zan -- Lauri Peltonen lauri.pelto...@gmail.com Index: CameraGroup.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/Main/CameraGroup.cxx,v retrieving revision 1.18 diff -r1.18 CameraGroup.cxx 157c157 < camera->setClearMask(GL_DEPTH_BUFFER_BIT); --- > camera->setClearMask(GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT); 205c205 < camera->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); --- > camera->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT); 216c216 < camera->setClearMask(GL_DEPTH_BUFFER_BIT); --- > camera->setClearMask(GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT); Index: Effect.cxx === RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/material/Effect.cxx,v retrieving revision 1.29 diff -r1.29 Effect.cxx 53a54 > #include 255a257,274 > struct ColorMaskBuilder : PassAttributeBuilder > { > void buildAttribute(Effect* effect, Pass* pass, const SGPropertyNode* prop, > const osgDB::ReaderWriter::Options* options) > { > const SGPropertyNode* realProp = getEffectPropertyNode(effect, prop); > if (!realProp) > return; > > ColorMask *mask = new ColorMask; > Vec4 m = getColor(realProp); > mask->setMask(m.r(), m.g(), m.b(), m.a()); > pass->setAttributeAndModes(mask); > } > }; > > InstallAttributeBuilder installColorMask("color-mask"); > 477a497,589 > > EffectNameValue stencilFunctionInit[] = > { > {"never", Stencil::NEVER }, > {"less", Stencil::LESS}, > {"equal", Stencil::EQUAL}, > {"less-or-equal", Stencil::LEQUAL}, > {"greater", Stencil::GREATER}, > {"not-equal", Stencil::NOTEQUAL}, > {"greater-or-equal", Stencil::GEQUAL}, > {"always", Stencil::ALWAYS} > }; > > EffectPropertyMap stencilFunction(stencilFunctionInit); > > EffectNameValue stencilOperationInit[] = > { > {"keep", Stencil::KEEP}, > {"zero", Stencil::ZERO}, > {"replace", Stencil::REPLACE}, > {"increase", Stencil::INCR}, > {"decrease", Stencil::DECR}, > {"invert", Stencil::INVERT}, > {"increase-wrap", Stencil::INCR_WRAP}, > {"decrease-wrap", Stencil::DECR_WRAP} > }; > > EffectPropertyMap stencilOperation(stencilOperationInit); > > struct StencilBuilder : public PassAttributeBuilder > { > void buildAttribute(Effect* effect, Pass* pass, const SGPropertyNode* prop, > const osgDB::ReaderWriter::Options* options) > { > if (!isAttributeActive(effect, prop)) > return; > > const SGPropertyNode* pmode = getEffectPropertyChild(effect, prop, > "mode"); > if (pmode && !pmode->getValue()) { > pass->setMode(GL_STENCIL, StateAttribute::OFF); > return; > } > const SGPropertyNode* pfunction > = getEffectPropertyChild(effect, prop, "funct
Re: [Flightgear-devel] Stencil operations for effects and new "light cone"
Hi Patrice, and thanks Heiko! > There is a detail that I do not manage to sort out, though. > The effect looks great at day : http://imagebin.org/82128 > but at night, it tends to fill the lit area with grey, overwriting the > ground texture : http://imagebin.org/82129 Yes, that is an issue, and it is because this "light" is rendered as kind of an post processing effect. Basically, the current blend mode just adds the light's color to whatever there is on the screen. And during night it is mostly black which results in only the light's color showing up. I tried with multiplying the existing color values, but again, because there is just black, the result is not physically correct (the otherwise hidden details will not become visible). I don't know if the only real solution is to use real lights for "critical" lights as Tim suggested, but that is not possible at the moment. I will try to investigate if I can find some way around this. > my light cone matierial is as follows : MATERIAL "DefaultWhite" rgb 0.2 > 0.2 0.2 amb 0.2 0.2 0.2 emis 0 0 0 spec 0 0.5 0 shi 64 trans 0.2 This is ok, but I would rather use "rgb 1 1 1 amb 1 1 1" (white cone) and "trans 0.8" which means the cone is almost invisible. The trans works the opposite of normal alpha, at least to my experiences. Only the rgb or amb material is used, the others should have no effect. Hope this clears things up, Lauri -- Lauri Peltonen lauri.pelto...@gmail.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Request for comments: Airport lighting
Hi! I've heard that there is need for ability to toggle certain runway lights on or off, depending on which runways are in use. I've done some tests with obj.cxx and GroundLightManager to group lights together and turn them on or off, and I think I have figured it out so that I could make the system work. BUT we need to have the information about which light belongs to which runway, so this would need some changes. I propose following: - Add 3 new property types to btg file format (http://wiki.flightgear.org/index.php/BTG_File_Format): 3: Grandparent node name (in light's case, this would be the ICAO code of the airport) 4: Parent node name (with lights this would be the runway code) 5: Direction, vector (could be used with directional runway and taxiway lights, if missing, assume point light) 3 and 4 would be strings of arbitrary length, and 5 could be 3 doubles, x, y and z. This way we could easily bind the lights to certain airport code and runway code, so they could be toggled on or off via easy properties. I also think that one light could have multiple parents, so opposite ends of runway would light up the same lights. I don't think this breaks compatibility with older versions of FG, since the .btg reader just discards unknown properties. I also have some questions about lighting in general: - Does the runway have same kind of lighting if it's used for takeoffs or landings? What about which end of the runway is used? - Can one runway have different sets of lights (simple, CATI, CATII, whatever they are?) - Are taxiway lights always on or do they depend on the runways being used? I also saw something interesting here, like the blinking runway guard lights, stop bar lights and lead-on lights. They should probably be taken into account for future versions. Link: http://www.caa.co.uk/docs/33/CAP637.PDF And an image from the forums showing current situation which may or may not be realistic: http://lh3.ggpht.com/_UQs70Ldx8uc/S2BAlMoiKqI/BEY/eWQaD5JufaI/fgfs-screen-007.png I'm glad to take any comments about this proposition, and if there are some things about the lights that should be taken into consideration. Sincerely, Lauri (Zan) -- Lauri Peltonen lauri.pelto...@gmail.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 3d clouds rendering order
Hello all! Attached is a quick fix for the "massive depth sorting problem" (as stated by a slashdotter, see http://games.slashdot.org/comments.pl?sid=1565430&cid=31297500 ) of 3d clouds. It simply sorts the 3d cloud layers so that farthest away clouds are rendered first, which should be the desired behaviour with translucent objects. I once again hope that the patch is correct, did it with 'cvs diff -U *' this time, on simgear/simgear/scene/sky/. On another topic, are the 2d cloud layers broken? When I toggle off 3d clouds, all clouds disappear. I expected to see the good old 2d clouds. IIRC they had some depth sorting problems too, which I was going to try to fix too. Lauri A.K.A. Zan -- Lauri Peltonen Index: cloud.cxx === RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/sky/cloud.cxx,v retrieving revision 1.69 diff -u -r1.69 cloud.cxx --- cloud.cxx 23 Jan 2010 11:40:42 - 1.69 +++ cloud.cxx 1 Mar 2010 20:10:25 - @@ -757,7 +780,7 @@ last_lat = lat; } -layer3D->reposition( p, up, lon, lat, dt, layer_asl); +layer3D->reposition( p, up, lon, lat, alt, dt, layer_asl); return true; } Index: cloudfield.cxx === RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/sky/cloudfield.cxx,v retrieving revision 1.35 diff -u -r1.35 cloudfield.cxx --- cloudfield.cxx 23 Jan 2010 11:40:43 - 1.35 +++ cloudfield.cxx 1 Mar 2010 20:10:25 - @@ -69,7 +69,7 @@ sgVec3 SGCloudField::view_vec, SGCloudField::view_X, SGCloudField::view_Y; // reposition the cloud layer at the specified origin and orientation -bool SGCloudField::reposition( const SGVec3f& p, const SGVec3f& up, double lon, double lat, +bool SGCloudField::reposition( const SGVec3f& p, const SGVec3f& up, double lon, double lat, double alt, double dt, int asl ) { osg::Matrix T, LON, LAT; @@ -132,7 +132,11 @@ field_transform->setMatrix( LAT*LON*T ); } -field_root->getStateSet()->setRenderBinDetails(asl, "DepthSortedBin"); +// Render the clouds in order from farthest away layer to nearest one. +// I *think* we should not use the altitude difference directly, but instead +// allocate enough bins to hold all cloud layers. +// Assume 100km is the highest where clouds may exist! :o +field_root->getStateSet()->setRenderBinDetails(10 - abs(alt - asl) + CLOUDS_BIN, "DepthSortedBin"); return true; } Index: cloudfield.hxx === RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/sky/cloudfield.hxx,v retrieving revision 1.19 diff -u -r1.19 cloudfield.hxx --- cloudfield.hxx 26 Nov 2009 17:24:02 - 1.19 +++ cloudfield.hxx 1 Mar 2010 20:10:25 - @@ -113,7 +113,7 @@ * @param asl altitude of the layer */ bool reposition( const SGVec3f& p, const SGVec3f& up, -double lon, double lat, double dt, int asl); +double lon, double lat, double alt, double dt, int asl); osg::Group* getNode() { return field_root.get(); } -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 3d clouds rendering order
Hello again. Please forget the last patch I sent, since it was a huge black hole in my head I think :) This one does the same but is much simpler, just pushes all 3d clouds into CLOUDS_BIN which is depth sorted from back to front, and all 3d clouds render nicely. I still see problem with 2d cloud layers hiding the 3d clouds behind them. It needs a bit more thinking to get that one working correctly. Lauri A.K.A. Zan P.s. the 2d cloud layers work, it was the same black hole again. -- Lauri Peltonen Index: cloudfield.cxx === RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/sky/cloudfield.cxx,v retrieving revision 1.35 diff -u -r1.35 cloudfield.cxx --- cloudfield.cxx 23 Jan 2010 11:40:43 - 1.35 +++ cloudfield.cxx 1 Mar 2010 21:25:47 - @@ -132,7 +132,8 @@ field_transform->setMatrix( LAT*LON*T ); } -field_root->getStateSet()->setRenderBinDetails(asl, "DepthSortedBin"); +// Render the clouds in order from farthest away layer to nearest one. +field_root->getStateSet()->setRenderBinDetails(CLOUDS_BIN, "DepthSortedBin"); return true; } -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patch for shaders (default & reflect)
Hi all. Attached are two patches that should fix bug reports http://code.google.com/p/flightgear-bugs/issues/detail?id=246 and http://code.google.com/p/flightgear-bugs/issues/detail?id=252 . The patches should be against latest git, they are done with command "git diff". The first one just normalizes the length of the normal after flipping it in case of double sided polygons. I guess there is some interpolation issue with older nvidia cards leading to the light saturation issue, but at least on my computer this seemed to fix it. The second one removes unused varyings (vec4 -> vec3 etc) from reflect, bumpspec and reflect-bump-spec shaders and should allow running those shaders on older hardware. Authors of models using those shaders should probably check that the visual appearance is still the same, I did a quick check with some aircrafts and they looked fine to me. - Lauri Peltonen (Zan) diff --git a/Shaders/default.frag b/Shaders/default.frag index 3b01a66..52afbaf 100644 --- a/Shaders/default.frag +++ b/Shaders/default.frag @@ -14,7 +14,7 @@ float luminance(vec3 color) void main() { -vec3 n, halfV; +vec3 n; float NdotL, NdotHV, fogFactor; vec4 color = gl_Color; vec3 lightDir = gl_LightSource[0].position.xyz; @@ -22,16 +22,16 @@ void main() vec4 texel; vec4 fragColor; vec4 specular = vec4(0.0); -n = normalize(normal); + // If gl_Color.a == 0, this is a back-facing polygon and the // normal should be reversed. +n = (2.0 * gl_Color.a - 1.0) * normal; +n = normalize(n); -n = (2.0 * gl_Color.a - 1.0) * n; -NdotL = max(dot(n, lightDir), 0.0); +NdotL = dot(n, lightDir); if (NdotL > 0.0) { color += diffuse_term * NdotL; -halfV = halfVector; -NdotHV = max(dot(n, halfV), 0.0); +NdotHV = max(dot(n, halfVector), 0.0); if (gl_FrontMaterial.shininess > 0.0) specular.rgb = (gl_FrontMaterial.specular.rgb * gl_LightSource[0].specular.rgb diff --git a/Shaders/model-default.frag b/Shaders/model-default.frag index 5ed50a6..2c94b92 100644 --- a/Shaders/model-default.frag +++ b/Shaders/model-default.frag @@ -22,11 +22,11 @@ void main() vec4 texel; vec4 fragColor; vec4 specular = vec4(0.0); -n = normalize(normal); // If gl_Color.a == 0, this is a back-facing polygon and the // normal should be reversed. -n = (2.0 * gl_Color.a - 1.0) * n; -NdotL = max(dot(n, lightDir), 0.0); +n = (2.0 * gl_Color.a - 1.0) * normal; +n = normalize(n); +NdotL = dot(n, lightDir); if (NdotL > 0.0) { color += diffuse_term * NdotL; halfV = normalize(halfVector); diff --git a/Shaders/bumpspec.frag b/Shaders/bumpspec.frag index b708746..16f8d16 100644 --- a/Shaders/bumpspec.frag +++ b/Shaders/bumpspec.frag @@ -2,11 +2,11 @@ // Licence: GPL v2 // Author: Frederic Bouvier -varying vec4 ecPosition; +varying float fogCoord; + varying vec3 VNormal; varying vec3 VTangent; varying vec3 VBinormal; -varying vec4 constantColor; uniform sampler2D tex_color; uniform sampler2D tex_normal; @@ -29,7 +29,7 @@ void main (void) vec4 Diffuse = gl_LightSource[0].diffuse * nDotVP; vec4 Specular = gl_LightSource[0].specular * pf; - vec4 color = constantColor + Diffuse * gl_FrontMaterial.diffuse; + vec4 color = gl_Color + Diffuse * gl_FrontMaterial.diffuse; color *= texture2D(tex_color, gl_TexCoord[0].xy); color += Specular * gl_FrontMaterial.specular * ns.a; @@ -37,7 +37,6 @@ void main (void) float fogFactor; - float fogCoord = ecPosition.z; const float LOG2 = 1.442695; fogFactor = exp2(-gl_Fog.density * gl_Fog.density * fogCoord * fogCoord * LOG2); fogFactor = clamp(fogFactor, 0.0, 1.0); diff --git a/Shaders/bumpspec.vert b/Shaders/bumpspec.vert index 4ed1b8a..d7b7a89 100644 --- a/Shaders/bumpspec.vert +++ b/Shaders/bumpspec.vert @@ -2,23 +2,24 @@ // Licence: GPL v2 // Author: Frederic Bouvier -varying vec4 ecPosition; +varying float fogCoord; varying vec3 VNormal; varying vec3 VTangent; varying vec3 VBinormal; -varying vec4 constantColor; attribute vec3 tangent; attribute vec3 binormal; void main (void) { - ecPosition = gl_ModelViewMatrix * gl_Vertex; + vec4 pos = gl_ModelViewMatrix * gl_Vertex; +fogCoord = pos.z / pos.w; + VNormal = normalize(gl_NormalMatrix * gl_Normal); VTangent = normalize(gl_NormalMatrix * tangent); VBinormal = normalize(gl_NormalMatrix * binormal); - constantColor = gl_FrontLightModelProduct.sceneColor + gl_LightSource[0].ambient * gl_FrontMaterial.ambient; - gl_FrontColor = constantColor; + + gl_FrontColor = gl_FrontLightModelProduct.sceneColor + gl_LightSource[0].ambient * gl_FrontMaterial.ambient; gl_TexCoord[0] = gl_MultiTexCoord0; gl_Position = ftransform(); } diff --git a/Shaders/re