Skoti

No właśnie raytracing jest używany do ustalenia koloru obiektu (promień uderza w geometrię i dzięki obliczeniu kąta odbitego promienia i wektorowi od punktu uderzenia w kierunku światła są liczone shadery diffuse, specular) - rasteryzacja dziś pozostała jako alternatywa dla niektórych efektów - np. cienie mogą być rasteryzowane (dla samego buffor-z nie warto robić raytracingu) do shadowmap lub raytracowane.

Bzdura - BI jest raytracerem (kiedyś był rasteryzerem, ale to wieki temu, a teraz z rasteryzacji praktycznie nic nie zost), a jeśli materiałowi dodasz glossy to nawet śledzi ścieżki promieni (ilość sampli z ustawień materiału i głębokość z ustawień materiału) ;p - jest on backward raytracer (promienie są rzucane od oka/kamery do światła - inaczej niż w normalnym świecie), dzięki czemu jest znacznie wydajniejszy niż forward raytracer (jak Yafaray), który robi w drugą stronę od światła do kamery przez co potrzebuje nieporównywalnie więcej obliczeń i promieni, ale dając automatycznie efekty kaustyczne (w backward rzucasz wysokość obrazka * szerokość obrazka, a w forward nieograniczoną z góry liczbę promieni z każdego światła na scenie). Yafaray można przygotować do wydajniejszego działania zamieniając go w backward + photon mapping. Tylko po co indigo skoro nie masz do porównania bi-directional pathtracera (połączenie renderowania backward i forward) z samplowaniem MLT ;p. Co do samego renderingu w Blenderze to radiosity wywalono w 2.5x i będzie nowa metoda po mergu z render branch (coś jak w filmach Pixar/ILM oparte o chmury punktów i śledzenie promieni kolidujących z chmurami) - teraz jest tylko szybsza, ale gorsza wersja bez raytracingu o której n-pigeon wspomniał... za kilka miesięcy będzie też Cycles on tak jak Indigo jest bi-directional pahttracer z MLT.

Pewnie robiłeś w Cycles CPU vs CUDA - jeśli tak to dobre wyniki (bo AVX nie wykorzystuje na CPU), ale poczekaj na test OpenCL (ten sam kod, tylko że optymalizowany do jednostek wektorowych karty (CUDA) lub jednostek wektorowych procesora (AVX) przez sterowniki OpenCL od producentów sprzętu). Jak braknie Ci pamięci RAM na karcie to wydajność będzie równa zero, bo nic nie wyrenderujesz. Serie 500 i 400 to w praktyce jedna seria z procesorami FERMI. 550 jest bardzo wolną kartą - arch ma taki jak 460 (48 procków na SIMD - wyższe modele mają po 32 procki na SIMD), ale ma mniej jednostek GF550 ma 4, a 460 ma ich 7 (GF550 ma 192 procki podczas gdy GF460 ma ich 336), GF550 ma mniejszą szynę pamięci niż GF460 (192bit vs 256bit), i mimo że GF550 ma wyższe zegary to nie może konkurować w obliczeniach z GF460 - GF550 teoretycznie osiąga 691.2 GFLOPs (giga operacji zmiennoprzecinkowych na sekundę), a GF460 osiąga 907.2 GFLOPs (w praktyce tego nie osiągają, ale wydajność jest proporcjonalna ze względu na identyczną architekturę).

@kolaborant: wersja OpenCL dla Cycles dopiero powstaje - jak powstanie to na radku będziesz mógł liczyć (chociaż wydajność radków nie zachwyca w obliczeniach) - teraz tylko CPU lub CUDA (nvidia). Ja mam kręcony GF460 1gb i i5 2500k i i5 bardzo nie ustępuje GPU ze względu na charakter obliczeń i rozszerzenia AVX (4 rdzenie 3,3GHz * AVX (wektorowe obliczenia na 8 liczbach na raz)). Co do kart na których się opłaca liczyć to 460+ (jednak arch 465+ będzie w obliczeniach lepiej się sprawować), jednak trzeba pamiętać ze na gpu ogranicza cie ilosz pamieci, a zyskujesz wydajność w granicach 2x-10x w zależności od sceny.

