Edycja: Do rysowania w czasie rzeczywistym, zaczął używać lwjgl, który jest bazą jmonkeyengine i jocl w "interoperacyjności" między opengl i opencl, teraz może obliczyć i narysować 100k cząstek w czasie rzeczywistym. Być może silnik jmonkey w wersji płaszczowej może wyleczyć ten problem z obciążeniem.

Od kilku dni uczę się silnika jMonkey (wersja 3.0) w Eclipse (java 64-bitowy) i próbuję zoptymalizować scenę za pomocąGeometryBatchFactory.optimize(rootNode); dowództwo.

Bez optymalizacji (z możliwością zmiany pozycji sfer):

Dobra, tylko 1-fps pochodzi z obu pasm ekspresji pci-express + jvm.

Z optymalizacją (bez możliwości zmiany pozycji sfer):

Teraz ma 29 klatek na sekundę, nawet przy zwiększonym numerze trójkąta.

Java3D miałsetCapability() metoda, która sprawia, że ​​obiekt sceny może być odczytywany / zapisywany nawet w zoptymalizowanej formie. Silnik jMonkey 3.0 musi być zdolny do tego tematu, ale nie mogłem znaleźć żadnego jego śladu (przeszukane samouczki i przykłady, nie powiodło się).

Pytanie: Jak mogę ustawićread/write position/rotation/scale możliwościoptimized węzły sceny w jMonkey 3.0? Jeśli nie możesz udzielić odpowiedzi na pierwsze pytanie, czy możesz mi powiedzieć, dlaczego liczby trójkątów rosną, gdy używam polecenia optymalizacji? Czy muszę utworzyć nową metodę dostępu do karty graficznej i zmienić zmienne samodzielnie (może jogl?)?

Informacje o scenie: 16k cząstek (kule 16x16 res) + 1 punkt światła (i jego 4096 rozdzielczości cienia).

Jestem pewien, że z łatwością możemy wysłać kilka tysięcy liczb zmiennoprzecinkowych w ciągu milisekundy przez pci-express.

Dodatkowe informacje: Używam jądra Aparapi do aktualizacji pozycji cząstek, co zajmuje 10 milisekund (16k * 16k interakcji do obliczenia sił). (Niczego nie zmienia w trybie zoptymalizowanym :() Czy aparapi może uzyskać dostęp do tych zoptymalizowanych danych?

W przypadkubatchNode.batch(); optymalizacja, tutaj 1 fps z mniejszą liczbą obiektów:

Numer obiektu jest teraz tylko kilkaset, ale fps nadal wynosi 1!

Wysłanie tylko pozycji kuli do gpu i umożliwienie obliczenia pozycji wierzchołków może być lepsze niż obliczanie wierzchołków na procesorze oraz wysyłanie ogromnych danych do gpu.

Nikt tu nie pomoże? Próbowałem już batchNode, ale nie wystarczył.

Nie chcę zmieniać 3d api, ponieważ ludzie jMonkey na nowo wymyślili koło i jestem zadowolony z obecnej sytuacji. Po prostu próbuję wycisnąć trochę więcej wydajności (anulowanie cieni daje prędkość 100%, ale jakość jest również ważna!).

Ten program java stanie się symulatorem sceny z asteroidami (będzie wybór rozmiaru, masy, prędkości, kąta asteroidy) z algorytmem sześcianów maszerujących z LOD (będą to miliony cząstek).

Algorytm Marching-cubes znacznie zmniejszyłby liczbę trójkątów. Jeśli nie możesz udzielić żadnej odpowiedzi na pytanie, wszystkie sześciany maszerujące (lub dowolny O (n) wypukły kadłub) algorytmu java zostaną zaakceptowane! Dane: tablice x, y, z jako źródło i tablica trójkąt-pasek jako cel (punkty siatki powierzchni izo)

Dzięki.

Oto kilka próbek o strumieniu (o znacznie niższej rozdzielczości):

1) Zwijanie się grupy skalnej w kształcie sześcianu przez grawitację:

2) Siła wykluczająca zaczyna się ujawniać:

3) Siła wykluczenia + grawitacja sprawia, że ​​grupa tworzy bardziej gładki kształt:

4) Grupa tworzy kulę (zgodnie z oczekiwaniami):

5) Następnie zbliża się wielkie gwiezdne ciało:

6) O dotyku:

7) Moment uderzenia:

Przy pomocy algorytmu Barnesa-Hutta i obciętego potencjału liczby cząstek będą o 10x (może 100x) więcej.

Zamiast algorytmu Marching-Cubes, płótno duchów, które owija nbody, może dać kadłub o niskiej rozdzielczości (łatwiejsze niż BH, ale wymaga więcej obliczeń)

Tkanina duchów zostanie dotknięta przez ciało (grawitacja + wykluczenie), ale nie będzie na nią wpływu tkanina, która ją okrywa. Nikt nie będzie renderowany, ale siatka tkaniny będzie renderowana z niższą liczbą triange.

Jeśli MC lub powyżej działa, pozwoli to programowi renderować tkaninę do owijania na około 200x więcej cząstek.