Board index FlightGear Development Spaceflight

Space Shuttle - Development

Discussion about development and usage of spacecraft

Re: Space Shuttle - Development

Postby eatdirt » Mon Mar 22, 2021 7:33 pm

@EatDirt : Could you do a new merge request with last dev commits as stages.nas and common.xml changed quite a bit please ?


Yes, I will. I am just waiting for Wayne to push the latest grapple target on HST, then I need to adjust the position of the view to match it and we're good. So, for the time being, don't merge my merge request.

@EatDirt: Is it the intended behavior of the view to not rotate anymore with the mouse when the RMS power is switched to primary ?


Yes, in fact the view is ON only when the RMS is powered, and when the RMS is powered, you cannot move around, the field of view is along the arm , only zoom in/out are allowed as said in SCOM.
I have let the view free when the arm is not in use, but I can freeze it if you prefer guys.
eatdirt
 
Posts: 846
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Development

Postby eatdirt » Mon Mar 22, 2021 7:40 pm

At some point in the future we'll have Canvas views which will allow such views to appear within the main view, e.g. as an emulated TV screen.


That will be perfect, thanks for the info Jules.

I have a question/comment to anticipate this. Right now, the only way to change the view offsets dynamically is to change them on current view with some conditionals on which view is "current". If the canvas view lands, we cannot have that any more, there will be more than one current-view! Any plan for this?
eatdirt
 
Posts: 846
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Development

Postby GinGin » Mon Mar 22, 2021 7:50 pm

, the RMS thing needs to be a separate view beyond what the dialog does


Ah ok, I understand better.

So, for the time being, don't merge my merge request


Sure, I just copy/past the relevant piece of codes, and I am re learning everything about RMS anyway // level 0 :)

I have let the view free when the arm is not in use,


Ok, thanks for the highlights. I dont have any preferences about it.


@cdgae: Thanks for the news, that is a nice thing to follow.
GinGin
 
Posts: 1391
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby Hooray » Mon Mar 22, 2021 8:31 pm

eatdirt wrote in Mon Mar 22, 2021 7:40 pm:I have a question/comment to anticipate this. Right now, the only way to change the view offsets dynamically is to change them on current view with some conditionals on which view is "current". If the canvas view lands, we cannot have that any more, there will be more than one current-view! Any plan for this?


Right, that can actually be looked up on the wiki - in the pre-Compositor/CompositeViewer days, the idea was to port the existing view manager to get rid of tied properties, and to turn it into a class that supports multiple independent instances/objects (rather than a so called singleton). That way, you could have multiple view managers running concurrently without affecting each other.

This was actually what we discussed originally, but Jules ended up making quite a bit of progress when he started experimenting with CompositeViewer, and also had an immediate use-case back then (standalone/independent tower views IIRC), so that he came up with a new view manager called "sview" (step view). That approach means that that the original method won't be needed, because the new view manager (instance) could be controlled via its own properties directly.

There have also been some talks about phasing out the legacy view manager and replacing it with sview in the future - but we don't have any tests (unit testing), so that this seems unlikely to happen anytime soon, i.e. out of fear of breaking stuff.

So what seems most likely for the time being is that "sview" is going to be composite-viewer specific initially, because that would mean that the whole shebang (compositeviewer + step view) would remain strictly opt-in, i.e. zero chance to break view handling for aircraft not using those two features in combination, but aircraft starting up in compositeviewer mode would get independent view managers (and property tree locations) for each view/window.

If in doubt, share with Jules and Fernando what you need, and they might be able to provide pointers - but the "one view manager instance per viewer" approach would also be required for other Canvas-based use-cases, and it would be in line with the way canvas-elements provide their element-specific APIs/functionality in the form of properties underneath the root of the element - which is to say, this approach would make it very easy/convenient and straightforward to control the whole thing, even without requiring anything else (not even dedicated Nasal bindings).

Basically, the original idea was that each canvas view element would get its own view manager controlling a compositeviewer window rendering into a compositor buffer, whereas each component (compositor + compositeviewer + view manager) would expose relevant setup attributes/parameters in the form of view specific properties that can be individually controlled.
But again, many of these original plans became kinda obsolete when the two compositor/compositeviewer efforts made so much progress at the same time.

PS: All that being said, I am not sure if the CV mode is currently of much use for the shuttle's RMS specifically, because I seem to recall that the corresponding CV views don't currently support event handling - so that might be best to check next before spending any time on implementing this, only to realize that keyboard/mouse event handling isn't working for those views (unless of course, that's not needed :?: )
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: 12197
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle - Development

Postby cgdae » Mon Mar 22, 2021 10:49 pm

eatdirt wrote in Mon Mar 22, 2021 7:40 pm:I have a question/comment to anticipate this. Right now, the only way to change the view offsets dynamically is to change them on current view with some conditionals on which view is "current". If the canvas view lands, we cannot have that any more, there will be more than one current-view! Any plan for this?

Yes, we can actually already do this.

Extra view windows use a new view system called Sview which is short for 'step view', where one configures an arbitrary number of individual steps that end up defining the camera position and orientation. There are a number of different step types defined which allow for various transformations such as moving to a particular user/multiplayer aircraft or nearest tower, move relative to the current position+direction, modify heading, pitch and roll according to particular property values, rotate view direction to point at a particular target etc. One can specify the exact desired sequence of steps by passing XML to the view-new command; see https://sourceforge.net/p/flightgear/flightgear/ci/8f5dc3e764a80e2e56efdb174653cd5fd2dfa7b1/tree/src/Viewer/sview.hxx for details.

