człowiek

Dzięki. Sprawdzę za parę dni jak dojdę do tego etapu, ale pewnie masz rację.

Jak wyeksportować w blenderze obiekty razem z materiałami itd. z jednego do drugiego projektu tak aby było jak najmniej rzeczy do poprawienia po eksporcie?

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.

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.

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

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

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

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.

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.

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.

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.

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.

Szkoda, bo już czas, żeby wreszcie powstało coś poważnego w wersji darmowej

Dobrze zrozumiałem ze strony Luxrendera, że są w fazie testów z wykorzystaniem GPU do obliczeń, ale na razie nie udostępnili aplikacji?

Czyli yafaray?

Tym razem głowię się jak zrobić, żeby światło przechodziło przez obiekt ze szkła np. szklankę i padało załamane np. na ścianę za szklanką. I nie mam pojęcia jak to zrobić. Jak w lampie nie mam "Ray..." to światło przechodzi przez szkło, ale nie jest w ogóle załamane. Zaś kiedy "Ray..." mam włączone to szklany obiekt rzuca cień jakby był nie przezroczysty. Sprawdziłem wszystkie opcje jakie przyszły mi do głowy i niestety nie dałem rady. Drugi problem podobny to jak zrobić, żeby światło np. "spot" skierowane w stronę paru obiektów i m.in. lustra i odbija się ono w lustrze i odbicie oświetla coś dalej? Królestwo temu, kto pomoże, bo jak szukałem w internecie to akurat tego nie znalazłem :(.

O widzisz. Właśnie o to mi chodziło. Takiej operacji jeszcze nie widziałem :).

Mam dość skomplikowany jak dla mnie problem z cieniem. Muszę zrobić tak, że mam 3 obiekty, światło i kamerę. Chodzi o to, żeby jeden obiekt reagował na światło, ale nie reagował na cień jednego obiektu, ale na drugi obiekt już ma normalnie reagować. Przy czym nie wystarczy wyłączyć rzucanie cienia, bo ten obiekt ma rzucać cień na drugi obiekt. Krótko mówiąc: mamy obiekty A, B, C Obiekt A reaguje na cień B, ale nie reaguje na cień C, sam rzuca normalny cień Obiekt B reaguje na cień A i C Obiekt C reaguje na cień A i B Udało mi się zrobić, żeby obiekt A reagował na światło, bez cienia z pozostałych obiektów, ale nie o to chodziło. Pomóżcie, bo to dla mnie już za poważne.

A, właśnie. Dzięki. Tam w tym polu wyboru jeszcze nie patrzyłem.

Jak dodać klucze dla ustawień barwy światła, energii i dystansu? Które to opcje w ipo? Nie mogłem tego znaleźć. A jeśli się nie da tego animować, to jak zrobić np. gasnące powoli światło lub zmieniające płynnie kolor?

Tak myślałem, że problemem mogą być te macierze transformacji. Tylko nie wiedziałem, że copy rotation kopiuje tę macierz, a nie same dane o obrocie.

No, czyli jedyny sposób to dodatkowy obiekt. Tak samo zrobiłem, ale liczyłem, że coś źle robiłem i dlatego mi nie działało. Szkoda tylko, że ktoś jakoś dziwnie zorganizował sprawę skali.

Nie wiem skąd zarzut, że to wjazd na ambicję. W końcu nikt nikogo nie zmusza do odpowiedzi. Równie dobrze nie zadawajmy w ogóle pytań, bo po co, jak prawie zawsze zadający pytanie chciałby poznać odpowiedź. Druga sprawa to napisałem przecież jaki efekt chciałem uzyskać. Mam dwa obiekty identyczne. Chcę aby jeden i drugi obracał się dokładnie tak samo niezależnie od skali i pozycji, więc zrobiłem copy rotation. Okazało się jednak, że copy rotation jakimś cudem wykorzystuje skalę z obiektu, z którego bierze obrót. Nie wiem więc czy jest to takie proste i oczywiste, bo niby jakim cudem to co nie jest kopiowane ma wpływ na obiekt? Zwrócę ci jeszcze uwagę, że ten obiekt, który ma copy rotation nie jest tylko odwrócony np. o 180st. On jest odbiciem lustrzanym. Pomóż więc i powiedz mi jak to zrobić, żeby oba obiekty odwracały się jednocześnie przy ujemnej i dodatniej skali, bo dla mnie kopiowanie obrotu to kopiowanie obrotu, a nie skali i obrotu.

O, widzę, że tym razem pytanie jest albo za trudne, albo za głupie, albo nie wiem. Jeśli za głupie to może mi ktoś powiedzieć dlaczego?