arev

@Monio: też się nakręciłem widząc Mali400 w tanich sprzętach. Przeszło mi gdy zobaczyłem benchmarki. Niestety układ w tych budżetowych urządzeniach nie jest nawet w przybliżeniu tak wydajny jak w SGS II. Nie wiem, może to wina pozostałych komponentów z niższej półki, ale wyniki są naprawdę słabe. Jak znajdę stronę z wynikami testów to wkleję linka. O, tu jest: http://glbenchmark.com/result.jsp?gpu=Mali-400+MP&benchmark=glpro25

Fajna bryła. Mnie akurat podobają się zbite kadłuby. Poza tym moment bezwładności obiektu jest wtedy niższy, więc łatwiej nim manewrować. A do referek tylko: http://conceptships.blogspot.com/ - gorąco polecam, oglądania jest na kilka dni.

@ola-f: Najsłabsze urządzenia jakimi jeszcze możesz sobie zawracać głowę to iPad 1 i iPhone 3GS. Samo Apple ma już dosyć iPada 1 nie wydając wersji iOS 6 dla niego. Mały problem stanowi samo odfiltrowanie urządzeń bo nie ma opcji zaznaczenia tylko kilku interesujących modeli, trzeba to robić wymagając konkretnych ficzerów. 3G odcina się architekturą armv7, natomiast 3GS i iPada 1 można odciąć wymagając w manifeście frontowej kamery. Zostaje iPhone 4, 4S, 5, iPad 2 i 3 i jakieś iPody. iPhone 4 jest jeszcze trochę kłopotliwy bo ma względnie mały stosunek wypełniania do rozdzielczości, ale jest i tak lepiej niż z iPadem 1. Jeśli chcesz puszczać gry, które nie zarysowują ekranu kilka razy to wystarczy, tylko pilnuj pamięci bo z tym też nie jest rewelacyjnie. @Idaho: problem rozwiązuje się właściwie w dwóch etapach. Pierwszy to projektowanie samego pola rozgrywki tak by dobrze wyglądało przy proporcjach 4:3 i 16:9. Słowo "wyglądało" ma tu kluczowe znaczenie, bo często nie da się zrobić całego obszaru interaktywnym w tak różnych proporcjach. Możesz więc skupić akcję w środku w proporcji 4:3 i po bokach dodać tło/ozdoby/whatever. Oczywiście renderując z kamery 3D nie ma tego problemu. Drugi etap to GUI. Zdecydowanie najlepiej jest podzielić je na kilka grup zakotwiczonych w różnych punktach ekranu (prawy-dół, środek-góra, etc.). Można też dodatkowo skalować w zależności od rozmiaru ekranu - w wersji 3.5 doszło Screen.dpi, co w połączeniu z rozdzielczością pozwala bezpośrednio obliczyć rozmiar ekranu i wziąć poprawkę na wielkość wyświetlanych elementów GUI. W sumie nic strasznego, ale dobrze myśleć nad tym od początku. edit: Zostaje jeszcze kwestia rozdzielczości tekstur na ekranach np. 480x320 vs. 2048x1536, ale to jest dość indywidualna kwestia. Czasem nie trzeba nic robić, a gra wygląda dobrze w każdej rozdziałce, innym razem warto zastanowić się nad ładowanie tekstur wyższej rozdzielczości dla lepszych ekranów (urządzenia z mniejszą rozdziałką mają też zwykle mniej pamięci, więc uniwersalne tekstury w najwyższej rozdzielczości mogą być problematyczne).

Cenne znalezisko, chłopaki w firmie uwielbiają. Dziękuję, Milordzie :)

No i właśnie tak należy traktować "przedsiębiorców" którzy próbują przerzucać ryzyko własnych inwestycji na kogoś innego, obiecując gruszki na wierzbie. Czyli ola-f ma rację - nie tylko w branży graficznej tak jest. Spróbujcie teraz coś zbudować. Jeszcze się robota nie zacznie, a generalny wykonawca już przyjdzie z łapą wyciągniętą po więcej kasy.

Źle się wyraziłem, pisząc o aproksymacji bo opisanym sposobem uzyskuje się właściwie dokładną reprezentację kapsuły. Wracając zaś do kwestii tych wklęsłych brył to oczywiście wrzucanie ich "na pałę" gdzie się da jest pozbawione sensu, ale przecież nie każda symulacja fizyczna ma n→∞ liczbę elementów. Może przecież zdarzyć się przypadek, w którym elementów będzie kilka, a na dokładnym odwzorowaniu kolizji jednego z nich będzie nam zależeć szczególnie. Jasne, wszystko można złożyć z boksów i sfer, ale czasem naprawdę mija się to z celem.

Nic nie zabrania stosowania brył wklęsłych jako collidery dla rigidbody. Jest jedno istotne ograniczenie - wklęsłe MeshCollidery nie kolidują ze sobą, ale mając to na uwadze można ich używać w obiektach dynamicznych. Sfera jest najtańszą do policzenia bryłą, bo żeby znaleźć punkt na jej powierzchni lub wewnątrz wystarczy porównanie promienia. Kapsułę chyba najkorzystniej liczyć aproksymując dwiema sferami na końcach i osią, na którą rzutujemy punkty pomiędzy nimi (chociaż to pewnie nie jedyny wydajny sposób). Natomiast inne bryły trzeba mnożyć przez macierze transformacji, co jest względnie kosztowne obliczeniowo.

