Teraz jest Pn 23 cze, 2025 14:53


Optymalna aranżacja tekstur na plikach

Archiwum działów sekcji Operation Flashpoint
  • Autor
  • Wiadomość
Offline
Avatar użytkownika

alderous

Pułkownik

Pułkownik

  • Posty: 1784
  • Dołączył(a): Cz 19 sie, 2004 13:20
  • Lokalizacja: Łódź

Optymalna aranżacja tekstur na plikach

PostCz 20 sty, 2005 10:44

O ile mi wiadomo dobrze jest zebrać tekstury kilku elementów i umieścić w jednym dużym pliku z teksturą (tj. lepiej mieć kilka dużych plików niż dużo małych). W związku z tym zastanawia mnie czy korzystne byłoby w przypadku posiadania kilku plików z teksturami, dobieranie ich w ten sposób że np. najniższy LOD używa wszystkich plików, wyższy LOD nie potrzebuje jednego z plików (bo tekstury które w nim są, dotyczą detali modelu nieobecnych w tym LOD), jeszcze wyższy nie potrzebuje dwóch itd., aż ostatni LOD używa tylko jednego.

Oczywiście to tylko przykład ilustrujący zagadnienie i zazwyczaj nie dałoby się tak tego dobrać, ale myślę że sprawienie aby wyższe LOD w ogóle nie potrzebowały niektórych "plansz" z teksturami, jest wykonalne.
Offline
Avatar użytkownika

offtime

Pułkownik

Pułkownik

  • Posty: 1089
  • Dołączył(a): So 21 sie, 2004 10:39
  • Lokalizacja: Katowice

PostCz 20 sty, 2005 21:15

kwestia zaplanowania ktore czesci beda widoczne w jakich lod'ach
osobiscie preferuje inne rozwiazanie, w dalszych lodach poza znikaniem pewnych detali stosuje rownierz mniejsze rozdzielczosci textur, oraz umieszczanie detali w wolnych miejscach textur ktore i tak beda wykozystane we wszystkich lodach tyle ze w rroznych rozdzielczosciach, ponizej przyklad textury, narazie ciagle wstepna, dojdzie na niej jeszcze kilka detali a te ktore juz sa zapewne upchne bardziej, lub nie, zobacze czy nie bede mial zbyt wiele textur z wolnymi miejscami do wykozystania.

Obrazek
Offline
Avatar użytkownika

Panda

Chorąży

Chorąży

  • Posty: 179
  • Dołączył(a): N 09 sty, 2005 18:33
  • Lokalizacja: Warszawa

PostN 17 lip, 2005 00:00

Odkopie temat.
Czy nie byloby kozystnie umieszczac tekstur uzywanych przez hiddenselections jako oddzielne pliki?
Zastanawiam sie takze czy ma to jakiekolwiek znaczenie... Tekstury upchniete zajmuja moze 5kb mniej, a duze pliki sa kozystne w Win i dosie, natomiast jezeli i tak wszystkie pliki sa juz w RAMie, to dostep do odpowiedniego fragmentu moze zajmowac tyle samo czasu.

Zalozmy, teoretyzujac:
1) engine laduje texy do ram'u. - tutaj aranzacja plikow ma znaczenie, ale najwiecej czasu i tak zajmie odczytanie PBO.
2) engine stwierdza, ze widzimy obiekt.
3) powierzchnie obiektu zostaja uwzglednione przy sprawdzaniu czy nie przebija ich zaden z promieni uzytych do generacji obrazu (jeden promien przypada na piksel).
4) engine sprawdza pozycje (x,y) przebicia danej powierzchni przez dany promien.
5) pozycja ta jest odnajdywana na odpowiedniej teksturze i zwracane sa najblizsze jej piksele (piksel - w zaleznosci od dystansu).
6) nastepuje zaokraglenie i w efekcie przypisanie pikselowi ekranu uzyskanego koloru.

