> -----Original Message----- > From: Stuart Buchanan [mailto:stuar...@gmail.com] > Sent: 30 July 2012 09:35 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Ideas for terrain shader structure in 3.0 > > On Fri, Jul 27, 2012 at 8:43 AM, Renk Thorsten wrote: > > > > 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. > > I'm all for the idea of having a single terrain "uber-shader", as at present we > have too much of a mish-mash of effects. If we do down this route, I think > we really need buy-in from all the people modifying materials to ensure that > we apply it to the full set of material definitions and clean up the unused > effects that at then replaced. I think that is you, me, Vivian, Emillian and Fred > (urban shader). Anyone else? > > I think the current approach of the uber-shader-deferred is a good one, the > base effect defines everything, and specializations of the effects can switch > individual features on/off. > > > 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. > > I'm very keen on the placement maps myself, but they are fundamentally > incompatible with the crop shader, as the placement information is required > well above the shader layer. > > > 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. > > I can do this fairly easily. As mentioned previously, I think I'd want to handle > this as a generic framework allowing properties to be defined in the > materials.xml file that are then passed through to the effects and can be > used in the parameters section. >
I'll certainly do what I can to help this one along. However, I'm not clear how this all ties in with the Rembrandt project. Are we in danger of having to tear it all down and starting over? I, too, am a fan of the placement masks: they have made a significant improvement in the realism of our scenery. On the other hand, I have long since abandoned using the crop shader. Let me know what it is you think we need. Vivian ------------------------------------------------------------------------------ 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
