Witam. Mam takie pytanie. W moich setach powtarzają się niektóre elementy. Czy to ma jakieś znaczenie ? Czy to jakoś optymalizować ?
1
1
Jeśli masz bardzo dużo danych trzymanych w RAM, to wtedy optymalizacja oczywiście ma znaczenie.
Zwykle robi się to w ten sposób, że masz zestaw unikalnych kafelków, natomiast mapa nie jest zbudowana z tekstur, a z indeksów kafli. W ten sposób nie dość, że unikasz duplikowania grafik, to w dodatku instancja mapy zajmuje o wiele mniej pamięci (w końcu to tablica liczb, zamiast tablicy tekstur).
Jeśli masz wiele tak samo wyglądających tekstur kafli, ale różniących się jedynie kolorem, to możesz je po prostu renderować inaczej — albo z wykorzystaniem innych kolorów/trybu modulacji, albo za pomocą shaderów.
U siebie akurat wykorzystuję modulację koloru. Font jest zbudowany z zestawu glifów w kolorze białym, natomiast aby móc renderować tekst w różnym kolorze, ustawiam różne kolory modulacji. Glify znaków mają czarną otoczkę i ta nie zmienia koloru (kanały mają wartości 0, więc wynikiem modulacji zawsze jest czarny kolor).
Coś podobnego sam możesz wykorzystać, ale pamiętaj, że modulację można wykorzystać raczej do prostych efektów — cudów tym nie zrobisz. Aby mieć pełną swobodę i niemal nieograniczone możliwości, skorzystaj z shaderów.
1
Wiem. Ale nie wiem jak podzielić te tekstury tzn. na co podzielić te tekstury. Mogę zrobić tak, że dzielę taki set na tekstury 64x64 px i ewentualnie mogę porównywać czy tekstury nie są takie same a gdy są to sie scalają.
1
Najlepiej by było, abyś ich w ogóle nie dzielił — czyli miał jedną teksturę, zawierającą różne kafle (jeśli jest ich relatywnie mało, to i nawet wszystkie typy kafli). Czyli tworzysz teksturę zwaną atlasem i w niej są wszystkie kafle, po jednym typie każda. Minus tego jest jednak taki, że taki atlas może służyć tylko do odczytu — jeśli coś namalujesz na którymś kaflu, to zmienisz jego wygląd na całej mapie (wszędzie, gdzie jest on używany).
Tak więc pytanie główne — potrzebujesz dynamicznie przemalowywać zawartość tych tekstur, czy służą Ci jedynie do odczytu? Jeśli potrzebujesz dynamicznego przemalowywania tekstur kafli, to do czego konkretnie?
Drugie pytanie jest ważne, bo można zrobić tak, że tekstury kafli będą tylko do odczytu, a jednocześnie będzie możliwość dynamicznego malowania po mapie, udając, że maluje się kafle tej mapy.
1
Nie zamierzam edytować kafli w Map Edytorze. Potrzebuję je do palety służącej do umieszczania kafli na mapie i staram się jakoś ją zoptymalizować. Chcialbym te sety umieścić w palecie.
1
To co pokazałeś wyżej, można wyrenderować na podstawie bardzo małej liczby grafik, zamujących o wiele mniej miejsca niż pełna grafika tego zasobnika (?). W zależności od tego jak bardzo chcesz zmniejszyć zużycie pamięci (liczbę tekstur), możesz wydzielić sobie kilka kafli i je renderować w pętli — pole bez ramki, pole z ozdobną ramką i przyciski strzałek. Ale możesz też pójść o krok dalej.
Biorąc pod uwagę to, że przyciski ze strzałkami współdzielą to samo obramowanie, możesz wydzielić poszczególne fragmenty obramowania. Rogi ramki (albo jeden róg renderowany z rotacją lub flipem), paski obrarmowania (tutaj tak samo), strzałki (lub jedna, również renderowana z flipem) itd. Do tego zamiast mieć np. belkę ogramowania jako długi pasek, wystarczy pasek o szerokości 1px, renderowany z rozciągnięciem. Tło, jeśli wszędzie ma być jednokolorowe, również może być sprajtem o wymiarach 1x1px i renderowany z rozciągnięciem, ale też możesz je renderować jako prymitywny kształt (jednokolorowy prostokąt).
Tak więc całą tę grafikę, którą pokazałeś, można zawrzeć w teksturze o wymiarach dosłownie kilka na kilka pikseli. Pamiętaj jednak, że im bardziej zmniejszysz liczbę tekstur, tym więcej kodu będziesz musiał napisać, który wyrenderuje dokładnie taki sam zasobnik. Ale to akurat nie stanowi problemu.
1
Raczej o to mi chodziło. Ale już wiem mniej więcej jak to zrobić.
- Wczytać teksturę setu
- Podzielić teksturę setu na kilka tekstur (64x64 px)
- Dodać tekstury do głównej listy tekstur (jeżeli się jakaś powtarza to zwrócić ją jeżeli nie to stworzyć nową)
- Renderowac paletę ze wszystkimi teksturami
1
Nie bardzo rozumiem co chcesz osiągnąć. Czemu interesuje Cię porównywanie zawartości tekstur?
1
Ponieważ w tym set'cie, który przed chwilą przedstawiłem jest 8 takich samych tekstur - pola czarne
1
Tło mają takie same, ale obramowanie już nie. Łatwiej by było to zobaczyć, gdyby podział na kafle był bardziej widoczny.
1
Wrzucam screena jakby co. Ale już wiem jak to zrobić :-)
2
Czy to ma jakieś znaczenie ? Czy to jakoś optymalizować ?
Nie. Po co.
Przedwczesna optymalizacja źródłem wszelkiego zła. Nie wydaje się aby twoja gra była wstanie zużyć specjalnie dużą ilość zasobów współczesnych maszyn. Masz pewnie milion ważniejszych rzeczy do zaimplementowania i jeżeli chcesz to skończyć w skończonym czasie to powinieneś sobie ustalać priorytety. Optymalizacja stanie się priorytetem jak ci zacznie gra lagować, a i wtedy najpierw trzeba będzie robić benchmarki i profilowanie żeby stwierdzić co konkretnie jest wąskim gardłem.
2
Spearhead napisał(a):
Przedwczesna optymalizacja źródłem wszelkiego zła. Nie wydaje się aby twoja gra była wstanie zużyć specjalnie dużą ilość zasobów współczesnych maszyn.
Co nie oznacza automatycznie, że należy się częstować RAM-em bez opamiętania. Współczesne systemy może i mają dużo zasobów (oprócz nowych Mac-ów, bo w nich mniej znaczy więcej 
), ale działają na nich setki procesów i tysiące wątków, które też z tych zasobów korzystają. Czasy Amigi i NES-ów już dawno minęły.
To samo dotyczy czasu CPU — jeśli w danym momencie nie ma czego przetwarzać, to się ten czas oddaje (na Windows za pomocą Sleep czy innych timerów). Dzięki temu nie tylko daje się możliwość korzystania z CPU przez inne procesy, ale i pozwala procesorowi utrzymywać niskie taktowanie rdzeni, unikać włączania trybu turbo, a więc ograniczać zużycie energii (co wydłuża żywotność baterii i obniża rachunki za prąd).
Ale tutaj masz rację — projekt hobbystyczny, niezbyt zasobożerny, więc można sobie pozwolić na zdecydowanie więcej. Tym bardziej jeśli miałoby to ułatwić robotę i skrócić czas implementacji. 
tBane napisał(a):
Wrzucam screena jakby co.
Tak, teraz jasno widać podział kafli. No i widać wyraźnie, że wiele z nich jest zduplikowanych, co możesz sobie zoptymalizować. W sumie to jeśli skorzystasz z typowego sposobu budowania map, czyli w formie tablicy indeksów tekstur-kafli, to bardziej bym to nazwał ułatwieniem implementacji, niż optymalizacją. Ale plusem tego podejścia jest właśnie drastyczne obniżenie zapotrzebowania na zasoby pamięciowe.
Ale już wiem jak to zrobić
Się pochwal się — nie trzymaj nas w niepewności, bo nie wiadomo czy dyskusja jeszcze trwa czy nie. :P
1
Się pochwal się — nie trzymaj nas w niepewności, bo nie wiadomo czy dyskusja jeszcze trwa czy nie.
A jak, zawsze jest szansa, że ktoś mi doradzi coś dobrego 
1
Nie wiem czy to jest jeszcze aktualne:
https://refactoring.guru/pl/design-patterns/flyweight
0
tBane napisał(a):
Witam. Mam takie pytanie. W moich setach powtarzają się niektóre elementy. Czy to ma jakieś znaczenie ? Czy to jakoś optymalizować ?
Premature optimisation is a root of all evil
Pamiętaj że jeśli optymalizacje będzie polegać na uwspólnieniu bufora to w ten sposób ten bufor (i wszystkie wskaźniki na niego) staje się mutable. Dzisiaj CPU i GPU są wielowątkowe a synchronizacja dostępu trywialna nie jest. Dlatego idzie się w stronę immutable objects/structs/buffers.
Mając trzy oddzielne kopie gwarantujesz że operacje na nich mogą być bezkonfliktowo realizowane z różnych wątków/rdzeni. To jest realna optymalizacja sama w sobie.
1
loza_prowizoryczna napisał(a):
Premature optimisation is a root of all evil
Tyle że usunięcie duplikatów z atlasu tekstur jest jak najbardziej sensowne. Ich usunięcie nie tylko uprości implementację, ale też ograniczy liczbę kafli w palecie, więc większa liczba unikalnych kafli będzie jednocześnie widoczna na ekranie, ale też nie będzie się w przyszłości musiał zastanawiać nad tym, czy duplikaty są osobnymi kaflami (np. czy mają różne ID), czy tymi samymi i może brać z palety którykolwiek.
Najgorzej by było, gdyby duplikaty były identyczne na ekranie (np. ta sama tekstura czy model), ale miały inne ID (czy inne metadane). Potem edytujesz sobie mapę, chcesz np. usunąć z danego obszaru kafle danego typu i głowisz się dlaczego niektórych kafli nie usuwa. Bajzel w assetach przyczyni się do rwania włosów z głowy i tracienia czasu na szukanie problemu tam, gdzie go w ogóle nie powinno być.
Ten cytat „Premature optimisation is a root of all evil” ma zastosowanie tylko w niektórych przypadkach, w tym przypadku nie ma. Zresztą często jest po prostu szkodliwy, bo kod należy pisać od razu dobrze, tak aby był prosty, czytelny i wydajny. Lepiej to robić od razu, kiedy wszystkie informacje są w głowie, świeżo pisany kod nie jest używany w milionach miejsc w projekcie, a ten nie jest zbyt złożony. Potem będzie problem, bo trzeba będzie przypominać sobie o co w nim chodzi, dlaczego nie jest prostszy, a jego poprawianie wymagać będzie analizy całości i sprawdzania gdzie dana funkcjonalność jest używana i w jakim kontekście, aby nie zepsuć kodu całości. A jeszcze gorzej, jeśli trzeba będzie przeprojektowywać architekturę, aby w ogóle można było cokolwiek uprościć.
To samo dotyczy mikro-optymalizacji, tak bardzo deprecjonowanych przez ogół. Piszesz kod danego elementu w sposób optymalny, dzięki czemu zyskujesz np. 200ns wydajności. Mało, prawda? Tak i nie, bo ignorujesz efekt skali i efekt kuli śnieżnej. W projekcie możesz używać nawet tysięcy tych elementów, których ten mikro-zoptymalizowany kod może być używany tysiące razy, na potrzeby generowania dziesiątek klatek gry w każdej sekundzie. I tak Twoja mikro-optymalizacja powoduje wzrost zysku czasu CPU z deprecjonowanych 200ns do setek mikrosekund czy całych milisekund, a to przekłada się na zauważalnie wyższy framerate. A im wyższy framerate czy po prostu mniejsze zapotrzebowanie na czas CPU, to stabilniej działający system, niższe zużycie energii elektrycznej i wsparcie szerszego wachlarzu konfiguracji sprzętowych.
Te przedwczesne i mikro optymalizacje to zwykłe buzzwordy, rzucane na lewo i prawo kompletnie bez zastanowienia i w durzej mierze promujące niedbałość oraz tworzenie niskiej jakości bloatware'u. A to jest szkodliwe, szczególnie w przypadku gamedevu, w którym wydajność jest bardzo istotna.
Mając trzy oddzielne kopie gwarantujesz że operacje na nich mogą być bezkonfliktowo realizowane z różnych wątków/rdzeni. To jest realna optymalizacja sama w sobie.
To nie jest optymalizacja, a obfuskacja, antywzorzec. Nigdy nie używa się duplikatów — zawsze jeden unikalny obiekt (tekstura, model itd.) posiadają tylko jedną instancję w pamięci i wszędzie używa się referencji do tej jednej, unikalnej instancji.
0
flowCRANE napisał(a):
loza_prowizoryczna napisał(a):
Premature optimisation is a root of all evil
Tyle że usunięcie duplikatów z atlasu tekstur jest jak najbardziej sensowne. Ich usunięcie nie tylko uprości implementację, ale też ograniczy liczbę kafli w palecie, więc większa liczba unikalnych kafli będzie jednocześnie widoczna na ekranie, ale też nie będzie się w przyszłości musiał zastanawiać nad tym, czy duplikaty są osobnymi kaflami (np. czy mają różne ID), czy tymi samymi i może brać z palety którykolwiek.
Od usuwania duplikatów są algorytmy kompresji w tym standardowe algorytmy kompresji tekstur. I są znacznie wydajniejsze od takich trywialnych optymalizacji.
Najgorzej by było, gdyby duplikaty były identyczne na ekranie (np. ta sama tekstura czy model), ale miały inne ID (czy inne metadane). Potem edytujesz sobie mapę, chcesz np. usunąć z danego obszaru kafle danego typu i głowisz się dlaczego niektórych kafli nie usuwa. Bajzel w assetach przyczyni się do rwania włosów z głowy i tracienia czasu na szukanie problemu tam, gdzie go w ogóle nie powinno być.
Pamięć GPU/CPU jest kompresowana, to o czym mówisz to bełkot. Narzut kompresji/dekompresji jest pomijalny (zwłaszcza w przypadku GPU które mają specjalizowane bloki od tego)
Ten cytat „Premature optimisation is a root of all evil” ma zastosowanie tylko w niektórych przypadkach, w tym przypadku nie ma. Zresztą często jest po prostu szkodliwy, bo kod należy pisać od razu dobrze, tak aby był prosty, czytelny i wydajny.
Python jest prosty, zazwyczaj czytelny, mało kiedy wydajny. W C jest na odwrót ale obecnie z uwagi na koniec przyrostu wydajności wracamy do kodu który może nie jest przyjemny dla oka ale jest wydajny (Rust)
To samo dotyczy mikro-optymalizacji, tak bardzo deprecjonowanych przez ogół. Piszesz kod danego elementu w sposób optymalny, dzięki czemu zyskujesz np. 200ns wydajności. Mało, prawda? Tak i nie, bo ignorujesz efekt skali i efekt kuli śnieżnej. W projekcie możesz używać nawet tysięcy tych elementów, których ten mikro-zoptymalizowany kod może być używany tysiące razy, na potrzeby generowania dziesiątek klatek gry w każdej sekundzie. I tak Twoja mikro-optymalizacja powoduje wzrost zysku czasu CPU z deprecjonowanych 200ns do setek mikrosekund czy całych milisekund, a to przekłada się na zauważalnie wyższy framerate. A im wyższy framerate czy po prostu mniejsze zapotrzebowanie na czas CPU, to stabilniej działający system, niższe zużycie energii elektrycznej i wsparcie szerszego wachlarzu konfiguracji sprzętowych.
Mikrooptymalizacja ma sens kiedy pisesz pod konkretny spec-kit. Ma to sens przy eksach na konsolach, praktycznie nigdy na mobile i PC i innych multiplatformach.
To nie jest optymalizacja, a obfuskacja, antywzorzec. Nigdy nie używa się duplikatów — zawsze jeden unikalny obiekt (tekstura, model itd.) posiadają tylko jedną instancję w pamięci i wszędzie używa się referencji do tej jednej, unikalnej instancji.
Gdyby tak było to w Javie pisalibyśmy gry. Kiedyś tak było na mobile ale nawet tam to się nie przyjęło.
2
Pokaż mi więc większą grę, stworzoną przez kogoś z głową na karku, która wykorzystuje atlasy z wielokrotnie zduplikowanymi teksturami, albo grę 3D z wielokrotnie zduplikowanymi modelami.
Oczywiście, że to o czym piszesz to kompletne bzdury, niezgodne z jakimikolwiek prawidłowymi technikami wytwarzania gier (a nawet z durnym DRY!). Nigdy nie używa się duplikatów, ani tekstur, ani modeli, bo nie ma to absolutnie żadnego sensu — nie tylko utrudnia to pracę z mapami, ale i podnosi ogólną zasobożerność, co jest absolutnie nie wskazane. Używanie duplikatów jest oznaką braku skilla i niedbałości — niczym więcej.
Widziałeś w ogóle kiedyś jak tworzy się mapy w profesjonalnych grach, w tym w 3D? Najwyraźniej nie, bo byś wiedział, że nie używa się duplikatów ani w przypadku tekstur, ani modeli. Każdy model istnieje jako jeden w pamięci (np. jedna struktura danych meshu), a silnik używa jej instancji/referencji, określających co najwyżej jej unikalne ID, rotację, skalę, flip, dane modulacji itp. Twórcy tak bardzo kombinują, że jeden model drzewa używają w tysiącach miejsc na mapie, w różnej skali i rotacji, a nawet używają tego samego modelu drzewa do tworzenia krzewów czy wyższej trawy (chowając większą część modelu pod powierzchnią gruntu). Niejeden mógł to zauważyć, kiedy z powodu glitchy wpadł pod mapę, a tam drzewa pod spodem, jak góry lodowe.
Gdyby to co piszesz, czyli używanie duplikatów miało sens, to żadna gra AAA nie miałaby prawa działać na żadnym sprzęcie, bo ani nie byłoby na to mocy obliczeniowej, ani wystarczającej ilości pamięci. Doinformuj się najpierw, zanim zaczniesz proponować komukolwiek, aby robił lipę.
To co pokazał OP, czyli paletę obiektów:
powinno być zrealizowane w taki sposób, aby każdy rodzaj kafla był unikalny, czyli aby identyczne kafle zawsze opisane były jedną paczką danych (ID oraz dodatkowe dane). Duplikaty mogą istnieć, ale tylko w palecie i wyłącznie po to, aby wygodniej dało się z takiej palety korzystać, wyklikując zawartość mapy.
0
flowCRANE napisał(a):
Widziałeś w ogóle kiedyś jak tworzy się mapy w profesjonalnych grach, w tym w 3D? Najwyraźniej nie, bo byś wiedział, że nie używa się duplikatów ani w przypadku tekstur, ani modeli. Każdy model istnieje jako jeden w pamięci (np. jedna struktura danych meshu), a silnik używa jej instancji/referencji, określających co najwyżej jej unikalne ID, rotację, skalę, flip, dane modulacji itp.
To że atlasy używają deduplikacji to jedna rzecz - zaszłość z dawnych czasów kiedy CPU były wolne a każda operacja dostępu do tekstury wymagała jego zaangażowania poprzez operacją kopiowania CPU mem -> GPU mem. Unikanie duplikacji pozwalało na obejście wolnego gardła. Tak było jeszcze w API DX11. W konsolach mogło być inaczej poprzez współdzieloną pamięć ale oni z kolei długo byli ograniczeni zafiksowanym rozmiarem nośnika danych - a i tutaj stosowało się często duplikację w celu zminimalizowania np. opóźnień dostępu przy wczytywaniu tekstur. To wie każdy kto kiedykolwiek robił repaki ;)
Dziś w czasach DX12/Vulkan kiedy API pozwalają GPU na swobodny dostęp do pamięci (ReBAR w przypadku PC) takie bzdety mijają się z celem bo przestrzeń jest tania, narzuty I/O są niskie a głównym problemem jest moc obliczeniowa i kompilacja szaderów w locie. Ale silniki muszą jeszcze uwzględniać starsze API + ich modernizacja jest wolna.
Myślisz że dlaczego taki Unreal cierpi obecnie na stuttering a nie mam problemów ze strumieniowaniem tekstur? Albo dlaczego taki Uncharted 4 lecący praktycznie na baked lightning (duplikacja tekstur z wypalonym oświetleniem) wygląda tak świetnie vs obecne technologiczne potworki (dynamiczne oświetlenie na tych samych teksturach)?
Zamiast pisać o bełkocie lepiej podnieś swoją wiedzę bo inaczej jakiś nowy pryszczaty po studiach cię wyśmieje na interview.
0
loza_prowizoryczna napisał(a):
Albo dlaczego taki Uncharted 4 lecący praktycznie na baked lightning (duplikacja tekstur z wypalonym oświetleniem) wygląda tak świetnie vs obecne technologiczne potworki (dynamiczne oświetlenie na tych samych teksturach)?
OP nie używa zduplikowanych tekstur, aby wypalać oświetlenie — jego silnik w ogóle nie obsługuje oświetlenia, a więc nie ma żadnego powodu, aby korzystać ze zduplikowanych tekstur. Tak więc cały Twój wywód jest nie na temat, nie ma żadnego zastosowania w przypadku omawianego w tym wątku projektu i wprowadza niepotrzebne zamieszanie.
Jeśli „taki Uncharted 4 leci praktycznie na baked lightning” to nie posiada duplikatów, bo wypalenie oświetlenia na kopii tekstury powoduje, że ma inną zawartość niż tekstura źródłowa. Zasięgnij słownika, jeśli masz problem ze zrozumieniem tego czym jest duplikat, zamiast uciekać się do manipulacji.
0
flowCRANE napisał(a):
OP nie używa zduplikowanych tekstur, aby wypalać oświetlenie — jego silnik w ogóle nie obsługuje oświetlenia, a więc nie ma żadnego powodu, aby korzystać ze zduplikowanych tekstur. Tak więc cały Twój wywód jest nie na temat, nie ma żadnego zastosowania w przypadku omawianego w tym wątku projektu i wprowadza niepotrzebne zamieszanie.
Dobra, widzę że trzeba prościej. Masz prostą scenę korytarzową. Trzy ściany używają tej samej tekstury. Sufit jest pokryty inną. Co będzie szybsze:
- pętla iterująca 3 razy po tej same tekturze i bindująca do geometrii
- zduplikowanie tej samej tekstury w pamięci i niezależny binding?
To powie mi wystarczająco na temat czy rozumiesz jak działają nowoczesne GPU i pipeline'y. No chyba że autor tworzy renderer GPU-agnostic (software'owy) ale tylko nigdzie tego nie ma.
Jeśli „taki Uncharted 4 leci praktycznie na baked lightning” to nie posiada duplikatów, bo wypalenie oświetlenia na kopii tekstury powoduje, że ma inną zawartość niż tekstura źródłowa. Zasięgnij słownika, jeśli masz problem ze zrozumieniem tego czym jest duplikat, zamiast uciekać się do manipulacji.
Ok, czyli operacja Tz * Tl = Tw (gdzie Tz - tekstura źródłowa, Tl - oświetlenie, Tw - wynik) wykonana dynamicznie przez shader na GPU na zdeduplikowanyn Tz to duplikat a to samo zaczytane z assetów to już nie? Bo wynik ten sam, tylko narzut inny.
1
Nadal nie rozumiesz, że nowoczesne ficzery GPU nie mają w tym przypadku żadnego znaczenia, bo OP zwyczajnie renderuje prostokątne kafelki na płaszczyźnie (teksturze), bez jakichkolwiek wyszukanych algorytmów — w końcu to projekt dla zabawy, nie Uncharted 4. Poza tym do renderowania wykorzystuje SFML, czyli wysokopoziomowe wrappery na API drivera graficznego, które w ogóle nie daje mu możliwości używania wspomnianych przez Ciebie ficzerów, więc pisanie o nich w kontekście tego wątku/projektu nie ma absolutnie żadnego sensu.
Natomiast do tego, aby nie marnować zasobów i czasu CPU/GPU, służy GPU instancing. Poczytaj sobie.
0
flowCRANE napisał(a):
Sam sobie zaprzeczasz
Nadal nie rozumiesz, że nowoczesne ficzery GPU nie mają w tym przypadku żadnego znaczenia, bo OP zwyczajnie renderuje prostokątne kafelki na płaszczyźnie (teksturze), bez jakichkolwiek wyszukanych algorytmów
vs
Poza tym do renderowania wykorzystuje SFML, czyli wysokopoziomowe wrappery na API drivera graficznego, które w ogóle nie daje mu możliwości używania wspomnianych przez Ciebie ficzerów
Gdzie
Tyle że usunięcie duplikatów z atlasu tekstur jest jak najbardziej sensowne. Ich usunięcie nie tylko uprości implementację, ale też ograniczy liczbę kafli w palecie, więc większa liczba unikalnych kafli będzie jednocześnie widoczna na ekranie, ale też nie będzie się w przyszłości musiał zastanawiać nad tym, czy duplikaty są osobnymi kaflami (np. czy mają różne ID), czy tymi samymi i może brać z palety którykolwiek.
Czyli innym słowy mówiąc - optymalizujemy na poziomie abstrakcji API drivera tylko po to żeby niskopoziomowe API to zdeoptymalizowało. Wybacz ale to wygląda trochę jak tweakowanie zapytania SQL pod quirki konkretnego silnika DB.
Natomiast do tego, aby nie marnować zasobów i czasu CPU/GPU, służy GPU instancing. Poczytaj sobie.
Jedyne co znalazłem to odnośniki do dokumentacji Unity. Rozmawiamy teraz w kontekście Unity?
0
Pisałem wcześniej, że OP nie powinien używać duplikatów, bo ich nie potrzebuje — a jeśli się czegoś nie potrzebuje, to się to usuwa. Nie ma znaczenia czego to dotyczy.
loza_prowizoryczna napisał(a):
Czyli innym słowy mówiąc - optymalizujemy na poziomie abstrakcji API drivera tylko po to żeby niskopoziomowe API to zdeoptymalizowało.
Nie, nie optymalizujemy niczego — po prostu usuwamy zbędne rzeczy z projektu, aby zawierał mniej elementów, a więc aby mieć mniej na głowie i łatwiej ogarniać ten projekt.
Jedyne co znalazłem to odnośniki do dokumentacji Unity. Rozmawiamy teraz w kontekście Unity?
Czas nauczyć się używać wyszukiwarki.
- https://www.google.com/search?q=gpu+instancing+direct3d
- https://www.google.com/search?q=gpu+instancing+opengl
- https://www.google.com/search?q=gpu+instancing+vulkan
- https://www.google.com/search?q=gpu+instancing+metal
Przy okazji znajdziesz odpowiedź na temat podanego przez Ciebie wcześniej problemu korytarzowego.
0
flowCRANE napisał(a):
Pisałem wcześniej, że OP nie powinien używać duplikatów, bo ich nie potrzebuje — a jeśli się czegoś nie potrzebuje, to się to usuwa. Nie ma znaczenia czego to dotyczy.
Przecież to się powinno robić automatycznie na etapie post procesu w przy release buildzie a nie na etapie projektu. Wciąż premature optimisation
loza_prowizoryczna napisał(a):
Nie, nie optymalizujemy niczego — po prostu usuwamy zbędne rzeczy z projektu, aby zawierał mniej elementów, a więc aby mieć mniej na głowie i łatwiej ogarniać ten projekt.
To samo mówili jak Java wprowadziła że wszystko jest Obiektem co miało ułatwić optymalizację. Wyszło tak że może i optymalizację ułatwiło ale pisanie w tym wydajnych wielowątkowych aplikacji to sado-maso dla dinozaurów przed emeryturą.
Deduplikacja odbywa się zawsze kosztem późniejszej reduplikacji (funkcje generyczne vs inlining) więc coś co wydaje się być zyskiem na początku dobija później kiedy kompleksowość projektu rośnie a reduplikacja wprowadza dziwne bugi widoczne dopiero w buildzie releasowym.
Jedyne co znalazłem to odnośniki do dokumentacji Unity. Rozmawiamy teraz w kontekście Unity?
Czas nauczyć się używać wyszukiwarki.
To zwraca wyniki dla D3D11
To zwraca wynik ale OpenGL jest starym API
To mi się podoba
Przy okazji znajdziesz odpowiedź na temat podanego przez Ciebie wcześniej problemu korytarzowego.
Ja znam odpowiedź, a ty nie odpowiedziałeś w sposób własny więc zakładam że nie rozumiesz problemu o którym rozmawiamy. Clou mojego zapytania dotyczyło tego czy szybciej jest iterować czy operować na zrównoleglonym batchu. GPU instancing odpowiada że to to drugie. Więc pod spodem zachodzi duplikacja.
1
loza_prowizoryczna napisał(a):
Ja znam odpowiedź, a ty nie odpowiedziałeś w sposób własny więc zakładam że nie rozumiesz problemu o którym rozmawiamy.
Problem, o którym rozmawiamy to projekt @tBane i niepotrzebnie zduplikowane assety. Wiem o czym rozmawiamy, bo przeczytałem ze zrozumieniem wszystkie posty OP, a ponieważ czytałem wszystkie wątki tego użytkownika, które dotyczą jego projektu gry, mam wystarczającą wiedzę na temat tego, jak jego gra jest zaimplementowana i jak działa, a także jakie ma ograniczenia, zarówno dotyczące jego silnika, jak i używanego API multimedialnego.
Ty natomiast piszesz o jakichś ogółach, nie mających absolutnie nic wspólnego z poruszanym w tym wątku projektem gry, a nawet o rzeczach, których nie da się w nim zaimplementować, ze względu na ograniczenia API i kompletnie inny rodzaj silnika. Nie jesteś pierwszym, który wbija do losowego wątku, zaczyna rzucać na lewo i prawo buzzwordami i masturbuje swoje ego przechwalając się (domniemaną) znajomością złożonych zagadnień, kompletnie ignorując tematykę wątku i szczególny przypadek w nim poruszany. Czyli w skrócie pisząc — ciągniesz off-topic.
Sugeruję więc, abyś przestał ciągnąć off-top i albo zaczął się wypowiadać na temat, albo przestał pisać w tym wątku i poszukał atencji gdzieś indziej.
0
flowCRANE napisał(a):
Problem, o którym rozmawiamy to projekt @tBane i niepotrzebnie zduplikowane assety.
O tym właśnie jest dyskusja.
Wiem o czym rozmawiamy, bo przeczytałem ze zrozumieniem wszystkie posty OP, a ponieważ czytałem wszystkie wątki tego użytkownika, które dotyczą jego projektu gry, mam wystarczającą wiedzę na temat tego, jak jego gra jest zaimplementowana i jak działa, a także jakie ma ograniczenia, zarówno dotyczące jego silnika, jak i używanego API multimedialnego.
To zaczniesz w końcu odpowiadać na zadawane pytania a nie opisywać swój feeling na temat swoich wypowiedzi? Bo jeśli wiesz wszystko i przeszkadzają ci inne posty to czemu nie przeniesiecie się na PW?
Ty natomiast piszesz o jakichś ogółach, nie mających absolutnie nic wspólnego z poruszanym w tym wątku projektem gry, a nawet o rzeczach, których nie da się w nim zaimplementować, ze względu na ograniczenia API i kompletnie inny rodzaj silnika. Nie jesteś pierwszym, który wbija do losowego wątku, zaczyna rzucać na lewo i prawo buzzwordami i masturbuje swoje ego przechwalając się (domniemaną) znajomością złożonych zagadnień, kompletnie ignorując tematykę wątku i szczególny przypadek w nim poruszany. Czyli w skrócie pisząc — ciągniesz off-topic.
Tematyka powinna być zawarta w poście OPa. Jeśli ważny jest kontekst to fajnie byłoby zalinkować żeby zaoszczędzić innym czas, ad-personam pominę bo tu nie o czym dyskutować
Sugeruję więc, abyś przestał ciągnąć off-top i albo zaczął się wypowiadać na temat, albo przestał pisać w tym wątku i poszukał atencji gdzieś indziej.
Cały czas czekam na odpowiedzi na swoje pytania (ważne) a jedyne co dostaje to erystykę z groźbami i ad-personam. To jest poziom?
0
loza_prowizoryczna napisał(a):
To zaczniesz w końcu odpowiadać na zadawane pytania a nie opisywać swój feeling na temat swoich wypowiedzi?
Odpowiedziałem na pytania wszystkie zadane przez @tBane — nowych na razie nie zadał.
Cały czas czekam na odpowiedzi na swoje pytania (ważne) a jedyne co dostaje to erystykę z groźbami i ad-personam. To jest poziom?
Twoje pytania nie są ważne, bo po pierwsze to nie jest Twój wątek, a po drugie, nie dotyczą one projektu omawianego w tym wątku. Tak więc ciągniesz off-topic w postach, dlatego jako moderator upomniałem Cię, abyś przestał to robić — do off-topu służą komentarze, nie posty. Sam jesteś sobie winny, więc skończ ze śmieceniem wątku i z blame-shiftingiem przy okazji.
To ostatnie ostrzeżenie — kolejne posty niezwiązane z tematem tego wątku będą usuwane.