Discussion:
Helicopter rotor wash
(too old to reply)
Thorsten Renk
2017-06-25 17:19:51 UTC
Permalink
I have a (nearly ready) GLSL implementation to visualize rotor wash both
on the new volumentric grass (you see blades bend away and wave around the
helicopter) and over water (you see extra foam churning and waves
spiralling outward).

I would need some helicopter developer to test and experiment with this
and tell me whether the interface is sufficient 'as is' to get decent
visuals or whether some more is needed.

Any takers? Let me know.

* Thorsten
James Turner
2017-06-26 13:49:41 UTC
Permalink
I have a (nearly ready) GLSL implementation to visualize rotor wash both on the new volumentric grass (you see blades bend away and wave around the helicopter) and over water (you see extra foam churning and waves spiralling outward).
Not a helicopter developer, but, this sounds awesome!

James
Thorsten Renk
2017-06-27 13:01:56 UTC
Permalink
Since the EC 135 P2 is already in another developement process and is
recieving a lot of impressive updates, I would like to test it. While
the new volumetric grass is a frame-rate eater here, I hope the it will
be better on the water ... ;-)
At least a feature I waited for, and very helpful for helicopter pilots!
Yeah, the grass is performance-hungry - but it does look pretty on
high-end systems. The performance impact on the water should be negligible
(needs ALS water shader quality to maximum, the lower-quality effect
doesn't have it implemented). Also needs wind effects enabled to see it on
the grass.

I've now pushed the interface. The heli needs to set

/environment/aircraft-effects/wash-x, wash-y and wash-strength


these are all pre-defined as zero.


The first two are the eye-relative position of where you want the center
of the air column to be (in meters, you can make that dependent on
velocity or other factors if you like) and the strength is supposed to
stand for the amount of displaced air and regulates both the amount of
foam/wind and the radius out to which the effect is visible. The idea is
to make this 0-1 ish, but it accepts values >1 just as well if you need
more oomph. You can make that depend on altitude agl and rotor RPM or
whatever you fancy.

I have quickly rigged the script below to test it all with the EC 135 and
this delivers plausible visuals to me, but I don't know overly much about
how this should look like. So I'm ready to improve this if I can get
feedback into what direction.

Cheers,

* Thorsten


# rotor wash test
---------------------------------------------------------------------------------

var wash_loop = func {

var vpos = geo.viewer_position();
var apos = geo.aircraft_position();

var lat_to_m = 110952.0;
var lon_to_m = math.cos(apos.lat()*math.pi/180.0) * lat_to_m;

var alt = getprop("/position/altitude-agl-ft");

var delta_x = (apos.lat() - vpos.lat()) * lat_to_m;
var delta_y = -(apos.lon() - vpos.lon()) * lon_to_m;

setprop("/environment/aircraft-effects/wash-x", delta_x);
setprop("/environment/aircraft-effects/wash-y", delta_y);

var rpm_factor = getprop("rotors/main/rpm")/400.0;


var strength = 20.0/alt;
if (strength > 1.0) {strength = 1.0;}
strength = strength * rpm_factor;

setprop("/environment/aircraft-effects/wash-strength", strength);

settimer (wash_loop, 0.0);
}

wash_loop();
Thorsten Renk
2017-06-29 05:59:41 UTC
Permalink
Wait, it only happens when paused, otherwise the rotorwash is exactly
below the heli!
Yeah, the script of course only updates eye-relative position while it
runs...

Actually, do we have any option of running code (property rules,
Nasal,...) for, say, view management, even when FG is paused by
designating it in a special way?

* Thorsten
Emilian Huminiuc
2017-06-29 06:09:55 UTC
Permalink
Post by Thorsten Renk
Wait, it only happens when paused, otherwise the rotorwash is exactly
below the heli!
Yeah, the script of course only updates eye-relative position while it
runs...
Actually, do we have any option of running code (property rules,
Nasal,...) for, say, view management, even when FG is paused by
designating it in a special way?
* Thorsten
May I ask why you use eye-relative position instead of using the actual model
position(+required offset) directly?

Regards
Emilian
Thorsten Renk
2017-06-29 06:20:56 UTC
Permalink
Post by Emilian Huminiuc
May I ask why you use eye-relative position instead of using the actual model
position(+required offset) directly?
Eye-relative has no coordinate discontinuities, I remember there were
situations in which actual model position referenced coordinates could
have discontinuities (unless you use true global coordinates, which
however have numerical issues for meter-scale phenomena), so I buried the
idea years ago.

* Thorsten
Emilian Huminiuc
2017-06-29 06:32:22 UTC
Permalink
Post by Thorsten Renk
Post by Emilian Huminiuc
May I ask why you use eye-relative position instead of using the actual model
position(+required offset) directly?
Eye-relative has no coordinate discontinuities, I remember there were
situations in which actual model position referenced coordinates could
have discontinuities (unless you use true global coordinates, which
however have numerical issues for meter-scale phenomena), so I buried the
idea years ago.
* Thorsten
The respective issue has been fixed, years ago too.
Anyway, it just seemed odd to have to jump through hoops when the position is
already available (either as cartezian or geodetic coords, caveat tied
properties)

Regards,
Emilian
Thorsten Renk
2017-06-29 07:21:35 UTC
Permalink
Post by Emilian Huminiuc
The respective issue has been fixed, years ago too.
Not sure whether we mean the same issue though...
Post by Emilian Huminiuc
Anyway, it just seemed odd to have to jump through hoops when the position is
already available (either as cartezian or geodetic coords, caveat tied
properties)
As I said - global (xyz) Cartesian coordinates evaluated in floating point
precision in the shader lead to numerical issues for me at meter-scale.
I've tried that in different contexts and always ended up working around
it. Evaluated on the CPU at double precision scale and the resulting small
difference passed to the shader works fine.

Accuracy issues in subtracting two individually large numbers are a
well-known issue in numerical math ;-/ The technique I apply seems like
jumping through hoops, but makes perfect sense from a numerical accuracy
POV to me.

* Thorsten

Loading...