[Flightgear-devel] Terrain self-shading
Following a forum discussion http://www.flightgear.org/forums/viewtopic.php?f=47t=19693 I've done some experiments with terrain self-shading based on changing the balance between ambient and diffuse light. The results look fairly compelling and the illusion (even without a real shadow-map) is usually pretty good (in fact, one has to go looking for cases where it breaks, they don't usually stick out even in complicated terrain) http://users.jyu.fi/~trenk/pics/light_balance_new05.jpg http://users.jyu.fi/~trenk/pics/light_balance_new06.jpg Since it's not based on a shadow-map, it works still 100 km out http://users.jyu.fi/~trenk/pics/light_balance_new02.jpg It works by reducing ambient light in the terrain shader, and to compensate for the loss of scene brighness, diffuse light has to be oversaturated (is this problematic ?). One problem is that I don't know the default ambient and diffuse reflection coefficients of terrain, so I have to experiment. If anyone knows these, please let me know, then I could compute rather than experiment. I do know that full ambient light has an intensity of about 0.5 in each channel and full diffuse light has 1.0. Downstream, to preserve the illusion of shadows, I've had to alter the tree shader to purely ambient lighting based on sun angle above the horizon. But that seems to be a good idea in general - not only is this cheapter to compute, but also our tree sprites have flat suraces with a clear normal, so they have very pronounced directional scattering - real trees have random orientation of leaves and needles and a leaf can also transmit light, so I think real trees have much weaker directional light scattering and isotropic scattering is actually the better approximation. I'm describing this in detail because the change is rather small (3 lines in the shader including all the environment dependencies on cloud cover and sun angle) - so this is an extremely good bang for the buck, and I would perhaps suggest considering similar changes in the other rendering schemes. I'll try to push a test modification to the highest quality terrain shader and the tree shader on Monday, so that you can experiment a bit and make up your mind * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain self-shading
On 04/14/2013 10:40 AM, Renk Thorsten wrote: One problem is that I don't know the default ambient and diffuse reflection coefficients of terrain, so I have to experiment. If anyone knows these, please let me know, then I could compute rather than experiment. They are read from the ambient, diffuse and specular files in fgdata/Lighting. For the default lighting scheme these do get altered, but I think you already override that scheme completely. The first row is the sun position (with 90 being at the horizon, 9 being straight up) and the second row is the lighting factor. Erik -- http://www.adalin.com - Hardware accelerated AeonWave and OpenAL for Windows and Linux - AeonWave Audio Effects software for DJ, Instrumentalist and Vocalist -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] vb6
how to use visual basic to display attitude of aircraft ,, full example -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Nasal props API relative path support
Extend Nasal property methods to support relative paths. All methods exposed to the Nasal props module now accept an optional first parameter refering to another node by a relative path. I'm a bit torn on this change; making APIs more flexible is usually a good thing. However, the cost of property path parsing has previously shown up in profilers as a source of dynamic allocations and overhead. Historically, on the C++ side; I can believe that in Nasal the extra parsing overhead is lost in general Nasal overhead, but still, the idea of the existing API was to force you to design work 'the right way', i.e cache leaf leaf nodes as objects, instead of repeated referring to leaves by a relative path. If you just want a quick and dirty way to read one property, we have getprop / setprop - for any other use, you should be doing what the API already supported; getting a props.Node object for the leaf, and then manipulating it with no further string/path handling. At least, I would prefer that getValue and setValue did not support this, since it will surely encourage convenient-but-inefficient styles of use. (I would also be happy to extend props.nas with helpers to make the above syntactically more compact, but I think such sugar can all be done on the Nasal side) Regards, James -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain self-shading
Hi Thorsten, I presume the balance between ambient and diffuse should vary with the weather. A clear sky gives harsh shadows and overcast sky with several layers of clouds gives barely any shadows (dull day in photographer speak). Your results (which are really pretty) are likely to be unrealistic with bad weather and perhaps a middle term as it is now will fit more situations if the balance is not adjustable. Regards, -Fred -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal props API relative path support
Am 2013-04-14 14:30, schrieb James Turner: Extend Nasal property methods to support relative paths. All methods exposed to the Nasal props module now accept an optional first parameter refering to another node by a relative path. I'm a bit torn on this change; making APIs more flexible is usually a good thing. However, the cost of property path parsing has previously shown up in profilers as a source of dynamic allocations and overhead. I haven't looked at it in detail, but why are dynamic allocations needed for parsing a property path? If this is the case we should to some profiling and rework it if needed. Historically, on the C++ side; I can believe that in Nasal the extra parsing overhead is lost in general Nasal overhead, but still, the idea of the existing API was to force you to design work 'the right way', i.e cache leaf leaf nodes as objects, instead of repeated referring to leaves by a relative path. If you just want a quick and dirty way to read one property, we have getprop / setprop - for any other use, you should be doing what the API already supported; getting a props.Node object for the leaf, and then manipulating it with no further string/path handling. At least, I would prefer that getValue and setValue did not support this, since it will surely encourage convenient-but-inefficient styles of use. (I would also be happy to extend props.nas with helpers to make the above syntactically more compact, but I think such sugar can all be done on the Nasal side) One thing I thing I want to achieve with this changes is to make the Nasal props API more similar to its C++ counterpart as this makes it easier to use if you are using both the C++ and the Nasal API. Also someday I want to refactor nasal-props.cpp to use cppbind, where I want to export as much methods as possible with exactly the same signature than in C++. Especially if using properties seldom (eg. only for initialization) the relative versions are probably even faster, as the Nasal overhead is lower. Eg. consider the following Nasal code used to initialize some module: var cfg = props.globals.getNode(/my/config/root, 1); var x = cfg.getDoubleValue(x); var do_it = cfg.getBoolValue(do_it); Using getprop on the one hand does not allow getting a property converted to a given type and on the other hand is tedious to use for more than one property, as one has to assemble the according property paths (which is definitely less efficient than using a relative method). Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain self-shading
On Sun, Apr 14, 2013 at 9:40 AM, Renk Thorsten wrote: Downstream, to preserve the illusion of shadows, I've had to alter the tree shader to purely ambient lighting based on sun angle above the horizon. But that seems to be a good idea in general - not only is this cheapter to compute, but also our tree sprites have flat suraces with a clear normal, so they have very pronounced directional scattering - real trees have random orientation of leaves and needles and a leaf can also transmit light, so I think real trees have much weaker directional light scattering and isotropic scattering is actually the better approximation. No objection from me. I've never been particularly happy with the directional scatter on the trees, but haven't spent any time trying to fix it. On a related note, the thread highlights that our tree textures are rather small, so our trees look quite blocky. When I initially implemented them, I think I just used the same texture sizes as the existing tree models, so the trees are only 128 pixels tall in a 512x128 strip. As it happens, I'm part way through a change that would allow varying snow- and leaf- cover without having to load different textures, so trees above the snowline could be snow covered while those below are not. This will increase the size of the textures to 512x512, while an individual tree will remain on 128 pixels tall. Given that we've got a very limited number of tree textures and the same texture is used on a large number of objects, perhaps it would be worthwhile increasing the resolution? -Stuart -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] static friction patch
Hi,
A long time ago I started working on a different implementation for
YASim static friction. With help from Csaba and Mathias Fröhlich the
patch worked but I never finished polishing it to submit a final
version. I finally got back to it and, although it is working on my
tests, I am not sure it follows the architecture design properly. I
think it could use some more testing also, as I couldn't test most of
the aircraft.
If you guys could test it and/or give any tips on how not to break any
interface design it would be appreciated.
I have a question also, is it possible to configure how much brake is
applied when I press the brake button? For now when you brake, the wheel
will lock and it will be hard to control the plane. I think it would be
necessary to limit the amount of brakes applied when using a key. It is
probably going to be more realistic when using a breaking pedal right
now though.
Regards,
Diogo
diff --git a/src/FDM/YASim/BodyEnvironment.hpp b/src/FDM/YASim/BodyEnvironment.hpp
index 0ff096a..d9b1719 100644
--- a/src/FDM/YASim/BodyEnvironment.hpp
+++ b/src/FDM/YASim/BodyEnvironment.hpp
@@ -19,6 +19,7 @@ struct State {
float rot[3];// rotational velocity
float acc[3];// acceleration
float racc[3]; // rotational acceleration
+double dt;// Time offset
// Simple initialization
State() {
@@ -29,6 +30,7 @@ struct State {
for(j=0; j3; j++)
orient[3*i+j] = i==j ? 1.0f : 0.0f;
}
+ dt = 0.0;
}
void posLocalToGlobal(float* lpos, double *gpos) {
diff --git a/src/FDM/YASim/FGGround.cpp b/src/FDM/YASim/FGGround.cpp
index a2f787b..f15ef19 100644
--- a/src/FDM/YASim/FGGround.cpp
+++ b/src/FDM/YASim/FGGround.cpp
@@ -22,13 +22,13 @@ FGGround::~FGGround()
}
void FGGround::getGroundPlane(const double pos[3],
- double plane[4], float vel[3])
+ double plane[4], float vel[3],
+ unsigned body)
{
// Return values for the callback.
double cp[3], dvel[3], dangvel[3];
const simgear::BVHMaterial* material;
-simgear::BVHNode::Id id;
-_iface-get_agl_m(_toff, pos, 2, cp, plane, dvel, dangvel, material, id);
+_iface-get_agl_m(_toff, pos, 2, cp, plane, dvel, dangvel, material, body);
// The plane below the actual contact point.
plane[3] = plane[0]*cp[0] + plane[1]*cp[1] + plane[2]*cp[2];
@@ -38,12 +38,12 @@ void FGGround::getGroundPlane(const double pos[3],
void FGGround::getGroundPlane(const double pos[3],
double plane[4], float vel[3],
- const simgear::BVHMaterial **material)
+ const simgear::BVHMaterial **material,
+ unsigned body)
{
// Return values for the callback.
double cp[3], dvel[3], dangvel[3];
-simgear::BVHNode::Id id;
-_iface-get_agl_m(_toff, pos, 2, cp, plane, dvel, dangvel, *material, id);
+_iface-get_agl_m(_toff, pos, 2, cp, plane, dvel, dangvel, *material, body);
// The plane below the actual contact point.
plane[3] = plane[0]*cp[0] + plane[1]*cp[1] + plane[2]*cp[2];
@@ -51,6 +51,15 @@ void FGGround::getGroundPlane(const double pos[3],
for(int i=0; i3; i++) vel[i] = dvel[i];
}
+bool FGGround::getBody(double t, double bodyToWorld[16], double linearVel[3],
+ double angularVel[3], unsigned body)
+{
+if (!_iface-get_body_m(_toff + t , body, bodyToWorld, linearVel, angularVel))
+return false;
+
+return true;
+}
+
bool FGGround::caughtWire(const double pos[4][3])
{
return _iface-caught_wire_m(_toff, pos);
diff --git a/src/FDM/YASim/FGGround.hpp b/src/FDM/YASim/FGGround.hpp
index f3cdadb..1869acf 100644
--- a/src/FDM/YASim/FGGround.hpp
+++ b/src/FDM/YASim/FGGround.hpp
@@ -19,11 +19,16 @@ public:
virtual ~FGGround();
virtual void getGroundPlane(const double pos[3],
-double plane[4], float vel[3]);
+double plane[4], float vel[3],
+unsigned body);
virtual void getGroundPlane(const double pos[3],
double plane[4], float vel[3],
-const simgear::BVHMaterial **material);
+const simgear::BVHMaterial **material,
+unsigned body);
+
+virtual bool getBody(double t, double bodyToWorld[16], double linearVel[3],
+ double angularVel[3], unsigned id);
virtual bool caughtWire(const double pos[4][3]);
diff --git a/src/FDM/YASim/Gear.cpp b/src/FDM/YASim/Gear.cpp
index 6276c44..13faa96 100644
--- a/src/FDM/YASim/Gear.cpp
+++ b/src/FDM/YASim/Gear.cpp
@@ -5,6 +5,7 @@
#include Math.hpp
#include BodyEnvironment.hpp
+#include Ground.hpp
#include RigidBody.hpp
#include cfloat
@@ -13,6 +14,7 @@
#include Gear.hpp
