SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

Status
Not open for further replies.

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
I thought I would start this thread to centralize all the VC update discussions and I'll to do by quoting GLS's MDU reply from the main development thread:

So I started the "MFD revolution" in the Orbiter2016 branch (should we create a SSU 4.0 to 5.0 thread for this?) by making a very very simple MFD for the Centaur vessel to display the info up to now shown in the HUD. It uses the 'T' key so it will not work with the keyboard as it collides with CRTMFD, but as when this is all done the CRTMFD will not be accessible from the Centaur (or anywhere else), this conflict will solve itself.
In the future we can have all kinds of pretty drawings in there, but for now I think just the numbers works fine.
IUS is next, and then the CRTMFD which will have to be done in parts: move the MFD into the vessel, change to sketchpad, add D3D9 goodies, move the subsystem displays into the MDU class (not in this particular order).

Is there anything mesh-wise that needs to change for best possible performance with the new MDUs?
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Is there anything mesh-wise that needs to change for best possible performance with the new MDUs?

Not sure, we could of course for example improve the event timers and MET clocks, which are really consuming a lot of FPS.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Not sure, we could of course for example improve the event timers and MET clocks, which are really consuming a lot of FPS.
In what way do they need to improved? Don't they already use the same technique as the new TBs?
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
In what way do they need to improved? Don't they already use the same technique as the new TBs?

AFAIR not yet, but they should. Same for the RCS/OMS propellant indicators.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
OK. Anything else while I'm at it?

Not sure, would need to check it...for example the warning lights. I think it is already using the new standard.

Technically, we don't need any blitting operation in SSU except the CRTs and even there it is only temporary needed.

