cameni

You know, for the time we exist we have been approached by several flight sim (scenery, aircraft) developers that were planning to make their own flight simulator. From that bunch there were/are probably 3 with somewhat realistic idea of the development costs involved and also not just a bunch of idealists without anything bigger behind them, that were also seriously considering the development and not just pinging us at the very beginning of their vague planning. One went bankrupt shortly after trying and failing to secure the funds from a third party, with nothing to contribute on their own but their brand name, but hoping to get us to give our tech into the project for a minor share. The second one went on and off with it for some time, and they still may return again. We never got anywhere deeper into technical discussions, it was quite weird actually - like the design doc in the form of a wish list, and while they asserted to had enough funds for the development on their own, we later learned they sought to share the development costs with the developer. Was it because of the risks they saw, or their estimates had to inflate after the research? I don't know. Nevertheless they backed off, stating some reasons ... The third is an acknowledged developer that probably knows well what the requirements and costs are, and there may still come something out of it, but it's all so cautious that it drags on for years and they have no sufficient large SW dev experience and seemingly nobody able to analyze what it would mean to use OT and change some paradigms they are used to. It's all painful to watch. IMHO the biggest problem are the money. Aviation fans tell us - you have such a big potential, why don't you make a simulator? When we do any research, the result basically is that if it has all the features and everything then they will buy it, but best if it also imported all the mods they already had. So basically lets invest a few millions and then have a few more for an add campaign, in a niche environment where there already are some established competitors, undead or alive. No wonder that the developers already operating in this market are getting nowhere all the time. Sure, there's some support involved, but we are still mostly working on world rendering and simulation, and on global imports and world building tech. I can say we aren't working on anything military specific. The reason it takes all so long is that a) we are a small company, and b) the ability to render world with such a high detail range comes at a cost. That's basically all there is. Without licensees that can use the engine even at this state we would not be able to continue developing it, unless there was an investor willing to finance it for some specific product(s).

Hi Minos, Yes Outerra is alive. We are working only on general engine features, nothing that's specific only to military applications. However, our resources are still limited compared to the amount realistically needed for the development of such a universal engine, so it's not as fast as we (or anyone) would like. Of course, the necessary support of our licensees takes its toll as well. Additionally we also decided to invest almost all the remaining time into the development of a game product that would be appealing to a wider gamer base, in order to be able to grow faster and then eventually cover also the niche areas. But all this contributes to a relative silence in the past few months ...

I can't really imagine how this would work, nor that it's a good idea for users to control the development process. First, how would a loosely defined community pick their representative/qualified members? And if they would join our team, will they become de facto employees subject to company control? Do you mean some community formed governing body arising from the NGFS SIM-Posium project? Basically acting as a virtual developer licensing the engine for their project? To be honest, I still cannot comprehend how's that supposed to work. Unclear structure, roles and responsibilities. If you launched your own crowd-funding project with the goal of gathering funds necessary for the development of a flight simulator, who would be managing and allocating the funds, controlling the development process? I can't speak about our exact license terms with Titan and what access level they have got, but we are quite strict about what features go into the engine core and how they are implemented, because we have a clear vision of engine architecture and won't allow it to break into gazillion chaotic patches. Until the engine becomes stable and complete, the only way of any early licensing can work is with our direct cooperation on the project with a qualified developer. There's no engine eval kit at the moment. At the moment the only way to assess the potential is via the tech demo, that is being continually extended and will eventually likely split into a sim platform and a game.

Never happy. Obviously it's not the only thing being worked on. I didn't state there are no actual plans.

