Efforts on terrain representation

[Ingolf]

As I understand it eSim is in the works of creating:

1. roadbanks/escarpments to level out the roads on top of coarse elevation data (which is great)
2. introduce a woodland fractal-like topography on-top of coarse elevation data, to reduce the "flat-terrain-factor" (also great)

I see this as a measure to create more believable terrain out of free/open elevation data.

 

My question is (for the future):
Can SBProPE make good use of real point-clouds (i.e. laser data) down to 0.25-1.0 m resolution? This would apparently (to a degree) eliminate the need for 1 and 2 above. How are the thoughts going about this for now? Graphics engine limitations? Perhaps this is already utilized in the classroom version?

 

The trend towards more and denser open data is speaking for itself, but it will take some time (if ever) before the high-res datasets are being released as open data (depending on national policies). As I work with advanced GIS on a daily basis, I was just curious to hear if eSim could elaborate on the future thoughts on terrain representation (including infrastructure) and the fact that there are fantastic data available, just not yet with a cheap price-tag.

 

All the best, and thanks (for the 100'd time) for a fantastic sim ,

/Ingolf

[Ssnake]

The engine will, in principle, be able to handle LIDAR scan data (as has been demonstrated by this YouTube video from last year. Whether it's always a good idea to use high resolution data is a different question. The ground resolution has been increased by a factor of 256, which also means a factor of 256 in the growth of height maps; if a current height map is 30 MBytes large we're talking about a single map occupying 7.6 gigabytes. This has implications about loading times, data storage/disk space, system RAM requirements, and the way how internet multiplayer sessions can be set up if some players don't yet have the map installed for a given scenario. Also, you need to ensure the validity of map data across all clients.

 

A better approach would be to use higher resolutions more selectively. You need high resolution only where there is high detail. So, that's one more area we're working on, to allow to mix source data of variable mesh width as a means to reduce the sheer mass of data to deal with. Oh, and on top of it, please retain the ability to edit a map on the fly to meet a scenario's specific requirements.

 

Of course we have ideas where we want to go. The initial implementation will be substantially less ambitious. Like I mentioned before, the initial scope of work is to replace the old terrain engine with one that is fully backwards compatible AND which has the growth potential for future improvements while retaining much of the ease of use that we're accustomed to when it comes to our map and mission editors.

 

 

In summary, the things that you mention are to a degree our long-term goals. The short-term goal of releasing the new engine later this year is more limited in scope to minimize the overall development risk. Secure the bridgehead first, then break out of it.

[Ingolf]

A big thank you, Ssnake, for your comment!

 

Good to hear/see that the engine can handle the data. I was misinformed about that video showing LIDAR, I thought it was a random noise overlay. I see now (in the zoomed out/up section) that it's LIDAR. Thanks for the clarification.

 

The representation of such large datasets always needs some baking so algorithms for selection/rendering comes to mind, as you say.

Back in the day when high-res DEM's (i.e. 0.25m vertical, ~1m horiz) saw first light, the software available could not keep up and one had to render small parts at a time (RAM/GPU-dependent). With todays software solutions (and better hardware) it is possible to render a whole nation down to 1 m on the fly. But of course, with Steel Beasts, it has to have a game on top of that!

 

The only title where I successfully (performance wise) used 10m DEM on a national scale (well ~200 000 km2) + "auto-generated" infrastructure on vector-based GIS-layers, was the FSX-SDK. But here, the units don't fight eachother .

 

Thanks for taking the time for a little casual talk on the topic. It's amazing what eSim have accomplished so far. I like the present graphics in SB and also look forward to seeing how the bridgehead is secured!

Intrigueing, indeed. The way to go!

 

Cheers,

Inglf

Edited April 16, 2017 by Ingolf

[Ssnake]

When it comes to the bumpiness of the ground per terrain theme setting, that IS a random noise overlay, yes. but under that artificial "wrinkling" high res data can still be used. One might start to debate the purpose of the artificial noise once that the LIDAR scan offers a sub-meter resolution, of course. But I think we'll start looking at that once that our customers use ultra-high resolution terrrain databases on a regular level for all their training purposes. To be honest though, I don't see that happening anytime soon. Most of the time they will stick to 10m data (DTED3), although with falling prices and ever more rapid database generation there may actually emerge a trend for sub-meter resolution as the new default, who knows. The good news is, we're prepared for such a trend. And if that doesn't materialize, we can still do interesting things to the terrain procedurally.

[Ingolf]

Aha, so I was not entirely mistaken. I am not a fan of noise overlays as it looks too artificial in my opinion. But each to their own, having the option is perhaps a good idea. Still, at 10m data I would go without the noise. The most interesting algorithm now then is the levelling of the road-/railroadtextures. If that auto-generates roadbanks and cuts into adjacent slopes, it would be truly awesome. I worked on such an algorithm for a personal "tank project" using the CryEngine 4 Sandbox.

 

Good to hear you're ready for the sub-meter data once/if it becomes more of a standard.

Thanks again, Ssnake, for taking the time to still my curiosity.

/Ingolf