> Which is very unfortunate, since in the common case it would allow a > huge amount of tile/terrain pixels to be dumped. Could we use a buffer > copying to trick to initialise a stencil plane on the far camera based > on the near-camera Z-buffer? > > I've no idea what the penalty of a z-buffer read and stencil buffer > write on the two camera would look like, but my impression is 'out of > the window' pixels are waaaay more expensive in terms of shaders and fog > / distance effects than in-cockpit pixels.
In my shading schemes, in-cockpit is much faster because no fogging is computed at all. I have a simple trick in mind which doesn't work automatically but might get most of the desired effect for really cheap: * for the default view in the cockpit, measure the angular range that is covered by the panel/cockpit and cast that into simple theta/phi limits * these are stored with the plane xml * I think current view axis and FOV are even somewhere in the tree, so a simple property rule could transform these limits into eye space on the application level when cockpit view is chosen * the limits in eye space are then passed as uniforms to the fragment shader * the terrain fragment shader then discards any pixels in the exclusion region (all the really expensive fragment shaders I know get vertex position passed anyway, so computing an angle isn't a problem) Would need to be solved on a per-plane basis... but can simply be left out for complicated cockpit geometries. >> That's a different issue. Earth centric coordinates can't be stored in >> single precision floating point at the required precision, so each >> tile has a local coordinate system. A "world wide" noise basis would >> be a good project. > Right, we need distinct coordinates per tile I'm afraid, no working > around that. Working around it isn't so difficult, just ugly. I'm using the same trick to get around discontinuities in altitude to ensure the snow level doesn't jump across tile boundaries. * define the aircraft starting position as (0,0,0) * compute the relative position vector to this in each frame * pass this vector as uniform to the shader, this is absolute aircraft position * then queary the noise texture not with the position in tile coordinates but with (vertex_pos - eye_pos) + absolute_pos -> that is a continuous function, since it's supposed to make noise accuracy isn't as big an issue as absence of discontinuities I thought maybe there's a better way of doing it, but if it's complicated, I think two uniforms are okay as a pricetag. Well, probably isn't the default way of addressing the problem... * Thorsten ------------------------------------------------------------------------------ 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