The engine can be used for many things, even for King Richard's era simulation. If you mean to ask when somebody (us or a simulator developer) will populate the world with contemporary buildings with appropriate density for a modern era simulator - well, when we or someone will be making the simulator with the required settings. You've already seen that it's possible to manually populate urban areas, it's also possible to autogenerate them. But we aren't making a simulator (for that particular setting) yet, as it clearly requires securing the necessary funding first. All what is shown is just a byproduct of what we are doing for our current licensees and to gradually make the engine more complete. But if we are going for Kickstarter, this will be surely one of things that will be shown in some WIP state (for a selected location), to show that the engine can handle cities. I understand without it it would be quite hard for many people to trust the project. I think it's obvious by now that if any new simulator platform should get a chance to survive and thrive, it must be an open one, creating a healthy ecosystem with third party developers who will trust the platform and be able to extend it considerably via addons. I'm not entirely sure what you mean by "we as a community" though - users who would have supported the development of a next gen simulator via crowd funding, or the developers?

Depending on the definition of "soon". There are many areas being worked on, and the limiting factor is the amount of workforce we have at our disposal. Note that at the moment we do not have any extra team members working solely on a simulator product; the whole next-gen simulator talk circles around the funding necessary for the development of one. Whether it's crowd funding or something more conventional, it all means there would be a dedicated dev team for the simulator, working closely with the engine team. Even though technically the generator is separate, in practice it cannot be easily taken out and plugged into a different 3D engine. You see, the whole rest of the engine is optimized for a specialized world renderer: resource management, physics, low level GPU access, coordinate system, practically everything. General engines must approach it in generic way, to allow creation of a wide range of games running on a wide range of hardware. This adds too much overhead to attempt to make a full world rendering engine on them. Initially we focused on the base procedural world, driven by real world datasets, but its main purpose is to generate the world as it may have been looking like without civilization. What mgh showed for London is the base layer, far from finished at that, but it's just the natural layer. Procedural generator is rendering the biotopes according to local climate data, available elevation, natural color and vegetation data etc. On top of it goes the civilization layer that contains the effects of civilization. For example, here's the road network in London as imported from the OSM (I believe this is the first time we are showing some preliminary results from it): Note this is WIP, terrain was not leveled and roads do not connect seamlessly yet, road coloring is is there just to show OSM road types etc. But these tests show us the feasibility of the vector overlay system: we imported the whole world, creating 29,583,113 km of roads and the whole system works really well. Buildings can be placed manually or imported from vector sources or procedurally generated to achieve geo-typical look. All of it is in development. There's still tons of work needed for a full combined simulator that we want to make, but we won't attempt to launch a crowd-funding campaign without having all the necessary components in some beta form there. Above shows what third party developers can provide: scenery editing is mostly about vector data layers that mod the underlying procedural world scenery, defining roads, but also fields, parks etc. Vector form means it can be refined procedurally down to the ground level, looking good also for vehicle and trains simulators, unlike raster imagery. So for the scenery there's plenty of addons that third party developers may provide. This also applies to all kinds of addons - simulator cores, weather control etc. A closed simulator platform would make no sense.

Not that big as you may think, or not that big for an engine provider at the end of the chain. But it's something that provides the necessary funding so we can continue working on the engine, and it's in this regard that (or so I interpreted it) that we are not dependent on one particular market, and not under pressure to rush something (which may be both good or bad). I would not say that we are aiming for a different market. Our primary interest is in simulators and planetary-scale games, and a global combined world simulator is something we always envisaged as one of the most important products. Military training is just something that shares a lot of requirements with general purpose simulators, and which was able to use the engine even in its alpha state.

I do not see any pages there, might not be available from here. But if a texture is "taking up too much memory" for what is actually needed for rendering, it means it either doesn't have mipmaps at all, which is often the case in FSX. But it also means the LOD system was not designed for that scale, because even though smaller mipmap levels take much smaller amount of memory, they also cover a much smaller screen space, and you will be issuing too many draw calls to cover the visible world if the engine won't switch to a coarser level geometry as well. I still can't see what's "too large" on the mipmaps though, I'd understand if you said they were too small wrt screen space. Or you mean the textures (not mipmaps) are too large in memory for given detail level?

