OpenGL 2.1 i 3ds max Praca inżynierska

[Oleksiak]

Witam wszystkich.

 

Chciałbym się dowiedzieć czy na tym forum są ludzie którzy mają wiedzę z OpenGL ?

 

Za kilka miesięcy ruszy wspólny projekt mój i kolegi ze studiów polegający na zrobieniu wizualizacji (spacer) wnętrza głównego budynku AGH. Będzie to praca inżynierska.

 

Ja będę odpowiedzialny za zrobienie modeli(+tekstury i normale), a kolega za OpenGL(tak w skrócie). Czy można liczyć na to że ktoś będzie w stanie pomóc ?

 

Pozdrawiam.

[Levus]

To raczej na forum programistycznym pytaj..

[Manver]

warsztat.gd, tu spróbuj, chociaż pewnie znasz.

[Oleksiak]

Trochę na tym forum siedzę i wiem że można tu dostać całkiem niezłą pomoc dlatego najpierw tu jej szukam ;) Cóż.. jeszcze trochę czasu mamy. Najwyżej będę musiał znaleźć inne dobre forum tylko programistyczne :P

[JacekCichy]

No mam troche wiedzy na temat OpenGL (inżynierka w Javie, aktualnie magisterka w C++) więc jak coś to pytaj śmiało :D

[Oleksiak]

Dzięki, za jakieś 3 miesiące rusza projekt wiec dam znać ;)

[Oleksiak]

Projekt ruszył i jego obecny etap wygląda następująco:

A0 zostało zwymiarowane i przeniesione do 3ds. Obecnie w planie jest zrobienie parteru i dwóch pięter.

 

Mam kilka pytań:

 

1. Potrzebujemy jakiegoś systemu/aplikacji do oceny wydajności kody i tego jaki wpływ

mają modele i jakość tekstur na wydajność aplikacji. Możecie polecić jakąś technikę itp.

Wiem że jest coś takiego jak programy które się odpala razem z aplikacją i analizują

która część kodu zabiera najwięcej zasobów - wiecie coś na ten temat ?

 

2. Wrzuciłem kilka screenów z tym jak wygląda model i ilość obiektów.

Chciałbym dodać że w większości chcieliśmy tylko zachować objętość danego

przedmiotu żeby później było mi łatwiej coś wymodelować dlatego też obiekty

będą bardziej złożone i będzie ich więcej niż jest to widoczne. Ciekawi mnie sposób

podziału tego wszystkiego :D czy podłoga ma być jednym obiektem czy jakoś ją podzielić

to samo ściany korytarzy... ?. Czy ktoś jak patrzy na ten obiekt ma jakąś wizję ?

Chętnie usłyszę ;)

Kamera z wnętrza A0 umieszczona w holu głównym: http://live.uci.agh.edu.pl/view/A0.html

 

3. W aplikacji będzie możliwa opcja latania dlatego ciekawi mnie jak ogarnąć tekstury

i ile może ich być. Chcemy umieścić diffuse mapy, specular mapy i normal mapy.

 

4. To co mnie najbardziej ciekawi: LOD czyli "level of detail" . Wydaje mi się że tutaj miałoby

sens zrobienie chociaż jednej wersji uproszczonej niektórych elementów - zwłaszcza tych w

holu (wydaje nam się że tam będzie najbardziej cięło z racji tego ile obiektów będzie w

kadrze). ALE.. co z teksturami a właściwie UVW obiektów które upraszczam ? jak zrobię sobie

obiekt i rozłożę UVW to czy później znów będę musiał ją rozkładać ponownie i znów malować

tekstury ? Jest jakiś system ?

 

Piszcie wszystko co wam przyjdzie do głowy ;) Póki co staram się ogarnąć rozkładanie UVW

wypalanie normali modelowanie pod gry itp. Myślę że minie jeszcze z miesiąc i dopiero wtedy

zacznę modelowanie.

 

Pozdrawiam.

 

 

 

 

 

 

 

i taka zabawa z samochodem... pokazuje bo widać trochę inaczej ten budynek - jest kilka wychodzących z ziemi obiektów ale pomińcie to bo zostanie poprawione później.

 

 

 

 

Edytowane 12 Sierpień 2011 przez Oleksiak

[Por@szek]

Gratki za uruchomienie projektu.

 

1) - szczerze nie pomoge, kiedys jeszcze jak bawilem sie w testy to wrzucalismy wszystkie najbardziej zrzace obiekty do sceny i patrzylismy ile klatek jest przy jakiej ilosci ^^ A przy jakiej sie wysypuje.Robilo sie np. postac, albo samochod, z pelna paleta textur, lod itd i kopiowalo sie tyle razy ile udzwignela aplikacja. Stare dzieje.

 

2) - ja mam wizje chaosu. Nigdy do mnie nie przemawialy roznokolorowe boxy. Ja nic nie widzialem tam, ale znam takich co tak pracuja. No nic, jako placeholder/blockout moze byc. Ale jezeli chcesz to do jakiegokolwiek realtimeowego silnika dac to pamietaj o dwoch podstawowych rzeczach - zabijasz framerate iloscia podobiektow oraz iloscia vertexow.

Jest to z tego widze dosc ambitne przedsiewziecie. Robiac lot z gory nie potrzebujesz sufitow , ani nic co ma kat pomiedzy 0 a 90 ( zakladajac ze 0 jest gornym punktem). I powinienes uzywac lodow , moze tez occluderow. Jezeli robisz widok zza plecow, obawiam sie ze bez portali mozesz miec problem. Occludery is a must w tym wypadku. Lody zbedne.

 

Podzialy - jezeli robisz occludery - Musisz miec jeden duzy obiekt ktory bedzie zaslanial obiekty nie widoczne dla kamery. Wtedy obnizysz frame rate bo schowane obiekty nie beda liczone. Portale traktuj jak duze pokoje, nic wiecej.To co jest wyswietlane w jednym pokoju nie jest liczone w drugim etc. Lody - musza byc jako osobne obiekty bo inaczej podmiana bedzie ...dziwna.

Pamietaj ze chec zrobienia duzej ilosci obiektow moze szybko spalic na panewce, ratuje cie brak animacji (kosci) oraz brak fizyki, nie zmienia to nadal faktu ze opengl to raczej archiwum.

 

3) - tak jak wspomnialem przy locie ratuje LOD i mipmapping. Najsensowniej byloby aby normal byl wysietlany dla pierwszego loda, dla drugiego,specular, a dla ostatniego tylko diffuse + oczywiscie 4 lod = cien.

Co do samych textur - nie wiem jak jest z wydajnoscia opengl, ale imho sadze ze na oko (nie bierzcie tych liczb doslownie) 20 setow po 1024x1024 powinniscie dac rade udzwignac. Zakladajac ze przy lodach i mipmapingu zjedziecie o polowe albo i nizej. Tutaj akurat bez testow sie nie da, duzo zalezy od silnika a jak wspomnialem opengl to raczej staroc.

 

4) - Nie bedziesz musial rozkladac ponownie. Poprostu bedziesz musial poprawic juz rozlozone uvw z racji brakujacych poligonow. Textura bez zmian, tylko mapowanie.

 

