On Thu, Aug 11, 2011 at 9:29 AM, Thorsten Renk wrote: > > Some progress and minor issues: > > I am in the process of redoing textures and cloud definitions for Cu > layers (the toughest nut), about halfway through converting all available > cloud types. > > I have implemented tested tile management functionality (automatic > building and removing clouds) and it seems to be working fine. The new > geodinfo() works great - many thanks for that! - it speeds up the system > considerably. > > Not to the point that all could be done in a single frame without > generating a noticeable delay, so I'll have to write some routines to > split it over maybe 10-20 frames (much better than 30 seconds though).
That should be < 1 second for most systems, so that's great. Does that just cover the elevation queries or generating the full model? If so, then I wonder if we can look at hiding the stop/start function from the end user. I think that would help the UI, and hopefully allow us to move towards my "holy grail" of a single (simple) UI for both global and local weather. > I've noticed that 3dcloud.vert contains the line > > fogFactor = exp( -gl_Fog.density * fogCoord * 0.5); > > which tends to fade distant clouds to transparent dependent on visibility > range. I find the visual impression better if the 0.5 is changed to a > lower value, say 0.3 or even 0.2. Is there a reason to keep it at 0.5, or > could we lower it? I suspect the 0.5 factor was copied straight from the 3D forest shader I wrote. I'll have a look and see what impact changing it has. I'd prefer not to make it configurable. We've seen some problems on older system where we exceed the number of registers available to the shaders for input, so I'd like to avoid adding any more if possible. > Also, at one point Stuart told me that the y-position of a texture on the > texture sheet is correlated with the position the sprite gets in the cloud > - is this something I should be aware of? For some cloud types, this may > be useful, but for others it makes no sense. In particular the Congestus > type images are much broader than high, so they are arranged in a 1x3 > pattern on the sheet, but I don't really want the same texture to always > form the cloud top. Yes, the sprite is selected from the sheet randomly on the x-axis and based on it's height in the cloud on the y-axis for precisely this reason. The behaviour isn't switchable at present though it could be. For the relatively small texture sheets I used in the default 3D clouds, I simply duplicated the textures, so you'd have a 2x6 or 3x9 sheet. Given that cloud performance is effectively limited by sprite resolution and coverage rather than texture sheet size, that might be OK. Otherwise I can add a switch fairly easily. Let me know if you want me to do so. > In any case - I take the opportunity to say thanks for all the help - I > think the system is moving a big step forward right now. No problem. Great to help. -Stuart ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