No to wtedy trzeba napisać/zmodyfikować shadera. Nie twierdziłem, że jest doskonale, ale rozsądna baza do pracy jest.

No jest przecież cała masa wbudowanych shaderów obsługujących speculara (zwykle jako kanał alfa w teksturze diffuse).

Dzięki za opinie o Batmanie. Byłem dzisiaj i jest spoko. Podobał mi się mniej niż poprzednia część, ale uważam, że jest solidną pozycją. Lekko irytujące momenty są do przełknięcia, w końcu to kino rozrywkowe.

Napiszcie coś, proszę, o nowym Batmanie. Kumpel mówił, że słabszy od Prometeusza, ale chciałbym zasięgnąć innych opinii przed podjęciem decyzji o wyjściu na seans. Thx.

@nihilplures: CapsuleCollider pochodzi z CharacterController, a kolizje są liczone na layerach, nie na tagach, więc chyba nie tu kłopot. @ledyr: To może spróbuj tak: Zostaw CharacterControllera do poruszania się, stwórz mu dziecko z Triggerem, Rigidbody i prostym skryptem, który będzie badał kolizje i wysyłał dane do PawnController. Edit: możesz jeszcze dodać dodatkowy trigger Collider do samego Character Controllera, ale musiałbyś pokombinować trochę z layerami, żeby nie dostawał OnTriggerEnter z kolizji z samym CharacterControllerem (to chyba w sumie łatwiejszy sposób).

Na pierwszy rzut oka obstawiałbym nieporozumienie pomiędzy CharacterControllerem a Rigidbody. Właściwie to używanie obu jest trochę bez sensu. CharacterController jest po to by się poruszać nie przechodząc przez collidery bez grzebania się w fizyce RB. Z kolei jeśli chcesz żeby postać wywierała fizyczny wpływ na elementy otoczenia to lepiej przenieść wszystko do rigidbody, dodać sobie jakieś constrainy i posiedzieć nad płynnym poruszaniem. Teraz rigidbody może mieć problem z załapaniem collidera z CharacterControllera jako swojego. Spróbuj zostawić tylko jeden z tych komponentów.

Pokazałbyś kod lub wrzucił gdzieś scenkę. Tak na sucho ciężko, ale pewnie coś źle zrobiłeś :D

Czyli wszystko ok, bo NES nie jest podłączony do telewizora. Widać jakaś atarynka w szafce musi być. Technicznie fajnie, światło i shadery przyzwoite, chociaż AO wydaje mi się zbyt mocne w rogach pomieszczenia. Poza tym sama konsola, razem z padami, wydaje mi się zbyt masywna w stosunku do stojącej obok puszki.

Skoro działa na piłce, to możesz usunąć całe "GameObject.Find("Ball").". Generalnie powinno wystarczyć jednorazowe przyłożenie siły, przy czym ustaw parametr "Drag" w Rigidbody na 0 - wtedy piłka nie powinna hamować. Dodając cały czas siłę nakłada się ona, prawdopodobnie, z siłą odbicia od ściany. Kolejną sprawą jest miejsce, w którym wymuszasz stałą siłę. Trzeba to robić w FixedUpdate, nigdy w Update, bo ten nie działa synchronicznie z silnikiem fizycznym.

Spróbuj przestawić ilośćkości wpływających na jeden vertex w SkinnedMeshRendererze, ew. przejrzyj opcje importu pliku, może coś się tam próbuje optymalizować.

Czy ten skrypt działa na piłce, czy na innym obiekcie? p.s. Nie pisz postów kolorem utrudniającym czytanie, pls :)

Batmana....

Chyba nie. Po seansach 3D w Multikinie boli mnie głowa, dlatego przestałem się na takie wybierać.

A czy po przełączeniu na inny driver viewportu sytuacja się poprawia?

Gdyby problem leżał w sterownikach graficznych to powinien ograniczać się do viewportów. Przecież GPU nie nadpisuje ufałek. Może masz w materiale "Use real world scale"?

Oprócz wartości szumu musisz jeszcze ustawić odpowiednio wysokie parametry samplera, żeby sobie poradził z odszumianiem. Prawdopodobnie wystarczy też podbić sample odbić w materiale płytek.

Bardzo bym się cieszył gdyby była konsola do TV z rynkiem dostępnym tak łatwo jak AppStore/GooglePlay. Szczerze mówiąc, to gdyby nie sterowanie dotykowe na iPada można by całkiem konkretne gry robić (nie twierdzę, że nie ma żadnych konkretnych, tylko że mogłyby osiągnąć nowy poziom). Niby jest parę kontrolerów przez Bluetooth, ale póki co to niszowe sprawy. Niestety hardware OUYA nie powala, szczególnie jeśli zacznie renderować w Full HD, no i szczerze wątpię, że będą w stanie to sprzedawać za $100.

Da się. Musisz najpierw wczytać dwa sety UV w shaderze: BindChannels { Bind "texcoord", texcoord0 Bind "texcoord1", texcoord1 } a potem, w SetTexture użyć tekstur w takiej kolejności w jakiej chcesz żeby korzystały z tym kanałów. Tutaj standardowo najpierw diffuse, potem normal. Jak coś więcej potrzebujesz to już nie pomogę, bom niezbyt biegły w shaderach.