Jump to content

PhilTaylor

Frozen-Inactivity
  • Content Count

    1,158
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

45 Neutral

About PhilTaylor

  • Rank
    Member - 1,000+
  • Birthday March 27

Profile Information

  • Gender
    Male
  • Location
    Renton, WA
  • Interests
    computers, science fiction, movies, wine, anything my son Matthew wants to do.

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    Other
  • Virtual Airlines
    No

About Me

  • About Me
    ex Lead PM for the Core Team in Aces Studio
    architect of the multi-thread patch and the DX10 patch

Recent Profile Visitors

4,326 profile views
  1. BAO and Bruce Artwick https://en.wikipedia.org/wiki/Bruce_Artwick
  2. for any product with extensibility and an SDK; during the Alpha/Beta/RC/Ship cycle the extensibility team needs to select a subset of the developer community due to the size of the community and the size the subset of the dev team that handles the incoming. just to size this, back of the envelope, as an example: if the SDK team is 20 people ( 10% of the 200 ) then 2-4 of those are likely to be the customer facing and dealing with the external incoming as well as the internal "day job". how many ISVs can 2 people handle? 50? that seems like a lot but do-able. more than that, not likely. the art and science of this is picking a representative subset of the dev community that will exercise all of the scope of the extensibility/SDK functionality to find issues. so expecting "all developers" to be contacted is just a tad unreasonable.
  3. see https://blogs.msdn.microsoft.com/ptaylor/2007/10/03/acceleration-and-sp2/ and http://www.joyofsetup.com/2007/12/16/flight-simulator-x-service-pack-2-available-and-how-to-work-around-common-problems/ note SP2 requires SP1 to be installed.
  4. That wasn't part of either SP1 or SP2, and I don't see it in the Dovetail SE list here: http://steamcommunity.com/app/314160/discussions/0/496881136926977562/ So no.
  5. Bert, Thanks. We thought it was solid work when we released, it's nice to see it has truly "stood the test of time". And I was honored at the time to have the freedom to make the call on what was "in". Yes, alpha-fade autogen was on our list, props to the LM team for getting it done. Phil
  6. Maybe exactly what SP1 did in terms of threading and peformance needs to be clarified: https://software.intel.com/en-us/articles/microsoft-flight-simulator-x-soars-to-new-heights-with-multi-threading http://blogs.msdn.com/b/ptaylor/archive/2007/05/15/performance-work-in-sp1.aspx And SP2: http://blogs.msdn.com/b/ptaylor/archive/2007/10/02/acceleration-and-sp2.aspx
  7. no worries there, just want to be sure of accurate data. one of the reasons, after all this time, 6+ years, that FSX (and its step-child P3D ) are still "what we have", is there are sooooo many challenges to making a full-world sim. the "sim engine and rendering engine" are almost dwarfed by the business and technical challenges of generating the world-data-set, for instance. the interlocking data agreements alone are serious business. and that's just the mesh; without human footprint ( urbania, suburbania, farmland, etc ), or airports, or planes to fly, or cockpits, or 3 types of traffic, or sky ( atmosphere, sun, moon, stars ), or water, or appearance of land, or add-ons, or .... still, the Steam version breathed some life into the old beast, and it will be exciting to see the VR version of FSX.
  8. uh, not true. unless something was broken after.
  9. Steve, does DTG get your updated tool set for Flight? having that as part of the "head start" might make a difference. and if they open Flight to 3DPs, it might be interesting depending. obviously the jury is still out, but having someone make a try is at least movement over no one making a try. Phil
  10. ok fair enough on camera-centered, but it still isnt a WGS coordinate system, so real-world object placement has to be implemented as a mapping on top of the base UE4 coordinate system. in some key cases, it looks like the range limits of UE4 and its coordinate system do not map to the required ranges. thats a hard problem to solve, since those sorts of range limits tend to be part of the authoring pipeline as well as the rendering pipeline. and nice to talk to you, virtually. :-)
  11. uh no. TS 2014 is "route-based" and not "world-based" like the FSX engine. That means TS 2014 could be "re-engined" to the UE-style engine relatively easily. A full-fledged world simulator like FSX, not so much. . FPS engines just are not a realistic option for a world simulator. The fact that Aerosoft investigated and discarded multiple FPS engines should serve as a proof-point, but I see people still get impressed by rendering technology and don’t think about either the world rendering requirement or the simulation aspect behind an FS-style engine that performs full-world simulation. So let’s get concrete for a second: Rendering limits, range: UE3: UE3 and the UDK had a 10kx10x10k limit to terrain, and I quote: Unreal Engine 3 supports a maximum world size of 512k x 512k (524288 x 524288) Unreal Units. This is equivalent to approximately 10 kilometers squared of area using the default engine unit conversion of 1 UU = 2 cm (10km x 10km). For those who don’t want to read documentation, UU=Unreal Unit. As we move to considering UE4 engine limitations, the use of UUs to describe size limitations will persist. Clearly, UE3 just won’t work for full world rendering without a source code license and a lot of custom streaming code. Hire a good dev. Rendering limits, range: UE4: World Browser does have some “streaming” capability, so it goes beyond the 10kmx10km extent limit of UE3. However, without implementing your tiling system, the default size is still small Forum posts state world size is on the order of half the total magnitude available, eg 5kx5k. Another thing to consider is the default UE tiling system is an infinite plane, so there is no curvature. So you still need source code access ( cheaper now so more possible ) and a dev to write some world streaming code that conforms to loading DEM at multiple resolutions, stitches this transparently at DEM boundaries and across a world geodetic sphere definition with curvature. Hmmm, I think I know an engine that already does that. Oh, wait. This ignores the fact that outside of low-resolution DEM data, the high-res data is a national asset and you need an interlocking set of data agreements to get "seamless" world coverage. Oh, and wait. "Seamless" from a business development perspective means getting all the data. At the best resolution at a price point that maps to studio profitability. Rendering-style "seamless" is different. The wizards in the Geo-team write tools that sweep the raw data, condition it where there are errors ( and if you think the published errors of spikes and holes are hysterical you should see what the data looks like before we condition it ) and export it at a data-density that respects commercially viable storage/download media/rates for most of us. Then the terrain programmer-wizard needs an oct-tree based engine that understands DEM resolution per tile, tile boundaries, level of detail, terrain texture generation, etc to stitch that all together visually in a way that from any altitude above 500 foot, the terrain looks good. Yeah, 500 ft of altitude. Thinking about that relative to UE4, the heightmap format has a severe limitation for our purposes, eg : Heightmap Format These values are divided by 128 internally, and then multiplied by the Landscape's Z scale (default 256). This means that by default, a value of 32769 (i.e. +1) is 2 units (cm) above the Actor location, and the maximum range of heights is -655.36m to +655.34m. 655 meters = ~400 feet. That is the height of the largest terrain feature. Dead Sea to Everest spans -1300 feet below MSL to 29,029 feet above MSL. That’s 30,329 feet of range, so you need the full 16 bits devoted to the range unmapped. And thats ignoring if you actually want to do accurate seafloors. Marianas Trench is how deep? That is not FS altitude, which will take you to 1,000,000 ft above the planet or approx 200 miles. Here is another one to consider: World Coordinates and Terrain Movement: UE4 offers “player-centered” movement where the world moves and the player stays at 0,0,0 That doesn't square with WGS84, GPS, etc. So from this, all should see that simple use of an “engine” like UE, Crytek, etc isn’t enough. Ignoring the issue of rendering range and if an engine could actually deliver a consistent 200milex200milex200mile rendering box, and seamlessly stream it at all altitudes – would it do it using the WGS84 coordinate system so that GPS navigation and other desirable features just work? Not today Zurg. And we haven’t gotten to a feature set like: · Gauge system designed to deliver gauge data at something approximating real world frequencies ( read 1s or sub second accuracy ) · Cockpit rendering, either 2D or 3D. · accurate 10,000 star starfield that enables shooting a sextant out of any plane and doing hand navigation, phases of the moon, tides, time of day, terrain shadows. · real world weather stations, · world airport database including ICAO, bush fields, etc · auto-gen airport provisioning and rendering for 24,000 airports located geographically precise on a WGS84 Earth globe. · ATC, taxi, tower experience, airport experience, etc · AI traffic for auto, 3 types of boats ( military, commercial, small craft ), and 3 types of air traffic ( military, commercial, private ) synced to real world data. · "work" systems like catapults, arresting gear, and hoists. · Wing, engine, and flight dynamics simulation for fixed wing ( prop, turboprob, jet) and rotary wing aircraft ( helicopters ) · 5 season autogeneration of terrain textures using a continental landclass system · water rendering, including ocean, river, lake using a water class system · auto-generation of city-scapes, forests, and other terrain features using real-world density data · Expandability for aircraft, terrain, textures, photo-scenery, etc as well as programmatic add-ons via the SimConnect interface. · And more I cannot remember since its been since October 2008. · Etc. As cool as UE4 is, and it’s pretty damned cool, it isn’t going to cut it for FS11.
  12. I don't know who might buy and what it might mean. But the economics of FS were not bad, just not "Microsoft scale" which is a billion dollar business. FSX sold on the order of 2 million units. Deluxe was $60, Standard was, I think, 40. With discounts, let's take $30 as the average. That's a 60 million dollar business. With a staff of 50, at an average salary of 100k and a billed cost to the corporation of 2x or 200k, that's 10m salary. If it takes you 3 years to build the product, net profit is 30 million over 3 years, or 10 million per year. Many people would see that as a viable economic model, but it is not "Microsoft scale". Then the studio was behind on its own schedule, the division the product was in (XBox) was increasingly moving away from PC gaming ( evidenced by canceling Age of Empires at the same time ), and the terrible economic times of 2008-2010...and a newly minted VP who desired to look VP-ish...all of that contributed. So yes you could have a nice profitable fun business that provided entertainment and enjoyment, and still get chopped off at the knees. It isn't easy operating at these levels of the industry and there are often "strange forces" at work....
  13. I know nothing about this specifically; there have been several "rumors" over the years about a sale before and nothing ever happened. If someone was serious about developing the tech, it would be great. There is still a lot of potential, if the codebase and geo/art assets were shown the right love. Would I go back to work on it? Maybe, if the offer was right.
  14. stranger things have actually happened...I caused an "international incident" by editing 1 airport out of FSX-SP1...true story. some governments are very sensitive and get upset if "a game" or anything doesn't represent the world as they see it.
  15. http://stevesfsxanalysis.wordpress.com/2013/06/21/dx10-scenery-fixer/ this tool looks very promising for FSX in D3D10 mode. D3D10 does offer efficiencies under heavy load so it will be interesting to see if this fixes enough anomalies to make flying at the "heavy load" airports both worthwhile from a lack of bugs and more fun due to a better frame rate.
×
×
  • Create New...