New Orbiter SVN commit (r.71, Oct 14 2017) - Page 37 - Orbiter-Forum

**Ripley** · 10-13-2018, 05:10 PM

I could be wrong, but something from the back of my head suggested me: could you try to rename the file Device.dat in your Orbiter root folder, and see if it gets recreated upon next start?

Upkeep · 10-13-2018, 05:29 PM

Yes it does get recreated. But still no luck.
Thanks again for trying.
All the best
Upkeep

**kuddel** · 10-13-2018, 09:36 PM

A very nasty little problem you present here...
Maybe this is not an option for you, but since you're having these problems after you've updated your NVIDIA driver to 411.70, would a downgrade to a former version be an option to try?
Or does the 411.70 version need a BIOS update, too? But I doubt, 'cause you can run other applications (DX10, 11 or 12 I presume) without issues.

Upkeep · 10-14-2018, 09:10 AM

Thanks for your response.

Yes, going back to a much earlier driver is an option I could try in principle. I expect there is not any particular problem doing so (except for establishing how far to go back as this issue has been around for me for a while now).

I am now currently running Nvidia driver 416.34 which produced the same problem with Orbiter, not surprisingly. Nividia seem to update their drivers very frequently...

I am nevertheless reluctant to go back to an earlier driver for a number of reasons:

1. All my other applications are working well with the new driver and I even appear to be getting better fps on some.

2. I am concerned about damaging my system in the process of going back to an older driver. I realise the risks are probably low here of course.

3. On principle I am not keen on using old drivers for anything. They are usually updated for a reason and Windows may well be updated in tandem with new releases from vendors. I like to keep the pc update to date as best I can.

The strange thing is that usually, when a driver is updated, other people suffer the same problem and some expert is able to find a solution. I am not an expert at all and tend to be risk averse as far as fiddling with software is concerned. So I seem to have a uniqiue set-up here

I think I am back to square 1 on this one, sadly.

Anyway, thanks everyone for your efforts to help.

I do appreciate them.

Best wishes

Upkeep

**Ripley** · 10-14-2018, 12:33 PM

Quote:

Originally Posted by Upkeep

...1. All my other applications are working well with the new driver and I even appear to be getting better fps on some...

Since you speak about fps, I assume that by applications you mean other games?

Upkeep · 10-14-2018, 01:25 PM

Yes. That is correct. Applications was no doubt the wrong terminology. Sorry about that.

Best wishes

Upkeep

**martins** · 10-22-2018, 04:32 PM

Is there any new information on this problem with the new Titan textures in the D3D9 client? In particular, is the problem with the textures themselves (i.e. something I need to fix) or with the D3D9 code that somebody else is going to look into?

Is it linked to the cloud layer and/or cloud shadows? What happens if clouds are disabled?

Quote:

Originally Posted by Ripley

About these new Titan textures, I've taken 4 screenshots (scenario is "The Solar System - Titan", starting paused):

Orbiter2016, default textures

Orbiter2016, D3D9Client2016-R3b, default textures

Orbiter2016, HiRes Titan textures + new config

Orbiter2016, D3D9Client2016-R3b, HiRes Titan textures + new config

**jarmonik** · 10-22-2018, 08:11 PM

Quote:

Originally Posted by martins

Is there any new information on this problem with the new Titan textures in the D3D9 client?

The problem with Titan textures is caused by a missing configuration file for Titan's atmosphere. The file was uploaded to D3D9 SVN right after the discovery of the problem. I'll have to double check if the file is actually present in the latest release.

The file appears to be there in Orbiter BETA build of the Client but is missing from 2016 build.

**kuddel** · 10-22-2018, 08:23 PM

I can confirm, that
a) the 2016 Version (of D3D9Client) is lacking those configuration files[1]
b) with them, Titan looks nice in Orbiter 2016.
...I'll wait for Jarmo to commit those files into the branch.

[1] Titan.atmo.cfg and Titan.atms.cfg

**Ripley** · 10-22-2018, 08:28 PM

