cameni

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.

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.

Hm, maybe videomaker.exe can't run because of a missing dependency. When you go to bin\video folder and try to launch videomaker.exe, does it produce any error?

Are you trying to open the Y4M raw video files, or the converted webm file? Y4M uses a special extension (LZ4 compression of frames) that makes it unreadable by other tools. You can turn that off be editing eng.cfg and setting video = 0, but the resulting raw video files will be slightly bigger. In any case, the webm file should be ok. Maybe the problem is in the player?

Nvidia Shadowplay should work, as it captures frames off the GPU directly. By default Outerra blocks apps that capture video frames, because they do not play nicely with modern OpenGL and with our asynchronous rendering pipeline. If you run outerra.exe with -allowext command line argument, it will allow Fraps and other apps to work, but you may get various artifacts and/or crashes. The built-in recorder compresses the video only lightly in the first capture phase, and so sometimes hard disk drive can't keep up recording the amount of data. A SSD would work, but .. it's a lot of data. We'll probably have to add another intermediate compression step there.

Not sure where those 8 years are coming from, in 2008 we met and started getting the engine together from our old terrain and engine codes. It took a lot of time just to make the first basic version working. Initially we kept the development blog at gamedev.net, under the name "Journal of Lethargic Programmers", as Outerra wasn't conceived yet. It was a hobby project; it wasn't until 2010 when we started fully working on it, and released the first public demo in Feb 2012. Of course, working on a whole new full world 3D engine with 2 people wasn't anywhere fast. We have a couple of special simulation projects (military) using it. Here's one that was publicly revealed: http://forum.outerra.com/index.php?topic=1248.0 Some other (bigger) projects will be revealed by the end of this year.

Well, I'm not worried for OT's own sake, I just smiled when reading that we "made an engine that is looking for a purpose". As you wrote the breadth of possible applications is enormous, even if we judge it only by the number and variety of companies and developers contacting us, and the projects that are already underway. For the simulator we'll have to win the support of content makers to make it a thriving ecosystem, sooner or later. Having some of them proclaiming support for the campaign would be surely beneficial to the outcome, IMHO almost a necessity, even though I'm not so sure what part of the backers of a "universal" simulator will be actually made of purely flight sim fans, where the well-known addon maker names will matter. But that's one of the goals of the pre-campaign prototype: to have all major tools and components of a simulator in some basic form there, showing what will be ultimately possible not only to users but also to developers.

We worked with dept. of Ecology and Evolutionary Biology in Arizona University, and the tree heights for used species come from their data. The problem is that these heights are for trees growing inside forests, where the trees compete for sunlight and grow much higher than the sparse ones that have enough space in urban areas. When you place the deep forest ones close to buildings, they will look exaggerated in size because that's not where you can see them normally. More so because since the models used are mostly of the standalone trees that were just scaled to the requested tree size. It clearly needs different models for trees depending on where they grow, and also to change this subtype around the urban and sparse areas. Here's a video from presentation about how the forests will change according to current climate models, where Outerra is referred and shown: https://www.youtube.com/watch?v=9PuhqAzTcow#t=653

There are lot of skeptics though. That targeted search also led me to an Orbx forum topic, where John Venema commented on it: Here you have a "3D engine enthusiast" who doesn't see any potential in Outerra for flight sims. Also note "give LM a few more years ..." :Raised Eyebrow: Btw it's not true we ever contacted them, they were looking for any possible future replacement for FSX after Microsoft pulled out and contacted us. It was very early into our development, and it really required someone who could see through the bare demo towards the potential.

2006 ... that could have been only some predecessor of Outerra, not yet based on real terrain and not using GPUs. Oldest algorithmic roots of Outerra came from my fractal terrain program in 2001. Small scale terrain, very limited and all, but the principles with which it worked proved to be perfectly scalable and usable on future graphic hardware. This was in 2001: It was developed very sporadically; there was an enhanced version in 2004 with 100km visibility, but only in 2008 I started using real world data and moved to GPUs with it. More info about the past, present and future can be found in new topic: Outerra Roadmap

