Board index FlightGear Development Aircraft

Dual control for Boeing 777

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Re: Dual control for Boeing 777

Postby Hyde » Tue Apr 26, 2016 11:21 pm

Hooray,
texture re-placement on the copilot aircraft, and copilot side

No, copilot aircraft, and both pilot and copilot side don't work.
the PFD can be mapped to that screen and vice versa to troubleshoot

PFD is not the canvas model. Normal ac3 model that's why it works.
I haven't heard any canvas indicator works on MP copilot side airplane.
Does anyone succeed?
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: Dual control for Boeing 777

Postby Octal450 » Wed Apr 27, 2016 5:53 am

@Hyde

Have you tried running the ND instance on the copilots system, but transfering the values through MP?
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: Dual control for Boeing 777

Postby Octal450 » Wed Apr 27, 2016 5:57 am

@Hooray, OK, I had this issue on the KC-137R boom operator nav display, but solved it somehow. I wish I remembered how. I will take a look.

Regards,
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: Dual control for Boeing 777

Postby Hooray » Wed Apr 27, 2016 1:15 pm

if this does not work at all, it would suggest that the Canvas code replacing the texture is the culprit - have you tried using a Canvas as part of the livery or somewhere else ?
I don't think there's an actual problem here, but if you cannot get a Canvas to show at all, something else may be going on.

Is there some other, less complex, aircraft that we could use as a testbed for this, something like the ufo or maybe one of the vehicles (snowplow) ?
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: Dual control for Boeing 777

Postby Hooray » Sun May 15, 2016 2:46 pm

@Hyde: It seems, Richard has been able to track down what is going on: https://sourceforge.net/p/flightgear/ma ... /35089070/
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: Dual control for Boeing 777

Postby Richard » Sun May 15, 2016 7:00 pm

Hyde wrote in Sun Apr 24, 2016 11:09 pm:I find one difference in the property window.
/canvas/by-index/texture[1]/palcement/status-msg
Pilot side is"Ok"
Copilot side is "No match"
This makes sense.
Both has Node="ND.screenL"
Then what should be for Copolot side?


This appears to be the root of the problem; that Canvas can't find the 3d element - I'm guessing that it is because it's not in the 'main' aircraft model and that's the only place it looks.

I've got a suspicion that the fix may actually not be that easy; as in a multiplayer environment with multiple aircraft how can we find the right one; and also what happens when the aircraft model is removed. I'm investigating to see if it is possible to pass in the instance of the 3d model to the canvas; this may take a while to get fixed.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Dual control for Boeing 777

Postby Hooray » Sun May 15, 2016 7:39 pm

That "ownship" reference you made makes a whole lot of sense - there are a bunch of hard-coded assumptions all over in SG/FG that assume that there's only a single aircraft (autopilot, route manager, fdm etc) - the interesting thing is that this cannot be addressed easily, because an AI/MP aircraft may be instantiated several times, so even an otherwise identical 3D model, may have multiple instances - thus, we'd need a way to address/look up a certain 3D model to replace a certain texture.
Like you say, fixing this may not be all that easy - the only "workaround" I can currently think of is using the equivalent of a -set.xml file as the key for a lookup, so that we can obtain the index of the 3D model in /models or /ai (mp) and then locate the correct texture to be replaced.

IIRC, there should be some kind FGCanvasSystemAdapter in $FG_SRC/Canvas that encapsulates the model lookup - but I need to check again.

I agree that it would be desirable to be able to use the Canvas _anywhere_ - but for that to happen, we need some clear heuristics to obtain the handle to the right scenegraph branch to traverse for the osg::nodevisitor

Besides, the AI/MP code got "recently" optimized - IIRC, at some point everything was using a single tree - so the fix may not be that straightforward.
For now, I think that we could review the AI and model_mgr code and automatically annotate newly created models so that a std::map<> is populated which the Canvas system can look up a certain 3D model and address it properly.
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: Dual control for Boeing 777

Postby Richard » Sun May 15, 2016 9:39 pm

Hooray wrote in Sun May 15, 2016 7:39 pm:That "ownship" reference you made makes a whole lot of sense
...
Like you say, fixing this may not be all that easy - the only "workaround" I can currently think of is using the equivalent of a -set.xml file as the key for a lookup, so that we can obtain the index of the 3D model in /models or /ai (mp) and then locate the correct texture to be replaced.

IIRC, there should be some kind FGCanvasSystemAdapter in $FG_SRC/Canvas that encapsulates the model lookup - but I need to check again.


