Board index FlightGear Development New features

Alternative camera control

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Re: Alternative camera control

Postby GinGin » Fri Nov 09, 2018 7:24 pm

Hey, Very nice add on.

Even with the nice explanations, I am having trouble to make it work.
Some one with windows is using it with sucess?

Thank you ;)
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Alternative camera control

Postby slawekmikula » Fri Nov 09, 2018 8:33 pm

@GinGin
- get current version from my github (it's based on 1.2 version with addon compatibility and some fixes, features)
- run fgfs with this addon
- open from menu view->FGCamera
- click create new camera
- select it and click CFG
- next using cursor keys and shift+pgup/pgdown and mouselook move to desired position
- click "store position" on "current camera settings" - and configure other options if you want
- camera is available on the index from the list e.g. pressing "0" will move to view "0"
- add other cameras and then you can switch cameras with buttons 0-9
- remember to click "save" to save your config

hope it helps

ps. on my github version 1.2.1 is ready, my todo list has only documentation left (as you noticed). Unfortunately i've not enough time to complete it for a long time.
slawekmikula
 
Posts: 128
Joined: Sun Feb 19, 2017 10:31 am

Re: Alternative camera control

Postby Hooray » Fri Nov 09, 2018 8:46 pm

I would suggest to also commit/share your todo list and then reach out to the original developer (I believe that was Marius_A??), and ideally this should be committed to the official fgaddon repository - I believe Torsten was once interested in seeing this ported, so he is likely to be supportive of any efforts doing just that.

That being said, for the time being, I would strongly suggest to consider the addon system to still be evolving (as can be seen by a number of major improvements in the last year), and therefore it's a good idea to only have a single "official" place to maintain/host addons, so that they can be community-maintained while the addon system is still taking shape.

Many improvements to the addon system required changes to existing addons in the process, changes that were "automatically" handled by the people improving the addon system. So, please don't underestimate the benefits of this worklow.

In other words, I would definitely suggest to treat the addon system as an experimental feature that may be subject to change in the time to come, and that is why it's important to "release early & often", aka team up to create an addon, and reach out to the folks on the devel list to get it committed to fgaddon, so that new addons are kept in fgaddon primarily, and please be sure to report back any issues when porting addons/features.

In theory, the addon system is a great system, and it could become a huge troubleshooting aid when dealing with Nasal related issues, simply because more and more Nasal based features could be moved into "addon space", which makes it much easier to keep things disabled (which means less Nasal code running in the main loop). But there is quite a bit of integration missing still, and a number of ideas were suggested by contributors already (such as integration with the package manager/catalog system, the built-in launcher or providing a way to ship certain addons as part of each release).

But for any of that to happen eventually, early-adopters should provide feedback to the core devs, who can really only help porting/maintaining addons if they are part of the fgaddon repository.

Having too many separate/independent locations of where addons are hosted will only add to the confusion at this point, especially if/when the addon system should continue to be revamped, so that future improvements may cause frustration among addon developers whose addons are not in fgaddon yet.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Alternative camera control

Postby slawekmikula » Fri Nov 09, 2018 9:04 pm

@Hooray

In principle yes. Florent has done tremendous job allowing to fgcamera run as fgaddon without any file copy to fgdata. Sorry, but i've very limited time to spend on flightgear and mostly some work is done only when i'm fed up with other (RL) coding and it is some kind of brain exercise ;) I've ported marius code (with communication with him) to fgaddon. On the next branch there is new code from Marius new code based on property rules. On my todo list is only documentation.

If someone willing to take a look at the code and process it to fgaddon it would be great. As for me personally I could not promise any ETA on my work - I wish i had it more.
slawekmikula
 
Posts: 128
Joined: Sun Feb 19, 2017 10:31 am

Re: Alternative camera control

Postby GinGin » Sat Nov 10, 2018 6:20 pm

Awsome, thanks

Just a question, run fgfs with this addon

I think I might block here, on the extension --addon=

Didn't find explantions on it in the FG launcher
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Alternative camera control

Postby slawekmikula » Sat Nov 10, 2018 6:27 pm

@GinGin

You have to put --addon=<path to addon> on the commandline that launches flightgear. Thus not in launcher (additional options) but on e.g. shortcut that runs flightgear. Unfortunately i've got no windows installation to show you how to do it. Maybe someone with windows installation can help and provide here some guidance.

PS. Maybe someone correct me, but addon registration have to be done on commandline not in launcher advanced options.
slawekmikula
 
Posts: 128
Joined: Sun Feb 19, 2017 10:31 am

Re: Alternative camera control

Postby rominet » Sat Nov 10, 2018 8:10 pm

Hi,

The --addon option works in the built-in launcher's Additional Settings box since FG commit 86aaaf6de9a6e516c. :wink:

