On Thu, Aug 4, 2011 at 12:51 PM, Thorsten Renk wrote: >> We should change the maximum to whatever you feel is sensible >> (40km?), and leave the default as it is (20km). > > I think my current maximum is 45 km, and for much more one needs a > different tile structure anyway, so if we could get 45 km that'd be nice.
I've made the small GUI dialog change required to allow users to get this up to 45km. >> However, I'm not sure we want to be over-riding the user's explicit >> preferences here. > > I can turn it around and use the value specified here for the cloud > visible range of the old system - if that's not too confusing. I'm not quite sure what you mean, but certainly I think using a single visibility range property is a good idea. >> Perhaps we should look at integrating your routine to match a given >> fps value by adjusting cloud visibility range? > > Do we all agree that it makes sense to use cloud visibility range here, > rather than random objects or such like? The advantage of using the cloud visibility range (and tree visibility range if I were to make it similarly dynamic) is that the effect of a change should be fairly subtle. Suddenly disabling (say) the urban shader will have quite a significant visual impact to the user. This probably needs a bit more thought. I'm also looking at ways to speed up the 3d clouds further by not rendering sprites at the back of the cloud (using the currently defunct cloud-density slider). The way this should be solved would be to generate Impostors of clouds where the view direction isn't changing much. Unfortunately the OSG implementation is Impostors doesn't work, and this is probably a lot of work. >> Yes, that's something I need to do. I think you've already implemented >> this in >> your codes. Can you point me at the best example shader/Effect? > > It's actually quite simple. You have: > > // Do the matrix multiplication by [ u r w pos]. Assume no > // scaling in the homogeneous component of pos. > gl_Position = vec4(0.0, 0.0, 0.0, 1.0); > gl_Position.xyz = gl_Vertex.x * u; > gl_Position.xyz += gl_Vertex.y * r * wScale; > gl_Position.xyz += gl_Vertex.z * w * hScale; > gl_Position.xyz += gl_Color.xyz; > > and I add just after that block > > gl_Position.z = gl_Position.z * zScale; > > (look into clouds-layered.vert where a value of 0.4 is hard-coded there). This is also now down (thanks to Torsten D. for the very fast merge). We now support a <z-scale> value which takes a value from 0.0 to 1.0. Default is 1.0. >> Great. Let me know what else you need and I'll put it near the top of my >> FG todo list. > > Wow :-) Thanks a lot! I think wrapping off and z-scaling are what limits > my experiments most - otherwise I simply need time to catch up with > texturing, parameter tuning, performance tests, but I'll keep you posted. Switching wrapping off is also supported, as of this morning. It is a global boolean property - /sim/rendering/clouds3d-wrap. It defaults to "true". I haven't yet put any logic in to switch it on when global weather is enabled, so you'll need too manage it actively within Local Weather for the moment. That combined with Mathias' fantastic work to improve the speed of alt/mat checks via geodinfo() should mean you've got all you need. -Stuart ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