Obiekty najlepiej na bierzaco pokazywac na forum wraz z siatka i rozlozona uvw. Wtedy napewno jaksi feedback dostaniesz. Nie wiem czy miales cokolwiek do czyniena z game artem, ale to co napisales, co chcecie osiagnac, to jest duze wyzwanie dla kogos bez jakiegokolwiek doswiadczenia. Moim celem nie jest zniechecenie ciebie, ale uzmyslowienie ze to dosc duze wyzwanie, jezeli sie zaprzesz napewno dojdziesz do celu, nie zmienia to faktu ze bedzie to dosc trudne.

 

Zycze powodzenia.

[Oleksiak]

Dzięki za tak szybką odpowiedź..

 

1. Taki jest póki co plan. będziemi testować światło itp. w tym modelu bo ma bardzo dobre

proporcje - planuje wymodelować kilka obiektów z teksturami LOD'ami duże/małe itp. i

kopiować w różnych konfiguracjach - symulując oczywiście przy tym ilość obiektów jaką będzie

można widzieć na finale.

 

2. Sprawa wygląda tak że będzie to chodzenie po wnętrzu budynku - zwiedzanie w 3d - ale że

budynek jest zajebiście duży ;) chcemy dodać opcje latania w nim, żeby np. wyskoczyć z 2

pietra i polatać wokół lampy czy pod sufit. widok to będzie jedynie kamera przemieszczająca

się po budynku - żadnych broni, reki czy postaci :P Mógłbyś napisać coś więcej dlaczego

uważasz że LOD w tym wypadku jest zbędny. Wrzucam widok z góry parteru. Trochę nie

rozumiem jaki jest sens używania portali skoro jest możliwość użyć occluderow które wydają

mi się bardziej "uniwersalne" - jakbyś mógł napisz coś więcej. Google mam ;) ale chce usłyszeć

opinie kogoś z doświadczeniem.

"Pamietaj ze chec zrobienia duzej ilosci obiektow moze szybko spalic na panewce" - dlaczego ?

;)

"zabijasz framerate iloscia podobiektow" - chodzi o to żeby np. krzesło nie robić osobno nogi

osobno siedzenie i osobno oparcie, a jako całość ?

 

 

Kolorowe boxy to tylko widzi-mi-się max'a - ważne jest to że teraz mogę modelować ze zdjęć

mając dobre proporcje obiektów i ich miejsce w przestrzeni - to bardzo dużo ułatwi.

 

3. Jeżeli będą lody co to znaczy że dla 4 LOD'a będzie tylko cien - chodzi o ambient occlusion,

nie kumam ?

"20 setow po 1024x1024 " set to dif spec normal mapy ? Masz tutaj na myśli że tyle tekstur

widocznych udźwignie silnik, a nie w sumie prawda ? :P

 

 

 

Wrzucam obiekt który służy mi do nauki tworzenia LP obiektów z HP. Jest to część celownika

optycznego z mojego RPG-7 link do WIP'a poniżej.

Mam pytanie jak podejść do takiego obiektu żeby zrobić jego LP. Czasem robię tak że biore HP

i zaczynam optymalizacje, czasem zaczynam od nowa - wszystko zależy jak łatwiej, a tutaj to

jak ?

 

 

Edytowane 12 Sierpień 2011 przez Oleksiak

[Przybysz]

Wydaje mi się, że LOD lepiej sprawuje się na otwartej przestrzeni np. cały budynek, pojazdy itp, widoczne z dali. Wewnątrz obiektów stawiał bym raczej na occlusion culling czy portale. Poza tym zrobienie kilku LoD jest czasochłonne, a ich podmiana w realtime zawsze jest widoczna i niezbyt fajna. Jeśli nie będzie widoku z lotu ptaka na cały budynek bez dachu to wydaje mi się, że gra nie warta świeczki lub ewentualnie 1 dodatkowy poziom LOD powinien styknąć. Poza tym jeśli sporo obiektów będzie się powtarzała to OpenGL chyba też obsługuję jakąś formę hardware instancingu. To tak na zdrowy rozsądek, bo nie mam żadnego doświadczenia w programowaniu engine'ów. Nie wiem na jaki system to ma być, ale do analizy calego kodu pod względem wydajności to pod linuxem używałem profilera gprof i valgrind do szukania wycieków pamięci. Pod windowsa z kolei jest PerfHUD (zdaje sie tylko do DirectX) i NVIDIA PerfKit w tym GLExpert (do OpenGLa), ale to już stricte do szukania wąskich gardel w rendering pipeline. Byćmoże od ATI/AMD też jest jakieś narzędzie, trzebaby poszukać w ich Developers Centrall.

[JacekCichy]

No witam! :)

Z mojej strony to tak:

 

1. OpenGL jest dobrym wyborem bo jest dość intuicyjny w przeciwieństwie do DirectX'a więc jeżeli zależy wam na czasie to z DirectX'em od razu bym dał spokój.

 

2. Co do tej nieszczęsnej ilości obiektów to chodzi o to że nie ma problemu żebyście mieli obiekt który ma np. 500k trójkątów ale jeżeli zamiast tego jednego obiektu zrobicie 100 obiektów po 5k tris to już problem może się zacząć (po prostu aplikacja może zacząć się ciąć) :) Nie oznacza to oczywiście że macie mieć jeden obiekt w scenie, warto natomiast o tym wiedzieć i w ten sposób planować grę/symulację żeby tych obiektów nie było na tysiące.

 

3. Ilości trójkątów - jakiś czas temu robiłem teścik w moim silniku i wrzuciłem obiekt który miał 1.5M trójkątów. GeForce GTX460 radził sobie z tym całkiem dobrze bo wszystko chodziło płynnie. Tak więc może być i trochę ponad 1M trójkątów na całą scenę jeśli oczywiście na prezentację uda wam się przytachać maszynę z dobrą kartą graficzną :)

 

4. Tekstury - Tutaj nie znam odpowiedzi co do ilość. Ale zakładając że będziecie korzystać z tekstur 24bitowych to 1024*1024*3 = 3.1 Mb Więc myślę że 30-50 tekstur można by wykorzystać. Natomiast nie chcę za bardzo wprowadzać w błąd bo są to rozważania nie poparte głębszymi testami. Dlatego dobrze jest wykorzystywać jedna teksturą w co najmniej kilku miejscach jeżeli istnieje taka możliwość. (Chyba że zaimplementujecie technikę zwaną MegaTextures :P To wtedy możliwości się znacznie poszerzą :D natomiast jest to dosyć trudna sprawa i ja na swoim obecnym etapie bym się za to nie brał co nie znaczy że to niemożliwe :))

 

