Release the 3D Sphere Earth Map tech ASAP! A modular updatable common sphere map!

[Worrazen]

[As of 5th May 2023 this topic has been updated signficantly (accuracy, clarity, overview), thanks also to some of the early posters for their additional input]

Hello

This is a proposition regarding the recently officially announced "Spherical Earth Map" or in other names and descriptions the community and developers have been using, to name a few:

• Whole World Map
• 3D Sphere Map
• Proper Globe Terrain
• ... and various other combinations

Planet Earth is technically an "oblate spheroid" and the DCS 3D whole world curvature-featuring map technology has to simulate our Earth's geometry for enhanced realism. This opens the possibility for major gameplay and other benefits across the board for the DCS ecosystem. Because this feature most likely affects many other components of the sim, it requires changes to those components as well I would suspect, most definitely physics (gravity), weather (clouds have to wrap around as well), and since coordinate system is something many things depend upon, those things may need adjustments to function correctly. So it is not just a question of map technology, with such a profound change it ofcourse means that existing terrains most likely cannot be simply transferred ontop of this technology, so it wouldn't come as a core update to existing terrains and turn them curved.

Quoted from the official newsletter:

Quote

Spherical Earth Map
2022 saw great progress creating the tools and technologies to support a precise spherical Earth map for DCS. Because this map will be based on current day, it will operate independently of the current and future regional maps that allow historic maps such as World War II, Korea, Vietnam, and other scenarios. Spherical Earth efforts will continue in 2023.

 

Analysis of the newsletter:

The way it is explained in the recent newsletter, is a bit different from what some of us imagined this technology would be implemented and introduced as, and how would it actually stand in comparison with traditional flat terrains.

- From the first sentence it seems that the technology behind the spherical Earth map is more or less complete, but it does not end confirming whether that is necessairly 100%, but non-the-less this is good news.

• If the technology is more or less complete, it should be entirely technically possible to release a test version with a minimal set of visuals and assets, at least for the closed-beta testing programme.

 

- The second statement has many parts to it which I will address individually. First it goes to indicate that the next major task at hand is to actually (fully?) populate this empty sphere earth model with some useful textures, buildings, environment for a worthwhile experience. But wait, it doesn't actually say that, it just says that the sphere map is based on the "current day" scenario/setting, but that's how our the common sense logic would tell us when we put these words together with the previous statement. This "current day" is, as I understand it, indicating that they're populating the map with assets (developing and placing the content/roads/structures/landscape) which happens to be in the current day timeline esthetics and design-wise. I say that if they have the ability and stability of the core technology to start populating it, than the core sphere technology most likely has to be finalized, for them to feel comfortable (worthwhile) doing it.

• To populate the whole world (Earth 1:1 scale) should be a massive task and may take a considerable amount of more time and effort.
• The time aspect might be lesser if there have been many many more developers assigned and hired, with additional external help and/or with new advanced automated map creation tools. Despite this, and considering the last statement of the news letter, a 2023 release doesn't seem likely.
• The most important question: Do DCS players really need the whole Earth map to be fully populated and highly-detailed at it's introduction? Would the players accept gradual expansion of the content of the spherical Earth map.

 

- The next part explains that the spherical Earth map would come as an independent installation, leaving existing terrains intact and playable.

• What has been expected is now confirmed and proper. Due to the profound changes this technology introductes, it cannot be simply bolted ontop of existing terrains (or the other way around, the existing errains cannot be just pasted into a 3D sphere model).

 

- Significantly, the second statement is worded in an odd way that blames the current day design theme/scenario/setting of the content of the new spherical Earth map to be somehow a limitation which prohibits other scenarios such as WW2 from supposably existing in a spherical Earth map, at all.

• This, no offense, makes no technical or practical sense at all, it's one of the points I have the biggest objection to. The sphere map technology must not be developed and implemented in such a way that creates hardcoded limitations to some kind of a specific scenario. I would really like to believe that this was a writing mistake of the newsletter and that this most likely isn't the case in the program code today.

- Additionally the same statement also says .. "independent of ... future regional maps ...",

• In my opinion, flat terrains of today should be segregated as "Legacy flat maps" scheduled for future deprecation.
• DCS 3rd-party developers should be provided with tools and APIs to be able to create their own spherical maps/instances in addition to flat ones, irrespective of the scenario theme, setting, season or size of the intended populated/gameplay/textured zone.

 

Additional Propositions:

 

• Spherical-s is the way to go  - Multiple instances! I see no reason why there couldn't be multiple instances of a spherical Earth map, existing independently, without the need to necessairly provide a whole world high-detail coverage/experience. A user just wouldn't be able to run more than one at a time ofcourse, we're not talking about simultaneous instances, just like only one flat terrain module could be loaded up currently.
  • The major point is ofcourse in the curvature that even the smaller regional spherical maps would benefit from. Just because the intended coverage area may be "small", it doesn't have to be limited to flatness.
  • Such smaller-area-only(regional) spherical Earth maps would segregated/categorized away from the fully populated spherical Earth maps.
  • Normally a user would expect to be able to travel freely and circumnavigate the sphere even on regional spherical maps, which is another major reason for such maps to also be spherical. However I would suspect that such kind of maps would need several special rules for AI's and Players alike due to most likely limited functionality outside fully populated areas, when operating outside the covered areas would affect gameplay in a negative way. For example other airfields could be disabled if they would infact exist as part of the core default spherical map.
  • Map developers would build their regional (limited) spherical maps ontop of a base-level layer of minimaly acceptable visuals and terrain surfaces, outlines of land, shore, mountains, forrests, and other geological features, textures.
  • The other reasons for a faster transition to spherical map technology is global weather, even regional maps would in that case benefit from this, which would avoid the need to maintain both flat and curved weather flavors, thus spending more effort trying to make the weather on flat terrains work as good as it would on the proper spherical version, should be avoided.
  • Current flat maps in early development should review future planning and reconsider whether they should push for an earlier switch to spherical before commiting too much time and effort into the flat method.

 

 

