Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ZeosPantera]

Bringin' it way back aren't we phoenix.!

[PytonPago]

Nice to see ya Phoenix !

[cameni]

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.

[PytonPago]

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. 

[Steve.Wilson]

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.

[Steve Jones]

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. 

[ZeosPantera]

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.

[cameni]

Steve already wrote to us and I replied, but perhaps he didn't receive the email response?

[Steve Jones]

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. 

[Black Phoenix]

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.

[SilentEagle]

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.

[cameni]

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.

[SilentEagle]

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.

[cameni]

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.

[SilentEagle]

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.