5. LOD'y i Portale - Tutaj widzę są różne opinie w tej kwestii natomiast według mnie powinniście zastosować i to i to :) Po co to wszystko? A no po to że pisząc o tych 1.5M trójkątów mam na myśli geometrię wyświetlaną w danej klatce a nie całość sceny. Jeżeli dobrze zrobicie system lodów i portali to i 10M trójkątów może być w scenie :) LOD'y osobiście zastosowałbym do np. garnków, rzeźb itp. bo z bliska fajnie żeby to było szczegółowe, a z dalsza już nie musi. Portale to ktoś wyżej dobrze pisał że do pięter, korytarzy a na końcu pokoi. Można oczywiście zastosować tzw. siatki adaptacyjne czyli zrobić jeden wydetalowany obiekt i niech algorytm się martwi ale no właśnie zawsze jest jakieś ale.. Algorytmy te nie są perfekcyjne i nie mają szans z dobrze przygotowanym zestawem LOD'ow przez grafika. Kolejna sprawa to skądś trzeba wziąść ten algorytm.. pisać samemu taki algorytm to to samo w sobie już jest tematem na inżynierke :P Sensowne wyjście to jeżeli zamiast lodów chcecie korzystać z siatek adaptacyjnych to skorzystajcie z jakiegoś gotowego silnika np. OGRE. Ostatnio też dosyć ciekawą sprawą jest sprzętowa tesselacja, można sobie zobaczyć na tym filmiku z Unigine jak to działa:

http://www.vidoevo.com/yvideo.php?i=YmtLdFkycWuRpRzNGYlU&hardware-tessellation-with-directx-11-unigine-heaven-benchmark

Natomiast nie korzystałem z tego więc nie wiem czy łatwo to zaimplementować czy nie :)

 

6. Napisz co chciałbyś aby Twoja aplikacja potrafiła robić. Czyli "latanie" masz na myśli przenikanie przez ściany (brak sprawdzania kolizji)? Czy chcesz wykorzystywać jakieś animacje szkieletowe, strzelać itp itd. :P :D To że tak powiem wszystko składa się na wydajność aplikacji bo wyświetlenie geometrii to dopiero początek problemów :)

 

7. Dosyć ważne pytanie które musice sobie zadać to czy chcecie sami wszystko pisać od nowa czy korzystać z jakiegoś silnika :)

 

8. Jeżeli jesteś zainteresowany to postaram się podesłać do końca tygodnia jakąś aplikację która pozwoli Ci na załadowanie modelu w formacie .obj z dowolną ilością tekstur i polatanie sobie po tym modelu kamerką :) (Będziesz mógł ocenić jak się ma sprawa z wydajnością :) )

 

9. Przed ostatnia rzecz to w jakim języku chcecie pisać: bo ja np. teraz męczę się w C++ i powiem szczerze że mam mieszane uczucia.. Bo owszem programy napisane w nim się szybciej uruchamiają natomiast jeżeli chodzi o szybkość aplikacji to początkujący nie ma za bardzo szans napisać czegoś co będzie dobrze zoptymalizowane w C++ natomiast Java a dokładnie Maszyna wirtualna i tzw. JIT wiele wybaczają :) Stąd w pojedynku program początkującego w Javie vs. program początkującego w C++ Ten pierwszy wypada trochę lepiej :) Niechcę Ci bardzo zamieszać bo spór C++ vs. Java vs. C# trwa długo i nikt za bardzo nie potrafi powiedzieć jak to naprawdę jest bo każdy z tych języków ma swoje plusy i minusy więc jeżeli już masz jakąś wizję to pozostań przy niej :) w każdym razie warto o takich niuansach wiedzieć. Ja jedynie mogę powiedzieć jakie są moje osobiste odczucia :)

 

10. Ostatnia rzecz to jeżeli czegoś nie rozumiesz coś źle wytłumaczyłem to się nie przejmuj i pytaj aż do oporu :)

[Skoti]

1. Potrzebujemy jakiegoś systemu/aplikacji do oceny wydajności kody i tego jaki wpływ

mają modele i jakość tekstur na wydajność aplikacji. Możecie polecić jakąś technikę itp.

Wiem że jest coś takiego jak programy które się odpala razem z aplikacją i analizują

która część kodu zabiera najwięcej zasobów - wiecie coś na ten temat ?

Możesz użyć gDEBugger (http://www.gremedy.com/ - masz tam profiler i całą masę liczników) lub jeśli używasz komercyjnej wersji VS 2010 możesz użyć pluginu od AMD http://developer.amd.com/tools/gDEBugger/Pages/default.aspx - zapewne możesz też trochę danych zebrać za pomocą http://developer.nvidia.com/nvidia-parallel-nsight (nie używałem - używam tylko gDEBugger pod linuksem). Jednak wymuszanie mipmap, podmiana tekstur, modeli musisz zrobić sam w aplikacji (programy zmierzą Ci wydajność i zrobią wykresy, ale trzeba im pomóc).

 

2. ...czy podłoga ma być jednym obiektem czy jakoś ją podzielić

to samo ściany korytarzy... ?...

Zależy jak się będzie silnik fizyki zachowywał przy chodzeniu - jeden duży czworokąt jest dobry dla wydajności, za to silniki fizyki gdy małe obiekty poruszają się po dużych polygonach lubią być niestabilne, więc wtedy musisz zagęścić siatkę.

 

3. W aplikacji będzie możliwa opcja latania dlatego ciekawi mnie jak ogarnąć tekstury

i ile może ich być. Chcemy umieścić diffuse mapy, specular mapy i normal mapy.

Może być tyle ile się zmieści w pamięci ram minus framebuffory i siatka - tylko tekstury na GPU są przechowywane nieskompresowane (tzn są formaty skompresowane, ale niewiele się na tym zyskuje) i dobrze mieć mipmapy więc nie przesadzajcie z rozdzielczością. Co do Spec mapek to jeśli możecie odpuścić sobie kolory i będą sterować jedynie intensywność (skala szarości), to możecie to wrzucić razem z normalmapą, jako jej kanał alpha.

 

4. To co mnie najbardziej ciekawi: LOD czyli "level of detail" . Wydaje mi się że tutaj miałoby

sens...

Lepiej nie rysować wcale tego czego nie widać, dlatego tu lepiej postawić na organizację obiektów w jakimś drzewku i rysować to co może być widoczne, a nie wszystkiego., wtedy LOD nie będzie za bardzo potrzebny, bo przydałby się jakby obiekty widoczne były dalej niż kilkadziesiąt metrów - w obiekcie zamkniętym rzadka sprawa, a jak się zdarza to niewiele ma to wpływu na wydajność - prędzej pomyślałbym o zagęszczaniu siatki bliskiej kamerze (tessellacja), ale to wymaga kart zgodnych z OpenGL 4.0, więc znacznie wyżej niż zakłada projekt. Jeśli jednak chcesz robić automatyczny LoD to w sieci cała masa jest artykułów o uproszczeniu siatki gdzie efektem jest siatka już z interpolowanymi UV automatycznie... ale nie widzę większego sensu tu w LoD.

 

"zabijasz framerate iloscia podobiektow" - chodzi o to żeby np. krzesło nie robić osobno nogi

osobno siedzenie i osobno oparcie, a jako całość ?

Raczej o to, żebyś korzystał z instancingu, oraz, żeby nie było setek draw calli - OpenGL jest mniej wrażliwy na ilość DrawCalli ale jednak warto tu uważać i pakować co się da w większe paczki VBO.

 

 

"20 setow po 1024x1024 " set to dif spec normal mapy ? Masz tutaj na myśli że tyle tekstur

widocznych udźwignie silnik, a nie w sumie prawda ? :P

Set złożony z tekstur RGB i RGBA (kolor i normalna połączona ze spec) o rozdzielczości 1024x1024 to 7MB (3+4 bajty * rozdzielczość) i musisz dodać do tego mipmapy więc będziesz miał ~10MB, więc na karcie z 1GB pamięci zmieści Ci się niecałe 100 setów (bo trzeba odjąć siatkę i framebuffer), Jeśli jednak na mniejszych obiektach użyjesz 512x512 to z jednego seta robi się 4 które możesz użyć (256x256 to zmieści się 16 setów w jednym secie o rozmiarach 1024x1024). Po prostu używaj tekstur z rozwagą i nie przesadzaj z rozdzielczością.

 

...nie zmienia to nadal faktu ze opengl to raczej

....

archiwum.wspomnialem opengl to raczej staroc.

Możesz rozwinąć tę myśl?

Już pomijam fakt, że najnowsza wersja OpenGL ma niecałe 4 dni ;p.

 

//EDIT:

Ostatnio też dosyć ciekawą sprawą jest sprzętowa tesselacja, można sobie zobaczyć na tym filmiku z Unigine jak to działa:

http://www.vidoevo.com/yvideo.php?i=YmtLdFkycWuRpRzNGYlU&hardware-tessellation-with-directx-11-unigine-heaven-benchmark

Natomiast nie korzystałem z tego więc nie wiem czy łatwo to zaimplementować czy nie :)

