Re: [Flightgear-devel] could not find texture LFPO001.rgb and
To add to the carrier bug report, the meatball turns white instead of red when the aircraft approaches too low for the glideslope, which I guess is the default whte appearing instead of the missing mystery texture... Cheers, -R. (MD-Terp) Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as [EMAIL PROTECTED] From: Martin Spott [EMAIL PROTECTED] To: flightgear-devel@lists.sourceforge.net Sent: Friday, November 7, 2008 9:00:09 AM Subject: Re: [Flightgear-devel] could not find texture LFPO001.rgb and Hi Torsten, Torsten Dreyer wrote: It spits out the error message could not find texture LFPO001.rgb grepping thru the base packages finds Models/Airport/apt-light-ba.ac using this texture. Indeed, this is a known bug - due to recent occupation by some hobby project ;-) we simply didn't get around merging the bug-fixed shared model from our repository to CVS It also complains about missing red-source.rgb which is missing in the Nimitz/Models directory. That's one for the carrier guys. This is a bit confusing, I have to admit: Even though the carriers move around in the Scenery, they still live in the directory which is destined to hold models of fixed position. I guess this is simply due to compilance with long-term tradition. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] could not find texture LFPO001.rgb and
Torsten Dreyer wrote: It spits out the error message could not find texture LFPO001.rgb grepping thru the base packages finds Models/Airport/apt-light-ba.ac using this texture. Indeed, this is a known bug - due to recent occupation by some hobby project ;-) we simply didn't get around merging the bug-fixed shared model from our repository to CVS It also complains about missing red-source.rgb which is missing in the Nimitz/Models directory. That's one for the carrier guys. My bad, I'll fix it This is a bit confusing, I have to admit: Even though the carriers move around in the Scenery, they still live in the directory which is destined to hold models of fixed position. I guess this is simply due to compilance with long-term tradition. Historical accident, I'm afraid. We adapted the original, static carrier Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p with terrain
On samedi 08 novembre 2008, Melchior FRANZ wrote:
* gerard robin -- 11/5/2008 4:27 PM:
Though, that nasal Terrain script could be part of the FG generic nasal
script , won't it be useful elsewhere (AI animation ? for instance)
This script continously updates a property which tells if the aircraft's
origin (usually the nose, sometimes other points) is over solid ground
or water. This is really a random point, and whether the aircraft's
nose is over water or not doesn't usually mean much.
What would be useful is to know whether contact points (especially
landing gear) are over water. But this is something that the FDM glue
code has to care for (JSBSim.cxx). It can query everything we know
about the terrain beneath from the ground cache, just like YASim.
That's a sample of what info is available about any terrain (~ texture)
type:
{ light_coverage: 0, bumpiness: 0.5999,
load_resistance: 1e+30, solid: 0,
names: [ Lake, Pond, Reservoir, Stream, Canal ],
friction_factor: 1, rolling_friction: 1.5
}
Would be nice if JSBSim would consider the ground properties in the
gear code, but it should at least publish those values that are needed
for sinking effects or rumbling sound.
terrain.nas is only a workaround for this omission. If you want to
know about terrain properties at other points, just use the geodinfo()
function directly (but not too often, to avoid expensive terrain
intersection tests).
m.
Is it it on purpose that you deviate my explanation , or you don't you
understand what i said ?
I Don't said that JSBSim devel wont include these information, with a
specific development in it .
I only said that the information in anycase is missing when why are not using
any FDM, AI model don't use it (wad my first remark), and missing when we are
within YASIm which is suppose to have it ( was my second remark ).
YES, missing when we are using YASim , i want to improve my rescue animation
and avoid that the rescued person is not digging solid.
WHERE is the property which say that the aircraft is on solid or on water ?
May be you don't know... but the rescue op im talking about, is with
helicopter and helicopter is using YASIm FDM
Cheers
--
Gérard
http://pagesperso-orange.fr/GRTux/
J'ai décidé d'être heureux parce que c'est bon pour la santé.
Voltaire
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p with terrain
On samedi 08 novembre 2008, gerard robin wrote:
On samedi 08 novembre 2008, Melchior FRANZ wrote:
* gerard robin -- 11/5/2008 4:27 PM:
Though, that nasal Terrain script could be part of the FG generic
nasal script , won't it be useful elsewhere (AI animation ? for
instance)
This script continously updates a property which tells if the aircraft's
origin (usually the nose, sometimes other points) is over solid ground
or water. This is really a random point, and whether the aircraft's
nose is over water or not doesn't usually mean much.
What would be useful is to know whether contact points (especially
landing gear) are over water. But this is something that the FDM glue
code has to care for (JSBSim.cxx). It can query everything we know
about the terrain beneath from the ground cache, just like YASim.
That's a sample of what info is available about any terrain (~ texture)
type:
{ light_coverage: 0, bumpiness: 0.5999,
load_resistance: 1e+30, solid: 0,
names: [ Lake, Pond, Reservoir, Stream, Canal ],
friction_factor: 1, rolling_friction: 1.5
}
Would be nice if JSBSim would consider the ground properties in the
gear code, but it should at least publish those values that are needed
for sinking effects or rumbling sound.
terrain.nas is only a workaround for this omission. If you want to
know about terrain properties at other points, just use the geodinfo()
function directly (but not too often, to avoid expensive terrain
intersection tests).
m.
Is it it on purpose that you deviate my explanation , or you don't you
understand what i said ?
I Don't said that JSBSim devel wont include these information, with a
specific development in it .
I only said that the information in anycase is missing when why are not
using any FDM, AI model don't use it (wad my first remark), and missing
when we are within YASIm which is suppose to have it ( was my second
remark ).
YES, missing when we are using YASim , i want to improve my rescue
animation and avoid that the rescued person is not digging solid.
WHERE is the property which say that the aircraft is on solid or on water
?
May be you don't know... but the rescue op im talking about, is with
helicopter and helicopter is using YASIm FDM
Cheers
AND in order to answer the point 1 and why not the point 2 ( without being
obliged to modify YASim)
Is it so difficult, to include within FG, the code which gives the
information, or at least, to include as generic the 'famous Nasal script ??
May be any idea which is not coming from you is bad :)
Cheers
--
Gérard
http://pagesperso-orange.fr/GRTux/
J'ai décidé d'être heureux parce que c'est bon pour la santé.
Voltaire
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p with terrain
Am Samstag, den 08.11.2008, 12:26 +0100 schrieb gerard robin:
On samedi 08 novembre 2008, Melchior FRANZ wrote:
* gerard robin -- 11/5/2008 4:27 PM:
Though, that nasal Terrain script could be part of the FG generic nasal
script , won't it be useful elsewhere (AI animation ? for instance)
This script continously updates a property which tells if the aircraft's
origin (usually the nose, sometimes other points) is over solid ground
or water. This is really a random point, and whether the aircraft's
nose is over water or not doesn't usually mean much.
What would be useful is to know whether contact points (especially
landing gear) are over water. But this is something that the FDM glue
code has to care for (JSBSim.cxx). It can query everything we know
about the terrain beneath from the ground cache, just like YASim.
That's a sample of what info is available about any terrain (~ texture)
type:
{ light_coverage: 0, bumpiness: 0.5999,
load_resistance: 1e+30, solid: 0,
names: [ Lake, Pond, Reservoir, Stream, Canal ],
friction_factor: 1, rolling_friction: 1.5
}
Would be nice if JSBSim would consider the ground properties in the
gear code, but it should at least publish those values that are needed
for sinking effects or rumbling sound.
terrain.nas is only a workaround for this omission. If you want to
know about terrain properties at other points, just use the geodinfo()
function directly (but not too often, to avoid expensive terrain
intersection tests).
m.
Is it it on purpose that you deviate my explanation , or you don't you
understand what i said ?
I Don't said that JSBSim devel wont include these information, with a
specific development in it .
I only said that the information in anycase is missing when why are not using
any FDM, AI model don't use it (wad my first remark), and missing when we are
within YASIm which is suppose to have it ( was my second remark ).
I think it is undestandable that the ground properties are not queried
while the Aircraft's gears are high up in the Air. They are only of
interest when the gear is on the ground.
YES, missing when we are using YASim , i want to improve my rescue animation
and avoid that the rescued person is not digging solid.
WHERE is the property which say that the aircraft is on solid or on water ?
I could use this information for the walker too. The current approach
with geo.elevation has some drawbacks (e.g passing beneath bridges isn't
possible).
Glazmax suggested in the forum to use submodels and query the impact
report. This should provide info wether the ground is solid or not
(=water). I haven't done much on this topic recently, but believe this
is could be a solution for both of us.
May be you don't know... but the rescue op im talking about, is with
helicopter and helicopter is using YASIm FDM
Cheers
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
Hi, I've put together an improved 3D clouds patch, available from here: http://www.nanjika.co.uk/flightgear/clouds2.tar.gz It fixes the following issues (to a greater or lesser extent): 1) Performance. Quad trees used to improve culling, and the sprites are placed on the surface of a sphere rather than randomly throughout the cloud, requiring fewer textures. This saves about 5-10fps on my machine. Indeed! Much better now! Even switching between None, METAR, fair weather make no really difference for me now! But the clouds seems to me that they are now to regular and not so random as before. 4) The cloud field is shifted as you travel. There's a small bug in that the clouds jump as you reach the edge of the field. How about loading the needed set of cloudfield when approaching the next available METAR? In reality weather and clouds are changing even on short distances. 5) Iterative sorting of sprites. This doesn't appear to solve the alpha blending problem completely, but may help a bit. There is no much improvement for me- still very visible. I wonder if this would disappear if we could add some volume to the clouds, but this would mean that we have to add some shaders and would also mean a decreasing of fps... Regards HHS - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
On dimanche 09 novembre 2008, Heiko Schulz wrote: Hi, I've put together an improved 3D clouds patch, available from here: http://www.nanjika.co.uk/flightgear/clouds2.tar.gz It fixes the following issues (to a greater or lesser extent): 1) Performance. Quad trees used to improve culling, and the sprites are placed on the surface of a sphere rather than randomly throughout the cloud, requiring fewer textures. This saves about 5-10fps on my machine. Indeed! Much better now! Even switching between None, METAR, fair weather make no really difference for me now! But the clouds seems to me that they are now to regular and not so random as before. 4) The cloud field is shifted as you travel. There's a small bug in that the clouds jump as you reach the edge of the field. How about loading the needed set of cloudfield when approaching the next available METAR? In reality weather and clouds are changing even on short distances. 5) Iterative sorting of sprites. This doesn't appear to solve the alpha blending problem completely, but may help a bit. There is no much improvement for me- still very visible. I wonder if this would disappear if we could add some volume to the clouds, but this would mean that we have to add some shaders and would also mean a decreasing of fps... Regards HHS I do like that new version , i hope that the next one without that ordering problem will be perfect. http://pagesperso-orange.fr/GRTux/3DClouds-img6.jpg with that screenshot we may identify where the problem is: -no clouds layer behind it is very good ( bottom part of the sky ) - with clouds layers behind ( upper part of the sky ) we get that ugly blue color -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p with terrain
On samedi 08 novembre 2008, Detlef Faber wrote:
Am Samstag, den 08.11.2008, 12:26 +0100 schrieb gerard robin:
On samedi 08 novembre 2008, Melchior FRANZ wrote:
* gerard robin -- 11/5/2008 4:27 PM:
Though, that nasal Terrain script could be part of the FG generic
nasal script , won't it be useful elsewhere (AI animation ? for
instance)
This script continously updates a property which tells if the
aircraft's origin (usually the nose, sometimes other points) is over
solid ground or water. This is really a random point, and whether the
aircraft's nose is over water or not doesn't usually mean much.
What would be useful is to know whether contact points (especially
landing gear) are over water. But this is something that the FDM glue
code has to care for (JSBSim.cxx). It can query everything we know
about the terrain beneath from the ground cache, just like YASim.
That's a sample of what info is available about any terrain (~ texture)
type:
{ light_coverage: 0, bumpiness: 0.5999,
load_resistance: 1e+30, solid: 0,
names: [ Lake, Pond, Reservoir, Stream, Canal ],
friction_factor: 1, rolling_friction: 1.5
}
Would be nice if JSBSim would consider the ground properties in the
gear code, but it should at least publish those values that are needed
for sinking effects or rumbling sound.
terrain.nas is only a workaround for this omission. If you want to
know about terrain properties at other points, just use the geodinfo()
function directly (but not too often, to avoid expensive terrain
intersection tests).
m.
Is it it on purpose that you deviate my explanation , or you don't you
understand what i said ?
I Don't said that JSBSim devel wont include these information, with a
specific development in it .
I only said that the information in anycase is missing when why are not
using any FDM, AI model don't use it (wad my first remark), and missing
when we are within YASIm which is suppose to have it ( was my second
remark ).
I think it is undestandable that the ground properties are not queried
while the Aircraft's gears are high up in the Air. They are only of
interest when the gear is on the ground.
YES, missing when we are using YASim , i want to improve my rescue
animation and avoid that the rescued person is not digging solid.
WHERE is the property which say that the aircraft is on solid or on
water ?
I could use this information for the walker too. The current approach
with geo.elevation has some drawbacks (e.g passing beneath bridges isn't
possible).
I don't know which system is being used with geodinfo (nasal) , i don't have
any difficulties when passing beneath bridges.
Glazmax suggested in the forum to use submodels and query the impact
report. This should provide info wether the ground is solid or not
(=water). I haven't done much on this topic recently, but believe this
is could be a solution for both of us.
Yes, i like simple stuff, i am not sure i will use submodels only for this :)
May be you don't know... but the rescue op im talking about, is
with helicopter and helicopter is using YASIm FDM
Cheers
Cheers
--
Gérard
http://pagesperso-orange.fr/GRTux/
J'ai décidé d'être heureux parce que c'est bon pour la santé.
Voltaire
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
Hi again, 5) Iterative sorting of sprites. This doesn't appear to solve the alpha blending problem completely, but may help a bit. There is no much improvement for me- still very visible. I wonder if this would disappear if we could add some volume to the clouds, but this would mean that we have to add some shaders and would also mean a decreasing of fps... Regards HHS I just tried out the cloud textures available for X-Plane! They even have more worse edeges and alpha blending than our current cloud puffs- if that woulden't be the case they would not much differ from that big commercial-made-by-developers-paid-by-a-nerd called X-Plane! BUT: The alpha blending seems to depend on the direction of view- I had just a fly from TNCM with heading 230- looking forward in chase view the alpha blending worked full! No or very less edges! But looking in the opposite direction no alpha blending! Heading to the opposite direction (HDG 50) the alpha blending also disappeared. My guess it has something to do with the direction of the clouds Hope my observations can help a little bit Regards HHS - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
Hi Stuart,
Attached is a small fix for the sorting in CloudShaderGeometry.cxx.
I think the sorting problem stems from the osg idiosyncracy
to store transposed matrices...so the intuitive
osg::Vec4f p = vm * osg::Vec4f(_cloudsprites[i]-position.osg(), 1.0f);
needs to be replaced with...
osg::Vec4f p = vm.preMult(osg::Vec4f(_cloudsprites[i]-position.osg(),
1.0f);
The patch also optimizes the distance calculation - it evaluates the distances
in model space instead of eye space, which reduces computation to a dot-
product instead of a matrix multiplication.
bye,
Manuel
Index: CloudShaderGeometry.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/sky/CloudShaderGeometry.cxx,v
retrieving revision 1.2
diff -u -r1.2 CloudShaderGeometry.cxx
--- CloudShaderGeometry.cxx 6 Nov 2008 21:58:07 - 1.2
+++ CloudShaderGeometry.cxx 9 Nov 2008 03:34:23 -
@@ -34,27 +34,32 @@
{
void CloudShaderGeometry::drawImplementation(RenderInfo renderInfo) const
{
+if (!_cloudsprites.size()) return;
+
osg::State state = *renderInfo.getState();
osg::Matrix vm = state.getModelViewMatrix();
//TODO: It isn't clear whether this is worth the perf hit ATM.
-// Do a single iteration of a bubble sort. We do this in reverse
-// so that elements closest to the camera bubble to the front than
-// the elements further away
-for(int i = (_cloudsprites.size() -2); i = 0; i--)
+// Transform the viewing direction, represented by the eye space vector (0,0,-1, 0), into model-space
+// (here we simply take the opposite direction and reverse the ordering when sorting)
+osg::Vec3f view_dir(vm(0, 2), vm(1, 2), vm(2, 2)); // Caveat: OpenSceneGraph matrices are transposed!
+
+float p = view_dir*_cloudsprites[0]-position.osg();
+// Do a single iteration of a bubble sort, sorting
+// back to front.
+for(int i = 0; i _cloudsprites.size() - 1; i++)
{
-osg::Vec4f p = vm * osg::Vec4f(_cloudsprites[i]-position.osg(), 1.0f);
-osg::Vec4f q = vm * osg::Vec4f(_cloudsprites[i+1]-position.osg(), 1.0f);
-
-if (p.z() q.z())
-{
+float q = view_dir*_cloudsprites[i+1]-position.osg();
+if (p q) {
CloudSprite c = *_cloudsprites[i];
*_cloudsprites[i] = *_cloudsprites[i+1];
*_cloudsprites[i+1] = c;
}
+else
+p = q;
}
-
+
const Extensions* extensions = getExtensions(state.getContextID(),true);
for(CloudSpriteList::const_iterator t = _cloudsprites.begin(); t != _cloudsprites.end(); ++t)
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
On Sun, 2008-11-09 at 05:30 +0100, Manuel Massing wrote: Hi Stuart, Attached is a small fix for the sorting in CloudShaderGeometry.cxx. I think the sorting problem stems from the osg idiosyncracy to store transposed matrices...so the intuitive osg::Vec4f p = vm * osg::Vec4f(_cloudsprites[i]-position.osg(), 1.0f); needs to be replaced with... osg::Vec4f p = vm.preMult(osg::Vec4f(_cloudsprites[i]-position.osg(), 1.0f); The patch also optimizes the distance calculation - it evaluates the distances in model space instead of eye space, which reduces computation to a dot- product instead of a matrix multiplication. bye, Manuel Well, that seems to have solved the alpha blending issues! Thanks! Is this applicable to the trees, too? Ron - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
