Sure - would you like a guess where my shader code largely comes from? :-) But there are limits:
I asked before doing any work if the existing system can be used to get me a cloud to a predefined location - Stuart's answer was a clear 'no', and since I wanted to have precisely that capability, I had to write the whole control structure myself. Since all you can control from Nasal are ac models, the system is now based on those. Which has the added benefit that one can stack textures in a pre-defined configuration, i.e. always use a diffuse small one above a structured opaque one, or that cloudlet textures don't have to fit on a m x n grid but can retain as much detail as I can extract. > What could we do to integrate your work with that system? I've made a fairly lengthy writeup of what I would see as useful and what properties I use here: http://wiki.flightgear.org/index.php/A_local_weather_system#Feature_requests_on_the_C.2B.2B_side > This reminds me that people found similar animation patterns for > 'common' Scenery models to be pretty expensive as well. Interesting... I guess it depends on numbers - if you have a detailed airport with 1500 different buildings, cars, aircraft, crates, lampposts, fences,... then you should have the same problem - and I guss the same solution, i.e. a sloppy range check which only probes every n frames should offer the same performance gain. * Thorsten ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