Bardzo łatwo - ofc trzeba się liczyć z dodatkowym kanałem tekstury np. koloru, na displace mapę, ale sama implementacja to napisać 2 proste shaderki na kilka minut pisania. OFC jeśli wymogiem jest kontekst 2.1 to nie ma mowy o tessellacji, bo nawet jako rozszerzenie wymagany jest kontekst 3.x

Edytowane 12 Sierpień 2011 przez Skoti

[Oleksiak]

Dziękuje wszystkim za tak dużo informacji - jak sprawdzimy wszystko to damy znać. Póki co mam pytanie o wypalanie normali.

 

Tutaj mam taki element z hard edge

i bez

 

mam taki problem: (wszystko wypalane przy pomocy xnormal )

 

1. jak zrobić żeby wypalić normale na całym obiekcie ale nie brać pod uwagę tego przełącznika, a żeby normale były też wypalone na tym przełączniku - problem jest dlatego że obie rzeczy są na jednym UVW - i powiedzmy że tak chce zostawić.

 

2. jak daje na wszystko jedną SG to robi się kaszana a z hard edge to jakoś wygląda zwłaszcza ten element z otworami.

[Oleksiak]

Ok przyznam że się troszkę pogubiłem - cały czas myślałem że obiekt LP powinien mieć tylko jedną SG teraz znalazłem informację że ma mieć różne SG w klastrach UVW jak tak zrobiłem to działa więc problem rozwiązany. Wrzucam model z rozłożoną UVW - celownik optyczny w RPG na tym modelu uczę się pod prace inżynierską.

 

Jedyne co trzeba jeszcze zrobić to ustawić wszystkim obiektom UVW tak żeby kwadraty były jednakowe. Dalej prosiłbym o pomoc w sprawie wypalania normali tego czegoś. Nie wiem jak teraz do tego podejść jeżeli wrzuce to do jednego mesha to przecież CAGE w projection będzie na siebie wszędzie nachodził i będę musiał go w wielu miejscach ręcznie poprawiać - no chyba że tak się robi ;]

 

 

 

[ultrakaka]

Rozsuń poszczególne elementy( najpierw sobie skopiuj gotowy do wypalania lp żebyś nie musiał składać z powrotem ( albo sobie zanimuj to rozłożenie))i wtedy wypalaj, w ten sposób cage będzie się czysto rozkładał. Poprawiania cage'a jednak nie unikniesz ale to już szczegóły.

[Oleksiak]

Wielkie dzięki za pomoc ! W połączeniu z możliwością eksportowania cage do siatki i łatwej edycji teraz mogę zacząć coś robić.

 

Interesuje mnie jeszcze roleta "projection" w modyfikatorze "projection" można tam nacisnąć "add" wielka roleta się pojawi "project mapping" - i można wiedzieć po co to bo czytam tego helpa i nie rozumiem..

 

EDIT:

 

mam jeszcze jedno ważne pytanie... mam taką UVW rozłożoną:

 

Daje rade ? coś trzeba poprawić ? Chce tylko zaznaczyć że póki co nie chce się uczyć robienia mirrorów normali dlatego ich nie ma na UVW, a wiem że tam trzeba jakieś kombinacje robić żeby zrobić mirror normali.

 

a ważne pytanie brzmi następującą: czy da się jakoś zaznaczyć te klastry w UVW i nadać im inne SG bo teraz wszystko ma 1 SG i jak będę musiał przeskakiwać miedzy modyfikatorem i Edit poly to chyba zwątpię. Mam nadzieje że jest jakieś łatwe rozwiązanie.

 

Pozdrawiam.

Edytowane 14 Sierpień 2011 przez Oleksiak

[Por@szek]

Możesz rozwinąć tę myśl?

Już pomijam fakt, że najnowsza wersja OpenGL ma niecałe 4 dni ;p.

 

Doinformowalem sie :) Prosze o zignorowanie mojej opinii ad OpenGL ;)

[Oleksiak]

Skończyłem wypalać normale... W kilku miejscach są błędy, wiem jak je naprawić ale póki co zostawiam to i biorę się za naukę teksturowania. Wiem że niektóre elementy mogłem nie wypalać tylko dodać w PS no ale cóż ... teraz to wiem. Podczas teksturowania będę robił sporo pęknięć itp. wiec później przy użyciu pluginu nDo dodam normale do tego co już mam.

 

 

 

 

 

 

 

Pozdrawiam.

[Dynamico]

Czy jesteś pewny tej literki "L" na wyłączniku? Moim zdaniem takiej litery jak u ciebie w cyrylicy nie ma.

[Oleksiak]

Hey taka litera tam jest za to nie ma tej litery A ;) i nie wiem czemu to tak zrobiłem.

 

Jestem na etapie teksturowania. Chce póki co zrobić zarys kolorów i zadrapań, a później dodam detale na normale poprawie specular itp. Zarapań jest chyba trochę za wiele ale to później postaram się poprawić.

 

Podczas robienia tekstur używam do podglądu marmoset'a tylko nie wiem jakie światła itp. są dobre w tym silniku do podglądu modelu - Macie jakieś propozycje.

 

Screeny z max'a bo marmo wypluwa jakieś dziwne

 

 

 

 

Pozdrawiam.

[bari]

Witam

 

Jestem wspomnianym na początku współautorem pracy inżynierskiej. Zajmuję się OpenGL.

 

Przyszedł czas, kiedy chcemy, aby powstał już jakiś zalążek docelowej aplikacji, w której można będzie testować modele, wydajność, ustawienia parametrów świateł itp.

 