• Common Curated Assimilated Sectorized Spherical Earth Map - This is actually that main idea how I imagined we could one day experience this technology in DCS.
  • This particular map instance would be intended to contain assimilated/recycled/converted content from existing flat terrain modules, provided by it's developers if they hopefully wish to do so, therefore a "common" map. Additionally it could be regarded as a transitional map, separate from a fully fresh from-scratch map instance that ED (alone?) is already seemingly working on.
  • The sphere model would be split into many standardized sectors of a grid, perhaps one of the standard GIS or military grids out there.
  • Perhaps evenly splitting those sectors down into smaller ones which DCS would accept, for more map making and merging flexibility.
  • All sectors would have unique identifier, those that are split from larger ones would preferrably bare some reference to it's parent before their own identifier.
  • A sector would accept an asset package that's specifically built for it and it's size type.
  • The asset package would, at least in this case let's not get too comlpex, contain a complete set of the terrain and all of it's features minus the core basics of the spherical map technology, which would all be the core spherical map technology responsibility managed by ED, thus alleviating 3rd-party developers from having to worry about physics, global weather, and other core and under-the-hood parts, allowing them to better focus on the actual map creation of the surface heightmap, ground features, objects and textures.
    • So when a developer would choose to develop a sector or sectors intended for this common spherical Earth map, they would start from a different template and slightly different set of APIs and tools versus what they would if they would be trying to create their own whole fresh instance of a spherical map.
  • The idea is for the users to be able to pick and choose which sector asset packages to buy, install and activate, depending on what they're interested in.
  • Regional spherical maps could be sold as a set of multiple sectors.
    • Perhaps optionally as a monolithic module of inseparable multiple sectors, without needing any special tooling to prevent extra effort dealing with possible sector boundry issues, by just locking multiple sectors artificially as a rule, disallowing users to try to fill in other (most likely incompatible, bug prone) sector asset packages replacing parts of this monolithic regional map. All or nothing. This is how these recycled flat terrains could initially be featured on this common spherical Earth map instance.
  • The ability to have multiple sector asset packages per sector, whatever developer they're coming from, whatever the design theme/timeline/setting it is.
    • Most significantly, enhancing cross-developer flexibility, redundancy avoidance and cooperation possibilities, allowing smaller map developers to contribute to the whole map without having to commit to large project timelines and resource requirements, but this isn't intended for this recycled map instance, but rather for the new fully-fresh from-scratch one that could and should also be in development for the future.
  • Users should have the ability to switch between sector asset packages in-game, only required to reload the mission, not the game program.
  • For that, new in-game user interface for map sector management would be created as part of DCS core, intended for users to activate-deactivate various sector asset packages, with a basic "F10"-ish minimap overview of the 3D sphere model where they could select and choose which installed assets packs would they like to enable on which sector.
    • The buying and installing management would be added to the in-game Module Manager.
  • Functioning global weather and fully dynamic seasons according to in-game date/time, so separate seasonal instances would be completely unnecessary.
    • Developers should avoid creating traditional multiple season versions until that system and tooling for making and populating the spherical map with dynamic assets is actually functioning and provided by ED.
    • However developers assets should be allowed to skip supporting dynamic seasons even if such support is already there and possible, because this would slow down the conversion of existing terrains for this map. This can come later (if at all for this transitional map)
      • In that case there simply wouldn't be a change noticable whenever it starts snowing or whatever, the global weather and dynamic seasons engine could still operate in the background on their own like they would, affecting other possible minor things that do support them.
  • Boundled with a core default basic layer of minimally acceptable visuals, a base-level asset package, containing what I mentioned already, low-detail (low dev time) land surfaces, shores, mountains, forrests, structures and textures ofcourse, for the full coverage of this spherical Earth map instance.
    • These base-level visuals would function and be separated to sector asset packages, populating all of the sectors of the whole spherical Earth map by default when they're the only ones available, but they would be replaced completely once a "high-quality" (official but free, sold, 3rd-party) or another sector asset package is installed and available for use.
  • "Curated" because it would most likely have to be merged together by the main DCS developers (ED) before being released/updated to the public as a fully independent map module.
    • This is because, from my educated guessing, I am foreseeing possible technical and practical challenges when dealing with assets on or close to the sector boundaries, where content from different asset packages would meet, requring an extra process that would adjust/modify and ensure compatability for all of the asset packages that would be available for this map.
    • This would be a problem mostly between asset packages from different developers.
    • It's about the need for visuals to blend and linkage of logistics so that no sector boundry could be felt or be visible in the final game environment. For example:
      • Rivers would have to flow seamlessly between borders (even if "flow" is only a visual (not physically simulated) effect)
      • Civilian traffic would have to to drive seamlessly between borders, including waypoints and paths for Combined Arms.
      • Trains would have to drive seamlessly between borders, and  the signalling, scheduling, would all have to work.
      • Textures, materials and objects would have to be properly aligned.
      • What happens with assets that stand literally on top of a sector border? There might be thousands of structural assets that might land ontop of the sector boundaries.
    • There is a possibility that this issue may have a chains or domino effect which would, for making one sector asset package compatible with the rest, require adjusting not just the immidiately adjacent sector asset packages, but perhaps others or many others as well, if long stretches of railway or other infrastructure routes would so require to function properly (when they would have a gameplay functionality and thus more complex logic that goes along with them > dynamic campaign)
      • It may be necessary to rework the infrastructure/path/route system to actually support such modularity and sectorization.
    • Without the additional ED step and merging process, this would need substantial cross-developer cooperation and compatability effort which may be less efficient for each and all third parties to do, not just with DCS, normally addons by 3rd-parties do not cooperate or share source data in such a way.
    • With ED being responsible for properly merging all of the sectors, provided by different developers, this kind of approach might work but there could still be a need for advanced automated sector compatability tools and verification processes, because of the sheer amount of assets that there would be in the boundary regions, but also depending on the lower level systems and whether the idea of sectorization would be seriously attempted with other core components being built to better support it, alleviating the need for a complicated merging process and additional manual labor.
    • The great question is, or rather the big goal should be, if after all this would work, whether it would be possible to give users the ability to switch between sectors without having to actually download and install a whole different version of this common map instance, just to replace that one sector. The system really has to be able to work like that, otherwise the installs could be huge and quickly impractical.
    • The other solution is to simply have isolated sector asset packages (or a series of locked-combined sectors > "regional maps") where you wouldn't expect any content inside it to be functonal with any other sector asset package from a neighbouring sector.
    • On the other hand, in this case the common assimilated map is intended for quickly getting the existing flat terrains together on a circumnavigatable sphere, almost it not all of these existing and perhaps soon to be released regional maps are actually far apart and do not touch closely, which would significantlly simplify the merging process because only the outer borders of the multi-sector map asset package would have to be addressed and in this case the touching asset packages wouldn't be from other "high-quality" asset packages, but from the pre-existing core base-level assets so it would be an even easier task at hand.
      • ..because the core default base-level asset package layer would only feature a couple of main roads and railways, large city outlines and stations, a few structures and couple of airports/airfields and that's it, not that much to worry about connecting.

 

