Redflag RP5 V5.0 Preview
-
@ I-Hawk.
The idea is simple:
- keep the textures size in L2 (1000m x 1000m) and don´t create smaller or bigger ones (no changes here)
- allow more than 4096 unique textures to be used, so we can consider covering a whole theater with indiviual textures instead of repeating patterns
- reduce elevation grid (or mesh) from 1000m (which is 1980 or older style tbh) to at least something more appropiate (like 50m or 100m)
Mind you (i dont know if you fly FSX)… THEIR elevation mesh can even go down to .30cm and with modern PCs (around 2 years old)… FPS is great !
If we take real textures from google map right now… and place them into BMS with only 1000m elv. mesh, the texture attributes don´t match with the low 1000m elv. mesh and we get again rivers flowing uphill and downhill or cities “hanging” in declined hills etc etc. It looks “squeezed” and “fake”.
Photoreal textures with wrong elevation data doesn´t match up. Photoreal textures only work nicely if appropiate elevation resolution is possible.
I am not proposing to change the size of TEXTURES … no, keep the same size you have now - Same texture size and tile-sets.
ONLY (if possible) re-code the ELEVATION DEFINTION to 50m or 100m for L0 or L2 …whatever you like and consider the AI understands it too.
Fartiles you still can kick out (as it is now) - no need and saves FPS.Once that is achieved…THEN we can litterally IMPORT … TEXTURES AND ELEVATION from the internet and create much more realistic terrain for BMS. We know how to do it, but we are limited by:
- only 4096 unique tiles, thus repetitions required
- only 1000m elevation resolution
Those 2 things cut us off in the creation of amazing looking terrain (forget what you see in redflag 5.0 preview pictures, because once that is possible… terrain can be much much better than the pictures shown in 1st post)
As you can see in the first post of this thread…Polak did an amazing job on the textures… i worked like an idiot on the WHOLE elevations for korea…making 250.000 tiles manually by hand (i had to, so it makes sense with textures used)BUT!!! we can DO EVEN BETTER THAN THIS, IF …those two limiations change.
My thoughts go towards “maybe we can utilize what we already have in better ways (with tweaks), instead of considering the creation of a whole new gfx-terrain engine”
Note: most DEVs (so i figured) haven´t even tried Redflag 4.0 as most don´t have 4.32 installed anymore for long. Once you see the textures+elevation is Redflag 5.0 … you will get the idea. At this point remember this what i wrote above… WE CAN DO MUCH BETTER, IF …those two limitations change (or look at that tileproxy video above).
-
always divide by 2 in Falcon world - so 1000m -> 500m -> 250m (L0) -> 125 m -> 62.5m -> 31.25 -> 16,625 m …etc…. are possible mesh subdivisions
BTW I like 1km patch, it is 90ths technology …80ths to early 90th is flat terrain with pyramid/hill objects (wireframe or solid) -
In the first step somebody pls. explain why had to give up the much more deteailed terrain of OF… I did not caused any FPS issue…
-
all 250m terrains “poped up” in front of player due to LOD switching…simply it was too heavy to see 250m resolution up to the horizont…
1000m terrain can be edited on triangle level
-
…and another problem - object placement, unit placement and movement…Z shifting is counted according L2
-
In the first step somebody pls. explain why had to give up the much more deteailed terrain of OF… I did not caused any FPS issue…
thats why
-
always divide by 2 in Falcon world - so 1000m -> 500m -> 250m (L0) -> 125 m -> 62.5m -> 31.25 -> 16,625 m …etc…. are possible mesh subdivisions
BTW I like 1km patch, it is 90ths technology …80ths to early 90th is flat terrain with pyramid/hill objects (wireframe or solid)31.25m for Le (extra) would be ideal. I still cant get my head around, that a better wireframe (and nothing else changed) would kill soo much FPS……espcially after having like 100FPS with my almost 2 year old system while running this:
-
@A.S:
31.25m for Le (extra) would be ideal. I still cant get my head around, that a better wireframe (and nothing else changed) would kill soo much FPS……espcially after having like 100FPS with my almost 2 year old system while running this:
imagine u are flying over 50 x 50km visible area
L2 res : 50 x 50 = 2500 polygons = 5000 triangles
L0 res: (50 x 4 ) x (50 x 4) = 40 000 polys = 80 000 tris if LOD switching off…if ON = pop ups… on the other hand 80k is not so much for most of u…so probably game logic part of it is rather show stopper here (but u also like 80k hires pit, F16 model, populated city with hi-res houses…)Edit: note to your video
FSX has much more inteligent and adaptive mesh tessalation compared to simple and regular Falcon grid/checker(F4 mesh is not adaptable)…see here:
http://www.microsoft.com/Products/Games/FSInsider/developers/Pages/GlobalTerrain.aspx
-
I get your point, what a pitty. So, bottom line… new terrain engine one way or the other is the only solution?
-
SFP1 terrain engine had small provision for local height map tile. It was small grayscale (256 values) 16x16 pixels so called nameofthetexture_HM.bmp, which superimposed locally heights with greater resolution on the mother tile. Terrain engine automatically was dividing that area into smaller squares (16x16 because of the size of _HM.bmp) and was taking into account height information from that small height map but only whenever there was nameofthetexture_HM.bmp present in the texture folder. Rest of the tiles were rendered with lower height resolution. I guess it was, what we call bump texture.
Tricky part of course was that higher resolution “meshed in” seamlessly with the rest of sorrounding tiles on the perimeter, but that was done by the smart algorithm within the engine. 16x16 did not have enough detail to sculpt say intricate terraform shapes, but I have experimented with much higher resolutions of bmp up to 256x256 with quite interesting results and no extra adverse effect on the performance. Again I repeat it was meant to be used only locally (say river tiles) and it was not meant to be widely used.
EDIT: only height information was taken from the _HM texture. Main also *.dds terrain texture still was covering area of the main larger grid.
-
-
Should I try the switch? Because I cannot see any real answer.
I havent exprimented with the “-g” switch in BMS yet. I know what it did in the past… so try it out.
-G31 is extreme high though. I remember screwing around with g-15 values in OF. -
It was said that cause of the new gfx engine this switch has no effect anymore in falcon…
-
@A.S:
I havent exprimented with the “-g” switch in BMS yet. I know what it did in the past… so try it out.
-G31 is extreme high though. I remember screwing around with g-15 values in OF.I set 99 terrain detail, and between 7-13. I did not see any change with -g31 or -g13 either.
-
and not being able to hear the Com1 and the Com2 radio traffic at the same time.
That doesn’t work? Are you sure? Because when training I use UHF so the students can interupt me on VHF and it seems to work. Maybe I’m confused.
-
This post is deleted! -
That doesn’t work? Are you sure? Because when training I use UHF so the students can interupt me on VHF and it seems to work. Maybe I’m confused.
Was talking about AI not being recieved at the same time on both radios
-
textures are real nice….
-
little update on the to-do list of Redflag 5.0 (Note: this is just informal and not for debate):
- Redefine all water areas in 2900 tiles (done) - Redraw all new raods in 2900 tiles based on the new photorealistic layout ( 5-6 days of work ) - Create sub-layer of tiles to prevent reptitive errors in the THR built ( 2-3 days of work ) - Built all bridge pathes ( 1-2 days of work ) - Create new pathes around airbases to avoid units over runways ( 2-3 days of work ) - Gobal visual crosscheck of all pathes ( 1 day of work ) - Built a improved (flags) mission.dat file and improve ATO behaviour ( 1-2 days of work) - Experimental test on the C3 network (working CGI) ( 2-3 days of work ) - Indepented SHORAD systems for all active airbases ( 2-3 days of work) - Ship movements improvements ( 1 day of work ) - New BMS rack dat. Release-sequencing and non-jettison abilities of stores and pylons (done) - New DRAG values (more sophisticated) for certain pylons and peripherials (done) - New terrain textures (done) - re-import / - implement RF4 elevations + testings (done) - FIX gfx bugs in tiles ( 2-3 days of work) - remake save0.cam and new_tac.cam (objectives) (4-5 days of work) - create new exports of TEs and Campaign files (1 hour). - creation of a new 2D relief map based on new water- and road-lines (1-2 days of work) - re-do all bridges in length, rotation (poling) and positioning (2-3 days of work) - changes to the campaign so it differs from the RF 4 Version (3-4 days of work) - considerations of community wish lists (3-4 days of work)
so eta 30-35 days more work-days here to do before final stage…… after all i´m confident, that it will be a VERY qualitative well made Korea theater (regardless the campaign on it).
-
@Molni (answering your PM publically here as others might have similar questions):
Well, first of all let me first finish things
Generally… the theater itself, meaning the textures, terrain (elv) and the objectives on them are one part and the campaign (units) is another, which allows you independent working in your own korea based campaign-built (quick export-imports possible regards).
But, as objectives are part of the database aswell and as i have to work on them (especially bridges - see list above) … you probably would have to extract my objectives from the database only and maintain YOUR units, vehicles and weapons etc. and “merge” the both contents.
I am not sure if that is possible, but it should be.
If you want to merge more, than yeah…you need to fiddle out things manually and decide if you want to integrate it (edit) in your database aswell.