EXPANSION OF DEVELOPMENT BASE PERSONNEL THROUGH EDUCATION
-
For me - my initial goal at least - is “how do we get a better, more detailed terrain that looks less blockish”.
I guess that makes the 2 of us then
Before I start explaining stuff deeper, I’ll tell you 1 thing that you need to know:
3D rendering is (Usually) made of 2 parts, 1) Geometry 2) Textures.
The Textures are mapped into the Geometry.You must know that in order to understand my answers better.
Questions for anyone that is code savvy enough to be able to answer. Take your time with these.
1. Are tiles the only method used by Falcon to create terrain?
In Falcon terrain, the Geometry represents squares of 1KMx1KM and the texturing also goes with that size, i.e every texture tile is stretched over 1KMx1KM of Geometry.
2. For a given area of 1sqkm lets assume that currently 100 tiles are used (10x10 layout). Can falcon scale upwards concerning the number of tiles for the same given area e.g. to a 1sqkm with 10.000 tiles (100x100 layout) or even better 1.000.000 tiles (1000x1000 layout)?
As I stated above, the textures are stretched over a 1KMx1KM world sized mesh.
Now, from a technical POV, yes you can tile as many textures as you want on a single 1KMx1KM, but there are 2 questions to ask here:
1. How long it’ll take the renderer (Let’s assume GPU time only by skipping some technical details) to render such amount of textures on all squares of the Geometry?
2. How much memory you will need in order to load all those tiles and render all in a single frame?Increasing tiling factor does cost memory and GPU time. And if the number of tiles is HUGE then you may also get out of Video memory and things may get REALLY slow. That said, tiling a texture many times is actually a VERY common technique in 3D rendering to texture large meshes, but of course repetition among other issues must be taken into account.
3. What dependencies arise from a change of tile count for a given area as also from a higher detail elevation map to go along with that?
For (textures) tiles I already answered above. Elevation is something else as it is related to the Geometry. The elevation resolution in Falcon is 1KMx1KM which I know is pretty low. Improving that will probably mean to write something new because it’s not just about the tiles size and textures, it’s also related to Z-Fighting (Higher resolution meshes on the current engine represent Z-Fighting issues, if you aren’t sure what Z-Fight is, then I’m sure you can google it :)), view range, rendering time, memory and more.
Bottom line - All Terrains you see on Modern games aren’t just plan meshes of a X-Y grids that are easy to implement, there are some sophisticated Graphics techniques out there for Rendering large terrains.
4. How does Falcon provide elevation for each tile? Or does it use combinations of elevation and tilt per direction?
Elevation comes from the Terrain L2 file, that holds the Heightmap, along with some other stuff.
5. Is there a limit to area of terrain or to number of tiles or number of elevation values that Falcon can handle?
Yes, the current mesh resolution in BMS is 1KMx1KM and the max number of separate tiles is 4096. Those 4096 textures can then be specified in the L2/O2/texture.bin files in order to decide how to actually tile them on the Mesh.
6. Can “maps” be adjoined? In other words for two adjacent maps, is it possible for the user to fly from the one into the other?
No, Falcon theaters are bounded.
7. How is a single tile labeled in Falcon? The proper nomenclature and formatting is important to have, so that work can be segmented.
For this info and a lot of what I explained above you can look here and at other related pages:
http://pmc.editing.wiki/doku.php?id=falcon4:file_formats:theater_l2Cheers!
-
And some forum post stickied in the terrain section, and some forum search for terrain elevation, coordinates, falcon projection etc etc
As said quite often already. The info is there, but you have to dig for it.
Because you won’t get all the facts all at once - if learning to fly BMS is a steep curve, learning to mod it and do it right is even steeper.It requires dedication, commitment on the long term, team work and a pretty basic understanding of you can’t do it on your own.
At least not if you want your work to survive the next BMS version -
1st of all thank you for taking the time to read and start to provide me with some valuable information!
I guess that makes the 2 of us then
Before I start explaining stuff deeper, I’ll tell you 1 thing that you need to know:
3D rendering is (Usually) made of 2 parts, 1) Geometry 2) Textures.
The Textures are mapped into the Geometry.You must know that in order to understand my answers better.
So far so good, as I am familiar with texels and voxels. However the textures - to my understanding - are rendered ONTO the underlying geometry.
In Falcon terrain, the Geometry represents squares of 1KMx1KM and the texturing also goes with that size, i.e every texture tile is stretched over 1KMx1KM of Geometry.
This is a VERY, VERY crude representation of any DTM. But I can’t blame anything since such were the limitations of machines 20+ years ago.
As I stated above, the textures are stretched over a 1KMx1KM world sized mesh.
Now, from a technical POV, yes you can tile as many textures as you want on a single 1KMx1KM, but there are 2 questions to ask here:
1. How long it’ll take the renderer (Let’s assume GPU time only by skipping some technical details) to render such amount of textures on all squares of the Geometry?
2. How much memory you will need in order to load all those tiles and render all in a single frame?Let me make this clear: I don’t want to use the existing 1km tiles. Geometry wise its VERY crude and using several textures on them would only add a memory problem to the existing crude geomentry. I want smaller tiles. I would be quite happy with 1mx1m tiles but since this will require a larger effort than just data collection, I / We / You and Me / Whoever else, need to plan for greater and smaller increments. So… If the minimum “straight edge” is currently 1000m long in the landscape, lets try to make plans for 100m edges, 10m edges and 1m edges I would say that, 1m edges would be adequate for the foreseeable future as I wouldnt expect a 0,1m edge requirement in the near future for any flight sim application… UNLESS we wanted to expand the scope of this project to e.g. driving and or naval simulation (is that possible?). Just laying down ideas… nothing set in stone yet.
Increasing tiling factor does cost memory and GPU time. And if the number of tiles is HUGE then you may also get out of Video memory and things may get REALLY slow. That said, tiling a texture many times is actually a VERY common technique in 3D rendering to texture large meshes, but of course repetition among other issues must be taken into account.
Lets see what limits we have with a finer mesh. I think we need to do some trial and error and experimentation while running a modified version on today’s hardware. I suspect that at the very least we will be able to make an improvement by a factor of 10 and that would be quite significant. But at the same time, I wont be making this pipeline all over again for another similar leap. I guess this falls right now onto you and me and anyone that hopefully will chip in and help us.
For (textures) tiles I already answered above. Elevation is something else as it is related to the Geometry. The elevation resolution in Falcon is 1KMx1KM which I know is pretty low. Improving that will probably mean to write something new because it’s not just about the tiles size and textures, it’s also related to Z-Fighting (Higher resolution meshes on the current engine represent Z-Fighting issues, if you aren’t sure what Z-Fight is, then I’m sure you can google it :)), view range, rendering time, memory and more.
There are several ways to orient a surface. Usually you provide the elevation of the COG (Center Of Gravity) of the tile and after that two cosine values perpendicular to each other that provide you with the tilt of the tile while rotated around the x and y axis (assuming z is elevation).
Another way to do this, is to provide elevation data for all corners of the tile (or as many needed to create defined geometry… in the case of a square or rectangle that would mean three corners).
How the machine is told to orient each tile is important because once you multiply the provided information by e.g. 1.000.000 tiles you get a performance penalty.
We need to know this Hawk.
Bottom line - All Terrains you see on Modern games aren’t just plan meshes of a X-Y grids that are easy to implement, there are some sophisticated Graphics techniques out there for Rendering large terrains.
I would never assume for any game of the last 20 years - unless it was designed to be flat - that its DTM IS flat. The question is what do we have to work with. And this once more relates to the code.
Elevation comes from the Terrain L2 file, that holds the Heightmap, along with some other stuff.
Useful to know. Is the L2 file a csv file kind of deal or does it use its own proprietary format for storing the information? How exactly is X, Y, for each elevation point stored? Are the positions pre-assumed or are they calculated? For instance, if you design a very steep terrain of 100 sqkm, (10x10 1km square) will the orthographic projection of the entire map be 10kmx10km in dimensions or will it be less than 10kmx10km as is expected? I need to know this distinction to account for stretching of each tile or not.
Yes, the current mesh resolution in BMS is 1KMx1KM and the max number of separate tiles is 4096. Those 4096 textures can then be specified in the L2/O2/texture.bin files in order to decide how to actually tile them on the Mesh.
So, for a square map layout we are limited to 64x64 1km tiles, each one with its own texture information.
1. Can we have a finer mesh? Tiles of 100x100m, tiles of 10x10m and finally tiles of 1x1m.
2. How much memory do we need for our ultimate goal of 1m resolution? Even at the 1m level we would still be using textures for each tile, and even if todays machines can’t handle this detail (assuming the software permits it or can permit it) then in the future we can have it.
3. Would the core dev team be able to provide us with a modified version for each of the above 3 iterations? 100x100, 10x10, 1x1?
4. Are there limitations on the file size of the above mentioned files (L2, O2, other)?No, Falcon theaters are bounded.
Which leads us to the next question for the core dev team:
Can we have larger theaters in terms of size?For this info and a lot of what I explained above you can look here and at other related pages:
http://pmc.editing.wiki/doku.php?id=falcon4:file_formats:theater_l2Cheers!
Thanks for taking the time I-Hawk!
-
Is there a way to import terrains from other 3D modeling packages like Bryce, Terragen, or Blender?
Or to build from RW DTED data?..which I think I might know how to do, using one or more of these packages. Others might also. Terragen in particular is capable of producing some stunning scenery.
-
Is there a way to import terrains from other 3D modeling packages like Bryce, Terragen, or Blender?
Or to build from RW DTED data?..which I think I might know how to do, using one or more of these packages. Others might also. Terragen in particular is capable of producing some stunning scenery.
I read the link that I-Hawk attached above. I suggest you do the same. In brief it says that the relative files in which elevation information is stored, is of a proprietary format, and I am guessing it is linked in with the executable. The question is in what way and in how many different places in the code.
All those great open source DTM programs generate wonderful terrain because they allow you to control the fidelity of it. Once you opt for a crude fidelity your results would be the same as the terrain in Falcon that we seem to be stuck with.
Lets assume that someone that is in the core dev. team can produce a fork for experimentation. One that allows files with a finer mesh than the crude 64x64 1sqkm tiles be produced. In that case, importing data is merely a matter of translating the values into the relative text entries that the file reads. That you could do even with an excel sheet or very basic programming skills (VB, Basic etc).
I will openly ask the core dev team - hoping that someone is reading this - if such a fork would be possible. I am not sure if an attempt at that has already been made, so maybe I-Hawk can answer me on this. He seems to have been tackling this problem longer than me, but I am not sure if he ever pursued the option of a code fork… one that allows much more detailed tiles to be generated.
If the initial values are 64x64 tiles of 1sqkm each, then the math goes as follows:
for a 100x100m setup of the exact same area, we would need 640x640 tiles of 0,01sqkm each.
for a 10x10m setup of the exact same area, we would need 6400x6400 tiles of 0,0001sqkm each.
for a 1x1m setup of the exact same area, we would need 64000x64000 tiles of 0,000001sqkm each.At a 1m resolution, the terrain would be nothing short of real life representation.
If we could PLAN for this kind of code mod per iteration, then we would have a growth pattern and therefore we would incorporate the code changes in a timely fashion into the pipeline.
We still strive to get every 3D object for our terrain at the highest possible detail initially and simplify per iteration / version of terrain model. After all, even current high-end graphics cards have limits. But before deciding “just how detailed do we want a vehicle to appear in the sim” we need to get out of the way our terrain.
We shall see what the core dev team has to say about this. I am not knowledgeable enough to answer myself. So if you are reading this and you have the answers, please help us.
There is one more possibility… One that I am not sure if it has been outruled entirely. If we could scale down AND expand it would be the equivalent of adding tiles to the map.
Let me explain:
Right now you take off and fly over a 64x64 km map. If we scaled it down by a factor of ten [initially shrinking the playable area to a 6,4x6,4 sqkm area] AND [boolean AND that one] expanded the playable area by adding tiles to it [e.g. 4 times the ammount of tiles] then you would have a playing area with a fidelity of 100x100sqm tiles 1/5 the size of the original map. I-Hawk in his previous comment said that the maps are bound and that we cannot attach one map to another. I don’t mind the map being bound as long as I can increase its size. I will wait for his clarifications on this.
-
@Cloud:
With that said, there are some fine young people here that have the desire, drive and commitment to learn a lot of stuff by themselves, but they are few and far between compared to the “entitlement” crowd.
C9. When I read your posts on this topic, you go back to how much effort you have had to put into being a useful contributor. I certainly respect everyone that has put a ton of time and effort into learning so much of this stuff. But BMS could very well organize this with liaisons and utilize volunteers to take tiny pieces of all of this. One 3D pit instructor could offer a class on building a pit. That class might take, I don’t know 6 months or so, I don’t know how difficult it is to learn this stuff. But after the class, you’d have say maybe 40% of the students willing to go on and build pits to give to BMS (or to someone that could build an interface for the pits from the project into BMS). Now, if BMS worked with such a project, I think you’d get the volunteers because the volunteers would know that BMS is planning to incorporate the work and it won’t be a total waste of people’s time.
That’s not being spoon-fed, stupid, or needy necessarily. That looks to me like people being risk adverse and wanting to leverage each other’s work. Most of us have been around long enough to see tech evolve and change making stuff obsolete. No one would want to build a pit only to find out it’s completely useless 2 months after completion. Lots of folks get excited about being part of a group project because they feel like they have the time to do a little but maybe not a ton. But they really want to see the whole project completed and have a shelf life. So that type of person is looking to see that the project is actually going to be seen through to the conclusion and at that point will jump in and do 1 cockpit so they can see 10 cockpits done. If that project goes reasonably well and is supported by BMS and experts, they might be in for the next project (doing various blocks of the same airframe for example). Again, to me that’s just analyzing the effort from a risk/reward perspective.
And I worry about this idea that someone needs to know and delve into everything about BMS in order to contribute. I don’t think that’s how airplane manufacturer’s approach their process. Your structural guy might not know diddly about engines except how much they weigh and how much thrust they produce so he can figure on how much stress the frame will take. But the structural guy and the engine guys really need someone to be in charge to work out the differences and make sure the pieces fit when done. So I see specialization and cooperation as perfectly natural ways to solve problems. Some folks will have knowledge that bridges several systems and some will just know a piece of the puzzle, but lots of hands can lead to lighter work so long as there is a plan for organizing it and people buy into the plan.
-
Reply to Vandal.
While engineering disciplines are separate when making something such as an airplane, there is always interface knowledge involved.
For instance, the structural guy wont know much more other than the type of engines possibly used in an airframe (piston, turboprop, turbojet of whatever bypass, etc) but their teachers will include oscillation stress in the curriculum so that they can handle the vibrations generated, as also [maybe, not sure] computational heat transfer to deal with the generated heat. They will also be told to make sections with cutouts because everyone and their mother needs to pass networks between sections (plumbing, electical, actuators, cables in older or cheaper designs etc).
Conversely, the mech. engineer that designs turbines knows the basics of structural work but he too will be told how many mounting points to include, what to expect from an airframe and he will design his turbine within limits that are safe for the structure.
When engineering pushes the limits of everything (a good example is the SR-71) then the overlapping of disciplines becomes even greater… For example the fuel of the SR-71 (JP-4 if I remember correctly) was used not only as fuel, but also as a coolant for the overheating airframe as also for the hydraulics… And this was decided to save weight! The damn thing doesn’t even ignite without a catalyst.
So, some times work is straightforward… other times there are overlapping considerations… and other times it becomes a clusterf***.
Software engineering is a beast on its own. As I-Hawk already stated - and this is very true - everything breaks down into two big buckets. Code and data. Code is the brains. Data is what the brain feeds on to give you Falcon 4.33.
Unfortunately, the program was written 20+ years ago. And limitations exist in that brain. Its like “designing” a human brain in the 1990s and accounting for it to remember 4096 tiles it will be juggling with while you and I play the sim. 20 years down the road we need more tiles and that wasn’t accounted for because back then they never even dreamed - and obviously didnt plan either - for more than 4096 tiles.
-
I-Hawk I have a workaround!
Its crude, but hear me out:
IF the code cannot be altered to support more than 4096 tiles, then we can do the following tricks:
1. This is limited, but we can make maps that are less “square” and more “rectangular” to increase fidelity. I personally see little gain to this approach and I don’t like it.
2. We “add on top of the existing terrain” additional terrain in the form of terrain objects. The only limitation we have is on top of each square km, the seams must meet. At 170+ knots you wont care much about a collision if it is a few feet off. Consider this trick like “caking” someone with mud. The initial skin of the model is the 4096 grid limitation. The “mud” we use to add fidelity to the landscape on top of the “skin” is the terrain objects.
3. We zeroize the 4096 tiles flat to reduce processing demands and design terrain objects (an entire map in fact of whatever complexity we choose) on top of them. However, I am not sure how altimeter, elevation etc would work.
4. We zeroize the 4096 tiles, but we also scale them up so that e.g. each tile represents 10x10 km 100sqkm. And on top of each tile we create our own terrain objects.
None of these solutions are as elegant as in changing the code to support more than just 4096 tiles.
Please get back to me concerning these possible workarounds. Also, read this conversation if you get around to it (http://www.pmctactical.org/forum/viewtopic.php?t=21198). It says that the limit is the sets of the tiles… 16 tiles per set times 255 sets and that the limitation exists on the utilities - that he already modified - rather than with Falcon.
-
I read the link that I-Hawk attached above. I suggest you do the same. In brief it says that the relative files in which elevation information is stored, is of a proprietary format, and I am guessing it is linked in with the executable. The question is in what way and in how many different places in the code.
All those great open source DTM programs generate wonderful terrain because they allow you to control the fidelity of it. Once you opt for a crude fidelity your results would be the same as the terrain in Falcon that we seem to be stuck with.
Lets assume that someone that is in the core dev. team can produce a fork for experimentation. One that allows files with a finer mesh than the crude 64x64 1sqkm tiles be produced. In that case, importing data is merely a matter of translating the values into the relative text entries that the file reads. That you could do even with an excel sheet or very basic programming skills (VB, Basic etc).
I will openly ask the core dev team - hoping that someone is reading this - if such a fork would be possible. I am not sure if an attempt at that has already been made, so maybe I-Hawk can answer me on this. He seems to have been tackling this problem longer than me, but I am not sure if he ever pursued the option of a code fork… one that allows much more detailed tiles to be generated.
If the initial values are 64x64 tiles of 1sqkm each, then the math goes as follows:
for a 100x100m setup of the exact same area, we would need 640x640 tiles of 0,01sqkm each.
for a 10x10m setup of the exact same area, we would need 6400x6400 tiles of 0,0001sqkm each.
for a 1x1m setup of the exact same area, we would need 64000x64000 tiles of 0,000001sqkm each.At a 1m resolution, the terrain would be nothing short of real life representation.
If we could PLAN for this kind of code mod per iteration, then we would have a growth pattern and therefore we would incorporate the code changes in a timely fashion into the pipeline.
We still strive to get every 3D object for our terrain at the highest possible detail initially and simplify per iteration / version of terrain model. After all, even current high-end graphics cards have limits. But before deciding “just how detailed do we want a vehicle to appear in the sim” we need to get out of the way our terrain.
We shall see what the core dev team has to say about this. I am not knowledgeable enough to answer myself. So if you are reading this and you have the answers, please help us.
There is one more possibility… One that I am not sure if it has been outruled entirely. If we could scale down AND expand it would be the equivalent of adding tiles to the map.
Let me explain:
Right now you take off and fly over a 64x64 km map. If we scaled it down by a factor of ten [initially shrinking the playable area to a 6,4x6,4 sqkm area] AND [boolean AND that one] expanded the playable area by adding tiles to it [e.g. 4 times the ammount of tiles] then you would have a playing area with a fidelity of 100x100sqm tiles 1/5 the size of the original map. I-Hawk in his previous comment said that the maps are bound and that we cannot attach one map to another. I don’t mind the map being bound as long as I can increase its size. I will wait for his clarifications on this.
This is just the sort of thing I was getting at when I said I’d like to see a document - some sort of standard and/or tools for doing just the above; and detailing the hard BMS requirements. I should think if we could get a detailed standard document that even 3rd parties could develop such tools…it’s really just about mapping and matching 3D formats, as you suggest. For my suggested “flatland theater” starting tool I’d even be satisfied with one standard “blank” tile - and knowing that a full theater is X by Y tiles, and what limitations BMS may impose. Then it would be up to me (or someone) to build on/from/with that. I don’t mind BMS “crudifying” my Terragen terrains, but if it’s easier to use that (or any other) 3D tool to build tiles then I’d like to be able to use a standard 3D tool to do that - and to be able to share my work because of having used a standard tool.
I’m still surprised there isn’t a single, consolidated thread on this subject. But alas…I also have a strong feeling there’s more keeping all this info this scattered at FL 360 than we’re privy to…
-
Aetrides:
Understood.
Of course any summary description of the cooperative process will itself be oversimplified, but yeah the main point that I am trying to make is that you can have a really great team without everyone knowing everything about everything or even a grunt being a bona fide expert in any one thing. As long as you organize and lead it well you’ll end up with a lot work getting done that you would not be able to get done in a timely fashion otherwise.
-
Atreides there is a waaaay waaay easier way to do what you describe which gave me a headache to get it.
Just use one and the same tile.
The structure can remain the same.
U r talking of what I call Falcon Terraforming.
Put huge 3d objects and cities on top of terrain. Then underneath tiles are not needed.
Just don’t tile them or tile them with the same tile texture.
The thing is codewise how LOS Line of sight will work TFR and AI or autopilot not go straight in cause still calculates the old terrain.
To your knowledge this is already done by a few members here and on different theaters.
The tiles gain aint saving the day I have to say, unless you terraform the hell out of it.
-
In my opinion, just a note:
- In reference to How to improve the visual aspect of Falcon? Joe 2012
-BAZT (or high-resolution terrain mapping) with the topographic resolution of the old theater.L0 (100m) as a visual reference to all distances when the power of the PCs allow to manage it.
-Using more than 4096 textures when the power of the PCs allow it to manage (post Joe 2011 year testing the possibility).Only with these two elements could be made great improvements that would involve improving two aspects of the terrain: topography and patterns of repetition.
- In reference to the learning curve of a developer (I can only speak of theaters):
-All the information needed to create a theater is available and public. And today more than ever there is more information available than ever before (BMS forums, PMC forums, wiki) by Snakeman
-The necessary tools are available and have tutorials
http://www.pmctactical.org/f4/downloads.php by PMC TFW (
http://www.weapondeliveryplanner.nl/ by Falcas
http://sakgiok.gr/ by Monster
-In the forums there are many topics that give very useful answers and mark standards, links to youtube (Demer blog, Arty blog), and pdf with procedures (e.g. how create a airbase by Cannon), etc.- And the most important, and I take the opportunity to express my gratitude to all of them: in these forums there are many people, gurus, developers, experts …. friends !!! Who will not hesitate to help you in difficult times. That help is free, monetarily speaking, but I have to earn that right; That is to say: I have to work hard; I have to make progress; I have to show commitment; I have to learn, to search, to inquire, to read, to prove, to make mistakes … And then, only then: I will ask for help.
-
Also let’s not forget the missing Falcon Editor and Mission commander manuals.
Writing the first will answer and shed enormous light on the theater development.
Community can write it and devs kick in when needed by asking them.sent from my mi5 using Tapatalk
-
Also let’s not forget the missing Falcon Editor and Mission commander manuals.
BINGO
and IMHO the reason it wasn’t done yet (for MC at least) is the fact that this wonderful piece of software is still being updated monthly in development
-
@Joe:
In my opinion, just a note:
- In reference to How to improve the visual aspect of Falcon? Joe 2012
-BAZT (or high-resolution terrain mapping) with the topographic resolution of the old theater.L0 (100m) as a visual reference to all distances when the power of the PCs allow to manage it.
-Using more than 4096 textures when the power of the PCs allow it to manage (post Joe 2011 year testing the possibility).Only with these two elements could be made great improvements that would involve improving two aspects of the terrain: topography and patterns of repetition.
- In reference to the learning curve of a developer (I can only speak of theaters):
-All the information needed to create a theater is available and public. And today more than ever there is more information available than ever before (BMS forums, PMC forums, wiki) by Snakeman
-The necessary tools are available and have tutorials
http://www.pmctactical.org/f4/downloads.php by PMC TFW (
http://www.weapondeliveryplanner.nl/ by Falcas
http://sakgiok.gr/ by Monster
-In the forums there are many topics that give very useful answers and mark standards, links to youtube (Demer blog, Arty blog), and pdf with procedures (e.g. how create a airbase by Cannon), etc.- And the most important, and I take the opportunity to express my gratitude to all of them: in these forums there are many people, gurus, developers, experts …. friends !!! Who will not hesitate to help you in difficult times. That help is free, monetarily speaking, but I have to earn that right; That is to say: I have to work hard; I have to make progress; I have to show commitment; I have to learn, to search, to inquire, to read, to prove, to make mistakes … And then, only then: I will ask for help.
Thanks for joining in Joe!
So far, what I am reading starting from the link I offered earlier in my posts on this page towards I-Hawk (20:29 timestamp), snake man came up with a method that he holds “close to his heart” to say the least, and on top of that, he remains sceptical towards BMS. Perhaps what I was reading is old, or maybe not up to date.
Tile textures are fine can be used extensively, but if your underlying geometry is just a flat slab or it comprises of edges 1000m long, you wont be fooling the human eye… unless that eye is in orbit!
The 1st goal that needs to be pursued in my opinion is a finer geometrical mesh. So far in my reading, what I am hearing is that an order of magnitude (going from 1000x1000m geometrical tiles to 100x100m geometrical tiles) improvement is out of the question because of memory constraints. I hope I am wrong in this. But eventually someone has to plan a push forward all the way down to 1x1m resolution. The hardware is improving, but this specific portion of the software has been left behind.
What I am talking about is not a matter of modding the existing terrain. Its a code based intervention to bring in a finer geometrical mesh. Again, so far in my reading and if I recall correctly, a user (bald eagle) said that the problem is not with the software its self, but with the tools that generate the terrain (TerrainView, SPTinstall, Pathmaker) that he modified to a version 1.55 and put them up for use. Even though I have downloaded them, I haven’t had a chance to test them yet.
10 years ago, a similar effort was made to incorporate SRTM data into the landscape of the Israel theater, being produced at the time. I haven’t had the time to go into the details of that endeavor, but I will be looking into it. If you have an opinion on everything I am mentioning right here I would be glad to hear it. If you know who I should be talking to, I would appreciate it if you set me off in the right direction.
Again, thanks for participating.
-
From my limited knowledge and partial vision of a project as immense and complex as Falcon BMS I think we are talking about a great puzzle where many elements depend on each other. And even more a puzzle where there are pieces that can move without problems, there are pieces that can not move … and there are pieces that when moved affect the rest of pieces and create a cascade effect that converts, in practice, into untouchables .
That interrelation will occur in many sections, but in the case of terrain, with a simplistic vision like mine could say:
- The textures of 1kmx1km are placed in the mesh of theater.L2 / O2
- The L2 / O2 mesh is related to the texture.bin file
- The texture.bin file determines the roads, roads, rivers, water through which troops can move or stop. Texture.bin also determines the type of “plain” terrain on which airports can be placed where an airplane can land (if it will not explode upon touching the ground).
- The paths and areas of texture.bin are taken into account when placing objects (cities, airports, … etc) …
- And the placement of objectives and their relationship between them depends on the smooth operation of the missions or campaigns: campaigns that exceed in their dynamic capacity to the most modern and current simulators.
… and that’s just the tip of the iceberg.
Atreides,
Due to my limited knowledge of English and the use of translators, I lose a lot of information in this particular thread. I apologize.I have not finished understanding,
What is the specific project you are working on? Theater, modding, textures, objects 3d…? -
I have a tool that creates fine manuals as for structure by the program.
It’s called Doctor Explain and it’s considered one of the top in it’s class. I use it for years now at work and managed to release a few manuals.With this tool it can be done that the manual be integrated in the app by using keys that will have to be active and usable in the code. That way it can be done like mouse over a field or button and a balloon can popup with a link or info.
The result can be auto made as html chm or pdf. So it could be online for everyone to use it.
But the thing aint the tool but free time and will to accomplish such project.It’s a vast project. Sure I can start it and I consider it very seriously for long time now but for sure I don’t have the time to keep a standard pace on it nor have all the knowledge as to be a no questions unanswered manual.
I will need help from many guys here in the community and for sure from the dev’s.
Additions and updates will always be, the thing - issue is at least be provided some comments or a few text lines what the newcomer does or is for.
-
Hi Atreides,
Since you touched a lot of stuff in your above posts since my last one, I’ll try to answer the main 2 points which I see as a key factors:
1. Geometry/Mesh - You (And by “You” I mean everyone) must understand that there is a quite tight limits to what you can render in terms of resolution.
Let’s go directly to the numbers because eventually everything is about numbers and measurements.Bottom line you have a grid of size X^2 (Let’s consider a complete square always) that represents the heightmap. Currently the size of the grid is very small, we have a point for every 1KM of world size, i.e 1024x1024 for an entire 64-segment theater which turns to 1MB for the number of components. Now, if you take 2 bytes for describing elevation (2 bytes are enough since you have 65,536 values to deal with, enough to describe feet size) you have 2MB of Heightmap data for the entire theater That’s nothing, right? Right.
But now try to go higher res - Let’s see, going down from 1KM per point to 100m, increase the resolution by a factor of 100 right? so ~200MB size of heightmap, that’s still doable right? Now think higher, let’s go to 10m resolution, that’s another 100 factor, that already takes us to 20GB size of heightmap… that’s already not doable, now go down to 1m resolution and you get the idea…If you wonder what I mean by “Not doable” you need to bear in mind that the Heightmap (or parts of it at times) MUST be kept in system memory in order to be able to calculate physics (Ground intersection, LOS etc) because in oppose to some nice scenery app, this is a flight simulator and we need also physics in order to simulate correctly ground intersections and vehicles/objects stationing and movement.
So, I’m sorry to disappoint you, but I doubt we will go higher res than the 90m SRTM resolution for the Heightmap. That’s more or less the only sane size for a Heightmap currently (30m SRTM will already require ~2GB of Heightmap size, which is too much, even for system memory to keep and access), at least for now. But think on the bright size - ~90m Resolution means that for every square in the Falcon current terrain you will have ~120 more points, that’s quite a lot for a jet flight sim (Think DCS at some areas still use 250m heightmap Resolution, at least AFAIK)
Now - Consider also the Rendering aspect - Assume that we don’t want today’s Falcon short view range of 30-35NM right? But we want something much further, say 100NM? So think how many tris you need to render a mesh that is ~100NM in size. Let’s do fast math and for the sake of calculation let’s take 200KM and let’s bump the measured resolution up to 100m (That should match ~same as 100NM with 90m Resolution) - Let’s see what we have:
200KM / 100m = 2000, that is the grid size.
Now in order to render the grid you need to render 2000x2000 = 4M quads, every quad is 2 tris --> 8M triangles. Now, I can tell that 8M tris isn’t such a huge size, but OTOH it’s not so practical, for the terrain alone.So if we sum it all up, there are 2 areas here actually that need to be taken care of from Geometry/Mesh perspective:
1. Heightmap size - Sane size that will be sampled in real time for rendering and physics - Say 90m SRTM resolution for now.
2. Rendered terrain grid size - Assuming 100NM view range and same resolution at least as the Heightmap - 8M tris –> Not so practical, requires something sophisticated.Example from the web of some advanced rendering technique (This specifically is procedural terrain but the rendering won’t be different for Heightmap based terrain):
2. Texturing/Filling - IMHO expecting stuff like RL images isn’t so practical, why? Mainly because satellite images are probably not so high res and while they may look good from high altitude, when you go low you’ll see the pixelized look of those textures.
What is the alternative then? More sophisticated and modern stuff like Multi-texturing can be used to create different look of the land from relatively low number of unique textures. Examples of Multi-textured terrain?
Think now that using more detailed textures with better blending, you can create many “looks” of terrain.
And the complementary part of using such “Generic” texturing may be filling the terrain with objects - Eventually a forest is made of green trees/bushes that are placed on brown land right? so you can simulate a forest by painting some green tile on the land with texturing that reminds trees when you fly over it, or you can use a “Generic” brown/gray land texture and put 2D/3D/ trees/bushes on it.
Cheers!
-
I Hawk what about our beloved bubbles?
can’t the same procedure be used on what u wrote so that only affected areas are calculated - loaded?ok u have some xxxtris resulting to some 20gb of heightmap…
but you don’t see or need all of them at the same time.
maybe what 20% of a whole theater is used when TE’s are engaged and 50-60% when campaigns kick in? -
So, I’m sorry to disappoint you, but I doubt we will go higher res than the 90m SRTM resolution for the Heightmap.
Cheers!
This one line should excite a huge majority of Falconeers on it’s own. A massive step up in terms of terrain resolution which would be extremely welcome. 3-4 weeks will be fine…
Cheers!