Feasibility of improving FC terrain DEM data?

[bruce]

Hello,

 

If any of you guys use FS2004, you're no doubt aware of numerous terrain "mesh" improvements out there. FS2004 terrain addons such as FSGenesis do wonders to improve the terrain detail, dramatically enhancing immersion at any altitude.

 

One thing I've noticed about FC is that, despite it being cutting edge in all areas, it still seems to lack a high resolution terrain mesh. Since the SU25T and the Ka50 (or whichever heli is coming with 1.2) are well-suited to terrain hugging, it strikes me as crucial that the terrain mesh resolution be bumped up a couple notches.

 

So, the question is, can this be done by end users? High resolution mesh of the Crimean peninsula is available, so it's just a matter of figuring out a way to incorporate that data into FC's data files. Anyone know if this is possible, or is the FC terrain engine unable to cope with high resolution mesh? Thanks.

[bruce]

bump .. any comments?

[Dmut]

This is not possible for 3rd parties in current architecture. Terrain data format is closed.

[Ди]

Completely agree it’s necessary to sharply increase the resolution of digital elevation model of a relief. Developers shall do it only in the following (not Lock On) project.

High resolution mesh of the Crimean peninsula is available.

What particularly data format you mean is accessible to Crimea and Caucasus? What vertical and horizontal resolution? What is the source?

90 meters SRTM it is too rough for this purpose, 30 meters is free only for Northern America...

[Guest Amount]

This is not possible for 3rd parties in current architecture. Terrain data format is closed.

 

 

Why not just open it up. Since you guys have the tools to add/edit it. Why not just release the tools to the 3rd parties.

[SwingKid]

Why not just open it up. Since you guys have the tools to add/edit it. Why not just release the tools to the 3rd parties.

 

The "tools" are not documented, stand-alone applications. "3rd parties" must be VC++ programmers, able to modify and re-compile them for each editing task they want to do. If such interested parties really exist, I would be pleasantly surprised to meet them... :)

 

-SK

[Dmut]

SK, you forgot to mention, that this 3rd party team has to spend about 1 year of full-time work to make something like current map in LO. of course, 1 year term is only valid if this team has made such job before. :D

[bruce]

Completely agree it’s necessary to sharply increase the resolution of digital elevation model of a relief. Developers shall do it only in the following (not Lock On) project.

What particularly data format you mean is accessible to Crimea and Caucasus? What vertical and horizontal resolution? What is the source?

90 meters SRTM it is too rough for this purpose, 30 meters is free only for Northern America...

 

FS Global 2005 Terrain Mesh ( http://www.fsglobal2005.com/ ) is a relatively inexpensive (~$60) FS2004 mesh addon which improves the _entire_ globe's mesh to 76m resolution. Their data is based on space shuttle SRTM data. The data is relatively cheap, $80 per CD of SRTM data (although I'd imagine that they have deals for people who purchase bulk data) .. the price is mentioned here http://edc.usgs.gov/srtm/data/obtainingdata.html . Coverage spans the globe, except for the poles.

 

My point is that, unless FC is already using this SRTM data, which I doubt, all they have to do is incorporate this higher res data into the engine in order to secure the longevity of their simulator. It seems like a no brainer to me, especially with the helicopter in the works.

 

The "tools" are not documented, stand-alone applications. "3rd parties" must be VC++ programmers, able to modify and re-compile them for each editing task they want to do. If such interested parties really exist, I would be pleasantly surprised to meet them...

 

-SK

 

I don't quite understand .. is all that is required that the 3rd party developers know VC++? If so, that should be absolutely no problem. Practically every professional programmer out there knows C++ at the very least, and many know VC++.

[bruce]

SK, you forgot to mention, that this 3rd party team has to spend about 1 year of full-time work to make something like current map in LO. of course, 1 year term is only valid if this team has made such job before. :D

 

That's interesting. I would be highly surprised if the terrain data was hardcoded into the engine. It may be that the elevations of every ground object in the game had to be adjusted to conform to the terrain, and this is what took so long. Although, that's the sort of operation which can be automated by a skilled programmer.

[Guest Amount]

That's interesting. I would be highly surprised if the terrain data was hardcoded into the engine. It may be that the elevations of every ground object in the game had to be adjusted to conform to the terrain, and this is what took so long. Although, that's the sort of operation which can be automated by a skilled programmer.

 

It appears they aren't using any kind of heightmap type of data to display terrain, Not sure why anyone would create terrain out of c++ code. Does this mean that the terrain is created on the fly.

 

BTW, I also think they (ED) grossly underestimated the resourcefullness and intelligence of the community.

[SwingKid]

I don't quite understand .. is all that is required that the 3rd party developers know VC++? If so, that should be absolutely no problem. Practically every professional programmer out there knows C++ at the very least, and many know VC++.

 

Do you really think a VC++ programmer has nothing better to do than edit relief for free? If there is absolutely no problem, then please, find such a volunteer. I would be delighted to tell them what to do. :)

 

