ORG

W tym wypadku detail było zastosowane dość nieszczęśliwie =\

Na drugim screenie widać znacznie większe zagęszczenie siatki, gdyż schody są detail, zostały pominięte w visie i przez to generuje się więcej ścianek, ktróre w pierwszym przypadku nie są widoczne. Odbija to się na fps.

Z reguły jest tak, że im mniej detali tym większy fps, bo dokładniejszy vis. A dokładniejszy vis to m.in. usuwanie ścian niewidocznych dla gracza. Dlatego jeśli zmieniasz jakiś brush na detail to wszystkie ścianki z wyjątkiem tych widocznych pokryj shaderem common/caulk (ewentualnie nodraw jeśli chcesz przyśpieszyć kompilację, ale oświetlenie może być trochę dziwne). Do ostatecznej kompilacji nigdy nie używaj fastvisa - zawsze będziesz miał mniej fpsów.

Nie można jednoznacznie powiedzieć czy stosowanie detail zwiększa czy zmniejsza ilość fpsów - one generalnie są po to, żeby przyśpieszyć kompilację, a [u]odpowiednio użyte nie zmniejszają[/u] ilości klatek na sekundę w grze.

dobrze , juz mniejwiecej wiem co zrobie z ta mapka. Zrobilem maly test i wziolem pewien element z mojej mapy (85 brushow). Kiedy calosc byla w structural kompilacja vis trwala ok. 10 min. (!) gdy sobie wyobraze ile trwalaby cala mapa (2500brushow) to widze astronomiczne liczby. No wiec wracajac , postanowilem niektore czesci tego owego elementu dac na detail. Kompilacja vis trwala kilka sekund a roznicy w fpsach raczej niezauwazylem. Mysle ze to samo zrobie z cala mapa.
btw. czy make detail mozna dawac na brushe z shaderami, np lampy?

btw2. mozna w jakis sposob sprawdzic ile dokladnie czasu trwala kompilacja( i poszczegolne jej czesci), bo pamietam ze ktos kiedys podawal dokladny czas trwania np. czesc light itp.

Może jeszcze dorzucę coś od siebie o schodach.

Robię je w sposób widoczny na screenie poniżej:

[img]www.members.lycos.co.uk/sfif/q3arena/schody.jpg[/img]

Duży brush structural pod spodem i małe trójkąciki (w przekroju) schodów detail.

Daje to piorunujące efekty. Także w przejrzystości.
edit:Jeszcze do T4m8a: nie pomyliłeś modeli z brushami? Modele nie są uwzględniane w visie. A między shaderem (jeśli solid) a texturą vis nie widzi róźnicy.

2 pytanie: czas jest podawany w sekundach po zakończeniu każdej kompilacji przez q3map (nie wiem, jak to robią gtkRadiant i q3map2).

> btw2. mozna w jakis sposob sprawdzic ile dokladnie czasu trwala kompilacja( i poszczegolne jej czesci), bo pamietam ze ktos kiedys podawal dokladny czas trwania np. czesc light itp.

Po każdym etapie pojawia się czas, jaki został poświęcony na wykonanie tego. Wygląda to np. tak w fazie \"Vis\":

[i]--- Vis ---

Loading D:\Gry\Quake III Arena\baseq3\maps\dade_pak.bsp

Loading D:\Gry\Quake III Arena\baseq3\maps\dade_pak.prt

189 portalclusters

438 numportals

796 numfaces

876 active portals

0 hint portals

visdatasize:4544
--- BasePortalVis (876) ---

0...1...2...3...4...5...6...7...8...9... (0)

5 average number of passages per leaf

0 MB required passage memory
--- CreatePassages (876) ---

0...1...2...3...4...5...6...7...8...9... (1)
--- PassagePortalFlow (876) ---

0...1...2...3...4...5...6...7...8...9... (1)

creating leaf vis...

Total visible clusters: 12227

Average clusters visible: 64

Writing D:\Gry\Quake III Arena\baseq3\maps\dade_pak.bsp

Wrote 0.2 MB (190140 bytes)

[b]3 seconds elapsed[/b]

Disconnecting[/i]
No i tutaj to się sprawdza, tzn. widać. Jak chcesz sprawdzić, to najlepiej chyba ustawić, żeby kompilacja się logowała do pliku.

Jak to zrobić \"normalnie\" nie pamiętam / nie wiem, ale w q3map2build wszystko bardzo łatwo można załatwić samym klikaniem i po kompilacji bez problemu sprawdzić.

Pisząc o schodach, zapomniałem jeszcze wspomnieć o kilku rzeczach.

Po pierwsze, jak tworzy się schody widoczne z boku w taki sposób, jak widać to na screenie z radianta wyżej, daje to taką oszczędność:

[img]www.members.lycos.co.uk/sfif/q3arena/shot0134.jpg[/img]

Może objaśnię, co widać: rząd trójkącików, podobny do trójkątów z radianta, a pod nim... sieczkę. Powstaje ona dlatego, że gdy brushe stykają się nie rogami, ale rogiem do boku, jeden z trójkątów zostałby pocięty tak, aby rogi nowych stykały się w miejscu zetknięcia z rogiem innego brusha. Jasne?[23] Daje to 1 poligon na stopień. Ponadto na dole jest jeden duży trójkąt ciągnący się przez całą długość brusha.