The only caveat I know regarding this is if you use non-ASCII chars for the path following '--addon='. IIRC, the launcher will interpret these chars as UTF-8, which is not necessarily your filesystem encoding. If the path uses only ASCII chars or if both encodings agree, you should be fine.
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Alternative camera control

Postby Hooray » Sun Nov 11, 2018 3:54 pm

We've been talking about making the add-on "trigger" property configurable, so that some of the more complex add-ons (e.g. stuff like bombable) could hook into different parts of the simulator's init sequence, this would -among others - make it possible to also allow add-ons to register their own command line options.

But it would also be possible to not just have a single trigger property for loading an add-on, but also separate properties to deal with other important simulator events (think /sim/signals), which in turn would mean that add-ons could hook into other subsystems and their "events" rather easily.

For instance, James mentioned that he would like to see Canvas-based reimplementations of the currently hard-coded HUD/2D panels systems, including hooks to trigger such Canvas/Nasal replacements instead of the legacy code:



http://wiki.flightgear.org/Addons#Hooki ... penGL_code
https://sourceforge.net/p/flightgear/ma ... /36399261/
James Turner wrote:The aim would be to replace the C++ code with a Nasal HUD layer, likely in FG_DATA/Canvas/Hud - with one Canvas HUD item per each of the current C++ HUD items (ladder, tape, dial etc). Each one should be fairly easy to build with some path, text and group commands.

Then we need to write an XML loader in Nasal, possibly one line of C++ to trigger loading, and we can remove the C++ HUD code in favour of the Canvas implementation.
[...]
map the old 2D panel code which uses raw OpenGL calls, to instead build up Canvas items (textures, transforms, text) and update them. Some things are easier here by using C++ - we can keep the same XML parser and the texture loading is much simpler.

In both cases the aim is to remove legacy OpenGL 1.x code, since these are some of the awkward remaining pieces.


If/when these features are implemented (hooks to allow add-ons to register new/alternate APIs to override legacy features), it's likely that the addon system's version number will also be incremented - thus, having all addons under a single "umbrella repository" (aka fgaddon) seems like a good idea.

Note that the C++ changes to have a piece of Nasal/Canvas code triggered are rather simple, i.e. it's as straightforward as using a STL std::map<> to see if any of the hard-coded heuristics are to be skipped. For example, this makes it possible to re-implement hard-coded widgets without touching any of the C++ code at all, delegating such calls to Nasal space, while still using the hard-coded layouting engine:

http://wiki.flightgear.org/Howto:Hooking_into_the_GUI
Image

The same approach would also work 1:1 for the HUD/2D panels subsystems - all that is needed are a handful lines of C++ code to check the STL map for matching primitives overriding the legacy C++ code, and instead trigger Nasal - which is also a nice way for fgdata/fgaddon developer to customize/override hard-coded functionality.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Alternative camera control

Postby The epic chicken » Sat Oct 31, 2020 6:11 pm

would it be possible to just add this through addons page
In Thrust We Trust
User avatar
The epic chicken
 
Posts: 283
Joined: Wed Oct 28, 2020 11:24 am
Callsign: cva1920
Version: 2020.3.9
OS: windows 10

Re: Alternative camera control

Postby Johan G » Sun Nov 01, 2020 4:06 am

It seems like you should be able to download an addon and on the Add-ons page under Add-on Module folders add the path to the addon.

Possibly with this caveat:
rominet wrote in Sat Nov 10, 2018 8:10 pm:The only caveat I know regarding this is if you use non-ASCII chars for the path following '--addon='. IIRC, the launcher will interpret these chars as UTF-8, which is not necessarily your filesystem encoding. If the path uses only ASCII chars or if both encodings agree, you should be fine.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6625
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Alternative camera control

Postby benih » Sat Dec 12, 2020 12:10 am

I just downloaded the master branch from https://github.com/slawekmikula/flightg ... n-fgcamera
The extracted files (i actually "git clone", but thats the same as downloading the zip from github) and added it to the launcher as addon.

I was then able to start FlightGear and it worked out of the box with 2020.3.0.

Some things come to my mind however, and i post it here in the hope a developer might grab them (probably i will make github issues out of them):
  • The default mode seems to interfere with the mouse. You have to right click to change modes. This can easily be mitigated by activating "spring loaded mouse" option (which then gets persisted).
    May i suggest to make this option active by default, so the addon is backwards compatible?
  • Mouse drag directions are inverted (is this configurable?)
  • Space key breaks with FGCom (it toggles flight controls on/off -> this breaks ATC interaction!!!)
  • it initalizes with wrong FOV (very zoomed) every start, so i must hit a preset key (1) to reset it.
  • An idea would be to use aircraft metadata to guess the basic filter set to load, so one doesn't start with empty filters (in case the aircraft dev did not define own sets)
  • It would also be cool if ground shaking depends on the surface roughness
  • same for air, smooth air my be lower shaking than turbolences
  • How can i rename existing cameras? nvermind found it on the wiki page

