Print

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

[Black Phoenix]

I am working on an aerospace simulator (a simulator which uses aircraft geometry to compute its flight dynamics in atmosphere and in space and simulates its internal systems). It is a non-commercial project, open-sourced (under custom license).

Right now this project is using X-Plane flight simulator as an "engine", but my friends have suggested me I contact Outerra team. I've sent an e-mail, but ZeosPantera suggests I should contact via forums as well.

It's not a "space simulator" (I don't plan much detailed physics beyond Moon, but certainly possible to add "deep-space" simulation. Just later), and it covers flight simulation (right now that's done by X-Plane). It's focused on what happens between 0 km and 500,000 km.

I want to move this simulator onto a standalone engine, because X-Plane limits greatly in doing certain things. I will just give some information on what's done so far, and what is planned.

If Outerra team is interested, I can post extra technical details and some of my technical questions, but if this project doesn't look attractive - I'll understand (it's non-commercial after all).

Features done so far:

• Has own physics engine (overrides X-Plane at high altitudes), computes precise trajectories of objects moving around the planet. Does all the 6-DOF stuff, supports multiple stages, supports variable center of mass, computes dynamics based on shape (does not yet calculate wing physics - X-Plane does this fine so far. If there is a need for wing physics, I will add it).
• Accounts for Earth shape, perturbations from gravity anomalies and other bodies (Moon, Sun)
• Models exosphere (air drag simulation, which accounts for current spacecraft attitude and geometry)
• Hypersonic fuselage drag (X-Plane calculates wings, but does not compute fuselage drag - this is extended by X-Space)
• Heating simulation. It computes heat due to high-speed flight in realtime, based on spacecraft geometry, using a very simplified model (which only accounts for "first order" iteraction). It also simulates heat conduction across the thermal protection system, spacecraft hull
  
• Knows about material parameters - for heat simulation it requests to use real materials and simulates their properties
• Adds some extra visual effects (not present in X-Plane - glow from thermal radiation, plasma layer around re-entering spacecraft, engine exhaust)
• Models Earth magnetic field

Some planned features:

• Networking (still work in progress, by April I need to have simulation which allows storing and integrating objects server-side)
• Very detailed internal systems simulation - integration with other project I'm working on, a highly-parallel internal systems simulator
• Own parametric vessel editor - right now uses X-Plane's plane maker, very tricky to get own plane format into X-Plane.

Some pictures (I'm not aware of rules about posting pictures, I'll replace them with links if they are too big):






I'm programming this project, I use OpenGL and C, GLSL shaders, but have no problem using any other languages. I've used CG shaders before (I heard somewhere that's what Outerra uses).

There are more pictures and some technical info here: http://brain.wireos.com/?tag=xspace

[Lieste]

Hmm, something looks odd about your alpha calculation... visually it looks to be around 45 degrees AOA from the direction of the incandescent plume, while the text indicates an 'engine' Alpha setting of ~135 degrees (ie partially backwards (~45 degrees tail first...)).

[Black Phoenix]

I'm overriding X-Plane physics engine. X-Plane thinks that velocity is zero, and shows nearly-random values for all of its internal variables (I have my own set of variables which are used by my instrumentation).

This is one of reasons I would want a standalone engine, to avoid this strangeness. I cannot simply tell X-Plane that my velocity is what it is - there's a problem with rendering in X-Plane, which relates to moving own vessel...

Only included that information so FPS is visible (20-25 FPS on my slow laptop - which is just few FPS less than what I get with all extra visuals off)

[Lieste]

Fair enough... maybe customise/suppress the display of null variables. ISTR that you can select items to display.

[Black Phoenix]

Fair enough... maybe customise/suppress the display of null variables. ISTR that you can select items to display.

I keep those variables on screen cause they DO show valid values... sometimes. They only work if vessel is located under 120,000 meters, and if there was no staging (detachment of something from this vessel) within last minute... This description fits initial ascent.

I would love to override those variables in X-Plane itself, but there are yet more issues in X-Plane engine which prevent me from doing so.

[cameni]

This is one of the types of projects that we envision using OT engine. Our plan is initially to open our game for modding, not only by being able to add new models and scripts, but also new simulation cores handling the models, and separate game modes, that will essentially get player into an entirely different game.

This one should fit into the "world simulator" mode, where you'd have different simulator modules loaded dynamically upon using the associated vehicle or model object.
So yes, we are interested to have this as one of the sim modules, for example.

(I meant to reply to your email, but I wondered if you didn't hit the send button early, it ended somehow abruptly )

[Black Phoenix]

I meant to reply to your email, but I wondered if you didn't hit the send button early, it ended somehow abruptly

Ah, sorry, that's just probably the way I talk and compose messages sometimes. I usually stick the stuff that matters in first part of the message, and add all the extra less interesting stuff in the end.

It is good that you plan to make it mod-able. Is there any documentation or at least general idea of the interface that I could use? For this simulation I would need to control the vessels (load/unload them, update their positions, somehow animate them if they use custom 3D animations), and also add additional visual effects (like the one I already did), give the engine custom vessel geometry (from a custom file format). Also some things (parachutes etc) I would like to draw myself (a simple callback from inside rendering routine will suffice).

Apart from that there's not much more technical stuff that would be required... What kind of coordinate system do you use/what kind of coordinate systems is rendering using? How precisely can I position objects (from rendering point of view) moving at a high velocity (8 km/sec)?

My current development plan is this:

• Work on X-Space (the version for X-Plane and the networking server)
• Do initial work on internal systems simulation (so computer systems run on this engine, instead of... some custom hack I did for X-Plane)
• Meet up with my friend and construct a new architecture of the whole simulator

The third part will only happen no earlier than summer - although by then I will be working on the X-Plane version of the simulator, and most of the code from it will go into the new architecture, just restructured.

[cameni]

A general idea for the interfaces is something that ought to come up from our discussion, identifying the needs and generalizing them. The APIs will start to appear as we progress with the game, likely in the summer.

For objects we are using the ECEF coordinate system with fp64 coordinates, there should be no problem with precision.

[Black Phoenix]

A general idea for the interfaces is something that ought to come up from our discussion, identifying the needs and generalizing them. The APIs will start to appear as we progress with the game, likely in the summer.

For objects we are using the ECEF coordinate system with fp64 coordinates, there should be no problem with precision.

I see. I've outlined what part of API I need in previous post. What kinda discussion? You mean discussion between developers, or this discussion?

ECEF sounds nice, I'm using this kind of coordinate system in my simulator already, so conversion will be trivial (if your Z axis goes through north pole, X axis sticks through just under Africa, then it's already fully compatible). I take it as that you either use doubles for all transformations, or somehow solve the problem with transformations so there's issue with objects jerking around relative to each other at high altitudes...

I'll take this chance to ask a much much less important question, but just out of curiosity: is your engine aware of planet shape? If start rotating myself at a fixed radius from Earth center, making a circle in a global coordinate system - will I see how Earth changes its shape under me?

[cameni]

I meant the discussion with the first mod-makers, so yes, both

Let me see .. yes, Z+ goes north, X+ from under Africa, and to get the handedness: Y+ below India.
With regards to floating point precision there are several solutions used, different ones for the terrain and the objects. Objects are first shifted to the camera space, getting rid of big numbers causing the imprecisions, and from that continued as single-precision floats to the GPU. As long as something else doesn't bring in the error (for example, the camera position computation), there should be no problem.

By the changing shape you mean if the engine accounts for the deformation of the planet surface? At the moment we are ignoring the ellipsoid shape and rendering the Earth as a sphere. The difference of 21km (0.3%) would make 4 pixels on 1080 pixel wide screen, hard to spot. However, it can (and will) be fixed so it can be used for more precise operation.

[Black Phoenix]

I meant the discussion with the first mod-makers, so yes, both

Perfect. I will try to finish development of the new core by summer then, and will stay in constant contact in meantime.

Let me see .. yes, Z+ goes north, X+ from under Africa, and to get the handedness: Y+ below India.

Even more perfect! That's the exactly system I use:

With regards to floating point precision there are several solutions used, different ones for the terrain and the objects. Objects are first shifted to the camera space, getting rid of big numbers causing the imprecisions, and from that continued as single-precision floats to the GPU. As long as something else doesn't bring in the error (for example, the camera position computation), there should be no problem.

Mmm... can you make sure it's possible to set camera position relative to any point around any object? I will only talk about myself here, but that would simplify my life (no camera handling in my code), and would make sure that I can always put a camera in a fixed location.

By the changing shape you mean if the engine accounts for the deformation of the planet surface? At the moment we are ignoring the ellipsoid shape and rendering the Earth as a sphere. The difference of 21km (0.3%) would make 4 pixels on 1080 pixel wide screen, hard to spot. However, it can (and will) be fixed so it can be used for more precise operation.

That sounds good enough. My physics engine works with true shape of the Earth, and will just place spacecraft where it must be - this problem can be solved later in the future.


Everything looks good. So I can count on being able to base off Outerra engine for visualization later on (the actual question here is: should I submit my ideas on API from my point of view/API ideas that would be comfortable for me based on problems that came up so far from using X-Plane)? What are the limitations on the distribution (will it be possible to pack it up as a distinct simulator, non-commercially distributed, or will it have to stay as a clearly distinct addon to the whole thing)?

[cameni]

Mmm... can you make sure it's possible to set camera position relative to any point around any object? I will only talk about myself here, but that would simplify my life (no camera handling in my code), and would make sure that I can always put a camera in a fixed location.

At the moment it's just how it works when you attach the camera to an object. I'm sure people will eventually need more camera modes for their stuff, but it's in their hands really. When you have fp64 coordinates of the object, you can derive the camera coordinates off of that, in any way that you want. We will need to connect it to the input system then.

Everything looks good. So I can count on being able to base off Outerra engine for visualization later on (the actual question here is: should I submit my ideas on API from my point of view/API ideas that would be comfortable for me based on problems that came up so far from using X-Plane)? What are the limitations on the distribution (will it be possible to pack it up as a distinct simulator, non-commercially distributed, or will it have to stay as a clearly distinct addon to the whole thing)?

I guess we'll set up a wiki for the API ideas, where it can be shaping up.
For now it should be an addon, we'll see later what other possibilities to open. The thing is, it's not just the engine but also the data for it that are served and updated. It's too early to tell now how we are going to fare, but our plan is to support mainly the indie developers this way.

[Black Phoenix]

At the moment it's just how it works when you attach the camera to an object. I'm sure people will eventually need more camera modes for their stuff, but it's in their hands really. When you have fp64 coordinates of the object, you can derive the camera coordinates off of that, in any way that you want. We will need to connect it to the input system then.

I guess we'll set up a wiki for the API ideas, where it can be shaping up.
For now it should be an addon, we'll see later what other possibilities to open. The thing is, it's not just the engine but also the data for it that are served and updated. It's too early to tell now how we are going to fare, but our plan is to support mainly the indie developers this way.

It's nice when you can have many cameras, and get image from multiple cameras (like for example cameras used during docking operations). And then pick which camera is active, also have an optional callback where XYZ and quaternion of camera can be overriden. But...

A wiki would be very nice. I'm eagerly waiting for it.

I suppose the good way to put is: I will make my simulator standalone, GUI-less project, and have support for Outerra as an optional visualizer. This would be the best solution.

By the way, for API to control vessels - must always retain a way for a simulation plugin to completely shut down Outerra physics, and update position in each frame from the external code.

[ZeosPantera]

Wow. I guess you got in contact Phoenix. Very impressive stuff BTW.

[Black Phoenix]

Hi again, I've got some more questions and comments.

What platforms are supported? I've heard it runs OpenGL, so I would expect the engine work under Linux (and possibly Mac OS).

Are rendertargets supported? A very well support of rendertargets would be just dandy - it would be very nice if arbitrary cameras could be specified on the vessels, and the image data read back (as an actual array of pixels). This would help testing image-based guidance stuff much better (my friend has developed an algorithm to determine attitude based on camera image for example - testing that on a computer would be very nice).

The idea about using Outerra to test image processing very well coincides with target photorealism of the renderer.

I presume you're working on your own networking? I'm working on networking for my aerospace simulator, but I believe this kind of networking isn't what you need (it's only for synchronizing locations of fast-moving aircraft). What kind of network library are you using (if any)? Would be nice if Outerra's networking could be integrated with any custom extra networking (worst case though just run them in parallel, or run either one).

(the networking I'm working on has orbital docking as one of its main features)

I'm eager to see what ideas the Outerra team has for modding API, and possibly suggest some own ideas related to it.