Radar v. terrain
-
FWIW, I can tell you this:
I will TRY to fix it myself - If the fix is easy then great, if not then I will forward it to our Terrain/GFX expert and will see from there. Although it was fixed in Monster’s terrain tool, I don’t know if it has any effect on other stuff, so will need to see. -
BTW I am also interested what kind of L2 can see BMS AI…
original terrain or bugged (new) one?
Colisions are caunted according displayed terrain I think.Good question, but if collision code is same as it always was (And I don’t see why it won’t be) then it probably not reflecting the (current) displayed terrain…
-
I am no a programmer and I dont have acess to source code as well….but I cam imagine - It can be done in many ways…for example collisions can be linked to generated DX mash since beginning(means fine collisions in BMS 4.3X), but radar can have different approach…the same units, buildings etc…
You will see. Thanks.
-
This sounds like it deserves a nice face palm.
-
I am no a programmer and I dont have acess to source code as well….but I cam imagine - It can be done in many ways…for example collisions can be linked to generated DX mash since beginning(means fine collisions in BMS 4.3X), but radar can have different approach…the same units, buildings etc…
You will see. Thanks.
Well, don’t forget that once BMS reads the L2 data, technically I don’t think it even requires the file anymore… BMS uses its own terrain data files which are saved in a different format than L2 and contain a lot of other data that is combined from the L2 and probably also texture.bin and O2 files. So it makes sense that once BMS read the data at the first time that those files are created, then it already stores all the Heightmap values according to the rendering and then only that data is used for physics calculations, if there is mismatch between different physics calculations from the Heightmap, then that isn’t good (and I really doubt that’s the case).
-
Thats maybe reason why TFR algorithm sometimes miss some hill eges maybe.
-
And maybe why AI ain’t good and crashed when in close formation and low level flights. Maybe.
IIRC this was talked extensively in the past and probably I-Hawk will waste his time just to see that everything is ok.
-
The reaction time from first detection for SA-2/3 should be about 20-25 sec. In RL the best crew know this in full alert state.
-
FWIW, I can tell you this:
I will TRY to fix it myself - If the fix is easy then great, if not then I will forward it to our Terrain/GFX expert and will see from there. Although it was fixed in Monster’s terrain tool, I don’t know if it has any effect on other stuff, so will need to see.OK so the easy & fast approach didn’t worked. So I don’t know now if other/harder fix is doable. Will check.
-
So I-Hawk….you have found the line in the code(library?), where the rule for grid tessalation is stored…changed it and it did not worked?
It is not stored in data (until new datafile introduced - not easy fix). It is hardcoded somewhere. I am sure you know much better.
I am sorry….I am just interrested if you were able to find it, flip it and see original tessalation in game…? -
wild thaught…perhaps the rule is ok, just point of view is flipped from bottom to top or vice versa…
-
Yea that’s exactly what I tried to do, flip the vertices so the tris of a quad will be built in the “other fashion” which will flip the diagonals. Problem is that once that is done, all quads had 1 triangle looking fine and other looked blue/untextured. Needless to say that I also flipped the texture coordinates along with the position changes., so it’s not a small tex coords issues.
The answer from the expert is that there are probably more places in the code when some changes should be done and it would be hard to track and do those changes now. So can’t promise anything, I will try to search further.
-
If texture mapping and normal orientation is based on polygon(quad), then tris redefining would be a solution. I thaught (guessed) it is done by API which uses external DX libraries….
-
If texture mapping and normal orientation is based on polygon(quad), then tris redefining would be a solution. I thaught (guessed) it is done by API which uses external DX libraries….
DX API doesn’t do things for you in that manner
DX API gives you a relatively comfortable interface to speak with the GPU without knowing specific GPU design and low level instructions. But still you and only you manage every tri that you tell it to render, be it quads splitting, tex coordinates, normals or anything else, it’s all up to you. So sure the tris are being split in the BMS code, but apparently just flipping the vertices around isn’t the whole solution, unfortunately
-
ok, it is perhaps even better to control it whole inside program….just a stupid note, there was always “right hand” rule for normal orientation…so the vertices must go in order “against the clock direction” for proper normal orientation…of course you know it, sry I am just so upset after these years…
take your time -
Hello folks,
Didn’t see the answers until yet, thank you all for your interest for the problem.
It seems the issue is quite beyond my understanding of the way the terrain works in BMS on a technical level. I can only be glad it is acknowledged & put the emphasis on how important it is to be solved, considering its impact on tactics at various levels… and I hope a solution will be worked out sooner or later. I trust BMS team on the matter!
Have a nice new year’s eve. -
is there any progress regarding diagonals please? I mean even theoretical chance to have it fixed. I know u dont like to inform about “coding status”, but I am rather curious about “the way to go”….mean future direction (both possible diagonals for the tile, one or another for whole theater via exe patch or externized parameter, reverting back to origin etc.)
-
hi guys,
i add that for an exampleand the link of website
http://www.gamasutra.com/view/feature/130909/using_vertex_texture_displacement_.php
best regards
sf -
? its about displace map…?
perhaps there is some inspiration, but…I guess our issue is much more simple dolphins… but perhaps devs are ok with crashing planes, locks through mountains etc.
-
Well, I don’t have good news, as the BMS terrain was built almost from scratch in order to migrate the old Falcon terrain to DX9 and get rid of Fartiles, but it also became more complex than the old terrain, so flipping the diagonals isn’t an easy task and I didn’t manage to track all the other changes that must follow. Also, I was informed that even if this change will be done in the code, the data will have to follow which means that many manual fixes that were done to the original Height map data and work that were done to the texturing will need to be fixed which isn’t trivial as well.
but perhaps devs are ok with crashing planes, locks through mountains etc.
No we aren’t OK and we do care about anything in BMS and specifically about terrain. Just that it’s not easy sometimes to fix things as simple as they sound.