These basic steps are enough to allow Sview to copy what conventional views do, allowing the 'Add clone view' menu item to work - this opens a new window with a copy of the current view, which is then independent of the main window's view.

It's easy enough to add (C++) code to implement new steps, including more sophisticated things. For example there is a view step that keeps two aircraft visible at all times, with one in the foreground. See https://wiki.flightgear.org/CompositeViewer_Support for details and demonstration videos.

It might be interesting to try to define the Shuttle arm view (apologies if that's the wrong name) as an Sview in its own top-level window. Apart from anything else i'd like to make sure that Sview supports whatever requires; i'd imagine that we would have one Sview step for each hinge/link in the arm for example, and this might need a new Sview step type.

It would also be a useful incentive to getting Canvas views working.

Thanks,

- Jules
cgdae
 
Posts: 66
Joined: Tue May 31, 2016 7:35 pm

Re: Space Shuttle - Development

Postby wlbragg » Wed Mar 24, 2021 1:33 am

Sorry for the delay Chris, I pushed the HST target texture, HST target mesh and RMS wrist roll 180 deg offset.
I hope this is what you wanted. If not, let me know what needs changed.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
wlbragg
 
Posts: 6041
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: Space Shuttle - Development

Postby eatdirt » Wed Mar 24, 2021 12:58 pm

I hope this is what you wanted. If not, let me know what needs changed.


Thanks a lot Wayne, I'll test all that tonight.

Edit: Well, the texturing and model are perfect, but the orientation not. Let me give it a try with blender, I'll call for help with more detailed instructions at some point. But, we should not touch the arm wrist roll, I am almost sure about that. At best it changes nothing, at worse, it changes everything!
Last edited by eatdirt on Wed Mar 24, 2021 8:24 pm, edited 2 times in total.
eatdirt
 
Posts: 846
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Development

Postby Thorsten » Wed Mar 24, 2021 1:07 pm

@wlbragg - could it be that we have no FRCS valve switches functional at all? Internally the whole FRCS valve logic is there, it just seems missing from the cockpit...
Thorsten
 
Posts: 12022
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

Postby wlbragg » Wed Mar 24, 2021 3:47 pm

Where or what panel they are supposed to be on? I didn't find anything in a cursory search through the SCOM. I don't know exactly what I am looking for though.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
wlbragg
 
Posts: 6041
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: Space Shuttle - Development

Postby GinGin » Wed Mar 24, 2021 5:02 pm

It is those switches Wayne, forward RCS that indeed are not activated in the cockpit, but are coded logical wise with the canvas for interactions.

Image
GinGin
 
Posts: 1391
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby wlbragg » Wed Mar 24, 2021 5:52 pm

Ok, should be able to figure out the mapping.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
wlbragg
 
Posts: 6041
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: Space Shuttle - Development

Postby Hooray » Wed Mar 24, 2021 5:58 pm

Regarding that screen shot, that's actually another potential use-case for canvas views: Once we can render arbitrary camera views to a texture/canvas, we can also render "in-cockpit" views to a Canvas to provide GUI dialogs for relevant cockpit panels without having to re-do those in scripting space using PUI/XML, just by aiming the corresponding view at the panel: Conceptually, a flat view could still support Canvas event handling by forwarding mouse/keyboard events to the corresponding 3D models.

Thus, complex cockpit panels could get UI dialogs "auto-magically" by specifying camera views that render the corresponding panel views onto a GUI dialog.
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: 12197
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle - Development

Postby Thorsten » Wed Mar 24, 2021 6:17 pm

Thus, complex cockpit panels could get UI dialogs "auto-magically" by specifying camera views that render the corresponding panel views onto a GUI dialog.


Well, since you still have to handle the mouse events, you can equally well take the 10 seconds to take a screenshot and do events on that one as we do now. Rendering a separate camera view sounds like overdesign.
Thorsten
 
Posts: 12022
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

Postby Hooray » Wed Mar 24, 2021 6:41 pm

right, depends on the point of view: screen shot based UI dialogs may obviously get out of sync with the 3D model, rendering simply a frontal camera view onto a texture is automatically up to date, and additional cameras passes are relatively cheap in comparison. Besides, events can be forwarded to the real cockpit, too - in other words, no need to explicit Canvas event handlers if you forward events to the 3D model in question.

So, the question if it's overdesign or not, depends on the complexity of the aircraft/cockpit in question, i.e. the number of dedicated UI dialogs for each panel.

Again, I am not saying this is the right thing to do, just stating that this will be possible and that we can evaluate whether it makes sense or not. I guess time will tell, but obviously some of the most complex cockpits, i.e. those with a ton of displays and panels/switches will benefit the most - because the break-even point is not that far away compared to managing, say, 12+ dedicated UI dialogs and 10+ switches per dialog - at that point, it will be much less work to simply tell FlightGear to register a corresponding view, render that to a canvas and/or an external OSG window, and simply pass keyboard/mouse events to the underlying 3D model (which also means both views will be in sync automatically without requiring explicit synchronization)
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: 12197
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle - Development

Postby Vinny002 » Wed Mar 24, 2021 7:16 pm

Hi guys, question for you. How is the new version of the stable space shuttle for FG coming along? Thanks! Cheers, Vincent.
Vinny002
 
Posts: 75
Joined: Mon Jul 01, 2019 8:55 pm

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 2 guests