Proste a blender nie działa dobrze?

[człowiek]

Witam wszystkich. Na początek powiem, że bardzo bardzo liczę na waszą pomoc, bo to co mi tym razem nie działa sprawia mi ogromne problemy.

 

W załączniku jest plik blendera z prymitywną, testową animacją. Jej błędne wyniki widoczne są na rysunkach.

 

Wspomnę tylko o warunkach.

Duże wartości pozycji i rozmiarów obiektów to wynik zastosowania skali wg. której 1 to 1mm, gdyż to dotyczy małych detali, których rozmiar nie przekracza w moich animacjach 50cm. Stąd przelicznik 1 to 1mm.

 

Zauważyłem, że problem znika w momencie, kiedy oba obiekty są rozsunięte więcej niż 1 a jak jest mniej to niestety nie działa :(. Rozwiązaniem jest zoffs, ale to mi się kompletnie nie sprawdza we wszystkich przypadkach a jest jedynie rozwiązaniem dla wybranych klatek (chyba że nie wiem jak poustawiać poprawnie wartości).

 

To zaczęło sprawiać mi duże kłopoty gdyż z tak prostymi animacjami nawet karta graficzna się nie myli. Pomóżcie rozwiązać problem.

[dac77]

A opis problemu?

[człowiek]

A opis problemu?

Hehe :) No jest. Dokładnie po renderingu widać o co chodzi, a opisać to nie tak łatwo słownie, ale skoro... Po renderingu animacji uzyskuje się klatki prawidłowe i takie, w których obiekt, który powinien być widoczny z przodu, jest widoczny tylko częściowo, choć wzajemne położenie obu obiektów jest niezmienne podczas całej animacji, zmienia się tylko położenie kamery i to jeszcze w dosyć niewielkim zakresie. Pomimo tych niewielkich zmian pojawiają się "prześwity" części elementu, który nie powinien być widoczny, bo jest z tyłu w danym miejscu. Zgoniłbym na to, że obiekty są po prostu nieprawidłowe, ale w tym przypadku jest to nie możliwe, ponieważ oba są zwykłymi mesh'ami.

[dac77]

Blender działa dobrze. Po prostu obiekty są zbyt blisko siebie, a ponieważ komputery są cyfrowe a nie analogowe więc jak się zaokrągli to czasami są w tej samej odległości od kamery w buforze Z więc czasami renderowany jest nie ten trójkąt co trzeba. Odsunąć trochę.

[rayGun]

wejdź do ustawień kamery i zwiększ Clipping Start do 0.20, albo więcej.

To załatwi problem. To jest ustawienie zakresu widzialności kamery, czyli jeśli zblizysz kamerę na odległość mniejsza niż Clipping Start, to obserwowany obiekt przestanie być widoczny. Jeśli ta wartość jest bardzo mała to, w takim przypadku jak Twój, dzieją się dziwne rzeczy. To samo jest w przypadku ustawień widoku 3D View.

Zresztą w maxie też jest taki problem :)

[człowiek]

Blender działa dobrze. Po prostu obiekty są zbyt blisko siebie, a ponieważ komputery są cyfrowe a nie analogowe więc jak się zaokrągli to czasami są w tej samej odległości od kamery w buforze Z więc czasami renderowany jest nie ten trójkąt co trzeba. Odsunąć trochę.

dac77 ja wiem jaka jest precyzja liczb typu float i double w programowaniu stąd takie usprawiedliwienie blendera jest lekko niezrozumiałe :), gdyż z tego co widziałem blender jest ograniczony do zaledwie 3 miejsca po przecinku przy podawaniu pozycji, ograniczony jest także plan, więc nawet dla floatów powinien być pikuś. Ale zakładając znacznie gorsze warunki to i tak pewnie programiści operowali na double, co jeszcze zwiększa precyzję. Ale mniejsza o szczegóły techniczne.

 

rayGun faktycznie to rozwiązuje problem. Dzięki.

[dac77]

Co innego jest precyzja geometrii a co innego precyzja Zbuffera. Możesz sobie zapisać Zbuffer i obejrzeć go w kompozytorze. Każdy program działa w tej kwestii tak samo, więc tytuł jest bez sensu.