- 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.

Jeśli chodzi o ścisłość to Radeony odpadają jeśli chodzi o tego typu obliczenia nawet w OpenCL i zamiast być konkurencją dla GPU nVidii są konkurencją dla CPU (na których OpenCL też działa). Nody też będziesz miał w Cycles (nawet o większych możliwościach niż w BI) i właśnie chodzi o to, żeby Cycles się ładnie integrował ze wszystkimi możliwościami blendera, czego nie da się zrobić w zewnętrznych rendererach (ponieważ one są dla wielu programów i siłą rzeczy wychodzi część wspólna wielu programów, a nie pełnia możliwości jednego programu).

1. Eksporter jest dla osób które kupią licencję. 2. Renderer nie korzysta z Ram, czy CPU, a tylko i wyłącznie z GPU firmy Nvidia (na AMD nie działa), dlatego dobrze jest mieć dobre GPU z dużą ilością pamięci na nim. 3. Działą szybko i dosyć sprawnie - ma pewne mankamenty okresu dziecięcego programu, ale za taką cenę nie jest źle. Ja nie jestem grafikiem, chociaż jak ostatnio robiłem wizualizację 1000m2 powierzchni to bardzo mi się przydał Octane ze względu na szybkie efekty. Jeśli masz kartę AMD (lub Nvidia, bo na nich też działa) lub chcesz mieć lepszą integrację z blenderem, lub chcesz mieć możliwość renderingu na CPU (np. gdy braknie ramu na GPU) to podobny renderer jest za darmo tworzony do blendera (Cycles), który pojawić się ma w blenderze 2.61 (gdzieś na gwiazdkę), a teraz możesz ściągnąć buildy testowe z wczesnych prac.

Potęgą 2 czy nawet kwadratem być nie musi - karty obsłużą takie tekstury w za pomocą specjalnych samplerów, ale można zapomnieć o powtarzaniu tekstur czy mipmapingu. Jeśli tekstura o prostokątnych rozmiarach czy rozmiarach nie będących potęgą 2 będzie podana do zwykłego samplera 2D to też będzie działać... tylko zostanie przeskalowana (mipmapy potrzebują kwadratów o rozmiarze potęgi 2 bo każdy kolejny poziom to kwadrat o rozmiarach 2 do potęgi (n-1)) przez sterowniki do rozmiarów kwadratu o boku potęgi 2 większej lub równej większemu rozmiarowi (czyli 100x600 to będzie 1024x1024, a 512x1024 będzie 1024x1024) - z tego powodu rozsądniej jest korzystać z kwadratowych tekstur o boku potęgi 2... tym bardziej z powodu tego, że coraz częściej tworzymy na mobilne karty w mobilnych konsolach, smartfonach czy tabletach (które wcale nie obsługują prostokątnych rozmiarów i rozmiarów innych niż potęga 2)

Jeśli nie chcą ujawniać pewnych sztuczek po stronie ekportera, czy sposobu pakowania danych dostarczanych (np. jeśli optymalizacja sceny i budowa struktur akceleracyjnych jest zrobiona po stronie plugina to nie chcą aby ten kod był łatwo dostępny dla konkurencji) do ich silnika to jest to kłopot (nie tak duży jak dla firm których produkcem końcowym jest plugin, ale firmy o zamkniętym charakterze nie lubą licencji która przymusza ich do dzielenia się kodem (a tym bardziej nie lubią płacić programistą za pracę nad kodem nad którym stracą kontrolę przez licencję)). Dlatego do czasu wykombinowania sposobu pisania zamkniętych pluginów blender w ekosystemie komercyjnych aplikacji nie istnieje i musi liczyć na siebie.

