Outerra forum
Outerra Engine => Technology => Topic started by: Steve.Wilson on July 24, 2012, 12:32:27 pm
-
Hello all - first post.
I came here seeking information on a potential SDK (software development kit) for Outerra, and I'm still poking around and learning as Anteworld continues to download....
My first love is simulated aviation, and that is because this form of flying gives me the chance to see far more of our world than I will ever be able to afford to see otherwise.
I am an X-Plane addict. I'm also an X-Plane development addict - I create airplanes and customized extensions of X-Plane via Laminar's very robust SDK system. This is a new SDK discussion - the last one died in January.
I would like to pursue using Outerra as a graphical extension of X-Plane, using X-Plane physics and avionics with Outerra visuals.
What is the current state of Outerra in this area?
-
There's still no SDK or APIs for doing what you want, but it will be one of things going to be developed this year mainly as a part of our other, non-game business. Some of it will be going back to the public game version to fulfill the promise of possibility to use Anteworld as an image generator in connection with FS/FSX and X-Plane.
Apart from this connection that should be relatively simple, we will also have to find out how to feed back the elevation data to X-Plane, so that the collision data can fit the visuals everywhere. Hopefully we'll be able to figure out the integration howtos with the help of some dedicated fans :)
-
We're thinking the same thing, cameni. While crash detection will be desirable, the main thing will be some sort of interplay as to when the aircraft is on a runway. Collision detection will have to remain within Outerra, but there's bound to be situations where the X-Plane terrain would actually be higher, and that would be like flying into an invisible mountain.
The key gain from the merge of Outerra and X-Plane would be X-Plane's flight dynamics and systems modeling. Given that both would have to be running at the same time, it might be necessary to run the merger on two computers.
The main solution I see is to use the Outerra world and to modify the X-Plane Global scenery so that the whole planet is nothing but water. Without terrain, the airports still exist - just at sea level. So while the aircraft is on the ground, the Outerra physics engine would rule. X-Plane flight dynamics would only apply after the aircraft took off.
While there may be a way to integrate the two into a comfortable desktop experience, my aim is more to support the full size cockpit community, mainly people running more than one computer to satisfy their flight sim yen.
-
One thing I should add to the my reply above: Outerra/Anteworld will benefit enormously from the ability to read and write directly into the running simulation. X-Plane handles this with a robust data reference system in their SDK. It is also possible to send commands into the simulation via plugin. These two features alone constitute a tremendous amount of capability. For great reading on this, I recommend visiting the site of the X-Plane SDK, starting here: http://www.xsquawkbox.net/xpsdk/mediawiki/Documentation (http://www.xsquawkbox.net/xpsdk/mediawiki/Documentation)
-
I have no idea how it's done in X-plane, but for JSBSim there are hooks where it provides rays (point + direction and length limit) and wants to know how far the contact point lies on that ray. AFAIK it produces the rays to check for the wheels and for a couple of other points like wing endpoints etc. If something like that was in X-Plane it would be easily adaptable.
Otherwise, the interaction with ground is rather important part of the simulation, and I can't quite imagine how it could work with two physics engines - JSBSim for the ground where it also simulates the suspension produced forces, and X-Plane only for the air. Even if the JSBSim engine can be (ab)used by turning off every aerodynamic force, we would still need to provide the ground interaction forces to X-Plane as some external forces so it can include them in its physics simulation ...
-
No question that the integration of the two physics engines would be a challenge. But I suspect development of the initial SDK is more of a concern than a unique merging at this point. There is a function in the X-Plane SDK that probes for height above the terrain mesh. Collision detection is not something that has been exposed, however.....except perhaps by dataref. I think at this point the smart move for me will be to wait and see what you choose to release for the Outerra SDK, and then work forward from there.
-
One question that I didn't think of here....is the planned SDK going to be in C/C++ or some other language?
-
Primarily C/C++, but since we use code generators to generate the interfaces, there will be also others. For example, since the UI is done in html+JS, the interfaces will be also generated for javascript, accessible from UI but also possibly from web services.
-
That sounds very good. Anything that has to run inside the simulation on an every-frame basis will benefit from C/C++, naturally. Interface customization will be markedly easier in HTML and Java. Sounds like modder paradise. ;)
-
I am very interested in using Outerra as a visualization for the PAL-V flight simulator, as I now use FlightGear with the external FDM setting, and use Matlab for calculating the state of the vehicle. It does require a two way communication because Matlab needs to know the ground elevation at the wheel points. Do you think this could be implemented in the future? It would be amazing to have the PAL-V flying and driving in Outerra!
-
It's actually already there, there's an IGC interface to Outerra that allows you to write a plugin that communicates with it. See the API and an example plugin code: ot-api.zip (http://outerraworld.com/appdata/Anteworld/ot-api.zip)
-
Thank you for the plugin, it sounds promising but I do not have the knowledge to implement this myself.
-
Any word on the SDK?
-
So far the released public "SDK" is composed of an IGC (image generator control, for using OT as a visualizer) API and tracker API, ot-api.zip (http://outerraworld.com/appdata/Anteworld/ot-api.zip).
-
So far the released public "SDK" is composed of an IGC (image generator control, for using OT as a visualizer) API and tracker API, ot-api.zip (http://outerraworld.com/appdata/Anteworld/ot-api.zip).
Great news! Now I can start work on integrating my physics engine with it. When/Are you planning an API to load custom meshes into Outerra? Something that would be loaded and drawn as another world object, at API-controlled position.
I should probably update my aerospace simulator thread which is buried somewhere...
Additional question, what kind of requirement version-wise is there for using the API (aka can I use the free tech-demo available, do I need the full sandbox, etc)
-
Bringin' it way back aren't we phoenix.!
-
Nice to see ya Phoenix !
-
Great news! Now I can start work on integrating my physics engine with it. When/Are you planning an API to load custom meshes into Outerra? Something that would be loaded and drawn as another world object, at API-controlled position.
In addition to the existing aircraft, vehicle and boat object types we plan to add a "black box" object, that would allow you to run a custom physics code, generating custom force impulses. Technically you can do it even now with vehicles or boats - there's a extra_force call that can be called in the vehicle script and given position to act on in the local frame, and force vector in the local frame. It can be called multiple times in an update. Gravity is already accounted for. Using it this way instead of setting the position directly will allow you to interact with the rest of the world, for example landing in water or hitting other objects and terrain. But setting the position directly can be supported as well, in case you don't need the interactivity or the physics code can't be altered to produce forces or force impulses.
Additional question, what kind of requirement version-wise is there for using the API (aka can I use the free tech-demo available, do I need the full sandbox, etc)
Currently the tracker API works in the free demo mode, IGC works only in the full version, since custom objects are possible only there. However, it shall be also made possible to create free sim plugins for the free demo as well, once we find out and decide how the model should work.
-
In addition to the existing aircraft, vehicle and boat object types we plan to add a "black box" object, that would allow you to run a custom physics code, generating custom force impulses. Technically you can do it even now with vehicles or boats - there's a extra_force call that can be called in the vehicle script and given position to act on in the local frame, and force vector in the local frame. It can be called multiple times in an update. Gravity is already accounted for. Using it this way instead of setting the position directly will allow you to interact with the rest of the world, for example landing in water or hitting other objects and terrain. But setting the position directly can be supported as well, in case you don't need the interactivity or the physics code can't be altered to produce forces or force impulses.
Thats great news Cameni ! Didnt notice the extra_force call ... now i can make some grad shaking effect ... looking forward for the "black box" - that will be a great help whyte some ballistics-playing. 8)
-
The black box call is interesting. That would seem to suggest that using X-Plane for flight dynamics and other avionics functions is possible while seeing the model react to the Outerra world as opposed to the X-Plane world. When I get a chance, I hope to get my head around this.
-
I have just started pouring through posts to understand where the development of this engine is currently and where it is heading. At work we use our own flight dynamics simulator that effectively models our aircraft. This will not be replaced since the equations of motion and aero coefficients are custom created and extremely accurate for our fleet of aircraft. What needs improving is our image generator. Our current IG interface is socket-based using a proprietary protocol which talks with the flight simulator. I am looking for other alternatives for our IG's terrain system in particular.
I would like to be directed to documentation, if any, that describes this engine. We would need to blend in our geospecific areas such as our hand created airport areas using DAFIF data, DTED, and satellite imagery. Our main issue is not adequately supporting the surrounding areas of the world around our detailed airports. Perhaps runway and taxi ways could be generated by DAFIF as a plugin in this software.
-
I am sure Cameni (Creator) can answer any questions you have Steve. Either wait for a response here or PM him if you need an answer faster.
ALTHOUGH I would love to read the response.
-
Steve already wrote to us and I replied, but perhaps he didn't receive the email response?
-
Steve already wrote to us and I replied, but perhaps he didn't receive the email response?
Thank you for the heads up. I will go back and check my inbox as well as the spam folder. Sometimes mail gets routed there incorrectly.
-
I've integrated my physics engine with X-Plane. Now I'll be working on integrating with Outerra (it is not the first priority until the object manipulation API is available - as I want to draw the models as output procedurally by my physics engine).
Don't suppose posting pictures from X-Plane will be relevant. I am very eager to post pictures from Outerra instead when it will be possible.
-
In addition to the existing aircraft, vehicle and boat object types we plan to add a "black box" object, that would allow you to run a custom physics code, generating custom force impulses. Technically you can do it even now with vehicles or boats - there's a extra_force call that can be called in the vehicle script and given position to act on in the local frame, and force vector in the local frame. It can be called multiple times in an update. Gravity is already accounted for. Using it this way instead of setting the position directly will allow you to interact with the rest of the world, for example landing in water or hitting other objects and terrain. But setting the position directly can be supported as well, in case you don't need the interactivity or the physics code can't be altered to produce forces or force impulses.
Any update on when this will be available? I think having a "black box" object will be the best solution for other developers. My code currently calculates a list of forces in the local body frame and at various locations on the body. I can't be bothered to write my own 6DOF solver to set position directly, especially if this will be available soon.
-
Just to make sure we are talking about the same thing: it's going to be a blackbox type physics handler that can be specified when importing a model, in which case you will have to generate forces each frame. Implementation will be in C++ or Javascript.
It's already possible to do this in Javascript with the vehicle or watercraft physics handler, using the extra_force() calls. We basically just need to expose the C++ plugin API for the vehicles.
-
I suppose my code would need a bit more than just an extra_force call. I calculate all the aerodynamic forces for my aircraft, but that requires an atmosphere model. Is a standardized atmosphere model going to be part of the weather system you are working on? Do any of the vehicles (besides the aircraft, which use jsbsim atmosphere) have aerodynamic drag forces?
I haven't written my own landing gear system of forces yet, but that is part of my plan. I also don't have gravity in my forces, but that would be easy to add.
All of this written in C++ for another simulator which provides a specific set of inputs i need. I will update later on the exact list that i think would be essential for aircraft developers in a black box type object.
-
Drag forces aren't yet used for aerodynamic drag, but they are already used for the hydrodynamic drag. There is going to be a basic universal directional aerodynamic drag model applied to all vehicles, accounting for the speed vector, air pressure, wind vector etc. Of course, if one needs a special more precisely simulated model, they could use the atmo values to perform the computation themselves.
For the landing gear it would be perhaps possible to use the vehicle wheels code. Generally it's all the same model with optional parts that can be added. If you add wheels with tire and suspension parameters via the API, they'll work on black boxes too, generating extra forces. The same with the hydrodynamic/static model.
Gravity (alt dependent) is included by default.
-
Here is a list to get you started on the minimum of inputs the developer would need. Keep in mind that this is only for the calculation of vehicle dynamics.
WCS = World Coorindate System
BCS = Body Coordinate System
What is needed from the engine
Atmosphere Data (at object's current location)
===============
Altitude above sea level
Temperature
Speed of Sound
Density
Pressure
Wind in WCS
Any other weather parameters (relative humidity, etc.)
World Data (all in WCS)
==========
World position
Altitude above ground for any location (BCS) on the body
Ground surface information (if available)
Orientation (quaternion/euler)
Linear acceleration
Linear velocity
Angular acceleration
Angular velocity
Body Data (all in BCS) (Saves the developer the trouble of converting all world data into body data, but I suppose this would require knowledge of the developer's choice of coordinate system and orientation)
=========
Linear acceleration
Linear velocity
Angular acceleration
Angular velocity
Wind in BCS (Could be included in linear velocity, but may want to keep separate)
What we send back to engine
Mass Information (at each time step)
================
Mass of the object
Moment of Inertia in all axes
Center of Gravity in BCS
Forces/Moments (function for each)
==============
Local Force (X,Y,Z) in BCS at location (X,Y,Z) in BCS
Global Force (X,Y,Z) in WCS at location (X,Y,Z) in WCS
Local Moment (X,Y,Z) in BCS
Global Moment (X,Y,Z) in BCS
and/or a bool function to continuously pass forces (instead of the developer summing them) during the time step until returning false
There are other calculations that you could do to make the developer's life easier, but they are specific to aircraft and I think you want to keep the interface as generic as possible.
If someone implements a flight sim on outerra, I suppose they could take these essential inputs and calculate other things that someone might need.
-
Seems reasonable, most of that (apart from the weather) is already available though not exposed.
Moment/torque is technically done as a tangential force.
-
I look forward to seeing what you guys together gonna produce ;)
-
Did anyone successfully use Outerra as an IGC for their respective projects? It's been a long time since the topic has been discussed around here. I am thinking about giving it a try myself now that I have written my own standalone flight and space vehicle simulator (https://simdeveloper.wordpress.com/projects/#FlightSpaceSimulator). I have integrated the simulator into the Unigine engine and have attempted overhauling other game engines for that purpose, but all options required much more time, effort, and knowledge in 3D graphics programming, planetary rendering, or world creation than I am willing to commit.
Edit: Just noticed this thread Integrating with another sim (http://forum.outerra.com/index.php?topic=2705.0). Perhaps I should read that first.