[człowiek]

Co innego jest precyzja geometrii a co innego precyzja Zbuffera. Możesz sobie zapisać Zbuffer i obejrzeć go w kompozytorze. Każdy program działa w tej kwestii tak samo, więc tytuł jest bez sensu.

 

Ale popatrz. ZBuffer to nic innego jak tablica całego obrazu, wszystkich pikseli, gdzie sprawdza się czy dany nowy piksel jest bardziej z przodu i ma być nadpisany czy też nie. Jeśli ta tablica jest typu float to nie ma to również i nie powinno to mieć kompletnie żadnego znaczenia i pewnie dlatego jak się zmieni to co zasugerowano wyżej to przestaje mieć znaczenie, choć wydawałoby się, że akurat te parametry nie powinny mieć na to wpływu a przynajmniej nie tak niewielkie różnice. Popraw mnie, jeśli gdzieś się mylę, albo napisz mi jaki wpływ na rozwiązanie tego problemu ma akurat zmiana wartości start na co najmniej 0.2? No chyba, że ZB działa inaczej. Ale w takim przypadku tego nie rozumiem, dlaczego ma działać inaczej skoro to jest wykonywane przez procesor główny a nie procesor karty graficznej gdzie optymalizacja jest konieczna do granic, bo bez niej nie da się wyciągnąć tych co najmniej 25fps.

Edytowane 20 Marzec 2010 przez człowiek

[dac77]

Prosta matematyka. Jeżeli masz scenę o pewnych wymiarach i wartości ZBuffer zaczniesz przypisywać bardzo blisko od kamery to po prostu bardzo dużo możliwych wartości zmarnujesz na te rzeczy blisko kamery. Float oznacza że wartości mogą mieć bardzo duży zasięg ale postęp i tak jest ograniczony ilością bitów. W kartach graficznych zwykle clipping jest bardzo ograniczony. Po prostu zapisując Zbuffer można mieć tylko pewną określoną liczbę możliwych wartości. Można to sobie wyobrazić jak szereg wielu milionów płaszczyzn rozpoczynających się na clip start a kończących na klip end. Czasami dwa trójkąty są tak blisko siebie że po prostu ciężko nawet przy ograniczeniu clippingu zmieścić je na dwóch różnych wartościach Z. Wówczas to który jest widoczny zależy od kolejności przetwarzania. Najlepiej po prostu nie dawać geometrii jeśli jest ona niepotrzebna. Przy tak bliskich od siebie obiektach lepiej stosować oddzielnie materiały na jednym obiekcie, no chyba że to animacja. Jest jeszcze inna technika lokalnego dodawania 'rozdzielczości Zbuffora' ale to wymaga renderowania w pasach i składania w kompozycji.

[człowiek]

No tak, ja rozumiem pewną ograniczoną liczbę wartości w ZB. Tak było w kartach graf. gdzie ze względu na optymalizację ograniczano liczbę np. do 16 bitów (65536 możliwych głębi). Ale skąd ten problem w przypadku pracy zwykłego procesora. Przecież to już nie jest to samo. Nie ma problemu takiej optymalizacji i każdy piksel mógłby być po prostu zwyczajnie opisany wartością z zakresu float, który daje wystarczającą precyzję, że już nie wspomnę o double, z którym tym bardziej nie ma problemu.

[dac77]

ZBuffer jest 32 bitowy. To po prostu wartość. Nie może przyjąć dowolnej wartości gdyż na komputerze nic nie może takiej wartości przyjąć. Zawsze jest jakieś ograniczenie precyzji. Po prostu liczba możliwych kombinacji to 2 do 32 więc jednak nie wszystko da się zapisać. Karta graficzna trochę inaczej rasteryzuje ale zasady są te same.

[człowiek]

ZBuffer jest 32 bitowy. To po prostu wartość. Nie może przyjąć dowolnej wartości gdyż na komputerze nic nie może takiej wartości przyjąć. Zawsze jest jakieś ograniczenie precyzji. Po prostu liczba możliwych kombinacji to 2 do 32 więc jednak nie wszystko da się zapisać. Karta graficzna trochę inaczej rasteryzuje ale zasady są te same.

 