^czy jest jakas roznica, czy tekstur jest 5 czy 20 juz po zainicjowaniu gry, skoro i tak wszystko jest w RAMie i i tak engine kazdorazowo decyduje z ktorej tekstury powinien wziac pikselki z pozycji (x,y)?
Wie ktos moze wlasciwie?
Upychanie tekstur jest tradycja z gier, gdzie tekstura powinna byc kwadratowa. Teraz stosuje sie to chyba tylko aby ulatwic instalacje i ladowanie misji. Czy ma to wplyw na performance - wlasciwie nie wiem, dlatego pytam.

@Offtime - chyba zle robisz robiac inne texy dla LODow. Tekstura o najwiekszej rozdzielczosci caly czas pozostaje w RAMie, a dzieki formatowi 2^ engine moze praktycznie bezkosztowo "zeskalowac ja na mniejsza" bez potrzeby robienia jej kopii - po prostu ignoruje co n-ty piksel (gdzie n jest potega 2) przy wszystkich obliczeniach (stad widoczne czasem rozmycie tkstur).
Robienie oddzielnych tekstur dla LODow zapycha RAM, a efektu nie ma.

Jestes pewien, ze masz racje? Kloci sie to z moja wiedza i teoretyzowaniem na tej wiedzy (malej, ale jakiejs) opartym.

[Edit] Przemyslalem sprawe i stwierdzam ze nie ma tez roznicy w czasie ladowania do RAMu, czy nawet kopiowania pliku PBO.
Jezeli ktos chce i ma dzien wolnego to wytlumacze w tym watku czemu.
Oba pomysly powoduja nie zyski a straty.
Offline
Avatar użytkownika

Diesel

Porucznik

Porucznik

  • Posty: 338
  • Dołączył(a): Wt 20 lip, 2004 12:45
  • Lokalizacja: Lublin

PostN 17 lip, 2005 13:50

Czy nie byloby kozystnie umieszczac tekstur uzywanych przez hiddenselections jako oddzielne pliki?


Zapomniałeś chyba, że tekstury z hiddenselections są rozmyte.


czy jest jakas roznica, czy tekstur jest 5 czy 20 juz po zainicjowaniu gry

Wg. mnie jest, choć nie wytłumaczę Ci tego profesjonalnie :-) Jedynym argumentem jest to, że addony z mniejszą ilością tekstur chodzą u mnie lepiej, niż z 20 teksturami (choć mało który niedawno wydany addon zejdzie poniżej 40 tekstur).
Obrazek
Offline
Avatar użytkownika

offtime

Pułkownik

Pułkownik

  • Posty: 1089
  • Dołączył(a): So 21 sie, 2004 10:39
  • Lokalizacja: Katowice

PostN 17 lip, 2005 15:22

Panda napisał(a):Odkopie temat.
Czy nie byloby kozystnie umieszczac tekstur uzywanych przez hiddenselections jako oddzielne pliki?

textury wczytywane na hidden selections poprzez setobjtexture sa zazwyczaj rozmyte, jesli zostanie taka textura wczytana na samym poczatku to ze wzgledu na fakt iz na tej samej texturze beda tez inne elementy, unikniesz rozmycia.
Panda napisał(a):Zastanawiam sie takze czy ma to jakiekolwiek znaczenie... Tekstury upchniete zajmuja moze 5kb mniej, a duze pliki sa kozystne w Win i dosie, natomiast jezeli i tak wszystkie pliki sa juz w RAMie, to dostep do odpowiedniego fragmentu moze zajmowac tyle samo czasu.

