Print

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

[planetsim]

Thanks it compiles now. I guess I should drop igc_plugin.dll into the OT root directory(where outerra.exe is). Is there someway to tell that this plugin is loaded and working from within OT ?

[cameni]

No, it has to be put into "plugins" folder in the install dir. You will see a message in the eng.log that it has been loaded. Note that the dll name must end with plugin.dll, e.g planetsim-plugin.dll

[John514]

What does this do, exactly?

[cameni]

It's a way to use OT as an image generator, by controlling the camera position and orientation from an external source via a plugin. People who have their own physics simulator (or are using another simulation program) can have OT rendering the world for them.

[John514]

Hm.....That would be a big hit with FSX users......

[Steve.Wilson]

Remembering that Outerra doesn't have a world populated by cities and roads and other aircraft.  I've had similar thoughts for X-Plane, but the main problem is the visible terrain matching the terrain in the physics simulator.  One or the other must rule, otherwise the aircraft could fly through the terrain at points, or be smashed by "terrain" that is not visible.  Then too, when you're on a runway or on the ground using some sort of bush field, then both simulation engines must be in perfect terrain height agreement.

[planetsim]

I am guessing the field of view of the camera can be adjusted to match that. For example in Orbiter, I need to get the FoV from the sim and set it on the OT camera.

Setting the FoV would affect the view frustum and frustum culling.

[Steve.Wilson]

It's not a view problem, it's a terrain/vehicle interaction problem.  Orbiter would only have this problem should the simulated spacecraft have need to land on a planet. 

I think the problem would likely be solved by having Outerra collision detection just as available to the driving simulation as the Outerra view system.  In X-Plane, terrain collision detection can be turned off by setting the sim/operation/override/override_groundplane dataref to 1.  Then, whatever code that is used to mesh the two simulations would be responsible for collisions/crashes, landing gear interaction, etc.

[John514]

Well, we can always choose the Outerra collision (since it has a better elevation dataset) to be used instead of the said game collision. Af course, the missiong runways/airports would be a problem!

In terms of the current flight simulators, its just not worthy to create such application.

[planetsim]

How about a combined approach. When the plane is close to the ground then we can let OT have control of the plane, let it do its collision checking and set the plane's position and orientation.

When its in the air and no longer colliding(as reported by OT) then XPlane has control over the plane's position and orientation.

That raises the following questions :
1. When the plane collides with the ground then OT's PhysX(or Bullet whichever is used) engine will report a collision and probably a resulting transformation matrix for the plane giving its new position and orientation. If this puts the plane back in the air then the matrix has to be used to transform the plane accurately in the XPlane sim as well as sets its velocity/acceleration. Then XPlane can take control again.

2. If the plane lands back on the ground then OT takes over again. As long as the plane is on the ground, OT has control so the plane is like a ghost object in XPlane controlled by external transforms.

3. Not sure yet how to ensure that a plane thats landed in XPlane is also landed in OT. Probably some sort of heightmap matching is needed there. We can either set up a custom height map in Xplane that matches the one in OT. Or retrieve the terrain height from OT and set it in XPlane at runtime.

[Steve.Wilson]

A seamless transition that accommodated all possible scenarios would be a challenge.

What is a collision system, anyway, but a means of detecting the proximity of certain xyz coordinates on the vehicle to the local terrain, be it meadow, street or runway? 

Outerra has to always own the geometry of the aircraft/spacecraft, and thus, Outerra will be able to report to the driving simulation, be it X-Plane or Orbiter, whether or not a crash collision has occurred, or if a non-crash interaction between landing gear and the terrain has occurred.

A crash condition is easy to resolve with whatever the normal reaction might be to the destruction of the vehicle.

On the other hand, the most complex collision analysis would happen as the vehicle's landing gear transitioned from unloaded to fully loaded.  I think that's where the greatest challenge lays.  X-Plane knows where the landing gear is on a given aircraft relative to the aircraft, but Outerra would know where the landing gear was in relation to the terrain. 

I think that's the key transition to accommodate.  X-Plane would report deflection of the landing gear depending on load, resulting in an ever changing report to Outerra where the landing gear was.  It would be a challenging feedback loop to code.

Ultimately, I think that the smartest solution would be to use the Outerra terrain database to generate an extremely simple terrain mesh in X-Plane, in other words one without land class data, etc., that was identical to the Outerra terrain mesh, and both kept in perfect synchronization to double precision.  That way X-Plane handles all terrain collisions and the interaction code is kept as simple as possible.

How to accomplish the terrain transfer?  A good question.  There are tools available for users to generate their own X-Plane terrain meshes.   I guess the question to ask for this solution is how to prepare the Outerra terrain input to satisfy the X-Plane tools?

[planetsim]

Is the terrain heightmap known to double precision levels by OT before it starts running ? Or can it change during runtime due to 'fractalization' ? If it does change at runtime then can we query it from OT and inject a new heightmap patch into the XPlane sim - at runtime ?

I think the actual heights at any region are only known at runtime by OT and varies much more than the base heightmap which serves only as a low resolution 'guide' for the lay of the terrain.

So some kind of runtime injection of heightmap has to be done into any sim that OT is used with.

[cameni]

That's a bit oddly phrased question, but I know what you mean.
Heights are deterministic, they cannot change during run time. Once a discrete position gets its height computed, it's set. However, there's a catch - finer mesh representations bring extra detail in between the height samples. It matters when you ask about the height of the terrain at some point in between the known samples - with coarser mesh levels you get an interpolated answer, since they simply do not know anything about stuff in between the discrete samples. Finer meshes will give you finer results.

Still, deterministic doesn't mean that the heightmap is "known" before running OT. Purely theoretically, one could compute the exact refined sample height just using the basic (~75m) OT dataset + road/vector modification. In practice it would be insanely inefficient to do it per request.

JSBSim integration works by providing height callbacks for gear and wingtips. They then compute suspension forces that are applied to the physics body, and integrated with the rest of the computed/simulated forces. Any simulator can be connected that way, as long as it can handle such external callbacks.

The best is if the simulator can work by generating forces that are integrated back in OT, instead of setting the position/orientation directly. That way those externally simulated objects can interact with other objects in the OT world.

[Steve.Wilson]

I'm still digesting the last two posts, but that's an extraordinary bit of data.  My mesh idea clearly wouldn't work since the OT "mesh" is refined dynamically during runtime.  The JSBSim landing gear positional data would clearly match up with the positional datarefs in X-Plane, using that example.  So it seems to me, on the surface, that perhaps the synchronization would be more between JSBSim and X-Plane, rather than between OT and X-Plane.

[planetsim]

Integration of the forces may work. But then we would not be actually using the XPlane or Orbiter engine. Those engines' jobs are to calculate the resulting displacement from the applied forces too. So lets say I do supply the forces to OT after taking them Orbiter, then OT may calculate a displacement of 5m on the runway for a plane, while the Orbiter sim may calculate 2m.

At that point a resync of the OT internal sim and the Orbiter external sim would be needed.