dac77 może być jeszcze 64 bitowy, lub nawet (jeśli dobrze pamiętam) 80 bitowy, bo i takimi liczbami można posługiwać się w przypadku programowania w c++ (pewnie w C też jest). Dlatego dowolność w tym przypadku jest jednak możliwa. Natomiast jeśli nie wprowadzi się kwantyzacji poziomów głębi i nie podzieli jej na "odcinki" o z góry ustalonej wielkości, tylko po prostu będzie ograniczenie do iluś tam kombinacji, z których każda może być inna, mogą być blisko siebie, ale najważniejsze żeby się nie powtarzały, to w 32 bitach można zapisać ich tyle, że obecnie żadna stacjonarka nie byłaby w stanie ich przetworzyć w krótkim czasie. Ja tylko koledze zwrócę uwagę, że pętla, która wykonałaby się 2^32 razy, robiłaby to bardzo długo na przeciętnym domowym komputerze. Nie to, żeby się nie dało, ale jednak robi się to dość długo. Stąd zakładanie, że w obrazie powstałoby aż 2^32 różnych głębi ostrości jest błędne. Z tego wynikałoby, że musi być wprowadzona stała wartość i bufor jest skwantowany.

Do czego zmierzam.

Zmierzam do tego, że nawet na floatach 32 bitowych można zapisać tak wiele różnych kombinacji z taką dużą precyzją, że nie sposób się nie zmieścić. Problem może być jedynie w precyzji obliczeń, ale to w zadanym przykładzie najwyraźniej nie ma nic do rzeczy, zwłaszcza, że można to zrobić na double.

Po prostu w przyp. kart graficznych to miało logiczne uzasadnienie takie ograniczenie, natomiast tutaj jest to chyba wynik nieprawidłowego podejścia do tematu ZB. Z tego co czytałem dawno dawno temu to ZB. jest tablicą gdzie ustala się czy piksel jest bardziej z przodu czy bardziej z tyłu. A to oznacza, że operując na liczbach całkowitych lub na liczbach zmiennoprzecinkowych dokładność jest ogromna. Przykład. Kamera widzi do 5000 w przód i od 0.1 w standardzie. Z tego jeśli założymy, że dokładność ZB. wynosiłaby setną część przedniej wartości, to wychodzi, że na każde 0.1 odległości przypadałoby 100 wartości ZB. No to podzielmy wszystko:

5000/0.1 * 100 = 50000*100 = 5000000 = ~2^22. Zostaje jeszcze w takim przypadku co najmniej 9 bitów (+ 1 bit na znak, jeśli przyjmiemy liczby ujemne). Rozdzielczość ta jest ogromna, delikatnie rzecz ujmując. Wydaje mi się w takim przypadku, że ktoś źle przyjął założenia w obliczeniach lub gdzieś brakuje precyzji.

 

Może to się wszystko bierze z tego samego głupiego pomysłu ograniczenia nazw dla obiektów do zaledwie ~30 znaków, choć tylko bój jeden raczy wiedzieć komu i czemu to ograniczenie miało służyć.

Edytowane 20 Marzec 2010 przez człowiek

[Skoti]

ZBuffer jest 32 bitowy. To po prostu wartość. Nie może przyjąć dowolnej wartości gdyż na komputerze nic nie może takiej wartości przyjąć. Zawsze jest jakieś ograniczenie precyzji. Po prostu liczba możliwych kombinacji to 2 do 32 więc jednak nie wszystko da się zapisać. Karta graficzna trochę inaczej rasteryzuje ale zasady są te same.

 