• In-house Spherical Earth Map - The separate independent spherical map instance with the "modern day" asset package that the DCS developers have apparently been creating fully fresh from-scratch for supposably the whole area of the spherical Earth map. And one day perhaps there may be a WW2 instance like this as well.

 

Other:

As mentioned, the flexibility and usefulness of this shift toward spherical maps, and merging of existing terrains into one salvaged spherical map, not perfect but a good start, might automatically alleviate some of the other problems that various community memebers have been expressing that do not necessairly have a direct relation to spherical modelling but to the way maps are sold.

Edited May 5, 2023 by Worrazen

[cfrag]

I find this to be a fascinating topic, and the prospect of having the whole world to fly in is tantalizing indeed. We should make sure, though, that in our excitement we don't jump to too many conclusions.

First, the 'spherical model' wrt to DCS as a flight sim has two very distinct applications that we need to keep separate. There is using the spherical model while the simulator is running. So instead of a flat earth that has all terrain surface points on a 2D map, these points are transformed to fit on curved surface, a sphere. Except for some edge cases (flying *very* high so you can see the curvature of earth, or sitting on water with LOS to distant objects which should have dropped under the horizon) such a change would have negligible impact on average game play: when you fly a jet to approach a carrier, your elevation (6000 feet or more) usually resolves LOS issues, and few planes regularly fly high enough so that we can theoretically see earth's curvature - 35'000 ft and more. Gaming impact would be minimal.

That being said, though, we should note that DCS today already has all required transformations from its 2D map to a spherical model in place: it can transform any 2D map co-ordinate into Lat/Lon - which is a spherical model. It's a linear transformation. Gaming-wise, there will be very little change, aside from some edge cases.

The other point is map streaming, i.e. a map that is so big that it does not fit into memory. For example the whole world. Spherical considerations only figure into this when we want to determine which chunk to load as we move from A to B. As you noted, the problem here isn't so much to figure out what to load, and to develop the technology to seamlessly integrate loading really huge amounts of data into an action game. It's difficult, but not insurmountable. Neither is getting global mesh data. Nor sat imagery. The big problem is - as you mentioned yourself - filling the gigantic void with meaningful, engaging and interesting data. For a glimpse of how big a task that is, load up the Falklands (South Atlantic) map and fly over Argentina or Chile. It's empty. Really, really empty - even after Raz have invested ungodly amounts of work. And for SA they use sat imagery to base their map generation on. It's a Herculean task even if you have terrain mesh, sat image and road data.

And this is, unfortunately, where we need to face a hard truth: ED and their partners are businesses: they exist to make money. Their business is to sell, among other things, maps. While it would only take a second to convince me - a customer - how great it would be if we could fly the whole world; or even better - from map to map (say: Take off from Kairo on the Sinai map to fly over Jerusalem to Beirut on the Syria map), you'll have a much harder time to convince ED's partners that they should relinquish their 'exclusive' rights to an area to the general public. Today, if you want to fly in Haifa, you need Syria. With a new streamed world tech, that would no longer be true. I know that there will be many people who feel that 'streamed real-world' Beirut is good enough for them. The map makers would need some form of guarantee that they still have a business. Raz, Ugra and the others have - or are in the process of - investing significant funds into map content design. They won't take kindly to having that pulled out from under them, they would want and need assurances that their business remains viable. That, I believe, would be one of the biggest challenges to master. It's definitely solvable, but I think we won't see any progress with a streamed world until that is resolved. 

4 hours ago, Worrazen said:

Lastly, the mention about "modern only" in the newsletter also wasn't entirely clear to me, because why would te Whole World Sphere tech disallow WW2 type of terrain

It's most probably a result from how we can get to a populated game map: take sat imagery for a region, and then, based on what we see on those images. we create map objects: roads, buildings, land marks, forests, cities etc. In populated areas, WW II maps were very, very different from today: cities were smaller, roads less pronounced (few highways if at all), with some significant changes to today (airfields that did or did not exist, industrial zones that were built in the 50s or that declined after the war). If you want to have any chance of creating a more-or-less interesting (not realistic) streamed world, you'd most probably resort to sat imagery that is populated by AI, based on the sat imagery. Since we don't have WW II based sat images, only modern maps have a chance to be auto-generated that way.

