[Flightgear-devel] generators 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 generate 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
...
...
}
}
}
end of function
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] [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
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
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] 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
[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=47t=11274p=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
[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] 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] 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/reflect-bump-spec.frag b/Shaders
[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=1565430cid=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#174; 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#174; 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] 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
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] 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 file against latest
CVS version. Hope that is correct way.
The format of stencil operations in effect file is following:
stencil
function.../function
value.../value
mask.../mask
stencil-fail.../stencil-fail
z-fail.../z-fail
pass.../pass
/stencil
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 color-mask type=vec4d1 0 0
1/color-mask 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 osg/Stencil
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);
}
};
InstallAttributeBuilderColorMaskBuilder installColorMask(color-mask);
477a497,589
EffectNameValueStencil::Function 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}
};
EffectPropertyMapStencil::Function stencilFunction(stencilFunctionInit);
EffectNameValueStencil::Operation 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}
};
EffectPropertyMapStencil::Operation 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-getValuebool()) {
pass-setMode(GL_STENCIL, StateAttribute::OFF);
return;
}
const SGPropertyNode* pfunction
= getEffectPropertyChild(effect, prop, function);
const SGPropertyNode* pvalue
= getEffectPropertyChild(effect, prop, value);
const SGPropertyNode* pmask
= getEffectPropertyChild(effect, prop, mask);
const SGPropertyNode* psfail
= getEffectPropertyChild(effect, prop, stencil-fail);
const SGPropertyNode* pzfail
[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 ?xml version=1.0? PropertyList pathlight-cone.ac/path effect inherits-fromEffects/light-cone/inherits-from object-nameCone/object-name /effect /PropertyList -- 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] 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 lauri.pelto...@gmail.com
--- 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] = vec4(texFract, gl_MultiTexCoord0.y, 0.0, 0.0);
// scaling
vec3 position = gl_Vertex.xyz * gl_Normal.xxy;
// Rotation of the generic quad to specific one for the tree.
position.xy = vec2(dot
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] 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
+double lapse_rate = 0.00053; // at equator
+double pause_top = 93750;
+
+if(lat 60