Hi everyone @AVSIM. I'm one of the Outerra founders and lead developers, and I would like to thank here to AVSIM staff for creating this forum dedicated to Outerra, and also use it to present our plans and to receive valuable feedback from flight sim users. Let me start with a brief history of the engine for people that might be interested in how it came to be and where it's now (and where it is going). Outerra started in 2008 as a hobby project, evolving from an earlier fractal terrain program. This was the first iteration of the to-be Outerra engine in summer 2008: It was a hobby project back then, and probably a very few people would have guessed it's got any future. The first video that hinted at any flight simulator potential was shown in summer 2009, followed by the "Cessna Test Flight" video that first raised interest from the flight sim community. (As a side note, I wonder how is it that the same youtube videos that played smoothly back then presently stutter like mad on my much faster current computer). After working on some basic vector data support and tools we created some test scenery and in summer 2010 released the "Himalayas trip" video: After we left our day jobs and founded Outerra company in 2010 to focus on the development (a two-man firm for a long time), we worked on a few special simulation projects and got a couple of early licensees who were capable of using the engine in its early state, but which also could and needed to utilize its capabilities. The breadth of work radically increased not just because of the required support, but also because what we call "fractal programming": every completed major feature opens four slightly smaller ones, and the work can't ever end, while the apparent progress now takes smaller steps. Later we added things like enhanced terrain texturing and terrain normal maps, 3D grass, dynamic and adjustable time flow, random rocks, realtime terrain deformation - craters, MiG 29, support for Oculus Rift and stereoscopic rendering modes, FreeTrack support, watercrafts and amphibious vehicles, and first level biome support: biome colors and vegetation density Recently we grew our core team and are hiring more people, but of course it takes some time until the results show. We are also working with other companies on OT-based software for special simulation areas, what DetCord meant by singling out non-commercial applications (erroneously though, as a simulator would be a commercial application as well). ✈ ✈ ✈ With regards to flight simulator development, we have been contacted by various flight sim companies ever since the first video with the Cessna test flight. Addon makers were looking for a FSX replacement for a long time, though at that time still not actively trying to develop a simulator by themselves, but looking for rising platforms for which they could continue producing content once FS goes into decline. It was very early for OT, and Orbx must have been quite shocked to see our early plain demo in 2009. For some reason they thought someone larger was behind it and expected a ready made tool chain for scenery editing and all. The problem with flight sim scene is that it is arguably the most demanding game/sim area, with a disproportionally sized user base for that. Investors do not exactly rush to fund development of new simulator platforms, more so after Microsoft pulled out. Development requires expertise in many areas. Many simmers want nothing less than a replica of the real world, or something as close as possible to it. That not only requires a very robust base capable of handling a large amount of data, but also creating tons of content for it. Compare that with typical games that focus primarily on some concrete game play and are usually cheaper to make but able to gain a much wider (though more temporary) user base. Currently we have ongoing discussions with several companies and developers operating in the flight sim business, with the larger ones actually interested in (possibly) making a new simulator. Don't get your hopes high though - this is business, the numbers are tough and addon/hw makers do not have large software systems development experience that's a necessity here. That all contributes to a high risk, and after the initial determination and enthusiasm it mostly breaks down on the money and the breadth of development scope. As we wrote in 2013 Retrospective, 2014 Look Ahead blog post, another option to fund relatively niche products (or products considered niche by conventional investors) is to crowd-fund the simulator development by launching a Kickstarter campaign to develop an open simulator platform based on the Outerra engine. Making the simulator would involve assembling a dedicated development team working on the simulator functionality and closely working together with our core engine team and also with other addon developers to create a rich ecosystem for it. The question is whether the community will be able and willing to support a project like that. I was quite surprised how much positive feedback we were getting through the huge "Interesting future for Outerra" thread, and we are grateful to HiFlyer for his constant promotional effort there. But how would it would work on Kickstarter - that's still very hard to tell. To elevate the chances of success, there are several things that we believe need to be done first: A prototype demonstrating all the potential and important basic capabilities. Generally, for successful campaign we will need a prototype showcasing the potential and addressing the main concerns. The prototype is also needed for other developers that would want to prepare and develop early for the simulator. That means enhanced scenery tools, stuff like basic weather support, plugin support for simulation cores, 3D cockpits and instrument rendering, support for other simulator types (mainly the rails for the prototype) and more. Note that even though these will be fully developed as a part of the simulator work, initial versions have to be created for the prototype to convince a significant part of the target audience. Getting support or endorsement from addon and HW makers early in the process, best ahead of the campaign launch. The prototype already needs to be created with this in mind, as the addon makers are essential for the success of the platform, and also the crowd-funding goals could be hardly achievable without some declaration of support from the developers. Making the simulator platform universal, suitable not only for flight but also other simulator types - vehicles and rails, sea and deep waters as well as the space, to make it appealing to a wider user base. With Outerra it's realistically achievable on a global scale. There's more to it - our goal is actually to make it possible to plug in multiple simulator cores, even for the same type. For example, ground vehicles can be simulated in a simple way as it is currently done in the tech demo, where they are using a simplified physics core with raycast wheels. There could be a more advanced simulation plugin possibly developed by a racing specialist, where tires and transmission are simulated in complex way. Aircraft are currently using JSBSim core, but the simulator is meant to be designed in a way that developers can plug their own core, and have other developers using it instead of the default one for their models. This has also some downsides, as some hardcore flight simmers will fear that a universal simulator will compromise on the flight sim aspect, so this needs to be addressed in the campaign. There's a lot more things that have to be addressed for such a project, but these are probably the most important ones early on. The prototype will probably take most of the time, depending how far we'll have to go with it. We would welcome your opinions in this regard - where to draw the line between what the prototype must have and what's best left for the project itself, balancing the time needed for the former with a reduced workforce vs. the enticing potential of the campaign when less of it is shown in the prototype. Of course, if crowd-funding becomes the chosen way to create an OT-based simulator platform, it will be essentially driven by you, and we would like to hear your opinions on every aspect of it. This newly created forum looks like an ideal start point for the discussion. Thanks everybody in advance for participation!