Początki nie są łatwe jak wiadomo i na wstępie mamy problem (a właściwie mam ja ;) ) z modułem ładującym obiekty w formacie *.3ds do sceny w OpenGL. Niestety w założeniach naszej pracy jesteśmy ograniczeni do tego właśnie formatu i niezbędna jest dobra implementacja. Zanim wziąłem się za pisanie kodu, założyłem naiwnie, że bez problemu znajdę w Internecie "gotowca", którego podepnę pod projekt i po wywołaniu dwóch funkcji będzie mi pięknie ładował modele z teksturami, a ja będę mógł skupić się na innych rzeczach, które chciałem dodać do projektu. Jednak rzeczywistość jest inna. Udało mi się znaleźć kilka loaderów, ale albo są napisane w innym języku (niż C/C++), albo nie mają funkcji rysującej obiekt, albo nie obsługują tekstur, albo działają i ładują obiekt lecz bez naniesionej tekstury, choć z kodu wynika, że obsługują tekstury, a pliki tekstur są dostępne. Zatem zastanawiam się, czy nie pozostaje mi napisanie własnego loadera ;). (Co mogłoby być tematem osobnej pracy inżynierskiej :P). I tutaj będą moje pytania i prośba o wskazówki:

 

1. Czy brać się za pisanie i nie szukać dalej loadera? (ponieważ projekt jest i tak obszerny i wolałbym to obejść i zająć się implementacją innych rzeczy)

2. Na ile może się przydać wiedza zdobyta przy pisaniu loadera, do np. późniejszej optymalizacji całego projektu.

3. Czy ktoś może zna i może podać skąd ściągnąć działający loader plików .3ds z teksturami pod OpenGL.

 

Te pytania na razie najbardziej spędzają mi sen z powiek.

W dalszej kolejności są inne założenia, które też chciałbym dodać (zobaczymy co z tego wyjdzie):

 

4. Chodzenia i poruszanie kamerą jak w FPS'ach.

5. Do tego przełączanie w tryb latania.

6. Wykrywanie kolizji obiektów, aby nie dało się przenikać przez ściany.

 

Proszę o wskazówki i rady. Dzięki :).

[Skoti]

@bari: Na samym początku muszę napisać, że współczuję konieczności używania *.3ds, bo to format bardzo słaby, bardzo stary i mało potrafiący (nie da się w nim np. zapisać animacji szkieletowej). Zastanawia mnie po Co Ci rendering w bibliotece do ładowania danych?

 

1. Nie pisz loadera, bo szkoda pisać loader do 3ds i szkoda interesować się jego strukturą... skorzystaj z gotowca bez renderera (zapewne dostaniesz ładne tablice z danymi które tylko wystarczy podać do funkcji OpenGL w jaki sposób chcesz (np. zbudować VBO) - zapewne specjalnie nie jest pisany renderer, żeby każdy robił jak chce, oraz dostajesz ładne ścieżki do tekstur (bez problemu załadujesz za pomocą SOIL, DevIL, FreeImage czy innych bibliotek do OpenGL)).

2. Wiedza dotycząca samego ładowania struktury pliku 3ds na nic Ci się nie przyda - za to rendering tego co się wczyta już powinieneś robić sam i zoptymalizować jak potrafisz.

3. Np. AssImp do ładowania wielu formatów (m.in. 3ds) http://assimp.sourceforge.net/index.html - tylko nie używaj przykładowego kodu OpenGL na poważnie bo rendering jest tam zrobiony najwolniej jak się tylko da (tryb bezpośredni).

 

4. Jeśli wiesz co to sferyczny układ współrzędnych i znasz wzory na zamianę na układ kartezjański lub znasz macierze transformacji http://pl.wikipedia.org/wiki/Elementarne_macierze_transformacji to nie powinieneś mieć problemu, ale na wszelki wypadek podam prosty przykład takiego ruchu jak w FPS http://nehe.gamedev.net/tutorial/loading_and_moving_through_a_3d_world/22003/ ... tylko że pewnie nawet tej wiedzy nie potrzebujesz jeśli zastosujesz punkt 6.

5. Podobnie jak 4

6. Użyj bibliotek fizycznych jak Bullet lub PhysX - poza odwaleniem za Ciebie wykrywania kolizji i zachowania obiektów przy kolizji (ustawiasz kształt i materiał, a reszta "robi się sama"), zajmie się też obrotami i ruchem bohatera (i tylko otrzymane dane przekazać do kamery).

[JacekCichy]

Skoti mnie tu już widzę ubiegł :)

 

- Co do pisania loaderów modeli czy tekstur to sprawa jest taka że najszybciej skorzystać z gotowca ale napisanie tego samemu jest bardzo kształcące i nie chodzi tu wcale o to czy to jest .3ds czy .xml czy .obj czy jeszcze coś innego. Podczas pisania kodu nabierasz doświadczenia poznajesz co jak działa i rozwiązujesz problemy. Jeżeli jesteś bardzo ograniczony czasowo to skorzystaj z linków od Skotiego ale jeżeli nie to szukaj dokumentacji .3ds i dawaj :)

 

- Widzę że mieszasz trochę pojęcia załadowania modelu a renderowania. Nie wiem na jakim jesteś poziomie ale na początek spróbuj wyświetlić sobie obracający się trójkąt. Jeżeli się to uda to już będziesz wiedział mniej więcej jak to działa. Co do tego z jakiego api korzystać to ja piszę w WinApi bo chciałem uniwersalnie niezależnie i takie tam sraty taty w każdym razie jak masz mało czasu to nie polecam się w to bawić tylko skorzystaj z glut'a. Są gotowe przykłady w sieci więc wrzucisz do kompilatora potestujesz i w miarę powinieneś ogarnąć. Co do tutoriali nehe(baza jeżeli chodzi o naukę openGL) to jest też wersja polska tutaj: http://aklimx.sppieniezno.pl/nehepl/display.php

 

- Co do samego .3ds to również współczuję no ale mus to mus :) Jeżeli chodzi o "statyczne" formaty modeli to ja osobiście uznaję tylko .obj.

 

- Co do VBO itp. rozwiązań to Skoti trochę przesadzasz bo widzisz że chłopaki dopiero zaczynają a Ty im zaraz powprowadzasz takie pojęcia że goście z Cryteka będą się zastanawiać :P Szanuję Twoją widzę bo masz jej bardzo dużo i piszesz mądre rzeczy ale ja osobiście odnoszę wrażenie że Bari'emu narazie przydało by się wyrenderowanie przysłowiowego trójkąta właśnie :)

 

- Kamerę ogarniesz bez problemu bo to tylko parę linii kodu :)

 

- Co do kolizji to ja piszę sam ale to trochę wynajdywanie koła na nowo więc nie mam na ten temat zdania :) Tutaj Skoti dobrze prawi że najlepiej skorzystać z gotowych bibliotek ;)

 

EDIT: Wysłałem wam na maila mój moduł loadera formatu .obj :)

[Skoti]

