New Release D3D9Client Development

asmi

Addon Developer
Addon Developer
Joined
Jan 9, 2012
Messages
350
Reaction score
0
Points
0
Location
Ontario
It would only matter when somebody released add-on with both bump and normal maps for the same texture at the same time, but why would they do it (I think it would be rather released with separate normal+displacement or just the bump map)?

Displacement map == bump map == height map. There is no real need for both normal and bump maps since latter contains all information necessary to calculate the former. The only case that comes into my mind is when normal map has much higher resolution than bump map and so it conveys even more higher-frequency details... But this doesn't make a lot of sence from space conservation point of view since bump map uses only single color channel while normal maps are required to have at least two channels. So instead of lower-resolution bump/displacement map + higher-res normal map you could just have higher-res height map...
 

orb

O-F Administrator,
News Reporter
Joined
Oct 30, 2009
Messages
14,020
Reaction score
4
Points
0
Displacement map == bump map == height map.
But D3D9Client doesn't use displacement maps at this time, only normal maps, so they aren't equal.
 

asmi

Addon Developer
Addon Developer
Joined
Jan 9, 2012
Messages
350
Reaction score
0
Points
0
Location
Ontario
But D3D9Client doesn't use displacement maps at this time, only normal maps, so they aren't equal.
Hmmm... What?
How "Only normal maps are currently used" (BTW not true, Jarmonik has said that he had added bump maps support) means that "Displacement map == bump map == height map" is false? These three terms are just different names for the same thing :)
 

orb

O-F Administrator,
News Reporter
Joined
Oct 30, 2009
Messages
14,020
Reaction score
4
Points
0
Hmmm... What?
How "Only normal maps are currently used" (BTW not true, Jarmonik has said that he had added bump maps support) means that "Displacement map == bump map == height map" is false? These three terms are just different names for the same thing :)

No, they aren't.
[ame="http://en.wikipedia.org/wiki/Bump_mapping"]Bump mapping - Wikipedia, the free encyclopedia[/ame]
[ame="http://en.wikipedia.org/wiki/Normal_mapping"]Normal mapping - Wikipedia, the free encyclopedia[/ame]
[ame="http://en.wikipedia.org/wiki/Displacement_mapping"]Displacement mapping - Wikipedia, the free encyclopedia[/ame]

The bump map is converted to normal map by the client. No tessellation or displacement is used.
 

asmi

Addon Developer
Addon Developer
Joined
Jan 9, 2012
Messages
350
Reaction score
0
Points
0
Location
Ontario
Oh, God...
By saying "Displacement map == bump map == height map" I mean that it's the same physical object (same file). The fact that bump map it's not used for displacement doesn't mean that it can't be used for that - it's simply not implemented (yet), but can be implemented later. So even if DX9 used bump map only for normal mapping, that doesn't mean that DX11 can't use it for, let's say, parallax displacement mapping, but it's still the same physical file!
 

dansteph

Addon Developer
Addon Developer
Beta Tester
Joined
Apr 30, 2008
Messages
788
Reaction score
64
Points
28
Website
orbiter.dansteph.com
In anyway I'll have a lot of fun with bump maps, I think I'll make one for each models :)

