Autor Wątek: JMonkeyEngine 3.0 i cienie  (Przeczytany 4685 razy)

Offline FrozenShade

  • Użytkownik
    • Skullstone's official site

# Wrzesień 25, 2014, 22:14:01
Witam,

Próbuje swoich sił z 3D, oczywiście w javie, oczywiście OpenGL. Silnik, którego używam to JME3 - dobrze zrobiony opensource, łatwy w obsłudze, projekt jest żywy.

Pytanie: czy ktoś z Was miał z tym silnikiem jakieś doświadczenie? Chodzi mi konkretnie o cienie. Przy wielu światłach jest brzydki efekt - przedmiot rzuca cień, drugie światło nie rozświetla tego cienia. Używam świateł punktowych.
Wcześniej nie miałem w ogóle styczności z 3D, dopiero poznaję podstawową terminologię ;) Doświadzcenie w programowaniu to ok 11 lat zawodowego klepania kodu, więc prędzej czy później sobie poradzę. A piszę tu, bo oczywiście wolał bym wcześniej. Może ktoś z Was podrzuci jakiś kod/przykład albo chociaż nakieruje na konkretne zagadnienie do zbadania.

Każda pomoc mile widziana.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

  • +2
# Wrzesień 25, 2014, 22:23:56
Cytuj
Próbuje swoich sił z 3D, oczywiście w javie
Dlaczego "oczywiście"? Java to ostatnia rzecz której bym użył do 3D (tak, próbowałem, wydajność była godna pożałowania).

Cytuj
Przy wielu światłach jest brzydki efekt - przedmiot rzuca cień, drugie światło nie rozświetla tego cienia.
Screen by tu mógł wiele pomóc.

Offline FrozenShade

  • Użytkownik
    • Skullstone's official site

# Wrzesień 25, 2014, 22:37:24
Dlatego 'oczywiście' bo to juz mój drugi projekt w javie, pierwszy to http://warsztat.gd/projects/pgr_online , ukończony, ludzie sobie grają. C# mam na co dzień w pracy, w domu wieczorami chcę odmiany ;)

Oto screen: http://s22.postimg.org/owukfl9pt/3ddu7.png

Na srodku pomieszczenia stoi kolumna, po jej prawej stronie znajduje się źródło światła, kolumna rzuca cień. Za kamerą znajduje sie drugie światło (cień od tego światła rzucany przez kolumnę nie jest tu za bardzo widoczny).


 

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Wrzesień 25, 2014, 23:11:34
Cytuj
C# mam na co dzień w pracy, w domu wieczorami chcę odmiany ;)
C# akurat wydajnościowo też już zdążył mnie zawieść, chociaż generalnie jest OK. Ale co kto lubi. Dopóki nie będziesz potrzebował za dużo obliczeń na CPU, to i Java da radę.

Cytuj
Oto screen: http://s22.postimg.org/owukfl9pt/3ddu7.png

Na srodku pomieszczenia stoi kolumna, po jej prawej stronie znajduje się źródło światła, kolumna rzuca cień. Za kamerą znajduje sie drugie światło (cień od tego światła rzucany przez kolumnę nie jest tu za bardzo widoczny).
Wygląda to tak, jakby dwa cienie maskowały to samo źródło światła. Co więcej, to źródło obok kolumny wcale nie wydaje mi się zgadzać z położeniem cienia (źródło jest trochę za kolumną, a środek cienia jest równo z nią).

Na mój gust coś pomieszałeś przy ustawianiu tych świateł. Przeglądając API jMonkeyEngine znalazłem przykładowy kawałek kodu (link) - zakomentowany fragment dodaje drugie światło, więc warto porównać to z Twoim kodem. Może przeoczyłeś albo pomyliłeś coś oczywistego.

Offline FrozenShade

  • Użytkownik
    • Skullstone's official site

# Wrzesień 25, 2014, 23:23:11
Raczej nie przeoczyłem, światła są dobrze ustawione a cienie dla pojedyńczego źródła światła zachowują sie poprawnie. Mam ustawione źródło punktowe, które podąża za kamerą, więc miałem okazje to sprawdzić.
Głównym problemem jest to, że cień kolumny powinien zostać rozświetlony przez źródło światła znajdujace się za kamerą. A przynajmniej nie powinien być tak czarny, jak by tego światła w ogóle nie było. Oto ta sama scena bez światła padającego zza kamery: http://s30.postimg.org/p40fha3qp/3ddu8.png
Cień rzucany na podłogę przez kolumnę jest taki sam.


Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Wrzesień 25, 2014, 23:44:12
Hmm, mogę się tylko domyślać, że cienie tutaj są renderowane i blurrowane w screen space. Może spróbujeszzrobić osobne point light filtery dla tych świateł?