And then there is the performance issue: There are flight sims available today that use a streamed world with large stretches of high-detail areas, populated mostly by AI. Try them, and then decide if you would want that in your combat flight sim. I live in an area that is available as "high res" for two such sims. I took a helicopter, and 'went home' in the two sims that I own. Compared with unrealistic-but-hand-crafted Caucasus, these high-res areas are are ugly, chunky, obviously not real - but hit my system much harder performance-wise. That's the secret of these hand-crafted maps: they take an unholy amount of work to assemble objects, and then and even greater amount of work to optimize. Yes, ideally suited for community work, agreed. But if you, on your way to build a greater world map destroy the business model that is the underlying foundation of DCS, that victory would be pyrrhic. So there are business questions that need to be answered before the artisan challenge can begin.

 

[Mr_sukebe]

As fast as possible?

What do you really mean by that and have you really thought it through, eg

- do you want to have little or no testing?  That can often be the longest time consuming thing to do, certainly so if you want to do it well

- when do you want it, eg date.  Even some physical elements of the world change, eg coastal erosion and reclamation

- what limits do you want to have, such that out current PCs aren’t incapable of running it?

- how much will it cost to build and can ED sell that many units

- what changes will be needed to existing coding to be compatible, oh and don’t forget to test and correct them too

- how to integrate with inbound technology, eg the planned dynamic campaigns and Vulkan

 

In principle sure, but ED have already said that the whole will come…eventually.  Chances are that it’s going to take a long time, so take a chill pill

[Worrazen]

I have just significantly rewrote this thread for far more clarity on what my idea was and how I understood the newsletter. I also removed the part that's way too speculative and forward looking about the modularity of cooperative development(breaking map making down to individual components), which really wasn't the main purpose of the topic but only as an additional possibility that I could talk about later or elsewhere, and ofcourse as with any approach there's a set of tradeoffs and this can have a lot of downsides and challenges to be practical for the developer as for the user side.

Replies:

@cfrag

1a: Yes, the curvature should not have a major impact on average gameplay in a small battle zone.

1b: I suspect there should be measurable differences in artillery ranges already, not to mention long-range stuff.

For this purpose I weant and did some more research and found a promising quora post on this exact question(just using bullets instead of artillery shells):

Which reminded me when we're talking about curvature, it's not just surface curvature but also curvature of the gravity as well that you suppose to account for.

https://www.quora.com/How-far-does-a-bullet-have-to-travel-before-the-curvature-of-the-earth-effects-it-trajectory

Quote

The red line shows the “school text book” trajectory where the Earth is flat and so gravity is vertically downwards all the way. The blue line shows the trajectory taking Earth’s curvature into account. I’ve also drawn in the surface curvature itself as the green line. Distances are in metres.

You can just see that the blue line drops more quickly than the red, due to the direction of gravity rotating with the curvature. In fact the red line is part of a parabola and the blue line is part of an ellipse with the Earth’s centre at one of the foci (what’s known as a Kepler orbit, as worked out by Johannes Kepler in the early 1600’s).

Let’s zoom in on where the bullets land to get a closer look:

Quote

I’ve added in crosses where each trajectory hits the ground. At this distance (1.4km) the blue trajectory is around 8cm lower than the red trajectory due to the change in the direction of gravity. However as you can see, there’s a more significant impact because of the curvature of the Earth itself, dropping below the horizontal axis that represents a flat Earth. The bullet on the blue trajectory travels around 5.5m further (horizontally) due to this curvature, despite being lower than the red trajectory.

So the effects are easily measurable at this distance, at least if it wasn’t for random variations that are difficult to control in practice, such as air currents. But of course, this is all just a matter of degree. The effects don’t suddenly start occurring at a particular distance. Even at a horizontal distance of just 200 m the blue trajectory is around 1.6 mm lower than the red one.

So if this test plot above is watertight, a 5.5 meter difference at ~1.4 km already is significant and measurable, that's easily the difference between a direct hit or a complete miss (excluding splash damage/AoE for appropriate weapons) ... but after a discussion with some math/physics people and my own analysis, it will indeed not have that of a major effect on gameplay because:

• Spherical conditions would persist for a session and even across sessions (let's ignore the continued availability of flat legacy terrains for now), while wind and temperature can change and will change quickly (if it's change/effects would be simulated for artillery shells and other projectiles)
• Everything would ofcourse support the spherical model and would show proper distances/amounts, the sensors, binoculars, artifical helpers (Combined Arms) therefore for example your ranging intel would give you a number which would already be adjusted for curvature, the same way it gives you numbers based for flat surface right now, so you wouldn't need to adjust it for curvature yourself and re-acquire the gameplay skills.

 

1c: However curvature of the surface and gravity is one thing, there are others. The biggest one may therefore be circumnavigation-ability. Though speaking about circumnavigation, there should be an ability to limit the playable area to a zone/radius as a dedicated server or mission scenario rule (and limit the dynamic campaign engine to it), where the goal would be to focus  example to closely or loosely replicate a historic scenario and have the things happening outside navigatable zones scripted to simulate for example reinforcements and other things.

There aren't just strict gameplay in-the-cockpit factors, but convenience factors at large, for sessions, servers, etc, you could have the ability to dynamically change playable area, expand or shrink it, in the same session, adding flexibility to server admins, that would avoid mission reloads, server restarts and reconfigurations. That is the real broad benefit of having one big spherical map. Yes this will take disk space if you'd choose to install everything in high-quality, but that's what it takes to replicate reality and have these conveniences. A 2 terabyte NVMe SSD for DCS shouldn't be something surprising. It shouldn't be slow or buggy, that wouldn't be the spherical map's fault, that's all memory management responsibility, it just needs proper programming to dynamically stream surface assets like it's already doing, just even more optimized and better.

