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

[Donamy]

How about some screen shots also ?

 

[GLS]

Same exact POV:

The real radiators reflect yes, but not like polished mirrors.

 

[DaveS]

This is what I have, Orbiter 2016, D3D9Client R2 Beta 3: https://www.dropbox.com/s/oh4ymcuflx3qt7a/SSU_radiator_reflections.jpg?dl=0

A nice dull effect just like the real thing.

 

[GLS]

Well, or you're running something that isn't on svn, or each graphics card is doing what it wants, or I messed up the D3D9 settings.

FrameRate = 200
EnableLimiter = 0
CustomCamMode = 0
PlanetPreloadMode = 0
PlanetTexLoadFreq = 500
Anisotrophy = 2
SceneAntialias = 2
SketchpadFont = 1
PreLoadBaseVisuals = 0
EnableNormalMapping = 1
NearClipPlaneMode = 1
RwyLightAnimate = 1
RwyLightAngle = 120
RwyBrightness = 1.8
NightLightsAngle = 10
BumpMapAmplitude = 1
PlanetGlow = 0.4
EnvMapSize = 512
EnvMapMode = 1
EnvMapFaces = 1
ShadowMapMode = 1
ShadowMapSize = 1024
EnableGlass = 1
EnableMeshDbg = 1
TileMipmaps = 1
TextureMips = 1
TileDebug = 0
StereoSeparation = 65
StereoConvergence = 0.2
DebugLvl = 4
VCNearPlane = 0.1
LightSourcesInUse = 10
DisableDrvMgm = 0
NVPerfHUD = 0
DebugLineFontSize = 18
DisableVisualHelperReadout = 0
LODBias = -0.6
MeshRes = 1
MicroMode = 1
MicroFilter = 2
BlendMode = 2
MicroBias = 3
PostProcess = 0
ShaderDebug = 0
PresentLocation = 1
PlanetTileLoadFlags = 3
SolCfg = Sol
DebugLineFont = Fixed

 

[DaveS]

Nothing uncommitted in the textures department. Here's my D3D9Client.cfg file. Are you running the same D3D9Client version? Maybe something has changed between the Release version and the Beta version?

FrameRate = 200
EnableLimiter = 0
CustomCamMode = 1
PlanetPreloadMode = 0
PlanetTexLoadFreq = 500
Anisotrophy = 16
SceneAntialias = 8
SketchpadFont = 1
PreLoadBaseVisuals = 0
EnableNormalMapping = 1
NearClipPlaneMode = 1
RwyLightAnimate = 1
RwyLightAngle = 120
RwyBrightness = 1.8
NightLightsAngle = 10
BumpMapAmplitude = 1
PlanetGlow = 1.25
EnvMapSize = 512
EnvMapMode = 2
EnvMapFaces = 3
ShadowMapMode = 1
ShadowMapSize = 1024
EnableGlass = 1
EnableMeshDbg = 1
TileMipmaps = 0
TextureMips = 1
TileDebug = 0
StereoSeparation = 65
StereoConvergence = 0.2
DebugLvl = 1
VCNearPlane = 0.1
LightSourcesInUse = 200
DisableDrvMgm = 0
NVPerfHUD = 0
DebugLineFontSize = 18
DisableVisualHelperReadout = 0
LODBias = 0.8
MeshRes = 1
MicroMode = 0
MicroFilter = 2
BlendMode = 2
MicroBias = 3
PostProcess = 0
ShaderDebug = 0
PresentLocation = 1
PlanetTileLoadFlags = 3
SolCfg = Sol
DebugLineFont = Fixed

 

[GLS]

I'm running Orbiter beta and (I think) the latest D3D9 for beta.

 

[DaveS]

I'm running Orbiter beta and (I think) the latest D3D9 for beta.

Could you try things on a Release version and see if you still have the same mirror-like reflections? If you don't, then it could be worth reporting this as a D3D9Client bug because I don't think the reflections should have changed between the two.

 

[GLS]

... and now for something completely different, I was tracking the reason why in the "Atlantis in orbit" scenario for STS-61G the vehicle was rolling 180º each time the scenario was (re)loaded, and found an issue with the conversion from rotation matrix to angles (the angles to rotation matrix conversion seems straight forward and correct), more specifically with the roll angle that flips between 0 and +/-180º. The function in question is this:

VECTOR3 GetYZXAnglesFromMatrix(const MATRIX3 &RotMatrix)
{
	VECTOR3 Angles;
	Angles.data[YAW]=asin(RotMatrix.m21);
	if(Eq(abs(RotMatrix.m21), 1.0, 0.0001)) { // singularity; assume pitch is zero
		Angles.data[PITCH]=0.0;
		Angles.data[ROLL]=atan2(RotMatrix.m32, -RotMatrix.m12);
	}
	else { // normal case
		Angles.data[PITCH]=-atan2(RotMatrix.m31, RotMatrix.m11);
		Angles.data[ROLL]=-atan2(RotMatrix.m23, RotMatrix.m22);
	}
	return Angles;
}

more spefically this line:

Angles.data[ROLL]=atan2(RotMatrix.m32, -RotMatrix.m12);

Changing the sign of the m12 term fixes this particular issue, and in fact when I checked if this function had been changed in the past I found that this line was once like this:

if(Angles.data[YAW] > 0.0) Angles.data[ROLL]=atan2(RotMatrix.m32, -RotMatrix.m12);
else Angles.data[ROLL]=atan2(RotMatrix.m32, RotMatrix.m12);

and was changed to the current version by SiameseCat back in 2012 (r1332).
So the question is: "+m12" or "if"? (Hopefully someone reading this has more "algebra muscle" than me, and can figure this out in 5 minutes instead of me taking 5 hours :facepalm

 

[GLS]

Could you try things on a Release version and see if you still have the same mirror-like reflections? If you don't, then it could be worth reporting this as a D3D9Client bug because I don't think the reflections should have changed between the two.

No noticeable changes between debug as release (as expected). Tried you're settings and no changes in the radiators, but the Centaur is reflecting the CISS orange foil from angles it probably shouldn't.

 

[DaveS]

No noticeable changes between debug as release (as expected). Tried you're settings and no changes in the radiators, but the Centaur is reflecting the CISS orange foil from angles it probably shouldn't.

I meant a plain Orbiter 2016 [160828] with D3D9Client R2 Beta 3 configuration, not a Release vs Debug configuration of the modules. I know that won't change anything.

As far as what should be reflected vs what shouldn't that's a known limitation of D3D9Client as it only supports one static environmental camera per vessel. I'd like to see the support for more and the ability to bind them to animations.

 

[4throck]

The latest D3D9 clients support complex materials (PBR like) so you must configure your materials for that.

The simplest way to do it is to add the required texture variations .refl and .spec (see the docs).
Those will control "shiny" X "smooth", reflected color, etc.

 

[DaveS]

The latest D3D9 clients support complex materials (PBR like) so you must configure your materials for that.

The simplest way to do it is to add the required texture variations .refl and .spec (see the docs).
Those will control "shiny" X "smooth", reflected color, etc.

We already have those. There's a physical difference between the two versions when using the exact same reflection texture. The Beta has the mirror-like finish while the Release has the correct dull finish.

 

[GLS]

Another thing that I'm about out of options, except post a bug report, is the vc click areas not responding. One scenario where that issue shows up regularly is the Testing Scenarios\Atlantis in orbit.scn scenario, where panel F4 doesn't work. The oapiVCSetAreaClickmode_Quadrilateral() call is made, the cg offset is the same as in the other panels, but clbkVCMouseEvent() is never called when clicking on that panel. Both with the debug and the release config, MOGE or D3D9, it doesn't work in that scenario, while other scenarios work just fine. :shrug: Any ideas before I bother the top man?

Anyone else having this issue?
>> STS-1/In orbit, change to PLT and C2 stops working
>> Testing/Atlantis in orbit, F4 doesn't work
>> STS-81I/Atlantis in orbit, R13L doesn't work until Centaur is released
>> STS-26R/IUS deploy, F2 doesn't work

... and now for something completely different, I was tracking the reason why in the "Atlantis in orbit" scenario for STS-61G the vehicle was rolling 180º each time the scenario was (re)loaded, and found an issue with the conversion from rotation matrix to angles (the angles to rotation matrix conversion seems straight forward and correct), more specifically with the roll angle that flips between 0 and +/-180º. The function in question is this:

VECTOR3 GetYZXAnglesFromMatrix(const MATRIX3 &RotMatrix)
{
	VECTOR3 Angles;
	Angles.data[YAW]=asin(RotMatrix.m21);
	if(Eq(abs(RotMatrix.m21), 1.0, 0.0001)) { // singularity; assume pitch is zero
		Angles.data[PITCH]=0.0;
		Angles.data[ROLL]=atan2(RotMatrix.m32, -RotMatrix.m12);
	}
	else { // normal case
		Angles.data[PITCH]=-atan2(RotMatrix.m31, RotMatrix.m11);
		Angles.data[ROLL]=-atan2(RotMatrix.m23, RotMatrix.m22);
	}
	return Angles;
}

more spefically this line:

Angles.data[ROLL]=atan2(RotMatrix.m32, -RotMatrix.m12);

Changing the sign of the m12 term fixes this particular issue, and in fact when I checked if this function had been changed in the past I found that this line was once like this:

if(Angles.data[YAW] > 0.0) Angles.data[ROLL]=atan2(RotMatrix.m32, -RotMatrix.m12);
else Angles.data[ROLL]=atan2(RotMatrix.m32, RotMatrix.m12);

and was changed to the current version by SiameseCat back in 2012 (r1332).
So the question is: "+m12" or "if"? (Hopefully someone reading this has more "algebra muscle" than me, and can figure this out in 5 minutes instead of me taking 5 hours :facepalm

I just committed a change to this... playing with the matrices (1) the "if" solution makes total sense, and (2) I can't find any issues in the sim.

---------- Post added at 12:18 AM ---------- Previous post was at 12:16 AM ----------

I meant a plain Orbiter 2016 [160828] with D3D9Client R2 Beta 3 configuration

Is this still needed? (I have to find where I put the 160828 files....)

 

[DaveS]

Anyone else having this issue?
>> STS-1/In orbit, change to PLT and C2 stops working
>> Testing/Atlantis in orbit, F4 doesn't work
>> STS-81I/Atlantis in orbit, R13L doesn't work until Centaur is released
>> STS-26R/IUS deploy, F2 doesn't work



I just committed a change to this... playing with the matrices (1) the "if" solution makes total sense, and (2) I can't find any issues in the sim.

---------- Post added at 12:18 AM ---------- Previous post was at 12:16 AM ----------



Is this still needed? (I have to find where I put the 160828 files....)

Don't think so. I posted about it in the D3D9Client Development thread so hopefully it will be resolved there.

 

[GLS]

Just committed a separated panel C3 mesh, and eagle-eyed users might notice small differences in that panel when flying Columbia, as opposed to other OVs. The "VIB SHUT DN" was only present in OV-102, so now it doesn't show up for the rest of the fleet (even though we don't use that particular switch). It's just a small visual change but it's a step towards having the correct panels for each vehicle.

 

[asdad]

GLS , I have problem with ssumeshc.cpp it says : ssumeshc.cpp(89): error C2143: syntax error : missing ';' before '{'
1>ssumeshc.cpp(89): error C2143: syntax error : missing ';' before '}'
1>ssumeshc.cpp(89): error C2059: syntax error : ')'
1>ssumeshc.cpp(100): error C2143: syntax error : missing ')' before '{'
1>ssumeshc.cpp(100): error C2275: 'ITEM' : illegal use of this type as an expression
1> ssumeshc.cpp(25) : see declaration of 'ITEM'
1>ssumeshc.cpp(100): error C2143: syntax error : missing ';' before '{'
1>ssumeshc.cpp(100): error C2143: syntax error : missing ';' before '}'
1>ssumeshc.cpp(100): error C2059: syntax error : ')' could you fix it ?

 

[GLS]

I guess the vs2010 compiler doesn't like some things... I changed those lines to a more conservative design, and it now should work fine.

 

[asdad]

Thank you GLS

 

[DaveS]

Now that we have begun the VC panel separations, I'm wondering how we're going to handle some of the aft flight deck items like the aft MDU and the CCTV monitors. Will those be split off as well and assigned to their closest panels?

 

[GLS]

Now that we have begun the VC panel separations, I'm wondering how we're going to handle some of the aft flight deck items like the aft MDU and the CCTV monitors. Will those be split off as well and assigned to their closest panels?

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.