No, I never heard the term "mipmap too large" to mean there's not enough coarse terrain texture detail levels - if that's what you mean. As for the rest, you aren't arguing with me, please do not reinterpret what others say. Procedural is used to fill up the world with detail that would be impossible to produce manually at that scale. But procedural is also the application of vector data in engines that can support vector overlays. Designers then can combine raster and vector data for custom modeling of selected areas.

I'm assuming you are not a game/engine programmer, just a long time user of non-realtime rendering software, right? Not meaning to be derogatory at all, just wondering, based on the choice of words. Actually, I find the usage of terms very weird. What does it even mean that texture mip-maps are too large? Auto-gaussian ... refers to GTA engine basically hitting limits of their supported level of detail range. And so on ... you are even assuming that Terragen renders = engine renders of Terragen data. Yes I'm assuming that people will still care where to put exabytes (million TB) of data on their next gen 10TB disks. This problematics of large scale high fidelity world rendering goes so much deeper than just wishfully combining pieces of software that one likes, as if it could somehow auto-scale beyond the normal annual hardware performance boost. I fear I made a mistake trying to explain and collapse that circle :huh:

Terragen is an offline procedural renderer. It's a great procedural renderer, but it's unusable for real-time rendering, as it was build with different objectives. The only way you can use it for games is to pre-render all textures and meshes and store them somewhere for the engine to access. Also, it means the engine now has to be optimized for streaming, and even though people easily dismiss FSX engine as outdated, it was heavily optimized for streaming too, and not using the GPU so much because of the same architecture type. Outerra is a real-time procedural renderer, moving the load to the GPU. Obviously it cannot reach the same quality as Terragen in 1/30 sec on today's hardware, it has to do a lot of compromises. It's also alpha, and the variety it can generate is currently limited because of that as well. But to put in into a perspective: just the land textures generated by Outerra in run-time (2x2cm² medium res) would take 1.3 exabyte (1.3x1018) of storage on the disk for the whole planet Earth. Actually you would not be able to use them because suddenly the throughput from the storage or net to the GPU will become a big issue. Time it will take Terragen to produce the data will be huge as well. And you won't reach anywhere nearly the same quality as movies produced by Terragen frame by frame ... You may disregard the need for such textures in a flight sim if your objective for the next gen sim isn't a world simulator, but you are still keeping all the disadvantages of a streaming engine, you just changed how the imagery and meshes are produced. As a side note: Outerra was inspired by Terragen 1, with the goal of making the procedural generation real-time and usable for games/sims.

Even though there aren't many technical details available, Vulkan looks like the long awaited evolution of OpenGL. Closer to the metal, much better control over the GPU, getting rid of ancient OpenGL clutter. For OT it's a logical upgrade path, that will mainly simplify our lives (once the drivers become available and usable). We don't actually expect a significant performance boost from just switching to the Vulkan alone, but it will make updating some of our existing older and slower code paths easier and cleaner. That said, at the moment I have no idea when that may happen. But ideally we'd kill more rabbits at once - switching to 64 bit builds, getting rid of old GPUs that do not support modern GL4+ features and can't run Vulkan ... that would allow us to throw off some old stuff and simplify the maintenance.

Sorry if it was unclear, the bold keywords should be "exclusive license to Outerra engine to TitanIM for military use". Indeed it means that only TitanIM can license the engine for use by the military users, as long as certain conditions hold, so that they can compete with other parties that are well established in that domain already. If it does change anything for the use of Outerra engine by us or by other parties for non-military uses, it's maybe that we have secured some resources for further development and can continue expanding and developing the core engine, that will be then used in other products. Right now this basically only covers the core engine development, so we'd still need to secure funds for the development of any larger scale simulator or game to be developed on OT, required for its dedicated developer team.

I found a bug there, and a possible cause - if your data directory or the video directory path contains spaces, videomaker won't launch.

No, that's actually OK. It does not do anything if not given the path to the video folder as argument. If there was a missing dependency though, it would display an error. So I guess it's not given the right directory when launched from outerra.exe, Eng.log will probably contain some info about that.