The more I am thinking about a clean way to implement proper rain cone tilting at any view origin, the more difficult it seems. I've already made it work properly for views attached to flying aircraft (such as in-cockpit/chase/helicopter view), and would love to make it work for all the simulation environment. Can somebody please read through and help with design assumptions below?
> > > Is there a simple way to learn if the current view origin is moving or > > > not? (If not, is it a reasonable thing for me to try to add to FGViewer? > > > what about the view origin airspeed computations?) > > > > One thing I notice when looking at the viewer configurations in > > preferences.xml is that all views (except for the cockit view that > > defines <from-model>true</from-model>) that are moving with the aircraft > > have this defined: > > > > <z-offset-m alias="/sim/chase-distance-m"/> > > > > This might not be good enough for looking from (for example) the cockpit > > of an AIModel, but otherwise it might be good enoug for your needs? > > Could be, although it still doesn't address the issue of forcibly zeroed > airspeed on a real aircraft. BTW, for yasim-based aircraft (bo105, for example), I do get non-zero airspeed indication on the ground, and thus I have a corresponding rain cone slanting working for me even on the ground w/o running engine. However, looking more at my code I realized that I'll have to change the fg<->sg interface wrt the speed passing altogether --- because right now, just a single scalar is passed for the (relative) aircraft speed. In fact, what is needed, is at least the headwind and crosswind relative component of the view origin. Maybe a 3D relative wind vector (just in case) would be a better thing to pass? This has to be 1) FDM independent (i.e., if I add it on a per-fdm basis, it means that each fdm must update the same set of properties in a consistent way. I.e., the airpeed property won't work because of the forcible zeroing of jsb) 2) view-type independent (i.e., stationary/moving views, i.e., if something updates the view origin (for views tied to an fdm-controlled object), I need to have the relative wind vector updated accordingly as well. For stationary views, I should just look at the local wind. BTW, if I am looking from a tower, where in the code is the weather updated to tower-local from the aircraft-local?) 3) work on the ground and in the air for aircraft-based views Please tell me if these requirements make sense, and then I'll expand the above and outline the scope of the changes I am planning. 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
