Stuart > From: Buchanan [mailto:stuar...@gmail.com] > Sent: 08 May 2013 10:56 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] 2.10.1 > > On Fri, May 3, 2013 at 6:15 PM, Vivian Meazza wrote: > > I re-installed the Jenkins nightly Win build from yesterday - seems > > OK, although I have NOT done any extensive testing. I'm seeing regular > > crashes here from ALS and Rembrandt, but that's nothing new. I'm > > getting a number of errors on start-up; they seem harmless: > > > > Failed to create alias at > > /controls[0]/refuelling[0]/refuelling-drogues-pos-norm > > > > [0]. Source /sim[0]/multiplay[0]/generic[0]/float[2] is already > > aliasing another > > > > property. > > > > Failed to set alias to > > /controls/refuelling/refuelling-drogues-pos-norm > > FYI, I don't think this is related to the AAR work I've done recently, and looks > like it might be aircraft specific. What aircraft are you seeing this with? > > > > I would be more concerned over the state of the data. The reinstall > > has partly solved the Screenshot directory issue - it now uses the > > default Working Directory, but the gui input is still stuck. We have a > > small glitch with Stuart's latest iteration of the Random Vegetation > > (aka trees) with what I think is probably a mipmapping issue. > > I thought 2.10.1 data would be taken from 2.10.0, with commits cherry- > picked? > > If not, I'd suggest backing out that commit from the 2.10.1 data branch, as it > has a co-requisite simgear change, and as Vivian mentions still has some > issues. > > I've been away for the last 5 days so haven't had the chance to look into the > tree problem further, but have a couple of ideas. One option would be to > "mirror" the texture rows, so instead of looking like this: > > ^^^^^^^ > ^^^^^^^ > ^^^^^^^ > ^^^^^^^ > > It would be top-to-top and base-to-base: > > vvvvvvvv > ^^^^^^^^^ > vvvvvvvv > ^^^^^^^^ > > That way is the mipmap UV isn't quite accurate, it would just include the > tree-top of the texture above, rather than the base. This would certainly be > less noticeable. The downside is that I think it would require adding an if() > test to the vertex shader, something I've been avoiding due to (unfounded?) > concerns about performance. > > Or I might simply change the textures to a (very) long strip, so instead of > 512x128 it would be 2048x128. However that feels rather clunky, and might > not make good use of GPU memory. Anyone with GPU experience care to > comment? >
General advice that I can find is that GLSL is designed as a linear program: conditionals and loops are best avoided: http://stackoverflow.com/questions/2614622/tips-for-efficient-glsl-code Here's some stuff on textures. http://www.arcsynthesis.org/gltut/Texturing/Tutorial%2014.html I don't think the shape matters as much as the overall size. As I understand it, GLSL optimizes the storage. In this case new the texture would be 4 times as big. I don't think that's optimal, but on the other hand, it's not pushing the envelope. Do you use a shader analyser? I use the AMD one: http://developer.amd.com/tools-and-sdks/graphics-development/gpu-shaderanaly zer/ might help to decide which route to take HTH Vivian ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
