Jump to content
Sign in to follow this  
bravo 6

Question: How long does your island/terrain takes to load ingame/editor?

Recommended Posts

I would like to ask this question to average and common island/terrain maker:

How long does your island/terrain takes to load ingame/editor?

Ie, if you go to edit and click your island how long does it take to open the map in editor?

My current Terrain size is set to 20480x20480 with 40x40 meters value set in Texture Layers, and i take like 4 mins to load the map. The file so far have 688mb, takes some time to load in editor but is it very fluid even for my old crappy computer (P4@3Ghz, 2Gb Ram ddr400, Ati X1950pro 512mb) using 10km View Distance

If you have a similar terrain size can you tell me how long does you island/terrain loads?

Share this post


Link to post
Share on other sites

Is it binarized or not? Makes big difference in loading time.

Share this post


Link to post
Share on other sites

Yes binarized, after using the program "BinPBO Personal Edition" from BI tools.

Share this post


Link to post
Share on other sites

Thats a similar size to my WIP island... It sounds very slow... I'll check mine, but I'm sure it loads a good bit faster than that...

*edit*

OK... Just tested my terrain... took exactly 26 seconds to load in editor...

Terrain size = 20x20km, 10m cell, 40m grid - filesize = 395,413KB

Bushplants.pbo (custom plants) filesize = 217,087KB

Bushmodels.pbo (custom models) filesize = 92,314KB

Now my landscape is still at the kinda empty stage - no trees yet on that version, so I tried Chernarus as well - that took 32 seconds... so 4 minutes is definitely a bit excessive! (and 668MB sounds quite big - the 3 files which make up Chernarus total around 360MB, for example)...

Like andersson, my first thought was - is it binarised? but since it is I'm not sure what to think next...

Is there anything unusual in the BINpbo log? No errors during binarising or during testing in-editor? Are you absolutely sure it binarised OK?

Maybe you could post a BINpbo log (maybe use the "spoiler" tab if its huge), there might be a clue in there...

B

Edited by Bushlurker

Share this post


Link to post
Share on other sites

Here are the figures from my WIP Tropica island

Terrain grid size : 2048x2048

Terrain cell : 10

terrain size (m) : 20480.0x20480.0

Loading the map in Editor in game : 11"

Size of the loaded .pbo :

Tropica.pbo : 105 MB

Tropica_objets.pbo : 1.3 MB

brg_africa.pbo : 19 MB

but ...

Loading the map .pew in Visitor3 : 22"

Getting a view of the map in Buldozer : 1'16"

Having previously build a rather small maps such as Winter Pomegratskaya or WIP Brik, I believe that that the load speed depends on many parameters related to the various objects involved, their amount of course and also how they are built.

I think also that the speed of the CPU, the amount of RAM and more the GPU and videoRAM speed on the graphic card are playing their part in this.