ZBuffer jest 32 bit, ale 32bit int (1 bit na znak i 31 na liczbę) nie równa się 32bit float (1 bit na znak, 8 bitów na wykładnik (liczba całkowita) i 23 bity na liczbę całkowitą) - we float masz dużo więcej możliwych kombinacji (dlatego np. od kiedy karty graficzne obsługują tekstury zmiennoprzecinkowe, problemy z precyzją zmalały prawie do zera). Jak zapiszesz Zbuffor w blenderze (np. do png (zapisujesz liczby całkowite), albo po prostu oglądasz w okienku to nie dziwne, że widzisz problem, bo blender zapisuje/wyświetla renderery w liczbach całkowitych (1 int to 1 piksel (po 8 bitów na każdy kanał)), i tracisz wtedy precyzję - w wypadku zbuffora (szara mapa czyli każdy kanał ma takie same wartości masz tylko 256 stanów (co strasznie wygląda i sugeruje na małą precyzję) - ale to co widzisz, nie musi być tym co jest wykorzystywane (czy jest nie wiem bo nie zagłębiałem się w źródła, ale raczej tak sądząc po braku większych problemów z bufforowanymi cieniami (które właśnie opierają się na renderingu ze światła w kierunku padania z przycięciem far przy końcu Dist - jeśli byłoby to na liczbach całkowitych więcej byłoby artefaktów niż cieni ;p))).

 

Tylko co precyzja buffora głębokości ma wspólnego z problemem nie mam pojęcia (tym bardziej, że zbuffor jest w blenderze tworzony jako "efekt uboczny" do wykorzystania w composite nodes (po prostu jak primary ray uderza w najbliższy obiekt, zapisuje nie tylko kolor, ale i odległość (interpolowaną liniowo pomiędzy bliską (0) i daleką (1) płaszczyzną przycięcia kamery))) - nie służy do samego tworzenia sceny.

 

dac77 może być jeszcze 64 bitowy, lub nawet (jeśli dobrze pamiętam) 80 bitowy, bo i takimi liczbami można posługiwać się w przypadku programowania w c++ (pewnie w C też jest).

Tak takie liczby w C/C++ to double (64bit) i long double (80bit) - a nawet na wielu GPU (większość dosyć nowych) takie liczby są możliwe (wydany nie darmo nowy OpenGL wymusza wręcz 64bitowe zmienne (AMD chce emulować takie liczby, na kartach, które nie mają odpowiednich jednostek - budżetowych kartach)). Jednak zupełnie nie o to tu chodzi i nie ma to nic wspólnego zbufforem (ani brakiem precyzji w 32bit zmiennoprzecinkowych) - po prostu dac zna jedynie liczby całkowite.

 

Może to się wszystko bierze z tego samego głupiego pomysłu ograniczenia nazw dla obiektów do zaledwie ~30 znaków, choć tylko bój jeden raczy wiedzieć komu i czemu to ograniczenie miało służyć.

Blender w większości jest pisany w C, a tam nie ma "samo rosnących" stringów (po zmianie alokuje nowe miejsce w pamięci, kopiuje, i usuwa stare) tylko tablice znaków wcześniej alokowane (ofc da się to samo uzyskać za pomocą realloc, ale nie widzę sensu) - po prostu ustalili, że n znaków będzie wystarczające i nazwa w obiekcie (strukturze) to char name[30]; na sztywno (bardzo często stosowane rozwiązanie) - pewnie nie jest też na sztywno w pisane 30 tylko ustalona stała i wystarczy zmienić jej wartość, żeby można było więcej - ja w bazie danych też nie daję więcej na nazwę niż 30 znaków ;p.

Edytowane 20 Marzec 2010 przez Skoti

[człowiek]

Dokładnie z tymi nazwami to wiem. Tylko po prostu sens takiego rozwiązania jest co najmniej śmieszny, bo nawet gdyby to było 1000 znaków (śmieszne i przesadzone w drugą stronę) to razem ze wszystkimi materiałami, wszystkimi obiektami i wszystkimi możliwymi możliwościami (:P) to wyszłoby może z maksymalnie 2MB, czyli 2000 różnych nazw. Trochę tego by było. Ale już 100 znaków spokojnie starczy.

 

Co do ZB. to właśnie przewidywałem int32_t lub uint32_t. Jednak nie bardzo rozumiem czemu ma to służyć i dlaczego nie tablica float lub double. Mogę się jedynie domyślać, że chodzi o specyficzny rodzaj optymalizacji, choć jest to mocno naciągane.

 

Zdaje sobie również sprawę z tego, że ZB. nie jest jakoś tak super ważnym elementem, stąd można sobie pozwolić na to by nie był on jakimś "standardem" i nie musiałby wówczas być intem. Dowodem takiego rozumowania dla mnie są karty graficzne gdzie właśnie podejście do ZB. zmieniało się na przestrzeni lat. Jednocześnie nawet najbardziej złożoną kombinację floatów można przedstawić jako znormalizowane wartości z przedziału 0-1, z czym można się spotkać właśnie na kartach graficznych, gdzie zarówno pozycje jak i kolory mogą być z tylko z tego zakresu.

 

W ogóle właśnie ten problem uważam za dość dziwny w takim przypadku, bo rozumiałbym gdyby rendering był z wykorzystaniem GPU, to jasna sprawa, że mogłyby się dziać cuda. Jednak tutaj robi to wolno i spokojnie procesor główny.

 

PS. w bazie danych zależy czego i zależy ile. Gdyby było realne maksimum w postaci 10000 wierszy z taką nazwą, to można ograniczenie do 30 nazwać nadgorliwym :P.

[dac77]

@Skoti. Z tego co się orientuję to jesteś programistą więc nie będę się wykłucał. Ja już bardzo dawno żadnego kodu nie widziałem, ale ciężko mi zmienić swoje przekonania. Zbuffer można przecież zapisać do .exr i spokojnie obejrzeć po programem graficznym. Ale w jaki sposób float może mieć większą liczbę kombinacji? Liczba kombinacji jest taka sama tylko zasięg jest większy, czyli duża precyzja przy niskich wartościach i mniejsza przy dużych. W końcu float też się zapisuje 1 i 0 więc nie może być więcej kombinacji niż 2 do 32, oczywiście w 32 bit float bo często stosuje się większe.

O ile wiem to Blender stosuje scanline dla przyśpieszenia renderingu. A scanline przecież wykorzystuje tablicę głębi pikseli i tablicę przynależności do geometrii. Czyli jak jest ewaluowane czy dany trójkąt w danym miejscu jest widoczny to po prostu wartość Z dla tej próbki jest porównywana do wartości Z w tablicy i jeżeli jest mniejsza to jest nadpisywane w tablicy głębokości i w drugiej tablicy jest kodowany numer tego trójkąta. Tak w każdym razie kiedyś czytałem w książkach ale nazwy pewnie są nie takie bo to były książki po Angielsku.

[człowiek]

Dac77 precyzji większej nie ma, ale jednocześnie znikają ograniczenia poprzez dopasowywanie się do sytuacji. W przypadku liczb całkowitych i stałoprzecinkowych ograniczeniem jest kwant jakim nie mamy wyjścia i musimy się posługiwać. Liczby całkowite można w pewnych okolicznościach traktować jako liczby staloprzecinkowe. W takim przypadku np. 1.5 i wszystkie obliczenia do danej precyzji można traktować mnożąc każdą wartość przez 10, czyli zamiast 1.5 mamy 15. To pewnie wiesz. Ale ograniczeniem zawsze będzie stały kwant. W przypadku obliczeń na zmiennoprzecinkowych nie ma z góry ustalonego kwantu, więc precyzja jest zależna tylko i wyłącznie od długości liczby. W zmiennoprzecinkowych nie ma problemu z porównaniem wartości 0.0000001 z wartością 0.1 choć obie te wartości dzieli ogromna przestrzeń. Te zera z tego co pamiętam można jeszcze dalej rozwijać. W przypadku stałoprzecinkowej do porównania takich liczb trzeba już znacznej ilości bitów do ich odróżnienia. Ale to pewnie wiesz, jednak tylko dla przypomnienia. Po prostu zmiennoprzecinkowe inaczej traktują ułamki.

 

W tym jednak przypadku nie ma to i tak znaczenia, bo przy 32 bitach (31 bitach) ilość głębi jest ogromna. Jak dobrze policzyć, to jeśli górna granica wynosi 5000 jednostek, to przy 31 bitach kwantem jest wartość 0,0000023, czyli takie wartości mogą być odróżniane. Przemnóżmy to przez 1000 to i tak nadal dokładność jest ogromna.

 

PS. ja też co nieco wiem jest o programowaniu i to nie tylko na PC :).