Edited May 6, 2023 by Worrazen

[cfrag]

1 hour ago, Worrazen said:

I have just significantly rewrote this thread for far more clarity on what my idea was and how I understood the newsletter.

Please don't do that. That's often considered rude and a breach of etiquette, since when people respond to your post, and you change your original post after a response, it breaks context. You didn't just correct some spelling, you fundamentally changed the direction of your post.

I no longer feel inclined to discuss this topic with you. 

[Silver_Dragon]

Some remarks....
- 3rd parties has none control over a flat or a sphere maps, inself, that has dictate by the Terrain Develop Kit (TDK) and your tools.
- "Assets Packages" has no feasible, the TDK will coming with a limited assets, but "other simulators" the map builider / 3rd party, need build all assets. On fact, the actual technology use very low to low asets generated by AI meanwhile previously, was all "autogenerated" with very low quality.

[Worrazen]

1 hour ago, cfrag said:

Please don't do that. That's often considered rude and a breach of etiquette, since when people respond to your post, and you change your original post after a response, it breaks context. You didn't just correct some spelling, you fundamentally changed the direction of your post.

I no longer feel inclined to discuss this topic with you. 

I can ofcourse apologize and agree this shouldn't be a habit, but this was a special case of this idea brewing for a couple of months and me combining several temporary notes, merging them and constructing the final post that I always wanted. It took me considerable amount of time to finish it (over a span of 3-4 days) as I was not satisfied with the initial post.

To me it however doesn't seem that it would severely affect your post except maybe 10% of it, even the direct quote you made of one of my previous sentences has practically remained the same in effect, just worded differently. More than half of your initial post is about other topics which I didn't brought up in my original OP, mainly issue of memory management of such a large map and other challenges.

Your worries are all valid. Though my goal with this post wasn't to chase the challenges associated with the idea too much, but if I can I will address them, but I'm not actually an expert and my familiarity of potential challenges and the significance of them may not be the best, though I have done extensive troubleshooting with DCS and it's memory management in the past and there should still be old threads on this forum about this, but those are quite unrelated in this case and it doesn't really help when speculating about spherical maps, and the engine is going through a transformation to multi-threading and the rest so things will change dramatically for the better, but yes the developers have to take everything into account. My position currently isn't that worrying, multi-threading should give good boost to the dynamic memory management, but it was already functioning better in the last few years. Hardware it self is well to blame, thankfully AMD has additionally upped the standard amount of VRAM on Radeon GPUs so that will help a lot going forward.

Memory management could take sectorization for help to simply ignore anything on sector designated "disabled" or something, roughly speaking, you could improvise easily, you could "put" Normandy 2.0 into a spherical model today and disable all other areas/sectors and it would result in practically the same experience when it comes to RAM/VRAM memory. They surely will upgrade the memory management aspect along the way for a full globe experience.

  

On 5/2/2023 at 12:13 PM, Mr_sukebe said:

As fast as possible?

What do you really mean by that and have you really thought it through, eg

- do you want to have little or no testing?  That can often be the longest time consuming thing to do, certainly so if you want to do it well

- when do you want it, eg date.  Even some physical elements of the world change, eg coastal erosion and reclamation

- what limits do you want to have, such that out current PCs aren’t incapable of running it?

- how much will it cost to build and can ED sell that many units

- what changes will be needed to existing coding to be compatible, oh and don’t forget to test and correct them too

- how to integrate with inbound technology, eg the planned dynamic campaigns and Vulkan

 

In principle sure, but ED have already said that the whole will come…eventually.  Chances are that it’s going to take a long time, so take a chill pill

1. Yes the "ASAP" doesn't use the common meaning of doing it so fast you ignore everything else, but faster, certainly much faster if you don't set a goal of trying to finish the whole world in high/full quality.

2. If the barebone spherical technology is complete, that it-self either works or not, correct distances, measurements, coordinate displays either work or not, but yes it's about other systems being sphere-aware that would take more time before it's ready for release and/or beta testing ...

In programming however, generally speaking, there are lots of common functions and common libraries, and what we're talking about here is the lower levels (coordinate system, gravity) which do affect many many things, but at the same time many many things can use that same common library and function. You change the function once, you change it for everything, without having to go to an individual unit and change it for that unit (but depends, long story). Many units (ground) could be using some common function-s that are responsible for sensor/positional data/indicators which depend on the coordinate system, it's not that hard for a skilled programmer to adjust that function, and if it works there, it'll work for all units/things using it, you test it once, twice, but that's enough, there's nothing more to test, you're done.

You could have it even earlier if you just have a subset (build) of it with errr "spherical caucasus" and only a few compatible units, but the lesser it is the less worthwhile it is for the community.

3. No dates ofcourse, the proposition isn't about an actual barebone sphere being released, but the one which would have a functional but low-definition coverage of the whole Earth, with at least 1 major region in high-definition (Caucasus) and I would consider that good enough for closed-beta, I think 1 or 2 3rd-parties would be able jump on the bandwagon and convert their flat maps for spherical a few months prior to closed-beta and 6 months later you'd, somewhere in the middle there could be an open-beta and the players would get ~2 regions of high quality, but just one would be enough for starters.

Isn't that reasonable?

I can't know that sure if it is reasonable enough, perhaps the whole thing would take much much more time and they would agree that there should be a preview earlier and we might get half the functioning coverage, with the other half of the Earth being hardcoded off-limits. There's gaps that I do not have familiarity with in terms of time/effort/research wise so I'm ofcourse avoiding any such guesses.