- Co do pisania loaderów modeli czy tekstur to sprawa jest taka że najszybciej skorzystać z gotowca ale napisanie tego samemu jest bardzo kształcące i nie chodzi tu wcale o to czy to jest .3ds czy .xml czy .obj czy jeszcze coś innego. Podczas pisania kodu nabierasz doświadczenia poznajesz co jak działa i rozwiązujesz problemy. Jeżeli jesteś bardzo ograniczony czasowo to skorzystaj z linków od Skotiego ale jeżeli nie to szukaj dokumentacji .3ds i dawaj :)

Ja ogólnie nie uznaje gotowych loaderów i wolę jeden dobry napisać (do Collada) i konwertować do własnego formatu, ale w wypadku projektu na studia, oraz wymuszenia 3ds (który jest tragiczny i niczego dobrego nie nauczy) uważam, że gotowiec jest usprawiedliwiony ;p (nigdy tego loadera by nie użył, a jedynie dowiedział by się jakich formatów nie robić).

 

Co do tego z jakiego api korzystać to ja piszę w WinApi bo chciałem uniwersalnie niezależnie i takie tam sraty taty w każdym razie jak masz mało czasu to nie polecam się w to bawić tylko skorzystaj z glut'a.

GLUT to złoo ;p. Polecałbym raczej SDL czy GLFW.

 

- Co do VBO itp. rozwiązań to Skoti trochę przesadzasz bo widzisz że chłopaki dopiero zaczynają a Ty im zaraz powprowadzasz takie pojęcia że goście z Cryteka będą się zastanawiać :P Szanuję Twoją widzę bo masz jej bardzo dużo i piszesz mądre rzeczy ale ja osobiście odnoszę wrażenie że Bari'emu narazie przydało by się wyrenderowanie przysłowiowego trójkąta właśnie :)

Nie ma co demonizować VBO - kilka funkcji i to dobrze opisanych w sieci i to wszystko - tryb bezpośredni jest trudniejszy (każdy wierzchołek to wiele osobnych funkcji, a nie jak w VBO kilka funkcji na wszystkie dane w modelu).

 

- Co do kolizji to ja piszę sam ale to trochę wynajdywanie koła na nowo więc nie mam na ten temat zdania :) Tutaj Skoti dobrze prawi że najlepiej skorzystać z gotowych bibliotek ;)

Ja wynajdywałem to koło kiedy silniki fizyki jeszcze raczkowały, lub były w zaporowych cenach... teraz już mi się nie chce ;], bo sam będę robił bardzo długo, i nie zaimplementuję tego tak dobrze jak w silnikach fizyki (nie jestem specjalistą od programowania fizyki, w przeciwieństwie do twórców tych silników ;p).

[Oleksiak]

hey

 

Brakuje spec i dodanych normali no i... obudowę będę jeszcze raz malował bo metal mi nie pasuje.

 

 

 

 

 

Co o tym sądzicie ?

[Oleksiak]

mamy takie pytanie... Jaka jest różnica pomiędzy formatem tekstur w jpg i tga ?

 

Który format powinniśmy stosować ? Z góry dzięki za pomoc ;)

[Skoti]

mamy takie pytanie... Jaka jest różnica pomiędzy formatem tekstur w jpg i tga ?

 

Który format powinniśmy stosować ? Z góry dzięki za pomoc ;)

- JPG mniej zajmuje na dysku (w pamięci karty czy ram tyle samo), daje gorszą jakość (format jest stratny) i ma tylko kanały RGB (nie zawiera informacji o przezroczystości)

- TGA podobnie jak PNG zajmuje dużą ilość miejsca na dysku, daje idealną jakość (format bezstratny) i potrafi przechowywać RGBA.

Podsumowując zależy co Was ogranicza i co potrzebujecie - jeśli kanał A was nie interesuje to JPG, jeśli ogranicza was przestrzeń dyskowa to JPG, jeśli przeszkadzają artefakty kompresji w plikach JPG to TGA/PNG w innych wypadkach TGA lub PNG.

[bari]

Witam

 

Projekt posunął się do przodu. Mamy na tą chwilę dobrze działający loader plików .3ds wraz z teksturami w .tga, który rysuje modele metodą VBO (Vertex Buffer Object). Jest też działająca kamera tak jak chcieliśmy, choć działa to na zasadzie przesuwania całej sceny, a nie samej kamery, ale efekt jest zgodny z oczekiwaniami (nie wiem tylko, czy to dobry sposób, czy nie będzie to kolidowało z implementacją innych rzeczy). Zgłębiliśmy kilka tematów, które musimy przerobić na najbliższej przyszłości, stąd mamy serię bardziej szczegółowych pytań. Będziemy wdzięczni, za pomoc.

 

1. Biblioteka GLUT.

Korzystamy w tej chwili z biblioteki GLUT. Czy to dobry pomysł i czy to nie będzie ograniczające w dalszej perspektywie. A jeśli nie GLUT to jaka? Spotkałem na internecie wiele przykładów z WinAPI (nie wiem, czy to poprawna nazwa, ale występuje tam funkacja WinMain zamiast main itp.)

 

2. Kamera i kolizje obiektów.

Trudny temat, nie wiem czy czuję się na siłach, żeby pisać sobie samemu algorytmy wykorzystujące równania płaszczyzn, wektorów i sprawdzanie przecięcia. Natomiast biblioteki fizyczne, które wcześniej tu były wspomniane, też nie są zbyt przystępne. Nie bardzo wiem jak z nich skorzystać. Czy wykorzystanie ich polega na podpięciu do projektu, potem utworzenia obiektu i jakieś operacje z tym obiektem? Z dokumentacją i przykładami do tych bibliotek też ciężko. A jak ma się sprawa łączenia algorytmów wykrywania kolzji z obiektami .3ds? Czy rysowanie VBO pozwala na dołączenia wykrywania klizji, czy trzeba by przejść na rysowanie bezpośrednie?

 

3. Światła w scenie.

Ile świateł można zastosowa? Wiem, że OpenGL obsługuje 8, ale jak je rozmieszczać i czy dadzą one wiarygodne efekty w oświetlaniu budynku wewnątrz?

 

4. Obsługa normal map.

W jaki sposób je zaimplementować wraz ze zwykłymi teksturami i również jak to się ma do rysowania ich z ładowanymi modelami .3ds rysowanymi przez VBO?

 

5. Specular mapy.

To samo co w poprzednim punkcie, tylko w połączeniu z normal mapami.

 

6. Cienie.

Jaką metodę rysowana cieni zastosować? Z tego co wiem są cienie płaskie, bryły cieni i mapowane cienie. Jak wygląda obsługa cieni z wieloma światłami w scenie? Czy da się tak to zaimplementować, żeby wyglądało naturalnie?

 

7. W jakim stopniu da się zrealizować te efekty bez wdrażania shaderów (GLSL)? Czy po zastosowaniu programów cieniowania łatwiej jest uzyskać tego ypu efekty?

 

8. Optymalizacja.

Jak konstruować modele? Z tego co wiemy, to powinno się robić jak najmniej obiektów. Tylko nie wiemy czy lepiej jest zrobić powtarzalną ławkę, która będzie występowała wiele razy w całym budynku i inne tego rodzaju powtarzalne elementy jako osobne obiekty? Czy może podzielić budynek na "skrzydła" i całe skrzydła ładować do jednego obiektu/modelu?

