4.32 with 4.33 tiles

[Earlybite]

Hi,

a few days ago I made a test in 4.32 with 4.33 tiles and there appears some weird things:

1. Some white squares

2. The terrain was mixed. Is meaning, I could see 4.32 and 4.33 terrain

My try for a solution:
I deleted the first 5 files in terrain to refresh, but no change.

Is it possible to fly 4.32 with 4.33 tiles?

TIA
Greeting
Earlybite

[Polak]

Is it possible to fly 4.32 with 4.33 tiles?

Because of higher number of allowed land categories in 4.33 (that is in texture.bin) you may potentially encounter some troubles. To make any switch Theater.L2 , Theater.o2, texture.bin and texture folder from 4.32 need to be replaced by respectives from 4.33. Make backup of 4.32 of those files and folders just in case.

[Amraam]

You will have issue with the vehicule path….

[Earlybite]

@Polak:

Because of higher number of allowed land categories in 4.33 (that is in texture.bin) you may potentially encounter some troubles. To make any switch Theater.L2 , Theater.o2, texture.bin and texture folder from 4.32 need to be replaced by respectives from 4.33. Make backup of 4.32 of those files and folders just in case.

Ah , ok, …I think I will give it a try.

Thanks and
greeting
Earlybite

[Earlybite]

@Amraam:

You will have issue with the vehicule path….

For GMT’s? Ah, ok, but i shall be a try, a simple try. I only want to know the FPS-behaviour of 4.32 stock, and 4.32 with 4.33 tiles…, so nothing special.

But thanks for drawing attention.
Greeting
Earlybite

[Amraam]

No, it mean that the vehicule will not follow the road. Impossible to do correct CAS in that situation.

[Earlybite]

4.32 stock = 71
4.32 stock w. TGP = 66
4.32 w. 4.33 tiles = 61
4.32 w. 4.33 tiles w. TGP = 51

Only to inform and not needing any discussion…
Regards
Earlybite

[PlayLoud]

If I may ask, why not just run 4.33?

[Migbuster]

@Earlybite:

4.32 stock = 71
4.32 stock w. TGP = 66
4.32 w. 4.33 tiles = 61
4.32 w. 4.33 tiles w. TGP = 51

Earlybite

This is to be expected, the tiles in 4.33 look to have grown to 512x512 (117KB) each compared to 256x256 (43KB) each in 4.32 so your PC needs to use more resource.

FYI in 4.32 I was using toms 2015 tiles at 1024x1024 (683KB) each……if you want the eyecandy you have to pay for it with performance…or up the power…applies to all.

[dema]

I don’t understand what is the problem with 4.33 tiles….

[Earlybite]

@dema:

I don’t understand what is the problem with 4.33 tiles….

They are “eating” the FPS…

Just made further tests:
(A single lonly 3 ship over land with TGP and starting in the air by x64, same view)
4.33 Stock 77 TGP 52 Diff = 25 (yesterday I even could notice 80 50 = -30)
4.32 Stock 71 TGP 63 Diff = 8
4.32 4.33 tiles 69 TGP 49 Diff = 20

And especially in 4.33…

[Amraam]

Yes, this is normal and expected. Your test don’t reveal any new things ;).

[Earlybite]

I´m curious about 3D objects (e.g. 3D cities) and TGP and WEAPON and FLIR and TFR and explosions in low pass…especially in campaign

But please accept one question for now:
It seems that the amount of tiles results in lower FPS. But why? (I´m wondering because the amount of real rendered tiles (view distance) hasn´t changed (isn´t it?)…, especially for e.g. TGP.)

And, but, to me it has brought new impressions…

Earlybite

[I-Hawk]

The story is like this:
In the way that the terrain is rendered currently, every tile texture change requires a draw call, draw call is a command coming from the CPU that tells the GPU: “Draw this, now”.

Now think about it, the terrain is made of triangles where a quad (2 tris) covers 1KMx1KM area and use 1 tile texture. But for every texture you need a draw call, so it goes like this:

CPU prepares data and then initiate a draw call, example:
GPU--> Load sea texture as current texture
GPU--> Draw all quads that use sea texture

GPU--> Load city texture as current texture
GPU--> Draw all quads that use city texture
....
....
....
....
GPU--> Load texture #456 as current texture
GPU--> Draw all quads that use texture #456
...
...

Until all the textures you need for the current state (depends of course on your position, the theater data etc) are loaded and the quads are rendered by the GPU. So think that if you are using more textures for your theater, you will need more draw calls right? So we now we can say that: More tile textures = More draw calls.

Now, why draw calls are expensive? you can read about it on the net, but I have found this explanation in stack overflow:
http://stackoverflow.com/questions/4853856/why-are-draw-calls-expensive

And specifically this:

The main reason to make fewer draw calls is that graphics hardware can transform and render triangles much faster than you can submit them. If you submit few triangles with each call, you will be completely bound by the CPU and the GPU will be mostly idle. The CPU won’t be able to feed the GPU fast enough.

Making a single draw call with two triangles is cheap, but if you submit too little data with each call, you won’t have enough CPU time to submit as much geometry to the GPU as you could have.

Think of it this way. For example, in order to render a simple cube you need 12 triangles, let’s leave texture a side for now. You can draw it in many ways but let’s take the edge cases.
Let’s assume for a sec that drawing 1 triangles by the GPU takes 1 second and the CPU takes 1 second to prepare data.

1. Draw 1 triangle per a draw call, means u do this:

CPU load 1 tri of side 1 of the cube to GPU vertex buffer --> Time = 1s.
CPU tells GPU to draw 1 tri --> Time = 1s.
...
...
CPU load last tri of side 6 of the cube to GPU vertex buffer --> Time = 1s.
CPU tells GPU to draw 1 tri --> Time = 1s.

How much time you spent? 12s for GPU drawing and 12s for CPU load time right?
total time = 24s

Now let’s see the other way.
2. Draw the cube in a single draw call:

CPU load all 12 tris of the cube to GPU vertex buffer --> Time = 1s + some factor (for preparing additional tris).
CPU tells GPU to draw 12 tris --> Time = 12s.

How much time you spent? 12s for drawing + 1s + some factor which for sure < 12s
total time < 24s –> More like 13 or 14s

Now… take into account that GPU is a parallel machine (WAY more than the CPU, although you can’t really compare because they have different purposes) so actually rendering 12 tris or 1 tri will take more or less same time, of course there is a difference when you start adding tris (to the Millions) but it’s not linear.

Bottom line: Drawing as much as possible with a single draw call is the best you can get from the GPU, because you can this way hold it busy most of time without spending long time in the CPU to prepare the stuff for rendering. Unfortunately in BMS currently we have exactly the opposite situation.

As always, hopefully things will get better in the future. Current cards are very capable, and can practically draw an impressive number of tris very fast, but the correct optimization and draw calls trade-off must be done to achieve such results.

Cheers!

[Earlybite]

@I-Hawk:

So think that if you are using more textures for your theater, you will need more draw calls right?

Is that so? AFAIK depends the amount of “things” to draw (in case of the tiles) on the visibility range (VR)…
If you e.g. have a VR of 15 tiles, then it needs 15x15 tiles to draw.
The difference from 4.32 to 4.33 (and not alone this) is the amount of tiles (~1700 / ~6000).
So, finding the “Add-On”-tiles while flying needs more time in 4.33. But this should not be a great time loss, IMHO / AFAIK.
If so, it would need a better naming for the tiles, maybe in case of a database, where a seeker has fast access to the newest tiles which are needed to add / to draw.

But, and AFAIK, hasn’t changed the VR from 4.32 to 4.33, so there is in both versions still the same amount to draw…
(And the difference of FPS (TGP ON/OFF) is IMO great: 8 FPS in stock 4.32, 20 FPS in 4.32 with 4.33 tiles, up to 30 FPS in 4.33…)

Overall: Thanks for your previous explanations!
Regards
Earlybite

[I-Hawk]

I didn’t get you, what about VR? yes VR does probably decide how many tile textures you will need to render the visible terrain, but VR in BMS is damn minimal already, you suggest to make it even smaller??

But I think you are missing the point of Draw calls, I say it because you posted this:

The difference from 4.32 to 4.33 (and not alone this) is the amount of tiles (~1700 / ~6000).
So, finding the “Add-On”-tiles while flying needs more time in 4.33. But this should not be a great time loss, IMHO / AFAIK.
If so, it would need a better naming for the tiles, maybe in case of a database, where a seeker has fast access to the newest tiles which are needed to add / to draw.

There is no effect in FINDING the tiles/textures/whatever, the CPU does that pretty fast I assure you, the problem is that there are more draw calls BECAUSE there are more textures. The problem is that the system probably reached its limits - The number of textures we have today is already too high and so causing the GPU to be even less efficient than in 4.32, because there are more textures.

Of course it is the artist’s choice to use more tiles textures, because it makes the terrain less repeatative, but it comes with a cost.

[Earlybite]

@I-Hawk:

I didn’t get you, what about VR? yes VR does probably decide how many tile textures you will need to render the visible terrain, but VR in BMS is damn minimal already, you suggest to make it even smaller??

But I think you are missing the point of Draw calls, I say it because you posted this:

There is no effect in FINDING the tiles/textures/whatever, the CPU does that pretty fast I assure you, the problem is that there are more draw calls BECAUSE there are more textures. The problem is that the system probably reached its limits - The number of textures we have today is already too high and so causing the GPU to be even less efficient than in 4.32, because there are more textures.