Tak, czy inaczej, dziwnie to mi wygląda i zrobienie tego wydajnie i sensownie w tym silniku może być bardzo nietrywialne.

Offline FrozenShade

  • Użytkownik
    • Skullstone's official site

# Wrzesień 26, 2014, 00:20:16
Czy 'deferred rendering' to dobry trop? Bo nie wiem, czy zainteresowałem się właściwym tematem....

Offline wozix

  • Użytkownik

# Wrzesień 26, 2014, 00:28:22
Dopóki nie będziesz potrzebował za dużo obliczeń na CPU, to i Java da radę.

Tutaj akurat przede wszystkim zwróciłbym uwagę na zarządzanie pamięcią. W Javie nie masz żadnego zarządzania pamięcią z twojej strony, a w takim C++ masz pełną dowolność i możesz optymalizować do bólu (oczywiście musisz pisać dużo bardziej odpowiedzialnie). Java jest zbyt uboga dla programu, który docelowo powinien wykorzystywać zasoby najwydajniej jak to tylko jest możliwe (czyli gry).

Offline FrozenShade

  • Użytkownik
    • Skullstone's official site

# Wrzesień 26, 2014, 00:37:28
Zarządzanie pamięcią częściowo można zaimplementowac samemu - Zarówno w c# jak i w javie fabryki obiektów czynią cuda. Przy poprzednim projekcie - PGR Online - miałem problem z tworzeniem sceny 3D kolejnych wycinków mapy. Duża ilość obiektów 'leciała do kosza' i po chwili równie dużo obiektów było na nowo tworzonych. Zamiast gubić referencje wystarczyło odkładać sobie obiekty na później. Efekt był taki, że java allokowała do pewnego momentu sporo pamięci a potem poziom zużycia pamięci praktycznie stał w miejscu. To samo się zresztą robi w c++, ale z troche innego powodu - żeby oszczędzić na ciężkich operacjach samego allokowania i zwalniania oraz nie fragmentować sobie sterty.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Wrzesień 26, 2014, 00:56:49
Cytuj
Tutaj akurat przede wszystkim zwróciłbym uwagę na zarządzanie pamięcią. W Javie nie masz żadnego zarządzania pamięcią z twojej strony, a w takim C++ masz pełną dowolność i możesz optymalizować do bólu (oczywiście musisz pisać dużo bardziej odpowiedzialnie). Java jest zbyt uboga dla programu, który docelowo powinien wykorzystywać zasoby najwydajniej jak to tylko jest możliwe (czyli gry).
Zarządzanie pamięcią ma się nijak do samej gry. Głównym problemem jest narzut VM przy rzeczach gdzie CPU musi przetworzyć większe ilości danych (przeliczyć animację na kościach, wygenerować kawałek heightmapy, coś rozpakować, czy przetworzyć teksturę).

Cytuj
To samo się zresztą robi w c++, ale z troche innego powodu - żeby oszczędzić na ciężkich operacjach samego allokowania i zwalniania oraz nie fragmentować sobie sterty.
W C++ po prostu tworzy się jeden std::vector struktur i nic nie allokuje przez całą grę.

Offline wozix

  • Użytkownik

# Wrzesień 26, 2014, 21:57:33
Zarządzanie pamięcią ma się nijak do samej gry
To chyba Ci się nigdy GC nie załączył...

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Wrzesień 27, 2014, 10:50:34
To chyba Ci się nigdy GC nie załączył...
Piszę w C++, więc bym się naprawdę mocno zdziwił, gdyby mi się załączył. ;)

Inna kwestia, że z reguły piszę tak, że gra po "rozgrzaniu się" nie robi już żadnych allokacji.

Offline wozix

  • Użytkownik

# Wrzesień 27, 2014, 19:23:51

Offline FrozenShade

  • Użytkownik
    • Skullstone's official site

# Wrzesień 27, 2014, 20:53:10
Do zamknięcia. Offtop się robi i jestem w trakcie rozwiązywania problemu.

Offline FrozenShade

  • Użytkownik
    • Skullstone's official site

# Październik 03, 2014, 09:35:06
Cienie były robione niezależnie dla każdego światła i nic 'nie wiedziały' o pozostałych światłach na scenie. Drobna modyfikacja kodu renderera cieni uwzględniająca przekazane do niego pozycje najbliższych świateł rozwiązała problem.
Niestety, deferred rendering, który by pewnie był tu bardziej na miejscu nie jest obsługiwany przez ten silnik a napisanie go samemu jest, jak na razie dla mnie rzeczą zbyt skomplikowaną.

Tak to teraz wygląda: http://postimg.org/image/yl0ks0tbd/