pozostaje jeszcze kwestia odczytania kazdego headera pliku z textura przy wczytywaniu, i poznijszej alokacji textur w pamieci, czas dostepu jest szybszy kiedy obeuje sie w obrebie jednego duzego pliku, tak twierdza przynajmniej fachowcy.
Panda napisał(a):Zalozmy, teoretyzujac:
1) engine laduje texy do ram'u. - tutaj aranzacja plikow ma znaczenie, ale najwiecej czasu i tak zajmie odczytanie PBO.
2) engine stwierdza, ze widzimy obiekt.
3) powierzchnie obiektu zostaja uwzglednione przy sprawdzaniu czy nie przebija ich zaden z promieni uzytych do generacji obrazu (jeden promien przypada na piksel).
4) engine sprawdza pozycje (x,y) przebicia danej powierzchni przez dany promien.
5) pozycja ta jest odnajdywana na odpowiedniej teksturze i zwracane sa najblizsze jej piksele (piksel - w zaleznosci od dystansu).
6) nastepuje zaokraglenie i w efekcie przypisanie pikselowi ekranu uzyskanego koloru.

^czy jest jakas roznica, czy tekstur jest 5 czy 20 juz po zainicjowaniu gry, skoro i tak wszystko jest w RAMie i i tak engine kazdorazowo decyduje z ktorej tekstury powinien wziac pikselki z pozycji (x,y)?
Wie ktos moze wlasciwie?
Upychanie tekstur jest tradycja z gier, gdzie tekstura powinna byc kwadratowa. Teraz stosuje sie to chyba tylko aby ulatwic instalacje i ladowanie misji. Czy ma to wplyw na performance - wlasciwie nie wiem, dlatego pytam.

z tego co slyszalem operacje w pamieci szybciej sa wykonywane jesli dziala sie w obrebie jednego pliku, nie zaglebialem sie nigdy w ten temat, jesli ktos kogo uwazam za wiarygodne zrodlo mowi mi ze tak jest to poprostu przyjmuje to do wiadomosci.
robienie textur na jednym pliku dodaje czasami probleemow przy nakladaniu textur, zwlaszcza w o2, ale program lithUnwrap niweluje ten mankament. szczerze polecam.

Panda napisał(a):@Offtime - chyba zle robisz robiac inne texy dla LODow. Tekstura o najwiekszej rozdzielczosci caly czas pozostaje w RAMie, a dzieki formatowi 2^ engine moze praktycznie bezkosztowo "zeskalowac ja na mniejsza" bez potrzeby robienia jej kopii - po prostu ignoruje co n-ty piksel (gdzie n jest potega 2) przy wszystkich obliczeniach (stad widoczne czasem rozmycie tkstur).
Robienie oddzielnych tekstur dla LODow zapycha RAM, a efektu nie ma.

Jestes pewien, ze masz racje? Kloci sie to z moja wiedza i teoretyzowaniem na tej wiedzy (malej, ale jakiejs) opartym.

jakis czas temu poczytalem sobie o mipmapach, teraz tez uwazam ze robienie textur dla odleglych lod mija sie z celem, no chyba ze w ostatnim lod textura jest naprawde mala i uboga, wtedy te 100 kilo wiecej w pamieci rekompensowane jest szybszym czasem renderowania.
Odnosnie mipmap zauwazylem tez co oslawiony program paatool robi z mipmapami przy wiekszosci efektow jakie posiada - totalnie pieprzy je.
w texwiev jest mozliwosc obejrzenia mipmap, proponuje sie przyjrzec destrukcyjnym efektom paatoola i pewnych efektow w nim unikac.
Panda napisał(a):[Edit] Przemyslalem sprawe i stwierdzam ze nie ma tez roznicy w czasie ladowania do RAMu, czy nawet kopiowania pliku PBO.
Jezeli ktos chce i ma dzien wolnego to wytlumacze w tym watku czemu.
Oba pomysly powoduja nie zyski a straty.

a mi sie wydaje ze ma znaczenie, aby dostrzec roznice musialbys potestowac troche dwa rozne kompy, skrajnie slaby i jakis bardziej "na czasie". nie sestesmy przy jednym czy dwoch addonach wyczuc roznicy, ale z pewnoscia ona jest, i jak to zazwyczaj bywa, kilka nanosekund tam, kilka tu i juz mamy lagujace CSLA.
Offline
Avatar użytkownika