4. Not that worrysome since the same newsletter mentions the adaptation of the fog system for spherical awareness and integration of the cloud system with dynamic weather engine is ongoing, complex but it's happening, they're surely not going to stop until they make it work. I'm not sure Vulkan's rendering it-self would be that of a factor in spherical efforts.

 

Edited May 6, 2023 by Worrazen

[cfrag]

Just now, Worrazen said:

I can ofcourse apologize

No apology needed, just be mindful of how others may interpret your good intentions  - I thank you for your thoughtful response.

I believe that although you raise some interesting points, it could perhaps help if you made sure that you understand the examples that you are citing as to not accidentally misrepresent them:

2 hours ago, Worrazen said:

a 5.5 meter difference at ~1.4 km already is significant and measurable, that's easily the difference between a direct hit or a complete miss

The plot is accurate, but you probably missed the (very important) assumptions/preconditions that go into it: a) constant 1000m/s velocity, i.e. no air or other effects that would slow the projectile (air has significant drag), b) fired at exactly perpendicular to surface, and c) assuming a perfectly smooth earth surface, with nothing sticking out. The calculations say that the earth drops 8 cm over 1400 meters (correct only for perfect sphere), and the bullet then has 8 cm more 'altitude' drop at 1000m/s, which at this parabolic point translates to 5.5 meters before it hits the ground. Important: the bullet wasn't aimed at anything, the experiment answers the question: "how much further does a bullet fly due to the fact that the ground drops on a curved surface". The answer is "the ground drops 8cm, and at 1000m/s velocity and G=9.81m/s2 gravity, that translates to a 5.5 meter longer trajectory as compared to level ground".

If you blindly aimed at anything sticking out from the ground that is higher than 8 cm, it would still hit it, assuming an ideal point (null size) projectile. If the projectile itself is 8 cm in radius or more it would still hit because the drop of 8 cm of ground is less than the projectile's size. So it's not a miss by 5.5 meters, it's an 8 cm relative drop of the ground due to curvature. It will still hit.

Since you usually (at 1.4 km) actively (i.e. not blindly) aimed using straight line of sight, you would corrected for those 8cm drop since they can be seen; if you are using radar/laser aim helpers like CCIP - they of course take distance and parabolic flight into account; naval artillery charts always use spherical earth correction in their calculation tables; taking this into account gamewise isn't a complex issue (if your local theater is flat, ignore; else add correction in).  

So yes, there is an 8 cm drop of the ground for 1.4 km distance due to earth curvature. That is negligible compared to the effects of air friction/drag to velocity and therefore parabolic flight path. The change in gravity (the down vector) is also irrelevant, as it barely changes (circumference is 40'000 km ~ 360°, so 1.4 km is ~0.01° deviation = 0.0017 correction factor to G). So the two biggest factors are air drag on the projectile (including wind), and the parabolic trajectory incurred by constant gravity (the constant down force which doesn't change perceptible at 1.4 km). Curvature is a non-issue. It definitely can become an issue for artillery at greater ranges, and that can be corrected with tables or direct calculations which are well understood and not difficult/performance intensive.

So spherical earth considerations are negligible for local theater active gameplay. If the theater of gameplay grows significantly, curvature may start impacting large-scale factors like communication (LOS), and long-distance flight path (great circle). Although (hopefully) possible in later DCS, I'm not sure that long-distance flights where this matters will be everyone's cup of tea, so I hazard the guess that most people would stick to short-distance engagements where curvature again is not an issue.

What will make noticeable dent is something related: the size of theater. Let's disregard storage requirements for the moment. No matter if spherical or flat - if you have 5000kmx2000km map (=10 mio km2 - about the size of Europe), you need a lot of units to fill it to mage an engaging game, and gobs of players (otherwise they can play on smaller maps for more fun), and that will tank the processor - Multithreading or not, keeping track of units will be the death, not curvature of the map. Curvature is just a linear transformation of co-ordinates. Tracking 1000 units will require that each of the 1000 units check if they can see the other 999, an exponential growth in performance requirement. Spherical earth is child's play against that. 

3 hours ago, Worrazen said:

There aren't just strict gameplay in-the-cockpit factors, but convenience factors at large, for sessions, servers, etc, you could have the ability to dynamically change playable area, expand or shrink it, in the same session, adding flexibility to server admins, that would avoid mission reloads, server restarts and reconfigurations.

Agreed - perhaps some new tech like a server mesh that each take only part of the globe, and people transition from one server to the other. The idea is great, but would break all current servers, all current missions, and may require a completely new set-up game-wise. It probably has not escaped your attention that Cloud Imperium Games have tried and spectacularly failed with such a set-up for their game (a space game), so that technology is still nascent - but promising.

My take on this: I definitely like the idea of spherical earth and the idea that I could theoretically use any location on earth as theater. Implementing this is not so much an issue of a spherical coordinate system, or transitioning to it. It's definitely a performance challenge data wise (earth is really, really big) und unit-wise (big theaters tend to be fun only with many units, and units kill performance). Leaving aside legal considerations (how do the 3rd party vendors that create map content figure into this), the spherical model itself is a side issue, that has been resolves years ago. The bigger problem I see is with distributing and handling work-loads for large maps. 

One way or the other (flat earth or spherical): the future is promising to be great

 

[Worrazen]

27 minutes ago, cfrag said:

No apology needed, just be mindful of how others may interpret your good intentions  - I thank you for your thoughtful response.

The several different half-finished notes I had in many places have all had different terms for the same thing such as "zones / area / border / boundary / sector" or "sphere, globe, whole, 3D" - I just had to rewrite and normalize it to one coherent piece so that even I could find my head and tail in there , the content was expanded and separated into bullet points and paragraphs.

 

