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

[Hlynkacg]

I am not 100% sure what you are referring to. Depending on camera mode, you can define the camera direction, or the position of the camera relative to a target, via azimuth and polar angle. If you are referring to additionally rotating the camera around its longitudinal axis, that isn't possible.

Effectively, the beta hasn't changed any of the underlying capabilities of the camera, but access to these capabilities from the API. So I would tentatively answer no to your question.

Understood, would it be possible to add longitudinal/roll to interior and exterior cameras at some point in the future? I'm thinking specifically about being able to have a "docking camera" who's alignment vectors would match the docking port's.

IE SetCameraParams (pos, dir, rot);

Another issue, did you make any changes to how animations are handled, specifically MGROUP_ROTATE? Something in one of the updates since 0.47 seems to have broken the engine gimbal animation on my Lunar Module. The code on my end hasn't changed and it still seems to work in Orbiter 2010.

---------- Post added at 10:21 ---------- Previous post was at 10:18 ----------

PS: Sorry If I seem like I'm nit-picking. Please keep up the good work. I've been having a blast with the new beta.

 

[Hlynkacg]

An update on my animation problem.

My existing code used the "VESSEL::SetAnimState()" function, replacing it with "SetAnimation()" seems to have fixed the problem. If SetAnimState() has been depreciated the documentation ought to be updated to reflect this.

 

[martins]

An update on my animation problem.

My existing code used the "VESSEL::SetAnimState()" function, replacing it with "SetAnimation()" seems to have fixed the problem. If SetAnimState() has been depreciated the documentation ought to be updated to reflect this.

Interesting - SetAnimState was already obsolete in the 2010 version, and possibly even earlier than that. You are saying that this actually worked until a few beta commits ago? That doesn't really make sense. I haven't changed the animation code for years.

 

[Hlynkacg]

SetAnimState works in Orbiter 2010 P1. It could have failed at some point in the interim and I just didn't notice.

 

[jarmonik]

There appears to be a minor tile visibility bug effecting the inline and D3D9. So, far I have only noticed it while viewing Brighton Beach.

Screen resolution is 1920x1080

 

[Abloheet]

What about the dg atmospheric autopilot? Is it working?

 

[Enjo]

What about the dg atmospheric autopilot? Is it working?

Did DG ever have an atmospheric autopilot?

 

[DaveS]

AMSO apollo not working orbiter beta :shrug:
View attachment 14321

That's on AMSO, not Orbiter. So please make a request elsewhere and ask the author of AMSO to update it when Orbiter 2016 goes live for real. You could try Dan's forum as I have seen him around those parts.

 

[Urwumpe]

Did DG ever have an atmospheric autopilot?

Yes, since 2010, by Lua scripts.

 

[4throck]

Perhaps not the best topic for it, but I've made some progress in writing a Python script to convert a global heightmap image into level 4 elevation data.

There are some problems with scale and 16bit encoding (my fault, but I'm still learning these things) yet Iapetus equatorial ridge is visible!

View attachment 14326

 

[jarmonik]

The surface tile visibility issue seems to originate from Tile::InView. Also, as the screen shot shows, corners of several missing tiles are within a viewing frustum that also includes the corners of bounding boxes. So, the actual clipping occurs on a higher level of the tile quad-tree.

I noticed that if I change this code section:

// build a transformation matrix for frustum testing
MATRIX4 Mproj = _MATRIX4(scene->GetProjectionMatrix());
Mproj.m33 = 1.0; Mproj.m43 = -1.0;  // adjust near plane to 1, far plane to infinity
MATRIX4 Mview = _MATRIX4(scene->GetViewMatrix());
prm.dviewproj = mul(Mview, Mproj);

to this one:

Mproj.m33 = 1000.0; Mproj.m43 = -1.0;

the problem seems to disappear or at-least reduce. Any ideas what's going on there ? Since, the frame rate remains unchanged it looks like it's still clipping the tiles it needs to.

 

[martins]

I am currently looking into this. The problem seems to arise when a single vertex close to the plane z=0 decides about visibility. There is a singularity at z=0, and points close to it may be affected by rounding errors. Possibly the transformation matrix requires re-orthonormalisation.

Edit: Ok, I've been trying to figure out how I actually designed the projection matrix, and I think I might have spotted the problem:

The projection matrix is set up to map the near plane from +1 in camera space to 0 in projection space. However, since the singularity appears at 0 in camera space there is a mismatch in the InView code for points between 0 and 1 in camera space.

Try to replace the lines

if (vt.z >  0.0) bz1 = true;
else hx = -hx, hy = -hy;

with

if (vt.z >  0.0) bz1 = true;
if (vt.w < 0.0) hx = -hx, hy = -hy;

Since the mapping produces w' = z, this change should flip the coordinates at the correct singularity position.

Let me know if this fixes the problem, and I'll put it in the next beta.

 

[jarmonik]

Let me know if this fixes the problem, and I'll put it in the next beta.

Yes, that seems to fix the problem. All test scenarios are running fine and I haven't been able to reproduce the problem any more. Great work :thumbup:

 

[4throck]

Using Earth surface+elevation data on Venus (only up to level 4) I get this strange effect (clouds removed):

View attachment 14328
View attachment 14329

It's the same on the standard or DX client.

 

[Marg]

Using Earth surface+elevation data on Venus (only up to level 4) I get this strange effect (clouds removed):

View attachment 14328
View attachment 14329

It's the same on the standard or DX client.

Wasn't the case, that Venus still is not on this new standart\format?

 

[4throck]

I changed Venus.cfg to the same surface parameters as Earth. ;-)

 

[martins]

New Orbiter Beta Released (r.52, Mar 09 2016)

Change log:

1. Bug fix: tile visibility check would sometimes produce false negatives, resulting in visual artefacts (missing surface tiles) as discussed here.
2. Bug fix: Incorrect elevation mapping for low-resolution (level 4) tiles, resulting in visual artefacts (random elevations) as discussed here.
3. Reverted default Earth atmosphere model to J71G (had inadvertently been set to the Legacy2006 model for debugging)
4. Playback scenarios: can now specify flight data directory with "Playback" entry in Environment group
5. Scenarios: added some more scenarios in 2016 folder, removed some obsolete scenarios from 2010 folder

A new commit to OVP (r.49) implements point 1 in the D3D7 client.

Using Earth surface+elevation data on Venus (only up to level 4) I get this strange effect (clouds removed):

This should now be fixed.

 

[Post much?]

Perhaps not the best topic for it, but I've made some progress in writing a Python script to convert a global heightmap image into level 4 elevation data.

There are some problems with scale and 16bit encoding (my fault, but I'm still learning these things) yet Iapetus equatorial ridge is visible!

View attachment 14326

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

 

[martins]

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

This reminds me that I had promised to provide an example script for elevation tile generation. Here is the Matlab script I used to generate the lunar level-12 elevations from LOLA data. Note that this script (make_patch_ldem.m) expects the LDEM_512_*.img raw elevation data files, as found at http://imbrium.mit.edu/DATA/LOLA_GDR/CYLINDRICAL/IMG/ to be located at ../data

To adapt this script to other data sources you will probably have to edit it somewhat, to account for differences in the source formats. This is just meant as an illustrative example. However, the tile read/write functions (read_elev_patch.m and write_elev_patch.m) may be useful since they encode the tile format as expected by Orbiter.

 

[birdmanmike]

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