[Current Status]

But, you can, in the code, define 2 versions for each system, and only adjust the version you want to compile (x32 or x64).

Yes that is usually no problem with your own code, problems may arise with some 3rd party libraries used (but that likely won't be an issue here).

What can be more problematic is when you actually design the program to use the extended address space in 64 bit mode (or above 3GB that is available in 32 bit mode), then running it in 32 bit mode will fail in run time. This can happen easily - not having to deal with constrained address space is attractive, and can be hard to fix later.

Basically, if you want to support 32 bit version as well, you have to design it as a 32 bit program (with regard to the address space); compiling it in 64 bit isn't usually such a problem in itself. You lose one nice property of using the 64 bit mode, but you still may gain a slightly better performance.

[A new simulator (September/ October issue)]

Ah but the whole point of ID Tech 5 engine is to let developers use a single virtual texture per level, with engine automatically streaming textures into memory as needed. This simplifies the creation of content. Once again - single virtual texture. Combining it with different technologies and breaking the whole simplicity point and introducing the very constraints back ..

Never mind, this leads nowhere

[A new simulator (September/ October issue)]

The world will be built up by algorithms that draws the correct textures based on landclass data and custom visual algorithms that draws the correct rock texture based on elevationdata (how steep is the curve?), areal preferences (diffrent rock textures in diffrent areas of the world) and erosion based on the curves in the landscapes, for instance.

Yep - and that's the point. It wants a different engine.

If you were to build a custom area around an airport. You would simply load up an area (maybe 128 000 x 128 000 pixels) and start drawing, maybe copy paste in ortophotos, adjust them and paint them into the landscape, for a seemless integration, you save the project, and the current area are rebuilt with your custom area modelling integrated.

And it will eat 20 GB for each one. A nice level in FPS. How many of them in a flight simulator?

The bulings and lights are done in a diffrent program, saved in a standard scenery format. The objects are loaded into the "game"-editor and the lightmaps are generated with radiousity for all seasons and lighting conditions (day, dawn, dusk and night). Save, and update the database, beta test, publish!

Again, you are combining stuff that is done this way in other engines. What was the point of using the Id Tech 5 engine?

[A new simulator (September/ October issue)]

First, I'm not sure we know how the texture data are organized in runtime, as I find it hard to belive that the virtual texture fills up 20 GB of texture memory, but anyways why would the methods used in IDtech5 be unusable for a flight sim?

The demo you refer to takes 20 GB of (heavily) compressed textures. Virtual texturing is basically advanced paging system that handles level of detail and occlusion very efficiently. And it must be efficient because of the sheer amounts of data involved. What it does very well (and it has been pinpointed in the presentation several times) is that it frees the artists to do whatever they want to do, to avoid instancing and mapping the same textures from a limited set etc.

I should not have said that the approach is unusable - it could be usable, if you accept its limitations.

For example, from Understanding Virtual Texture:

For instance, a typical database design for a high to medium altitude range flight simulator covers an eight by eight geo-cell area, which translates into a typical geographical coverage of 900 by 700 kilometers. A typical requirement for geo-specific satellite imagery resolution is approximately 0.8 meters per texel, which translates to the corresponding texture dimensions on the order of 1125000 x 875000 texels.

That's quite a lot of data. Additionally, what advantages the virtual texturing brings you over standard multilevel texture tiling? A better compression, but you also have to process the data because of it. Occlusion optimizations don't account for so much in this scenario.

I don't think it solves the real problems here. You will still end up with visually unattractive ground detail. Rest of the world looks ugly in comparison to few selected and modeled areas. Also, with this approach every modeled area will add another heavy chunk of data - you wouldn't constraint the artists again by a requirement to reuse parts of the world to save the space, would you? What for is the engine then?

Virtual texturing or an advanced tiling system - the problems are still there. Some argue that using Google imagery is the future. Citing from x-plane thread aptly named Tired of lack of ground scenery in X-Plane:

Practically speaking, it will never happen [Gmaps in all flight sims]. This is why: orthophotos aren't consistent enough in quality and resolution throughout the world, as depicted by Scooter's screens. The total area covered by orthos are just a tiny percentage of the entire world, and it makes no sense economically covering the entire globe in high res orthos. In addition, each location would need to be photographed for all seasons or weather conditions, but you will still need data on where buildings goes and where to draw forrests, roads etc. Bandwidth will be another limiting factor, even in ten years. And finally, the world is changing all the time and it will be impossible to keep all regions up to date, some orthos are only updated every once in a while, some spanning several years between updates.

The answer is simply to use better data and better textures to create a plausible world with generic objects and textures based on sophisticated algorithms. Take a look at game engine called outerra, it showcases where the gaming industry in general is headed, and it is a much better solution in a longer perspective.

[A new simulator (September/ October issue)]

Hmm, with a resolution of 25 cm per pixel, this would make for an area of 32 000 meters x 32 000 meters in their current incarnation. If you check out the development tools, you would find that the engine use procedural textures made in a custom photoshop-like program, the texture is not a bitmap... Carmack is a geek who loves making elegant technology that push pixels and polygons in the most efficient way. ID has claimed that they are very interested in seeing other games than first person shooters made with their new technology. Carmack would not be a bad partner for Aerosoft, but it would require some kind of personal interest from him and his company.

Those are procedural textures within the editor, that allow painting to the mega texture. In game everything is one big virtual texture, 20GB for that 32km x 32km region.

And I don't think this approach is usable for a flight simulator at all.

But indeed, procedural approach is the way to go. Did you guys see the recent videos from Outerra engine?

[A new simulator (September/ October issue)]

For some reason i belive that ID-tech 5, would be a superb visual engine for a future-gen simulation.

Yeah, with its maximum size of virtual texture 128000x128000 taking a few giga it would make a nice, seamless .. flying insect simulator, albeit with quite limited range and detail ...