EXPANSION OF DEVELOPMENT BASE PERSONNEL THROUGH EDUCATION
-
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.
-
I have one thing would like to say:
There’s too much irony on this forum, especially from the side of senior member.
Irony works as joke as intended sometime, but otherwise it works as PROVOCATION if such irony is commented to the serious question or something.
Most of the time, it doesn’t work as constructive comment, and it lead someone who wants to learn something seriously to give up, and angry.I’m not going to escalate the debate, so this will be the only post on this thread.
-
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).Thanks for the reply. An ambitious project. I like it.
Je, je … to think that all my work done with the textures of the POH Theater can be obsolete if you achieve your wonderful goal causes me mixed feelings. But if that day comes, although it can be frustrating for theaters developers, the undeniable thing is that we will have an even better simulator: and that is the important thing.
Do not hesitate: if you can do it: do it
I will be attentive to your progress: “Start with difficult work, and the impossible will only take you a little longer.”
-
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.
TorvilI thought of that earlier myself, and I think I-hawk called it “terraforming Falcon” before me, by creating additional terrain objects (3D wedges) that just sit on top of the terrain to trick the human eye in thinking its seeing a higher resolution geometrical mesh. There are considerations though concerning this.
1. How does Falcon read altimeter values?
2. How does it handle collisions with terrain objects?
3. Would this overload the terrain model?
4. Possibly other considerations too…At this point, we need someone with a deeper knowledge of the code and how its been written to provide answers to our queries and I wish we had one at hand to ask all this.
-
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_vrWelcome Chihirobelmo to this endeavour! Are these links about Falcon? Please explain.
-
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.
To replace the terrain portion of Falcon with something that would have as a fundamental capability “the ability to grow” you would need to know all the co-dependencies in the executable. I understand now why Arty suggested earlier at the top of page 9 that the Falcon Editor manual (if such a manual intends to let devs and users alike to reference how the program is structured and what can/cannot be changed) preceeded this effort and he may be right.
What I am suggesting however, is that for the time being we limit ourselves to the chapter of terrain in order to finish a single pipeline and be able to have improvement in one specific area.
Similarly, after that, the next pipeline (e.g. audio) could focus on sound generation concerning said manual.
-
Hmmm all those talks where done in the past.
No working or fisible or devs thought of the Overkill when gain was minimum.Atreides is reinventing the wheel here… But some times looking at something from a different or a fresh angle might result to something good.
About bubbles I wasn’t talking about the ones we know, but about loading to be rendered terrain data.
Another aspect. In the past there where L0 L1 L2…
Why?
All the levels are subsets of L0.
Wouldnt just L0 and an algorithm per altitude level to exclude xy points be maybe better?
A draft example:
L0 has 1000 X lines of points and 1000 Y lines of points. (Random numbers used here).Now when the player enters a different level reduce the XY lines you take in to account. Going higher select even less.
Border lines are not affected of course.
Also I have a low-end PC . Set the high detail level to use same algorithm and instead of 1000 lines take the reduced one.
Textures if 1000 or 600 or 200 or 10 lines are exactly the same. Maybe textures size should be larger to fit the biggest square.Hmmm the math are available like 64 segments theaters… Also the way terrain is rendered.
Still you don’t save the 20gb monster… But ease up the CPU-GPU.sent from my mi5 using Tapatalk