EXPANSION OF DEVELOPMENT BASE PERSONNEL THROUGH EDUCATION
-
Sounds Tagman (?)
Atreides, you do not understand what I mean. Could also be my bad english, I failed to make you understand my point. Whatever.
Feel free to try to improve everything you want … no prob with this. Wish you all the best and good luck as everyone will enjoy it at the end.
Cheers.
Take your time to write down things in a manner that I will understand Dee-Jay. I don’t even know you to be hostile or offensive towards you. As I mentioned on earlier posts, the BMS team - and since you are on it you are included in this - deserve credit for everything that you have done for us… and that we enjoy for free.
How am I supposed to know who is on the Dev. team is my question, but anyway.
Lets focus on the Tac-Ref since its a fairly easy thing to improve.
Here are my ideas on it:
Someone earlier suggested a pdf version. Not entirely a bad idea, but I prefer it to be an integral part of the game for the following reasons:
1. The tac-ref 3D models will be used in the game regardless.
2. Its more convenient to have a “one-stop-shopping experience” than opening a separate PDF file as you would with the manual.You mentioned that the data is outdated.
Perhaps some weapon systems have received upgrades since their introduction - as they usually do - so the information per version(s) participating in the game needs to be researched and collected. That is one thing.
The other thing is what kind of information will you make available to the end user? Technical specifications, capabilities, limits etc is the one side of weapon systems. The other is doctrine. How is it used? Tactics? Interoperability with other assets. Do you have any ideas on where to source that data? If its on-line then all that we need is either consent to copy-paste it or in a worst case scenario, we need to re-write everything. In the later case, the question is “what do you focus on, what do you keep and what do you leave out”?
Another approach is asking an active duty pilot what information they are presented with concerning other weapon systems. That would allow a realistic focus of the Tac-ref in the direction of the actual simulation, unless its useful for one reason or another to include information outside that field.
I hope I have set you up well enough to continue your thoughts on this.
QUESTION: Is there a member list somewhere on the forum for looking them up?
QUESTION 2: Is it Tomcatz1988? -
Atreides I didn’t say u wanted to lead somewhere. I just stated that with lack of basic knowledge you can’t lead or manager the effort. And now that I think of it you can’t even have a holistic view to propose something.
U must have deep knowledge.
Sure your general idea is very correct regardless what BMS developers say.
You (all not just Atreides) got in details of the leaf of a three and you don’t see the forest.sent from my mi5 using Tapatalk
-
Atreides I didn’t say u wanted to lead somewhere. I just stated that with lack of basic knowledge you can’t lead or manager the effort. And now that I think of it you can’t even have a holistic view to propose something.
U must have deep knowledge.
Sure your general idea is very correct regardless what BMS developers say.
You (all not just Atreides) got in details of the leaf of a three and you don’t see the forest.sent from my mi5 using Tapatalk
And that is why I believe that the core dev team needs to initiate this thing. I agree about not knowing the limitations imposed as also the capabilities of the software. But to be quite honest - like many others in here from what I can tell already - if the core dev. team doesn’t want to contribute I will try to OPENLY try to find out what those limitations are. If we don’t take that into account we might as well do nothing since there is no guarantee that the end goals will be met.
e.g.
Will it be expandable?
Would it be possible to connect adjacent maps into a larger one?
In what way(s) would future improvement take place? etcAll these questions adhere to scope. Without it, I / You / We would be flying blind. Its the very same reason why I said that at least ONE person needs to be told what needs to be done from beginning to end. After that, there can be contribution. But not without a plan that includes growth, expansion, scope, improvement.
P.S. The invitations have been sent out (Today, 12:47) to Joe Labrada, Earlybite and Tomcatz to voice their opinions in this thread.
-
In another thread there was a nice expression said by a member. Development debt.
This is also a nice example of this debt… Actually it is the most important from the community devs side.
BMS devs straggle to reduce the core debt… So no time or resources for the community devs.
From time to time the spaghetti is passing to the community.
Bits of info scattered all over.
Sure if devs started a wiki and instead of answering here answer to the wiki and link as an answer some pieces of the puzzle would be already there.
But someone must create and maintain this platform we can’t ask from the devs to do that too.sent from my mi5 using Tapatalk
-
Hi Atreides,
I didn’t read all what you posted in this thread because it’s honestly too much and I don’t have the time, but hopefully I’m getting what you are trying to say.
OTOH, I’ll try to tell you how things are working in Falcon land, since ever. Falcon world is globally divided to 2 main parts:
1. Code –> Everything that is part of the EXE, and since we also have shaders for GFX for sometime now, that also includes shaders. In other words anything that you can’t really “crack” or “Reverse Engineer”.
2. Data --> Everything elseI think that’s a place to start for you, so you can understand what’s going on (I’m assuming, mainly from your post-count, but not only, that you are new here…)
Now, think this way:
BMS team holds the source code and keeps developing it to all kind of directions and areas. There are many areas in the sim, and if we look at it, I can put a short list of headlines - GFX, Avionics, Sounds, Physics, Network UI etc etc. Going into a more detailed list I can write - 3D models, Special effects, Avionics, Multiplayer and 2D/3D worlds, Terrain, Weather, Comms etc etc…What’s my point? That no matter how you turn it around, it all eventually sums up to code & data. I like to think that 90% of the serious guys that hanging around here for a couple of years now, will have the ability to tell you what you can do alone and what you can’t do because you need code support for.
So, Now my turn to ask:
What kind of process you try to search here that isn’t already known or been discussed to death during the years?Because… Dude, Falcon is OLD, older than most of us here, Hell when I found there is a Falcon forum it was at 2003, and the sim was already ~5 years old! People already were messing with it back then and some of them knew on some areas more than we know even today. So sorry to disappoint you but there is no “new process to start” here, because almost everything is known already.
But, at the same time I can say that there is an infinite work to do, so if someone is REALLY looking to help, then you can start right away. I’ll start from the most needed stuff:
- We have at any given moment 100s of 3D models that needs updating.
- We probably have many textures in the DB that could use some love.
- As it was mentioned already, Tacref requires some work.
And I’m sure there are many many more. So, if someone wants to really help? You can start picking anything and start work. There are guides to do almost everything and I’m sure we have experts that can help with anything. I never remember even once that someone was screaming about some area and we didn’t checked it (Yes there is stuff which takes us time to check, and also there is stuff which cannot be changed/fixed although people may think it’s all easy…)
So, the path is right there, one just need to choose what he wants to do and start chasing that.
Cheers!
-
Hi Atreides,
I didn’t read all what you posted in this thread because it’s honestly too much and I don’t have the time, but hopefully I’m getting what you are trying to say.
OTOH, I’ll try to tell you how things are working in Falcon land, since ever. Falcon world is globally divided to 2 main parts:
1. Code –> Everything that is part of the EXE, and since we also have shaders for GFX for sometime now, that also includes shaders. In other words anything that you can’t really “crack” or “Reverse Engineer”.
2. Data --> Everything elseI think that’s a place to start for you, so you can understand what’s going on (I’m assuming, mainly from your post-count, but not only, that you are new here…)
Now, think this way:
BMS team holds the source code and keeps developing it to all kind of directions and areas. There are many areas in the sim, and if we look at it, I can put a short list of headlines - GFX, Avionics, Sounds, Physics, Network UI etc etc. Going into a more detailed list I can write - 3D models, Special effects, Avionics, Multiplayer and 2D/3D worlds, Terrain, Weather, Comms etc etc…What’s my point? That no matter how you turn it around, it all eventually sums up to code & data. I like to think that 90% of the serious guys that hanging around here for a couple of years now, will have the ability to tell you what you can do alone and what you can’t do because you need code support for.
So, Now my turn to ask:
What kind of process you try to search here that isn’t already known or been discussed to death during the years?Because… Dude, Falcon is OLD, older than most of us here, Hell when I found there is a Falcon forum it was at 2003, and the sim was already ~5 years old! People already were messing with it back then and some of them knew on some areas more than we know even today. So sorry to disappoint you but there is no “new process to start” here, because almost everything is known already.
But, at the same time I can say that there is an infinite work to do, so if someone is REALLY looking to help, then you can start right away. I’ll start from the most needed stuff:
- We have at any given moment 100s of 3D models that needs updating.
- We probably have many textures in the DB that could use some love.
- As it was mentioned already, Tacref requires some work.
And I’m sure there are many many more. So, if someone wants to really help? You can start picking anything and start work. There are guides to do almost everything and I’m sure we have experts that can help with anything. I never remember even once that someone was screaming about some area and we didn’t checked it (Yes there is stuff which takes us time to check, and also there is stuff which cannot be changed/fixed although people may think it’s all easy…)
So, the path is right there, one just need to choose what he wants to do and start chasing that.
Cheers!
Thanks for taking the time to reply and clarify certain issues.
Let me simplify things for you so we can focus on what I am presenting:
For me - my initial goal at least - is “how do we get a better, more detailed terrain that looks less blockish”.
Realizing that it requires alot of work to be done… much more than a single person would be able to handle - this turned into PIPELINES: If pipelines were created that allowed the community to contribute productively (not in a disorganized and overlapping manner) then at least that portion of the problem is resolved.
The problem with setting up the pipelines is that the non programming savvy that have no idea concerning the limitations and capabilities of the engine, can’t say what can be done to go after it. This includes me.
That is why I have insisted that the initiative of setting up such a pipeline in which the average Joe is given a way to contribute, either falls on the shoulders of the current core dev. team, or someone else that will try to get all that information into one place, figure out “the how” along with the goals, verify everything before doing it himself once while creating educational resources (video? pdf?) to train other members, and then set the whole thing in motion.
That is what I think. Perhaps you have a different opinion. Or perhaps you feel that the terrain is just fine (while clearly I feel its the portion that needs the most attention… certainly not the tac-ref which is not even directly involved while flying the sim).
I pretty much figured out by myself that “code” imposes the inherent limitations to what can be done concerning the environment. So - if you share the same or similar views with me - I invite you to educate me concerning those limitations. What can be done. What is Falcon capable in terms of terrain? What do you think should be done to improve on its current blockiness? What do you think about ground obejcts needing improvement? Can we think freely and unconstrained about these things and try to set up what I am reffering to as pipelines or are there other things I need to be aware of? Perhaps you have a better way to do this?
I am looking forward to read your thoughts on all this.
Enjoy!
One more thing… I am not suggesting specifically modding the existing terrain. I am looking forward - hopefully - to come up with a terrain that has many more smaller tiles to start with, more detailed elevation data and then apply - if possible - photorealistic textures from sat. imagery. That I think would be a vast improvement. But again, we need to know what are the limitations.
If the current terrain comprises of 100x100 tiles, things would look MUCH better if it comprised of 10.000x10.000 for the exact same area, if more detailed elevation was generated not via linear interpolation though, as that would give us the same blockiness we already have.
And if anyone feels I should be apologizing to anyone, just speak up. I have no ego concerning recognizing mistakes and apologizing.
Thanks all.P.S. I will be looking into what data is freely available for use (e.g. NASA Worldwind). I will be aiming for a 1m resolution with its elavation data. That is 1mx1m tiles with - if I remember correctly - 4 elevation values per tile (one for each corner). If alternatives exist, I kindly request anyone interested to do research into this area so we can see what we can work with. NASA Worldwind is a global project. There might be other projects out there that offer their DTM (Digital Terrain Model) data openly. Good luck data hunting!
P.S.2 I will also be contacting FlightGear with questions in the same direction. Just letting everyone know so our efforts don’t overlap.
-
I think it’s fair to say that everyone who is passionate about BMS has the best interests of the future of Falcon at heart, even if they don’t always agree on the best way to get there. Please also understand that English is not everyone’s first language, so if meaning is unsure please refer to the sentence above and give people the benefit of the doubt.
Bear (not Bare unless their mind is empty) in mind that Benchmark Sims is a group of volunteers who give up their free time for something that they believe in too. As such the group does not function like a business, nor are the members interested in self-aggrandisement. The fact that the group is the only one, to my knowledge, that continues to function and develop Falcon 4 would seem to indicate that they must be doing something right.
Also consider that coders code because that’s what they know and do and enjoy. Data guys & gals, graphic artists, etc are the same. If you only have limited time for your hobby you’re going to do what you want and know best. Whilst we do try to document what we know don’t forget there are many extremely talented and knowledgeable individuals outside the dev group who give up their free time too and might be able to answer your questions in a more timely fashion.
-
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?
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)? What would be the expected performance penalty for that?
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?
4. How does Falcon provide elevation for each tile? Or does it use combinations of elevation and tilt per direction?
5. Is there a limit to area of terrain or to number of tiles or number of elevation values that Falcon can handle?
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?
7. How is a single tile labeled in Falcon? The proper nomenclature and formatting is important to have, so that work can be segmented.
8. Are tiles “grouped” or does the developer need to assign a tile for every tile position? For instance, I provide a list of all the tiles that form a road which has a given color (e.g. asphalt), will Falcon assign the same tile to all of those tiles or do I need to provide one tile per tile position? In other words, is the terrain “smart” or “dumb”?
-
@Cloud:
But you’re missing the point Molni!!!
C9
I cannot see the point.
-
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.