SIM-Posium - The Next Generation Flight Simulator

[Even Rognlien]

Dette ser spennende ut! Baserer seg på Outerra-motoren ser det ut som.

 

http://nexgenflightsim.com/

[Brynjar Mauseth]

Spennende!

[Roar Midttun]

Ser spennende ut det der:)

[Kristian Kristiansen]

Gøy å se at P3D, FSX og X-plane endelig får litt "frisk" konkurranse. Håper bare dette faktisk blir gjennomført. Dog er jeg spent på om dette faktisk blir i nærheten så bra som de prøver å få det, eller om det blir en enorm flop (merk: ms flight).

 

 

[Gunnar Fidjeland]

Dette er i første omgang et symposium (konferanse) der hensikten er å samle flest mulig bidragsytere til en idédugnad.

Så nå er det bare å hive seg på. Alle kan delta. 

 

En kunnskapsrik person har allered skissert sin ide, og skriver bl.a.:

 

The Next Generation Flight Simulator

 

 

As an FSX developer, and someone that has experience doing estimates, I can say that the budget for a basic flight sim that would be NEXT GEN, needs to be around 5 - 10 million, and that is if the game were 95% developed in C# with only a few C++ interfaces for optimizations added, and then you can leave the rest of the coding to the add-on developers.

 

Have 2 family members in the gaming industry, software dev for more years than I'd like to admit, etc.. etc...

 

A flight sim is just a "box" (plane) moving over a mesh that has rendered textures on it, that is all it is. The game engine does all that for you, you sure are not going to write that (what a waste of time that would be).

 

There is an unbelievable amount of talent in FSX add-on development, but that said a lot of it is not the same type of talent you need to build the initial architecture around an engine (Some of the talent fits for this, and some of the talent fits later).

 

The way I see a Next Gen Flight Sim engine is that it has to have these capabilities:

 

1) A C# code base interfacing with a modern game engine and a performance friendly developer database on the back-end.

 

2) The ability to use multiple types of land texture creation. One being, repeating textures derived from PR that are modded by procedural like algorithms, you basically have a template of PR textures that are modded in real-time by blend equations rather than trying to generate the world with only procedural equations. This forms the basis of your global textures. You would likely need to create around 25,000 tiles of the highest RES 30cm or better sampled PR from various places around the world. You don't need to create all these tiles at first, you start with just one state in the US. 30cm is almost good enough even for a car to drive over at close distances, not by default, but with a little trickery.

 

At sub-500 feet elevations, you apply a filter to the ground texture that smooths out the details, and then the overlay vegetation and grass does the rest. Overlay'd vegetation (excluding trees) will essentially disappear with a blur or blend mask as you get above a certain altitude as to use NO texture memory for 3D grass at a certain elevation. The color of the 3D vegetation will actually inherit itself from the aerial imagery with a shader mod.

 

Add-on developers however can do whatever they want, PR-scenery, Land Class, or (if the game engine supports it) real-time procedurally generated.

 

3) The ability for add-on developers to overlay a fully rendered sub-area (city / national park / airports) that overlays on top of the procedural and landclass to provide more variety.

 

4) A graphical creation UI that simplifies the way for add-on developers to interface their add-on products

 

5) World Placement Tools built directly into the simulator that allow real-time object placement, that are almost as easy to use as a Minecraft like interface. (thinking wireframe mesh mode with alignment markers and 3D positional movement). Also includes brush modes to quickly drop trees and stuff directly, as well as some shader stuff.

 

6) Fully locked down (unmoddable, non-overwriteable) core file system. This is done by an add-on installer that is built into the game, and every developer must conform to the same add-on installer. This installer would use logging and registration system so that anytime an add-on modifies something, it would register the modification and use the new instance of it, while leaving the old instance untouched. Thereby not allowing a developer to overwrite the core default files installed with the sim. Reverting the sim to its original state, is as simple as a checkbox. Every add-on has its own private duplicated / inherited config file, it cannot change your configs.

 

7) ENB and SweetFX like shader mods built directly into the game, to allow people to optimize their viewing colors without having to change their core calibration or profiles of their monitors.

 

I believe getting those things created first is the key, the clouds and weather engines, plane models, physics, AI, can all be created separately mostly by add-on developers or by purchasing other products already built.

 

The thing about procedural generation is that you don't necessarily need to do it with complex math algorithms, you can use the procedural class assignment method and blend mask algorithms built into a game engine. This last thing can be thought of much like CSS, and is in some ways FSX already does this (such as with autogen). The problem is the FSX Autogen stuff is tedious at best because one developer's file overwrites the default autogen, though some are finally making it easier with tools to keep the autogen separated.

 

http://forum.avsim.net/topic/469292-the-new-faster-leaner-next-generation-flight-simulator-sim-posium-is-now-available-for-your-input/