What I would like to suggest is separating SSU development directory and the Orbiter directory used for testing and libraries, using a deploy script to make sure that we also test according to the files we are going to include in a release. I have a test of this here on my PC for another project and it works fine with 2010 and 2016.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
I was thinking about when we get the panels all separated and fix all the little problems that exist in the vc, we should also upgrade all the (remaining) talkbacks, lights and LEDs to the "UV-system".
I remember seeing some images of the new Orbiter version in which the vc panels on the default Atlantis had a back light. We could at least get the new panels ready for that when they are separated, so in the future that can be done "easily". A thing that stopped me from already upgrading some lights is that in the real vehicle, the light intensity is controllable. I don't know if/how that is possible to do in the new Orbiter, but if it is possible we should at least plan for it.
About the current 7-disp LED lights, a vc component will have to be crafted for them to "automate" displaying stuff (I still haven't sat down to fully think it :(), and the mesh groups that already exist will have to be resized as I think they are overlapping each other.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
I was thinking about when we get the panels all separated and fix all the little problems that exist in the vc, we should also upgrade all the (remaining) talkbacks, lights and LEDs to the "UV-system".
I remember seeing some images of the new Orbiter version in which the vc panels on the default Atlantis had a back light. We could at least get the new panels ready for that when they are separated, so in the future that can be done "easily". A thing that stopped me from already upgrading some lights is that in the real vehicle, the light intensity is controllable. I don't know if/how that is possible to do in the new Orbiter, but if it is possible we should at least plan for it.

I already researched this feature, but on the DG in Orbiter beta, it used an undocumented mesh flag. If I would know how this all works, I would implement it on SSU as well. But right now, I can't guarantee it to work.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
About the MDU screens, currently they are 2 parts ("main" display and menu)... I don't really see the point in that, and anyway we need to manually the menu completly if we are to do it like the real think.

Another thing that I don't think is going to be easy, is making the vc structure (no panels) such that we can then have the correct overhead panel configuration on Columbia. They were a bit different due to the ejection panels.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
About the MDU screens, currently they are 2 parts ("main" display and menu)... I don't really see the point in that, and anyway we need to manually the menu completly if we are to do it like the real think.

Another thing that I don't think is going to be easy, is making the vc structure (no panels) such that we can then have the correct overhead panel configuration on Columbia. They were a bit different due to the ejection panels.

Its a legacy of the MFD implementation of Orbiter, for supporting standard orbiter MFDs. Not needed if we do away with generic MFDs.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
I already researched this feature, but on the DG in Orbiter beta, it used an undocumented mesh flag. If I would know how this all works, I would implement it on SSU as well. But right now, I can't guarantee it to work.

If we need time to "learn" things, then I say we wait on the vc upgrade, and when we're ready we do it in one go. There are plenty of other things to do in the meantime.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
If we need time to "learn" things, then I say we wait on the vc upgrade, and when we're ready we do it in one go. There are plenty of other things to do in the meantime.

Sorry, I have to disagree. There is no reason right now to do it all in one large step. We can afford smaller steps and we should do so. Should we need dramatic changes to the mesh for panel lighting, we should do so. But right now, it looks like we don't have to worry, the DG meshes in the beta are not showing magic.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
Its a legacy of the MFD implementation of Orbiter, for supporting standard orbiter MFDs. Not needed if we do away with generic MFDs.

I haven't thought about how it will work with just one texture, but I think it has to be done somehow. Right now in the MFD world, we can get a better CRTMFD without "making many waves", by changing to sketchpad and by making it SSU-specific. The single texture thing should be done with the vc panel upgrade.

---------- Post added at 12:12 AM ---------- Previous post was at 12:09 AM ----------

Sorry, I have to disagree. There is no reason right now to do it all in one large step. We can afford smaller steps and we should do so. Should we need dramatic changes to the mesh for panel lighting, we should do so. But right now, it looks like we don't have to worry, the DG meshes in the beta are not showing magic.

Like I said, I don't know the specifics of that "new technology" and if we can use it or not. If we can use it, and since we are going to be touching pretty much every texture in the vc, I think it's a waist of time to do that process twice.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Like I said, I don't know the specifics of that "new technology" and if we can use it or not. If we can use it, and since we are going to be touching pretty much every texture in the vc, I think it's a waist of time to do that process twice.

Sure, but we also inflate the risks. Without some kind of automatic quality assurance, I would not recommend trying something like that. Better keep the steps as big as we can test them.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
The VC needs updating just to fit the current orbiter mesh. Currently the the aft flight deck doesn't line up properly with the orbiter. These screenshots shows it well.

SSU_VC_alignment.jpg


SSU_VC_alignment_2.jpg
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
Sure, but we also inflate the risks. Without some kind of automatic quality assurance, I would not recommend trying something like that. Better keep the steps as big as we can test them.

It will have to be done in a branch anyway, as once we start it will not work until all the panels are finished, so I don't think it increases risks of ending up with something that doesn't work.
We don't need to do the back lighting right away, but if that is possible, let's plan for it and leave that door unlocked. As for the variable intensity on the annunciator lights/LEDs, as we need them to work now, (again, if it's possible to do) we could get that intensity control to work when the lights are upgraded.

---------- Post added at 12:48 AM ---------- Previous post was at 12:38 AM ----------

The VC needs updating just to fit the current orbiter mesh. Currently the the aft flight deck doesn't line up properly with the orbiter. These screenshots shows it well.

SSU_VC_alignment.jpg


SSU_VC_alignment_2.jpg

Yes it needs. I'm just saying that as we need to fix that and other things there, we could save some time in texture editing, mesh editing, code editing, coordinate correction, and do it in one go. I see little point in resizing the vc, updating all the switch coordinates and then sometime later having to rework it all again to separate the panels, or to add lights or something else. :2cents:
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
So which way should be the path forward? The panel separation isn't compatible with keeping the current VC intact with only minor fixes.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
So which way should be the path forward? The panel separation isn't compatible with keeping the current VC intact with only minor fixes.

IMO, here is the TODO list:
>> resize vc
>> separate panels (and allow OV-102 cockpit to be simulated)
>> fix some wrong switch types, buttons, covers, positions, etc
>> update remaining talkbacks
>> update lights (and if there's a way to do it, allow variable intensity immediatly or in the future)
>> (if there's a way to do it) prepare panels for future back light work (maybe also with variable intensity)

The last 2 points might require some research (and maybe standalone testing) to be done. I still haven't looked at how that works, or would work, so I can't tell much other than let's try and not have to redo things in a few months.
But if the rest of the project feels like this has to be done ASAP, even at the risk of in the future needing to redo all the textures to have the variable lights and/or back lights, who am I to say no.

---------- Post added 06-13-16 at 02:31 AM ---------- Previous post was 06-12-16 at 01:15 PM ----------

I just committed the CRTMFD change to a SSU specific MFD. There's a bug that I can't fix that causes the CRTMFD name not to show in the menu buttons, although it still shows in the display and the button still works as normal. I'm not creating a ticket yet as I want to check this in the default Atlantis and make sure it isn't an Orbiter issue, because I didn't change anything else except the registration.

Before I start with the sketchpad update I'll do some changes to the way things are saved, that am fairly confident will fix all the issues with saving the display/menu state.

BTW: the VS2013 will need to be updated to deal with the deletion of the CRTMFD project in the OrbitersimBeta branch.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Could we maybe resolve the VC2013/2015 duplication issues by porting to CMake? I have started learning it for the C server component at work, it automatically detects the Visual C++ version installed and generates project and solution files for the version, as well as building the files.

Makes a good appearance so far, much better than the native code plugin of gradle, which complains a lot and pretty confusing about external dependencies.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
Could we maybe resolve the VC2013/2015 duplication issues by porting to CMake? I have started learning it for the C server component at work, it automatically detects the Visual C++ version installed and generates project and solution files for the version, as well as building the files.

Makes a good appearance so far, much better than the native code plugin of gradle, which complains a lot and pretty confusing about external dependencies.

Does it work for vs2010? And does it work without me touching makefiles :)compbash:)? :lol:
 
Status
Not open for further replies.
Top