EXPANSION OF DEVELOPMENT BASE PERSONNEL THROUGH EDUCATION
-
cough cough cooooough :lol:
-
This post is deleted! -
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 want to put this out here before answering to the entire post:
I agree with your calculations, even though I would like to see them in detail. Here is a suggested workaround on the memory issue:
Bubble: The bubble limit could be used to reference higher detail geometry within it and cruder geometry outside of it. The main problem I see with this approach, is that it probably requires every terrain to be generated twice. Once in crude geometric resolution for objects and terrain beyond the bubble and once for finer mesh geometry inside the limits of the bubble. But I am not sure if this is even doable. In other words, I am speaking out of my a**.
Even if we could come down to 100 or 90m resolution concerning heightmap - which as you pointed out is represented in per foot accuracy through a 2 bytes record per point - Its an order of magnitude in terms of improvement which is huge.
The other thing I am not sure is the following: Does the flight sim load the entire heightmap or just what exists within the bubble? And to be more precise about that, other than LOD what else does the bubble control? If the bubble allows for reading the heightmap within its radius, then we don’t need to worry about the entire heightmap, but rather the extent of the radius of the bubble and the number of heightmap points within it.
P.S. Joe Lambrada and Arty I have not forgotten or ignored you… I will be back in a couple of hours I think. You will be receiving answers and comments.
P.S.2 I was beaten to the punch concerning the bubble and 90~100m resolutuion! Credit DOES NOT go to me.
Enjoy!
-
some motivational tune that screams to move forward, so:
Cheers!!!
-
Well yes… many things sound logical…
I believe this bubble thing was discussed years ago also…
Also never ignore or forget something which is just a simple sentence here, for coding can be an uber multi overkill and a super trooper bug creator…
So yes like opinions we can all have one… Let’s see us do it.
-
Well yes… many things sound logical…
I believe this bubble thing was discussed years ago also…
Also never ignore or forget something which is just a simple sentence here, for coding can be an uber multi overkill and a super trooper bug creator…
So yes like opinions we can all have one… Let’s see us do it.
Would capturing a memory dump of Falcon while being played, display if the heightmap loaded is a region within or directly surrounding (tangent square) the bubble or if its the entire heightmap? I suspect that the exe would either load the whole of it, or whatever the bubble dictates. If that is the case it would be good to know. The other thing is, what happens to e.g. enemies outside the bubble? They exist over a heightmap whether they are missile launchers or scrambling aircraft. Whats good for the viper is good for the Migs.
-
I find myself wondering about the feasibility and benefits of being able to exploit commercially available online satellite imagery and related data (Google Earth, to name the obvious first data source) as a means of being able to generate accurate terrain mapping “on the fly” as it were. While I doubt that Google would permit a flight simulator to hook into Google Earth unfettered and for free, they might allow this if it was made an optional feature requiring a nominal subscription fee.
While G.E. imagery would not automatically give you more targets to strike and avoid, at the very least it could add another layer of realism while flying over terrain
that is not actually populated with targets, troops, items of interest worthy of directly coding into the database, etc.i
NASA WorldWind is for free. No need to pay royalties for using that data to my knowledge but still this should be verified via direct contact and request. The benefits - especially if you can have the heightmap AND the color values with some tweaks and compromises, are that you will “feel” like flying over actual landmarks in the area you are flying. At 90m mesh resolution, you wont be tricking the human eye while on the ground or taxiing, but when flying with 170knots upwards of 3000ft, you won’t be able to tell the difference. Especially for people that are familiar with a certain region, seeing what their mind expects to see will be enough to offer them the illusion of simulation. The rest of us will have to use our imagination initially, and wait for our brains to adjust to what we are seeing.
The brain-eye combination is a tricky combo. It registers things “out of the norm”. So when you adjust to what you see from +3000 ft, then it takes something “violently different” for that to register. What may that be? Usually a very sharp edge (think mountain peak or cliff) but those kind of features are isolated and few in comparison with the dozens of hills surrounding a single mountains peak.
I want to ask other people about all this - people that have actually seen the code and have an idea of the codependencies of what what we are talking about. If someone reading this has hands-on experience please speak up.
-
This post is deleted! -
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
Question: Could the Falcon Editor be created in a segmented manner?
Let me explain. Usually someone wants to mod or improve certain aspects of the game. In some case its the data, in other cases its the code and in other cases its the data and the code.
If someone wanted to develop the terrain, would it be possible to
a. list all the co-dependencies of the code.
b. make a diagram of said dependencies.
c. describe the processes involved in changing certain key areas?It would be like answering the question: “What aspects of the terrain am I able to tweak?”
-
They don’t really exist outside the bubble. That’s where the terms agg’d and de’agged come from, aggregated units are units that are outside the bubble which get combined into a single “parent” unit. So a ground SAM unit turns from a formation of vehicles into just a “ground SAM unit” and not 4 trucks, 3 launchers, etc… Combat is then calculated statistically based on parameters in the DB, and not done in a mock 3D sense. Movement is referenced against the heightmap and paths (Or at least it used to be) but not necessarily in the same fashion as when it gets produced in the 3D world (Presented to the render pipeline). Height map is required for altitude limitations on SAM engagements, ordnance usage during statistical combat, and departure/approach altitude calculations to display AC position on the map, but otherwise not much of a factor outside the 3D environment. At least that’s how it worked in the “old” code, and if you watch the 2D map during a campaign it suggests that it still works more or less in the same way.
And what happens when you are targeted BVR and you hit “view enemy” and the screen shows you an SA-6 turning towards you and getting ready to kebab your sorry ass? The enemy has “materialized” and now exists over a specific portion of the heightmap despite that being outside your bubble. Am I wrong?
-
-
@Joe:
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…?To answer you fully, here are the goals:
1. Make a pipeline that allows us the users to improve the terrain - and other aspects of Falcon, but primarily the terrain - not just now, but also in the future.
2. decrease the mesh size of the 3D geometrical tiles.
3. improve on the texturing AFTER (2). -
Yes,
You’re wrong.
Spend more time learning, than keep this thread alive.Sorry… wasn’t talking to you and I don’t take orders from you either. In case you are ignorant of the fact there are two ways you can learn.
1. Talk with people smarter than yourself.
2. Read books.I will close this comment stressing that you will not dictate or force what manner I choose to learn.
-
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!
Hehe…Got my attention!
-
The problem I see in thinking we are going to get increases in terrain (or any…) resolution is that the overarching architecture of the sim is not currently written to take full advantage of modern/current hardware capabilities. This need for a complete re-write/re-host of the sim to catch up leaves us with limitations and constraints. That’s ok with me, as far as the devs can take it for us…but I have a feeling that things could be reaching a plateau on the eye-candy front.
I can only figure it’s currently a trade-off between functional capabilities and eye-candy at present…personally, I’ll give up the eye candy. And some (if not all) of the non-Viper modeling related capabilities that may be eating up overhead, as far as flying other aircraft “in cockpit” go - thought being that if they aren’t or can’t be as well done as the F-16, then I’m not particularly interested in them anyway. I’d gladly give them up for improvements in AI and RW modeling in the combat environment…if they are getting in the computational way, or serving as distractions.
-
With a 90m*90m Height mesh, to further break the ‘unwanted’ straight lines, could there be an option for the GFX powerful to fill the 90m up with 2,3,5,10 extra random height points, not falling too much out of the line (- meaning from either side of that square)?
By going below 4000 ft, for example?
The general landscape and landmark ‘issue’ would not be bothered by this, but the persuasive trick would be there (looks natural and fast - speed feel).
Thanks for answering.
Torvil -
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.
Interesting, this guy made whole terrain with that “complementary” way.
http://www.jpnvr.com/
According to the website this VR app never uses any satellite nor photo textures but only uses Fundamental Geospatial Data from GSI(The Geospatial Information Authority of Japan).An indie game developer “ICKX” also made a flight game using their terrain engine.
http://www.ickx.jp/product/ickx/cm1_vr -
I’m seriously guessing here, but I’m going to guess that the issue isn’t the GFX but the sheer amount of computational power it takes the CPU (and a limited number of cores) to generate the OTW and the subjects within the OTW…let alone the avionics, weapons (video), AI, etc. modeling. This is where eye candy becomes “overhead”, and where the code shows it’s age, IMO - limited multi-core, no multi/hyper-threading, etc. sorts of capability that would fully leverage an i7 CPU; which we users currently find slick ways around by using multiple machines, assigning core affinities, overclocking, using SSDs to increase throughput (though I’ve had BMS operate very nicely from a 7200 rpm HD on a Mac Mini under Win 7). These are techs that need to be leveraged in order to get current performance from current hardware.
That’s a long, hard chunk of work and effort…and I get that and it tempers my own expectations - MMV. Great job by the devs stretching the limits so far…but I understand there are limits.
-
Most of the current active commercial flight sims… DCS,FSX(P3D),IL-2 also uses limited multi-core, no multi/hyper-threading. That wasn’t changed for years IIRC. Instead, They update their graphic engine more GPU intensive to secure CPU sources.
-
…sounds like the whole biz is due for an update. Most of the 3D modeling/rendering packages I know of use this stuff to shorten render time. I’ll have to do some looking into applications in near realtime processing.