EXPANSION OF DEVELOPMENT BASE PERSONNEL THROUGH EDUCATION
-
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
-
I have a tool that creates fine manuals as for structure by the program.
It’s called Doctor Explain and it’s considered one of the top in it’s class. I use it for years now at work and managed to release a few manuals.With this tool it can be done that the manual be integrated in the app by using keys that will have to be active and usable in the code. That way it can be done like mouse over a field or button and a balloon can popup with a link or info.
The result can be auto made as html chm or pdf. So it could be online for everyone to use it.
But the thing aint the tool but free time and will to accomplish such project.It’s a vast project. Sure I can start it and I consider it very seriously for long time now but for sure I don’t have the time to keep a standard pace on it nor have all the knowledge as to be a no questions unanswered manual.
I will need help from many guys here in the community and for sure from the dev’s.
Additions and updates will always be, the thing - issue is at least be provided some comments or a few text lines what the newcomer does or is for.
Good morning Arty!
Please read above, if its possible to focus for the time being only on the chapter of terrain to limit the workload. Could you please check with someone in the core dev team if they would be able to help us with all the codependencies of the code in making that chapter (terrain). Once we finished the the whole terrain pipeline, we would be focusing on other aspects of the manual for the next pipeline. You saw ahead of all of us on this one. Well done!
If we have all the co-dependencies at hand, we would know what can be changed / re-written and at what cost.
-
Hello and good morning.
Well the same means I have to contact devs you have them also. I believe they read and they already responded.
I don’t have a different way communicating with them. So help is already provided and will be since they see something worth to spend their time.
Your main issue mainly is that you came out of nowhere without any legacy to prove you know what you
Are talking about, and you are basting their balls. Reminds me in the past, and present… [emoji38]
So set aside (as I see u do) negative things written and stand your ground if u know what you are doing.
Having dependencies only for terrain might take what? A few months? In the best case scenario…Finally breaking down analysis is my favorite. The thing is with this beast everything is interconnected to other aspects. So changing one field value only in one thing might start a chain reaction that fubars all other.
Also I don’t think the devs master the whole thing like the palm of their hand.
I believe they also do the same piece by piece. There are pieces of code from falcon day one before 1998.
Terrain engine is on their Todo to change it all. But it’s a bitch.sent from my mi5 using Tapatalk
-
Hmmm all those talks where done in the past.
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).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.
-
Welcome Chihirobelmo to this endeavour! Are these links about Falcon? Please explain.
Not really, It is VR Unity application which you can fly over 3D rendered Japanese islands. As I described above the application renders the terrain from Geospatial Data rather than using any photo image textures, I just reminded of this when I-Hawk talked about a weakness of satellite images and what can be alternative. Perhaps The idea is still not so practical for Falcon now.
My Amateur thoughts for F4 development is this…if terrain elevation mesh can have more points per a tile in the future, Then what if using a single 4096x4096 texture tile for 16x16km? 1x1km still have a 256x256 resolution which is still same to 4.32 KTO tiles. the 64*64 theater can make the whole terrain with a unique RL aerial photos within 4096 tiles limitation. Theater development might not be as hard as making 100k numbers of tile. Drawing a single tile for 16x16km eats GPU resource less than 16x16 tiles for 16x16km.
We can say goodbye with repetitive coastline/textures.
The problem of this method is that Campaign Engine would make a decision per 16x16km than current 1x1km. So needs to give 16x16 unique AREA/PATH information per single tile if to keep current DC alive. That might be an overhaul of the DC Engine. -
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!