Pomógł: 105 razy Wiek: 39 Dołączył: 19 Lut 2008 Posty: 5160 Skąd: Warszawa
Wysłany: 11-01-2009, 11:42 Kilka uwag jak to należy robić.
Temat wałkowany "od zawsze". Ostatnio paru autorów popisywało się swoimi osiągnieciami w te klocki, niemniej nadal jest rzesza ludzi którzy przedkładają trawkę w odległości 400m od kamery nad grywalność a potem ich cholera bierze że im Trainz po 20km szlaku wylatuje w powietrze.
Więc krótki temacik w moim wydaniu "jak to się robi". Nie ma tu nic z autolansu ani poprawy własnego ego. W tej kwestii jednakże przeszedłem długą drogę i mam coś do powiedzenia.
Mapy powinny być lekkie. Powinny być lekkie z następujących przyczyn:
-Możliwości silnika TRSa.
-Możliwości naszych kart graficznych/procesorów.
-Chęci budowy dalej i więcej.
-Chęci posiadania realnej i znacznej liczby taboru na gotowej mapie.
-Nieudolność wielu autorów w godzeniu lekkości i jakości w dodatkach które tworzą.
Biorąc to pod uwagę wszelkie podejście typu "ja wiem lepiej, ja mam mocnego kompa, a mi się uda" natychmiast skazane jest na porażkę prędzej czy później, ewentualnie powstaje produkt w który nie da się grać, da się go oglądać, ale przyrównałbym go do kupienia za 2500zł modelu parowozu Trix'a i postawieniu go na półkę. Sztuka dla sztuki.
Trzy uwagi z cyklu "podstawy":
-Najbardziej niesprawny element obsługi TRS to grafika -> ilość kb na dodatek.
-Polygony zaczynają być odczuwalne tylko w bardzo dużych ilościach -> np. 4000+
-Procesor i RAM spełnia rolę drgugorzędną, obsługa ilości maszynistów itp itd.
Wynika z tego w prostej linii że dokładniejsze modelowanie przy oszczędniejszej i bardziej powtarzalnej grafice daje lepsze efekty grywalności.
Trzy screeny z budowanej mapy:
Proszę przyjrzeć się skrinom i następującym w nich tematom: układ zieleni, relacja trawy FMA spline i trawy scenery, ilość i rodzaje zastosowanych roślin, teksturowanie, relacja obiektów 3d i tekstur pod nimi.
Po kolei:
Screen z torem po środku: Trawa FMA spełnia tylko rolę 1 planową. Uzupełniona jest w niewielkim stopniu trawą "caddylars" Jankvisa z DLS, co przy złożonym wielokolorowym teksturowaniu pozwala na złudzenie optyczne, zwłaszcza z niższych perspektyw że trawa tak naprawde wcale nie znika. Ważna jest ilość trawy JVC jak i jej rodzaje. Jest tylko 2 rodzaje trawy stałej + żółty spline, nie za gęsto. Przeplatane krzakami i drzewami by nie było sztucznej monotonii i wprowadzić zróżnicowanie odbioru przestrzeni. Najważniejszy element: teksturowanie. Spasowane z dodatkami. Pod żółtym drzewem tekstura imitująca jednocześnie cień i opadłe liście (kolor), pod trawą spline przy torze tekstura sugerująca wyschniętą trawę, w rowie tekstura udająca podmokły grunt, ciemną trawę, ciemne tekstury ydające cień pod krzakami. widoczna w tle ciemna tekstura pod zorganizowanym lasem. Tylko 4-6 rodzaji drzew, 1 rodzaj spline krzaków, 1 rodzaj krzaków scenery. Dodatki o małych teksturach (drzewa spline voytasa) na dalszym planie. Bardzo oszczędna ilość dodatków. Efekt? Sami oceńcie.
Screen z dwutorem i siecią trakcyjną. Dodatki ciężkie animoane dokładne na 1 planie. Słupki, chłopiec, dalej widoczna przyczepa 3d sony'ego na polu. Identyczny schemat. Trawa spline wzdłuż tory, wzdłuż samego toru wąski pas żółtej suchej trawy, dalej wysoki pas szerokiej żółtej trawy. krzaki na granicy widoczności trawy z teksturą pola (złudzenie łagodnego przechodzenia z 3d w samą teksturę), dokładniejsze domki Jacka bliżej, mniej dokładne obiekty z rozmazanymi teksturami dalej. Minimalizacja ilości użytych dodatków. Powtarzalność.
Screen bez tekstur. A tak to wygląda na goło po ułożeniu dodatków. Tekstury wykonuję na końcu dopasowując je do dodatków. Tu bardzo ładnie widać korelację znikającej trawy spline FMA i nie-znikającej trawy scenery JVC. Tekstury jeszcze nie ma (dużo dającej wizualnie) a już powstaje złudzenie że trawa wcale nie znika (kwesia spasowania kolorystki traw). Reszta jw. Powtarzalne dodatki, małe zróżnicowanie, umiejętne budowanie z tych samych obiektów -> duże miasto można zbudowac z maksymalnie 20 obiektów powtarzając je i paru płotów FMA + kilka obiektów indywidualnych typu auta sony'ego, ludziki Neoklaia. Na tym skrinie pod wieżami wodnymi widać takie obiekty. Po lewej seria szop od Jacka, idealne plany tuż-obok-toru, oraz dwa samochody Sony'ego. Po lewej widoczne obiekty 1 planowe indywidualne, żuraw JDS i nastawnia Zgreda07. Obiektów 1 planowych indywidualnych nie można dublować i zastępować ekonomią. One są wpisane w poświęcenie ekonomii. Dublowanie dotyczy otoczenia, roślin, traw, domów mieszkalnych, fabryk itp.
Żeby było ładnie nie musi być bogato. Znów powraca kwestia umiejętnego budowania.
Kilan zapomniałeś dodać kilka słów o budowie szlaku gdzieś w lesie, zwłaszcza na pałąskich odcinkach, wystarczy dosłownie rząd kilku drzew, umiejętne wykorzystanie tła i mamy bujny las :) no i jeszcze tekstury ziemii imitujące cień rzucany przez drzewa.
Pomógł: 31 razy Wiek: 40 Dołączył: 24 Mar 2008 Posty: 808 Skąd: Poznań/Kołobrzeg
Wysłany: 11-01-2009, 13:22
A jak ktos stawia na spora ilosc maszynistow AI to procesor i RAM jest najwazniejszy i mozna sobie smialo odpuscic prace nad otoczeniem ;) (zwlaszcza ze takie mapy raczej nie wychodza poza kompa tworzacego).
KGrid [Usunięty]
Wysłany: 11-01-2009, 13:26
Mi się dodatki serii JVC totalnie nie podobają. O ile merytorycznie Kilan napisał najlepsze sposoby na lekkość to dobór traw już mi nie pasuję. Sposób jaki Kilan ukazał to podwójne kładzenie traw, czyli trawa FMA oraz trawa JVC. Trawa FMA jak wiadomo jest lekka, ładna i oryginalna, ale JVC wydaje się sztuczna, nie ważne jaki typ, ale brakuje jej "czegoś". Jak wiele osób zauważyło na moich mapkach ja stosuję serię FMA + Greenery. Tutaj Kilan napisał że jest to przeskalowana, przeciążona trawa. Zgadzam się, jest ciężka, ale wtedy gdy napcha się kilka typów tejże trawy. Wtedy mamy N razy buforowania grafiki. Ale gdy stosujemy FMA + jeden typ Greenery? Jest ładnie, lekko i przyjemnie. Proszę obejrzeć sobie screeny w tym temacie: http://www.trainz.pl/_forum/viewtopic.php?t=1536
Także rotacja seriami trawska dozwolona. Ja jednak uważam że aby było ładnie nie musi być ciężko, ale nie musi być iście i chorobliwie lekko. Cóż, każdy ma swój styl budowy map, każdy ma swoje gusta. O gustach się nie dyskutuje.
Pzdr
Pomógł: 105 razy Wiek: 39 Dołączył: 19 Lut 2008 Posty: 5160 Skąd: Warszawa
Wysłany: 11-01-2009, 14:22
Nie wiem czy zauważyłeś ale pierwsze pół Twojego posta jest zaprzeczeniem drugiego pół.Z przodu sprzedajesz opinie o swoim guście i swoje opinie a dalej piszesz że o gustach sie nie dyskutuje.
Są tu tacy autorzy którzy "greenery" używali zanim Twoja najdłuższa mapa przekroczyła 10km i mają na temat greenery opinie taką a nie inną. A to nie jest temat do pokazywania ile sie ma do gadania o swoich ulubionych dodatkach, tylko jakie triki stosować żeby na mapie było lekko. W moim przypadku z użytkiem preferowanych przeze mnie dodatków. Kto inny zrobi sobie z innnych.
Nie wiem czy zauważyłeś że na początku swojego postu wypowiedziałem zdanie o swoim guście. Zaś na końcu stwierdziłem że się o nich nie dyskutuje, metaforycznie mówiąc chodziło o to ażeby nie rozpoczynać jakiejś bezsensownej wymiany zdań na temat wyższości trawy X z trawą Y lub na odwrót. Style są różne, gusta również. Jaką trawę wybierzesz - decyzja należy do Ciebie.
Obawiam się że moja "najdłuższa" mapa przekroczyła 10km w czasach gdy PTT jeszcze nie istniało. Więc jak mogła istnieć ta trawa? Ahh... kocham czasy typowego, podstawowego Trainza. Tak naprawdę próba doskonalenia to ciągła praca dot. rozwikłania jak czegoś się używa, a nie całkowite rotacyjne używanie i zmienianie dodatków, żeby przekonać się co jest lepsze. Ot takie moje skromne zdanie.
Od dużych fiatów nastąpiła u mnie mała rewolucja. Pojazdy mają mało poly oraz małe tekstury. Do tego dochodzi LOD. Innym przykładem jest poprawianie dodatków czyli Ikarus 280.
Ogólnie z prawie 350 poly na pojazd poprzednio obecne mają po max 200 i dodatkowo LOD.
Trawa FMA jak wiadomo jest lekka, ładna i oryginalna
Ładna może i jest... z tą lekkością bym jednak uważał. Zobacz sam ile to waży, jesli chodzi o trójkąty.
Generalnie nie można na ten typ trawy narzekać zbytnio... jedyny chyba minus, to ten zasugerowany powyżej.
Na wielki plus jest to, że jest trawach zastosowany LOD. Jednakże siatka tego odchudzenia jest tylko jedna i ma 8 poly (niewidoczny obiekt). Można bylo jeszcze się pokusić o fazę przejściową. Napewno coniektórzy nie musięliby wydłużać we wpisach widoczności trawska.
Kolejny plus to oszczednosc karty graficznej ze wzgledu na rozdzielczosc plikow graficznych.
Sam stosuję tą trawę (może dlatego, że nie ma lepszej), jednakże z rozwagą, bo i tak mój komp choruje od zbyt dużej liczby dodatków na mapie.
Bardzo dziękuję Wam wszystkim za rady jakie dajecie innym użytkownikom. Myslę że każdy na swój sposób z nich skorzysta (ja napewno). Cały czas na swojej budowanej mapie zastanawiam się czy postawienie takich czy innych dodatków nie zacznie zacinać mapy, szczególnie że nie mam najlepszego kompa. Z każdej rady czy informacji można i należy korzystać, a nie uczyć się na własnych błędach.
Pomógł: 105 razy Wiek: 39 Dołączył: 19 Lut 2008 Posty: 5160 Skąd: Warszawa
Wysłany: 11-01-2009, 15:38
Maki, jeśli idzie o polygony to ja robiłem z tym testy, które zresztą mnie zszokowały i sprawiły że całkowicie zmieniłem technikę modelarską.
Maszyna testowa była Dual IP4 2400 z 2GB-ram i 128 megowym GF6600 pod maską.
Test zrobiłem na mostach. Mosty stalowe kratownicowe. Dużo 3d, mało grafiki i duża grafika z minimalnym 3d. Efekty były takie że przy wartościach:
-4,0mb grafiki i 220 poly (Most Uniwersalny)
-0,6mb grafiki i 1860 poly (Most Pilchowice)
Efekt jest taki że samo odczytanie przez TRS mostu pierwszego w spisie powoduje czknięcie trainza, za to drugi tnie jak nóż papier. Spodziewałem się że obciążenie rzędu 1860 poly będzie odczuwalne bardzo dla komputera. Zrobiłem jednak drugi test. Na w pełni zabudowanej stacji 4 kierunkowej rzędu 12 torów z bocznicami wstawiłem maksimum taboru jaki mógłby się tam znaleść (dodam że mapa 180km), i obserwowałe po gwałtownym "wleceniu" kamerą w rejon stacji co się najszybciej loaduje. Ewidentnie najciężej pracowała grafika.Z jakichś przyczyn drzewa ładowały się zawsze ostatnie i do tego wyskakiwały nie równo, najpierw jeden typ, potem inne, obiekty z dużymi teksturami na końcu wywołując zresztą ostrą czkawkę. Podobny efekt prawie zawsze jest też z parowozami SLW.
Przebudowałem stacje, ujednoliciłem drzewa, zmniejszyłem ilośc wielkich tekstur, powtórzyłem zabieg. Cięcie było ale radykalnie mniejsze, rzekłbym 2/3 mniejsze, tak że stało się "akceptowalne" i występowało tylko przy wjeździe na stacje, po buforowaniu ustępowało już na stałę.
Dodatkowo wywaliłem pomysł z zestawianiem pociągu z węglem z 40 różnych eaosów, zastosowałem 2 repainty w różnych konfiguracjach. Efekt? Karta graficzna widzi tylko 2 tekstury 256x512 Chestera, a co za tym idzie "błyskawicznie i z automatu" wrzuciła cały skład od razu po wskoczeniu w jego rejon.
Oczywiście nie ma co wariować. Są pewne rzeczy, np. lokomotywy czy wagony osobowe, które muszą występować w różnych odmianach, po to zresztą wymodelowałem je "na lekko" w takiej liczbie. Pełna grafika wagonu osobowego zamyakjąca się w 1,3-1,8mb daje bardzo duże możliwości kształtowania składów.
A i jeszcze co do poly. Te mosty miały 1800 poly. To bardzo dużo. Lub tak się wydaje... bo najlżejszy szczupak jaki zrobiłem waży 1760 poly. Więc...cały most = 1 wagon. Trawa FMA jest tak skonstruowana że znika za szybko by mogło się jej pojawić na tyle dużo żeby zarżnąć komputer. Najwyraźniej komponent odpowiedzialny za przetwarzanie trójkątów jest mniej wrażliwy w trainzie niż grafika. Potwierdza to Fakt zestawienia pary składów powiedzmy 40 Falnsów Torstena z duetem ST43 Marcina. Dwa hiperciężkie ale graficznie relatywnie lekkie spalinowozy + 40 identycznych węglar. To przecież więcej poly niż cała trawa na stacji (a stoją przyjmijmy inne typy wagonów i lokomotyw). I Jakby cięcia nie ma... także trawa FMA wydaje się w tym momencie dość zwycięskim urządzeniem.
Pewnie macie rację... jednak mój komp to stary dziadek, dlatego też nie pozwalam sobie na zbyt wiele jeśli chodzi o dodatki :P Może jak będzie lepszy sprzęt, to będę mogł sobie pozwolić na więcej ;)
Pozdro!
Ostatnio zmieniony przez Maki 12-01-2009, 08:05, w całości zmieniany 1 raz
Owszem, każdy robi mapy według swojego uznania, sprzętu, gustu itp. Ale robienie map ma być tylko przyjemnością, metodą na czas wolny. Nie może się to zmienić w przykry obowiązek bo wtedy to mija się z celem. Nie mam zamiaru sprawdzać, liczyć każdy dodatek ile on ma poly i przeliczać to na całą mapę. Trzeba tylko po prostu dobrze dobierać rodzaj i ilość dodatków, ale to trzeba umieć, aby robienie map nie przerodziło się w "festiwal mierzenia ilości poly", bo nie po to robimy mapy.
Ostatnio zmieniony przez Jacbull 13-01-2009, 06:04, w całości zmieniany 1 raz
Pomógł: 105 razy Wiek: 39 Dołączył: 19 Lut 2008 Posty: 5160 Skąd: Warszawa
Wysłany: 13-01-2009, 11:18
Znaczy wiesz co. Ja bym raczej powiedział że każdy ma swoje priorytety i to jest podstawa.
Łatwo sie mówi "trzeba tak, trzeba inaczej". Jeśli tzw. przyjemnością ma być użytek mapy z realnym zestawieniem taborowym to niestety festiwal poly jest konieczny. Z prostej przyczyny że przyjemność o której rozmawiamy zmieni się w nieprzyjemność a w finale we wkur****ie jak mapa którą się budowało rok/dwa zacznie się ciąć jak album fotograficzny przy finalnym odpaleniu...
Równie dobrze można budować mapę totalnie lejąc na te sprawy, ale to od razu można podpisać na siebie wyrok że zbudowawszy 20km szlaku mapa przestanie się nadawać tak do dalszej budowy jak i do dalszego użytku.
Każdy z Was ma rację. Ja dodałbym że do całego procesu budowania należy dodać fakt -"Czy mapa ma pójść w świat" czyli zostać wydana. Wtedy trzeba się liczyć z faktem że potencjalni użytkownicy produkcji mają bardzo zróżnicowane konfiguracje sprzętowe! Np. buduje mape i nie liczę się z płynnością "bo mi pójdzie" i chcę to wydać a po owym fakcie są same negatywne określenia że się tnie itp itd! Podsumowując- budując mape "do szuflady" każdy niech robi co mu tam się chce ale jeżeli chce się ja wydać należy się liczyć z potencjalnymi użytkownikami i wtedy jak nic metoda Kilana sprawdza się w 100% i nie ma co na ten temat dyskutować! To tyle jeśli chodzi o moje zdanie! Pozdrawiam!
Standardy styczeń 2009 a TC ?
Jakie przyjąć standardy dziś w doborze podstawowych składników : torów , sygnalizacji , roślinności . itp . Aby mapy były jak najlżejsze, jak najdłuższe . Wbudowane w grę , czy inne ? Np. Drzewa w grze są ponoć ciężkie , "zakazane" do używania .... jaki zamiennik ?
Jakie przyjąć założenia w wersjach gry projektu o minimalnych ilości dodatków , kiedy tory , pociągi i przemysł to najważniejsze , pozostałe dodatki schodzą na dalszy plan ....
Tak , aby każdy nowy gracz , jak najszybciej mógł uruchomić .
Pomógł: 105 razy Wiek: 39 Dołączył: 19 Lut 2008 Posty: 5160 Skąd: Warszawa
Wysłany: 14-01-2009, 01:24
Ciężko mówić o takich rzeczach. Grupa autorów słynie z pewnej polityki dodatkowej i jej efektów ubocznych. W czołówce na pewno znaleźli by się:
-Grabash- znaczna liczba doskonale opracowanych obiektów pierwszej kategorii. Dworce kolejowe, bloki mieszkalne, nastawnie, magazyny, wieże wodne. Wszystko doskonałej jakości i relatywnie grywalne. DLS & www.grabash.cba.pl
-Sura & Vendel (FMA) - profesjonalne dodatki wysokiej klasy o najlepszej jakości teksturach z dużym naciskiem na relację grywalność/lekkość. www.trainz.hu / DLS
-Roslas - bardzo dokładne i drobiazgowe obiekty do TRS. Masa drobnego detalu, wysoki poziom grafiki, dodatki ciężkie. Idealne w roli pojedyńczych obiektów znacznej wagi na mapie. www.roltrainz.hu
-Jacek83218 - podstawowe dodatki przytorowe, masa tzw. niezbędników + sporo drobnego detalu. Relatywnie ekonomiczne względem szerokości zastosowania i mnogości wyboru / www.trainz.pl / DLS
-Sony25 - niezbędnik w formie polskich pojazdów drogowych i wielu obiektów pierwszo i drugoplanowych typu scenery. Magazyny, fabryczki, szopy etc. http://www.sony25.one.pl/
-ChWerwick - niemicki autor posiadający w dorobku wysokiej jakości słupki hektometrowe oraz grupę doskonałych dodatków przemysłowych na dalsze plany. DLS.
-Connyxy - jedna z nielicznych kobiet-modelarzy w TRS. Wysokich lotów dodatki przemysłowe pruskiego typu, fabryka stali, gazownia, fabryczka, kioski, nastawnie. Relatywnie ekonomiczne. DLS.
-Maddy25 - druga z nielicznych kobiet-modelarzy w TRS. Grupa najwyższych lotów dodatków przemysłowych, mostów, kopalnia węgla, elektrownia, bardzo wysokopolygonalne dokładne modele przy relatywnie niskich liczbach grafiki. DLS.
-Trunda - Czeski potentat w dziedzinie zieleniny. Spory wybór letni, ładne, dość ciężkie www.trainzmotion.cz
-Jankvis - norweski gigant roślinności trainzowej. Wybór blisko 3000 roślin, krzewów, traw, drzew, krzaków, pól itp ze wszystkich pór roku. Masa innowacji i pomysłów. Znaczny rozrzut jakościowy od słabych po śliczne. DLS.
-Rene_Stambke - niemiecki modelarz, autor grupy bardzo sympatycznych choć mocno za dokładnych obiektów scenery oraz grupy lokomotyw. M.in trabanty, wartburgi, BR106, BR130, BR144 itp. DLS
-Maki- Bardzo lubiane i robione z głową dodatki pierwszoplanowe typu tory, perony, także tabor. www.trainz.pl
-Voytas- autor grupy iglastych spline i teł spline, których opracowanie w relacji ciężar-grywalność nie ma sobie równych. www.eetrainz.eu
-haegarle- niemiecki autor grupy obiektów wiejskich i miejskich pruskiego typu. Domy, stodoły, chałupy. Wysokiej jakości tekstury, nadające się jako uzupełnienie na szlaku, w miastach mogą być odczuwalne jako ciężkie. DLS.
-zgred07- póki co drobne ale rozrastajce się uzupełnienie w dodatkach dolnośląskich pruskiego pochodzenia. Relatywnie lekkie przy dużej dokładności. DLS.
-iceman2117- Zdrowo przeciążone dodatki niemieckiego autora o bardzo dokładnych teksturach i z bardzo dużą ilością detalu 3d. Wiele zasługuje jednak na bezwarunkową uwagę z uwagi na ich znaczną przydatnośc jako obiekty główne i naczelne. M.in. animowany szyb kopalni. DLS.
-hadotwe- niemiecki autor w którego dorobku znajduje się sporo obiektów torowych i przytorowych, m.in. typowe dla zachodniej polski małe obrotniczki i półobrotniczki. DLS.
-Rbach- polski monopolista na doskonałe wskaźniki, bez tego ani rusz. DLS.
-JDS & ES, czyli paka różnych polskich dodatków z których absolutnie najważniejsze są semafory kształtowe i swietlne. DLS.
-kilanziom- czyli ja, duży wybór lekkich i zwykle nader ekonomicznych obiektów pozbawionych bajerów typu animacje, dobre do budowania "dużo, lekko i ładnie" ale nie dla wielbicieli dokładnego detalu. Sporo pruskiej architektury kolejowej i przemysłowej.
I z tym zestawem można i na marsa mapę budować, bo daje on naprawdę ogromne możliwości. Każdy oczywiście ma swoje dalsze preferencje, ale ten zestaw to jakby podstawa sukcesu.
Powiem tyle, bo też już się poznałem na tym stylu budowy, który Ty preferujesz. Powiem, że wykorzystanie tekstur, trawska jest bardzo dokładnie przemyślane. Układanie trawy
Ukłądanie trawy... złudzenie optyczne pozwala nam widzieć trawę jakby koło siebie patrząć ok 180 stopni do toru, tak naprawdę na powyzszych screnach trawa jest w odległościach ok 10m!
http://www.fotosik.pl/pok...de9b8fc9f6.html tutaj mozna już zauważyc te odstepy, dziwię się autorom map, ktorzy walą trawę koło siebie, jest o wiele ciężej, a efekt taki sam. Dobry sposób jest z cieniamy pod drzewami, ale i nie tylko
http://www.fotosik.pl/pok...43bab2c1ac.html pod tym wiaduktem kolejowym w jędrzychowicach, dzięki cieniom mozna ładnie wkomponować dodatek w grunt.
Jest wiele sztuczek wizualnych, które trzeba wykorzystywać i jednoznacznie podzielam Kilan Twoje zdanie.
A dla nieposiadajacych konta badz nieklikajacych w linki:
Overview
This page provides a framework for considering performance when creating new models. Blindly making a model without considering performance is likely to lead to poor results, both in terms of frame rate, and in terms of visual quality. People often assume that better-looking objects will be inherently poor performers. This is not a good general-case summary- in practice, the better that objects perform, the more detail can be used in a scene. With this in mind, we can see how an object built with performance in mind can actually provide significantly better visual quality than an object built for visuals alone.
It's also worth considering that polygon count and performance are not the only trade-offs involved when modeling. Modeling techniques and context often prove a significantly larger effect on frame rate than the raw polygon count numbers.
Where is the object used?
Before creating a new model in Trainz, there are certain usage parameters that need to be defined:
* What is the closest that the player-camera will come to the object in a regular play session?
* What is the farthest that the player-camera will be able to view the object in a regular play session?
* At what range will the player-camera typically sit from the object in a regular play session?
* Will the object regularly be viewed from multiple angles, or primarily a single angle?
* What is the expected object density of the scene surrounding the object? Is it urban or rural, jungle or plains?
* How custom is the object? Is it specific to a particular area in a particular layout, or is it likely to be reused heavily?
* Will the object typically be reused heavily in a single scene?
Regardless of the object type to be modeled, answering these questions provides a framework for making decisions about modeling techniques.
Performance Impacts
Each mesh and each texture used in Trainz impacts performance at various stages in its life cycle:
The following techniques are exceedingly useful in allowing higher-detail scenes.
Level Of Detail
Level-Of-Detail (LOD) is a rendering term for swapping between various 'detail levels' as an object changes viewing distance. Close objects are rendered in high detail, whereas far objects use a lower detail variant. Each LOD should look identical, with the exception of the performance vs quality trade-off. It is important that the overall coloring (including apparent coloring that stems from the lighting model) and silhouette of the object are preserved, since changes to these are the most visible to an observer. Changes to the fine details within the object are far less noticeable.
As an object moves away from the observer, each doubling of the distance results in a halving of both the horizontal and vertical size of the object in screen space. Roughly speaking, this means that we can afford to lose 75% of the object detail at each double distance. In practice, it can be hard to lose that much detail without compromising the silhouette, so a slightly more gradual approach is recommended. If an object is at full detail at 10m, consider halving the detail at 30m, and again at 100m. By the time you reach 1000m, you need to have shed the vast majority of the detail and be left with a box or billboard type object. Smaller objects should vanish completely well before they reach this distance.
LOD operates for both the textures and the models.
Texture LOD
TS2009 will take care of performing texture LOD by falling back to lower mip levels as the object moves into the distance. The unused higher mip levels will be unloaded as necessary, to reduce the game's memory footprint. When the object approaches the observer, the higher mip levels will be reloaded. When several of the same object are in the scene, the game will load up to the highest mip level currently necessary for any of the objects, but the GPU will still perform texture LOD per object.
Model LOD
It is up to the content creator to correctly configure LOD for the models. It is very important to include LODs for any object that has more than ~20 polygons which is capable of mesh stitching, to prevent the polygon count blowing out if the model is used heavily and the draw distance is set high. For objects which are definitely not candidates for mesh stitching, LODs are important where the polygon count exceeds ~300 polygons.
The number of LOD models to make is dependent on the the object type and how it is used, but it is recommended that roughly four models are used. Too few LODs, and the object will either drop detail too visibly or not drop soon enough. Too many, and the game will waste CPU time swapping the models in and out.
Where mesh stitching is not possible (for example, on Train vehicles), LM.txt files should be used to provide LOD support. For stitched meshes, the "mesh-table" Container 'lod-level' tag should be used instead.
Sharing textures
Creating a texture page which is shared between multiple meshes can be a significant performance win if the meshes are likely to be visible in a scene at around the same time. For example, several related tree meshes could be made with a single shared texture. Each tree mesh may use a common part of the texture and some object-specific part of the texture, or each tree mesh could use a completely separate space on the texture page. This is also true for different LODs of a single object - since the various LODs will be swapped between on a regular basis, having all the LODs use the same texture (again, either the same space on the texture, or separate spaces as required) is going to be a performance win.
To enable texture sharing, the following conditions should be met:
* Multiple meshes exist in the same directory.
* The meshes use identical material names.
* The meshes are exported with up-to-date TS2009 exporters. Older exporters will prevent texture sharing.
* The materials should have identical setup, including referencing the same *.texture.txt files.
Mesh libraries
A mesh library is an asset which is not placeable in itself, but rather provides a number of mesh files which are used by other assets. The advantages of using assets from the shared library are as follows:
* If multiple assets use the same mesh, there is a corresponding reduction in disk usage and memory usage (as compared to each asset containing a duplicate copy of the mesh and textures.)
* If multiple assets use the same mesh, they are candidates of mesh stitching together.
* If multiple assets use different meshes from the same library, but the meshes share materials, they are candidates for mesh stitching together.
* If multiple assets use different meshes from the same library, but the meshes share textures, there is a corresponding reduction in disk usage and memory usage (as compared to each asset containing a duplicate copy of the textures.)
* If many assets use the same library, an update to the library will affect all assets rather than requiring an update to each asset.
* Textures from meshes that are regularly used together can be combined into a unified texture page to enable mesh stitching where it would not otherwise be available.
An asset may source meshes from multiple libraries as well as its own local folder.
It is recommended that asset libraries are not made too large on disk - while combining meshes and textures in this manner improves efficiency, the bandwidth cost of providing an update to the entire library can become prohibitive if it becomes too large.
Alpha Masking
Alpha masking refers to a special case of alpha blending where all pixels are rendered as either fully opaque (100% alpha) or fully transparent (0% alpha) with no partial transparency. This can be treated as a special case because it does not require alpha sorting in order to produce visually correct results. This provides a significant performance win over an equivalent alpha sorted material.
When an alpha masked texture is recognized, Trainz will also prefer DXT1a compression over the DXT3 required for normal alpha blending. This provides a 50% reduction in texture memory usage.
Poor Performers
The following techniques generally lead to poor performance and reduce available scene detail.
Alpha Sorting
Prior to TS2009, all materials which made use of alpha blending, with a very few exceptions, were passed through a very slow alpha sorting process. This process is necessary to achieve some semblance of correct transparency ordering, however it is a burden on the CPU and results in the geometry being broken up in a manner that gives a very inefficient input to the GPU. There is no real solution to this problem - current rendering technology based on polygon rasterization is fundamentally inefficient when dealing with blended alpha sorting.
The current recommendation is to simply avoid using alpha blending. Most objects which have traditionally used alpha blending can be constructed using an increased polygon count and alpha masking. This leads to a slightly different graphical result - object edges are sharp, rather than blurred - which may be considered better or worse than the old approach, depending on the circumstances and personal opinion. When close to the observer, this approach is generally considered to give superior results due to the increased polygon count.
The increase in polygon count does bring a performance cost of its own, but when applied sensibly and in conjunction with LOD, the polygon cost is negligible when compared with the old alpha sorting approach.
In summary - if your diffuse map uses an alpha channel for opacity control, ensure that the entire channel consists of pure black and pure white pixels - do not use even a single pixel of gray. It is recommended that you additionally flag your texture.txt file with the "AlphaHint=masked" attribute.
Use of multiple materials
When rendering a model, each material used results in a single request to the GPU, regardless of the number of polygons drawn with that material. This is known as a "draw call". Due to driver and communication overheads, each draw call has a fixed performance cost, in addition to any pixel cost and polygon costs. This cost varies between hardware platforms, but it is reasonable to say that the fixed overhead becomes a significant penalty in any draw call below 500 polygons.
Because of this fixed cost, it is more efficient to use a single texture page rather than several separate textures when rendering a given model. This is especially true at lower LODs since the polygon count and pixel count are lower - the ratio of wasted setup time to actual geometry rendered will increase substantially.
As an example, let's assume that the hardware can handle around 400 calls in a frame. This means that you can safely render 400 objects if each uses a single material. If each uses 4 materials, then you are limited to around 100 objects in view. It's easy to see how reducing material count becomes important. Mesh stitching can also help here, since it may reduce the number of draw calls necessary if the same object is used repeatedly.
Wybaczcie ze nie po polsku, postaram sie przetlumaczyc w miare wolnego czasu, bo to dosc istotne i wazne opracowanie. Po pobieznej lekturze nasuwaja sie juz wnioski - nie bede ich pisal poki co, jak przetlumacze badz ktos chetny z czasem sprobuje to tlumaczyc to wtedy mozemy podyskutowac na temat tego co napisali (A uwazam trainzdev za bardzo wiarygodne zrodlo, o wiele wiarygodniejsze niz forum Auranu).
Pomógł: 31 razy Wiek: 40 Dołączył: 24 Mar 2008 Posty: 808 Skąd: Poznań/Kołobrzeg
Wysłany: 25-01-2009, 17:56
Oto tłumaczenie (pomijam literówki), zapraszam do lektury - warto naprawdę.
"Ogólne spojrzenie
Ta strona dostarcza podstawy informacji do rozważań nad wydajnością przy tworzeniu nowych modeli. Tworzenie modelu bez brania pod uwagę wydajności najprawdopodobniej doprowadzi do kiepskich rezultatów, zarówno pod względem klatek na sekundę jak i jakości wyglądu. Ludzie często przypuszczają, iż lepiej wyglądające obiekty będą z góry słabo wydajne. To nie jest prawidłowy, uogólniający wniosek - w praktyce, im lepszą obiekt ma wydajność, tym więcej detali może być użyte na mapie. Mając to na uwadze, możemy zauważyć jak obiekt zbudowany mając na uwadze wydajność może dostarczyć znacząco lepszych wrażeń w wyglądzie niż obiekt zbudowany tylko z naciskiem na wygląd. Warto także wspomnieć iż liczba trójkątów i wydajność nie są jedynym kompromisem przy modelowaniu. Techniki oraz kontekst tworzenia często dowodzą znaczącego wpływ na fps (to chyba najlepsza nazwa na ten parametr po polsku - dop. mój) niż tylko sama liczba trójkątów.
Gdzie obiekt ma być użyty?
Przed stworzeniem nowego modelu do Trainza, należy sobie zdefiniować pewne parametry
dotyczące używania danego obiektu:
- Jak najbliżej obiektu jest w stanie znaleźć się kamera w trakcie regularnej gry?
- Z jak najdalszej odległości kamera będzie w stanie uchwycić obiekt w trakcie regularnej
gry?
- W jakim zasięgu kamery dany obiekt będzie najczęściej przebywał w trakcie regularnej
gry?
- Czy obiekt będzie regularnie widziany z różnych kątów czy tylko z jednego?
- Jaka jest spodziewana gęstość występowania obiektu z uwględnieniem planu otaczającego obiekt? Czy to obiekt miejski, wiejski, dżungla czy równina?
- Jak dowolny jest obiekt? Czy jest on tworzony w określone miejsce na określoną mapę czy będzie używany dowolnie i często?
- Czy obiekt będzie często występował na mapie?
Niezależnie od rodzaju obiektu do wymodelowania, odpowiedzi na te pytania dostarczą
podstaw do podjęcia decyzji o zastosowaniu odpowiednich technik modelowania.
Wpływ na wydajność
Każda siatka i tekstura użyta w Trainz wpływa na wydajność w różnych etapach "cyklu
życia":
- wydajność ładowania siatki
- wydajność ładowania tekstury
- pamięciowy koszt siatki
- pamięciowy koszt tekstury
- wydajność parametrów siatki
- wydajność "zszywania się" siatek (stitching mesh to inaczej nakładające się na przemian
siatki czyli LOD dla obiektów ciągłych - spline, tory, mosty, tunele itp. a przynajmniej tutaj widziałem wykorzystanie w działaniu - dop. mój)
- koszt renderowania pojedyńczego trójkąta
- koszt renderowania pojedyńczego materiału (w gmaxie tekstury nakłada się poprzez
Material Editor i to jest de facto determinująca wartość, a nie liczba plików tekstur
choć z reguły jeden materiał = jeden plik - dop. mój)
- koszt przełączania siatek w ramach LOD
- koszt usuwania pojedyńczej siatki
- pamięciowy koszt jednego obiektu
Techniki wpływające pozytywnie na wydajność
Następujące techniki są niezmiernie użyteczne dla tworzenia obiektów o wysokim
współczynniku jakość/wydajność (dop. mój)
Level of Detail (nazwy ogólnie znane zostawiam w oryginale - dop. mój)
LOD to nazwa dla techniki renderowania wykorzystującej zamiany pomiędzy siatkami z różnym
poziomem detali w zależności od odległości widzenia. Obiekty z bliska renderowane są w
wysokich detalach, a oddalone w niskich. Każda siatka powinna wyglądać identycznie z
wyjątkiem kompromisu na linii wydajność a jakość. Ważne jest by ogólna kolorystyka
(włącznie z różnym oświetleniem modelu) i sylwetka obiektu były zachowane, gdyż zmiany w nich są najbardziej widoczne. Zmiany w detalach obiektu są o wiele mniej zauważalne.
W momencie oddalania się obiektu od obserwatora (kamery), każde podwojenie odległości
oznacza zmniejszenie o połowę zarówno poziomej jak i pionowej wielkości obiektu na
obszarze monitora. Pobieżnie mówiąc, oznacza to, że możemy zmniejszyć o 75% detale na
każde podwojenie odległości. W praktyce ciężko jest uzyskać taki spadek bez zmiany bryły
modelu, więc polecane jest podejście większego stopniowania zmian. Jeżeli obiekt jest w
pełnych detalach w odległości 10m, rozważyć trzeba obcięcie połowy detali przy 30m i
znowu przy 100m. W momencie gdy osiągniesz 1000m musisz mieć usuniętą ogromną większość detali i pozostawić obiekt w formie boxa lub billboard'u. Mniejsze obiekty powinny całkowicie zniknąć zanim osiągną taką odległość.
LOD operuje zarówno na teksturach i modelach (zapewne odnosi się do 2009 - dop. mój)
Texture LOD
TS2009 wykonuje LOD tekstur poprzez schodzenie na niższe poziomy mipmapingu (czyli
ogólnie mówiąc zmniejszając rozdzielczość tekstury) w momencie oddalania się obiektu.
Niewykorzystywane wyższe poziomy będą wyładowywane w celu zmniejszenia zużycia pamięci. W momencie zbliżenia się obiektu wyższa rozdzielczość będzie przeładowana. Jeżeli kilka takich samych obiektów są widoczne, gra wczyta najwyższy wymagany poziom dla tego obiektu który tego wymaga, ale procesor karty grafiki nadal będzie przetwarzał LOD tekstury na każdy obiekt.
Model LOD
Prawidłowa konfiguracja LOD dla modeli zależy od autora. Jest bardzo ważne by dodawać LOD dla obiektów które mają mieć więcej niż ok. 20 trójkątów i wykorzystać mogą "mesh
stitching" (to "zszywanie siatek" co dotyczy splinów, torów - dop. mój), żeby
zabezpieczyć przed nagłym wzrostem liczby trójkątów (co przy torach ma znaczenie - dop.
mój). Dla obiektów które nie muszą mieć "zszycia siatek", LOD jest ważny gdy liczba
trójkątów przekroczy ok. 300. Liczba siatek LOD zależy od rodzaju obiektu i tego jak będzie użyty, jednak rekomenduje się używanie czterech siatek. Za mało siatek może spowodować widoczną (w sensie odbiorcy) stratę detali, a zbyt duża ilość spowoduje, że gra będzie tracić moc procesora na ciągłe zmiany siatek.
Tam gdzie "szycie" nie jest możliwe (np. tabor) pliki lm.txt (czyli jak zawsze - dop.
mój) należy użyć dla LOD. Natomiast dla szycia siatek, należy dodać tag "lod-level" w
sekcji "mesh-table".
Dzielenie się teksturami (TS2009)
Stworzenie tekstury (texture page - czyli jeden plik tekstury zawierający w sobie kilka
mniejszych) która jest dzielona między kilkoma siatkami, może być znaczącym wzrostem
wydajności jeśli siatki miałyby być widoczne na mapie w tym samym czasie. Na przykład
kilka siatek drzew może być wykonanych z użyciem tej samej tekstury. Każda siatka drzewa może użyć tej samej częsci z tekstury, a część z nich także tylko specyficznej dla danej siatki, lub też każda siatka użyje innej częsci tekstury. To jest też prawidłowe dla
różnych siatek LOD modelu - jeśli kilka siatek LOD posiadałoby tę samą teksturę to będzie
to z korzyścią dla wydajności.
By móc korzystać z dzielenia tekstur należy spełnić takie warunki:
- siatki znajdują się w tym samym katalogu
- siatki używają tych samych nazw materiałów (hint-> gmax)
- siatki są eksportowane za pomocą najnowszych eksporterów. Starsze eksportery zablokują współdzielenie (czyli obecnie przy zmianie siatki LOD tekstura wypada i wpada z powrotem do karty nawet jeśli jest taka sama - dop. mój)
- materiały muszą mieć identyczne ustawienia, uwzględniając odniesienie do tego samego
pliku *.texture.txt
Biblioteki siatek
Biblioteka siatek jest dodatkiem, którego nie użyjemy bezpośrednio, ale raczej jako
dostawcę plików siatek, które mogą być użyte przez inne dodatki. Zalety takiego
rozwiązania to:
- Jeżeli dodatki korzystają z tej samej siatki, to otrzymamy zmniejszone zużycie pamięci
dysku i pamięci (porównując z faktem posiadania przez każdy dodatek siatki i tekstur)
- jeżeli dodatki korzystają z tych samych siatek, można je "zszyć" (aczkolwiek za mało
informacji o tym znalazłem - dop. mój)
- jeżeli dodatki korzystają z różnych siatek z biblioteki, ale siatki dzielą te same
materiały, można je "zszyć"
- jeżeli dodatki korzystają z różnych siatek z biblioteki, ale siatki dzielą te same
tekstury to jest oszczędność w zużyciu miejsca na dysku i w pamięci
- jeżeli dużo dodatków korzysta z biblioteki, update siatek odniesie się do wszystkich
dodatków zamiast robienia update każdego dodatku z osobna
- tekstury z siatek, które są używane wspólnie mogą być połączone w jedną by umożliwić
"zszycie"
Dodatek może pobierać siatki zarówno z wielu bibliotek jak i z własnego folderu.
Zaleca się, żeby biblioteki nie były za duże - gdy kombinacje siatek i tekstur dają
korzyści tak koszt update (przesłanie w sieć) może być wysoki.
Maskowanie alfą
Maskowanie alfą odnosi się do specjalnego stosowania alfy (alpha blending) gdzie
wszystkie piksele są renderowane jako w pełni przezroczyste bądź nie (100% lub 0%) bez
przejsciowych wartości. Należy to traktować jako przypadek specjalny ponieważ nie wymaga on sortowania alfy w celu uzyskania prawidłowego wyglądu. To powoduje znaczący wzrost wydajności nad taką samą alfą, która wymaga sortowania (czyli alfą z szarością - dop. mój)
W momencie wykrycia alfy maskowanej w ten sposób, Trainz zastosuje także metodę kompresji która da 50% zysk w użyciu pamięci dla tekstury.
Kiepska wydajność
Poniższe techniki prowadzą do słabej wydajności i redukują szczegółowość detali na mapie.
Sortowanie alfy
Przed TS2009 wszystkie materiały korzystające z alfy nieczarno-białej poza paroma
wyjątkami, były przeprowadzane przez bardzo wolny proces sortowania alfy. Ten proces jest potrzebny do osiągnięcia złudzenia prawidłowej kolejności przezroczystości, jednakże jest to obciążenie dla procesora (CPU) i w rezultacie geometra ulega uszkodzeniu w sposób
taki, który przekazuje bardzo niewydajne dane dla procesora grafiki (GPU). Nie istnieje
rozwiązanie tego problemu - obecne technologie renderowania oparte na rasteryzacji
trójkątów z założenia są nieefektywne w momencie działania z sortowaniem alfy (a więc
niemaskowaniem alfy czytaj nieczarno-białą).
Obecnie zaleca się by po prostu unikać stosowania takiej alfy. Większość obiektów które
posiadają taką alfę da się stworzyć tak, by użyć większej liczby trójkątów i maskowania
alfy. To prowadzi do trochę innego rezultatu graficznego - krawędzie obiektu są ostre
aniżeli rozmyte - co może być uważane za lepsze bądź gorsze od poprzedniego podejścia
(czyli niemaskowania alfy) zależnie od okoliczności i osobistych opinii. W momencie
bliskiego spojrzenia na obiekt, to podejście rozważane jest jako dające świetne rezultaty
w związku ze zwiększoną liczbą trójkątów.
Zwiększenie liczby trójkątów niesie ze sobą koszt wydajności, ale zastosowane rozsądnie i
w połączeniu z LOD, koszt ten jest pomijalny w porównaniu z kosztem sortowania alfy.
Podsumowując - jeżeli tekstura główna używa kanału alfa dla przezroczystości, upewnij się
że cały kanał zawiera tylko w pełni czarne i białe piksele - nie używaj nawet jednego
piksela szarego. Zaleca się także dodać w pliku texture.txt atrybutu "AlphaHint=masked"
Używanie wielu materiałów
W momencie renderowania modelu, każdy materiał użyty powoduje wysłanie żądania do GPU (procek karty graficznej) niezależnie od liczby trójkątów ktore ten materiał "rysuje"
(czyli które są nim pokryte - dop. mój) Jest to znane pod pojęciem "draw call". (Tu dla
mnie jako niekumatego z metodami przesyłu informacji w kompie to troche zakręcone - dop. mój) Każde "draw call" ma stały koszt wydajności w dodatku do kosztu piksela i trójkąta. Ten koszt zależy od sprzętu, ale rozsądne jest stwierdzenie, że stałe "overhead" (co to jest? - dop. mój) staje się uciążliwe w każdym "draw call" poniżej 500 trójkątów.
Ponieważ jest to stały koszt, wydajniejsze jest użycie jednego pliku z teksturami niż
kilku plików oddzielnie w momencie renderowania modelu. To sprawdza się zwłaszcza przy
niższych poziomach LOD gdzie liczba trójkątów i pikseli jest niższa - współczynnik
zmarnowania czasu na ustawienie odpowiedniej geometrii wzrośnie znacząco.
Jako przykład załóżmy że sprzęt może obsłużyć 400 "draw calls" na klatkę. Oznacza to że
można bezpiecznie wyrenderować 400 obiektów jeśli każdy używa pojedyńczego materiału.
Jeśli każdy korzysta z czterech materiałów, wtedy ogranicza się do 100 obiektów w polu
widzenia (w sensie, że kolejne pojawią się później). Łatwo zauważyć jak redukowanie
liczby materiałów staje się ważne. "Zszycie siatek" może także pomóc, gdyż może
zredukować liczbę "draw calls" potrzebnych jeśli ten sam obiekt jest użyty ciągle."
Pomógł: 31 razy Wiek: 40 Dołączył: 24 Mar 2008 Posty: 808 Skąd: Poznań/Kołobrzeg
Wysłany: 25-01-2009, 18:18
W CCG do TRS2004 LOD stał pod znakiem zmiany takze tekstur (w sensie rozdzielczosci i elementow) jednak Chester po jakiejs tam dyskusji na forum Auranu wyciagnal wnioski ze to nie ma sensu i wystarczy ciagle ta sama jedna. Z tego co w artykule stoi to i tak nie mialo znaczenia, bo dopiero w 2009 tak to dziala ze w teksturze silnik sam zmienia rozdzielczosc (chyba ze ja czegos nie rozumiem). Natomiast co do LOD - niby jest ta wartosc graniczna jakas, ale jesli dodatek mialby wystepowac w sporej ilosci na mapie to niech nawet ma ten LOD majac mniej trojkatow. Bo to chyba o to glownie chodzi z tego artykulu zeby wiedziec po co robic dany dodatek, czemu ma on sluzyc, jak czesto wystepowac itp. itd. a wtedy mozna dobierac odpowiednie narzedzia zeby zrealizowac pogodzenie wydajnosci z jakoscia.
Nie możesz pisać nowych tematów Nie możesz odpowiadać w tematach Nie możesz zmieniać swoich postów Nie możesz usuwać swoich postów Nie możesz głosować w ankietach
FAQ
Szukaj
Użytkownicy
Grupy
Rejestracja
Zaloguj
