Donamy, if you want to upgrade the Centaur/CISS panel, you should use this one: https://dl.dropboxusercontent.com/u/24122088/Orbiter stuff/Centaur_SSP_L12U.zip
To do what? That texture is just what you see there, single layer.I would need the .psd to do that ?
To do what? That texture is just what you see there, single layer.
Actually the SSPs are flat like that. Here's a photo of the same panel configured for payloads of STS-95, HOST and IEH-03. The purpose of the SSPs are to provide payload customers with a standard panel that can be easily reconfigured to suit any requirements. The payload customer submits a proposed SSP layout to NASA which then reviews it and if it meets all the requirements, then they'll reconfig the SSP to meet that particular customer's layout.Shading doesn't look right. It looks more like a 2D panel, not a 3D one.
I'd prefer C# to Java, mainly so we don't have to install the JDK (and so users don't need to install the JRE). I also prefer C# to Java as a language, although I don't have particularly strong feelings there. I haven't done much GUI programming in either C# or Java, so I'm not sure if there's a big difference there.I think I will then pick up the work on the Centaur again and use the new talkback code there as well for its panel, so both is based on the same code-base.
On a parallel track, I think I have the research together to create a second prototype for a Java FX 8 based mission editor, after the quick&dirty GUI prototype there. If consensus goes against Java FX (I count the vote as 1/1/1 right now), I would just keep it general and without too many SSU relations.
I'd prefer C# to Java, mainly so we don't have to install the JDK (and so users don't need to install the JRE). I also prefer C# to Java as a language, although I don't have particularly strong feelings there. I haven't done much GUI programming in either C# or Java, so I'm not sure if there's a big difference there.
Because now every update is done based on the original mesh (instead of the modified by a previous update), there is no need to subtract the old state. Instead we need to subtract the default state, which so far is barberpole = (0,0), so it still worked perfectly without any subtraction. But if the default isn't barberpole then a subtraction is needed, so the subtraction (of the default state) is back in.Remember to also subtract the coordinates of the old state from the texture coordinates so you are not shifting the texture with every update.
Done.EDIT... since new and malloc() are pretty slow, would it be possible to use a static vertex buffer in the DLL or must we create a new array of vertex coordinates in every modification?
FSS_OWP_BRACKET_LENGTH: I don't quite understand this one.
FSS_OWP_STRUT_OFFSET: 23.8144 //Is this measured from the center point of the FSS (coordinate 0,0,0)?
FSS_OWP_STRUT_LENGTH: 17.9491//Entire length of the rail
FSS_OWP_STRUT_NULL_ANGLE: 83°s
These are what I get when I have measured out things in the mesh:
FSS_OWP_BRACKET_LENGTH: 5.6557
FSS_OWP_STRUT_OFFSET: 17.305
FSS_OWP_STRUT_LENGTH: 17.9491
FSS_OWP_STRUT_NULL_ANGLE: 83°s
const double FSS_OWP_BRACKET_LENGTH = 12.4;
const double FSS_OWP_STRUT_LENGTH = 18.02;
const double FSS_OWP_STRUT_OFFSET = 13.427;
const double FSS_OWP_STRUT_NULL_ANGLE = 88.5; //angle in degrees
You're correct, I read the measurement wrong. The correct number for FSS_OWP_BRACKET_LENGTH is 11.8745.
Did you make this? If so, then you just won a place in the "manual writing group" as "head diagram designer". :thumbup:
double StrutAngle=acos((FSS_OWP_STRUT_OFFSET-YPos)/FSS_OWP_STRUT_LENGTH)+angle;