Czy warto pokusić się o implementację testu zasłaniania obiektów?

Na koniec, co będzie chodziło szybiciej i da ciekawsze efekty - prosta geometria i normal mapy + diffuse map, czy złożona geometria i diffuse map?

 

 

Sporo tego... Dzięki za zainteresowanie i cierpliwość :).

[Skoti]

1. GLUT jest złym pomysłem - radziłbym zainteresować się SDL lub GLFW.

 

2. Zarówno dokumentacja do bibliotek fizycznych jak i przykłady są łatwo dostępne i dosyć jasne - ogólnie na początku tworzysz świat fizyczny (w Bullet masz np. zmienną typu btDiscreteDynamicsWorld której ustalasz jaki algorytm ma być wykorzystywany przy liczeniu kolizji czy ustalasz grawitację (wartość jak i oś w której działa (zazwyczaj Y lub Z))) - dalej w klasie w której masz załadowane *.3ds dajesz obiektowi poza siatką zmienną jak np. btRigidBody (czyli bryła sztywna) i ustalasz tarcie, masę (w bullet wartość 0 to obiekt statyczny) i inne fizyczne oraz kształt (kształt jest ważny ze względu na wydajność - jeśli całą scenę potraktujesz jako siatka to procesor się nie wyrobi - dlatego np. małym obiektom dajesz kształt box/sphere/capsule (wartości możesz podawać ręcznie lub odczytać takie jak wysokość/szerokość/długość czy promień będziesz miał jak przelecisz w pętli wierzchołki modelu i zbierzesz informacje o wartości maksymalnej i minimalnej dla każdej osi (różnica max-min to wielkość modelu w danej osi (oraz podwójna wartość promienia kuli opisanej na modelu)))) - jeśli chcesz mieć dokładniejszy kształt to masz też obrysy wypukłe czy dokładny kształt siatki (do utworzenia obu podajesz podobne dane jak do utworzenia VBO - czyli siatkę)... dodajesz to do świata (dynamicsWorld->addRigidBody(RigidBody);) i co klatkę świat aktualizujesz (w bullet dynamicsWorld->stepSimulation(...);), a przy rysowaniu obiektu ze zmiennej odczytujesz macierz (RigidBody->getWorldTransform().getOpenGLMatrix(macierz);) i już masz całą fizykę - ofc dla innych typów obiektów niż bryła sztywna robisz to trochę inaczej, ale zasada pozostaje ta sama (i wszystko masz w dokumentacji).

 

3. Jeśli chcesz obyć się bez shaderów to albo wypalisz lightmapy (tylko nie liczyłbym na to, że 3ds przechowa Ci więcej niż 1 UV więc słabo), albo będziesz miał listę świateł i sortując względem najbliższych włączysz te 8 które są najbliżej - jeśli chcesz użyć shadery to deferred shading (renderujesz Gbuffory do multi render targetów (polecam FBO (Framebuffer Object) w którym na raz w jednym shaderze możesz pisać na raz do 8 tekstur) w fazie geometrii i w fazie oświetlenia możesz mieć nawet tysiące świateł, a nie wpłynie to znacząco na wydajność).

 

4. Bez shaderów Multitexturing i bawienie się z rozszerzeniem GL_DOT3_RGB_EXT lub z shaderami multiteksturing i napisanie shadera.

 

5. Nie pamiętam jakie/czy jakiekolwiek rozszerzenie SpecMap nie użyjesz bez shaderów - z shaderami to po prostu sobie wrzucasz jako n-tą teksturę w multitexturingu (masz do dyspozycji od GL_TEXTURE0 do GL_TEXTURE31) na uniformy.

 

6. Jeśli chcesz dosyć naturalny wygląd sceny (czytaj cienie wewnątrz budynku rzadko (nigdy) nie są ostre więc odpadają Ci Shadow Volumes) jeśli chcesz naturalny efekt uzyskać i pozostaje Ci Shadow Mapping i PCF (Percentage Closer Filtering), żeby mieć miękkie cienie - dla lepszego efektu (lepszej precyzji) skorzystaj z VSM (Variance Shadow Maps).

 

7. Bez shaderów praktycznie bardzo ograniczasz efekty, a te które da się uzyskać, zdecydowanie łatwiej osiągniesz korzystając z shaderów.

 

8. Zależy czy ogranicza Cię ilość obiektów czy rozmiary w pamięci - większa ilość pojedynczych obiektów będzie spowalniać komunikację CPU -> GPU, wiele razy ta sama siatka w jednym VBO zwiększy jego rozmiary - możesz też użyć instancingu, ale zapewne wymagania Ci się nie spodobają (GeForce z serii 8000 lub nowszej, Radeon HD 2k lub nowszy), ze względu, że bronisz się przed shaderami.

Tak - warto się pokusić ;].

Ofc, że prosta geometria z normalkami będzie działać szybciej (ale też nie będzie taka ładna... tylko dla niewprawnego oka będzie udawać ładną).

[JacekCichy]

To ja też wtrące swoje 3 grosze :D

 

1. Według mnie GLUT nie jest wcale złym pomysłem :) Nijakie EtherFields też jest na Glucie i działa oraz wygląda całkiem fajnie :) Co do WinApi to owszem da się ale z moich osobistych doświadczeń to krew, pot i łzy :P

 

2. Kamerę zrób sobie normalnie czyli funkcja glLookAt() dlatego że nie warto sobie utrudniać na siłę życia :)

 

3. Co do reszty pytań zgadzam się z Skotim w 100% :)

[Skoti]

To ja też wtrące swoje 3 grosze :D

 

1. Według mnie GLUT nie jest wcale złym pomysłem :) Nijakie EtherFields też jest na Glucie i działa oraz wygląda całkiem fajnie :) Co do WinApi to owszem da się ale z moich osobistych doświadczeń to krew, pot i łzy :P

 

2. Kamerę zrób sobie normalnie czyli funkcja glLookAt() dlatego że nie warto sobie utrudniać na siłę życia :)

 

3. Co do reszty pytań zgadzam się z Skotim w 100% :)

1. Na GLUT ofc nie ogranicza jeśli chodzi o wygląd i jeśli jest użyty tylko do utworzenia okna to jeszcze ujdzie, tylko po co się z nim męczyć skoro są ciekawsze alternatywy ;p. WinAPI też może być jeśli chcesz tylko zrobić okienko, podpiąć OpenGL i zapomnieć (jednak jeśli chcesz dorobić GUI to lepiej odstawić WinAPI daleko i zainteresować się QT/Wx).

 

