SDK Question DefSetState Perturbations

[dumbo2007]

More perturbations that I am hoping to fix soon

So with reference to the older thread here :

http://orbiter-forum.com/showthread.php?t=20201

What I am trying to do is set a vessel's position in every simulation step, from another vessel. So here is the code

//Update position using DefSetStateEx() 

    VESSELSTATUS2 mystat;
    VECTOR3 moonpos, correct_ecliptic_orientation, diff;

    memset(&mystat,0,sizeof(VESSELSTATUS2));
    mystat.version = 2;
    
    VESSEL* v = oapiGetVesselInterface(oapiGetObjectByName("Dummy"));
    v->GetStatusEx(&mystat);
    //GetStatusEx(&mystat);    

    matrixPrintD(pkt->m);
    
        
    Local2Global( _V(pkt->m[12], pkt->m[13], pkt->m[14]), correct_ecliptic_orientation);
    //oapiGetRotationMatrix(mystat.rbody, &mat); 
    //mystat.rpos = mul(mat, position_wrt_moon_frame);

    oapiGetGlobalPos(oapiGetObjectByName("Moon"), &moonpos);
    //mystat.status = 1;
    

    diff = relpos - mystat.rpos;   
    
    relpos = correct_ecliptic_orientation - moonpos;
    mystat.rpos = relpos;

    v->DefSetStateEx(&mystat);

and here is what happens :

The numbers are present here in the sheet "DefSetState"
https://docs.google.com/spreadsheet/ccc?key=0AhSyPNGmuyAqdGJsc1NfeFZDOHJXRURNVC1WdkJKMVE

and graph looks like :

 

[martins]

Does the behaviour change depending on whether you put this code into clbkPreStep or clbkPostStep? It may be that the new position is only applied at the next time step, so the two vessel positions may be out by one frame. Also, does the behaviour become less spiky if you turn on fixed time steps? This would also be an indication that the vessel positions are out of sync.

Another potential problem is

relpos = correct_ecliptic_orientation - moonpos

because it subtracts two large, similar values with potential loss of precision. However, for the moon this should not yet be critical, since |moonpos| ~ 1.5e11, while doubles provide about 16 significant digits. So you should still be in sub-millimetre precision range.

 

[dumbo2007]

ok, it's quite stable with a fixed time step of 0.01, wow !

I have the DefSetState call in the clbkPostStep() now. With variable time steps and the DefSetState call in the clbkPostStep(), the same instability is present.

So this is an issue with variable time steps I guess and not the location of the call.

By the way, whats the optimum fixed time step value ?

 

[martins]

Depends on what you want to do. Fixed time steps are for debugging (as in this case) or for non-interactive tasks (e.g. trajectory generation). They are not for general interactive simulation, since they separate the simulation time step (fixed) from the render time (variable). So the simulation is no longer real-time.

You may be able to get similar results if you turn on vsync instead of using fixed time steps.

However, all of this is not really a fix to the original problem. The state updates are a bit of a mess at the moment. I am currently in the process of rewriting and cleaning the code, and maybe this will also have an effect on this particular problem.

 

[dumbo2007]

I am currently in the process of rewriting and cleaning the code, and maybe this will also have an effect on this particular problem.

That is great news

As far as the time steps are concerned, I ll stick with attachment points for now, till DefSetState() works with variable time steps, as I need rigid positioning of objects.

I run the simulation in a 800by 200 window, so vysnc is enabled by default I think. Is there a separate option in the launchpad too(didnt find one) ?

 

[martins]

I run the simulation in a 800by 200 window, so vysnc is enabled by default I think. Is there a separate option in the launchpad too(didnt find one) ?

Vsync is not supported in window mode. You have to use fullscreen for that.