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

Status
Not open for further replies.
AFAIK, the aft MDU (aft ADI in MCDS) is +/- standalone... so I'd treat that as another panel (and that's how we have it implemented). The CCTV monitors are panel A3.
I see. So when everything is done, will we have any use for VC.msh? It is nothing but Cockpit.msh with the detailed panels overlaid on it. Cockpit.msh is what we use to render the flight deck when in exterior camera mode. I have been working on correcting it so it fits the orbiter again and some other issues I have noticed (mainly texture mapping issues which seems have been there for quite some time).

Once all of the fixes have been applied, I'll check it in.
 
I see. So when everything is done, will we have any use for VC.msh? It is nothing but Cockpit.msh with the detailed panels overlaid on it. Cockpit.msh is what we use to render the flight deck when in exterior camera mode. I have been working on correcting it so it fits the orbiter again and some other issues I have noticed (mainly texture mapping issues which seems have been there for quite some time).

Once all of the fixes have been applied, I'll check it in.
About that mesh, could something be added to it to close ticket 115? Even a 5-sided "box" with a cheap texture would work IMO, as we just need to have something to look at and give the impression that there's something inside.

On the vc my idea is to have a base vc mesh (VC.msh) with the structures on which the panels are mounted (and maybe seats, etc... i.e., the static stuff), and then we would load the individual panel meshes as needed.
My only doubt about this is whether or not just one base mesh can handle (1) Columbia's ejection panels (both active and inactive) and the rest of the fleet, (2) the MCDS and MEDS and (3) MCDS with HUD and without it. Probably some more thinking must go into how to choose between all these options...
 
On the vc my idea is to have a base vc mesh (VC.msh) with the structures on which the panels are mounted (and maybe seats, etc... i.e., the static stuff), and then we would load the individual panel meshes as needed.
That's what the Cockpit.msh really is. It is just the static stuff (seats, HUDs and the flight deck strucrture). VC.msh is just Cockpit.msh with the actual dynamic VC stuff (high-res textures, switches, rotaries, MDUs etc) added. So what you're essentially doing by separating the panels is regressing VC.msh back to Cockpit.msh.

So what I'm suggesting is deleting either Cockpit.msh or VC.msh and just using one of them to be rendered in both VC mode and external camera mode. This will simplify maintenance in the future.
 
So what I'm suggesting is deleting either Cockpit.msh or VC.msh and just using one of them to be rendered in both VC mode and external camera mode. This will simplify maintenance in the future.

It would be much better to have a reduce poly count cockpit in external view. But we can switch to display one or the other, not both at once.
 
That's what the Cockpit.msh really is. It is just the static stuff (seats, HUDs and the flight deck strucrture). VC.msh is just Cockpit.msh with the actual dynamic VC stuff (high-res textures, switches, rotaries, MDUs etc) added. So what you're essentially doing by separating the panels is regressing VC.msh back to Cockpit.msh.

So what I'm suggesting is deleting either Cockpit.msh or VC.msh and just using one of them to be rendered in both VC mode and external camera mode. This will simplify maintenance in the future.

It would be much better to have a reduce poly count cockpit in external view. But we can switch to display one or the other, not both at once.
This.
 
It would be much better to have a reduce poly count cockpit in external view. But we can switch to display one or the other, not both at once.
I guess I wasn't clear enough: The actual VC panels, they would only be displayed in VC mode. But both modes would share the same base structure mesh. The now separated panels is added to the base structure mesh in code rather than being hard parts of a what amounts to a cloned version of the base structure mesh.

That is what I'm proposing.
 
I guess I wasn't clear enough: The actual VC panels, they would only be displayed in VC mode. But both modes would share the same base structure mesh. The now separated panels is added to the base structure mesh in code rather than being hard parts of a what amounts to a cloned version of the base structure mesh.

That is what I'm proposing.

