Re: [Flightgear-devel] Patch: FOV automatic compensation for wider screens
On Tue, Oct 9, 2012 at 3:28 PM, Stuart Buchanan wrote: The proposal is to merge the Display Options and View Options dialog, leaving the Rendering Options dialog alone. This has now been done. Comments welcome as always. -Stuart -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch: FOV automatic compensation for wider screens
On Monday 08 October 2012 02:20:25 James Turner wrote: On 8 Oct 2012, at 07:47, ThorstenB wrote: On 7 Oct 2012, at 15:19, Stuart Buchanan wrote: The use-case is to enable or disable particular views if you don't want to have to spend ages cycling through them. I also quite like this option. Some a/c also provide many additional custom views. It's handy to just enable the personal favourites. Okay - I guess since my yoke has a button bound to 'cycle views' I've got used to rapidly clicking through. I have a button bound, but still frequently turn off a few views... Personal taste: I'd keep the views named as views and just merge the dialogs. Yep, definitely gets my vote. One issue might be, since aircraft can define custom views, making the dialog a sensible proportion. But I don't believe many aircraft define more than an extra 4-5? I'm against merging views and rendering dialogs. They perform two distinctly different functions. Views simply select which views are cycled through and rendering options gets into much detailed and global changes to the way the flightgear world looks. Please don't overload grandpa! Thanks, Ron -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch: FOV automatic compensation for wider screens
Hi Ron, On Tue, Oct 9, 2012 at 3:16 PM, Ron Jensen wrote: I'm against merging views and rendering dialogs. They perform two distinctly different functions. Views simply select which views are cycled through and rendering options gets into much detailed and global changes to the way the flightgear world looks. Please don't overload grandpa! The proposal is to merge the Display Options and View Options dialog, leaving the Rendering Options dialog alone. -Stuart -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch: FOV automatic compensation for wider screens
On 7 Oct 2012, at 15:19, Stuart Buchanan wrote: The use-case is to enable or disable particular views if you don't want to have to spend ages cycling through them. I also quite like this option. Some a/c also provide many additional custom views. It's handy to just enable the personal favourites. Options dialogs at present, but the View Options name is too generic. How about Enable/Disable Views? Doesn't sound like a proper main menu entry to me. Just as awkward to translate to other languages. Alternatively, we could just merge the Display Options and View Options dialogs into one (probably named View Options). Neither of them are very large. That sounds good to me! A more radical idea would be to change the noun from Views to Cameras, which IMO are a bit more descriptive. We'd then have a Cockpit Camera rather than a Cockpit View etc. Also ok. But it could still be merged into a single dialog then. Disadvantage of renaming view to camera though is that plenty of places would need to be adapted or things get inconsistent. There are also lots of aircraft which install custom views (jump seat view, radio panel view, ...). So, things get messy. And I think camera even sounds odd for some of our current views: would the copilot view be renamed to copilot camera? Should aircraft provide custom radio panel cameras? Hmm ;-). Personal taste: I'd keep the views named as views and just merge the dialogs. cheers, Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch: FOV automatic compensation for wider screens
On 8 Oct 2012, at 07:47, ThorstenB wrote: On 7 Oct 2012, at 15:19, Stuart Buchanan wrote: The use-case is to enable or disable particular views if you don't want to have to spend ages cycling through them. I also quite like this option. Some a/c also provide many additional custom views. It's handy to just enable the personal favourites. Okay - I guess since my yoke has a button bound to 'cycle views' I've got used to rapidly clicking through. Personal taste: I'd keep the views named as views and just merge the dialogs. Yep, definitely gets my vote. One issue might be, since aircraft can define custom views, making the dialog a sensible proportion. But I don't believe many aircraft define more than an extra 4-5? James -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch: FOV automatic compensation for wider screens
On 6 Oct 2012, at 23:13, Stuart Buchanan wrote: We've currently got three different dialog with graphics options - Rendering Options containing elements such as wireframe, frame-rate throttling, random objects/trees, shader quality. - View Options allowing the user to configure the active views - Display Options allowing the user to configure what GUI/non-scene information is displayed on the screen. On balance, I think this new options probably sits best under Rendering Options along with frame-rate throttling. Mind if I move it? In terms of usability, I never know what's in view vs display options until I open them - some restructuring here would be awesome. Especially since the 'view options' sounds useful, but in practice I've no idea what use-case it fulfils. James -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch: FOV automatic compensation for wider screens
Le 07/10/2012 00:13, Stuart Buchanan a écrit : On Wed, Oct 3, 2012 at 9:05 PM, Alexis Bory wrote: The idea is NOT to change anything to this standard. Instead, I've just added a tiny option in the Display Options dialog On balance, I think this new options probably sits best under Rendering Options along with frame-rate throttling. Mind if I move it? Hi Stuart, I don't mind at all. I'm already delighted to see courageous people dealing with the gui which is kind of a nightmare for me. Well I mean dealing with gui dilemmas is a nightmare, not FG gui ;-) Alexis -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch: FOV automatic compensation for wider screens
On Sun, Oct 7, 2012 at 4:27 PM, James Turner wrote: In terms of usability, I never know what's in view vs display options until I open them - some restructuring here would be awesome. Especially since the 'view options' sounds useful, but in practice I've no idea what use-case it fulfils. The use-case is to enable or disable particular views if you don't want to have to spend ages cycling through them. Personally, I've had the Helicopter, Chase, Tower, Tower Look From and Model Views disabled for some time, as they are all very similar. I find that Chase Without Yaw View the most useful exterior view for assessing landings. (In fact, I wonder whether we should disable some of them by default in preferences.xml so that new users aren't overwhelmed. OTOH I've not heard of anyone complaining of confusion on the forum, so I'm probably trying to solve a problem that doesn't exist.) I think we have the right split of function between the Display Options and View Options dialogs at present, but the View Options name is too generic. How about Enable/Disable Views? Alternatively, we could just merge the Display Options and View Options dialogs into one (probably named View Options). Neither of them are very large. A more radical idea would be to change the noun from Views to Cameras, which IMO are a bit more descriptive. We'd then have a Cockpit Camera rather than a Cockpit View etc. On Sun, Oct 7, 2012 at 4:56 PM, Alexis Bory wrote: I don't mind at all. I'm already delighted to see courageous people dealing with the gui which is kind of a nightmare for me. Well I mean dealing with gui dilemmas is a nightmare, not FG gui ;-) Yup - it's a minefield :) -Stuart -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch: FOV automatic compensation for wider screens
On Wed, Oct 3, 2012 at 9:05 PM, Alexis Bory wrote: The idea is NOT to change anything to this standard. Instead, I've just added a tiny option in the Display Options dialog: [ ] Compensate Field of View for wider screens (Disabled by default) We've currently got three different dialog with graphics options - Rendering Options containing elements such as wireframe, frame-rate throttling, random objects/trees, shader quality. - View Options allowing the user to configure the active views - Display Options allowing the user to configure what GUI/non-scene information is displayed on the screen. On balance, I think this new options probably sits best under Rendering Options along with frame-rate throttling. Mind if I move it? -Stuart -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patch: FOV automatic compensation for wider screens
Hi all
The default Field of View has been choosen a long time ago and discussed
several times on the devel list.
AFAIK this 55 deg FOV had been settled for two main reasons:
1) There is a need to have a standard FOV across different aircrafts so
the user keeps its space and distance perception when being in different
aircrafts cockpits.
2) We determined [55 degree] as an acceptable compromise between
seeing enough of the instrument panel and the outside world quoting
Curt's email in september 2008.
Today we all are throwing our old 4:3 CRTs through the windows and most
of us already enjoy the 16:9 or 16:10 ratio. This changes the rules.
The idea is NOT to change anything to this standard. Instead, I've just
added a tiny option in the Display Options dialog:
[ ] Compensate Field of View for wider screens (Disabled by
default)
When you check this option, a new function in /Nasal/view.nas checks FG
window size and changes the default FOV for each view so the vertical
FOV keeps in line with what ought to be a 55 deg on a 4:3 screen.
Actually it computes a 4:3 central part of the screen and change the
overall FOV so the FOV on this central part keeps being 55 deg.
The result is that when you resize and change the height/width of your
window you still see the same instruments than in a standard 4:3 screen
with 55 deg FOV.
This should work out of the box for any aircraft. Unchecking the option
resets the FOV for any view to the initial settings.
Patch attached, Tests and comments welcome.
Alexis
diff --git a/Aircraft/E-2C/E-2C-set.xml b/Aircraft/E-2C/E-2C-set.xml
index 9d6730a..3d16688 100644
--- a/Aircraft/E-2C/E-2C-set.xml
+++ b/Aircraft/E-2C/E-2C-set.xml
@@ -63,8 +63,8 @@ Grumman E-2C simulation config.
config
x-offset-m-0.45/x-offset-m
y-offset-m-0.072/y-offset-m
-z-offset-m-6.9/z-offset-m
-pitch-offset-deg-16.5/pitch-offset-deg
+z-offset-m-6.85/z-offset-m
+pitch-offset-deg-17/pitch-offset-deg
default-field-of-view-deg55/default-field-of-view-deg
!--limits
enabled type=booltrue/enabled
diff --git a/Nasal/view.nas b/Nasal/view.nas
index 6af58fa..09244dd 100644
--- a/Nasal/view.nas
+++ b/Nasal/view.nas
@@ -6,7 +6,7 @@
var index = nil;# current view index
var views = nil;# list of all view branches (/sim/view[n]) as props.Node
var current = nil; # current view branch (e.g. /sim/view[1]) as props.Node
-
+var fovProp = nil;
var hasmember = func(class, member) {
if (contains(class, member))
@@ -235,6 +235,7 @@ var manager = {
me.current.handler.start();
if (hasmember(me.current.handler, update))
me._loop_(me.loopid += 1);
+ resetFOV();
},
reset : func {
if (hasmember(me.current.handler, reset))
@@ -638,7 +639,61 @@ var point = {
-var fovProp = nil;
+##
+# view.ScreenWidthCompens: optional FOV compensation for wider screens.
+# It keeps an equivalent of 55° FOV on a 4:3 zone centered on the screen
+# whichever is the screen width/height ratio. Works only if width = height.
+#
+# status: 0=Init, 1=toggle option, 2=waiting for the window size to change.
+
+var defaultFov = nil;
+var oldW = 0;
+var oldH = 0;
+var fovStore = {};
+
+var screenWidthCompens = func(status) {
+ var opt = getprop(/sim/current-view/field-of-view-compensation);
+ if (status == 0) {
+ defaultFov = getprop(/sim/current-view/config/default-field-of-view-deg);
+ forindex (var i; views) {
+ var defaultFovNode = views[i].getNode(config/default-field-of-view-deg, 1);
+ fovStore[i] = defaultFovNode.getValue();
+ }
+ } elsif (status == 1) {
+ opt = ! opt;
+ setprop(/sim/current-view/field-of-view-compensation, opt);
+ if (! opt) {
+ forindex (var i; views) {
+var defaultFovNode = views[i].getNode(config/default-field-of-view-deg, 1);
+defaultFovNode.setValue(fovStore[i]);
+ }
+ var vn = getprop(/sim/current-view/view-number);
+ setprop(/sim/current-view/field-of-view, fovStore[vn]);
+ }
+ } elsif (status == 2 and ! opt) {
+ return;
+ }
+ var w = getprop(/sim/rendering/camera-group/camera/viewport/width);
+ var h = getprop(/sim/rendering/camera-group/camera/viewport/height);
+ if (! opt) {
+ setprop(/sim/current-view/config/default-field-of-view-deg, defaultFov);
+ return;
+ }
+ if ( w != oldW or h != oldH or status == 1) {
+ oldW = w;
+ oldH = h;
+ d = 1.28066 * h; # 1.28066 = 4/3 (width/height ratio) / 2 / tan(55°)
+ newFov = 2 * math.atan2( w / h * h / 2, d) * R2D;
+ setprop(/sim/current-view/config/default-field-of-view-deg, newFov);
+ forindex (var i; views) {
+ var defaultFovNode = views[i].getNode(config/default-field-of-view-deg, 1);
+ defaultFovNode.setValue(newFov);
+ }
+ fovProp.setValue(newFov);
+ }
+ settimer(func { screenWidthCompens(2); }, 1);
+}
+
_setlistener(/sim/signals/nasal-dir-initialized, func {
@@ -654,6 +709,7 @@ _setlistener(/sim/signals/nasal-dir-initialized, func {
manager.init();
manager.register(Fly-By View, fly_by_view_handler);
