Thorsten wrote in Thu May 26, 2016 6:31 pm:So it requires a numerical prediction of the trajectory. This needs to be done at high temporal resolution to avoid numerical drift and hence be split across multiple frames (I'm forwarding some 5 seconds per frame). Then the calculation takes time... perhaps some 4 seconds. What I figured out today is that computing distance to target without taking the calculation time into account causes an offset of some 40 km in the result - because stuff in orbit moves fast.
Now the code latches onto the wrong solution - it gets the closest distance when the Shuttle on the rising trajectory passes right underneath ISS, rather when it reaches apoapsis and ISS comes from behind 15 minutes later. So the whole aim has to be refined.
Not sure where your computations are running (JSBSim, Nasal, C++, GLSL/effects (GPGPU)) - but if you are using Nasal to do any of this, you may want to consider using a worker thread to run/update your calculations - Nasal threads generally work fairly well, you just need to avoid using any of the FlightGear specific extensions functions or accessing/mutating anything that is updated/used in the main loop.
A worker thread can be invoked using thread.newthread( function): http://wiki.flightgear.org/Howto:Start_ ... s_in_Nasal
- Code: Select all
thread.newthread( func() {
for (var i=0;i<10000;i++) {
var j = i*i+i*i / i/2
} # for-loop
}); # newthread call
Note that you can access other Nasal variables just fine - but you would want to use a reader/writer separation to prevent race conditions (i.e. no properties) - and you may want to use one of the serialization mechanisms (mutexes and semaphores are both supported by the thread module).
This means that any getprop()-like calls would need to take place in the main thread, where you'd then put all retrieved state into native Nasal data sttructures variables, that can be safely accessed from a Nasal worker thread.
Obviously, you can pretty much ignore everything I said if you are doing computations in C++, GLSL or JSBSim space - equally, before you consider porting any non-Nasal stuff over to Nasal, it would probably make sense to use the Nasal Console to see if that makes sense or not.
In general, it is likely that a property-rule, fgcommand or JSBSim building block should be faster than any Nasal code - but Nasal code using thread.newthread() is not executed within the main loop thread (however, it does share the same GC context for the time being, so that main-thread GC pressure will also impact the worker thread to some degree).
Feel free to get in touch if you'd like to investigate using background threads in a producer/consumer fashion. Alternatively, it would also be possible to add XML/property building blocks to make these things possible using fgdata-level hooks.