EXPANSION OF DEVELOPMENT BASE PERSONNEL THROUGH EDUCATION
-
Once upon a time F4 terrain was drawn using L0 at close range - L0 had 16 times the resolution of L2, meaning 10241616 = approximately 256k * 256k height points for the entire map - and was scaled outwards using L1, L2, etc. as the viewpoint distance increased. The downside to this was terrain “popping” under standard conditions. The popping effect could be negated to some extent using the -G* command line switch then upping the terrain detail slider in the Setup page. Way back when, I tried along with T-Rex’s encouragement to smooth out the popping using averaging methods - the L1 was smoothed using L0 values, L2 using L1, etc. but the improvements were minimal and results thought not enough of an improvement to include in FF version x (meaning I cannot remember which).
As far as I believe the code to draw the terrain in this way (using L0, L1) would still be in today’s executable.
BMS decided to settle on using the L2 height map. Personally, I’m quite happy the way things are, given the vast majority of my time in the air is spent above 14,000 feet, but that said, a mesh of 250m (or even finer as hinted at by I-Hawk earlier) would be a very welcome return, and would make TFR and low level work all the more enjoyable.
As for Atreides’ efforts to, what appears to be on the face of at least, start a whole re-write of the terrain engine (and beyond), my own thoughts are; BMS team has done us proud to date - I think we should leave things in their proven capable hands and let them move things forward in the way they want to. They have a successful model in respect who they do and do not employ as members of their team. It has worked to date, I can see no reason why it won’t continue to work.
These are my own humble opinions on this matter, and as such I won’t be contributing further to this thread. http://www.185th.co.uk/forum/images/ernaehrung004.gif
I am not trying to prove anyone wrong or incapable. It just seems to me that either the terrain is far down on their list concerning being improved in the manner I am mentioning, or it is way too complicated (which I certainly can’t exclude as a possibility) or they lack resources (which MIGHT be the case, however I am not sure).
I would lend my free time and effort into any direction that:
a. Aided the core dev team to effect the changes I have been talking about.
b. Managed to effect those changes regardless of anyone’s contibution.For me, everything is on the table.
For instance, if what Arty suggested about the Falcon Editor is required I will take up a portion of that work to help. I might need some guidance - same as most other people since I am not code savvy enough - but I will be the 1st to volunteer.
If we can only rely on “tricks” to improve the blockiness of the terrain, then I will start designing building blocks of terrain to fit on top of the existing terrain or whatever other trick we choose to employ.
If anyone can provide definitive answers concerning the inter-relations and co-dependencies of everything that are affected by a finer height map, then I would not mind one bit in helping do/change things in that direction.
I do remember one thing said to me in the beginning of this thread though:
That the BMS team wants / needs to keep the code to themselves or make sure nothing is reverse engineered which I respect _. Meaning that - for me at least - I am dependent on them and when they choose/decide/have the time to take up everything I am talking about.
I hope I have clarified my position well enough. No matter what, thanks for your input and shedding some light on what we have been discussing the last few days._
-
Not sure if its already been said here
but a lot of what the OP posted has and is being done already we have dedicated Data / DB guys who Co-Ordinate with the Coders
a lot of work is going on behind the scenes so if it seems some functions or architecture is not being worked on I can assure you most of it is do we post about whats to come no and for good reasons IMO as you can imagine the threads come saying "Oi you said this would be in or that would be in blah blah “” when it could just be down to code complications anyone who has seen the code knows how all over the place it is
We provide IMO a very informative Documentation on how to use the systems etc. etc. and community members provide really useful videos on these as well
The code itself needs to be kept to the core dev team as per this thread https://www.benchmarksims.org/forum/showthread.php?26408-4-33-1-will-release-shortly-what-you-need-to-know-and-how-to-be-prepared.
That being said there is nothing stopping IMO a group who wish to create a Theatre / Tools / Models / or any other update as is already the case will they become part of the main installer possibly see the FAQ section for details on what we need for that.
Point is we do bring in guys from time to time usually the ones that have shown their work and reached out.
Hope that helps little
-
General statements - Regarding the bubble - I suggest to anyone to d/l and go over the relevant sections in the RP5 manual. Most of what’s written there is still valid:
http://www.maverick.webd.pl/pliki/F4_RP5_User_Manual.pdfRegarding BMS “choice” to use the L2 resolution and not L0, is mainly because with L0 and the existing rendering we get severe Z-Fighting issues between terrain vertices (Because of the higher resolution). Although it looks same, the rendering of the Terrain in BMS was actually rewritten compared to older versions of Falcon (e.g water normal mapping, no LODing/Popping and of course no Far tiles used).
Rendering of the current Terrain is segmented yes, i.e only what needs to be rendered is loaded at a given moment, but that’s mainly because of the texturing, we are executing a draw call for any texture that is involved in the current render frame, in other words drawing the terrain requires a HUGE amount of draw calls, not because of mesh resolution but because of the texturing.
It just seems to me that either the terrain is far down on their list concerning being improved in the manner I am mentioning
Well, I said earlier that finding interest in the terrain is true for the 2 of us, so it’s not low priority, I assure you that
or it is way too complicated (which I certainly can’t exclude as a possibility)
Yes it probably is complicated, but complicated never stopped us
-
All the work done so far is very much appreciated. I think sometimes an update now and again on projects being worked on would help people understand where the work is going. I do understand that not all the work comes to fruition, everybody needs to understand this. So don’t get disappointed or exited about current projects, Probably why you don’t here to much from the Devs. Myself I look forward to every update that improves this Sim even if it is 3-4 weeks.
-
In dictionary under complicated and beast you find Falcon4. [emoji38]
sent from my mi5 using Tapatalk
-
Not sure if its already been said here
but a lot of what the OP posted has and is being done already we have dedicated Data / DB guys who Co-Ordinate with the Coders
a lot of work is going on behind the scenes so if it seems some functions or architecture is not being worked on I can assure you most of it is do we post about whats to come no and for good reasons IMO as you can imagine the threads come saying "Oi you said this would be in or that would be in blah blah “” when it could just be down to code complications anyone who has seen the code knows how all over the place it is
We provide IMO a very informative Documentation on how to use the systems etc. etc. and community members provide really useful videos on these as well
The code itself needs to be kept to the core dev team as per this thread https://www.benchmarksims.org/forum/showthread.php?26408-4-33-1-will-release-shortly-what-you-need-to-know-and-how-to-be-prepared.
That being said there is nothing stopping IMO a group who wish to create a Theatre / Tools / Models / or any other update as is already the case will they become part of the main installer possibly see the FAQ section for details on what we need for that.
Point is we do bring in guys from time to time usually the ones that have shown their work and reached out.
Hope that helps little
It does help. Alot. If not for any other reason than that of establishing intentions and well meant decisions-actions. I also recognize very well at what is said in the FAQ that stating commitment of what will go into the next iteration/version will only cause premature excitement and a ****storm of questions. It is very well said that “instead of working with the code we [the dev team] would spend our time answering questions”.
As I already said, I don’t seek to be in the core dev team or any other team for that matter. I am here because I volunteer my time and energy to help improve this flight sim… not unlike alot of other people that have already been working on it for years or even decades.
When everything is all said and done, I - or anyone else - don’t have a reason and especially no right to complain about what is being given to use for free.
-
General statements - Regarding the bubble - I suggest to anyone to d/l and go over the relevant sections in the RP5 manual. Most of what’s written there is still valid:
http://www.maverick.webd.pl/pliki/F4_RP5_User_Manual.pdfRegarding BMS “choice” to use the L2 resolution and not L0, is mainly because with L0 and the existing rendering we get severe Z-Fighting issues between terrain vertices (Because of the higher resolution). Although it looks same, the rendering of the Terrain in BMS was actually rewritten compared to older versions of Falcon (e.g water normal mapping, no LODing/Popping and of course no Far tiles used).
Rendering of the current Terrain is segmented yes, i.e only what needs to be rendered is loaded at a given moment, but that’s mainly because of the texturing, we are executing a draw call for any texture that is involved in the current render frame, in other words drawing the terrain requires a HUGE amount of draw calls, not because of mesh resolution but because of the texturing.
Well, I said earlier that finding interest in the terrain is true for the 2 of us, so it’s not low priority, I assure you that
Yes it probably is complicated, but complicated never stopped us
I-Hawk, the way I see it, the first hurdle we need to overcome is the code co-dependencies and limitations. You seem to know more about this than me. Can you think of a way to teach more than just one person certain skills to allow them to help with what i understand is something like “spaghetti code”?
-
Heya
sometimes its easier to explain if you see it for yourself
Have a look around the net you can find various versions of Falcon code I know its not the latest but it is a good starting point to see what a mess it truly is.
from personal experience latest isn’t much better (mainly from me before I-Hawk says it ) but a lot has changed or just updated to cleaner code.
-
Heya
sometimes its easier to explain if you see it for yourself
Have a look around the net you can find various versions of Falcon code I know its not the latest but it is a good starting point to see what a mess it truly is.
from personal experience latest isn’t much better (mainly from me before I-Hawk says it ) but a lot has changed or just updated to cleaner code.
I really need to understand this:
Are you implying that over the years the core dev team is performing a complete re-write of the original code by approaching one feature after another?
The following is addressed to anyone capable of answering (I-Hawk, Malc, Ninja, Cloud 9, other):
One more thing:
From what I understand the terrain portion of the code has not been touched too much or at all. Would it be possible - while working with a version other than the one the BMS dev team works on - to catalog all the co-dependencies and limitations of it to speed up the process of bringing to life a new cleaner and hopefully expandable or at least more detailed version of terrain? If, so, what version would be the closest a. to what the BMS team is working on and b. to the goal of using a finer geometric mesh and a much higher number of tiles concerning texture without affecting the simulation and game play?
-
I really need to understand this:
Are you implying that over the years the core dev team is performing a complete re-write of the original code by approaching one feature after another?
Seems to me like you are trying to put everything in order, but if you know how software works, then you should know the core stuff is usually tied. And in dependency of the complexity level, things may be more or less complicated to manage. Falcon code is an example of a complicated code project. Add to that the fact that it was touched over the years by many folks and which not always tried to do things the right way - As in many cases during software development you are hitting a concrete problem and there are 2 or more ways to solve it, usually there is the easy and short way which we call “Hack” or “Kludge”, and there is the harder but the better ways to do it.
I’m not an expert to the real deep stuff of MP and bubble but believe me, the guys who worked on that stuff to allow BMS the stable MP we have today, they really had to bust their ass off in order to make that work, as this stuff isn’t trivial to manage, not at all.
-
Yeah kind of let me try and explain from my perspective
A lot of the original code still exists this is true but over the years and different groups it has changed soooo much that If you compare codes for example SP3 - whatever other code base there is available Good and bad coding practice had been applied.
You will notice a huge difference remember originally it was in C or C# over the years we have been adding features or totally rewriting them to fix a bug or improve on what was there and these normally get transferred into C++ as well as Library’s being added or removed is there more that can be done hell yes and I am always amazed with the rest of the guys enthusiasm to add a new feature or fix a bug that has been there since day 1.
From what I understand the terrain portion of the code has not been touched too much or at all. Would it be possible - while working with a version other than the one the BMS dev team works on - to catalog all the co-dependencies and limitations of it to speed up the process of bringing to life a new cleaner and hopefully expandable or at least more detailed version of terrain? If, so, what version would be the closest a. to what the BMS team is working on and b. to the goal of using a finer geometric mesh and a much higher number of tiles concerning texture without affecting the simulation and game play?
you can read between the lines here
I know for sure some have taught themselves on graphics rendering code where their main aim is to help improve on the rendering side of things over my head but I been doing other things mainly on the GUI side of things which btw sends shivers down other coders backs lol just because it has always been on the dark side of the code.if I get a chance over the weekend I will see if I can compile a list of what is to come or something like that if I can I am 100% sure most coders look at the if you could have one thing thread
-
This post is deleted! -
Seems to me like you are trying to put everything in order, but if you know how software works, then you should know the core stuff is usually tied. And in dependency of the complexity level, things may be more or less complicated to manage. Falcon code is an example of a complicated code project. Add to that the fact that it was touched over the years by many folks and which not always tried to do things the right way - As in many cases during software development you are hitting a concrete problem and there are 2 or more ways to solve it, usually there is the easy and short way which we call “Hack” or “Kludge”, and there is the harder but the better ways to do it.
I’m not an expert to the real deep stuff of MP and bubble but believe me, the guys who worked on that stuff to allow BMS the stable MP we have today, they really had to bust their ass off in order to make that work, as this stuff isn’t trivial to manage, not at all.
I-Hawk, thanks for the explanations and your time.
Where do we start?
Where do we help?
How do we help?Since you mentioned at least You and Me - and from what I understand several others that would be willing to help - do you have any estimate about how much it would take to have some kind of understanding about what can be changed in a positive way towards the goals I mentioned? And are those goals even valid given that the existing code imposes limitations that most of us - me included - don’t quite understand?
-
For starters i have already started the falcon editor manual.
First goal is to give basic usage and structure to the newb user. It will be enriched as i go along and implemend object oriented procedures like add new weapon or rack.
Everyone is invited to contribute with plain text pics or videos.
I’ll try to host the html version somewhere so ppl and devs can have a look and kick me when im wrong or i forget things.
If the coder of FE wants to implement the file as help with keys or keywords we must come to an arengement so it will be easy for him. Not that needed but it would be neat to mouse over a button or frame name and a kind text confuses u to death… [emoji38]sent from my mi5 using Tapatalk
-
I know of at least one real world F-16 pilot that offered to help improve the avionics and bring them closer to what is actually in the jet and he was more or less ignored. To put it bluntly, they don’t want our help.
There are things in recent BMS updates that came from feedback from real world F-16 pilots. The CZ highlighting when you move your cursor is one that comes to mind but I know there are more. There’s a list of things provided from real world F-16 guys around avionics (non-classified of course) - the team just hasn’t got to them all yet. It’s not from a lack of having the information.
-
There are things in recent BMS updates that came from feedback from real world F-16 pilots. The CZ highlighting when you move your cursor is one that comes to mind but I know there are more. There’s a list of things provided from real world F-16 guys around avionics (non-classified of course) - the team just hasn’t got to them all yet. It’s not from a lack of having the information.
Definitely and that’s great to hear, I look forward to the future, I think what he was trying to get across was simply how difficult it actually is to get on the team, that even an F-16 pilot who had the ability was passed over in this case. This thread has been very interesting at one point I thought for sure it was going south, but I was wrong. The development team and moderators have been super generous on this one, it is much appreciated watching the team rise to the occasion and sharing knowledge with the new guy. Very impressed
-
I-Hawk, thanks for the explanations and your time.
Where do we start?
Where do we help?
How do we help?Since you mentioned at least You and Me - and from what I understand several others that would be willing to help - do you have any estimate about how much it would take to have some kind of understanding about what can be changed in a positive way towards the goals I mentioned? And are those goals even valid given that the existing code imposes limitations that most of us - me included - don’t quite understand?
Well, when I said you and me, I mainly spoke about the interest in improving the Terrain
But unfortunately, the task itself is to be done with coding access, so there isn’t really not much to share and only say that hopefully the future will become better.
-
There are things in recent BMS updates that came from feedback from real world F-16 pilots. The CZ highlighting when you move your cursor is one that comes to mind but I know there are more. There’s a list of things provided from real world F-16 guys around avionics (non-classified of course) - the team just hasn’t got to them all yet. It’s not from a lack of having the information.
Mavericks, SPI, TGP and probably more stuff that I already forgot
-
Well, when I said you and me
Don’t let AB or is it now AD see that he get jealous
/me sneeks back to the shadows
-
Well, when I said you and me, I mainly spoke about the interest in improving the Terrain
But unfortunately, the task itself is to be done with coding access, so there isn’t really not much to share and only say that hopefully the future will become better.
Precisely my point.
Could the same task be approached through a different version of Falcon, older FreeFalcon, Falcon AF, OpenFalcon, other? Would that even be useful or would it just be double the effort?
If nothing can be done at the moment on behalf of the users that have no access, I suggest at least setting up a pipelines for complimentary work while the core dev team tries to comb the spaghetti code concerning terrain.
That means that the average user falls into 4 different categories:
a. Those with coding skills we should at least try to employ on non-critical code tasks (ideas anyone?).
b. Those with 3D skills
c. Those with 2D skills
d. Those with no skills (they can still help)We can setup pipelines concerning 3D models and do preliminary work concerning terrain (Group b.).
We can setup pipelines concerning textures of 3D models and terrain (Group c.).
We can help Dee-Jay with the Tac-Ref (Group d.).I would suspect that Dee-Jay’s pipeline would be the easiest and be described something like:
1. Decide on a common format for storing / handling text entries.
2. Find approved sources of information for each weapon system.
3. Decide on what information will be included in the Tac-Ref for each weapon system (specs, capabilities, doctrine, other, history of weapon system?)
4. Obtain permissions to copy-paste material, or if denied re-write in own words taking note of the source for credits and reference.
5. Store and hand over to Dee-Jay.If I have forgot anything, Dee-Jay already doing this should point it out before the typing begins because he would be receiving text entries from more than just one user.
Concerning 3D terrain, I will research what is freely available for the future and give a heads-up so everyone knows, in this thread. After that, we can decide on how it will be used. Last time I downloaded version 2.0 of Flightgear’s terrain it was 80+ GBs of terrain data. So I think its safe to guess that they are using NASA WorldWind with or without modifications (without most likely because you wouldn’t mess with that size of a dataset without good reason). There are a few other options and I am aware of some companies that MIGHT offer high(ish) resolution terrain in exchange of publicity / advertisement.
Concerning 3D vehicle models, the way I see it, its either digitize, model, or both. I also think that my initial approach of going for the highest possible accuracy model is correct so that its avoided making the models twice. The high-end stuff can always be simplified to fewer polygon versions.
The same applies for real-world objects such as buildings, bridges, harbors, power line towers, etc etc.
Finally, those with 2D skills can pick up from where finished 3D models leave off (skin the plane / missile launcher / truck / whatever) and also collect and prepare the landscape colors DB for the terrain depending on position (seaside, plain, hill, foot of mountain, mountain, summit), season (winter, spring, summer, autumn) and time of day / night.
Naturally, those with coding / 3D / 2D skills need to be put to work on their specific skillsets and everyone regardless of skillsets on their spare time need to type along with those that don’t have any special skills as mentioned.