34 minutes ago, cfrag said:

No apology needed, just be mindful of how others may interpret your good intentions  - I thank you for your thoughtful response.

I believe that although you raise some interesting points, it could perhaps help if you made sure that you understand the examples that you are citing as to not accidentally misrepresent them:

...

Indeed and appreciated a lengthy dive into the end-result effects of just this change affecting or not affecting gameplay. Perhaps if my OP had the indication that I'm trying to prove some kind of a significant gameplay effects/benefits/realism with this then wasn't my true intention apart from just being enthusiastic about the subject, admittingly focusing more on the benefits rather than challenges yes. I'm However I did infact isolate every other factor on purpose and I was aware that I'm disregarding air/temp/wind and surface feature factors, in order to first get an idea about the raw difference of curvature alone, but you are correct that I should have added context to that sentence that is indeed a raw test condition and the difference between hit and a miss would be just in those conditions of the test, ofcourse actual surface is rough on both flat and spherical types, not perfectly smooth.

 

44 minutes ago, cfrag said:

My take on this: I definitely like the idea of spherical earth and the idea that I could theoretically use any location on earth as theater. Implementing this is not so much an issue of a spherical coordinate system, or transitioning to it. It's definitely a performance challenge data wise (earth is really, really big) und unit-wise (big theaters tend to be fun only with many units, and units kill performance). Leaving aside legal considerations (how do the 3rd party vendors that create map content figure into this), the spherical model itself is a side issue, that has been resolves years ago. The bigger problem I see is with distributing and handling work-loads for large maps.

The distribution and revenue model is something that I think I included in the original OP briefly, either way it was in my notes but I removed it along with some other parts I didn't felt were to be discussed yet as I had to finish these main points that we discussed so far, so I definitely agree and have foreseen there might have to be changes and negotiations around this. At this exact moment I'm recovering from deep focus into these primary discussions so I'm kinda out of ideas and a good writeup for the distribution/updates/revenue/prices side of things, but certainly anyone can discuss this in the meantime while I take a bit of a break. On the other hand perhaps it may not be that necessary for us to speculate on distribution, if the technicals, wishes, and economy pans out, they'll surely figure it out and adapt the distribution and revenue model to it, not the other way around, ...rrright?

Mainly that we established some understanding around this topic, my self included as I was getting more familiar and re-checking my knowledge while writing the OP; the expectations and wishes, and that'll help out the developers shaping their priorities. So I'm glad I finally managed to get this one written down and the added discussions from everyone else here would also give the rest of the community the idea what's going on around the spherical map technology.

 

[Mars Exulte]

What is the point of this huge wall of text both explaining the obvious and somehow also begging? Do you think it's sitting on a shelf somewhere and Nick Grey is like ''NO NO, not yet... let them... stew in their angst a bit longer. The suffering makes the meat taste... sweet.''?

They will release it if/when it's ready, and forum users writing lengthy discourses on the ''community's needs'' and ''ED responsibilities'' is, at best pointless.

[NineLine]

We will release any new feature and update only when it's ready for customer consumption. That's all I have for you on this. 

[Worrazen]

12 hours ago, Mars Exulte said:

What is the point of this huge wall of text both explaining the obvious and somehow also begging? Do you think it's sitting on a shelf somewhere and Nick Grey is like ''NO NO, not yet... let them... stew in their angst a bit longer. The suffering makes the meat taste... sweet.''?

They will release it if/when it's ready, and forum users writing lengthy discourses on the ''community's needs'' and ''ED responsibilities'' is, at best pointless.

I didn't wish the "ASAP" context to feel like I would want things rushed, but after I already edited the post and title, I rather just leave it like it is and everyone that reads into it will see my explanation regarding that, so begging isn't intentional.

On your main point, didn't I heard that quite recently some priorities were changed with F-16 or F-18's sensor pod development so that one that was scheduled for later is now going to come sooner to make it not feel like it's a downgrade, but I do understand that it depends on other factors and we can't expect to adjust every bit of back and forth with development by just making a few arguments in threads.

Many things in such threads are meant to be discussions, ideas, thoughts and opinions which is just there, I would say threads like this are far less of a nuisance than some the low-effort bickering that most likely happens as it does in general in gaming community discussions.

The "community's needs" in this case was true yes, but not in a way that I would speak for the community. I kept reading various posts over the months around maps, the splitting, server admins, etc ... and then I thought that many of those complaints could be solved by the whole world spherical Earth map which was mentioned further back in interviews so it was something that's going to happen, then the January 2023 newsletter finally mentioned more details about it, some of which I had my own comments on and that's how this thread got made, with good intentions.

Yes I rather make such big well-done threads rather than sprinkling it over 50 posts all over the forum or elsewhere.

[Silver_Dragon]

49 minutes ago, Worrazen said:

I didn't wish the "ASAP" context to feel like I would want things rushed, but after I already edited the post and title, I rather just leave it like it is and everyone that reads into it will see my explanation regarding that, so begging isn't intentional.

On your main point, didn't I heard that quite recently some priorities were changed with F-16 or F-18's sensor pod development so that one that was scheduled for later is now going to come sooner to make it not feel like it's a downgrade, but I do understand that it depends on other factors and we can't expect to adjust every bit of back and forth with development by just making a few arguments in threads.

Many things in such threads are meant to be discussions, ideas, thoughts and opinions which is just there, I would say threads like this are far less of a nuisance than some the low-effort bickering that most likely happens as it does in general in gaming community discussions.