[dac77]

To tylko znaczy że można zapisać bardzo duże i bardzo małe liczby z dużą precyzją. Ale zapomnijmy na chwilę o formacie liczby a spójrzmy na te 32 bity jak na informację. To znaczy że każdy piksel może mieć przypisany kod 0-1 w 32 bitach i tych możliwych kodów jest 4 294 967 296. A więc jednak istnieje ograniczenie w przeniesieniu informacji. I w tym tkwi problem. W pamięci komputera jest informacja o geometrii która niesie ze sobą bardzo dużo informacji, ale po przetworzeniu te informacje niekoniecznie mieszczą się w tych 32 bitach i powstają nieścisłości/błędy/artefakty. To samo występuje w buforowanych cieniach. Trzeba stosować przesunięcie gdyż czasami cień wystaje z geometrii go generującej. Dokładnie ta sama sytuacja, tyle że cienie jest stosunkowo łatwo ograniczyć dla zwiększenia precyzji.

[człowiek]

Tak, dac77, właśnie tego nie potrafię pojąć, skąd problemy, skoro operacje w obliczeniach nie są wykonywane na int'ach na 100%, bo byłoby to raczej spowolnieniem niż przyspieszeniem procesu. Są wykonywane co najmniej na float'ach a być może na double. Z tego jednak wynika, że precyzja samych obliczeń jest dużo większa niż gdyby to samo obliczać na liczbach stałoprzecinkowych lub intach. Pozostaje więc zadać sobie pytanie, czym różni się pozycja piksela policzona dla danego układu z parametrem start dla kamery równym 0.1 od tego samego układu z parametrem start dla kamery równym 1. Fizycznie rzecz biorąc ostateczna pozycja i wszystkie transformacje dadzą ten sam wynik. Zakładając ograniczenie w precyzji do 0.002 czyli 1000 razy mniejsza precyzja od tej, którą policzyłem, to i tak nie tłumaczy dlaczego obiekty rozsunięte o 0.2 w jednym przypadku będą prawidłowe (dla start 1) a w drugim nie. Po prostu zanim napisałem post długo siedziałem i kombinowałem co z tym zrobić. Brałem pod uwagę ZB. i sporo naszukałem się gdzie można dokonać jakiejś zmiany w dokładności. W pewnym momencie problem mnie przerósł i napisałem na forum. Zdziwiło mnie rozwiązanie, które ma się nijak do obliczeń ZB. bo nie ma wpływu realnego na precyzję, jeśli rzeczywista precyzja jest blisko 500 razy większa niż kwant w blenderze (kwant ten wynosi jeśli się nie mylę 0.001 zaś jak wcześniej przytaczałem precyzja dla kamery jest o 500 razy lepsza wg logiki).