I hope DXT1 is fine for both engines ? (8:8:8 take 16MB vs 2.66MB for DXT1 so its not
possible as it would add 160MB only for the bump map of the Arrow (2x2048x5 skins)
I hope also there is some safe management for those texture, I mean they are loaded
only if there is enough resources in user's hardware ?

Last as said above I hope that they render the same in both engine, nobody replied but
I'll test that with DGIV & UCGO & UMMU beta and report if there is any problem.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
In anyway I'll have a lot of fun with bump maps, I think I'll make one for each models :)
I hope DXT1 is fine for both engines ? (8:8:8 take 16MB vs 2.66MB for DXT1 so its not
possible as it would add 160MB only for the bump map of the Arrow (2x2048x5 skins)

D3D9Client can use DXT1 format but it would be better to use A8 or L8 formats, since they offer a better quality with the same memory consumption as DXT1.

I hope also there is some safe management for those texture, I mean they are loaded only if there is enough resources in user's hardware ?
D3D9Client doesn't have that kind of resource management in mesh textures, however, there is a checkbox in a setup panel that allows a user to disable them manually.
 
Last edited:

asmi

Addon Developer
Addon Developer
Joined
Jan 9, 2012
Messages
350
Reaction score
0
Points
0
Location
Ontario
I hope DXT1 is fine for both engines ? (8:8:8 take 16MB vs 2.66MB for DXT1 so its not
possible as it would add 160MB only for the bump map of the Arrow (2x2048x5 skins)
I hope also there is some safe management for those texture, I mean they are loaded
only if there is enough resources in user's hardware ?

Last as said above I hope that they render the same in both engine, nobody replied but
I'll test that with DGIV & UCGO & UMMU beta and report if there is any problem.
Dan, bump maps are not required to have the same resolution as main diffuse texture, allthough it's preferred. If it's possible for you to use a single-channel texture format, that's the best option as far as space is concerned.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
I think it would be rather released with separate normal + optionally displacement or just the bump map ?

I suppose that's a question for a graphics designer. But from my point of view a displacement mapping is fine when creating out-door environments like caves, buildings and even in character modelling. But I don't know what good would they do with space ships. I don't recall displacement maps being used in engineering designs. I would go with a higher resolution meshes with a proper geometry instancing to improve rendering speed and normal maps for micro-details.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
jarmonik, could you take a look at a problem reported here?.

It's basically that the screen blanks out when it hits a certain orientation, in this case the RMS End Effector hitting an attitude of 270.0(P), 0.0(Y) and 0.0(R), which equals to pure downward vertical.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
jarmonik, could you take a look at a problem reported here?.

It's basically that the screen blanks out when it hits a certain orientation, in this case the RMS End Effector hitting an attitude of 270.0(P), 0.0(Y) and 0.0(R), which equals to pure downward vertical.
Hi Dave,
is it possible that you could provide a scenario that reproduces this?
It would make re-creation of the issue much easier and therefore speed up possible solutions.
Preferred would be a scenario that only contains stock Orbiter objects.
But if you can only do it with a SSU scenario it's OK as well[1].

/Kuddel

[1] as long as I can download/compile a working SSU ;)
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Hi Dave,
is it possible that you could provide a scenario that reproduces this?
It would make re-creation of the issue much easier and therefore speed up possible solutions.
Preferred would be a scenario that only contains stock Orbiter objects.
But if you can only do it with a SSU scenario it's OK as well[1].
It can only be reproduced with the SSU RMS End Effector view. Here's a scenario that can reproduce perfectly. Problem occurs between EE attitudes of 270.0 and 270.4, both pitch attitudes. Yaw and roll are zero.

EE attitude can be seen on A8U.

Code:
BEGIN_DESC
Contains the latest simulation state.
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 51982.0444552066
END_ENVIRONMENT

BEGIN_FOCUS
  Ship STS-101
END_FOCUS

BEGIN_CAMERA
  TARGET STS-101
  MODE Cockpit
  FOV 50.30
END_CAMERA

BEGIN_HUD
  TYPE Docking
  NAV 0
END_HUD

BEGIN_VC
END_VC

BEGIN_SHIPS
STS-101:SpaceShuttleUltra
  STATUS Orbiting Earth
  RPOS 1571081.20 -6375676.65 1495853.16
  RVEL -7342.666 -1390.861 1819.635
  AROT 37.28 -25.33 91.34
  AFCMODE 7
  PRPLEVEL 0:0.989987 1:1.000000 2:1.000000 3:1.000000 4:1.000000 5:1.000000 6:0.870829 7:1.000000 8:1.000000 9:1.000000
  NAVFREQ 466 0
  CONFIGURATION 3
  WING_NAME Atlantis
  GEAR 0 0.0000
  RMS
  OPS 201
   PAYLOAD CACTIVE1 8.000000 0.000000 0
   PAYLOAD CACTIVE2 0.000000 0.000000 0
   PAYLOAD CACTIVE3 -8.000000 0.000000 0
   PAYLOAD CPASSIVE1 4.000000 0.000000 0
   PAYLOAD CPASSIVE2 2.000000 0.000000 0
   PAYLOAD CPASSIVE3 -6.000000 0.000000 0
   PAYLOAD CPASSIVE4 7.000000 0.000000 0
   PAYLOAD PORT1 3.000000 0.000000 0
   PAYLOAD PORT2 -2.000000 0.000000 0
   PAYLOAD PORT3 -8.000000 0.000000 0
   PAYLOAD PORT4 7.000000 0.000000 0
   PAYLOAD STBD1 3.000000 0.000000 0
   PAYLOAD STBD2 -2.000000 0.000000 0
   PAYLOAD STBD3 -8.000000 0.000000 0
   PAYLOAD STBD4 0.000000 0.000000 0
  PLBD_CAM 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
@SUBSYSTEM MPS_C
  SSME_model 1
  SSME_Igniters 0 0 0 0 0 0
  SSME_Valves 0.000000 0.000000 0.000000 0.000000 0.000000 0 0 0
  SSME_BLOCK_II_pos 0.000000 0.000000
  VIE_WDTstate 1
  VIE_VehicleDataSwitch 0
  OE_chA StorageRegister 0
  OE_chA ONOFFCommandRegister 0 0
  OE_chA SH 0.000000 0.000000 0.000000 0.000000 0.000000
  OE_chB StorageRegister 0
  OE_chB ONOFFCommandRegister 0 0
  OE_chB SH 0.000000 0.000000 0.000000 0.000000 0.000000
  DCU_chA SW 0
  DCU_chB SW 0
  CIE_chA bWDT 1 1
  CIE_chB bWDT 1 1
@ENDSUBSYSTEM		;MPS_C
@SUBSYSTEM MPS_L
  SSME_model 1
  SSME_Igniters 0 0 0 0 0 0
  SSME_Valves 0.000000 0.000000 0.000000 0.000000 0.000000 0 0 0
  SSME_BLOCK_II_pos 0.000000 0.000000
  VIE_WDTstate 1
  VIE_VehicleDataSwitch 0
  OE_chA StorageRegister 0
  OE_chA ONOFFCommandRegister 0 0
  OE_chA SH 0.000000 0.000000 0.000000 0.000000 0.000000
  OE_chB StorageRegister 0
  OE_chB ONOFFCommandRegister 0 0
  OE_chB SH 0.000000 0.000000 0.000000 0.000000 0.000000
  DCU_chA SW 0
  DCU_chB SW 0
  CIE_chA bWDT 1 1
  CIE_chB bWDT 1 1
@ENDSUBSYSTEM		;MPS_L
@SUBSYSTEM MPS_R
  SSME_model 1
  SSME_Igniters 0 0 0 0 0 0
  SSME_Valves 0.000000 0.000000 0.000000 0.000000 0.000000 0 0 0
  SSME_BLOCK_II_pos 0.000000 0.000000
  VIE_WDTstate 1
  VIE_VehicleDataSwitch 0
  OE_chA StorageRegister 0
  OE_chA ONOFFCommandRegister 0 0
  OE_chA SH 0.000000 0.000000 0.000000 0.000000 0.000000
  OE_chB StorageRegister 0
  OE_chB ONOFFCommandRegister 0 0
  OE_chB SH 0.000000 0.000000 0.000000 0.000000 0.000000
  DCU_chA SW 0
  DCU_chB SW 0
  CIE_chA bWDT 1 1
  CIE_chB bWDT 1 1
@ENDSUBSYSTEM		;MPS_R
@SUBSYSTEM FMC1
@ENDSUBSYSTEM		;FMC1
@SUBSYSTEM FMC2
@ENDSUBSYSTEM		;FMC2
@SUBSYSTEM FMC3
@ENDSUBSYSTEM		;FMC3
@SUBSYSTEM MMC1
@ENDSUBSYSTEM		;MMC1
@SUBSYSTEM MMC2
@ENDSUBSYSTEM		;MMC2
@SUBSYSTEM MMC3
@ENDSUBSYSTEM		;MMC3
@SUBSYSTEM MMC4
@ENDSUBSYSTEM		;MMC4
@SUBSYSTEM AMC1
@ENDSUBSYSTEM		;AMC1
@SUBSYSTEM AMC2
@ENDSUBSYSTEM		;AMC2
@SUBSYSTEM AMC3
@ENDSUBSYSTEM		;AMC3
@SUBSYSTEM FF1
@ENDSUBSYSTEM		;FF1
@SUBSYSTEM FF2
@ENDSUBSYSTEM		;FF2
@SUBSYSTEM FF3
@ENDSUBSYSTEM		;FF3
@SUBSYSTEM FF4
@ENDSUBSYSTEM		;FF4
@SUBSYSTEM FA1
@ENDSUBSYSTEM		;FA1
@SUBSYSTEM FA2
@ENDSUBSYSTEM		;FA2
@SUBSYSTEM FA3
@ENDSUBSYSTEM		;FA3
@SUBSYSTEM FA4
@ENDSUBSYSTEM		;FA4
@SUBSYSTEM PL1
@ENDSUBSYSTEM		;PL1
@SUBSYSTEM PL2
@ENDSUBSYSTEM		;PL2
@SUBSYSTEM LF1
@ENDSUBSYSTEM		;LF1
@SUBSYSTEM LM1
@ENDSUBSYSTEM		;LM1
@SUBSYSTEM LA1
@ENDSUBSYSTEM		;LA1
@SUBSYSTEM OF1
@ENDSUBSYSTEM		;OF1
@SUBSYSTEM OF2
@ENDSUBSYSTEM		;OF2
@SUBSYSTEM OF3
@ENDSUBSYSTEM		;OF3
@SUBSYSTEM OF4
@ENDSUBSYSTEM		;OF4
@SUBSYSTEM OA1
@ENDSUBSYSTEM		;OA1
@SUBSYSTEM OA2
@ENDSUBSYSTEM		;OA2
@SUBSYSTEM OA3
@ENDSUBSYSTEM		;OA3
@SUBSYSTEM LL1
@ENDSUBSYSTEM		;LL1
@SUBSYSTEM LL2
@ENDSUBSYSTEM		;LL2
@SUBSYSTEM LR1
@ENDSUBSYSTEM		;LR1
@SUBSYSTEM LR2
@ENDSUBSYSTEM		;LR2
@SUBSYSTEM EIU1
@ENDSUBSYSTEM		;EIU1
@SUBSYSTEM EIU2
@ENDSUBSYSTEM		;EIU2
@SUBSYSTEM EIU3
@ENDSUBSYSTEM		;EIU3
@SUBSYSTEM MTU
  MET_RUNNING 1
  MET0 352.109751
  MET1 352.109751
  MET2 352.109751
EVENT_TIMER0 0.000000 DOWN STOPPED
EVENT_TIMER1 0.000000 DOWN STOPPED
@ENDSUBSYSTEM		;MTU
@SUBSYSTEM IDP1
  IDP1 SPEC 65535
  IDP1 DISP 65535
@ENDSUBSYSTEM		;IDP1
@SUBSYSTEM IDP2
  IDP2 SPEC 65535
  IDP2 DISP 65535
@ENDSUBSYSTEM		;IDP2
@SUBSYSTEM IDP3
  IDP3 SPEC 65535
  IDP3 DISP 65535
@ENDSUBSYSTEM		;IDP3
@SUBSYSTEM IDP4
  IDP4 SPEC 65535
  IDP4 DISP 65535
@ENDSUBSYSTEM		;IDP4
@SUBSYSTEM IMU1
@ENDSUBSYSTEM		;IMU1
@SUBSYSTEM IMU2
@ENDSUBSYSTEM		;IMU2
@SUBSYSTEM IMU3
@ENDSUBSYSTEM		;IMU3
@SUBSYSTEM GPC1
@ENDSUBSYSTEM		;GPC1
@SUBSYSTEM GPC2
@ENDSUBSYSTEM		;GPC2
@SUBSYSTEM GPC3
@ENDSUBSYSTEM		;GPC3
@SUBSYSTEM GPC4
@ENDSUBSYSTEM		;GPC4
@SUBSYSTEM GPC5
@ENDSUBSYSTEM		;GPC5
@SUBSYSTEM MMU1
@ENDSUBSYSTEM		;MMU1
@SUBSYSTEM MMU2
@ENDSUBSYSTEM		;MMU2
@SUBSYSTEM SimpleGPCSystem
  @BEGINSOFTWARE OrbitDAP
  TGT_ID 2
  BODY_VECT 1
  ROLL 0.000000
  PITCH 0.000000
  YAW 0.000000
  P_ANGLE 0.000000
  Y_ANGLE 0.000000
  OM_ANGLE -1.000000
  DAP_MODE 0 0
  ROT_MODE 0 0 0
  TRANS_MODE 0 0 0
  CONTROL_MODE 1
  @ENDSOFTWARE 
  @BEGINSOFTWARE StateVectorSoftware
  T0_POS 0.000000 -0.004750 0.000000
  @ENDSOFTWARE 
  @BEGINSOFTWARE OrbitTgtSoftware
  TIG_T1 0 0 0 0.0
  DT 0.000000
  RELPOS_T2 0.000000 0.000000 0.000000
  BASE_TIME 0 0 0 0.0
  @ENDSOFTWARE 
@ENDSUBSYSTEM		;SimpleGPCSystem
@SUBSYSTEM ODS
  RING_STATE -1 0.0000
@ENDSUBSYSTEM		;ODS
@SUBSYSTEM ADPS
  LEFT_AIRDATAPROBE 0 0 1.000000
  RIGHT_AIRDATAPROBE 0 0 1.000000
@ENDSUBSYSTEM		;ADPS
@SUBSYSTEM ETUmbDoors
  ET_DOORS 0.000000 0.000000
  ET_DOOR_LATCHES 1.000000 0.000000 0.000000
@ENDSUBSYSTEM		;ETUmbDoors
@SUBSYSTEM -YStarTrackerDoorMotor
@ENDSUBSYSTEM		;-YStarTrackerDoorMotor
@SUBSYSTEM -ZStarTrackerDoorMotor
@ENDSUBSYSTEM		;-ZStarTrackerDoorMotor
@SUBSYSTEM ACBusSystem
@ENDSUBSYSTEM		;ACBusSystem
@SUBSYSTEM INVERTER1
@ENDSUBSYSTEM		;INVERTER1
@SUBSYSTEM INVERTER2
@ENDSUBSYSTEM		;INVERTER2
@SUBSYSTEM INVERTER3
@ENDSUBSYSTEM		;INVERTER3
@SUBSYSTEM APU1
  APU1_State 0
  APU1_FuelPress 0.000000
  APU1_HydPress 0.000000
  APU1_Speed 0.000000
@ENDSUBSYSTEM		;APU1
@SUBSYSTEM APU2
  APU2_State 0
  APU2_FuelPress 0.000000
  APU2_HydPress 0.000000
  APU2_Speed 0.000000
@ENDSUBSYSTEM		;APU2
@SUBSYSTEM APU3
  APU3_State 0
  APU3_FuelPress 0.000000
  APU3_HydPress 0.000000
  APU3_Speed 0.000000
@ENDSUBSYSTEM		;APU3
@SUBSYSTEM WSB1
@ENDSUBSYSTEM		;WSB1
@SUBSYSTEM WSB2
@ENDSUBSYSTEM		;WSB2
@SUBSYSTEM WSB3
@ENDSUBSYSTEM		;WSB3
@SUBSYSTEM LATCH0
  LATCH_STATE1 1 1.0000
  LATCH_STATE2 1 1.0000
  LATCH_STATE3 1 1.0000
  LATCH_STATE4 1 1.0000
  LATCH_STATE5 1 1.0000
@ENDSUBSYSTEM		;LATCH0
@SUBSYSTEM LATCH1
  LATCH1_ATTACHED_PAYLOAD Leonardo 0
  LATCH_STATE1 0 0.0000
  LATCH_STATE2 0 0.0000
  LATCH_STATE3 0 0.0000
  LATCH_STATE4 0 0.0000
  LATCH_STATE5 0 0.0000
@ENDSUBSYSTEM		;LATCH1
@SUBSYSTEM LATCH2
  LATCH_STATE1 2 0.9633
  LATCH_STATE2 1 1.0000
  LATCH_STATE3 1 1.0000
  LATCH_STATE4 1 1.0000
  LATCH_STATE5 1 1.0000
@ENDSUBSYSTEM		;LATCH2
@SUBSYSTEM RMS
  ARM_STATUS 0.715750 0.615772 0.700807 0.148379 0.518718 0.587597
  SHOULDER_BRACE 0.000000
  GRAPPLE 1 1.0000
  RIGIDIZE 1 1.0000
  EXTEND 1 1.0000
  RMS_ELBOW_CAM 0.0000 0.0000
  RMS_ROLLOUT 1 1.0000
  RMS_LATCHES 1 1.0000
@ENDSUBSYSTEM		;RMS
  CARGODOOR 1 1.0000
  CRT_SEL 1 1
  @PANEL F2
  "F2_SPDBKTHROT_AUTO" 1
  "F2_BODYFLAP_AUTO" 0
  "F2_PITCH_AUTO" 0
  "F2_PITCH_CSS" 0
  "F2_RY_AUTO" 0
  "F2_RY_CSS" 0
  @ENDPANEL 
  @PANEL F4
  "F4_SPDBKTHROT_AUTO" 1
  "F4_BODYFLAP_AUTO" 0
  "F4_PITCH_AUTO" 0
  "F4_PITCH_CSS" 0
  "F4_RY_AUTO" 0
  "F4_RY_CSS" 0
  @ENDPANEL 
  @PANEL F6
  "Cdr Flt Cntlr Pwr" OFF
  @ENDPANEL 
  @PANEL F7
  @ENDPANEL 
  @PANEL F8
  "Plt Flt Cntlr Pwr" OFF
  @ENDPANEL 
  @PANEL R2
  "Boiler1 N2 Supply" OFF
  "Boiler2 N2 Supply" OFF
  "Boiler3 N2 Supply" OFF
  "Boiler1 Cntlr" OFF
  "Boiler2 Cntlr" OFF
  "Boiler3 Cntlr" OFF
  "Boiler1 Cntlr Pwr/Htr" OFF
  "Boiler2 Cntlr Pwr/Htr" OFF
  "Boiler3 Cntlr Pwr/Htr" OFF
  "APU1 Run" OFF
  "APU2 Run" OFF
  "APU3 Run" OFF
  "Hyd Main Pump Press 1" LOW
  "Hyd Main Pump Press 2" LOW
  "Hyd Main Pump Press 3" LOW
  "APU1 Cntlr Pwr " OFF
  "APU2 Cntlr Pwr " OFF
  "APU3 Cntlr Pwr " OFF
  "APU1 Fuel Tank Valve" CLOSE
  "APU2 Fuel Tank Valve" CLOSE
  "APU3 Fuel Tank Valve" CLOSE
  "ET Umb Centerline Latch" GND
  "ET Umb Left Door" OFF
  "ET Umb Left Door Latch" OFF
  "ET Umb Right Door" OFF
  "ET Umb Right Door Latch" OFF
  "MPS Pwr Left AC2" [0]
  "MPS Pwr Ctr AC1" [0]
  "MPS Pwr Right AC3" [0]
  "MPS Pwr Left AC3" [0]
  "MPS Pwr Ctr AC2" [0]
  "MPS Pwr Right AC1" [0]
  "MPS He Isol A Left" GPC
  "MPS He Isol A Ctr" GPC
  "MPS He Isol A Right" GPC
  "MPS He Isol B Left" GPC
  "MPS He Isol B Ctr" GPC
  "MPS He Isol B Right" GPC
  @ENDPANEL 
  @PANEL C3
  "LOMS Arm" ARM/PRESS
  "ROMS Arm" ARM/PRESS
  "LADP Stow Enable" INHIBIT
  "RADP Stow Enable" INHIBIT
  "LADP Deploy" STOW
  "RADP Deploy" STOW
  @ENDPANEL 
  @PANEL O6
  "L GLRSHLD FLOOD" VAR
  "S TRK DR CNTL SYS1" OFF
  "S TRK DR CNTL SYS2" OFF
  "GPC_POWER_1_COVER" [0]
  "GPC_POWER_2_COVER" [0]
  "GPC_POWER_3_COVER" [0]
  "GPC_POWER_4_COVER" [0]
  "GPC_POWER_5_COVER" [0]
  "GPC POWER 1" ON
  "GPC POWER 2" ON
  "GPC POWER 3" ON
  "GPC POWER 4" ON
  "GPC POWER 5" ON
  "GPC_OUTPUT_1_COVER" [0]
  "GPC_OUTPUT_2_COVER" [0]
  "GPC_OUTPUT_3_COVER" [0]
  "GPC_OUTPUT_4_COVER" [0]
  "GPC_OUTPUT_5_COVER" [0]
  "GPC OUTPUT 1" NORMAL
  "GPC OUTPUT 2" NORMAL
  "GPC OUTPUT 3" NORMAL
  "GPC OUTPUT 4" NORMAL
  "GPC OUTPUT 5" NORMAL
  "IPL SOURCE" OFF
  "GPC MODE 1" STBY
  "GPC MODE 2" STBY
  "GPC MODE 3" STBY
  "GPC MODE 4" STBY
  "GPC MODE 5" STBY
  @ENDPANEL 
  @PANEL R11
  @ENDPANEL 
  @PANEL A6
  "SENSE" -X
  "Aft Flt Cntlr Pwr" ON
  "Payload Ret Latch 1" OFF
  "Payload Ret Latch 2" OFF
  "Payload Ret Latch 3" OFF
  "Payload Ret Latch 4" OFF
  "Payload Ret Latch 5" OFF
  "Payload Select" 2
  @ENDPANEL 
  @PANEL AftMDU
  @ENDPANEL 
  @PANEL A7U
  "PLBD FLOOD FWD STBD" ON
  "PLBD FLOOD FWD PORT" ON
  "PLBD FLOOD MID STBD" ON
  "PLBD FLOOD MID PORT" ON
  "PLBD FLOOD AFT STBD" ON
  "PLBD FLOOD AFT PORT" ON
  "PLBD FWD BHD" ON
  "PLBD DOCKING" BRIGHT
  @ENDPANEL 
  @PANEL A7A3/A8A3
  "SYSTEM POWER MNA" [1]
  "SYSTEM POWER MNB" [1]
  "PYRO POWER MNA" [0]
  "PYRO POWER MNC" [0]
  "SYS1 VENT ISOL" [1]
  "SYS1 VENT" [1]
  "SYS2 VENT ISOL" [1]
  "SYS2 VENT" [1]
  "PSU POWER MNA" [0]
  "PSU POWER MNB" [0]
  "LIGHTS AIRLOCK 1-4" [0]
  "LIGHTS AIRLOCK 2-3" [0]
  "LIGHTS DOCKING TRUSS FWD" [0]
  "LIGHTS DOCKING TRUSS AFT" [0]
  "ARLK/TNL FAN A" [0]
  "ARLK/TNL FAN B" [0]
  "LIGHTS C/L VESTIBULE PORT" [0]
  "LIGHTS C/L VESTIBULE STBD" [0]
  "CNTL PNL PWR A" OFF
  "CNTL PNL PWR B" OFF
  "CNTL PNL PWR C" OFF
  "HTRS/DCU PWR H1" OFF
  "HTRS/DCU PWR H2/DCU" OFF
  "HTRS/DCU PWR H3/DCU" OFF
  "APDS PWR A" OFF
  "APDS PWR B" OFF
  "APDS PWR C" OFF
  "PYROS Ap" [0]
  "PYROS Bp" [0]
  "PYROS Cp" [0]
  @ENDPANEL 
  @PANEL A8
  "Port MPM Deploy Cover" [0]
  "Stbd MPM Deploy Cover" [0]
  "Port RMS Latches" OFF
  "Stbd MPM Latches" OFF
  "Port MPM Deploy" OFF
  "Stbd MPM Deploy" OFF
  "EE Mode" OFF
  "RMS SELECT" PORT
  "Parameter" ATTITUDE
  "Joint" WRIST_PITCH
  "RMS Mode" END_EE
  @ENDPANEL 
END
Leonardo:Leonardo_mplm
  STATUS Orbiting Earth
  RPOS 1571079.93 -6375676.27 1495853.61
  RVEL -7342.666 -1390.861 1819.635
  AROT 37.28 -25.33 91.34
  ATTACHED 0:6,STS-101
  AFCMODE 7
  NAVFREQ 0 0
  XPDR 477
END
END_SHIPS

[1] as long as I can download/compile a working SSU
Shouldn't be a problem. Just download the latest SSU sources and build them and you should be set.
 

MrAshDarksideTM

New member
Joined
Nov 13, 2012
Messages
1
Reaction score
0
Points
0
I've done a bit of searching but couldn't seem to find an answer, so please excuse me if this has been covered. But I cannot seem to get this to work. I select the d3d9Client in Orbiter_Ng but I still get just a console window, and no video option in the main orbiter config program.


I also get this error in the log

Failed loading module Modules\Plugin\D3D9Client.dll (code 998)
[Orbiter::LoadModule | .\Orbiter.cpp | 612]
 
Last edited:

DarkWanderer

Active member
Orbiter Contributor
Donator
Joined
Apr 27, 2008
Messages
213
Reaction score
83
Points
43
Location
Moscow
Can anyone please take a look on why TotalImmersion's ShuttlePB does not work with the D3D9 client?
It is such an awesome addon, it would be a pity to lose it due to some minor bug...

Symptoms:
* The addon works well with the default graphics
* When using D3D9 client, upon lodeing the ShuttlePB model, Orbiter crashes with "Critical error - see log" message
* Following line is present in the Orbiter.log:
ERROR: Invalid mesh handle. Returned NULL. (Continuing)
>>> [oapiMeshGroup | .\OrbiterAPI.cpp | 1196]

Maybe this can be easily fixed?
 
Last edited:

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
jarmonik, could you take a look at a problem reported here?.

It's basically that the screen blanks out when it hits a certain orientation, in this case the RMS End Effector hitting an attitude of 270.0(P), 0.0(Y) and 0.0(R), which equals to pure downward vertical.

I presume this also happens with the inline engine. There is a singularity in the euler angles that is most likely causing the problem and it can't be fixed from the client side.

How do you compute or where do you get the Y,P,R for the camera ? Maybe there is something wrong in the computation of Y, P and R.

Could you attach the source code into your post.
 

BruceJohnJennerLawso

Dread Lord of the Idiots
Addon Developer
Joined
Apr 14, 2012
Messages
2,585
Reaction score
0
Points
36
Noticed something Orb said about the graphics clients & addons, so I thought Id ask:
Is there a possibility of adding Orulex support to D3D9, or is the conflict a fundamental one that cant be solved? I would really like to use the D3D9, but I really prefer having Orulex.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
I presume this also happens with the inline engine. There is a singularity in the euler angles that is most likely causing the problem and it can't be fixed from the client side.

How do you compute or where do you get the Y,P,R for the camera ? Maybe there is something wrong in the computation of Y, P and R.

Could you attach the source code into your post.
I believe this is the code:

Code:
void RMSSystem::UpdateEECamView() const
{
	if(oapiCameraInternal()) {
		// calculate rotation angle for EE cam
		VECTOR3 dir = arm_tip[1]-arm_tip[0];
		VECTOR3 orbiter_cam_rot = crossp(crossp(dir, _V(0, 1, 0)), dir);
		orbiter_cam_rot /= length(orbiter_cam_rot);
		if(orbiter_cam_rot.y < 0) orbiter_cam_rot = -orbiter_cam_rot;
		double angle = SignedAngle(orbiter_cam_rot, arm_tip[2]-arm_tip[0], dir);
		//sprintf_s(oapiDebugString(), 255, "Rot Vec: %f %f %f dir: %f %f %f dot_prod: %f Angle: %f %f", orbiter_cam_rot.x, orbiter_cam_rot.y, orbiter_cam_rot.z, dir.x, dir.y, dir.z, dot_prod, angle, angle*DEG);
		//sprintf_s(oapiDebugString(), 255, "Rot Vec: %f %f %f cam dir: %f %f %f dir: %f %f %f Angle: %f %f length: %f", orbiter_cam_rot.x, orbiter_cam_rot.y, orbiter_cam_rot.z, arm_tip[2].x-arm_tip[0].x, arm_tip[2].y-arm_tip[0].y, arm_tip[2].z-arm_tip[0].z,  dir.x, dir.y, dir.z, angle, angle*DEG, length(dir));
		//sprintf_s(oapiDebugString(), 255, "dot_prod: %f Angle: %f %f", dot_prod, angle, angle*DEG);

		STS()->SetCameraOffset(STS()->GetOrbiterCoGOffset()+arm_tip[4]+RMS_MESH_OFFSET);
		//STS()->SetCameraDefaultDirection (arm_tip[1]-arm_tip[0], 0.0);
		STS()->SetCameraDefaultDirection (arm_tip[1]-arm_tip[0], angle);
		oapiCameraSetCockpitDir(0.0, 0.0);
	}
}
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
Looks like the situation is much worse than I thought. The camera orientation is defined by Azimuth, Elevation and Tilt.

The problem is "crossp(dir, _V(0, 1, 0))" that will become unstable if the dir is close to _V(0,1,0) or _V(0, -1, 0). Orbiter is probably computing it the same way so there is not much we can do about it.

I suppose I could add a function to a client to set the camera global direction.

void gcSetCameraGlobalDir(VECTOR3 *dir, VECTOR3 *up, double znear)

This function would steal the camera from the Orbiter. User would need to return the camera control to the Orbiter by a calling the function with NULL parameters. gcSetCameraGlobalDir(NULL, NULL, 0);

An other possible approach is to prevent near zero yaw and roll values.

if (fabs(yaw)<1e-5) yaw=1e-5;
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Looks like the situation is much worse than I thought. The camera orientation is defined by Azimuth, Elevation and Tilt.

The problem is "crossp(dir, _V(0, 1, 0))" that will become unstable if the dir is close to _V(0,1,0) or _V(0, -1, 0). Orbiter is probably computing it the same way so there is not much we can do about it.

I suppose I could add a function to a client to set the camera global direction.

void gcSetCameraGlobalDir(VECTOR3 *dir, VECTOR3 *up, double znear)

This function would steal the camera from the Orbiter. User would need to return the camera control to the Orbiter by a calling the function with NULL parameters. gcSetCameraGlobalDir(NULL, NULL, 0);

An other possible approach is to prevent near zero yaw and roll values.

if (fabs(yaw)<1e-5) yaw=1e-5;
Thanks for looking this over. So it is a core Orbiter problem? The last workaround, is it something that would have to be implemented in the core or can it be implemented on the graphics engine level?
 
Top