Too many chiefs, not enough indians...

 

-SK

[Dmut]

That's interesting. I would be highly surprised if the terrain data was hardcoded into the engine. It may be that the elevations of every ground object in the game had to be adjusted to conform to the terrain, and this is what took so long. Although, that's the sort of operation which can be automated by a skilled programmer.

Who says it was hardcoded?

They've store terrain info (and this is not just an elevation data) in binary datafiles. Format of this datafiles is classified, because of commertial value. It wasn't C++ coders, who create and adjust the terrain in LO, but a special small team of GIS professionals.

[SwingKid]

It appears they aren't using any kind of heightmap type of data to display terrain, Not sure why anyone would create terrain out of c++ code. Does this mean that the terrain is created on the fly.

 

BTW, I also think they (ED) grossly underestimated the resourcefullness and intelligence of the community.

 

Ok you guys.

 

With 3 and 4 posts respectively, I don't know who you are or how you can make such conclusions about ED, but I'll give you the benefit of the doubt and a proper introduction, because, anybody interested in the map can't be all bad. Let's start again.

 

My name around here is SwingKid. I am a beta tester, and also a VC++ programmer and self-described Lock On "hacker/modder". I helped to create the NATO airbase modification:

 

http://forum.lockon.ru/showthread.php?t=7097

 

and am working on a dynamic campaign engine:

 

http://lockoncampaign.com:8811/board/index.php?a=forum&f=11

 

...among other little projects. From this experience, I consider myself fairly well familiar with Lock On's map, for somebody outside of Moscow.

 

Frankly, I think Lock On can benefit from many other things, far more than a better relief mesh. With the lua script support I think ED has already done a fantastic job supporting user modifications. The use of text-based .xml files for everything from mission and campaign files to payloads shows they have very high faith in the ability of the user community to make modifications.

 

If I wanted to change the relief, I don't think I would need ED to waste any time "releasing" their messy in-house "tools" code to me. And if I did, having some Russian language ability myself, I certainly wouldn't need English-speakers to ask on my behalf. It would be much, much faster for me to make my own tools, which I would already know how they work and how to manipulate it without any documentation, hack the terrain files and do whatever I want, as I did to move the Razdolnoye airbase. I have no need for another person's tools, but even more so, I have no need for someone else to be telling me what to do. They are my programming skills, I do what I want with them, when I want, how I want.

 

I am writing this to give you the benefit of the doubt. Maybe you are honest, hard-working people with great ideas and talents of your own, who are simply newcomers to this forum and don't know your way around. In that case I would be very happy to co-operate and share what I know or can do in a fair exchange. I also have many ideas about the map:

 

http://forum.lockon.ru/showthread.php?t=6450

 

But if you arrived here looking to form a kind of Peanut Gallery, just throwing criticism at people who can do more than yourselves... well then, no offense, I have other pressures on my time.

 

Regards,

 

-SK

[pappavis]

Who says it was hardcoded?

They've store terrain info (and this is not just an elevation data) in binary datafiles. Format of this datafiles is classified, because of commertial value. It wasn't C++ coders, who create and adjust the terrain in LO, but a special small team of GIS professionals.

 

 

Isnt it somehow, if at all possible to create some programmers API interface or release info about the binary format, so as to allow community hackers to create new terrain?

I know its not easy but ED could extend the lifetime of Lo-mac much more if it can be moddable.. for example: Operation Flashpoint is >=4 years old it still has a huge modding community -- thanx to its scriptinglanguage and that the dev's released an inhouse tool to the community. Now every1 with some common sense can create a vehicle, terrain etc.

 

There are some talented "indians" amongst the lo-mac community who certainly would be extending the lo-mac. Yep, commerical interests, copyright etc etc all come into play :(.

[bruce]

SK:

 

Thanks for the info. It's good to know that it IS possible, we just need some programmers to throw at it.

[SwingKid]

Isnt it somehow, if at all possible to create some programmers API interface or release info about the binary format, so as to allow community hackers to create new terrain?

...

There are some talented "indians" amongst the lo-mac community who certainly would be extending the lo-mac.

 

They made a couple of APIs already. One of them was the Mission Object Model, MOM.dll, for creating missions automatically. In the end, SkyWars does NOT use it, because there were some important things that MOM.dll could not do, and this API was even harder for me to modify, than to create the mission files with my own code. IMHO, the creation of such APIs would not be an effective use of ED's time.

 

Without any APIs and very little help, I was able to hack, decode and understand the .rn, .sup and .scn file formats in less than two weeks. Maybe we could do the same for terrain relief - in a few days, now that I have experience. To create a special API and all the documentation, and to translate it from Russian to English, would not be faster.

 

-SK