[Skoti]

@Skoti. Z tego co się orientuję to jesteś programistą więc nie będę się wykłucał. Ja już bardzo dawno żadnego kodu nie widziałem, ale ciężko mi zmienić swoje przekonania. Zbuffer można przecież zapisać do .exr i spokojnie obejrzeć po programem graficznym.

Blender zapisując do exr zapisuje to co pokazuje (dlatego mimo że zapiszesz obrazek do exr masz małą precyzję i będziesz widział kłopoty z utraconą precyzją (32bit float zbuffora -> 8bit na kolor int -> 32bit na kolor w exr).

 

Ale w jaki sposób float może mieć większą liczbę kombinacji? Liczba kombinacji jest taka sama tylko zasięg jest większy, czyli duża precyzja przy niskich wartościach i mniejsza przy dużych. W końcu float też się zapisuje 1 i 0 więc nie może być więcej kombinacji niż 2 do 32, oczywiście w 32 bit float bo często stosuje się większe.

Faktycznie źle się wyraziłem - pozwala na większą liczbę kombinacji w danym przedziale liczb co wpływa bardzo korzystnie na zapis obrazu (dużo większa precyzja w liczbach bliskich 1, a mała w bardzo dużych liczbach (int ma stałą odległość pomiędzy kolorami)).

 

O ile wiem to Blender stosuje scanline dla przyśpieszenia renderingu. A scanline przecież wykorzystuje tablicę głębi pikseli i tablicę przynależności do geometrii. Czyli jak jest ewaluowane czy dany trójkąt w danym miejscu jest widoczny to po prostu wartość Z dla tej próbki jest porównywana do wartości Z w tablicy i jeżeli jest mniejsza to jest nadpisywane w tablicy głębokości i w drugiej tablicy jest kodowany numer tego trójkąta. Tak w każdym razie kiedyś czytałem w książkach ale nazwy pewnie są nie takie bo to były książki po Angielsku.

Nie wykorzystuje scanline, a do przyspieszenia renderingu i sprawdzania w co najprawdopodobniej uderzy promień używa drzew - wcześniej ósemkowego (octree), a w 2.5 dostał jeszcze kilka odmian BVH (dzięki czemu przyspieszył)

 

Dokładnie z tymi nazwami to wiem. Tylko po prostu sens takiego rozwiązania jest co najmniej śmieszny, bo nawet gdyby to było 1000 znaków (śmieszne i przesadzone w drugą stronę) to razem ze wszystkimi materiałami, wszystkimi obiektami i wszystkimi możliwymi możliwościami (:P) to wyszłoby może z maksymalnie 2MB, czyli 2000 różnych nazw. Trochę tego by było. Ale już 100 znaków spokojnie starczy.

Wiesz nazwy obiektów, siatek, kości, materiałów, tekstur, grup wierzchołków, grup materiałów, cząsteczek, włosów, pomnóż to przez ilość wszystkiego na scenie i może to trochę zajmować - każda jedna rzecz to dodatkowe 70bajtów (ofc każdy obiekt może mieć wiele innych, każdy materiał może mieć wiele tekstur...) - da się to przeżyć, ale da się też przeżyć 30 znaków na nazwę.

Edytowane 21 Marzec 2010 przez Skoti

[dac77]

Dzięki Skoti za wyjaśnienie. Generalnie się zgadzam. Tylko jeżeli wyłączę raytracing to czy wtedy nie używa scanline? I co z tym problemem będącym w temacie? Rozumiem że mimo wszystko winna jest ta precyzja zapisu. Podobne problemy zauważyłem też w innych programach 3D więc to nie jest niedoskonałość Blendera.

[Skoti]

Dzięki Skoti za wyjaśnienie. Generalnie się zgadzam. Tylko jeżeli wyłączę raytracing to czy wtedy nie używa scanline? I co z tym problemem będącym w temacie? Rozumiem że mimo wszystko winna jest ta precyzja zapisu. Podobne problemy zauważyłem też w innych programach 3D więc to nie jest niedoskonałość Blendera.

A możesz powiedzieć jak wyłączysz w blenderze raytracing? Przełącznik wyłączający raytracing w render panel wyłączy tylko raytracing cieni czy odbić/załamań promieni - po prostu rzuca primary rays które od razu zwracają kolor, bez śledzenia co się dalej z nimi dzieje.

 

Co do problemu to jest on powszechny bo to jest spowodowane zwykłym frustum culling (który na podstawie kamery i jej bliskiej i dalekiej płaszczyzny przycięcia generuje informacje, czy coś się znajduje w kamerze czy nie) - jest to standardowa rzecz stosowana zarówno w grach (opengl/dx), scanline, jak i raytracerach dla primary rays (bo dalej nie wiadomo czy odbite/załamane promienie będą kolidować z czymś z "bryłą widoku" czy nie).

[Ania]

Sprawdź czy rozwiązanie podane tutaj przez Avengera pomoże:

http://www.blender.pl/index.php?option=com_smf&Itemid=2&?topic=7480

[człowiek]

Sprawdź czy rozwiązanie podane tutaj przez Avengera pomoże:

http://www.blender.pl/index.php?option=com_smf&Itemid=2&?topic=7480

 

Dzięki Ania, rozwiązanie podano już wcześniej i jest dokładnie takie samo jak to z tej strony.

 

Skoti a możesz mi łopatologicznie wyjaśnić jakie znaczenie ma w tym problemie ma start w kamerze? Ja wymyśliłem, że problem teoretycznie może brać się z precyzji wynikającej z kąta rozchodzenia się widoku w kamerze. Im początek jest bliższy kamerze tym plan na takiej odległości jest mniejszy? Czyli tak naprawdę problemem nie tyle jest liczenie odległości co różnica pomiędzy wielkością obrazu na start i wielkością na end? Stąd faktycznie mógłby się brać problem precyzji, bo to jednak ogromna różnica. Nie wiem czy zostałem dobrze zrozumiany, więc obrazowo. Do zakrycia całej kamery w odległości 0.1 od niej potrzeba płaszczyzny o wymiarach "a x b". Dokonanie zasłonięcia całego widoku w odległości 5000 wymaga o wiele większej płaszczyzny. Tylko w takim przypadku widzę sens powstawania błędów precyzji.

[Skoti]

Skoti a możesz mi łopatologicznie wyjaśnić jakie znaczenie ma w tym problemie ma start w kamerze? Ja wymyśliłem, że problem teoretycznie może brać się z precyzji wynikającej z kąta rozchodzenia się widoku w kamerze. Im początek jest bliższy kamerze tym plan na takiej odległości jest mniejszy? Czyli tak naprawdę problemem nie tyle jest liczenie odległości co różnica pomiędzy wielkością obrazu na start i wielkością na end? Stąd faktycznie mógłby się brać problem precyzji, bo to jednak ogromna różnica. Nie wiem czy zostałem dobrze zrozumiany, więc obrazowo. Do zakrycia całej kamery w odległości 0.1 od niej potrzeba płaszczyzny o wymiarach "a x b". Dokonanie zasłonięcia całego widoku w odległości 5000 wymaga o wiele większej płaszczyzny. Tylko w takim przypadku widzę sens powstawania błędów precyzji.

Nie wiem czy łopatologicznie potrafię ale spróbuję.

 

Teoria: każdy punkt jest mnożony przez macierz 4x4 (wynik mnożenia macierzy projekcji (generuje się ją z fov płaszczyzny przycięcia near/far) i widoku (przekształcenia kamery które się generuje np. z pozycji oka i kierunku patrzenia/punktu na który patrzy i wektora up (w blenderze na kamerze masz strzałkę to właśnie up ;]))), i pierwsze trzy komponenty otrzymanego wektora (x, y, z) mnożymy przez 1/w (w jest ostatnim komponentem 4 elementowego wektora) - w wyniku otrzymujesz pozycje punktu w przestrzeni 2d (układ współrzędnych 2d na ekranie to komponenty x,y, a z to wektor idący wgłąb ekranu (ich wartość jest [-1, +1] oznacza, że jest na scenie - ofc to zależy jak macierz była robiona (z jakich wzorów) - np. w opengl wartości są takie jak pisze (osi to [-1, 1]^3), w dx wartości x,y są takie same, ale z na ekranie jest tylko jeśli wartości są [0, 1] (czyli osie to [-1, 1]^2*[0, 1]))).

 

Praktyka: Ogólnie błędu tu nie ma - po prostu dany punkt matematycznie nie mieści się w danych przedziałach, to znaczy, że go nie ma i może powstać błąd przez złe ustawienia płaszczyzn przycięcia w kamerze.

[człowiek]

Dzięki za wyjaśnienie. Jak zwykle w przypadku takich wyjaśnień to jednak pomimo łopatologii, którą widzę (bo sam czasami takie wywody piszę) to jednocześnie wiem, że żeby w pełni zrozumieć to trzeba trochę posiedzieć i analizować. No ale niestety na to nie ma aż tak dużo czasu, a szkoda. No nic, ważne, że istnieje jakieś rozwiązanie dla danego problemu.