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.