Gdyby zaś schody byłyby zbudowane ze stopni o trapezoidalnym przekroju (podobnie do tego, jak zrobił Tamb, ale z uwzględnieniem skosu u dołu), rysowany byłby trójkącik widoczny na górze, owszem, ale oprócz niego jeszcze dwa inne trójkąty na każdy stopień, zgodnie z tym, co napisałem powyżej. Tak więc, oznaczając stopnie jako n, mamy w 2 wersji 3*n trójkątów z boku, a w pierwszej 2*n+1. Korzystniejsze?[23]

Ponadto, jak ma być jakieś pomieszczenie pod schodami, sklepienie składające się z 2 trójkątów jest gotowe (a nie z co najmniej 2*n...).

Nie pokręciłem zanadto?[22][23]

Ja zawsze daję płaską krawędź (rampę) na brzegach schodów (jak na obrazku poniżej). O tym jaka to oszczędność polygonów nie muszę mówić, ale warto zaznaczyć, że tak skonstruowane schody stwarzają więcej okazji do wykonania trików (pod cpma).

[img]www.planetquake.com/lukin/img/levels/l3dm3-b.jpg[/img]

Hmm... To ma sens. Pobiłeś mnie[20]. Coś takiego rzeczywiście daje horrendalną oszczędność (o ile oczywiście krawędź rampy styka się z krawędziami schodów, co, jak widzę, robisz).

( pisze tego posta po raz drugi bo mi sie jakos dziwne bspace przycisnelo [27])
Dobra, wroce do max_map_visibility.Fakt faktem ze bylo to moze 4,5 razy , ale konkretnej odpowiedzi to znalesc ciezko bedzie, mi sie to nie udalo. Nie jestem nawet pewien co dokladnie to powoduje, raz mowia ze za duzo widzialnych powiezchni, a raz ze to przez modyfikacjie przez egdes i vertex. Co jest prawda, do dzis nie wiem, jak to naprawic?rowniez tego nie wiem, choc mam pewne przypuszczenia. W \" normalnej \"mapie bedzie troche roboty, ale zrobic sie da, pocaulkowac gdzie trzeba, tu i tam make detail i po problemie. Ja jednak robie mape w przestrzeni. Wymiary odpowiednio xyz to 12304x2752x7512, ilosc brushow 2603, light- niewazne ale jak juz zaczalem...- 447- czyli dosc duza mapa.

probowalem zwalczyc ten blad, dalem ok 800 brushow na detail, o caulku nie mowie nawet bo jest chyba wszedzie gdzie sie da- blad pojawia sie nadal, no i co mam robic dalej?Nie potrafie wstawiac hintow ale sadze ze przy tej mapie nic by nie daly, to samo areportale itp. Co do blocksize, to nie jestem pewien czy go zmieniac, bo boje sie ze mapa bedzie wolno chodzic, czy nie ma innego rozwiazania?. Prosze Was o pomoc, jakies sugestie, moge ostatecznie podeslac plik map komus. Z gory dzieki, szczerze mowiac jestem juz troche zdesperowany,a zmniejszenie mapy raczej nie wchodzi w gre...bleh[27]pdzr

edit. probowalem z tym _blocksize. Nie bylem pewny jak to sie pisze ( czy tak : \"X X X\", czy moze tak: \" X*X*X \"- wiec probowalem i to i to). Doszedlem do 50000, i nadal nie pomaga...[27]

Możesz podesłać .map. Pokombinuję.

mapa poszla na maila ktorego masz w profilu.

Powiem tyle: vis poszedł [5]

Jutro się zajmę dalszą optymalizacją....bądź cierpliwy :]

PS: I wcale nie użyłem techniki \"cała mapa na detail\" ;)
[b]Edit:[/b]

fast vis - 278 sekund

lol?
nie no, powiem ze mnie zadziwiles. Co jak co, ale takie rezultatu to sie nie spodziewalem. Moglbys powiedziec jak to zrobiles, chcialbym poznac tak skuteczne techniki optymalizacji:]? I dzieki ze poswiecasz mi czas. [61]

Kolejny sukces - fastvis 123 sekundy
A zrobiłem to bardzo prosto - detail i tyle. Na Twojej mapie było już trochę elementów zdetalowanych, ale i tak stanowczo za mało. Trezba po prostu wyobrażić sobie co kompilacja może zrobić z poszczeglnymi bruszami, np:

mamy brusz o 6 ścianach, a jedna z nich przylega do innego brusza. Tak czy inaczej 5 ścian będzie widocznych, więc szóstą trzeba ocaulcować a brusza dać na detail. Akurat w tym wypadku było bardzo dużo elementów, które spokijnie mozna zdetalować bez uszczerbku na fps.

A ten cały bład \"max_visibility..\" polega na tym, że visdatasize jest zbyt duzy, a najprościej zmniejszyć go właśnie za pomocą detalowania.

Aha, jeszcze u Ciebie blocksize miał rozmiar jakiś taki - 9999999

Niepotrzebny i za duzy, wystarczy 2048, a nawet na defaultowym 1024 by poszło.

Ponadto blocksize powinien mieć wartość 2^n.

NIedługo wyślę poprawianą wersję (zmieniłem w niej skyboxa, bo nie miałem takiego akurat) .

.

.

Ok wysłałem

.

.

Znowu wysłałem =]

niestety archiwum jest uszkodzone.
edit. mapke dostalem i wszystko dziala jak nalezy. niedlugo zapewne ja wydam. wielkie dzieki alchemik, bo bez Ciebie pewnie trudne by to bylo=]