To patch cleanliness gurus (i.e., mostly to Eric): I had written earlier in this thread: > make the thing a bit more configurable (instead of all the in-code magic > numbers), as a first step before introducing textures onto the cone
I'd like to have some precipitation renderer parameters configurable... what is the politically correct way to make it so? (i.e., smth that would be logical enough, not increasing the inter-component knowledge/dependencies beyond needed, and acceptable in the light of the oncoming freeze) I don't think there is much sense to have these parameters tweaked during the fgfs normal use (only for development). (E.g., constants to determine the streaks length at the "near" and "far" level). Hence I am unsure if it makes sense to expose them all explicitly via the SGEnviro interface and have the FG's FGEnvironmentMgr manipulate them directly. Rather, I wanted to make a subsection of preferences.xml dedicated to precipitation rendering, maybe smth like a /sim/rendering/precipitation then just pass an sgprop node pointer from that environment manager over to SGEnviro, and read properties inside SGEnviro from the subtree, whenever I need that? Would that be a fine thing to do? Vassilii ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