Panda

Chorąży

Chorąży

  • Posty: 179
  • Dołączył(a): N 09 sty, 2005 18:33
  • Lokalizacja: Warszawa

PostN 17 lip, 2005 17:55

Dobra tlumacze:
P{rzewaga jednego pliku nad wieloma w win/dos polega na tym, ze komp stara sie zapisac taki plik w jednym miejscu, zas wiele plikow bedzie rozrzucone tam gdzie poasuja w dziory na krazku powstale po wykasywaniu lub rearanzacji danych. Opoznienie ma chrakter hardwareowy, gdyz zczytujac glowica jezdzi z miejsca w miejsce.
Uzycie formatu spakowanego PBO powoduje, ze dla win/dos archiwum jest jednym plikiem - to czy w srpodku jest jedna, czy 2000 tekstur nie ma rzutu na predkosc odczytu z dysku. Nie ma tez duzego rzutu na rozpakowywanie, gdyz w trakcie procesu dane z PBO trafiaja do RAMU i tam juz zostaja.
Zip ma lepsza kompresje, jednak poza wymogami licencji jest jeszcze jeden powod dla ktorego sie go nie uzywa - wymagaloby to rozpakowanie pliku do tymczasowego folderu i dopiero stamtad ladowanie w ram.

Teraz RAM: wszelkie Twoje rozwazania skwituje jednym - w ramie nie ma plikow. RAM ma charakter ciagly, nie posiada tablic alokacji ani innego szita - dlatyego jest taki szybki.
Adresy zas sa wszystkie bardzo dlugie i nie ma znaczenia czy potrzebny bajt jest jeden czy 10000 bajtow dalej - oszczednosci na odwolaniu do niego nie bedzie.

Ram jest zupelnie odrebnym typem pamieci. Tam wszystko jest poszatkowane i namieszane, pliki znajduja soie porozrzucane w wielu miejscach... W RAMie pliki nie istnieja - bazuje on na wielocyfrowych adresach a kazdy bit i bajt jest zwracany oddzielnie.

Co do porownywania addonow - jezeli mowisz o dwu roznych addonach, to nie mamy o czym rozmawiac.
Laga moze zmniejszac np. inna paleta barw - ktora okaze sie latwiejsza w obliczeniach, bo jakis kolor miejscami wogole nie wystepuje.

REASUMUJAC:
-W win/dos PBO to jeden plik.
-Zeby w RAMie zobaczyc plik trzebaby zazywac LSD.
-Jesli komus cos sie zdaje prawdoppodobnie przyczyny sa inne.

Co do rozmycia - dzieki, dobrze wiedziec :D. Na pewno skorzystam.
Offline
Avatar użytkownika

offtime

Pułkownik

Pułkownik

  • Posty: 1089
  • Dołączył(a): So 21 sie, 2004 10:39
  • Lokalizacja: Katowice

PostN 17 lip, 2005 19:07

no to z innej strony.
czerwona linia na dolaczonym obrazku to srodek textury o wymiarze 512x128
nalozymy ja na model o jakiejstam wielkosci i uzyskamy jakiestam zageszczenie UV.
jesli to rozbic na dwie textury ktore laczna powierzchnia odpowiadalyby pierwszej, uniemozliwiloby to narysowanie tych bokow pojazdu z takim samym zageszczeniem UV.
pod zageszczeniem UV rozumie ilosc pikseli przypadajacych na jakas tam powierzchnie modelu.
dodatkowe miejsce ktore moznaby wykozystac na texturze, w przypadku polaczonej tekstury, mozna lepiej i efektywniej wykozystac do otekesturowania innych elementow.

podsumowujac:
1. na laczonych texturach mozna lepiej zagospodarowac pozostale miejsce do otexturowania dodatkowych elementow, zmiejszajac liczbe textur, zwalniajac miejsce w pamieci.
2. mozna przygotowac texture w lepszej jakosci przy takiej samej powierzchni calkowitej jak przy kilku texturach.

uparles sie na wielokrotne textury podwazajac teorie szybkosi obslugi textur w pamieci. i chyba masz racje.
no ale tej teorii nie podwazysz ;-)

