Re: [Flightgear-devel] First attempt with terragear: fail! :-(
Gijs de Rooy wrote: Looks like OGR-decode is broken (in the Windows builds at least) since some time. I still don't completely understand the difference between OGR and Shape, both seem to deliver the same results... Maybe someone else can explain this? ogr-decode uses gdal to process the shapes, which is generally a good idea as gdal is THE tool for such tasks. As I'm not running windows I can't help with improving the situation there, sorry. Chris -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Spaceflight patches
Independent of using Earthview or not, I've found that the following series of
code modifications makes Flightgear support flights into low orbits (without
Earthview, you can enjoy a fogged sphere, but without the changes, JSBSim
models never reach high enough and rendering artefacts (grey zone, red zone,
dark zone) appear.
1) The fix for almost everything is Ron's patch:
diff --git a/src/Environment/atmosphere.cxx b/src/Environment/atmosphere.cxx
index 022ea54..f16005f 100644
--- a/src/Environment/atmosphere.cxx
+++ b/src/Environment/atmosphere.cxx
@@ -18,7 +18,8 @@ ISA_layer(3, 32000, 104986, 868.019,0.256326, 228.65,
-44.50, -0.0028, -
ISA_layer(4, 47000, 154199, 110.906, 0.0327506, 270.65, -2.50, 0,
0),
ISA_layer(5, 51000, 167322, 66.9389, 0.0197670, 270.65, -2.50, 0.0028,
0.0008534),
ISA_layer(6, 71000, 232939, 3.95642, 0.00116833, 214.65, -58.50, 0.0020,
0.0006096),
-ISA_layer(7, 8, 262467, 0.88628, 0.000261718, 196.65, -76.50),
+ISA_layer(7, 8, 262467, 0.88628, 0.000261718, 196.65, -76.50, 0.0,
0.0),
+ISA_layer(8, 1.0e9, 3.28e9, 0.1, 3.0e-9,2.73, -270.4, 0.0,
0.0),
};
const int ISA_def_size(sizeof(ISA_def) / sizeof(ISA_layer));
This removes the red and dark zone rendering artefacts, it enables JSBSim
operation in orbit beyond 150 km altitude (over the last days, I've tried
taking the Vostok to a 450 km orbit and back down and then went into some basic
orbital maneuvering raising the orbit to a circular 800 km - all this works as
expected, at some point the TDU just doesn't have the juice to do anything
fancy, there's no return from 800 km...). It also removes the hole in the
atmosphere at re-entry - previously g-force ramped up around around 70 km, then
fell to zero, then ramped up to full around 40 km altitude - now it's a smooth
deceleration.
I if no one sees any bad side effects, I would highly recommend to commit this
to GIT.
2) The grey zone is caused by the spacecraft going beyond the skydome, in which
case a fog-grey background color is painted. This can be solved by changing the
background color to black, and Lauri told me how to do that:
flightgear/src/Main/renderer.cxx around line 700. There are two
instances of following:
camera-setClearColor(toOsg(clearColor));
which should be changed to
camera-setClearColor(osg::Vec4(0.0, 0.0, 0.0, 0.0));
To my knowledge this was already committed at some point but got reversed since
it caused black fog for low visibility when the skydome unloaded.
However, thanks to Torsten's recent work, we can now fix that by not unloading
the skydome at low visibility, i.e. we simply default
/sim/rendering/minimum-sky-visibility
to a really low value (possibly zero) and the skydome never unloads, which
prevents the black fog from being an issue and fixes the grey zone at high
altitude.
If there are no other bad side effects I have missed, I would recommend to
commit this to GIT.
3) Vostok is no longer maintained by vitos, so to fly it to high altitude
someone needs to remove the Nasal-coded mission restriction.
This means removing the block
if (altitudemaximum_altitude_ft)
{
setprop(fdm/jsbsim/systems/crashes/crashed, 1);
setprop(fdm/jsbsim/systems/crashes/crash-type, Alititude exceeds
~(maximum_altitude_ft*0.3048/1000)~km);
crash(Alititude exceeds ~(maximum_altitude_ft*0.3048/1000)~km,
Vysota prevysila ~(maximum_altitude_ft*0.3048/1000)~km);
}
in Aircraft/Vostok-1/Nasal/Crashes.nas.
Provided the first patch which fixes the reason for why this condition is
probed in Nasal is committed, I would ask that the altitude restriction in
Vostok is also removed.
Thanks,
* Thorsten
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Skydome shader rendering artefact
I guess most people are aware of the rendering artefact in the skydome shader. I've made an observation which might shed some light into what it happening. Under most angles, the artefact appears as a thin light grey line with subtly mismatched colors to both sides of it. However, under some angles at really high altitude, the line 'opens up' and becomes a narrow triangle. After changing the background color without skydome from fog to black, I've seen this narrow triangle filled with black rather than grey. This suggests that what we're seeing is not really a problem caused by the shader computations, but that there is a 'crack' in the skydome. I've observed repeatedly with the more complicated terrain shaders that they generate color and haze mismatches across fault lines in the terrain. This seems to be that more complicated trigonometry interpolation is thrown off-track whereas more simple distance computation fogging are not. So it may just be the case that the default skydome rendering procedure would never show such a crack in the skydome, but a more complicated shader would. Anyway, that's my best suspicion at this point, that in the artefact region we really see through a crack in the skydome into whatever is rendered beyond, and that trigonometry doesn't interpolate properly across the crack. So, I would recommend to have a look at the skydome vertex structure, although I have no idea where that resides. Cheers, * Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG
For anyone who wants to have a look at Earthview in action, I've made the first version available for download here: http://www.flightgear.org/forums/viewtopic.php?f=6t=15754#p153257 (I have the next higher resolution level textures as well, but they're too large to host for me). Anyway, this is really meant as an invitation to 3d modellers - I'm just fooling around with ac3d, I've no real idea how to use it properly - I guess you guys can do the chopping of the sphere into segments and the texturing of the segments much more precisely and thus get rid of the seams, or even introduce some smart texturing allowing higher resolution in the fly. This is just a really simple 3d model with fancy textures, so if you can do an aircraft or a cockpit, this should be a piece of cake! Please really feel free to play with it, because I'm not going to do much more, I want to get back to weather-making and just fly into space for recreational purposes :-) Our space shuttle orbiter model (from many years ago) is incomplete, and based on limited data from publicly available tech reports. I do have a J246 model that is a launch vehicle designed to place heavy payloads into orbit. That is incomplete, and awaiting some simple guidance for the upper stage to try and get it into orbit from the launch pad. A couple of years ago Robin Gerard made a 3D model of that, as well as the pad. It will be nice to see that fly someday. EEKPO has located the model, see http://www.flightgear.org/forums/viewtopic.php?f=6t=15754start=15#p153739 It's currently done with an ufo FDM, but the basic structure is all there, i.e. it loads into Flightgear and just needs the FDM inserted and possibly some controls/instruments to monitor ascent. So - it seems you could try it rather quickly :-) I'm a new guy and I have to chime in on this our team wants to use FG for simulations to orbit because we are actually trying to be the first amateurs to make orbit and we would like to do HIL testing. FG may be our only hope. If there is something I can do to help please direct me. Possibilities are endless - but quite possibly you'd like to do your own spacecraft at some point anyway, so I would suggest you study Vostok, fix it's issues (like the sound file problems) in the process so that you know how a multi-stage spacecraft model is done, then start making some other craft flight ready, and/or possibly start designing your own. Using textures rendered from the scenery also allows to create intermediate steps at a higher resolution. Ultimately it should be possible to transition between the scenery derived texture and the blue marble texture by generating intermediate stages, if not by cross-fading them through a shader. Incidentally, some sort of cross-fading shader would also be very useful to handle the day/night transition zones, that should be quite evident when orbiting the planet several times each day. If anyone knows how to render textures from scenery, please do so - I don't know how to do it. Btw - we don't need any day-nigh transitions - the fact that Earthview uses a real sphere means that the sphere is actually illuminated correctly given the sun angle, the sun angle is determined by your real position, and so if the earthsphere is set to zero ambient reflection it gets you a rather credible day-night transition for free. Combined with the atmosphere light generated by the skydome shader which persists even after earth is dark, this looks really pretty :-) * Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Skydome shader rendering artefact
On Thu, 2012-03-22 at 07:53 +, Renk Thorsten wrote: Anyway, that's my best suspicion at this point, that in the artefact region we really see through a crack in the skydome into whatever is rendered beyond, and that trigonometry doesn't interpolate properly across the crack. So, I would recommend to have a look at the skydome vertex structure, although I have no idea where that resides. This sounds suspiciously as an alpha coloring problem. Could you double check that color.z (or color.a) is always 1.0 for the skydome in the shader? Erik -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Skydome shader rendering artefact
On Thu, Mar 22, 2012 at 3:28 AM, Erik Hofman wrote: On Thu, 2012-03-22 at 07:53 +, Renk Thorsten wrote: Anyway, that's my best suspicion at this point, that in the artefact region we really see through a crack in the skydome into whatever is rendered beyond, and that trigonometry doesn't interpolate properly across the crack. So, I would recommend to have a look at the skydome vertex structure, although I have no idea where that resides. This sounds suspiciously as an alpha coloring problem. Could you double check that color.z (or color.a) is always 1.0 for the skydome in the shader? This is a rendering glitch that has bugged me for a long time -- I didn't get anywhere with it when I dug into the skydome code myself, but I'd love to see this one figured out! Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear and Simgear multiple format string vulnerabilities
Hi, I agree with Olaf. Both format strings and buffer overflow in Rotor.cpp could allow user-assisted remote attackers to execute arbitrary code, if flightgear's users download material (aircraft, airports, etc) from an untrusted web page or even an e-mail. Take a look of a vulnerability I found before which is very similar: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4620 No to mention the buffer overflow in SGSocketUDP (simgear) which could be exploitable by networks packets, without user assistance. Something important to note is that not every sprintf is vulnerable, so there is no need to change them all, but just those which are vulnerable. Also It is true that flightgear is supposed to run in user's context but very often user and administrative context are used as the same, specially in windows. Anyway always can exist a way to scale privileges ;) Here an example of format string exploitation and privilege escalation: http://www.vnsecurity.net/2012/02/exploiting-sudo-format-string-vunerability/ Regards. Andres Gomez 2012/3/20 Olaf Flebbe f...@oflebbe.de Hi Torsten, I am quite sure Flightgear has remote exploitable bugs. Think about social attack vectors like custom sceneries, special interest aircraft models. And the multiplayer protocol, or the httpd server Running malicious code in user context is bad enough... Olaf This is low priority, because the possible code injection can only happen by the user itself and usually not over the (inter)net. And FlightGear is supposed to run in the user's context which should add some extra safety. (Never run fgfs as root or Administrator!) -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- -- AVISO DE CONFIDENCIALIDAD: Esta transmisión se entiende para uso del destinatario o la entidad a la que va dirigida y puede contener información confidencial o protegida por la ley. Si el lector de este mensaje no fuera el destinatario, considérese por este medio informado que la retención, difusión, o copia de este correo electrónico está estrictamente prohibida. Si recibe este mensaje por error, por favor notifique inmediatamente al emisor y destruya el original. Gracias -- CONFIDENTIALITY NOTICE: This transmission is intended for the use of the individual or entity to which it is addressed, and it may contain information that is confidential or privileged under law. If the reader of this message is not the intended recipient, you are hereby notified that retention, dissemination, distribution or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please notify the sender immediately and destroy the original. Thank you. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
