The visual model and physics model are a single thing in EVDS/FoxWorks Aerospace Simulator. So rendering the models is a pretty trivial task and animation comes naturally from the physics of the vessels themselves.
For example, here’s motion of gimbal platform (as commanded by a pre-defined program). The motion corresponds to what happens in the physics engine:
In the future, every motion of any control surface will both have physics effect and visual feedback. It is one of the main features of the EVDS physics engine.
The rendering got improved and all minor bugs are fixed. The simulation is still disabled, but now I’m working on adding LOD support to speed up the rendering.
The mesh generation is multithreaded – procedural meshes are generated on every core while X-Plane itself is loading. Right now every single object has a unique mesh, although that will change in the future (copies of objects will all share the same mesh).
Some additional screenshots of the whole launch pad assembly (which is placed by exact geographical WGS-84 coordinates, which are transformed into X-Plane local coordinates). I can’t be entirely sure of X-Plane coordinate transformation… but I hope it matches with WGS-84 properly.
I’ve started work on FoxWorks Aerospace Simulator X-Plane client. This will allow to run simulations inside X-Plane and later also connect X-Plane as a rendering engine for another instance of FWAS or any EVDS-based simulator.
Right now it merely loads up the mesh (there are some minor bugs and the simulation is still disabled):
All the models are procedural and generated from an EVDS file. Texture support will become available some time in the future.
I’m resuming the blog! Again! There was a temporary delay – and as a result I got a driving license.
FoxWorks simulator has got a website now. Here’s a picture of it (very likely its outlook will change a lot in the future):
There are many updates related to EVDS, FoxWorks and FoxWorks Editor, and I’ll try to post about them over time. Right now my work mainly lies in re-starting VSFL (Virtual SpaceFLight Network) and putting all the parts of the simulator itself together.
I’ve added a basic throttle model to EVDS rocket engine simulator which models how engine thrust varies during startup, shutdown and throttling. It uses exponential startup and shutdown transients, as well as exponential (or linear) throttle transient. This seems to model real world engines more or less well.
In this picture, the engine starts up when throttle is commanded above 50% (minimum set), and shuts down when throttle is commanded below 25% (arbitrary threshold):
And exponential throttle transients compared with linear throttle transients:
All transients can be configured by specifying certain parameters, see picture:
In EVDS, throttle speed is specified instead of throttle time (maximum rate of throttle change, percent per second). All transient times are specified so if (for example) engine starts at 0%, at the moment of startup time the engine has already reached 95% of thrust.
And just for fun, here are graphs of STS (Space Shuttle) OMS engines transients (they are somewhat different due to engine nature though):
This is just a small thing I’m working on for EVDS. If one takes 3000 data points and interpolates them with a spline, that will be 2999 different polynomials describing line segment between every two points. If I want to store smooth functions, that’s a little bit too much.
I wrote a simple tool (first in Mathematica, then in C) which optimizes number of splines describing the function, given maximum residual error. Instead of 3000 splines, it may reduce that number down to 5-20 splines which still approximate the source function (the big bold points are the points which were retained for building the spline):
Additional examples with more source points:
The tool will be available as part of EVDS later.
I haven’t been writing to this website much! Over the last few days I’ve started adding unit tests to EVDS, as well as improving the way it handles coordinate systems as inspired by Orekit, its sort of a competitor.
There are four kinds of coordinate systems currently supported or planned for EVDS:
- Cartesian coordinate system of any object in EVDS – these are coordinate systems in which actual calculations are performed, EVDS has a very wide support for automatic conversion between such coordinates, including non-inertial coordinate frames.
- Pre-defined cartesian frames – EVDS will output state vector for several predefined coordinate systems used widely (for example J2000).
- LVLH frame – local vertical, local horizontal. This coordinate frame is local horizon relative, it is mostly used to determine aircraft pitch/yaw/roll angles relative to ground and such. X-Plane works exclusively with LVLH non-inertial coordinates.
- Geodetic coordinates – latitude, longitude, altitude given datum.
The default cartesian coordinate frame corresponds to vessel coordinates like this:
EVDS now supports arbitrary datums for any planetary (or non-planetary) body. Right now the datums are only defined by the reference ellipsoid centered in the planets center of mass, but in future this can be easily extended. EVDS geodetic vectors, just like normal position vectors, are tied to a specific objects cartesian coordinate system.
Here are the schematics for the RV-501 rocket – the first configuration which used the solid rocket motors. These schematics are created using FoxWorks Editor. They aren’t very useful and I can’t provide much labels that would point out various specifics of the rocket, but it’s still a work in progress.
You can click on these. They are actually fairly large (A3, 32 pixels per cm).