(Modern) OpenGL actually doesn't need to do much to get on par with Mantle. Here's a tweet from our discussion about Mantle with OpenGL head at AMD: https://twitter.com/grahamsellers/status/383242587609395201 I totally agree with that, and OT profiling only confirms it. Mantle would still be a good thing if it was widely available and supported, as it allows to leverage some extra performance by people who know how to work at that level, but those numbers compare mainly to DirectX and apps that currently lose performance in the driver overhead. OT would barely gain anything, though it could allow us to do some things more efficiently, mainly for better fluidity and better resource management. Here's where we count on OpenGL bringing some extra control in the future, and view Mantle more like a catalyst that can get some things moving. DirectX has always had a much higher API overhead, so it's only good that Mantle can kick them into doing something about it. Though I guess it will be locked to Windows 9 because of all new driver model that for mysterious reason cannot apply to older Windows versions :rolleyes:

The main difference is that FSX, X-Plane and most others use traditional streaming-type rendering engines: optimized to stream prepared terrain meshes, textures and other geometry, that is then almost directly rendered by the GPU, without using many of its computation capabilities. That puts a high load on the CPU and the CPU->GPU bridge which have to select and stream a lot of data, while the GPU mostly waits for the data and its utilization is usually fairly low. It also means that a streaming engine usually only renders what it's got prepared in advance - only so many levels of detail, and if you want to double the resolution, it will quadruple the amount of data. OT, in a simplified view, is a procedural, "generating" engine: its terrain data are prepared in a special format that allows producing any required level of detail on the GPU, and continue refining it below the resolution available in the dataset, using a set of statistical rules. This allows us to get a detailed terrain even from coarse world data. The data are highly compressed and fully unpacked only on the GPU, and thus there's much less traffic going from the CPU to GPU, and the CPU has to do less. The second part is the vector engine that overlays and modifies the base world. Again, the data come in a highly compressed vector form and are effectively expanded and applied only on the GPU, lowering the internal bandwidth and relieving the CPU side. It's currently used for roads & runways and craters, but it's being extended to handle rivers, lakes, fields & pastures, parks and other civilization effects on the natural world. All being in the vector form, it's again procedurally refineable and takes a tiny space compared to the traditional approach. There are, of course, some disadvantages. The increased complexity requires a relatively powerful GPU. Outerra predecessor was actually done way back before programmable graphics appeared, and it was a wild guess that one day there will be a hardware suitable to handle the approach. One of the disadvantages is also that new tools have to be created for scenery editing, to fully take advantage of the architecture. It's possible to combine it with the streaming style though; for example the current buildings are technically streamed and not procedurally generated (yet). In practice, no engine is purely streaming or procedural, e.g the autogen in FS. The advantage is clear: this design is able to fully exploit the programmable graphics hardware, which scales much better than CPUs can. It also leaves the CPU resources for the simulation. Note OpenGL 3.3 is the minimum required version, but we actually create a 4.x context when available and use some functions from higher OpenGL versions, or some extensions when they are available.