Really cool work and the effects are stunning. What i really dislike is that it messes with controls. If all default controls would still work (like mouse dragging, CTRL+Mouse shift and pan the View), that would be awesome. However i made a workaround using preset cameras (which is a nice feature btw).

Also, when i do not load the addon, my controls are still wrong. <- my fault: the addon just switches standard mouse behaviour and this can be reset using fgfs standard options dialog

How can i configure the head movement to lean slightly into courves?
User avatar
benih
 
Posts: 1679
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit

Re: Alternative camera control

Postby slawekmikula » Sat Dec 12, 2020 1:32 am

benih wrote in Sat Dec 12, 2020 12:10 am:I just downloaded the master branch from https://github.com/slawekmikula/flightg ... n-fgcamera

Some things come to my mind however, and i post it here in the hope a developer might grab them (probably i will make github issues out of them):
  • The default mode seems to interfere with the mouse. You have to right click to change modes. This can easily be mitigated by activating "spring loaded mouse" option (which then gets persisted).
    May i suggest to make this option active by default, so the addon is backwards compatible?
  • Mouse drag directions are inverted (is this configurable?)
  • Space key breaks with FGCom (it toggles flight controls on/off -> this breaks ATC interaction!!!)
  • it initalizes with wrong FOV (very zoomed) every start, so i must hit a preset key (1) to reset it.
  • An idea would be to use aircraft metadata to guess the basic filter set to load, so one doesn't start with empty filters (in case the aircraft dev did not define own sets)

    Really cool work and the effects are stunning. What i really dislike is that it messes with controls. If all default controls would still work (like mouse dragging, CTRL+Mouse shift and pan the View), that would be awesome. However i made a workaround using preset cameras (which is a nice feature btw).


As this post mentions my repository that encapsulates fgcamera as an addon I might add something to this:

  • first of all thanks to Marius_A for this great work. It is almost everything from him. I've made some small tweaks and additions.
  • please post issues you've found on the github. It would be best to keep it there.
  • mouse drag - yes, i've also my note about it. I'll try to correct it soon.
  • mouse/keyboard controls - it buggers me because the addon replace mice.xml and keyboard.xml with the mapping available in the addon. It was done because original fgcamera code forces to manually change it in fgdata folder. Nonetheless this is very unfortunate and I was looking at it, in order to do not use this technique. Still nothing substantial with it.
  • aircraft configuration - on my list there is ability to load aircraft config from the aircraft dir. It could be somewhat possible to define camera and other settings from aircraft developers. Don't know if it possible to "guess" settings. Maybe some predefined settings to choose from. If you could provide such model settings it would be great
  • wrong FOV - please give info n which aircraft it is, post your config along the github issue. I'll look at it.

Nonetheless I do not have much time working on it and any help/pull request are very welcome :)
slawekmikula
 
Posts: 128
Joined: Sun Feb 19, 2017 10:31 am

Re: Alternative camera control

Postby benih » Sat Dec 12, 2020 2:02 am

Thank you very much, i spammed you with tickets :)

Ah btw, the readme says:
run flightgear with --addon directive. WARNING this is not "additional settings" window in the launcher ! you have to modify windows shortcut or linux startup script for example to looks like this (in linux):

But this exactly works fine! You can just add the folder to the launcher in the addons section.
User avatar
benih
 
Posts: 1679
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit

Re: Alternative camera control

Postby slawekmikula » Sat Dec 12, 2020 2:11 am

benih wrote in Sat Dec 12, 2020 2:02 am:
run flightgear with --addon directive. WARNING this is not "additional settings" window in the launcher ! you have to modify windows shortcut or linux startup script for example to looks like this (in linux):

But this exactly works fine! You can just add the folder to the launcher in the addons section.


Yes, docs are somewhat outdated. Earlier, before Qt Launcher has this ability, that was the only way to start it. Now it's much easier. I'll correct it.
slawekmikula
 
Posts: 128
Joined: Sun Feb 19, 2017 10:31 am

Re: Alternative camera control

Postby benih » Sat Dec 12, 2020 1:45 pm

What i don't still get is how the head movement is defined.
I have seen a video of the project, where the hear turns into the flight direction, and i used that alot.

Or do i confuse and this was a head tracker at work?
User avatar
benih
 
Posts: 1679
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit

PreviousNext

Return to New features

Who is online

Users browsing this forum: No registered users and 4 guests