[Flightgear-devel] Ideas for terrain shader structure in 3.0
Since we usually don't have roadmaps and things, I thought I might try to put this up for discussion early on. I've been experimenting with a partially procedural texturing approach, and I think this is the way to go forward, the outcome looks very convincing. My experiments are coded within the atmospheric scattering framework, but do not require it, and since all code is the fragment shader, it'd be straightforward to port things also to the default rendering scheme or to Rembrandt, if so desired. After some thinking, it seems easiest to me to organize the terrain shading scheme in such a way that one default shader handles most of the visible terrain and the exceptions are declared as effects. My current implementation works for pretty much all natural solid landclasses (forest, rock, glacier, shrub, tundra, lava, sand,...). These can get: * always snowcover above some altitude * always user-defined dust cover * always user-defined wetness (I haven't implemented that one though, I'm not quite sure yet what's the best way) * hopefully cloud shadows (the only thing I don't know is at which point to generate the texture - I know the algorithm, and I know how to shade the terrain once I have the information as a texture, but I don't know how to turn the algorithm into a texture) * if declared in materials.xml, an overlay alternative texture which appears with a probability modified by the terrain gradient (that's similar to the existing transition effects, so the alternative texture should represent the terrain most likely to appear on steeper slopes - for instance I pair herbtundra with rock, but shrubcover with dirt). If nothing is declared in materials.xml, the shader automatically skips the operation * if declared in materials.xml, a detailed hires overlay texture is additionally used, with probability dependent on distance to the pixel, so nearby terrain is always shown biased towards high resolution texture cover * superimposed for distances 2000 m is a height map created from tile-less noise at the 5 and 10 m scale, going into parallax and normal mapping for the detail overlay texture To me, this scheme has the advantage over the existing transition effects that it doesn't have to declare a separate effect for each combination of texture/overlay texture - (i.e. I don't need 'base-grass' separate from 'base-rock'), so the majority of the terrain gets treated as it should, and the exceptions need to be dealt with separatrely. The exceptions are man-influenced terrain (agriculture, town, city, airport,...) which isn't characterized by randomness the same way as natural terrain and water (for which reflection and normals need to be treated differently). Currently, if these landclasses do not have their own effects, they get snow, dust (and wetness) but no overlay textures or height maps. My idea would be to treat those by suitable effects (which we partially have, partially not) - for instance runways should not be snow-covered, city should at best be partially snow-covered, water might get ice before it gets snow-covered but should never get dust, and in these effects the existing work on wet runway, urban relief shader, you name it should be incorporated. I'm not sure at this point what to do with agriculture. Large fields have a really bad tiling problem, and variants of the crop shader technique (which I haven't studied yet) might address this. But this would completely screw the object placement masks which require the underlying texture to be fixed rather than dynamically generated. So this should be discussed, it isn't appealing to get some terrain down to 10 cm resolution and other terrain at 2 m, but I like the placement masks very much. It'd be really cool to be able to specify a few more parameters in materials.xml to be passed as uniforms - for instance we could then generate custom heightmaps for the terrain rather than hard-coded ones. Since I use tiling-less noise functions, we could easily get a 1cm scale heightmap for runway textures for instance, and we could give sand dunes same larger wavelength noises than rock. So to summarize, the structure I am proposing: * natural terrain uses a default terrain ubershader which does all the common effects (snow, dust, patchy fog,...) based on selected detail level and optional transition effects and heightmaps * materials.xml contains the relevant information (overlay textures, heightmap parameters,...) * terrain which doesn't fit into the ubsershader is treated declaring special effects which make use of other shaders, running existing work (urban relief, wet runway,...) and leave out inappropriate effects (no dust effect for water, no snow effect for runways and towns,...) * landclass texturing is separable from scene light computations and fogging, thus I think it should be straightforward to generalize and port the relevant bits * since I propose to code the
[Flightgear-devel] Patch for metar.exe for windows
Hi,
For a long, LONG time the small utility program
metar.exe has failed to work in windows...
It turns out WSAStartup() is NOT called, thus the
HTTP request always fails...
Applied this simple patch below, and all is
well ;=))
Hope this can get into fg git, and I hope pushed
to Release/2.8.0 as well, and thus get into
the next fgrun release 2.8 windows install...
Regards,
Geoff.
metar.patch
diff --git a/src/Main/metar_main.cxx b/src/Main/metar_main.cxx
index 7b904d3..833ac2e 100644
--- a/src/Main/metar_main.cxx
+++ b/src/Main/metar_main.cxx
@@ -533,6 +533,45 @@ void usage()
);
}
+static bool doneNetInit = false;
+static void netExit(void)
+{
+if (doneNetInit)
+{
+#ifdef WIN32
+ /* Clean up windows networking */
+ if ( WSACleanup() == SOCKET_ERROR ) {
+ if ( WSAGetLastError() == WSAEINPROGRESS ) {
+ WSACancelBlockingCall();
+ WSACleanup();
+ }
+ }
+#endif // WIN32
+doneNetInit = false;
+}
+}
+
+static int netInit(void)
+{
+int iret = 0;
+if (!doneNetInit)
+{
+#ifdef WIN32
+ /* Start up the windows networking */
+ WORD version_wanted = MAKEWORD(1,1);
+ WSADATA wsaData;
+if ( WSAStartup(version_wanted, wsaData) != 0 ) {
+ printf(Couldn't initialize Winsock 1.1\n);
+ iret = 1;
+}
+#endif // WIN32
+doneNetInit = true;
+atexit( netExit );
+}
+return iret;
+}
+
+
int main(int argc, char *argv[])
{
bool report = true;
@@ -544,6 +583,8 @@ int main(int argc, char *argv[])
return 0;
}
+if (netInit())
+return 1;
string proxy_host, proxy_port;
getproxy(proxy_host, proxy_port);
@@ -574,6 +615,9 @@ int main(int argc, char *argv[])
}
try {
+if (verbose)
+ printf(Getting metar for [%s]\n,argv[i]);
+
MetarRequest* mr = new MetarRequest(argv[i]);
HTTP::Request_ptr own(mr);
http.makeRequest(mr);
/metar.patch
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for metar.exe for windows
On 27 Jul 2012, at 16:37, Geoff McLane wrote: For a long, LONG time the small utility program metar.exe has failed to work in windows... It turns out WSAStartup() is NOT called, thus the HTTP request always fails... Applied this simple patch below, and all is well ;=)) Hope this can get into fg git, and I hope pushed to Release/2.8.0 as well, and thus get into the next fgrun release 2.8 windows install... There's an even simpler fix: call: int simgear::Socket::initSockets() Which does whatever platform-specific socket initialisation is required. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for metar.exe for windows
On Fri, 2012-07-27 at 17:39 +0100, James Turner wrote: On 27 Jul 2012, at 16:37, Geoff McLane wrote: For a long, LONG time the small utility program metar.exe has failed to work in windows... It turns out WSAStartup() is NOT called, thus the HTTP request always fails... Applied this simple patch below, and all is well ;=)) Hope this can get into fg git, and I hope pushed to Release/2.8.0 as well, and thus get into the next fgrun release 2.8 windows install... There's an even simpler fix: call: int simgear::Socket::initSockets() Which does whatever platform-specific socket initialisation is required. James Hi James, Just as my patch does... SAME code except for the throw sg_exception() ;=)) So 6 to one, and half dozen to the other... Just hope one of them gets pushed ;=)) Regards, Geoff. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for metar.exe for windows
Geoff, your patch is asking for the quirky old win95-era winsock1.1. Is this intentional? WSACancelBlockingCall and friends don't exist in modern winsock. -- Chris On Sat, Jul 28, 2012 at 5:03 AM, Geoff McLane ubu...@geoffair.info wrote: On Fri, 2012-07-27 at 17:39 +0100, James Turner wrote: On 27 Jul 2012, at 16:37, Geoff McLane wrote: For a long, LONG time the small utility program metar.exe has failed to work in windows... It turns out WSAStartup() is NOT called, thus the HTTP request always fails... Applied this simple patch below, and all is well ;=)) Hope this can get into fg git, and I hope pushed to Release/2.8.0 as well, and thus get into the next fgrun release 2.8 windows install... There's an even simpler fix: call: int simgear::Socket::initSockets() Which does whatever platform-specific socket initialisation is required. James Hi James, Just as my patch does... SAME code except for the throw sg_exception() ;=)) So 6 to one, and half dozen to the other... Just hope one of them gets pushed ;=)) Regards, Geoff. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