I had switched from 2GB to 4GB RAM and from nice old 1950Pro 512Mb to 4870 Vapor-x 1Mb as I was already making maps and the effect was quite nice ^^. The CPU is still the sturdy E6600 Core 2 Duo I bought when I switch from OFP to ArmA and had to left my OFP rig behind ... :(

Edited by Old Bear

Share this post


Link to post
Share on other sites

I too am having problems with my island loading. I had it working fine beforein Vista, then I installed Windows 7 a while ago and copied the files onto an external hard drive and now put it back on. However, now I find it takes a very long time to load in editor and I usually give up and quit arma2.

Not sure what is making the difference. I am using a 4096x4096 grid and 10m cell and tried both 40x40m and 80x80m texture layers.

I have tried using a 20480x20480 pixel satellite map which I know is big but I have managed to get it to load quickly in the past and now trying a 29696x29696 pixel satellite map for better quality. The 20480 version ends up as a 200mb pbo and the 29696 version about 400mb. These are without objects on them...:j:

Share this post


Link to post
Share on other sites

The Sat_lco image is definitely the single biggest factor in island project size...

My current 2048x2048 island has a 20480x20480 Sat image = 395MB, whereas experiments with the same terrain, no changes at all apart from a 28672x28672 Sat image pushed the final terrain filesize to 788MB...

Looked great... well, definitely better, but I'm not sure it's 370mb+ extra download better...

Currently I'm back to 20480x20480...

B

*edit* - tested loading time in-editor there with a backup copy of my 28K version... 32 seconds to load... not much difference from the 20K sat image version...

There has to be another factor involved in bravo6's problem...

Edited by Bushlurker

Share this post


Link to post
Share on other sites

I notice from all of you all files are below 500mb, mine have 666mb just the terrain, not the other pbos (roads, trees, buildings, etc) all together is about 900mb.

Maybe thats why it takes too many time?

Share this post


Link to post
Share on other sites

Ok, maybe its time to ask it as clear as possible..

How big is your terrain layers folder?

like this:

"P:\Iraqborder\data\Layers", how big is it? mine is 610 mb and it contains 11.199 files

Share this post


Link to post
Share on other sites

"P:\Bush\LFA14\data\Layers" = 1.08GB, 14,981 files...

After BINpbo, the resulting LFA14.pbo is 367MB

B

Share this post


Link to post
Share on other sites

Well i don't understand why my terrain loads slower then your.. should be loading faster actually.

I wonder what am I doing wrong so my terrain takes so many time do load :\

I also use BinPBO.

Share this post


Link to post
Share on other sites

The final file you're getting seems awful big at 600MB+...

Maybe something isn't actually binarizing correctly? It almost sounds as if the layers folder is just being copied directly and not binarized at all...??

Could you maybe post a screenshot of all your BINpbo settings, and maybe a .log file too? There might be a clue in there somewhere...

B

Share this post


Link to post
Share on other sites

Are you remembering to remove the png files from the "P:\Iraqborder\data\layers" folder?

Share this post


Link to post
Share on other sites
Are you remembering to remove the png files from the "P:\Iraqborder\data\layers" folder?

If anyone is using BinPBO correctly you never need to do anything like this.

If you use BinPBO, and are not getting errors (tick the log box and look at the log) that fail the Binarization process, then BinPBO creates a smaller binarized PBO for you.

Note, it usually still creates a usable PBO for you even it you have certain errors, but you will find the wrp file within the PBO is NOT binarized.

Share this post


Link to post
Share on other sites

Ok, im just doing what worked for me.

The log file for mines reads:

skye\data\cr_sterk_mco.paa->C:\Users\Craig\AppData\Local\Temp\ARMAaddons\skye\data\cr_sterk_mco.paa
... (same for each texture)

skye\data\layers\s_000_000_lco.paa->C:\Users\Craig\AppData\Local\Temp\ARMAaddons\skye\data\layers\s_000_000_lco.paa
skye\data\layers\m_000_000_lco.paa->C:\Users\Craig\AppData\Local\Temp\ARMAaddons\skye\data\layers\m_000_000_lco.paa
... (same for rest)

skye\data\layers\p_018-023_n_n_l02_l04.rvmat->C:\Users\Craig\AppData\Local\Temp\ARMAaddons\skye\data\layers\p_018-023_n_n_l02_l04.rvmat
... etc

Found p:\skye\Data\Layers\textures.lst, inserting textures not linked by .p3d-s...
Convert world p:\skye\Skye.wrp -> C:\Users\Craig\AppData\Local\Temp\ARMAaddons\skye\Skye.wrp
No entry 'C:\Program Files (x86)\Bohemia Interactive\Tools\BinMake\Binarize\bin\config.cpp/CfgSurfaceCharacters.SparseWeedsClutter'.
No entry '.probability'.
Size: '/' not an array
Default clutter names TypeX used for /
<world = "p:\skye\Skye.wrp">
String STR_LOCATION_KHESANH not found
String STR_LOCATION_KAMENYY not found
String STR_LOCATION_KHESANH not found
String STR_LOCATION_KAMENYY not found
</world>

I know the clutter error still remains as with the STR_LOCATION things. I took it the text about the textures etc was just showing that it was creating a new path to them.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×