New Orbiter Beta Released (r.44, Dec 5 2015)

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
Committed r.30

Incremental update. Change log:
  1. Bug fix: VESSEL::GetTotalPropellantFlowrate did not return correct values [issue #947]
  2. oapiGetBaseByName: no longer crashes if OBJHANDLE parameter refers to a non-planetary body object (but still requires valid OBJHANDLE); see http://orbiter-forum.com/showthread.php?t=36031
  3. DeltaGlider: subsystem code restructuring (ongoing)
 

Hlynkacg

Aspiring rocket scientist
Addon Developer
Tutorial Publisher
Donator
Joined
Dec 27, 2010
Messages
1,870
Reaction score
3
Points
0
Location
San Diego
Yes, I've been thinking about a new "ActiveGroundStructure" class as a kind of stripped-down vessel.

A ways back I asked about the possibility of a DLL module interface for surface bases. Any chance of that getting revisited?

---------- Post added at 22:57 ---------- Previous post was at 19:42 ----------

To clarify, allow surface base .cfg files to load a .dll similar to how the vessel class modules work.

That .dll can then be used to define things like lighting, animations, and other active elements in much the same way a vessel's .dll would.
 

Topper

Addon Developer
Addon Developer
Donator
Joined
Mar 28, 2008
Messages
666
Reaction score
20
Points
33
Using the new API function "oapiSurfaceElevation", I created a little MFD mode which shows a topographic map. It's just experimental and just for fun.

topoMFD.png


I noticed that "oapiSurfaceElevation" is a bit to slow for this task.
The generation for such a map needs ~ one second, depending on the zoom level, and so the FPS in Orbiter goes down.

My feeling is that the map generation is slower the farther the queried point is.
Of course, it's necessary to use the function for each pixel so maybe it's normal and it works as designed.
Even painting each single pixel of the MFD takes a bit time, so maybe I should give up my plans for such a MFD mode for the next time if there is no way to improve it at the moment...
 
Last edited:

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
Committed r.31

Change log:

  • Mainly deals with the "floating runway" problem. This should be fixed now.
  • Taxiways (and similar) defined as meshes should now also be fixable, but they require a new flag in their base config entry: "WRAPTOSURFACE". This is because Orbiter doesn't know if a mesh should be wrapped to the surface or not. If the flag is not specified, the mesh is uniformly elevated to the elevation of its reference point (which still works if the surface is flat)
  • As usual more DeltaGlider re-coding
Note that runways and taxiways can still be partly covered by the underlying surface texture, since the elevations are mapped only at the nodes, which are not conforming between surface grid and decal mesh. In the inline client this is taken care of with a hack: the runways and taxiways (anything with UNDERSHADOW flag) is rendered without z-testing on top of the surface. This however leads to other artefacts (runways visible through mountains).

I'll try some stencil buffer tricks to see if this can be fixed.


I noticed that "oapiSurfaceElevation" is a bit to slow for this task.
The generation for such a map needs ~ one second, depending on the zoom level, and so the FPS in Orbiter goes down.

My feeling is that the map generation is slower the farther the queried point is.
Of course, it's necessary to use the function for each pixel so maybe it's normal and it works as designed.
Even painting each single pixel of the MFD takes a bit time, so maybe I should give up my plans for such a MFD mode for the next time if there is no way to improve it at the moment...

The oapiSurfaceElevation is not really meant to extract an entire surface raster. I could expose a function to return the entire elevation grid for a surface tile (something similar exists for the GraphicsClient interface), but this might be a bit more tricky to use (you first need a handle to a planetary body's elevation manager, then specify the tile by latitude/longitude indices and level. It's not really something I would like to expose to the "user space" API.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,660
Reaction score
2,381
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Will you document the elevation file format? Then it would be possible for such special MFDs to prepare their data during start-up and use optimized data during run-time.
 

Topper

Addon Developer
Addon Developer
Donator
Joined
Mar 28, 2008
Messages
666
Reaction score
20
Points
33
Change log:
I could expose a function to return the entire elevation grid for a surface tile (something similar exists for the GraphicsClient interface), but this might be a bit more tricky to use (you first need a handle to a planetary body's elevation manager, then specify the tile by latitude/longitude indices and level. It's not really something I would like to expose to the "user space" API.

Ok thanks! I would give it a try if you expose this function.
I also need to improve the drawing of the map:
Now I just use Sketchpad->LineTo (x,y) and I need to create and release the "Sketchpad Pen" for each pixel just to change the color.
Maybe there are better solutions but I guess thats stuff for the sdk section later on...
 
Last edited:

fred18

Addon Developer
Addon Developer
Donator
Joined
Feb 2, 2012
Messages
1,667
Reaction score
105
Points
78
Hello!

I have a small question and I'm sorry if it was already done, but couldn't find around the exact answer:

I am compiling multistage2015 for the new beta and changing what has to be changed. In particular the 2010P1 gets to the proper orbit inclination by heading correction across ascent and it basically recalculates the azimuth each time to correct the heading. It uses GetHorizonAirspeedVector to get eastward velocity (+ earth rotation) and northward velocity in order to do the proper calculation.

for the Beta I changed the GetHorizonAirspeedVector to

Code:
VECTOR3 hspd;
GetGroundspeedVector(FRAME_HORIZON,hspd);

as I think is correct, but in 2010P1 version the final orbit inclination at burnout was very very precise, independently on orbiter configuration (non spherical gravity source activated or not etc).

In orbiter beta I keep getting an error from 2 to 10 centimals of degree at burnout, depending on launch site and target inclination (also independent on orbiter configuration).

Therefore my question is: was there any change from airspeedvector to groundspeedvector? Or is there any change relevant to latitude calculation etc?
Something else that I need to take into the count?

Thanks in advance!

Fred

---------- Post added at 19:21 ---------- Previous post was at 13:26 ----------

Sorry to bother, I just found another thing that I don't understand and maybe could be useful to be pointed out.

The very same routine for jettison/spawning of stages behaves differently from 2010P1 to the new beta, in particular relevant to the ShiftCG call.

I found it a bit difficult to explain so I post the code, if this is not the right place to do it I'm sorry

This is my jettison routine:
Code:
                Spawn(type,current);
		DelMesh(stage[current].msh_idh);
		ClearThrusterDefinitions();
		DelPropellantResource(stage[current].tank);
		currentStage+=1;
		UpdateMass();
		UpdatePMI();
		CreateUllageAndBolts();
		CreateMainThruster();
		CreateRCS();
		ShiftCG(_V(0,0,(stage[current+1].off.z-stage[current].off.z)));
		SetCameraOffset(_V(0,0,0));

And this is my spawning routine
Code:
char mn[MAXLEN];
VESSELSTATUS2 vs;
memset(&vs,0,sizeof(vs));
vs.version=2;
GetStatusEx(&vs);
VECTOR3 ofs;
VECTOR3 rofs, rvel = {vs.rvel.x, vs.rvel.y, vs.rvel.z},vrot={vs.vrot.x,vs.vrot.y,vs.vrot.z},arot={vs.arot.x,vs.arot.y,vs.arot.z};
VECTOR3 vel; 
GetMeshOffset(stage[current].msh_idh,ofs);
vel =_V(stage[current].speed.x,stage[current].speed.y,stage[current].speed.z);
Local2Rel (ofs, vs.rpos);
GlobalRot(vel,rofs);
vs.rvel.x=rvel.x+rofs.x;
vs.rvel.y=rvel.y+rofs.y;
vs.rvel.z=rvel.z+rofs.z;
vs.vrot.x=vrot.x+stage[current].rot_speed.x;
vs.vrot.y=vrot.y+stage[current].rot_speed.y;
vs.vrot.z=vrot.z+stage[current].rot_speed.z;

strcpy(mn,stage[current].meshname);
		
oapiCreateVesselEx(mn,stage[current].module, &vs);

In orbiter Beta the spawned stage and the new stage get overlapped when this function is called, like this:

staging.png


If I call ShiftMeshes manually then it works properly.

looks like if I delete a mesh, the next one is running back in the offset of the first one. Actually also if I don't call shift CG the visual looks good, but of course then engines etc are not in the correct place.

Thanks

Fred
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
I noticed that "oapiSurfaceElevation" is a bit to slow for this task.
The generation for such a map needs ~ one second, depending on the zoom level, and so the FPS in Orbiter goes down.

Cool. Maybe you could try to discretize the map, fill it with calculations, cache them, and then once enough movement has been made in a given direction, (using floor / ceil), shift the map, but query only for the changed part (incoming from the border), and query your cache for the remaining points?
 

Topper

Addon Developer
Addon Developer
Donator
Joined
Mar 28, 2008
Messages
666
Reaction score
20
Points
33
Thanks great Idea Enjo!
I don't know if it's then fast enogh but it should be much faster as it is now.

Because this is not the thread to discuss addon developement and I don't want to go off topic, I've opened a new thread.
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
The oapiSurfaceElevation is not really meant to extract an entire surface raster. I could expose a function to return the entire elevation grid for a surface tile (something similar exists for the GraphicsClient interface), but this might be a bit more tricky to use (you first need a handle to a planetary body's elevation manager, then specify the tile by latitude/longitude indices and level. It's not really something I would like to expose to the "user space" API.
The function is not necessarily the problem. See my added post here.
 

Topper

Addon Developer
Addon Developer
Donator
Joined
Mar 28, 2008
Messages
666
Reaction score
20
Points
33
The function is not necessarily the problem. See my added post here.

Maybe yes, maybe not...
As discussed, the drawing of the MFD is not the "main issue" and I need further tests.

Because oapiSurfaceElevation not really meant to extract a surface raster, it could make sence to extract such a function.

How ever, I can continue the way we discussed first to find it out.
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
Maybe yes, maybe not...
My point is: please verify this first, before distracting Martins from the main task of providing a stable release so that we have a "save state".

---------- Post added at 04:20 PM ---------- Previous post was at 02:12 PM ----------

... besides, caching will help you even if you're right on this one.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
Committed r.32

Change log:
  • Bug fix: VESSEL::ShiftCG did not correctly update global position
This update addresses the bug reported below. Please let me know if this now works as expected.

Sorry to bother, I just found another thing that I don't understand and maybe could be useful to be pointed out.

The very same routine for jettison/spawning of stages behaves differently from 2010P1 to the new beta, in particular relevant to the ShiftCG call.

I found it a bit difficult to explain so I post the code, if this is not the right place to do it I'm sorry

(Code snippets)

If I call ShiftMeshes manually then it works properly.

looks like if I delete a mesh, the next one is running back in the offset of the first one. Actually also if I don't call shift CG the visual looks good, but of course then engines etc are not in the correct place.

Thanks

Fred
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
I am compiling multistage2015 for the new beta and changing what has to be changed. In particular the 2010P1 gets to the proper orbit inclination by heading correction across ascent and it basically recalculates the azimuth each time to correct the heading. It uses GetHorizonAirspeedVector to get eastward velocity (+ earth rotation) and northward velocity in order to do the proper calculation.

for the Beta I changed the GetHorizonAirspeedVector to

Code:
VECTOR3 hspd;
GetGroundspeedVector(FRAME_HORIZON,hspd);

as I think is correct, but in 2010P1 version the final orbit inclination at burnout was very very precise, independently on orbiter configuration (non spherical gravity source activated or not etc).

In orbiter beta I keep getting an error from 2 to 10 centimals of degree at burnout, depending on launch site and target inclination (also independent on orbiter configuration).

Therefore my question is: was there any change from airspeedvector to groundspeedvector? Or is there any change relevant to latitude calculation etc?
Something else that I need to take into the count?

There is indeed a small change between the definitions of GetHorizonAirspeedVector in 2010-P1 and GetGroundSpeedVector(FRAME_HORIZON) in the beta:

In 2010-P1, the vector returned by GetHorizonAirspeedVector is the vessel's velocity vector (relative to the planet centre) minus the velocity of a surface point below the vessel - independent of the vessel's altitude.

In the beta, the vector returned by GetGroundSpeedVector is the vessel's velocity vector (relative to the planet centre) minus the velocity of a point at the current vessel position, fixed in the rotating planet frame. In other words, it is the vessel's velocity in the rotating planet frame.

The two definitions are identical at ground level, but start to diverge at higher altitudes. In particular, a vessel in geostationary orbit has a zero groundspeed in the new definition, but had a nonzero airspeed in the old definition. (I think my rationale of the old definition was something like the atmosphere lagging behind the rotating planet surface at higher altitudes - which obviously is not correct.) So the new version is intended to remove this ad-hoc assumption and provide a more consistent definition.

Does that make sense? Given this new definition, can you correct your ascent calculations so that they come to correct results again?
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
Committed r.33

Change log:
  1. Bug fix: calling ShiftCG in VESSEL2::clbkLoadStateEx caused CTD at second launch [issue #1064]
  2. DeltaGlider: MFD instruments implemented as subsystems
 
Top