Still I don't think it's necessary to have the same level of details inside vs outside, both texture wise and mesh parts (THC, RHC, etc...).
:2cents:
 
Still I don't think it's necessary to have the same level of details inside vs outside, both texture wise and mesh parts (THC, RHC, etc...).
:2cents:
The load isn't that bad. We're talking about 3.9k surfaces and about 5.2k vertices. The orbiter mesh itself is much worse. And it is using three textures, two with a 1024x1024 resolution and one with a 2048x2048 resolution. This is nothing to modern hardware. Even Wolf's super-hires (8192x8192) photo-realistic textures are easy on my machine (3 year old 4690K which is officially EoL, 2.5 year old GeForce GTX 970, 16 GB HyperX Savage DDR3 RAM).

So, unless you're running an IGPU, things are not as bad as they might seem. More than likely, you're running software that puts more strain on your hardware than Orbiter will for the next while.

I'm proposing this for easy of maintenance. This is the entire mesh:

https://www.dropbox.com/s/g71mpzq94ypbo7q/AC3D_VC_Base_Mesh.jpg?dl=0
 
The load isn't that bad. We're talking about 3.9k surfaces and about 5.2k vertices. The orbiter mesh itself is much worse. And it is using three textures, two with a 1024x1024 resolution and one with a 2048x2048 resolution. This is nothing to modern hardware. Even Wolf's super-hires (8192x8192) photo-realistic textures are easy on my machine (3 year old 4690K which is officially EoL, 2.5 year old GeForce GTX 970, 16 GB HyperX Savage DDR3 RAM).

So, unless you're running an IGPU, things are not as bad as they might seem. More than likely, you're running software that puts more strain on your hardware than Orbiter will for the next while.

I'm proposing this for easy of maintenance. This is the entire mesh:

https://www.dropbox.com/s/g71mpzq94ypbo7q/AC3D_VC_Base_Mesh.jpg?dl=0

I understand your point of view, but when was the last time this external vc mesh was changed, and when will be it be changed again? I don't see the need for much maintenance there, except maybe delete it and always show the full vc when PC speeds increase enough. :shrug:
My only complaint with the external vc mesh is ticket 115. Other than that I'd leave it alone and worry about the internal one.

... and yes, I'm currently running Orbiter in the IGPU as I think I somehow fried my 720M (still haven't "debugged" it.... :facepalm:)
 
Most of the action is in the PLBY, while in external view anyway. Maybe an astronaut or 2 looking out would look cool.
 
Most of the action is in the PLBY, while in external view anyway. Maybe an astronaut or 2 looking out would look cool.

I generally think some astronauts in the Shuttle could not be wrong. :lol:
 
Just committed a "recent looking" panel R2... it's way too hard to do 3D model editing by hand. :uhh:
I corrected a few details in the APU/WSB area, and wanted to also correct the click area for panel R2, as it overlaps with R1, but I can't do it.
Anyway, I'd like to know the source of the original panel R2 config (committed by Urwumpe, 9 years ago), as it might/will be useful in the future.

BTW 1: as I'm separating the panels I'm renaming the controls as correctly as I can, and ordering them by material. If something in the naming doesn't add up, please give me a chance to explain what I did.
BTW 2: could mesh "templates" be created for switches, guards, covers, etc? It seems there are several versions of most things, and then each one uses a different texture instead of maybe having one (small) texture for those elements.
 
Just committed a "recent looking" panel R2... it's way too hard to do 3D model editing by hand. :uhh:
I corrected a few details in the APU/WSB area, and wanted to also correct the click area for panel R2, as it overlaps with R1, but I can't do it.
Anyway, I'd like to know the source of the original panel R2 config (committed by Urwumpe, 9 years ago), as it might/will be useful in the future.

Had been based on the meshes that I got at that time and those had been based on the Atlantis VC mesh AFAIR. At that time, I was knowing almost nothing about the Shuttle and believed anything. :D
 