2. Nie ma takiej funkcji jak glLookAt - jest gluLookAt, a całe glu* zniknęło razem z OpenGL 3.0 więc lepiej się nie przyzwyczajać (tzn można użyć jednej z bardzo wielu bibliotek matematycznych z obsługą macierzy i tam też będziesz miał implementacje LookAt - np. w Configurable Math Library (http://cmldev.net/) masz funkcje cml::matrix_look_at_RH(), albo w GLM (http://www.g-truc.net/project-0016.html - trochę dziko napisana biblioteka, ale plusem jest składnia z shaderów GLSL) masz glm::lookAt()). Jednak to nie zmienia tego, że korzystając z jakiegokolwiek LookAt faktycznie transformujesz scenę, a nie kamerę - w shaderze wierzchołków przygotowujesz pozycje wierzchołka do operacji na fragmentach/pixelach - musisz dostarczyć macierze projekcji (nazwijmy Proj), później macierz widoku (View), dalej macierz Modelu (Model) i wektor 4-elementowy pozycji (POS = vec4(x, y, z, 1)) i przekazujesz iloczyn do gl_Position

gl_Position = Proj * View * Model * POS

bez shaderów w starym OpenGL ofc robisz to samo, Proj (GL_PROJECTION) ustawiasz za pomocą gluPerspective/gluOrtho, View i Model są połączone (GL_MODELVIEW) i ustawiasz za pomocą gluLookAt (View), a później to przemnażasz przez macierz Model (glRotate/glTranslate/glScale). Czyli ogólnie rzecz biorąc zasada jest ta sama i ruszasz nie kamerą, a światem (kamera jest zawsze w punkcie (0, 0, 0) i siatka jest przekształcana tak, zeby być widoczna przez kamerę, a nie odwrotnie);

[Oleksiak]

Skoti i JacekCichy - jest to niesamowite jak dużą wiedzę posiadacie z zakresu opengl wydaje mi się że większą od niejednego wykładowcy opengl z którym rozmawialiśmy :)

 

Dzięki za pomoc pozwala nam to bardziej ogarnąć problemy przed którymi stoimy - zwłaszcza kumplowi ale i ja mam kilka pytań z którymi się już od jakiegoś czasu męczę i jeżeli potraficie pomóc to byłbym wdzięczny.

 

otóż:

 

1. Skoti napisałeś: "większa ilość pojedynczych obiektów będzie spowalniać komunikację CPU -> GPU, wiele razy ta sama siatka w jednym VBO zwiększy jego rozmiary - możesz też użyć instancingu, ale zapewne wymagania Ci się nie spodobają (GeForce z serii 8000 lub nowszej, Radeon HD 2k lub nowszy)" - moim zdaniem te wymagania są dość niskie bo chyba każdy teraz kupiony laptop je spełni a nawet te sprzed 2-3 lat a to nam wystarczy. Mógłbyś coś więcej napisać o instancingu - będę go używał podczas modelowania ile się tylko da i mieliśmy nadzieje że model jako instance z tekturą taką samą jak inne jego kopie będzie bardziej wydajny dla aplikacji niż zwykłe kopie obiektów.

 

2. przy eksporcie modeli z 3ds max'a do .3ds będę używał wbudowanego exportera. Czy są jakieś rzeczy/opcje w obiektach na które mam uważać przy eksporcie - coś co będzie zajmować pamięć albo czas procesora podczas ładowania lub używania obiektów ?

 

3. przychodzą Wam do głowy jeszcze jakieś rady o których taki początkujący jak ja (jeśli chodzi o game art) mógłby nie widzieć, a są bardzo istotne - bo jeżeli tak to śmiało piszcie ;)

 

 

Co do mojej części projektu modelowanie zacznę najprawdopodobniej za góra miesiąc gdy będę znał wszystkie potrzebne informacje.

 

Pozdrawiam.

[Skoti]

1. ...moim zdaniem te wymagania są dość niskie bo chyba każdy teraz kupiony laptop je spełni a nawet te sprzed 2-3 lat a to nam wystarczy. Mógłbyś coś więcej napisać o instancingu - będę go używał podczas modelowania ile się tylko da i mieliśmy nadzieje że model jako instance z tekturą taką samą jak inne jego kopie będzie bardziej wydajny dla aplikacji niż zwykłe kopie obiektów.

Bez problemu kupisz laptop z GPU nie obsługującym instancingu - wystarczy procek starszy niż najnowsza generacja intela (starszy niż SandyBridge, bo nawet i7/i5 pierwszej generacji nie będzie obsługiwać) i integra Intela o co wcale nie jest trudno. Dodatkowo możliwe, że musicie odpalić na uczelnianych kompach, a tam mogą być starsze karty

 

2. przy eksporcie modeli z 3ds max'a do .3ds będę używał wbudowanego exportera. Czy są jakieś rzeczy/opcje w obiektach na które mam uważać przy eksporcie - coś co będzie zajmować pamięć albo czas procesora podczas ładowania lub używania obiektów ?

Nie znam eksportera 3ds max (nie używam tego programu), ale co do samego formatu 3ds to nie używaj kości (format ich nie obsługuje), nie przekraczaj 65536 trójkątów (więcej format nie obsługuje).

[JacekCichy]

Nie ma takiej funkcji jak glLookAt - jest gluLookAt

 

Mea culpa :) oczywiście glu :) Ja pomimo używania shaderów używam gluLookAt i póki co daje radę. Jeżeli jest oznaczona jako DEPRECATED to pewnie będzie się kiedyś trzeba przestawić ale póki co daje radę :)

 

Skoti i JacekCichy - jest to niesamowite jak dużą wiedzę posiadacie z zakresu opengl wydaje mi się że większą od niejednego wykładowcy opengl z którym rozmawialiśmy :)

 

Hehe dzięki :) Jeżeli chodzi o mnie to jeszcze bardzo długa droga przede mną :D A co do niektórych wykładowców na AGH no to hmm... Niestety nieraz to strata czasu...

[Skoti]

Mea culpa :) oczywiście glu :) Ja pomimo używania shaderów używam gluLookAt i póki co daje radę. Jeżeli jest oznaczona jako DEPRECATED to pewnie będzie się kiedyś trzeba przestawić ale póki co daje radę :)

Nie jest oznaczona jako DEPRECATED tylko wyleciała ze standardu w OpenGL 3.1 (jak i wszystkie funkcje typu glRotate itp.) i teraz są wspierane tylko jako niezobowiązujący Compatibility Profile (żeby mieć wsparcie dla OpenGL 3.1+ trzeba mieć tylko Core Profile), i mimo, że jak włączysz profil kompatybilności to dalej działa to w standardzie OpenGL (Core) już tego nie ma i wątpię, żeby była w urządzeniach mobilnych które zapowiadają wsparcie dla OpenGL 4+, pod koniec przyszłego roku (urządzenia które pracują teraz pod OpenGL ES 2.x raczej nie będą chciały implementować wszystkiego, a zrobią tylko to co konieczne).

 

 

Hehe dzięki :) Jeżeli chodzi o mnie to jeszcze bardzo długa droga przede mną :D A co do niektórych wykładowców na AGH no to hmm... Niestety nieraz to strata czasu...

Dobrze, że napisałeś, ze niektórzy - pomimo, że mam doświadczenia takie, że programując dekady w C musiałem się uczyć na uczelni języka C od osoby która rozpoczynała naukę 2 lata przed zajęciami i niezbyt orientowała się w standardzie C99, a wykładowcy OpenGL utknęli w latach 90, to mimo takich przykładów jest cała masa osób, które są negatywem niechlubnych przypadków.