Programowanie grafiki - C++ czy Rust

Hej, od paru miesięcy uczę się OpenGL z użyciem Rusta, piszę własny prosty render. Zacząłem się jednak zastanawiać czy nie wrócić do C++, którego używam w pracy ale nie związanej z grafiką. Chciałbym być może w przyszłości znaleźć pracę jako Graphic/Engine Programmer i się zastanawiam czy uczenie się Rusta z openGL/vulkanem, zamiast maksowania C++ to lepsze rozwiązanie. Problem jest tylko taki, że ja nie mogę zdzierżyć tego C++ :) nie chcę wchodzić w szczegóły ale ten język wraz z Cmake generuje tyle niepotrzebnych problemów...
Podsumowując, jeśli poważnie myślę kiedyś o roli Graphic Programmer to czy Rust w ogóle może mi się przydać? Czy tylko iść w C++?

Póki co C++ wyraźnie dominuje, chociażby z tego względu, że wsparcie Rusta na konsolach jest ciągle znikome jeśli nie zerowe. Problem tu taki, że to są zamknięte systemy, a pisanie gier na nie wymaga podpisania umowy z korporacją i dostania odpowiednich development kitów, co blokuje ludziom od open source rozwijania jakichś alternatyw (patrz opis https://docs.godotengine.org/en/stable/tutorials/platform/consoles.html na stronie Godota gdzie opisują sytuację). Słyszałem, że komuś tam udało się coś skompilować i odpalić, ale generalnie póki co jest się skazanym na C++ czy C# jeżeli ktoś używa Unity.

Nawet zaś pomijając same konsole i ograniczając do PC/mobilnych to generalnie niewiele się dzieje, jeżeli chodzi o użycie Rust w gamedevie. W sieci krąży dowcip, że to język, w którym powstało do tej pory więcej silników niż faktycznych gier. Pomijając jakąś drobnicę z game jamów faktycznie ciężko coś wskazać. Jednym z głośniejszych tytułów to wydane dość niedawno Tiny Glade (https://store.steampowered.com/app/2198150/Tiny_Glade/), mały indyk robiony przez dwie osoby. Pisali to z użyciem Bevy, tyle że napisali własny renderer. Poza tym trudno wskazać cokolwiek, co na tle setek gier w C++/C# jest cokolwiek marnie. Kojarzę, że było jakieś inne indie studio, które eksperymentowało z Rustem, ale chyba też się z czasem wycofali. Oprócz tego parę miesięcy temu dość głośny był post Leaving Rust gamedev after 3 years, który zebrał też sporo komentarzy na HN i r/programming. Generalnie - Rust ma swoje nisze, ale w gamedevie na razie się nie przyjmuje.

Co natomiast będzie za ~5/10 lat to znowu trudno przewidzieć, ale na chwilę obecną C++ w silnikach 3D trzyma się mocno i nigdzie raczej nie wybiera.

Gamedev jest bardzo konserwatywnym środowiskiem. Do tego Rust nie wnosi tak wiele do gamedevu jak w innych branżach. Gamedev nie wymaga takiego poziomu bezpieczeństwa jak przeglądarki/serwery/libki.

Pewnie powoli będzie się coś zmieniało, ale szczerze wątpię, żeby w bliskiej przyszłości zaczeło się coś dziać więcej

@Spearhead Dzięki za fajną kompilacje informacji. @slsy Patrząc na jakość kodu pisanego przez gamedev w C++, nie dziwię się, że branża w kryzysie :) tak pół żartem pół serio. Rust na pewno wniósłby jakość kodu, choc z drugiej strony to chyba silnik jest najważniejszy (Unity ,Unreal czy Godot). Trochę się bawiłem silnikami tymi ale czysto dla zabawy.

Fargo94 napisał(a):

Hej, od paru miesięcy uczę się OpenGL z użyciem Rusta, piszę własny prosty render.
[...]
Chciałbym być może w przyszłości znaleźć pracę jako Graphic/Engine Programmer

Ambitnie. Może moje obawy nie mają odzwierciedlenia w rzeczywistości, jednak moim zdaniem warto przemyśleć tą decyzję.

Jak sobie wyobrażasz taką pracę?

Bo ja sobie wyobrażam, że w firmach rozwijających silniki, które zatrudniają ludzi na takie stanowisko, czekają nietrywialne zadania.
Wszystkie rzeczy, które musi mieć prosty render zostały tam już zaimplementowane.
Na programistów takiego silnika czekają takie zadania:

• dodatkowe, nieznane feature'y,
• optymalizacja istniejącego kodu,
• debugowanie.

Chyba, że trafisz do jakiegoś startup'u, który tworzy nowy silnik od zera.
To wtedy będziesz mógł po swojemu na czysto zrobić lepiej wszystko co jest znane z innych silników.
Praktycznie żadnych niewiadomych. Tylko trzeba dobrze ogarniać duże projekty ;)

Dlaczego piszesz "własny prosty render"?

Pod konkretny projekt, żeby zrobić w swoim silniku grę?
Czy po prostu interesuje Cię jak zbudowane są silniki i to co w swoim silniku wyprodukujesz, to będą raczej demosy pokazujące możliwości Twojego silnika?

@Spine właśnie ciężko mi sobie taką pracę wyobrazić :) obstawiam, że ktoś ma swój silnik i dodaje do niego feature'y albo firma korzysta z UE i trzeba pisać jakieś customowe efekty.