Cyclesem zajmuje się tylko jedna osoba odpowiedzialna od dawna za renderer i materiały - i to z tego co się orientuję w wolnym czasie (poza przerwie w pracy dla BF kiedy był w ekipie Octane - wtedy powstawał Cycles). Reszta BF pracuje nad zupełnie innymi rzeczami, a osoba robiąca Cycles gdyby tego nie robiła siedziałaby nad Internalem, a nie nad tym co chcesz. Octane jest ok to statycznych wizek bez wykorzystania tego co jest najfajniejsze w Internalu - nodów, a Cycles połączy rendering statyków, animacji, kompozycji, współpracując idealnie z animacjami, voxelami, fluidami, dymami, nodami materiałów, cząsteczek itp. Co z tego, że kupisz Octane jak wykorzystasz go tylko do nieskomplikowanych statycznych scen, bez możliwości wykorzystania wielu rzeczy z blendera? Jest wiele projektów około-blenderowych podobnych do Cycles które w przeciwieństwie do niego nie mają żadnego sensu (jak lokalizacja interface czy poprawki do game engine), ale Cycles, Nody w OpenCL i tego typu projekty to są bardzo ważne (tym bardziej, że nie wpływają na rozwój reszty blendera w znacznym stopniu (Cycles tworzy jeden programista, zupełnie obok innych obowiązków w BF, a nody liczone na GPU powstają zupełnie niezależnie i dopiero od niedawna są dotowane z nowego programu http://code.blender.org/index.php/2011/08/blender-development-fund-fund-raisers/)). Problem polega na licencji Blendera - nie będzie pluginów integrujących programy od firm zewnętrznych, dopóki jest tylko możliwość pisania skryptów (kod eksportera dostępny dla wszystkich) - nie będzie możliwości pisania pluginów, bo licencja i tak nakazuje opublikowanie ich kodu (na licencji GPL przez co nikt nie jest zainteresowany pisaniem pluginów). Blender Fund zdaje sobie z tego sprawę i wiedzą też że nie mogą zmienić licencji (nie jest to wykonalne, żeby każdy kto napisał chociażby linijkę się na zmianę licencji zgodził), ale myślą cały czas jak obejść licencję, aby zamknięte pluginy mogły być robione do blendera i sprzedawane (pisali o tym jako o wyzwaniu na siggraph2011).

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ć). GLUT to złoo ;p. Polecałbym raczej SDL czy GLFW. 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). 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).

@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).

Załamani to mogą być gracze - tesselację na Macach zobaczą najwcześniej za kilka lat... i to jak powieją dobre wiatry, bo Apple nie zrobiło aktualizacji do 3.x z dobrego serca, a dlatego, że 3.x dużo lepiej komunikuje się z OpenCL, a na tym im zależy.

Na MacOS sterowniki robi Apple, a nie producent sprzętu, dlatego masz kilka nowych rozszerzeń OpenGL od Apple, ale na kartach zgodnych z OpenGL 4.2 masz obsługę 3.2 w najnowszej wersji MacOS X Lion, a we wcześniejszych masz obsługę 2.1. Podobnie sprawa się ma z OpenCL gdzie Apple ma własną implementację - pamiętam, że z Nvidią były zgrzyty z CUDA, bo Apple nie chciała zeby były na MacOS... w końcu Apple jest twórcą OpenCL, a nVidia to konkurencja. Co do jakości sterowników to Apple robi powolne sterowniki dla Amd i jeszcze wolniejsze dla Nvidii i ogólnie jest strasznie z wydajnością - jedynie ich sterowniki ratuje to, że w przeciwieństwie do sterowników Amd są zgodne ze standardami jak OpenGL, dlatego żaden programista narzekać nie chce, bo mają dość sterów OpenGL od AMD czy Intela na innych systemach.