Obrazek
sprobuj narysowac ten bok pojazdu na dwoch texturach 256x128 tak aby zachowac gestosc UV a co za tym idzie, jakosc.

gdybys przeprowadzil test w ktorym ten sam model texturowalbys raz kilkoma miejszymi texturami i drugi raz jedna wielka, nie dalbys rady zachowac takiej samej jakosci textur chcac zachowac identyczna powierzchnie łączną textur w obu przypadkach.
a powierzchnia textur to odpowiedni rozmiar zajetej pamieci.

dodatkowo zastanawiam sie czy w przypadku kilku plikow ktore jak wiemy zawieraja jakies naglowki nie lepiej jest stosowac jeden plik z jednym naglowkiem, oszczedzajac w ten sposob ulamek pamieci, ziarnko do ziarnka... ;-)

mam nadzieje z nie zamotalem, jak cos to moge sprobowac wytlumaczyc inaczej ;-)
Offline
Avatar użytkownika

Panda

Chorąży

Chorąży

  • Posty: 179
  • Dołączył(a): N 09 sty, 2005 18:33
  • Lokalizacja: Warszawa

PostN 17 lip, 2005 19:27

Nie, wszystko zrozumialem za jednym razem.
W tym przypadku sie zgadzam, gdybys np. oddzielil przod obu tekstur tez byloby zle.
Natomiast pozostawienie bialej powierzchni niekoniecznie musi przeszkadzac. Trzebaby sprawdzic czy pac ma ten sam rozmiar na dysku zarowno w przypadku rysunku jak i bialej planszy...
Jezeli tak, to zgadzam sie (na wszelki wypadek sam Twoja technike stosuje, tym bardziej, ze wtedy mniej mnie ogranicza limit 2^nx2^m i moge robic np. teksture w proporcjach 1:3 a pozostale miejsce zagospodarowaci innymi dwoma, nierownych wymiarow).
Natomiast posiadanie texow w oddzielnych plikach pozwala mi np. zrobic teksture rury wydechowej w formacie 1x8 zamiast np. 32x8 - gdyz tekstura bedzie sie powtazac na tej samej powierzchni, albo zrobic zawiasy jako kilkakrotne powtozenie na tej samej zasadzie i zaoszczedzic kilkanascie kilo RAMu na addonie... a takze troche pracy.

eee... nie optuje za "wielokrotnymi" teksturami... Po prostu tam gdzie nie ma roznicy nie trzeba kombinowac - zaoszczedzisz kilka godzin na addonie, plus jak ktos ma malo ramu woli pracowac na mniejszych plikach i na mniejszej ilosci warstw.
Offline
Avatar użytkownika

offtime

Pułkownik

Pułkownik

  • Posty: 1089
  • Dołączył(a): So 21 sie, 2004 10:39
  • Lokalizacja: Katowice

PostN 17 lip, 2005 19:51

jesli nauczysz sie sprawnie texturowac, a co za tym idzie wymiarowac textury w o2, nie bedzie Ci robilo roznicy czy to jedna wielka czy kilka malych ;-) ale aktycznie, czasami ciezko jest "ustawic" texture do mapowania, ale wtedy zawsze mozna urzyc odpowiedniego softu, takiego jak lithUnwrap...
a oszczednosc na pamieci (nawet jesli textura jest pusta/biala to i tak zajmuje jakiestam miejsce) lub ewentualnie polepszenie jakosci zawsze bedzie faktem.

