Jump to content

dtmicro

Frozen-Inactivity
  • Content Count

    209
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

1 Neutral

About dtmicro

  • Rank
    Member
  • Birthday 01/01/1980

Profile Information

  • Gender
    Male

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    IVAO
  • Virtual Airlines
    No
  1. I fixed it myself, was just venting mostly. Welcome to FSX --- The game that never works just quite right.
  2. 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...
  3. 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!
  4. 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.
  5. 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).
  6. 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
  7. 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...
  8. 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...
  9. 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.
  10. 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.
  11. 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.
  12. Don't mean to be picky, but we're getting a bit off-topic with all the VR talk.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...