@adek: osławionej? Ja raczej nie zauważyłem, żeby tak źle ludzie ją postrzegali.

Taa nie znam się na Mac (używam ich systemu i laptopów jeszcze długo przed przejściem ich na intela - aktualnie też mam maca na intelu, ale głównie tam siedzi linux), a linuksa używam od 1999 (jest to moja główna platforma i pod którą programuję aplikację wieloplatformowe). Można powiedzieć całkiem spokojnie, że nie znam Windowsa, bo ostatnie większe z nim spotkania (więcej niż odpalić swój kod i sprawdzić jak działa pod tym OS) miałem w 2002 r., ale Linuksa czy MacOS akurat znam bardzo dobrze. Linux nie powstało na Unix (ogólnie nie ma jednego Uniksa, a jest wiele systemów które są Unixami - główne dwa nurty to System V i BSD), a powstało jako system podobny do jednego z uniksów (Minix - Linus poznał go na uczelni i postanowił zrobić podobny darmowy), ale nie jest z nimi zgodny - jest tylko podobny dlatego Linux nie jest zaliczany do Uniksów, a do systemów Unix-like. MacOS (jądro Darwin) to zupełnie inna bajka, bo to Unix powstały ze sklejenia kilku innych Uniksowych jąder jak Mach czy BSD, zachowując zgodność z Unixem - tylko w jedną stronę czyli jeśli program jest pisany z API Unixowym to zadziała i na MacOS, jak jest pisany pod MacOS to już na Uniksach nie zadziała. Twój kolega pewnie przeczytał, że FreeBSD może odpalić programy z Linuksa (FreeBSD ma specjalnie zmodyfikowane jądro, ze specjalnie napisaną obsługą plików ELF, oraz z implementacją LinuxApi (w jądrze FreeBSD nazwali to emulacją Linuxa, chociaż to błędna nazwa bo to coś w stylu Wine (i tak jak wine nie jest emulatorem tylko implementacją API, formatu plików wykonywalnych, oraz translacja wywołań do jądra linuksowego na jądro BSD))) i połączył fakt, że Darwin w MacOS bierze wiele z FreeBSD (akurat "emulacji" Linuksa nie brali) i puścił wodzę fantazji, że w drugą stronę też zadziała ;p. PS. Jeśli sam odpaliłeś program w wersji dla MacOS na Linuksie to podaj namiary na dilera... też chce taki towar

To ciekawe... Linuks nie jest kompatybilny z Unix (chodzi o samo api, bo już o kompatybilności programów nie ma co marzyć), MacOS (jąrdo Darwin) jest kompatybilny z Unix (nie binarnie, a api i jak masz kod źródłowy programu z Unix to skompilujesz go na MacOS - bez rekompilacji (napisania w jądrze systemu obsługi nowego formatu) nie odpalisz (tym bardziej że unixów jest setki, a każdy ma swoje formaty plików wykonywalnych i np. HP UX nie odpali programu z FreeBSD)), ale Uniksy nie są kompatybilne z softem dla MacOS (poza warstwą kompatybilności z unix, ma własne API i programy dla Maca używają go). Ogólnie aby w linuksie była obsługa MacOS trzeba zrobić to samo co w wypadku Windowsa czyli zrobić obsługę plików wykonywalnych - linux obsługuje tylko ELF, windows tylko PE32, mac tylko swój format (najdziwniejszy bo to kontener obsługujący wiele architektur w jednym pliku - coś jak FatELF) i dodatkowo napisać obsługę Api Apple, czyli m.in. Cocoa (czyli coś w stylu Wine, tylko Wine to implementacja Windowsowego Api). Jeśli ten spec mówi, że potrafi uruchomić program z MacOS na Linuksie to albo robi sobie z Ciebie jaja, albo sam nie wie co mówi (chyba że chodzi o wirtualną maszynę i instalacji MacOS w wirtualnej maszynie której hostem jest linux).