I don't think it is a property tree issue, the -set.xml isn't necessarily going to help as there isn't a one-to-one mapping of model to the -set file.

The cmdarg that is passed to the model (xml) in the nasal load section could be where the link between the scenegraph model and the nasal / canvas is made; but I don't think this is currently possible. I think Canvas is making assumptions about the scenegraph; but I can't say for certain as I've not managed to figure out the data flow through the code yet. This all needs to be linked properly together without using heuristics. It needs to be fixed properly or not at all and simply be classified as a limitation if a proper fix cannot be found.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Dual control for Boeing 777

Postby Hooray » Sun May 15, 2016 9:54 pm

I wasn't meaning to suggest it's a ptree level issue - I just meant to say that'd be one way to solve the lookup issue when multiple instances of a 3D model are involved - e.g. imagine AI/MP traffic with 10+ 737 models loaded

I do think it can be fixed "properly" - but we need a way to look up different instances of a model and make that known to the Canvas system, even if that means explicitly telling it to use a different scenegraph branch.

What have you looked at so far ? Do you need any specific pointers ?

Internally, the abstraction the Canvas is using is a "placement" - for models, this is overriden in $FG_SRC/canvas/canvas_mgr.cxx IIRC

At the C++ level, in SimGear, it all ends up as an OD_gauge (owner-drawn gauge), the class is named FGODGauge there, with a FGODGauge::set_texture() call to set/replace the texture

If that's a red herring, I'd suggest to look at other OD_gauge based hard-coded instruments inheriting from it, because those all predate the Canvas system, and the Canvas system is likely using the same texture visitor mechanism to replace the static texture with a dynamic RTT/FBO, so that should be easier to go through in comparison to all the Canvas C++ code - e.g. by looking at agradar, groundradar, wxradar or the navdisplay C++ code

There's probably some kind of osg::NodeVisitor sub-class in there to replace the texture with the created RTT, and I _assume_ that the Canvas system is likely reusing that mechanism, so that other scenegraph branches may simply not be touched
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: Dual control for Boeing 777

Postby Hooray » Sun May 15, 2016 11:16 pm

Okay, here are some more preliminary findings/pointers, based on skimming through $FG_SRC:

The Multiplayer system is using the AI system to load/add 3D models to the scene: https://sourceforge.net/p/flightgear/fl ... .cxx#l1457

The attach() method ends up at the AIManager class: https://sourceforge.net/p/flightgear/fl ... r.cxx#l273

The destructor there removes those models from a separate scenery branch: https://sourceforge.net/p/flightgear/fl ... e.cxx#l227

pSceneryManager->get_models_branch()


This is in line with the ::init() method, where the aircraft model is added: https://sourceforge.net/p/flightgear/fl ... e.cxx#l435


Code: Select all
globals->get_scenery()->get_models_branch()->addChild(aip.getSceneGraph());


scenery models are treated differently:

https://sourceforge.net/p/flightgear/fl ... gr.cxx#l57
Code: Select all
scene_graph = globals->get_scenery()->get_scene_graph();


The osg::Group / scenegraph branches we have available are listed below:

https://sourceforge.net/p/flightgear/fl ... y.hxx#l115
Code: Select all
    osg::Group *get_scene_graph () const { return scene_graph.get(); }
    osg::Group *get_terrain_branch () const { return terrain_branch.get(); }
    osg::Group *get_models_branch () const { return models_branch.get(); }
    osg::Group *get_aircraft_branch () const { return aircraft_branch.get(); }
    osg::Group *get_interior_branch () const { return interior_branch.get(); }
    osg::Group *get_particles_branch () const { return particles_branch.get(); }
    osg::Group *get_precipitation_branch () const { return precipitation_branch.get(); }




Next, I would check where/if any of the Canvas code is calling FGScenery::get_aircraft/scenegraph_branch()

I hope to take another look tomorrow ... but there should be some kind of nodevisitor scheme that makes a get_*_branch call and replaces the textures there...
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: Dual control for Boeing 777

Postby Hooray » Sun May 15, 2016 11:42 pm

Ok, just checked it briefly - the FG level code resides in $FG_SRC/Cockpit/od_gauge.cxx, where you can find the corresponding ReplaceStaticTextureVisitor

https://sourceforge.net/p/flightgear/fl ... e.cxx#l250

