dtmicro

I fixed it myself, was just venting mostly. Welcome to FSX --- The game that never works just quite right.

After rebooting, it worked as in the FSX.cfg settings started working and my joystick started working... However, I am getting blurries now... Go figure...

Hmm, nevermind I guess, after rebooting seems it works. I've never had to reboot like that after an Orbx update, man that update did too much stuff to the FSX files. I think like others, I'll probably have to reinstall FSX now, thanks Orbx!

The settings in my FSX.CFG are no longer being applied after the Orbx migration in FTX Central 2. What the heck did it do? Also, my flight stick is not working.

The problem with all the flight sims out now is the improper structuring of code, and the lack of automation interfaces and auto-script generators. This therefore limits what you can do because it increases the time it takes to build and design stuff. A lot of the Aerial imagery process is a waste of time and should have been fully implemented, also Microsoft should have included at least some low-level shaders (well they have a few in the SDK, but I am talking about in the UI itself). Microsoft hired a bunch of math geniuses that were good coders at math, but few of them were all that great at how to structure their code and the overall app. The FSX SDK is very disorganized when you think about all the different pieces it takes to make something simple. It would have been obvious from day one to me that MS should have created a standard installer with inherited configs, instead of having all these different add-ons share things (that's just a recipe for disaster).

The auto-generation techniques we will be using are sophisticated based on real vegetation data, OSM roads, and even city-level auto-rendering of real skyscrapers. That said, people will be able to add more detail to areas if they choose. We have made great progress for only being at this for one week, but I do not have a lot of help, so having to do most of it myself so far. However, soon I'm going to start training others to help, even for the non-programmers there is stuff they can do. The naysayers would be surprised www.nexgenflightsim.com

Stephen: You sent me a PM reply in your forum, but I never received it (just a repeat of what I sent came back to me), looks like an issue with the PM system or something...

I'm not claiming to be the major driver of this project, I'm just the first guy that stepped up that happens to be able to code with some spare time to contribute, and some resources. If anything, I may be as valuable or more valuable on the business side or as a project consultant than as a programmer. I know I probably sounded a bit arrogant MUCH earlier in the thread (several posts ago), but I was just responding to the flack this project was getting in general as if we are some "kids with a dream". I'm a middle aged man with a mission. I am not so worried about the market conditions for a Next-Gen Flight Sim, because I believe there is a solution to that. I haven't myself yet thought of the solution, but I think we or someone will find away to broaden the audience, and therefore the potential budget and revenue stream. I didn't post the full Unigine list of features, only the bottom part (which is really what sold me), because I think most people probably skipped over that page since it's very long. Unigine has some interesting features for sure. ----------------------------------------------------- Here is what I believe to be true ----------------------------------------------------- My thinking is that there are only two feasible choices at the moment in a realistic budget, either UE4 or Unigine, but the issues I see with UE4 is a potentially longer development path because it appears Unigine is already on the path to making things easier for flight sims, some of the GIS stuff is in their roadmap. Unigine also has a MUCH smaller user base, so it means we will be able to influence their dev team more than the other bigger engines. UE4 does provide the source code for direct modifications, but Unigine provides enough such as the full code for the shaders and the WYSIWYG editor, and that's what I care most about is having that source code. That means we could possibly distribute a modified version of their editor directly to the Add-on Developers (if their licensing would allow), and the SweetFX shader like system is pretty much already built. CryEngine3 seems too tedious for a mid-level budget sim, and look how long Star Citizen has been under development and how many changes they have had to extend to the engine. It's also been touted by nearly every UE4 convert that CE3 was always a bit harder to do things in. Now is Unigine harder than UE4, I believe if you are making a shooter, maybe. If you are making a flight sim, I think Unigine is the simplest because of the direction it is heading...

Well I imagine those modules can be integrated into Unigine with some good coding, and Unigine also has ways of importing the needed things. Outerra is a real accomplishment, but it's in alpha, and it shows. The clouds are basically volumetric blobs, the ground lighting has issues with reflections and too dark under trees. The transitions between high altitude and low altitude are not seamless. The variety of textures is still too early and some textures do not really fit in its overall scheme. Outerra doesn't have an established API with developer samples. It takes 3 seconds or so sometimes for the fractal algorithms to update the textures. The developers themselves may have an accidental conflict of interest with anyone wanting to build a flight sim, since they said they may go to pitch it to kickstarter when ready. It lacks some standardized interfaces and only supports OpenGL with no Direct3D/DirectX support. From what I saw, it has a very basic scripting engine and not a fully developed one conducive of the other engines. Not a single major title has been built yet with Outerra (it's just too much in its early stages). At least with Unigine, there are some semi-major game titles already built, and it's benchmarking applications are nationally known in the rendering world, even though no AAA game titles AFIK. That is just a few problems. That said, Unigine is not perfect either, nothing is, but Unigine has a semi-polished system that just needs to be optimized.

We're not sure where this is going yet, those kind of decisions are premature. If it were to get funding, then it might not even start as an open source project. Most of the code would not be worth it to port it over, there are going to be unique challenges in this engine. It will be a while before we even start thinking about "which physics engine or which flight plugin". Even before it gets to a crowd funding point, we would have to do a bunch of stuff ahead of time. I do not see the OSM data as being the big hurdle, we can always import the data on an approximated coordinate system temporarily until Unigine finishes their GIS coordinate capabilities (which are in their roadmap doc as Q3 this year I think). The big hurdle with this is going to be the graphics work and procedural generation at next-level graphics with multiple world textures (deserts, beaches, etc...), as well as performance optimizations. That said, it's already been proven by Unigine themselves that they have the capability of procedurally rendering (their method is probably partly texture based) a large area for believable sim graphics, that in at least some ways looks better than even SOME 30cm PR scenery, especially close to ground level.

I was VERY impressed with Unigine's feature list: https://unigine.com/products/unigine/features/ Outerra looked good too in most respects, and I agree it's hard to judge Outerra, but Outerra is not really ready as a game engine. I am sure Outerra could be spiced up, and both Outerra and Unigine are probably in the same league graphics-wise in some respects. For a game engine, one of the most important things you need is an active developer community and a lot of documentation, tools, and samples on how to do things. Outerra had some modders adding models and doing some physics stuff, but those are not actual games. Outerra has a ways to go, maybe many years unless they get funded and get more help. Unigine is already a well known engine, even though it is not NEARLY as widely in-use as Unity, CryEngine3, Unreal4. Unigine has split their SDK into 2 versions, one is SPECIFICALLY built for designing flight SIM's. Unigine has already been used to produce Helicopter simulations, and at least a few games. There are people in the CryEngine3 forums complaining that they want more of the lighting and transparency effects that exist in Unigine added to the Cryengine. Even the hard-core CE3 developers in their own forums were talking about how advanced the Unigine engine is and how it has partially surpassed both the CE3 and UE4 engines. Now that wasn't what convinced me, all that stuff is fine and dandy, but what I was really looking at was what would be quickest and the lowest budget way to create a great flight-sim in. Here it was easy, none of those engines were targeting the ability to handle a FULL-WORLD generation as part of their primary or core functionality, but Unigine is. Now Unigine might not have completed everything you need, but they have a clear road map including most of the features we need to finish a flight sim to completion. Unigine has already done much of the work that I was worried we would have to do ourselves. I think they have set a high foundation for graphics work as well, and likely their demos and instructional materials are going to reveal how they created those demos, meaning the techniques can be reproduced and modified to produce more variety.

Don't mean to be picky, but we're getting a bit off-topic with all the VR talk.

I am now convinced Unigine is what you are going to want to use, it was built for this purpose. I thought it would take me longer to be convinced, but many of the other engines had very few of the core features we needed for a Flight Sim, but Unigine does have many of them (not all, but a lot more than the others, but more importantly Unigine has a roadmap to add more). On top of that, it also appears to be highly capable in the graphics department easily matching (and in some ways outmatching even CryEngine3 and UE4), at least with some of the effects and transparency lighting stuff it had. It looks like we might even get access to their vegetation, buildings, and textures as standard with the engine. If this is true, then a lot of the preliminary graphics work is already done and we'd be way ahead of the game. Creating a workable prototype, well it's pretty much already been done by them in the Port Angeles demo, not sure what we add for the prototype, I guess we could use mesh to create a different area. Their graphics designers are second to none, I've never seen mountains look that good in a game. The tree models are some of the best I've seen, if not the best. The houses and buildings look amazing, the ground textures are also incredible. It all looks almost too good to be true for a Flight Sim. It would be interesting how difficult or how long it would take to import a MESH and use the same included textures that came with Port Angeles (assuming they are included) to texture another area (like say Idaho or Oregon, or maybe even Upstate NY)... They have basically already done the graphics so well, that I think I can safely say you can abandon aerial images entirely by following the general methods they are already using for graphics creation.

I took at look at UE4 and Unigine as far as just reading stuff about it online, I like Unigine for the fact that it has a C# Wrapper, but not ever having used either engine, I'm not sure if there are any severe performance implications to using C# in Unigine instead of C++. I suggest srborick send an email to the Unigine eval support team and ask them something like: -------------------------------------------------------------------------------- Do you see any downsides to using your C# API instead of the C++ API that you provide? Since we are doing a flight sim and performance is paramount, do you see any gotchas to where we will need to use C++. Are we going to have to use any unmanaged pointers in C#? -------------------------------------------------------------------------------- There was a C# wrapper under development for the Unreal4 Engine, but it got canned for various reasons because it was a third-party add-on. If we went with UE4, it'd have to be a C++ back-end, the front-end API stuff we build could still be in C# and some of the back-end too since we could wrap some of the key parts of it. I think the downsides of Unigine not having as much public documentation and community support might be slightly counteracted by the fact it supports C#, compared to the huge user base of the UE4 engine (which has thousands of more users than Unigine does). It's a bit hard for me to know exactly how much time native C# support is going to save in labor (hence the development process) when dealing with the game engine, because the way they are implementing C++ in these newer game engines is a little different than in the past, it's not quite as complicated as it used to be. The game engine developers finally realized, hey if we are going to expose everything in C++, that doesn't we mean we still do not need to heavily encapsulate it. This thread is also interesting: https://forums.unrealengine.com/showthread.php?304-Which-is-the-largest-maximum-size-of-land&highlight=landscape+size From what I gather, it is possible to create a flight sim in the UE4 engine, though there will likely be more coordinate correction issues than their would be if using Unigine. That is at least as long as Unigine does what their roadmap says and adds some native support for various GIS coordinate systems. At this point, I'm pretty convinced to give Unigine a shot at least.

I think the issue with 3D (and also VR) is it has always caused eye fatigue to people. If they can make it more natural feeling, then it might gain wider acceptance, but I think the natural feeling is expensive and a long ways off. I don't see it as a fad, but more of a niche.

Yah, if we do end up going the Terragen route, we will need something to do procedural generation to fill in the gaps between the custom designed areas. I have an idea how to do this, but am going to keep this idea private for now. I've actually already done some procedural generation. However, If I give away all my secrets here that I learned over 20+ years of coding, and this project does get going, then you guys will not even need me anymore and I will be out of a job before I can even get a job Honestly, I'd love to build a flight sim over the type of programming I have been doing, it's about bored me to tears lately, I need a change. I did the same basic type of work for the last 15 years (databases, statistics, modeling, basic derivatives w/ pixel geometry, some light server admin duties, web design, etc..). My background is mainly back-end math and query stuff, but I also know front-end ok. That said, I prefer to be more of a project architect or consultant at this point, instead of having to be a math banger.

Yah, the image above is exactly what I meant earlier when I said MOSTLY the east coast is covered in 30cm, as the brown I believe represents 30cm or greater (or at least 60cm or greater), but I think 30cm or greater. You can create snow over a PR image with various tone curve settings by isolating a particular gamma or exposure range and ONLY turning that level to white. I would look up a tutorial from google, as I doubt I can explain it here much more than that. Any paint program like Gimp or Adobe can do it. NOTE: I however used my own front-end FSX compiler extension to do it, basically it uses Image Magick in the background so I could run all the images through at once to generate a new season as I am compiling them. So I just check a box on my FSX compiler helper app I wrote, the box is called "Add Winter Textures"... The software is not available to the public and likely never will be as no plans for releasing it.

I wouldn't ask flight gear as they are more concerned about the SIM than the graphics. At first we are more concerned with the graphics, the sim stuff can always be added. Your only going to get what you are going to get with this stuff, so the most important thing to me is the ability to handle textures quickly in a large open world, and for it to have a decent API. Everything else is secondary and can be added to any decent game engine. I have a good idea what Unity's API was like as I used it some, and I got a good idea what needs to exist for requirements. Game engines have a lot of add-on developers and do different things, effects are often rendered as animations in outside programs than imported with various techniques, some game engines do provide some effects like basic explosions, shooting, etc... Most of the time I find them insufficient and need to be replaced anyhow, so I think you're not going to have it easy there regardless. The flight models I've seen are fairly basic, but there is no way for me to judge the physics in all of the different flight sim plugins. Unity as one example has a ready-to-go flight sim plugin with very basic physics, but I doubt it would be sufficient for anyone to put into production. Edit: Some stuff such as intra-module add-on communication would be exposed with encapsulated hash tables or custom data structures directly to a DLL that any add-on developer can script it with. What scripting would it support, well that's a whole different issue, but you could easily use any interface that can read a real-time .NET DLL (which is almost anything really once you wrap the DLL). There are so many other methods of communication, but this is the least of our worries. This is the simple part.

Getting the roads into a game engine isn't difficult until you have floating point rounding or coordinate conversion issues between the different Coordinate systems, especially with certain game engines the precision of the coords might not be there and might require hand correcting coordinates. Though using a detection algorithm you could make a program that self corrects coordinate rounding issues after the fact with image detection.

You can use vector data for the roads. ------------------------------------------------------------------------------------------------------------------------------------------------------ I already came up with an algorithm to do snow over PR textures, here is snow over a 1.2m NAIP image. Note that this snow is NOT painted on, it is instantly procedurally generated over the texture. The original image had NO SNOW in it at all. Anyhow there are plenty of ways to make snow over a PR texture, only problem is it takes up twice the hard-drive space to create winter/summer textures in PR vs just one season (even worse if you do 3 seasons). And it works in FSX as raster for my seasonal variations of the scenery I was working on, and it looks heck-of-a lot better than FSX seasons or just making everything pure white for snow. Unfortunately is again that dreaded 1.2m quality from NAIP we always get It's not perfect since it's low res aerial, but it's not too bad, and would only get better using higher res (terragen or otherwise).

I like it as well, but I have some fears when dealing with outerra like real-time procedural vs. Terragen pre-rendered. The reason being is also due to performance issues on the CPU and GPU with RT procedural, and blending artifacts between different resolution zones (don't really want to call it a LOD zone since I'm not super familiar with the mathematics outerra is using). Since it's fractal, I would of course assume fractal RT math that generates the close-up textures separately on the fly. I think outerra might need more work on their pre-render caching it looks like, but I don't know because RT procedural rendering could just be real heavy on the GPU/CPU.

That's what I'm about to find out, but it should be possible... I used to talk to the couple of guys that originally wrote Terragen somewhere in some render forum (maybe their forums) years and years ago. I once had a great success for a snow texture I made in Terragen where I fooled my own friends that it was an actual PHOTO picture of Antarctica and not a rendered image (and that was 12+ years ago I think, lost track of time). One of my own family members would not believe me it was rendered and kept saying I got that picture from somewhere else, no way I could have made that! Yah should be possible, but might need some custom software to blend the edges into the aerial image.

The experimental prototype textures in Terragen of course to see if we can match or beat the quality of 30cm aerial images, I will render some to compare them to 30cm aerials (which I have already remastered). Then all we need to do is decide on a game engine, the prototype is not going to take all that long if we go forward with it. Edit: I don't even need the game engine to be decided to do the prototype, I can do the prototype textures in Terragen and run them in FSX by converting them to 30cm raster overlayed onto a default GIS mesh. I will have to figure out how to get the mesh into Terragen, but I think at this day and age an add-on should let me just download the mesh into Terragen from the GIS data, or I'll find out what format the mesh needs to be in to do it. I will do it by rendering the mountains East of SLC in Terragen, since I already have a bunch of remastered aerial images from that area that we can compare to. I haven't used Terragen in a very long time, and I have regular work to attend to, but I will do my best. These would be pre-RC prototype textures just for team members to view at first most likely.

Whatever the rendering software needs, I can set it up that way. Most of the rendering software has ways to break it up into jobs, or I can script it myself. I did build a way for the FSX compiler to work across multiple PC's so that you can split tiles across say 50+ PC's. Some of these rendering apps require more expensive licenses for multi-PC rendering, so that's another thing we gotta watch out about at first, but I might be able to find a legal but still workable way around that by job scripting the mesh + texture mapping settings. Yah, exported mesh which is small after compressed, and then the texture settings can be sent to me in a file with most render apps.

I was hoping some other developers would comment on what I've said thus far. I don't want to rule the conversation. I can provide at least 12 to 20 cores of rendering from a home office, and at least 12 cores from the data center (that's 32+ cores for a start). I actually have about 100 cores at the data center, but some are in use, and some are such older servers I'm not sure it would do much good, though 1-2 additional could be upgraded cheaply. But at some point if I'm providing all this, I'm going to expect others that want to be involved to also pitch in something (at least others that want in early to help with the prototype). This is only until we get funding of course, then we can figure the rest out later. What it boils down to is I have NO PASSION for my current job, and all the passion in the world to build a new sim.