A very legitimate point. I have seen them asked about that repeatedly, and unlike their replies to technical questions, the answers always seem a bit vague. Even with a big team, development of a game or a simulator based on a new technology or IP takes many years. Development of a whole new type of engine generally takes longer, not just because writing an engine is a huge task in itself. Before there's an SDK usable by third party developers with all the documentation and with all corners tested, there basically has to be a full game/sim developed by the engine writers, as a working proof of the concept, of which the SDK/docs are the byproduct (or the main product, depending what is the goal). What we are telling to all interested parties that approach us is: it's possible to start developing a sim/game/app using Outerra (OT) right now, and develop it in parallel with the development of the engine given the state, the only way it can work in this stage is with our direct participation on the project, assembling a dedicated team that will work closely with us (the core engine dev team) I can tell you that thus far there were two potentially large (multi-million $ project) inquiries for use of OT for a flight simulator, from companies that already have something to do with the flight simulation, and have a fairly big interest in appearance of an advanced simulator so that their business can thrive. Although neither one is technically closed, in both the problems are/were with two things: the funding, and the (lack of) experience developing complex high performance software. The funding - traditional investors are reluctant to invest into niche areas, or into something from which Microsoft pulled away, and they usually ask for unrealistic guarantees. The other part is equally significant. Companies that are currently "only" producing content for existing simulator platforms are no software houses; not really capable of developing a complex SW like a simulator even if they had a good 3D engine to begin with. That could be clearly visible by the lack of deeper technical questions. Ultimately they would assess the business risks and back off, but still wholeheartedly support anyone who would attempt making such a simulator because it just widens their own opportunities. On the other hand there's a handful of smaller independent developers who would like to see an OT-based simulator and develop for it, and together with crowd funding this looks like a better option to get the thing done to the satisfaction of the community. What we need to do is to prepare a prototype that can be used both to get the support of a wide array of content makers, and then also for the Kickstarter campaign, to ensure it will attract enough interest to be successful. Nothing is set in stone, of course, there are lots of details on how to best approach it, that have to be resolved first.

Both effects (GPU and CPU load) stem from the same thing, and both should appear if the vertical synchronization works correctly. Basically, CPU will block as soon as the GPU queue is full, and the GPU queue gets full after 2-3 frames as the frames are waiting for the vertical sync, and both the CPU and GPU utilization should go down. But this looks as if it didn't really sync, or was doing a busy wait (i.e. not yielding the control to OS but looping and thus not lowering the utilization). It looks like a driver issue, especially if in manifests only on some systems. We will be inspecting it deeper. Oh btw, did you run it in fullscreen mode? The behavior is a bit different in the windowed mode.