Redflag RP5 V5.0 Preview
-
I would try:
-
to keep the texture-size still in L2 format (fps consideration and no use of farttiles aka no pop-ups in the LOD-distance rendering of textures, which can be seen in FSX with LOD1 to LOD20 for terrain), but just allow more unique tiles usable in the code (fool-tweak the code).
-
and also re-create the elevation mesh LOD-levels, meaning something like L0 = 10m, L1 = 20, L3 = 30m, L4 = 60m L5 = 120m … and make sure the .mea file (collision data definition) is based on L0. Right now L0 = 250m and L2 = 1000m and L2 is the only used for elevation defition. 1000m mesh terrain elevation is 1980 style.
That alone would allow to litterally IMPORT REAL DATA (elevation and textures) and create some outstanding realsitic looking terrain for BMS (like in tileproxy) …if that tweak is possible of course…dunno. I think it should be. -
Shaders are based on water-tiles atm, but F4 code itself operates (sorts) in this order:
1st Tile-set type (plain, water, etc etc)
2nd Areas (water, plain…etc etc)
3rd Pathers (raods, rivers etc etc)BMS reversed this order for water areas in order to get the shaders working over water-tiles, but this comes with difficulties in the theater-creation, especially while rebuilding the .thr file, which is crucial for a proper save.cam built as the .thr file defines where the GU can go and can not go. It was a “look” versus “functionality” compromise. Functionality comes first.
So shaders would probably need a different implmentation aswell based on water AREAS NOT water TILES (in RF the built order is correct, thus no water shaders, but instread water splashes instead of raising dust if shells hit the water)
- furthermore BMS only uses PLAINS and WATERTILES. Why i can undertand. Tacview itself considered other sets such as URBAN, THINK THINK FORREST, SWAMP while calculating the link values.
I wonder if different or more tile-types (like in original F4) have an impact on GU move speeds if re-introduced??? That would be interesting.
-
-
Yep … this is what I am seeing on DEV forum. I wonder also if is wasn’t also to fix some MP issues (not sure?) … and allowing sharers.
=>
It suppress the far tiles system and use only near tiles. At the same times, it resolve a old MP bug for elevation.
So is normal that he take much more FPS to run, because he use only near tiles , so huge resolution tiles.Its not only the tiles but I think the terrain resolution is at the same level as the old terrain running with a -g31 (or something like that) switch. If you wish to compare performance you should run old terrain with -g31 switch and then note FPS (you’ll get ~half or even less than without the switch and less than new terrain).
So … BMS terrain engine is already a “new” engine compared to OF, FF or AF … maybe one day, it will be enhanced a bit further (?)
There would be quite a bit of worked involved to change this (including mesh collision detection). Frankly I do not have the time for this.
And yes, we need a new terrain engine.Probably not tomorrow!
-
Yeah i remember the -g command :=)
I highly doubt a simple elevation grid (or mesh) improvement (resolution) WHILE KEEPING SAME TEXTURE SIZES will have a huge impact on FPS on modern machines, because its simple just a “blank” 3D elevation grid (like empty low poylgons as an analogy) and not more tiles (textures) to be loaded or processed.
Keep texture as is (L2)…allow more unique L2 textures tiles… increase elevation resolution. Infact - as example - textures can even be 2000x2000m instead of 1000mx1000m (currently) because as long a good mesh will allow to “lay” those tiles (texutres) over the better elevations …the textures will fit it naturally and cover respectively and naturally.…i think i will jump under cold water…its ridicilously hot here today…
-
@A.S:
I highly doubt a simple elevation grid (or mesh) improvement (resolution) WHILE KEEPING SAME TEXTURE SIZES will have a huge impact on FPS on modern machines,
My 1st couple of quotes is from 2008
… the third from 2013.
-
Copy… i ´ve read them before… someone posted same before.
-
BMS reduced from L0 to L2 (250m to 1000M) terrain resolution for different reasons. One of them afaik was no more fartiles and pop-up texture. I remember there was a discussion here about that.
Why? Just because of texture resolution (?) issues?
-
Why? Just because of texture resolution (?) issues?
Because of post '73 (Dee-Jays quotes)
-
Errr may I add…
First Molni from 1000 to 100 will be 10 times better not 100 times. This is important. Why?
It will load 10x4=400 times more tiles (or 10x3 in some cases), and the problem ain’t on the GPU’s yeap GPU’s can cope (maybe?) with the load but HDD’s also if the resolution is upgraded and use 1024x1024 or 2048x2048 then u killed it just by that, the problem as I remember from the OLD days it was stutters - freezes which was found that it was loading freeze cause the CPU-GPU was waiting for the data to be loaded from the HDD, this was noticable even on fast Hdd back then. Ok now we have SATA and SSD but I’m sure we will pump up the resolution for sure, so we r back at the same point. (?)
Now this 10 times more detailed elevations automatically result in 10 times more CPU calculations consider this specially in a campaign… Don’t u think that this will have a huge impact on performance even with MONSTER super trooper ultra wow pc’s??? On the other hand we ask for larger Bubble… yeap right…
To do so then needs way much optimization and if u create a “heavy” theater then u r dead meat and the wagging of performance will be endless… So this is mostly why BMS did it I believe…
Also it might need optimization and on 64bit code and multicore multithread and all HELL others to bring it down to reasonable performance levels, and don’t ask for +3.000€ pc’s just to run a TE.So it’s not that simple at all IMO.
If u have the bubble size u can do the math for the tiles load demand… I remember it was done in the past… -
First Molni from 1000 to 100 will be 10 times better not 100 times.
Ok, it is not 100 times better but also not only 10 times… Surafce is a 3D object which defined by mesh. The 1000 m base terrain is defined by 4 points. How many nodes we have with same size of terrain with 100 m node distances? Not only 10 times more…
I never asked bigger bubble size.
-
It will load 10x4=400 times more tiles (or 10x3 in some cases), and the problem ain’t on the GPU’s yeap GPU’s can cope (maybe?)
Hehe… NO
If one keeps the L2 textures (1000m x 1000m) and only changes the elevation to 10m resolution (instead of 1000m) … you ARE NOT LOADING MORE TEXTURES OR TILES into the memory.
That is the whole trick
Instead of looking like this (examples):
it will look more like this:
WITH THE SAME 1000m x 1000m tiles (textures) over it. And we still don´t use fartiles (no need) to safe FPS.
We still keep same tiles (and numbers and size of them) and only change the “fabric” under them.
And as result we can built stuff like this:
with the SAME 1000m x 1000m photorealistic tiles from goolge-map ie. We already use partially photorealistic tiles in some theaters (its just a picture).
Increasing the mesh resolution will definitly not have much of an impact on FPS. But if one would use ONE tile for EACH NEW elevation area…than yes…it would kill FPS, but that is not the idea.
I hope its understandable what solution i am talking about. -
Ok now it’s better to understand it… hmm looks like a nice idea… Don’t know if those two are connected in some way mesh detail and tiles number per area.
Still the CPU-GPU load will increase 10 times… and u save from the whole process the loading of the tiles… the 3d calculations will increase but as u say today vga’s I’m sure will be ok with it. -
I always wondered what prevents rewrite the code of terrain.
mmm… how about the most expensive resource?
-
today vga’s I’m sure will be ok with it.
EASILY. Just fly Warthunder or try FSX with tileproxy and check your FPS. No problem at all.
-
This remenber me to Joint Strike Fighter 3D terrain mesh.
-
mmm… how about the most expensive resource?
Manpower on dev side or CPU? Too many people simply reject the Falcon because mostly of very outdated terrain. As I see the first line 3D models are acceptable even “eye candy guys” the terrain is simply too low detailed comparing to today’s usual level.
We still keep same tiles (and numbers and size of them) and only change the “fabric” under them.
Yes, I think about the same. I do not know what perevents applying this method.
-
Manpower on dev side or CPU?
Actually I meant time, but yes you can translate it to manpower.
Too many people simply reject the Falcon because mostly of very outdated terrain. As I see the first line 3D models are acceptable even “eye candy guys” the terrain is simply too low detailed comparing to today’s usual level.
Agree, but creating a terrain engine for a computer game isn’t the same as creating a 3D model or coding most other stuff. That’s why its called engine, because it’s not only a small feature, it’s something that has effect on the entire sim.
I wish there was someone with time and ability to do it, but until that happen, we will keep using what we have now.
-
it’s like the polys in a 3d model… more or less…
-
I wish there was someone with time and ability to do it, but until that happen, we will keep using what we have now.
Community is big with alot of talents… just keep a door open…and you never know you might come in
-
@A.S:
Community is big with alot of talents… just keep a door open…and you never know you might come in
Our door is open. And don’t think we are not getting joining requests from people, but it’s not enough to know c++ or having some ideas. If someone wants to join and can contribute really, the RV abandoned code is still floating somewhere… and in many many areas it’s same or similar to what’s in BMS…
-
This post is deleted!