eatdirt wants to merge 2 commits from /u/dirteat/fgdata/ to next, 2024-03-25
Hi there,
I'd like to submit this small patch which is allowing for freezing the viewer position in the Fly-By view.
This minor option allows to use the Fly-By view as a perfect view for using FG as an Remote Control simulator (we have actually a few RC planes already in the hangar, the Rascal110 (JSBSim), Malolo1, Resolution3). Indeed, the eyes should always look to the plane, but the viewer position, supposed to be at the eyes of the RC-pilot, should be fixed.
The Fly-By view we have already is actually perfect in the sense that it is always nearby the planes, which is what happens with RC. As such, adding this option to freeze the viewer when the user click on it is very convenient and allows one to pick-up the most wanted to start doing RC simulation.
Cheers,
Chris.
Hi Chris,
I'm not really convinced by this as a generic piece of function for fgdata.
We already have two Tower views which already provide suitable fixed viewpoints for RC aircraft. The only thing this seems to add is that the fixed view will be much closer?
I'd suggest adding it to the aircraft themselves, or perhaps adding some function to the aircraft to set a much closer tower position, more suitably for an RC field.
But perhaps I'm missing something here?
-Stuart
Hi Stuart,
I've spent quite some times testing many things and I disagree. I'll add a video to show why this works, and why the Tower view does not. None of the tower views provide suitable RC views. They're too far, too high and never close to the RC plane.
Notice that it is not a new view, just a switch holding the fly-by position, so I don't see any issue in that. Plus, one fantastic, and wanted side-effect, is that if the switch is on (viewer hold still), switching the view from fly-by to fly-by, allows you to jump to another very convenient position. Hence, the viewer can actually move around the plane doing so, till the most liked position is found.
At last, because the fly-by view is always nearby the plane, when you start on the runway, the viewer is aside the runway, as wanted for RC. Tower View is quite far an unusable in that case, or would need unrealistic zooming and narrow fov. Notice that Tower AGL is doing this automatically, which is unrealistic for a RC view.
Notice also that this patch allows you to start FG not necessarily at an airport, but possibly in a RC field without tower, and, the fly-by view works again!
Videos coming, both from tower view and fly-by view with the patch!
Last edit: eatdirt 2024-03-09
Here we go, a fly test with the Tower View. Look how the fov is wrong (compared to what a RC pilot would actually see), the auto-zoom is not adequate neither, it makes the view too easy and you can never loose sight of the plane (which may happen in real RC). Also, it is almost impossible to guess distances and parallax. I am even missing the runway while trying to land.
tower_view_vp9_1080p.webm
Now, with the Fly-by view, plus the hold switch on. I am first switching view from fly-by to fly-by to find a position that suits to me, and then fly and land. This is quite realistic and nothing more is needed for RC sims. The flight sucks a bit because I am a beginner in real life RC, and notice how easy is to loose the plane, exactly as in real life.
flybyheld_view_vp9_1080p.webm
For both flights, I am using my TX16II remote control as a joystick. The plane is the Rascal110, and, in addition to me being a rookie, it has also some issues with ground contacts and engine cut-off, but these are unrelated issues that I am going to fix plane-side.
NB: A question though, if you merge that patch, and I think you should, I am wondering if a listener should not be added to the "Hold Viewer Position". This would allow the button to reflect its actual state would it be changed from the remote control (joystick).
Last edit: eatdirt 2024-03-09
Hi Chris,
Thanks for the explanation and the videos.
I still think a better solution here is to move the tower position to a better location, setting it much closer to the aircraft. As well as being cleaner, it also means you can use both a normal Tower view, and the Tower-AGL view. I also think this function is really only applicable to the RC models, and a such I don't think we want to complicate the core fgdata GUI.
I've put some simple prototype code below, but I'm thinking perhaps this could be in a Nasal file in Aircraft/Generic, and included in the RC models. Then
As it happens there was a bug in the view C++ code that stopped the code below from working. I've just pushed a fix for that bug into next. Assuming you are building yourself (or using the nightlies), could you try the code below and let me know what you think?
Once you've tried it, if you still think that modifying the fly-by view is the better solution I'm happy to have a further discussion on-list about this.
-Stuart
Thanks for the code, I'll give it a try with the rascal and let you know what I feel. But, I can anticipate already some limitations such as not allowing remote controlling real planes (which is quite cool too) nor starting again the view nearby the plane when you land too far!
A better solution plane-side could be to copy-paste the fly-by view with held position as an RC view for RC planes, but that would not address RCing real planes. Now copy-pasting the same code for all RC planes and all real planes simply means it should be in fgdata...
All in all, there might be something I am missing in the big picture, but why are you so against this tiny extra on the fly-by view?
I am actually spending much more time making videos and detailing why this tiny things just works fine than the time it took to code it / safe it / improve it. I am pretty sure other RC pilots would be happy with just that, it is minimal modification, spare of coding time, and it should not affect the default behaviour of the fly-by view (we could also prevent its saving and set it to false at fg start to be sure no one would activate it by mistake).
Cheers,
Chris.
Last edit: eatdirt 2024-03-10
All right, I've coded it within the Rascal. I've converted it into a function that must be called after the fdm is initialized (otherwise the geo.* are not yet set).
It is "ok" and quite realistic, so that would be acceptable indeed. But, as I said, compared to the fly-by view, it lacks:
I understand how to fix all this, I would plug the fly-by view in an rcview.nas file, that would need to be in a loop , or called from a loop, to have the geo.pos() updated. But, do we really really want to do this copy-pasted for all rc planes for avoiding one new checkbox in fgdata? Quid of remote controlling big planes too :-/
Cheers,
Chris.
I have been thinking, may a fg-addon be only a new view? Would it make sense? How to be sure it won't collide with planes' views?
Let me reject this merge request, I have changed my mind and I am currently coding an addon with just that exact view. It won't do much better than the Fly-By held, but I'll add menubox to set the height of the pilot, distance to plane, etc... Much more flexible at the end.
I might also avoid collision with plane's view using addon hints, let's see.
Of course, much more coding time than the checkbox indeed!
Last edit: eatdirt 2024-03-23
For the record it is now there:
https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Addons/RCView/
Certainly needs some tuning on view-number collision and position within the view menu.
Cheers,
chris.
There's supposed to be a mechanism (possible a human driven one) to avoid view number collisions intelligently, in an add-on. But I can't seem to find any information on it, hmmm.
@jmturner I'me sure I didn't add that, being too ignorant on views. My guess is, I'm afraid there is no such mechanism.