inna ciekawa prawa to to ze jesli stosunek x do y w gestosci UV jest rowny lub bliski 1 to mamy do czynienia z widoczna poprawa jakosci wyswietlanej textury. a to dlatego ze zadne piksele nie sa nieproporcjonalnie "rozciagane"
wiele textur BIS'u jest "sciśnietych" do wymiarow 2^nx2^m co owocuje utrata jakosci wyswietlania....
troche o tym ostatnio czytam...
ludzie sa dociekliwi i niewąskie prace pisza na te tematy ;-)
Offline

Mr0Buggy

Szeregowy

Szeregowy

  • Posty: 24
  • Dołączył(a): Śr 08 cze, 2005 17:07

PostN 17 lip, 2005 19:58

A mógłbyś zapodać jakieś linkii do tego softu ?? Sorry za OT.
Offline
Avatar użytkownika

offtime

Pułkownik

Pułkownik

  • Posty: 1089
  • Dołączył(a): So 21 sie, 2004 10:39
  • Lokalizacja: Katowice

PostN 17 lip, 2005 20:24

http://www.csk.pl/~neochan/ofpc/viewtopic.php?t=1314

czesc "textury"
program LithUnwrap np
a w czesci "konwertowanie" program P2MS

oba narzedzia niezbedne do mapowania "z poza o2", czyli kiedy mapowanie w o2 doprowadza Cie do bialej goraczki ;-)
Offline
Avatar użytkownika

Panda

Chorąży

Chorąży

  • Posty: 179
  • Dołączył(a): N 09 sty, 2005 18:33
  • Lokalizacja: Warszawa

PostPn 18 lip, 2005 19:54

Ok jeszcze jeden komentarz: mozliwe ze na niektorych kartach graficznych istnieje roznica i lepiej uzywac duzych tekstur ze wzgledu na ich aranzacje w pamieci karty. Jednak jesli wasza karta nie ma duzo pamieci to nie musicie sie tym martwic, gdyz i tak wszystko leci z RAMu a pamiec karty w pierwszej kolejnosci bedzie zuzyta na powierzchnie, obiekty itp... To tak tylko k-woi scislosci.
Szczeze: z naszymi sprzetami to sie nie ma co martwic :twisted: . Mozliwe tez ze problem zniknie po wydaniu upgradeow Biosu (chyba ze nie ma mozliwosci) albo sterownikuw albo czegos w tym stylu... tak bywalo w przeszlosci. :twisted:
Nie oszukujmy sie - kupujac nowa karte w mniej niz rok po wydaniu prosimy sie o problemy. :wink: Wiekszosc kart wydaje sie z niepelnymi, niezoptymalizowanymi driverami, podobnie tez jest z grami - to ogolny trend.
Offline
Avatar użytkownika

Marcin_BM

Porucznik

Porucznik

  • Posty: 330
  • Dołączył(a): N 25 lip, 2004 20:49

PostPn 18 lip, 2005 21:23

A ma ktos moze jakis tutorial odnosnie mapowania w lightunwarp
Ten który rzucił na mnie się niewiele szczęścia miał,Bo wypadł prosto mi na kły i krew trysnęła z rany
Online

xersius

Pułkownik

Pułkownik

  • Posty: 99987
  • Dołączył(a): Pn 29 lip, 2024 15:01

Re: Optymalna aranżacja tekstur na plikach

Online

xersius

Pułkownik

Pułkownik

  • Posty: 99987
  • Dołączył(a): Pn 29 lip, 2024 15:01

Re: Optymalna aranżacja tekstur na plikach

PostN 08 wrz, 2024 15:44

сайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайт
сайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайт
сайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайт
сайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайт
сайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайт
сайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайт
сайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайт
сайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайт
сайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайт
сайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтсайтtuchkasсайтсайт
Następna strona

Powrót do Operation Flashpoint

Kto przegląda forum

Użytkownicy przeglądający ten dział: xersius i 12 gości

cron