Re: [Flightgear-devel] Aircraft modellers - is a grain texture useful?
Okay, I've pushed an experimental version of a grain overlay texture for the model ubershader to FGData. It affects Atmospheric Light Scattering only, i.e. will be absent in the default rendering, which should make for easy comparison. For lack of texture units, I had to take the rainbow coloring of reflections out for the moment (again, only in the Atmosperic Light Scattering version). I can't visually spot a difference, and in any case a 2d texture lookup call seems an overkill for a simple 1d color table, so I plan to replace that by a function eventually. As far as I can see and test, this shouldn't take any framerate unless used. The grain overlay is configured pretty much like any other model effect in the ubershader - a model specific effect file needs to set the flags, which are * grain-texture-enabled: does what you think it does, needs to be 1 to work * grain-magnification : the texture magnification relative to the base texture - I think values between 10 and 100 would work here The grain texture itself needs to be declared as n=14. The grain texture should be largely transparent and seamless - I think unlike for the terrain tiling artefacts are not an issue for artificial patterns, they actually occur. For a quick check, inserting the following xml code into Aircraft/Citation-Bravo/Models/Effects/reflect.eff texture n=14 imageTextures.high/Terrain/grain_texture.png/image filterlinear-mipmap-linear/filter wrap-srepeat/wrap-s wrap-trepeat/wrap-t internal-formatnormalized/internal-format /texture grain-texture-enabled1/grain-texture-enabled grain-magnification50/grain-magnification gives me this effect for the hull of the Bravo which is now re-painted using the terrain grain texture at high resolution http://users.jyu.fi/~trenk/pics/overlay.jpg Looks a bit like a military version... So, please play with it - it's basically down to how well the grain overlay can be made. * 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
[Flightgear-devel] DDS warning message
Hi all, Following a discussion with Vivian on IRC, it seems it was decided to remove the DDS warning message some weeks? months? years? ago. Someone could handle it ? I admit that using DDS materials and DDS aircrafts results in a thousand of warining messages in my console and it's really not easy to debug my Nasal code ( print(); ) with all these messages. Also I'm not convinced that our users are interested by this warning message because they can't do anything to solve it. (Considering that decompressing a DDS file is not a basic user action) Thanks you in advance, Cheers, Clément -- 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] Aircraft modellers - is a grain texture useful?
Thorsten Okay, I've pushed an experimental version of a grain overlay texture for the model ubershader to FGData. It affects Atmospheric Light Scattering only, i.e. will be absent in the default rendering, which should make for easy comparison. For lack of texture units, I had to take the rainbow coloring of reflections out for the moment (again, only in the Atmosperic Light Scattering version). I can't visually spot a difference, and in any case a 2d texture lookup call seems an overkill for a simple 1d color table, so I plan to replace that by a function eventually. As far as I can see and test, this shouldn't take any framerate unless used. The grain overlay is configured pretty much like any other model effect in the ubershader - a model specific effect file needs to set the flags, which are * grain-texture-enabled: does what you think it does, needs to be 1 to work * grain-magnification : the texture magnification relative to the base texture - I think values between 10 and 100 would work here The grain texture itself needs to be declared as n=14. The grain texture should be largely transparent and seamless - I think unlike for the terrain tiling artefacts are not an issue for artificial patterns, they actually occur. For a quick check, inserting the following xml code into Aircraft/Citation- Bravo/Models/Effects/reflect.eff texture n=14 imageTextures.high/Terrain/grain_texture.png/image filterlinear-mipmap-linear/filter wrap-srepeat/wrap-s wrap-trepeat/wrap-t internal-formatnormalized/internal-format /texture grain-texture-enabled1/grain-texture-enabled grain-magnification50/grain-magnification gives me this effect for the hull of the Bravo which is now re-painted using the terrain grain texture at high resolution http://users.jyu.fi/~trenk/pics/overlay.jpg Looks a bit like a military version... So, please play with it - it's basically down to how well the grain overlay can be made. Removing the rainbow effect spoils the highly polished aluminium effect on the b29 and the Lightning F1. It is also incompatible with AO effects. Will this all work with non-nVidia cards/drivers? The grain effect you proposed did not gain much if any support from developers. Do we need to go down this road? We are breaking more and more for minimal gains. Did we ever restore the wake effect on the Carrier with Atmospheric Light Scattering? I think something like the grain effect can already be achieved with the nmap tiling facility in the existing ubershader. Vivian -- 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] Aircraft modellers - is a grain texture useful?
I think that a better approach would be to allow multiple UV layers and textures (and texture modes, like decals) on the model format. I understand that right now FGFS only relies on the native AC3D loader, though AC3D is not the only 3D format supported by OSG by any means. But there's no reason why alternate lists of UV coordinates and textures could not be supplied along with the basic mesh. The cleanest implementation would use a FGFS native model format, but there's plenty of possible solutions, like a list of vertex indexes along with the corresponding UV coordinates and material definition to integrate the basic AC3D mesh, or several copies of the mesh with matching geometry and differing materials... I suspect that OSG is not being used to its full potential. Alessandro From: vivian.mea...@lineone.net To: flightgear-devel@lists.sourceforge.net Date: Mon, 22 Apr 2013 13:34:36 +0100 Subject: Re: [Flightgear-devel] Aircraft modellers - is a grain texture useful? Thorsten Okay, I've pushed an experimental version of a grain overlay texture for the model ubershader to FGData. It affects Atmospheric Light Scattering only, i.e. will be absent in the default rendering, which should make for easy comparison. For lack of texture units, I had to take the rainbow coloring of reflections out for the moment (again, only in the Atmosperic Light Scattering version). I can't visually spot a difference, and in any case a 2d texture lookup call seems an overkill for a simple 1d color table, so I plan to replace that by a function eventually. As far as I can see and test, this shouldn't take any framerate unless used. The grain overlay is configured pretty much like any other model effect in the ubershader - a model specific effect file needs to set the flags, which are * grain-texture-enabled: does what you think it does, needs to be 1 to work * grain-magnification : the texture magnification relative to the base texture - I think values between 10 and 100 would work here The grain texture itself needs to be declared as n=14. The grain texture should be largely transparent and seamless - I think unlike for the terrain tiling artefacts are not an issue for artificial patterns, they actually occur. For a quick check, inserting the following xml code into Aircraft/Citation- Bravo/Models/Effects/reflect.eff texture n=14 imageTextures.high/Terrain/grain_texture.png/image filterlinear-mipmap-linear/filter wrap-srepeat/wrap-s wrap-trepeat/wrap-t internal-formatnormalized/internal-format /texture grain-texture-enabled1/grain-texture-enabled grain-magnification50/grain-magnification gives me this effect for the hull of the Bravo which is now re-painted using the terrain grain texture at high resolution http://users.jyu.fi/~trenk/pics/overlay.jpg Looks a bit like a military version... So, please play with it - it's basically down to how well the grain overlay can be made. Removing the rainbow effect spoils the highly polished aluminium effect on the b29 and the Lightning F1. It is also incompatible with AO effects. Will this all work with non-nVidia cards/drivers? The grain effect you proposed did not gain much if any support from developers. Do we need to go down this road? We are breaking more and more for minimal gains. Did we ever restore the wake effect on the Carrier with Atmospheric Light Scattering? I think something like the grain effect can already be achieved with the nmap tiling facility in the existing ubershader. Vivian -- 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 -- 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] multiplay refuel test
Hi, NOTAM: Refueling CLOSED, temporarily at least... Ok, have finished for now my refueling sorties. As I put in the chat after one pilot reported holding a position for refueling can be quite tiring - Yes, so can even watching it ;=)) It all certainly confirmed that some FG code changes are needed to make this experience viable... like removing, or reducing the rubber-band effect, and compensating for lag which makes the view from the tanker different to the view from the aircraft. Additionally, there is NO collision detection code between the aircraft and the mp derived models, so this means even when you get the probe into the basket, if you push forward a few more feet, and the basket/drogue will enter your cockpit ;=)) But I had lots of fun, and I hope the others that joined me did also ;=)) As to the virtual bottle of red wine, I think that must go to callsign jano, who held steady very close, or touching! proximity for the longest period of time in the lightning (jsb). http://www.flightgear.org/forums/viewtopic.php?f=19t=19756#p181737 I chose a Chateau Petrus 1982, and the 'virtual' bottle is here - http://en.wikipedia.org/wiki/File:Petrus1982.jpg It is under a GFLD licence, which I understand is GPL compatible ;=)) jano later tried to repeat the feat in an f-14b (yasim), but while holding a similar relatively close position, the aircraft always looked quite 'jumpy'... maybe something to do with the different FDM? An honorable mention must go to F-JJTH who posted an image with the probe in the basket, followed by one with the basket in the cockpit ;=)) http://www.flightgear.org/forums/viewtopic.php?f=19t=19756#p181749 As per some others if you scroll down... I have now put up a page on my site with the images I took - http://geoffair.org/fg/mp I left all the images at full screen shot size, so they can take a little time to download... But a BIG thank you to ALL who came along for the ride... As stated, it was great, if not exhausting!, FUN! Regards, Geoff. -- 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] [Jsbsim-devel] wind vs body axes
This has important implications for Datcom /JSBSim users, as Datcom output is in stability axes. It will also apply to FDM´s built from other data that was supplied in stability axis form. It is only significant for aircraft which are able to fly at high incidence – typically delta wing types. At low angles of attack the difference between the two axes systems is small, and can often be neglected. To convert derivatives from stability axis (as output by Datcom) to body axis (as needed by JSBSim) the equations given in table 8 of FDL-TDR-64-70 http://contrails.iit.edu/DigitalCollection/1964/FDLTDR64-070.pdf may be used. This report was intended to have been part of the Datcom compendium. JSBSim allows the user to select body or stability axes for the linear axes (i.e. lift or Z, drag or X), but has no such option for the roll and yaw axes. It is only necessary to do this conversion for the lateral derivatives. I have taken the unusual step of cross posting this to JSBSim, Datcom ad Flightgear developers lists as it is equally important to all three. Replies would be best kept to the JSBSim list if possible. Alan From: Jon S. Berndt Sent: Monday, April 22, 2013 4:43 AM To: JSBSim Developer List Subject: Re: [Jsbsim-devel] wind vs body axes Alan, Yes, JSBSim assumes rotational coefficients are expressed in body frame. Jon - Reply message - From: Alan Teeder ajtee...@v-twin.org.uk To: Development issues jsbsim-de...@lists.sourceforge.net Subject: [Jsbsim-devel] wind vs body axes Date: Sun, Apr 21, 2013 3:00 PM I have just done a rather unscientific test in which I set up a simplified flight case from my unflyable stability axis simulation into one with lateral derivatives expressed in body axes. The result is flyable at all incidences. Could someone please confirm that JSBSim indeed uses body axes for roll and yaw. -- 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] ATIScreenSizeHack() in main.cxx
Recently I noticed an alert on my console when starting up the git version
of FlightGear:
Enabling ATI viewport hack
This is odd because I have nvidia hardware. I tracked down that this
message was coming from main.cxx, specifically this chuck of code:
if (fgGetBool(/sim/ati-viewport-hack, true)) {
SG_LOG(SG_GENERAL, SG_ALERT, Enabling ATI viewport hack);
ATIScreenSizeHack();
}
This takes the value of /sim/ati-viewport-hack or true if the value is not
set at all (like on my nvidia based system.) Shouldn't this default to a
false value? I can change the default in git unless someone has a specific
reason why it should be the other way? Any objections to defaulting this
to 'false'? (I think this is James code from 'git blame')
Thanks,
Curt.
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
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] ATIScreenSizeHack() in main.cxx
Hi Curt, Shouldn't this default to a false value? this is enabled by default, because it seemeds to have no effect on NVidia hardware, but a big positive effect on ATI. You may remember seeing lots of reports about quarter screen size issues. The warning could be moved to a lower loglevel or removed all together, as it seems to have no negative side-effects on NVidia indeed. Cheers, Gijs -- 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] Aircraft modellers - is a grain texture useful?
Removing the rainbow effect spoils the highly polished aluminium effect on the b29 and the Lightning F1. As I said, I don't plan to remove it for good. Quoting myself: in any case a 2d texture lookup call seems an overkill for a simple 1d color table, so I plan to replace that by a function eventually I might add 'this will make it quite a bit faster, as it is a very simple function' - so I believe this should be done anyway everywhere the rainbow is used. I am working hard, but don't expect everything to be 100% on the first commit of a new feature. It is also incompatible with AO effects. Will this all work with non-nVidia cards/drivers? I believe I've seen screenshots of terrain overlay textures working just fine on ATI cards. Likewise, functions rather than texture lookups work just fine - what counts in the end is a number, the shader doesn't really care if this is calculated or read from texture. The four websites I have studied regarding conditional texture lookups agree that textures can be looked up conditionally on a uniform, not on a varying. Do you see actual reasons for concern, or is this just stabbing in the dark? Not sure why a grain overlay would be incompatible with AO - care to elaborate? My understanding is that we don't have any AO outside of Rembrandt, and a grain would not be intended to carry pre-computed shadows, that's what the base texture is for. The grain effect you proposed did not gain much if any support from developers. Do we need to go down this road? No, we don't have to. Like many things, overlay textures and the grain effect are just something I believe have incredible potential. The grain effect on terrain is awesome - without going dds or using huge textures, you can create 15 cm sized terrain resolution everywhere. So, let's give it a few months of testing, see if folks can not use it to good effect - the 5 lines are easily removed from the shader if the potential doesn't materialize. We are breaking more and more for minimal gains. I beg to disagree on two counts. First of all, this is a net acceleration. I think currently the ubershader isn't structured well since it unconditionally looks up lots of textures, most of which aren't needed if you use, say, reflection or normal map only - restructuring the shader to not read unused textures and to evaluate as function what can be evaluated as simple function will speed things up. Second, having a technique to achieve 25 times the resolution for 2 times the texture memory isn't a minimal gain. It's visually way more powerful than the rainbow. So we're actually getting more bang for the buck. Did we ever restore the wake effect on the Carrier with Atmospheric Light Scattering? Well, we never had it running in the first place, so there can be no talk about restoring it. Someone just has to write it. Presumably that someone will eventually be me, but I have to ask your forgiveness of I priorize things which interest me personally. I mean, it's not like there's something taken away from you... There's two rendering frameworks left in which everything works as you're used to, surely we can afford to have one of three going ahead and trying for a few experimental new features rather than re-doing every effect in the others? Cheers, * 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