For aircraft, this will only get the aircraft branch from FGscenery:
Code: Select all
simgear::canvas::Placements
FGODGauge::set_aircraft_texture( const char* name,
                                 osg::Texture2D* new_texture )
{
  return set_texture
  (
    globals->get_scenery()->get_aircraft_branch(),
    name,
    new_texture
  );
}


But there is a set_texture() method to specify a different osg::Node

Next, I would look for calls to set_aircraft_texture() and set_texture() respectively

HTH


PS: Funnily, according to the git logs, you were the last person to commit changes to that file ;-)
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: Dual control for Boeing 777

Postby Hooray » Mon May 16, 2016 12:14 am

Apart from that, a little feedback from bugman may be good, because we're currently talking about the Canvas and how to use it with MP/AI models - so given that he recently touched the scenegraph code, it would be helpful if he could share what he is thinking, even if that just means sharing his plans on how to do this in the future - because James basically agreed with his proposal, and the whole "ownship" assumption must be teased out anyway, because it's been lingering in the tree for over a decade meanwhile, and crippling FlightGear quite severely (including even fairly recent additions like the Canvas system obviously):

http://www.mail-archive.com/flightgear- ... 00881.html
Curt wrote:We need to be able to have multiple instances of various FDM's
running concurrenty (and with your proposed changes, accessible
through the property manager interface.) I'm thinking of things like
random 'traffic' that would get created and deleted. For instance we
have fdm[0], fdm[1], fdm[2], fdm[3] and then we delete fdm[1] because
it flew out of range, but now another aircraft flies into view so we
need to create fdm[4], etc.


http://thread.gmane.org/gmane.games.fli ... ocus=13342
Andy Ross wrote:Lots of existing code was written to
reference "The Panel" and some work had to be done to enable the
notion of multiple panel objects. Likewise, there was no easy notion
of "this aircraft" within the rendering tree (all you get is an ssg
node walk back). I just hacked around this one and put in a global
array of panel objects with a (hopefully obvious) comment that these
should be per-aircraft when that capability arrived.

FlightGear is an old code base, and lots of the old assumptions (like
a single aircraft) need to be teased out of the code before progress
can be made on new features. This kind of work isn't glamorous, and
often requires more effort than the new development does. But it's
not brain surgery either. The problem with some great new features is
that they show up with code that is "ready" to integrate, but without
the integration work done. So they languish in the CVS tree until
everyone forgets about them. I can recall at least one occasion where
a unused module got replaced by a simpler (and arguably less
functional) one precicely because the original never got integrated
very well and the replacement actually worked.

The extreme programming cult manages to get this idea right (every
religion has a kernal of truth, right?) with their insistence on
constant refactoring and integration. Features are useless in
isolation.

Andy


https://sourceforge.net/p/flightgear/ma ... /34631875/
Richard wrote:the property tree as it is currently
is in need of some rework because of the ownship (single desktop
aircraft) approach. This is easier than it sounds - basically most of
the property tree becomes part of the aircraft and only a few items are
shared. This will also allow the switching of aircraft. The reason to
consider this now, and maybe not implement it, is to ensure that the
design will support this when it is time to implement it.
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: Dual control for Boeing 777

Postby bugman » Mon May 16, 2016 11:25 am

I would simply suggest trying out the lastest FlightGear code (or unstable nightly release). This could be due to the lost OSG scene graph branch problem that I recently fixed. That fix re-enabled the precipitation, but I predicted that there were a number of other broken branches that had not been noticed or reported yet.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Dual control for Boeing 777

Postby Hooray » Mon May 16, 2016 12:08 pm

Well, I am not sure - even if it /could/ in theory be related to the bug you mentioned/fixed, there would still be the indexing/addressing issue when dealing with otherwise identical models (think several instances of an AI/MP model) - thus, I suppose it really cannot be that simple, but I surely don't mind standing corrected obviously.

The only way I can see that working with "just" your fix, would be going through cmdarg() or some other kind of API that maps a 3D model to the Canvas/Nasal section.

However, I've sent a heads-up to TheTom (Canvas developer) so that he's aware of this discussion.
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: Dual control for Boeing 777

Postby bugman » Mon May 16, 2016 12:44 pm

I was working at a much higher level, with the organisation of the management, both creation and destruction, of the branches attached to the root of the scene graph. From the fix, I know that the scene graph branch with the aircraft may have been attached to the original root, which was then overwritten/hidden by a accidental second root. So the branch would be present, maybe even shown, but it would not accessible via "globals->get_scenery()" which would pull out the second root. With my fix, the second root is now no more, hence why I speculate that this could have an effect here.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 13 guests