The "community's needs" in this case was true yes, but not in a way that I would speak for the community. I kept reading various posts over the months around maps, the splitting, server admins, etc ... and then I thought that many of those complaints could be solved by the whole world spherical Earth map which was mentioned further back in interviews so it was something that's going to happen, then the January 2023 newsletter finally mentioned more details about it, some of which I had my own comments on and that's how this thread got made, with good intentions.

Yes I rather make such big well-done threads rather than sprinkling it over 50 posts all over the forum or elsewhere.

The "Comunity needs" has always the "Where are my ... <module / feature >" discussion with always full the forum post before a release, nothing new, and the comunity never change, with many examples as actually of "Get my F-4E / F4-U1 / Synai / etc, etc, etc" and "ED doesn't do his job / doesn't listen to us".

Spherica Earth map has a very dificult technology to implement with some years of researchs, planning and develop as Vulkan, MT, Dynamic campaing and others and require time, resources, time and planning to reach to a propper release status. Do you like ED release them broken only by a "ASAP" and the "hate" return as happened in the past with F-16 and others?, sorry, but I prefer to wait quietly until it's ripe before they give me something broken and this turns into hell again.

[Worrazen]

1 hour ago, Silver_Dragon said:

The "Comunity needs" has always the "Where are my ... <module / feature >" discussion with always full the forum post before a release, nothing new, and the comunity never change, with many examples as actually of "Get my F-4E / F4-U1 / Synai / etc, etc, etc" and "ED doesn't do his job / doesn't listen to us".

Spherica Earth map has a very dificult technology to implement with some years of researchs, planning and develop as Vulkan, MT, Dynamic campaing and others and require time, resources, time and planning to reach to a propper release status. Do you like ED release them broken only by a "ASAP" and the "hate" return as happened in the past with F-16 and others?, sorry, but I prefer to wait quietly until it's ripe before they give me something broken and this turns into hell again.

1. To be precise I was referring to various posts here and in other flight communities about people expressing the desire of being able to fly from one to another terrain, the fear of having to completely restart custom missions once an upgrade to a map makes them incompatible, etc.

2. I don't object in general, but as @cfrag pointed out the sole spherical technology in it's raw barebones isn't that of a major job, once it is set up it just works, it can't be half a sphere, it's round and you can travel around it so it works, it's more about making everything else work with it, and correctly it's not ready for the community that wishes to have more than an empty ball to fly around, so I don't disagree there.

Besides all of the surface terrain and assets, how many other engine components need to be made compatible and how complex that job would be is hard to guess, there migth be other upgrades and new additions done along the way that don't exist in these current public DCS builds, but if it's only about transfering what DCS has today into spherical, I would say that I doubt the task is as big as MT or Vulkan or EDDCE, in complexity and time, because it should be about adjusting, hopefully not having to re-create physics modelling, what for every single aircraft and movable object, I doubt it.

After that comes all the static map objects and the surface it self, texturing, but that's a separate field that can be done concurrently(independently) by the map making specialists.

In the end I'm just responding with additional thoughts as just thoughts and entertaining my side of the argument, it's not an absolute belief that what I say must happen or else, I'm not part of those kind of discussions that you guys would be used to from the rest of the community, so I hope mine didn't sound so demanding, but if it does it's not intentional.

Having for example Caucaus and Syria on a preview spherical map, linked by a few key roads and railways, with 3-5 airports while much of the in between surface (Turkey ...) is low-quality, wouldn't be too much to ask in my opinion, because everything else has been released in such early-access fashion (that doesn't mean the future has to be so, I get it, but that shouldn't nullify my argument completely). Doesn't even have to be necessairly circumnavigatable all the way around and could be artificially playarea limited to this region but it would still be spherical under-the-hood and provide a good beta test non-the-less.

That said, I do actually have no idea what the community thinks about having these low-quality gaps, how would it work out for gameplay, would it be acceptable for the community, worthwhile, or would it look broken and end up being annyoing, I honestly don't know and I admit this was been my sort of less conscious speculation that I only realized right now. The community would have to vote on whether they would find this kind of merging of exisiting regional maps toleratable.

Edited May 7, 2023 by Worrazen

[Dragon1-1]

Current maps can't be converted or reused for the spherical Earth map in any way. The only things that would carry through are buildings and so on. A flat map is simply incompatible with spherical geometry. 

TBH, I suspect it's going to come after Vulkan and MT hit stable. It's already been stated that some features, most notably cloud API, require the work on MT to be finalized. Whole Earth map probably more so.

[Silver_Dragon]

1.- "Restart mission" will need required when you change from a "plain mat" to "spheric map" by geometry, not sure that will be a problem. Has the same situation with ED big patchs when new scripting funtionality has modified / updated and old ED, 3rd party campaigns will broken and required redone.

2.- ED surely will build a "autogenerated" maps as some old fly simulators on the past, making a low detail world  with cities, airports, roads, rivers etc on your sphere map. On fact, actual TDK (Terrain develop Kit) map tools use global  data server as NOAA to get mesh / texture data to build elevations, depth, roads, powerlines, etc (missing funtionality to build depresions below 0 feet / metters as talked by OnReTech on your Sinai Map, waiting ED implement them), all filled with generic objects by ED libraries.

Old very outdated TDK (Terrain Develop Kit) 2018 Editor, not representative of 2023 version. You can see the install of assets packs / global data / map building.

About convert old maps from planar to spheric ED surely build some pluging to add to TDK to export them, of course ED and 3rd party need check and remodel your maps searching bugs and other problems before ED release that technology (Surely some world map "alpha" API  will be tested today by some 3rd parties to get feedback to ED). Otherwise, the map interconections mesh and textures will require join work by ED and/or 3rd parties but that has only will require time. Other point with be roads, train lines, etc, connected to "commun" points added to the maps on the borders.

Edited May 7, 2023 by Silver_Dragon