Had been based on the meshes that I got at that time and those had been based on the Atlantis VC mesh AFAIR. At that time, I was knowing almost nothing about the Shuttle and believed anything. :D

462928main_GPN-2000-001083_full.jpg

This picture from STS-7 shows a panel R2 that is very similar, if not equal, to our "old" panel R2, so it wasn't invented. :lol:
 
Well, I am pretty sure, we might have some "anachronisms" hiding in our add-on.

But don't ask me about a good quick way to fix them. We have no reference period to limit the work right now, except maybe giving the MEDS era some preference.
 
Well, I am pretty sure, we might have some "anachronisms" hiding in our add-on.

But don't ask me about a good quick way to fix them. We have no reference period to limit the work right now, except maybe giving the MEDS era some preference.

Yes, I'm also giving priority to MEDS. But (I hope) we'll eventually do MCDS, as well as panel evolutions, so having all info is precious.

BTW, a bit of "info" I want to leave here: the "thumbwheel" switches in panels C2, A6U, A1, O7, and the audio panels (can't remember the names now) are the original "control". Eventually they were discontinued and replaced by "pushwheel" switches. As the thumbwheels are the original "control" and our "default orbiter", Atlantis, used thumbwheels to the end (as did Columbia) I say we give priority to putting thumbwheels in the panels, and latter add panel versions with the pushwheels for Discovery and Endeavour.
 
GLS, I just saw you added AddMeshes as function to PanelGroup - are you sure this makes sense? PanelGroup was intended to just handle the visibility of panel meshes at most, not change the mesh structure of the orbiter. I think you open a whole new can of worms with that change, since now the mesh indices are local knowledge of the panel group and no longer found by the panels for defining the animations.
 
GLS, I just saw you added AddMeshes as function to PanelGroup - are you sure this makes sense? PanelGroup was intended to just handle the visibility of panel meshes at most, not change the mesh structure of the orbiter. I think you open a whole new can of worms with that change, since now the mesh indices are local knowledge of the panel group and no longer found by the panels for defining the animations.

Hmmm, my idea was having a member in the PanelGroup that called all the panels inside to add their meshes.... instead of having pointers to every panel in the Atlantis class. So now instead of this:
Code:
PanelX1* pPanelX1;
PanelX2* pPanelX2;
PanelY1* pPanelY1;
PanelY2* pPanelY2;
// (...)
if (pPanelX1) pPanelX1->AddMeshes( VC_OFFSET );
if (pPanelX2) pPanelX2->AddMeshes( VC_OFFSET );
if (pPanelY1) pPanelY1->AddMeshes( VC_OFFSET );
if (pPanelY2) pPanelY2->AddMeshes( VC_OFFSET );
we have this:
Code:
pgX->AddMeshes( VC_OFFSET );
pgY->AddMeshes( VC_OFFSET );

As the PanelGroup is "holding" the panels, IMO it can call them... nothing else. The mesh id stuff is still all inside each panel class, as initially implemented on panels A8 and the ODS one (whatever its name is).
Is that no good?
 
Not sure, I can't look into the code easily to make a good statement here.

I think this solution violates SOLID even more than the stuff I did before, and we should better fix this, instead of adding to the lava flow.

We should have a single responsibility in our classes and the PanelGroups already has one (Managing the event handling for multiple panels belonging to the same physical assembly). This way, we can also avoid nasty circular dependencies.

Also, I think the list of meshes that compromise our add-on should be defined somewhere near the class Atlantis. If we want to swap panels, we should keep the mesh index the same, because changing the mesh order is a common source of animation problems.



What if two panels share the same mesh? Split into more tiny meshes? (eg, middeck)

How can we handle configuration changes later, like changing the panels during run-time (as needed for going from a flown mission to the next mission).

I know, I am responsible for the current mess. The person who developed this was 9 years less experienced than I am now.
 
"AddMeshes" changes:
Atlantis.cpp
Code:
-		if (pPanelC3) pPanelC3->AddMeshes( VC_OFFSET );
-		if (pPanelA6U) pPanelA6U->AddMeshes( VC_OFFSET );
-		if (pA7A8Panel) pA7A8Panel->AddMeshes(VC_OFFSET);
-		if (pPanelA8) pPanelA8->AddMeshes(VC_OFFSET);
-		if (pPanelO1) pPanelO1->AddMeshes( VC_OFFSET );
-		if (pPanelO2) pPanelO2->AddMeshes( VC_OFFSET );
-		if (pPanelO3) pPanelO3->AddMeshes( VC_OFFSET );
-		if (pPanelO6) pPanelO6->AddMeshes( VC_OFFSET );
-		if (pPanelO8) pPanelO8->AddMeshes( VC_OFFSET );
-		if (pPanelO17) pPanelO17->AddMeshes( VC_OFFSET );
-		if (pPanelL1) pPanelL1->AddMeshes( VC_OFFSET );
-		if (pPanelL10) pPanelL10->AddMeshes( VC_OFFSET );
-		if (pPanelL12U_IUS) pPanelL12U_IUS->AddMeshes( VC_OFFSET );
-		if (pPanelL12U_Centaur) pPanelL12U_Centaur->AddMeshes( VC_OFFSET );
-		if (pPanelR1) pPanelR1->AddMeshes( VC_OFFSET );
-		if (pPanelR2) pPanelR2->AddMeshes( VC_OFFSET );
-		if (pPanelR13L) pPanelR13L->AddMeshes( VC_OFFSET );
-
+		pgForward.AddMeshes( VC_OFFSET );
 		pgForward.DefineVC();
 		pgForward.DefineVCAnimations(mesh_vc);
 
+		pgLeft.AddMeshes( VC_OFFSET );
 		pgLeft.DefineVC();
 		pgLeft.DefineVCAnimations(mesh_vc);
 
+		pgCenter.AddMeshes( VC_OFFSET );
 		pgCenter.DefineVC();
 		pgCenter.DefineVCAnimations(mesh_vc);
 
+		pgRight.AddMeshes( VC_OFFSET );
 		pgRight.DefineVC();
 		pgRight.DefineVCAnimations(mesh_vc);
 
+		pgOverhead.AddMeshes( VC_OFFSET );
 		pgOverhead.DefineVC();
 		pgOverhead.DefineVCAnimations(mesh_vc);
 
+		pgOverheadAft.AddMeshes( VC_OFFSET );
 		pgOverheadAft.DefineVC();
 		pgOverheadAft.DefineVCAnimations(mesh_vc);
 
+		pgAftPort.AddMeshes( VC_OFFSET );
 		pgAftPort.DefineVC();
 		pgAftPort.DefineVCAnimations(mesh_vc);
 
+		pgAft.AddMeshes( VC_OFFSET );
 		pgAft.DefineVC();
 		pgAft.DefineVCAnimations(mesh_vc);
 
+		pgAftStbd.AddMeshes( VC_OFFSET );
 		pgAftStbd.DefineVC();
 		pgAftStbd.DefineVCAnimations(mesh_vc);

PanelGroup.h
Code:
+	template <class TVessel>
+	void PanelGroup<TVessel>::AddMeshes( const VECTOR3& ofs )
+	{
+		for(unsigned int i = 0; i<panels.size(); i++)
+			panels.at(i)->AddMeshes( ofs );
+	}


Changes (in red) to panel class to make it use its own mesh (as originally implemented on A8 and others) (PanelO17 as example)
.cpp
Code:
#include "PanelO17.h"
#include "../Atlantis.h"
#include "../Atlantis_defs.h"
[COLOR="Red"]#include "..\CommonDefs.h"
#include "..\meshres_vc_o17.h"[/COLOR]


namespace vc
{

	PanelO17::PanelO17(Atlantis* psts):AtlantisPanel(psts, "O17")
	{
		[COLOR="Red"]hPanelMesh = oapiLoadMeshGlobal( DEFAULT_MESHNAME_PANELO17 );
		mesh_index = MESH_UNDEFINED;[/COLOR]

		Add(pEIUPowerLC = new StdSwitch2(psts, "EIU L-C"));
		Add(pEIUPowerCR = new StdSwitch2(psts, "EIU C-R"));
		Add(pEIUPowerRL = new StdSwitch2(psts, "EIU R-L"));

		pEIUPowerLC->SetLabel(1, "OFF");
		pEIUPowerLC->SetLabel(0, "ON");
		pEIUPowerLC->SetOnPosition(0);
		pEIUPowerCR->SetLabel(1, "OFF");
		pEIUPowerCR->SetLabel(0, "ON");
		pEIUPowerCR->SetOnPosition(0);
		pEIUPowerRL->SetLabel(1, "OFF");
		pEIUPowerRL->SetLabel(0, "ON");
		pEIUPowerRL->SetOnPosition(0);

		Add( pMECPower[0] = new StdSwitch2( psts, "MEC 1 Power" ) );
		pMECPower[0]->SetLabel( 1, "OFF" );
		pMECPower[0]->SetLabel( 0, "ON" );
		pMECPower[0]->SetOnPosition( 0 );
		Add( pMECPower[1] = new StdSwitch2( psts, "MEC 2 Power" ) );
		pMECPower[1]->SetLabel( 1, "OFF" );
		pMECPower[1]->SetLabel( 0, "ON" );
		pMECPower[1]->SetOnPosition( 0 );
	}

	PanelO17::~PanelO17()
	{
	}
[COLOR="Red"]
	void PanelO17::AddMeshes( const VECTOR3 &ofs )
	{
		SetHasOwnVCMesh();

		if (mesh_index == MESH_UNDEFINED)
		{
			mesh_index = STS()->AddMesh( hPanelMesh, &ofs );
			STS()->SetMeshVisibilityMode( mesh_index, MESHVIS_VC );
		}
		return;
	}

	void PanelO17::SetMeshVisibility( bool visible )
	{
		if (visible) STS()->SetMeshVisibilityMode( mesh_index, MESHVIS_VC );
		else STS()->SetMeshVisibilityMode( mesh_index, MESHVIS_NEVER );
		return;
	}

	UINT PanelO17::GetVCMeshIndex( void ) const
	{
		return mesh_index;
	}[/COLOR]

	void PanelO17::DefineVC()
	{
		const VECTOR3 SWITCH_ROT = _V(-0.788502306017, 0.615031798693, 0.0);
		AddAIDToMouseEventList(AID_O17);

		pEIUPowerLC->SetInitialAnimState(0.5f);
		pEIUPowerLC->DefineSwitchGroup(GRP_S8_O17_VC);
		pEIUPowerLC->SetReference(_V(0.7605, 3.1545, 13.336), SWITCH_ROT);
		pEIUPowerLC->SetMouseRegion(0.073f, 0.625f, 0.159f, 0.7f);

		pEIUPowerCR->SetInitialAnimState(0.5f);
		pEIUPowerCR->DefineSwitchGroup(GRP_S7_O17_VC);
		pEIUPowerCR->SetReference(_V(0.78925, 3.1325, 13.336), SWITCH_ROT);
		pEIUPowerCR->SetMouseRegion(0.171f, 0.625f, 0.265f, 0.7f);

		pEIUPowerRL->SetInitialAnimState(0.5f);
		pEIUPowerRL->DefineSwitchGroup(GRP_S9_O17_VC);
		pEIUPowerRL->SetReference(_V(0.81725, 3.1105, 13.3365), SWITCH_ROT);
		pEIUPowerRL->SetMouseRegion(0.270f, 0.625f, 0.362f, 0.7f);

		pMECPower[0]->SetInitialAnimState( 0.5f );
		pMECPower[0]->DefineSwitchGroup( GRP_S5_O17_VC );
		pMECPower[0]->SetReference( _V( 0.8507, 3.0852, 13.4520 ), SWITCH_ROT );
		pMECPower[0]->SetMouseRegion( 0.296503f, 0.365015f, 0.346141f, 0.413497f );

		pMECPower[1]->SetInitialAnimState( 0.5f );
		pMECPower[1]->DefineSwitchGroup( GRP_S6_O17_VC );
		pMECPower[1]->SetReference( _V( 0.8507, 3.0852, 13.4520 ), SWITCH_ROT );
		pMECPower[1]->SetMouseRegion( 0.390501f, 0.365165f, 0.439871f, 0.412690f );
	}

	void PanelO17::RegisterVC()
	{
		AtlantisPanel::RegisterVC();
		VECTOR3 ofs = STS()->GetOrbiterCoGOffset() + VC_OFFSET;

		oapiVCRegisterArea(AID_O17, PANEL_REDRAW_NEVER, PANEL_MOUSE_LBDOWN | PANEL_MOUSE_LBUP);
		oapiVCSetAreaClickmode_Quadrilateral(AID_O17, 
			_V(0.721, 3.186, 13.609)+ofs, _V(1.021, 2.949, 13.609)+ofs, 
			_V(0.721, 3.186, 13.205) + ofs, _V(1.021, 2.952, 13.242)+ofs);
	}

[COLOR="Red"]	void PanelO17::DefineVCAnimations( UINT vcidx )
	{
		AtlantisPanel::DefineVCAnimations( mesh_index );
		return;
	}[/COLOR]

	void PanelO17::Realize()
	{
		DiscreteBundle* pBundle = STS()->BundleManager()->CreateBundle( "O17_to_EIU_AC", 3 );
		pEIUPowerLC->output.Connect( pBundle, 0 );// AC2
		pEIUPowerCR->output.Connect( pBundle, 1 );// AC1
		pEIUPowerRL->output.Connect( pBundle, 2 );// AC3

		pBundle = STS()->BundleManager()->CreateBundle( "O17_MEC", 2 );
		pMECPower[0]->output.Connect( pBundle, 0 );
		pMECPower[1]->output.Connect( pBundle, 1 );
		AtlantisPanel::Realize();
	}
};

.h
Code:
#include "AtlantisPanel.h"
#include "StandardSwitch.h"

namespace vc {

	class PanelO17 : public AtlantisPanel {
		[COLOR="Red"]MESHHANDLE hPanelMesh;
		UINT mesh_index;[/COLOR]

		StdSwitch2* pEIUPowerLC;
		StdSwitch2* pEIUPowerCR;
		StdSwitch2* pEIUPowerRL;

		StdSwitch2* pMECPower[2];
	public:
		PanelO17(Atlantis* psts);
		virtual ~PanelO17();

		[COLOR="Red"]virtual void AddMeshes( const VECTOR3& ofs );
		virtual void SetMeshVisibility( bool visible );
		virtual UINT GetVCMeshIndex( void ) const;[/COLOR]
		virtual void DefineVC();
		virtual void RegisterVC();
		[COLOR="Red"]virtual void DefineVCAnimations( UINT vcidx );[/COLOR]
		virtual void Realize();
	};

};

Atlantis_defs.h
Code:
const static char* DEFAULT_MESHNAME_PANELO17 = "SSU\\panelO17";


I'm working under the assumption (yes I know the joke :P) that one panel class will correspond to one panel mesh. If the panel mesh is small and makes sense to joint it with others, then it probably makes sense to joint the code as well. :shrug:
As for changing panels at runtime, adding DelMesh to the panel destructor, and deleting it from the PanelGroup list, and then load a new one should work.
 
Status
Not open for further replies.
Back
Top