Závorku klidně nečíst:
(No chápu, že mluvíš o pozemních texturách a .bgl, ale podle mě je problém ten, že zatímco obrázek otevřeš a víš kolik má pixelů a z toho plyne i velikost v kB, tak u .bgl těžko stanovíš nějakou základní jednotku, ke které budeš porovnávat rozsah. Tak jak já si dělám podkladní scenerky pod letiště, rozsah pár km čtverečních, tak vždycky výchozí obrázek má jiný rozměry a nejsou to ani mocniny 2. Resample.exe to pak přechroustá, ale těžko se dopátrám jak to v sobě uloží. A nevím ani jestli si k nějakému základnímu čtverci (tilu) doplní obrázky průhledně, nebo jestli se s tím vypořádá a zvládne to bez doplnění. Proto říkám, že ty potřebuješ otevřít .bgl (což je problém), abys do něj viděl, nebo už mít ten algoritmus na to uložení. )
To asi zkusit napsat na Fs developeru "Arno"(ovi) a zeptat se jeho, toho jsem chápal jako otce Fs developer webu.
ALE, pokud budeš chtít přijít s lepším algoritmem na bglka, tak bych si dovolil zmínit jiný postřeh:
Ty uděláš efektivnější archivování a zmenšíš 4x všechny ty obrovský archivy, tak nutně bude muset počítač při každým načítání provádět rozbalování a zobrazování složitější.
Proč si to myslím,
Je to tak 2 roky co jsem se začal zabývat stavbou mapy v OMSI. Ve fázi takového nastavování konceptu jsem řešil, jaký formát na textury objektů použít, protože podpora v programu byla dobrá: dds, bmp, png, jpg, tga...
Samozřejmě jsem odzkoušel na ten stejný objekt všechny a zatímco png byly asi 4x menší než dds textury, tak png textury se dost dýl načítaly. Zřetelně jsem viděl bílý model bez textur po delší dobu, odhaduju na sekundu (a to tam bylo pár domečků a ten s testovací texturou jen jeden. (a textura měla něco kolem 1024x1024).
Závěr: Aby se to nedostalo do stejné situace a výhody a nevýhody se vynulují, nebo hůř. |
|
