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 Timi » Sun May 20, 2018 8:12 pm

Is there a way to slave the view to an object, say the helicopter deck of a moving AI ship for example?
Would love to do videos similar to this in FG:
Timi
 
Posts: 21
Joined: Mon Nov 21, 2016 8:08 am
Callsign: Jaeger
Version: 2018.2.2

Re: Alternative camera control

Postby GinGin » Fri Nov 09, 2018 6: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: 412
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Alternative camera control

Postby slawekmikula » Fri Nov 09, 2018 7: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: 51
Joined: Sun Feb 19, 2017 9:31 am

Re: Alternative camera control

Postby Hooray » Fri Nov 09, 2018 7: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: 11191
Joined: Tue Mar 25, 2008 8:40 am

Re: Alternative camera control

Postby slawekmikula » Fri Nov 09, 2018 8: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: 51
Joined: Sun Feb 19, 2017 9:31 am

Re: Alternative camera control

Postby GinGin » Sat Nov 10, 2018 5: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: 412
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Alternative camera control

Postby slawekmikula » Sat Nov 10, 2018 5: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: 51
Joined: Sun Feb 19, 2017 9:31 am

Re: Alternative camera control

Postby rominet » Sat Nov 10, 2018 7: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: 550
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Alternative camera control

Postby Hooray » Sun Nov 11, 2018 2: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: 11191
Joined: Tue Mar 25, 2008 8:40 am

Previous

Return to New features

Who is online

Users browsing this forum: No registered users and 5 guests