I've updated to the latest D3D9 (R3.1), but the result is no changes to the 4 screenshots I already posted, which are still exactly the same.
BTW, it might be obvious, but those screenshots were all taken with cloud layer ON.

I've taken 4 new screens, all with cloud layer OFF, and here they are:

O2016 - HiRes tex - D3D9 R3.1 - Cloud layer OFF

O2016 - HiRes tex - Cloud layer OFF

O2016 - Def tex - D3D9 R3.1 - Cloud layer OFF

O2016 - Def tex - Cloud layer OFF

**jarmonik** · 10-23-2018, 01:45 AM

There is a small problem on the roof panel in stock DeltaGlider. Some of the scematics are invisible in D3D9. The reason is that the alpha channel is set to be fully transparent in (blittgt1.dds). For some reason the DX7 Inline engine seems to ignore the transparency. I don't know what steps leads to this result. One way to fix this is to convert the file in DXT1 format without alpha. That seems to be working in both DX7 and DX9.

**kuddel** · 10-24-2018, 08:40 PM

I was clicking through the "The Solar System\Grand tour.scn" scenaio and found that Callisto and Ganymede were just black rsp. white spheres[1].

I could circumnavigate the problem by
1. getting Textures\Callisto.tex and Textures\Ganymede.tex from Orbiter 2016
2. remove/comment-out the "TileFormat = 2" line(s) in Config\Callisto.cfg and Config\Ganymede.cfg so that the "old .tex" files are used.