Of course it is the artist’s choice to use more tiles textures, because it makes the terrain less repeatative, but it comes with a cost.

We can stay with tiles, not mixing tiles and textures, because it shows up that only by changing the tiles (4.33 tiles in 4.32) drops heavily FPS while using (only) TGP. In which 4.32 is not drawing trees and/or grass…
Drawcalls are calls to draw, right? And drawing happens if it needs to been drawn, right? So, why should there be more drawcalls if you only change the amount of the tiles (which are not drawn all at once!)… (You are only seeing what is drawn inside the visual range (e.g. 15x15 tiles, or 30x30 tiles, or whatever)).

So, but I haven’t changed the visual range in 4.32 while using 4.33 tiles, but as soon as I run those 4.33 tiles in 4.32 the FPS-drop (TGP ON/OFF) changed from ~7 FPS to ~20 FPS…

[dema]

@Earlybite:

They are “eating” the FPS…

Just made further tests:
(A single lonly 3 ship over land with TGP and starting in the air by x64, same view)
4.33 Stock 77 TGP 52 Diff = 25 (yesterday I even could notice 80 50 = -30)
4.32 Stock 71 TGP 63 Diff = 8
4.32 4.33 tiles 69 TGP 49 Diff = 20

And especially in 4.33…

Be happy with 77 fps in pit, 50 with tgp.
If you don’t like 4.33 for this “problem” fly with 4.32.
Just my 2 cents, again, your tests are welcome but they have no sense. Take it easy.

[I-Hawk]

@Earlybite:

We can stay with tiles, not mixing tiles and textures, because it shows up that only by changing the tiles (4.33 tiles in 4.32) drops heavily FPS while using (only) TGP. In which 4.32 is not drawing trees and/or grass…
Drawcalls are calls to draw, right? And drawing happens if it needs to been drawn, right? So, why should there be more drawcalls if you only change the amount of the tiles (which are not drawn all at once!)… (You are only seeing what is drawn inside the visual range (e.g. 15x15 tiles, or 30x30 tiles, or whatever)).

So, but I haven’t changed the visual range in 4.32 while using 4.33 tiles, but as soon as I run those 4.33 tiles in 4.32 the FPS-drop (TGP ON/OFF) changed from ~7 FPS to ~20 FPS…

OK I think you still don’t get it

Let’s call them by names:
Tiles = Geometry - Meaning every tile is a square sized 1KMx1KM in the 3D world OK?
Texture = An image that should be drawn into a tile, OK?

So while for a constant VR the number of tiles is constant, in that you are right indeed, you have to take also the number of textures, why? because as I explained above - For every texture that you use you need a draw call, no matter how many tiles are going to be paint with this texture.

Let’s think this:
Let’s take 100 tiles to ease things OK? if all the 100 tiles are painted with the same texture (for example middle of ocean so you need only sea tile, let’s leave alone the water normals etc) so you need 1 draw call only for all 100 tiles.
But if you are in the middle of Korea and you are rendering mountains or grass or whatever, then you may need up to 100 draw calls for the same number tiles, just because each may be using a different texture. Now that said, as many as you have “grouped” to be drawn with the same texture, will reduce the number of draw calls.

So now you may ask why there is a need for more textures right? Because an artist want as less repeatative terrain as possible, so he is using more textures to achieve that, that’s part of the reasons why the 4.33 terrain is more beautiful than 4.32, not only because every texture is better but also because there are more textures used that helps to minimize repeatation.

But, newer engines have more sophisticated ways to give the terrain different looks without using so many textures, you can read for example about multitexturing and texture arrays (a DX11 feature).

And BTW, the trees/grass rendering, while very impressive, use only a single draw call - That’s why they are so efficient and you almost don’t feel their cost, that’s 180 degrees the opposite from the terrain drawing.

BTW, the same play with 3D models, see all the new models in BMS, Tornado, MIG-23, MIG-25 etc etc, you will see all of them are using 1 or 2 large textures, while old models using many small ones, what do you think is more efficient? drawing a 30K tris model with 2 textures or drawing a 10K model with a dozen of textures? I guess you know the answer by now

I hope it’s understood better now.

[Earlybite]

Ok, its meaning by avoiding repaeting the amount of draw calls has raised.
Then this is a problem…
Thank you for the detailed explanations!

@Dema:
4.33 is a beauty and has many improvements (big and small ones) that 4.32 cannot hold. Why abandon 4.33?
But you can also concede that with my rig it is a (little) shock to see that the FPS drops from ~80 to ~50 by only engaging TGP, or that I RTB after campaign mission with stutter at ~22 FPS. That is the thing…
In which I can imaging that a (real) 5.00 GHz CPU would manage a lot…

Regards and
greeting
Earlybite

The present is useless.