Nie wiem czym jesteście tak zszokowani - skanery 3d są od dawna, 3d można generować nawet z fotek obiektu, a kamerki internetowe wiele razy służyły do skanowania 3d - tylko tu potrzeba ruchu, a że Kinekt ma kamerę rgb i kamerę głębokości (depth cam) to jest znacznie łatwiej, bo odległości nie trzeba ustalać na podstawie ruchu, a jest już gotowa displace mapa z kamery głębokości, co tylko ułatwia sprawę. W niedawno utworzonej grupie Khronos StreamInput (http://www.max3d.pl/news.php?id=1931) ma być stworzone wszechstronne api dla urządzeń wejścia m.in. depth kamerek dzięki czemu takie skanerki za niedługo zobaczycie również w telefonach, tabletach czy komputerach.

Pewne kompetencje są potrzebne, ale nie jakieś wielkie - ofc poziom tego co uczą na studiach jest żenujący i mając wiadomości tylko ze studiów ciężko kogoś nazwać początkującym programistą (raczkującym to bardziej trafne określenie). Jednak nie wiem skąd to przekonanie, że student = poziom ze studiów... wielu studentów przewyższa wiedzą profesorów czy programistów w wielkich firmach (zdarza się też, że w wielkich firmach programiści są niekompetentni i początkujący to za dużo powiedziane).

Wiedzą jaką potrzeba mieć jest na tyle podstawowa, że każdy początkujący programista ją ma (a przynajmniej mieć powinien). Tu problemem nie jest wiedza, a logistyka czyli wymyślenie dobrego sposobu przechowywania danych, który da się aktualizować (o ile będzie on aktualizowany np. wywalając material, żebyś nie musiał przepisywać całego pliku 1GB reszty danych), żeby można było szybko wczytać (tu da się rozwiązać dobrze tylko pod już konkretny program i struktury - w wypadku kilku firm o upakowanie danych w sposób bezpośrednio pasujący do ich softu zapewne rozegrałaby się niejedna bitwa - jeśli dane są w pliku nie będą współpracować z istniejącym programem, to będzie on musiał ładować do pośredniej struktury, obrabiać i dopiero ładować do struktur programu), pozwalać na swobodny dostęp do danych (zeby w wypadku dużych plików nie trzeba było trzymać wszystkiego w pamięci, a szybko doczytywać)... tu wiedza ma mało do powiedzenia, a wkracza logistyka i inteligencja. Cpio z tego co pamiętam to archiwizer bez kompresji. Ten sposób trzymania danych ma wiele zalet - łatwy dostęp do danych i wiele rzeczy na pliku można zrobić szybciej - wadą jest to, że nie załatwisz ładowania wszystkiego za pomocą jednego memcpy, ale zalety i tak przesłaniają wady (bo nie ma idealnego rozwiązania - są tylko mniej beznadziejne ;p). Tak kompromis jest najlepszą rzeczą jaka mogła się Colladzie zdarzyć, ale przez ten kompromis, jest formatem końcowym znacznie gorszym niż taki stworzony przez nastolatka do jego zastosowań, dlatego jedyne miejsce dla niego to jako format pośredni. Akurat Cyclest ma dobre podstawy, żeby mieć te 100%. Teraz jest przepisywany z zasadniczego powodu - autor znał CUDA, przez chwilę pracował przy Octane i zrobił PoC i tak jak w wypadku profesjonalnych projektów PoC nie jest rozwijany i trafia do kosza (PoC z założenia olewa wiele problemów, wiele jest uproszczeń i dąży się do szybkiego efektu, żeby dowieść koncepcji - jeśli koncepcja jest słuszna to wywala się PoC (bo przeprojektowanie PoC to więcej pracy niż zrobić od nowa) i zaczyna się projektować od zera tym razem porządnie).

Nie wymaga wiedzy technicznej - programowanie tu ma praktycznie zerowe znaczenie. Potrzebna jest wiedza, teoretyczna na temat nie programowania, a projektowania wiedza jest potrzebna chociażby na temat jakie dane chcemy zapisać, jak coś zapisać i jaką strukturę utworzyć (mi się podoba np. potraktowanie przez blendera swoich danych jako plików i zapisywanie wszystkiego w skompresowanym wirtualnym systemie plików). Niestety, ale z dogadywania się wielu firm rzadko wychodzi coś ponadprzeciętnego - przykładem niech będzie Collada (bardzo lubię ten format i stosuje go jako format pośredni do mojego formatu), nad którą pracowały firmy zrzeszone w Khronos Group - fajny format, ale tak na prawdę nikomu i do niczego nie pasuje (normalne przy kompromisach pomiędzy firmami), bo jest uśrednieniem tego co każda z firm chciała. Zawsze tam gdzie firmy współpracują jest walka o to kto przepchnie więcej swojego i wychodzi to średnio - w wypadku jednej firmy lub jednej osoby idzie to znacznie sprawniej bo liczy się zdanie jednej osoby (tej która robi to sama, lub szefa grupy, który odpowiada za wykonanie i to co mówią podwładni to sugestie, z którymi jeśli się nie zgadza, to narzuca swoje zdanie). Dzięki temu mniejszy team z jasną hierarchią zrobi coś w kilka dni, a kooperacja firm, gdzie prawa są równe, będzie ustalać nawet proste szczegóły latami (żeby wybrać pomysł, jeden osoby, z X, lub uśrednić pomysły pojedynczych osób z kilku firm). Tylko to nie 10% roboty - przeważnie różnica wynosi raczej 90%. Przykładowy Cycles w tej chwili ma za sobą może 2% drogi, a zaraz wszystko będzie przepisane z Cuda do OpenCL, do 90% drogi to ma bardzo daleko (te prezentacje to były raczej Proof of Concept, a praca zasadnicza dopiero będzie ruszać, jednak akurat o ten projekt bym się nie bał bo robi go główny dev blendera i osoba, która nie porzuca rzeczy w połowie drogi). Co do innych projektów (chociaż nie wiem do końca co masz do smoke, poza tym, że mało kto je potrafi wykorzystać i poważnie się nimi bawił, w zadaniach produkcyjnych) to dobrym przykładem są fluidy - dla osoby będącej poza tematem zostały zrobione i nikt się nimi nie zajmuje... fajnie że są i w innych programach też podobnie zaczynały, ale to dopiero początek powinien być. Dla osoby która dokładniej obserwuje rozwój blendera, jest jasne, że dalej jest rozwijane i to równolegle w kilku kierunkach, a dodatkowo powstały projekty zupełnie inaczej podchodzące do fluidów i zamiast voxelowych obliczeń polegają na luźnych cząsteczkach nie zamkniętych w pudełku, i akceleratorowych za pomocą GPU (OpenCL), a i w silniku fizyki Bullet (którego autor jest autorem części kodu w blenderze) robi się teraz małą rewolucja z obliczeniami w OpenCL i symulacją m.in. fluidów, dlatego brak rozwoju w oficjalnej gałęzi blendera, który przeszedł remont kapitalny i nie było czasu się nad nowymi możliwościami rozwodzić, nie oznacza, że coś się w dalszym ciągu nie rozwija - niestety nie jest tak pięknie, żeby kilku programistów mogło rozwijać projekt złożony z setek mniejszych projektów tak szybko, żeby co 2 miesiące były aktualizacje wszystkiego i jeszcze dochodziły nowe rzeczy - projektu muszą odleżeć chwilę, aby dostały aktualizacje możliwości, przy dzisiejszych funduszach BF.

Blender często jest wykorzystywany w reklamach np: - 3 znane nam polskie reklamy: http://www.blendernation.com/2008/05/31/3-commercials-made-with-blender/ - rosyjskie napoje - Reklama Bridgestone http://www.blendernation.com/2009/05/07/3-new-bridgestone-commercials-by-promotion-studios/ To tylko kilka reklam, ale w reklamówkach blender dosyć często znajduje zastosowanie - w filmach rzadziej, bo nie ma camera tracingu (robi się i będzie wykorzystywany w kolejnym projekcie blendera), ani nie współpracowały z nim zewnętrzne programy, a dodatkowo wielkie studia mają już opracowany workflow, wyszkolonych pracowników itp... drogie byłoby przejście na blendera i szkolenie od nowa pracowników i rekonfiguracja całego workflow... w wypadku wielkich to przepisywanie całej masy pluginów i softów, bo modyfikacje firm często doprowadzają do tego, że maya jest nią tylko z nazwy, a faktycznie wykorzystują własne narzędzia (co nie przeszkadza pojawianiu się bajek robionych w blenderze jak "The Secret of Kells", który był nominowany do Oskara, czy nawet w filmach, ale przed całym workflow jak w Spiderman 2 do prac przedprodukcyjnych - później był już zwykły ich workflow) Ta płatna wersja w przeciągu dnia stałaby się wersją legalną darmową dla wszystkich - licencja blendera chroni (przed np. Autodesk), ale też ogranicza - bez zgody wszystkich którzy napisali chociaż literę w kodzie blendera, nie można zmienić jego licencji, a ta nakazuje blenderowi być na licencji GPL (więc nawet płatnie, jak ktoś kupi, dostaje kod i ma prawo udostępnić wszystkim za darmo). GPL też jest ograniczeniem dla rozwoju blendera w znacznie większym stopniu - licencja nie pozwala robić do blendera zamkniętych pluginów - wszystko musi być na licencji GPL, przez co o komercyjnych pluginach nie ma co marzyć (licencja GPL nakazuje również pluginom do programu mieć licencje GPL). Problem tu nie leży w problemach technicznych, ani wymagania wybitnej wiedzy - tu jest problem z dogadaniem się co się chce mieć w formacie i jak zapisane im więcej firm współpracuje tym dłużej będzie to trwać (jedna firma chce to zapisać w taki, a taki sposób, bo tak zapisują dane w ich programach, a inni inaczej...) - podobnie jak trwa wojna o HTML5... każda firma promuje coś innego, i mimo, że każda z firm zaimplementowała swoje propozycję w mgnieniu oka, to nie ma szans na dogadanie się szybko ;p... w takich sytuacjach jeden zdolny programista z wiedzą zrobi to szybciej i często lepiej. Projekty które jak mówisz są zrobione w 90% są przeważnie zrobione w 10%, a pozostało 90% - problem w tym, że wiele osób piszących takie rzeczy to młode osoby ze słomianym zapałem - jak już coś działa to już brakuje motywacji na mozolną optymalizacje, debuggowanie i dopieszczanie. Jednak nie jest problemem to, że czymś zajmuje się jeden programista - jeśli ma wiedzę, umiejętności i potrafi dokończyć to co zacznie to rozpoczął to lepiej jedna osoba taka (jeden dobry programista zrobi szybciej i lepiej niż setka przeciętniaków).

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). 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ę. 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. 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. 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. 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ą. Możesz rozwinąć tę myśl? Już pomijam fakt, że najnowsza wersja OpenGL ma niecałe 4 dni ;p. //EDIT: 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

@makak_: Większość z tych ma polskie znaki (wiele z nich znajduje się na do użycia w Web bezpośrednio, na stronie google) http://www.smashingmagazine.com/2007/11/08/40-excellent-freefonts-for-professional-design/

Tak już ma - po prostu przed renderem kliknij "L" i daj "All" to staną się lokalne (po renderingu nie zapisuj tylko ctrl + z), a jak Cię denerwuje to wrzuć na buglistę (o ile tam już tego nie ma).