New Orbiter SVN commit (r.71, Oct 14 2017)

[martins]

on the SVN update to r52 getting conflicted scenarios (currentstate).scn - skipped.
Should I worry?

No. This is because the latest commit has an updated default (CurrentState).scn, while your checked-out version has a local modification (after running Orbiter).

If you want to see the default CurrentState as it will appear in a new Orbiter installation, just delete your local (CurrentState).scn and update from the repository. But it's actually just a copy of 2016 Edition/Welcome to Orbiter 2016.

 

[4throck]

Any chance you could polish up a new version for distribution?

Sure, when I get around to handling elevation scale , a few issues with duplicated data around the poles and output to higher resolutions (with proper folder structure).
Anyway, the script is aimed at importing data in image format, with altitude as grayscale values.

For now, here are the height files for Iapetus (with the above problems). Should be good enough to do some flying
View attachment 14332

 

[4throck]

Bug fix: tile visibility check would sometimes produce false negatives, resulting in visual artefacts (missing surface tiles) as discussed here.
Bug fix: Incorrect elevation mapping for low-resolution (level 4) tiles, resulting in visual artefacts (random elevations) as discussed here.
This should now be fixed.

Confirmed Venus loads OK with level 4 surface+elevation :thumbup:

 

[Marg]

I can report one issue... when scenario (on the Moon) is saved with ground camera near landed vessel, after loading scenario again, ground camera is reset to "0" level (I think), because it`s ~2900 m above vessel.
I can move viewpoint back to vessel, but after reloading scenario, it is up there again....
Likewise when I use ordinary camera (Abs-Dir, for example), being near vessel, if I press ground camera "current" tab (to switch to ground camera), it jumps up...

 

[Post much?]

I re-saved the TC tiles (@512 ppd) to .bil, changed extension to .IMG, even edited a whole set of .LBL files to match the binary data. The script was in the root (C:\) directory, and the folder for the data was in C:\data. Yet, I get this...

processing: 12/0/0 ... Error using fread
Invalid file identifier. Use fopen to generate a valid file identifier.

Error in make_patch_ldem>maketile (line 204)
                    loadim = fread(fid,[im_nc,im_nr],'int16',0,'l')';

Error in make_patch_ldem (line 107)
            elev = maketile(level,ilng,ilat,display);

This was only with the make_patch_ldem.m script. Does it require the other scripts as well?

Using R2015b

EDIT: Adding the other scripts to the root directory fixed the problem. Alas, I only have 12GB of memory...

>> make_patch_ldem
processing: 12/0/0 ... Error using fread
Out of memory. Type HELP MEMORY for your options.

Just to note, make_patch_ldem requires 16 tiles, each covering a 90°×45° region, and with the format filename_**N/S_**N/S_***_***.IMG,
where the first two fields indicate latitude and the last two fields indicate longitude, in PDS convention (0°-360°):

latname = {'45N_90N','00N_45N','45S_00S','90S_45S'};
lngname = {'180_270','270_360','000_090','090_180'};

Saving as a raw 16 bit signed file should work. The method I used was writing as a .bil within GDAL. Also I changed the variable data_scale to 1
to match the data values of my chosen dataset.

Change the variables im_nr (vertical resolution) and im_nc (horizontal resolution) to match the dimensions of the tiles.

 

[martins]

EDIT: Adding the other scripts to the root directory fixed the problem. Alas, I only have 12GB of memory...

>> make_patch_ldem
processing: 12/0/0 ... Error using fread
Out of memory. Type HELP MEMORY for your options.

Yes, well I was running the script on a Linux machine with 128GB RAM, so memory conservation wasn't a high priority. The script will require some extensive re-design to make it more memory-efficient.

 

[Eduard]

To be a little help in the development I would like to report some things here ...

> I have done a little test with the latest beta versions, I still notice the following critical problem:
Using timewarp 1000x or 10000x for a while frequently results into a CTD, for example when traveling between Earth and Moon. Most often it happens with the D3D9Client, but I also noticed it with the stock client. It starts with a badly responding and shaking screen during a short time, before the complete crash occurs.
It especially occurs almost always when using the Shuttle-A vessel, but I have seen it happening with the Deltaglider too now.
But when I start a saved scenario in transfer to the Moon in without changing anything in the orientation of my vessel, than the CTD doesn't seem to happen. I need to "do" something first. For example when I use the rotation RCS and then use timewarp, than it occurs.

> Deployed radiator of the Deltaglider automatically closes when starting saved scenario. Is this a known problem?

 

[Ripley]

Deployed radiator of the Deltaglider automatically closes when starting saved scenario. Is this a known problem?

I noticed it too.

 

[jedidia]

Most often it happens with the D3D9Client, but I also noticed it with the stock client. It starts with a badly responding and shaking screen during a short time, before the complete crash occurs.

That sounds very familiar. I can get the exact same symptoms after a minute or two of zooming in and out from the moons surface with terrain resolution set to 128 in D3D9 client.
Given your report, it seems possible that the problem originates in the orbiter core and gets expounded by the higher settings allowed by D3D9client.

for example when traveling between Earth and Moon.

Can you be more specific? does the crash happen in a place where you could reasonably expect some terrain loading and unloading going on? To me, the whole thing still smells of a memory leak in the terrain engine, but I could easily be wrong.

 

[jroly]

Yes I too have had problems with it at 128, but I usually use dx9 client. It happens when near the terrain.

 

[Eduard]

Can you be more specific? does the crash happen in a place where you could reasonably expect some terrain loading and unloading going on? To me, the whole thing still smells of a memory leak in the terrain engine, but I could easily be wrong.

Good question. No I do not believe it's terrain loading related problem, because I also experience the problem when doing mid-course corrections half away, when being at the boundary of Earth's major SOI, still very far away from the Moon. I warp time to that point to get more stable data in TransX.
So the first thing I asked myself was if it could be a TransX-problem. But completely disabling TransX does not solve the problem.

And the crash does not seem to happen when I haven't don any engine- or RCS-actions with the selected vessel after starting a scenario.
When I orbit the Moon I and warp time, I really hear a lot of harddisk reading and see indeed some slowing down because of it (I have downloaded all hi-res textures), but this does not crash my Orbiter process. And I believe this part has been programmed very well now and tested very well by everyone.

I think it may be related to someting with celectial bodies or gravitation, but not the terrain thing or surface textures.

So It has to be an Orbiter core-problem indeed. Not occurring with my Orbiter 2010 instance, but it is something new in the Beta.
I am running Windows 10 and I have an GeForce GTX 750 Ti videocard.

 

[jedidia]

And the crash does not seem to happen when I haven't don any engine- or RCS-actions with the selected vessel after starting a scenario.

Interesting... I have no thruster action at all going on in my tests. I wouldn't suspect a connection between the issues if it wasn't for the exact same symptoms described.

Might help if you post the scenario and exact steps for reproduction, so I and others can try to confirm.

And I believe this part has been programmed very well now and tested very well by everyone.

Oh, it's not about the quality of the coding. It wouldn't be C++ if it wouldn't be leaking at some point during development :lol:

 

[jarmonik]

...with terrain resolution set to 128 in D3D9 client.

That will cause the system to run out of memory, 128 is a way off being anything practical at a moment. With that setup surface vertex data alone can take 1GB of memory and that's too much for 32-bit apps. With tile resolution setting 32 the total vertex data consumption is something like 25-50MB.

It's recommended to keep the tile resolution at 32 until we have a better LOD control.

 

[Eduard]

Update:

I think I have found out something new.
I experience this at least when using the D3D9Client (which uses better graphics and thus uses more memory = creating bigger risk for crashes when there are memory leaks, I think). But I cannot say for sure that the client is the (only) cause.

What I found out is the following thing:
When disabling surface elevation (nice to know there is a setting for it so I can turn it of if I like), the number of crashes appeared to decrease.
After re-enabling it, I noticed the number of crashes increased dramatically.
And now I probably now why: disabling the checkbox "Surface elevation" also defaults the setting to "linear interpolation" (after restarting the Orbiter Launchpad) automatically.
This is strange, because this is not the same default as the default when starting Orbiter the first time (or after removing Orbiter_NG.cfg), because that default is "cubic interpolation".

And that setting "linear interpolation" appears to be much more unstable than "cubic interpolation", with much more crashes when being close to Earth or Moon.

I don't have that scenario of the transfer between Earth and Moon anymore. I have to recreate it. I don't know if the CTD there has the same cause as this more elevation related CTD. It has to be tested again.

 

[martins]

Update:

I think I have found out something new.
I experience this at least when using the D3D9Client (which uses better graphics and thus uses more memory = creating bigger risk for crashes when there are memory leaks, I think). But I cannot say for sure that the client is the (only) cause.

That would be quite an essential piece of information. Can you try without the D3D9 client to see if you can reproduce the crashes? If it is reproducible, can you post a scenario?

Also, what makes you think that the problem is down to a memory leak? Do you crash due to running out of 32-bit address space? (which has been observed before, though this happens without memory leak, but because of over-enthusiastic application of memory-greedy render settings).

 

[Hlynkacg]

Just a heads up, found a possible new bug

double man_pitch = GetManualControlLevel (THGROUP_ATT_PITCHUP, MANCTRL_ROTMODE, MANCTRL_JOYSTICK);

Moves with the joystick x-axis even when linear control mode has been selected

 

[Eduard]

That would be quite an essential piece of information. Can you try without the D3D9 client to see if you can reproduce the crashes? If it is reproducible, can you post a scenario?

Also, what makes you think that the problem is down to a memory leak? Do you crash due to running out of 32-bit address space? (which has been observed before, though this happens without memory leak, but because of over-enthusiastic application of memory-greedy render settings).

Ok, I have tried some things again now, I have created three scenariofiles and tested them. I have uploaded this files here:

> Eduard.scn: Standing on brighton beach, when using timewarp for a while at high speed, I get a CTD in the D3D9Client.

> Eduard1.scn: Transfer from Earth to Moon, using DG-S. When repeating I sometimes experience a CTD, but it's difficult to reproduce.

> Eduard1A.scn: A modified version of the previous scenario: I replaced the DG-S by Shuttle-A (and checked very well that I did it in the correct way).
Now I get much more CTD's, when using the D3D9Client with setting "linear interpolation".
To reproduce: 1. move the vessel with the RCS. 2. Killrot. 3. timewarp 1000x or 10000x.
With 1000x, I am still very far away from the moon and I already get a CTD.

I have tried to reproduce exactly the same CTD with the stock client orbiter.exe, but I do not see it there anymore.
But I still think it's very strange that the problem occurs much more frequently with the Shuttle-A version than with the DG. So I am not shure if we can say that it's only a problem of the D3D9Client.

And finally, I also noticed this: Sometimes when coming very close to the moon, the stock client also crashes sometimes, at least when using "linear interpolation". This could be a purely terrain related problem of course. I don't know. But it's important to know that this also happens with the stock client.

I hope this information helps you.

 

[jarmonik]

I suppose, you could zip and post the D3D9ClientLog.html from /Modules/D3D9Client/ right after a CTD has occurred. It might give some ideas about what's going on.

 

[Eduard]

I suppose, you could zip and post the D3D9ClientLog.html from /Modules/D3D9Client/ right after a CTD has occurred. It might give some ideas about what's going on.

Ok. See the attachment, I have zipped the D3D9ClientLog.html together with the Orbiter.log here.

 

[jarmonik]

Ok. See the attachment, I have zipped the D3D9ClientLog.html together with the Orbiter.log here.

I get a log like that when Orbiter hits the 2GB memory limit. We would need to reduce a distant terrain resolution to bring down the memory consumption.