Natomiast pisze własny render na podstawie stronki learnopengl. Czytam rozdział i staram się go zaimplementować u siebie. Wydaje mi się, że to najlepsza metoda na naukę renderingu. Wadą jest to, że muszę często rozwiązywać architektoniczne problemy, które nie są proste np. implementacja systemu ECS czy jakieś matematyczne akrobacje.

Natomiast zaletą taka, że parę linijek i mam efekt graficzny jaki chce bo znam na wylot swój "silnik".

Może jak kiedyś ogarnę dokumentację i fajne demo to się nim pochwałę na mikroblogu.

Odpowiadając jeszcze na Twoje pytanie, interesuje mnie jak silniki działają i chce zrobić demo układu słonecznego, jakąś prostą symulacje. Nie mam ambicji robić tak gry, to wtedy myślę użyje Godota jak mnie najdzie na gierkę.

Fargo94 napisał(a):

Natomiast zaletą taka, że parę linijek i mam efekt graficzny jaki chce bo znam na wylot swój "silnik".

Moim zdaniem efekty graficzne można sprowadzić do kilku standardowych rzeczy, które powinny być w zaimplementowane w silniku lub komponentach z nim dostarczanych.

• Particle System z możliwością przypisania shaderów renderowanych cząsteczek,
• Możliwość przypisania shaderów obiektom 3D,
• Możliwość przypisania shaderów dla renderowanych klatek (postprocessing).

Jak widać, shadery przy renderowaniu są wszechobecne ;)

Z takim zestawem użytkownik osiągnie chyba każdy efekt graficzny.
A czy to będzie łatwe, czy skomplikowane zależy od dodatkowych warstw abstrakcji i presetów dołączonych do silnika.

Właśnie mam problem z customowymi shaderami. Na chwilę obecną nie można ich dodawać bo za dużo logiiki renderowania w nich siedzi. Mam na myśli obliczanie oświetlenia modelem phonga (jeśli jest źródło światła), obsługa tekstur czy kolorów (jeden na obiekt czy per wierzchołek). Wiem, pewnie coś spartaczylem bo śmierdzi mi tu antywzorcem ale nie wiem i nie znalazłem lepsze metody jak do tej pory. Ciężko mi sobie wyobrazić ta swobodna możliwość przypisania shaderow :) skoro jak ktoś doda shaders bez obliczania światła to obiekt wyjdzie poza system oświetlenia i będzie np. czarny obiekt przy lampie.

Obiekty 3D bez oświetlenia też są potrzebne i mogą współistnieć na scenie z oświetlonymi obiektami.
Np. jeśli chcesz zrobić, że oczy postaci świecą jak w Mortal Kombat 11 (kolory HDR + bloom postprocessing), to nie chcesz żeby trójkąty oczu reagowały na lampę w żaden sposób.

W Unity takie shadery nazywają się Unlit:

Jak tworzysz materiał w ShaderGraph w Unity, to też możesz wybrać rodzaj materiału Unlit:

proponuję poznać jakiś istniejący silnik w bardzo dobrym stopniu od strony użytkownika przed zabieraniem się do implementacji własnego

@obscurity To taki lekki silnik jak Godot byłby okey? Nie wiem czy chce startować do takich kobył jak Unity czy UE

Nie używałem Godot, więc nie mogę go ocenić.
Moim zdaniem jest duża szansa, że silnik używany przez większość programistów jest przyjazny dla początkujących:

Próbowałem Unreal. Unity moim zdaniem jest znacznie bardziej user-friendly.
Nie musisz od razu ogarnąć całego silnika, a Unity sprytnie ukrywa rzeczy, których dany obiekt nie używa, poprzez system komponentów.

MS Word to też kobyła, a nie musisz ogarniać jego wszystkich funkcji, żeby napisać w nim jakiś tekst ;)

Jeśli piszesz sobie własny renderer, żeby nauczyć się grafiki, to wybierz sobie taki język, w którym ci się najwygodniej pisze. Nie ma znaczenia, czy to będzie C++, Rust czy JavaScript.

Fargo94 napisał(a):

Prawda ale bardziej mi zależy na nauce opengl/vulkan. Silnik jest efektem ubocznym tej nauki. No ale zgadzam się, pewnie byłoby o wiele łatwiej.

Będzie ci się łatwiej uczyć i nie będziesz ciągle odkrywał koła na nowo jeśli najpierw poużywasz czegoś podobnego; tworząc coś samemu bez zapoznania się dobrze z tematem ciężko w ogóle natrafić na problemy do rozwiązania. Poza tym może się okazać że jest wystarczająco wiele wyzwań na wyższym poziomie i nie musisz schodzić aż tak nisko, bo szczerze mówiąc nie wróżę dużych sukcesów w szukaniu pracy na tak niskim poziomie.
Kiedyś lata (w wolnym czasie) poświęciłem pisząc własny silnik, ale praca z directx mi nie wystarczyła i zszedłem tak nisko że czytałem artykuły jak w ogóle działa rasteryzacja, teselacja, nakładanie tekstur, cieniowanie na najniższym poziomie, z ciekawości zaprogramowałem oteksturowaną i oświetloną scenę 3d działając jedynie na pikselach na cpu. I szczerze mówiąc to do niczego mi się to nie przydało. Ciekawość zaspokojona ale straciłem sporo cennego czasu.

W unity możesz programować np własny custom rendering pipeline i to już jest wystarczające moim zdaniem wyzwanie.
Jak już liźniesz podstaw to proponuję przejść na wyższy poziom, na coś co faktycznie będzie użyteczne w pracy, bo tylko szaleńcy piszą grę na własnym silniku (chyba że to tetris...)