My question is: Did I miss some Hi-Res package that contain those two moons? (Minor bodies doesn't)
or are we lacking Hi-Res textures for them and the (Orbiter BEAT) repository should be "modified" as I did locally?

[1] black when using D3D9Client, white when using the inline client

GLS · 10-24-2018, 09:02 PM

Quote:

Originally Posted by kuddel

I was clicking through the "The Solar System\Grand tour.scn" scenaio and found that Callisto and Ganymede were just black rsp. white spheres[1].

I could circumnavigate the problem by
1. getting Textures\Callisto.tex and Textures\Ganymede.tex from Orbiter 2016
2. remove/comment-out the "TileFormat = 2" line(s) in Config\Callisto.cfg and Config\Ganymede.cfg so that the "old .tex" files are used.

My question is: Did I miss some Hi-Res package that contain those two moons? (Minor bodies doesn't)
or are we lacking Hi-Res textures for them and the (Orbiter BEAT) repository should be "modified" as I did locally?

[1] black when using D3D9Client, white when using the inline client

I'm running r84 and have both a Callisto\Archive\Surf.tree and a Ganymede\Archive\Surf.tree, and both look normal on MOGE and D3D9.
Did you install r84 over the Orbiter 2016 release? I think that is the way to do it, as some files aren't in the repository.

**martins** · 10-24-2018, 09:02 PM

Ganymede and Callisto should already have been included in .tree format in the Orbiter 2016 release version. They are fairly lowres, so there was no reason to include them in the MinorBodies highres package. Are you sure they are missing?

**kuddel** · 10-25-2018, 07:34 AM

The "Orbiter 2016.zip" contains them (Textures\Callisto\Archive\Surf.tree and Textures\Ganymede\Archive\Surf.tree), the SVN repo doesn't.
I used to work on the SVN repository only and add the HiRes Textures on top.

But now when I read the last note on betainstall.html it clearly states:

Quote:

[...]
Note that the texture maps for most of the planetary bodies are not included in the SVN repository. You need to install those separately. The easiest way is to re-use the texture directory from an existing Orbiter 2016 installation
[...]

Thanks for the hint!
So it's "svn checkout" + "2016 Textures" + "HiRes textures" now

You never stop learning

Summary: There is no bug! Thanks again Martin.

10-22-2018, 08:11 PM	#548
jarmonik Beta Tester	Quote: Originally Posted by martins Is there any new information on this problem with the new Titan textures in the D3D9 client? The problem with Titan textures is caused by a missing configuration file for Titan's atmosphere. The file was uploaded to D3D9 SVN right after the discovery of the problem. I'll have to double check if the file is actually present in the latest release. The file appears to be there in Orbiter BETA build of the Client but is missing from 2016 build. Last edited by jarmonik; 10-22-2018 at 08:22 PM.

10-23-2018, 01:45 AM	#551
jarmonik Beta Tester	There is a small problem on the roof panel in stock DeltaGlider. Some of the scematics are invisible in D3D9. The reason is that the alpha channel is set to be fully transparent in (blittgt1.dds). For some reason the DX7 Inline engine seems to ignore the transparency. I don't know what steps leads to this result. One way to fix this is to convert the file in DXT1 format without alpha. That seems to be working in both DX7 and DX9. Attached Thumbnails

10-24-2018, 08:40 PM	#552
kuddel Donator	Callisto & Ganymede in Orbiter BETA (r84) I was clicking through the "The Solar System\Grand tour.scn" scenaio and found that Callisto and Ganymede were just black rsp. white spheres[1]. I could circumnavigate the problem by 1. getting Textures\Callisto.tex and Textures\Ganymede.tex from Orbiter 2016 2. remove/comment-out the "TileFormat = 2" line(s) in Config\Callisto.cfg and Config\Ganymede.cfg so that the "old .tex" files are used. My question is: Did I miss some Hi-Res package that contain those two moons? (Minor bodies doesn't) or are we lacking Hi-Res textures for them and the (Orbiter BEAT) repository should be "modified" as I did locally? [1] black when using D3D9Client, white when using the inline client

10-25-2018, 07:34 AM	#555
kuddel Donator	The "Orbiter 2016.zip" contains them (Textures\Callisto\Archive\Surf.tree and Textures\Ganymede\Archive\Surf.tree), the SVN repo doesn't. I used to work on the SVN repository only and add the HiRes Textures on top. But now when I read the last note on betainstall.html it clearly states: Quote: [...] Note that the texture maps for most of the planetary bodies are not included in the SVN repository. You need to install those separately. The easiest way is to re-use the texture directory from an existing Orbiter 2016 installation [...] Thanks for the hint! So it's "svn checkout" + "2016 Textures" + "HiRes textures" now You never stop learning Summary: There is no bug! Thanks again Martin. Last edited by kuddel; 10-25-2018 at 07:48 AM.

Quick Links	Need Help?
About Us Register to Participate Orbiter Website Orbiter Download Projects Recommended Addons Orbit Hangar Mods Photo Gallery Social Groups External Links	Did you forget your password? Rules & Guidelines Frequently Asked Questions Orbiter F.A.Q. Orbiter Tutorials Orbiter IRC Chat Search Forum Site Map Contact Us Mark Forums Read

10-13-2018, 05:10 PM	#541
Ripley Tutorial translator	I could be wrong, but something from the back of my head suggested me: could you try to rename the file Device.dat in your Orbiter root folder, and see if it gets recreated upon next start?

10-13-2018, 05:29 PM	#542
Upkeep Orbinaut	Yes it does get recreated. But still no luck. Thanks again for trying. All the best Upkeep

10-13-2018, 09:36 PM	#543
kuddel Donator	A very nasty little problem you present here... Maybe this is not an option for you, but since you're having these problems after you've updated your NVIDIA driver to 411.70, would a downgrade to a former version be an option to try? Or does the 411.70 version need a BIOS update, too? But I doubt, 'cause you can run other applications (DX10, 11 or 12 I presume) without issues.

10-14-2018, 09:10 AM	#544
Upkeep Orbinaut	Thanks for your response. Yes, going back to a much earlier driver is an option I could try in principle. I expect there is not any particular problem doing so (except for establishing how far to go back as this issue has been around for me for a while now). I am now currently running Nvidia driver 416.34 which produced the same problem with Orbiter, not surprisingly. Nividia seem to update their drivers very frequently... I am nevertheless reluctant to go back to an earlier driver for a number of reasons: 1. All my other applications are working well with the new driver and I even appear to be getting better fps on some. 2. I am concerned about damaging my system in the process of going back to an older driver. I realise the risks are probably low here of course. 3. On principle I am not keen on using old drivers for anything. They are usually updated for a reason and Windows may well be updated in tandem with new releases from vendors. I like to keep the pc update to date as best I can. The strange thing is that usually, when a driver is updated, other people suffer the same problem and some expert is able to find a solution. I am not an expert at all and tend to be risk averse as far as fiddling with software is concerned. So I seem to have a uniqiue set-up here I think I am back to square 1 on this one, sadly. Anyway, thanks everyone for your efforts to help. I do appreciate them. Best wishes Upkeep

10-14-2018, 12:33 PM	#545
Ripley Tutorial translator	Quote: Originally Posted by Upkeep ...1. All my other applications are working well with the new driver and I even appear to be getting better fps on some... Since you speak about fps, I assume that by applications you mean other games?

10-14-2018, 01:25 PM	#546
Upkeep Orbinaut	Yes. That is correct. Applications was no doubt the wrong terminology. Sorry about that. Best wishes Upkeep

10-22-2018, 04:32 PM	#547
martins Orbiter Founder	Is there any new information on this problem with the new Titan textures in the D3D9 client? In particular, is the problem with the textures themselves (i.e. something I need to fix) or with the D3D9 code that somebody else is going to look into? Is it linked to the cloud layer and/or cloud shadows? What happens if clouds are disabled? Quote: Originally Posted by Ripley About these new Titan textures, I've taken 4 screenshots (scenario is "The Solar System - Titan", starting paused): Orbiter2016, default textures Orbiter2016, D3D9Client2016-R3b, default textures Orbiter2016, HiRes Titan textures + new config Orbiter2016, D3D9Client2016-R3b, HiRes Titan textures + new config

10-22-2018, 08:23 PM	#549
kuddel Donator	I can confirm, that a) the 2016 Version (of D3D9Client) is lacking those configuration files[1] b) with them, Titan looks nice in Orbiter 2016. ...I'll wait for Jarmo to commit those files into the branch. [1] Titan.atmo.cfg and Titan.atms.cfg

10-22-2018, 08:28 PM	#550
Ripley Tutorial translator	I've updated to the latest D3D9 (R3.1), but the result is no changes to the 4 screenshots I already posted, which are still exactly the same. BTW, it might be obvious, but those screenshots were all taken with cloud layer ON. I've taken 4 new screens, all with cloud layer OFF, and here they are: O2016 - HiRes tex - D3D9 R3.1 - Cloud layer OFF O2016 - HiRes tex - Cloud layer OFF O2016 - Def tex - D3D9 R3.1 - Cloud layer OFF O2016 - Def tex - Cloud layer OFF

10-24-2018, 09:02 PM	#553
GLS Addon Developer	Quote: Originally Posted by kuddel I was clicking through the "The Solar System\Grand tour.scn" scenaio and found that Callisto and Ganymede were just black rsp. white spheres[1]. I could circumnavigate the problem by 1. getting Textures\Callisto.tex and Textures\Ganymede.tex from Orbiter 2016 2. remove/comment-out the "TileFormat = 2" line(s) in Config\Callisto.cfg and Config\Ganymede.cfg so that the "old .tex" files are used. My question is: Did I miss some Hi-Res package that contain those two moons? (Minor bodies doesn't) or are we lacking Hi-Res textures for them and the (Orbiter BEAT) repository should be "modified" as I did locally? [1] black when using D3D9Client, white when using the inline client I'm running r84 and have both a Callisto\Archive\Surf.tree and a Ganymede\Archive\Surf.tree, and both look normal on MOGE and D3D9. Did you install r84 over the Orbiter 2016 release? I think that is the way to do it, as some files aren't in the repository.

10-24-2018, 09:02 PM	#554
martins Orbiter Founder	Ganymede and Callisto should already have been included in .tree format in the Orbiter 2016 release version. They are fairly lowres, so there was no reason to include them in the MinorBodies highres package. Are you sure they are missing?