Silniki 19808 50

O temacie

Autor Sawik

Zaczęty 30.03.2015 roku

Wyświetleń 19808

Odpowiedzi 50

Sawik

Sawik

Użytkownicy
Rebel
posty4791
Propsy3193
ProfesjaNierób
  • Użytkownicy
  • Rebel

Sawik

Silniki
2015-03-30, 22:26(Ostatnia zmiana: 2016-11-24, 20:54)
No więc taki luźny temacik do wrzucania silników zbyt mało popularnych żeby osobny temat miał sens (patrz ten silniczek od Pagana)
Paradox Game Engine
https://www.youtube.com/watch?v=5gHKp9t4lms


Zdaje mi się że próbuje udawać Unity, jak będę w domu mam zamiar dłużej się nim pobawić, głównie chodzi mi o sprawdzenie build'a, bo nawet małe gry na Unity ważą więcej niż mogłyby. (chyba że ktoś zna jakiś lekki silniczek).
 
Życzę wam seksu analnego po stronie biernej.
Dropbox +500 mb na start
LowPoly
Wykonanie modelu niskopoligonowego to sztuka kompromisu. Nie jest to jedynie uproszczenie modelu wysokopoligonowego, ale głęboka modyfikacja oraz podejmowanie decyzji często zmieniających wygląd pierwotny obiektu, tak by przy najmniejszej ilości trójkątów uzyskać jak najwierniej odwzorowany kształt oryginału. Nie można też zapomnieć o tym iż musi nadal wyglądać przekonywająco i tak balansować by uzyskać efekt optymalny.

Podstawowym założeniem jest, że model nie powinien mieć zbędnych, niewidocznych dla gracza detali włączonych w geometrie. Większość obiektów jakie znajdują się w grze powinna prezentować się najlepiej z odległości około 3-5 metrów. Wszelkie detale, które zanikają, wydają się płaskie lub zlewają się z bryłą modelu należy uznać za zbędne i pozostawić je na normal mapie.

Fakt, iż gracz będzie w stanie podejść bliżej do obiektu i zobaczyć go z mniejszej niż 3m odległości nie powinno stanowić większego problemu, gdyż większą rolę odgrywają wtedy tekstury oraz dodatkowy detal zależny od materiału obiektu. To właśnie kompromis między wydajnością, a szczegółowością otoczenia.

Detal, którego nie widać z 3-5 metrów nie powinnien istnieć w geometrii modelu.
Krawędzie znajdujące się blisko siebie, które zlewają się z większej odległości należy uprościć do wspólnej płaszczyzny

inż. Avallach

inż. Avallach

Administrator
posty7706
Propsy5229
NagrodyV
ProfesjaProgramista
  • Administrator
Rzeczywiście pod wieloma względami "zrzyna" z Unity :D
Skrypty w C#, budowanie z jednego źródła na wszystkie główne platformy, shadery w HLSL itd. 
Ale i pod wieloma względami wyprzedza Unity - jest CAŁY w C# (Unity jest w C++, tylko kod tworzonej gry jest w C#) i otwartoźródłowy. Nie wiem jak to się odbija na wydajności, ale na nie-mobilnych platformach nie powinno być dużym problemem. Za to dzięki temu można lepiej integrować grę z silnikiem (nie polegając w całości na API).

Sawik, ani gry na Unity, ani na tym nie będą tak łatwo ważyć mniej. Razem z nimi dołączasz całego .NET Frameworka. On waży swoje pare mb (sprawdź rozmiar plików w paczce i wszystko będzie jasne). Można wycinać z niego niepotrzebne części przy budowaniu, ale do tego potrzeba Unity Pro. Ewentualnie mógłbyś próbować podmienić libkę z nim na samodzielnie wykrojoną (tylko czym? jakieś narzędzia chyba do czegoś takiego są, ale ja ich nie znam).

Sawik

Sawik

Użytkownicy
Rebel
posty4791
Propsy3193
ProfesjaNierób
  • Użytkownicy
  • Rebel
Sawik, ani gry na Unity, ani na tym nie będą tak łatwo ważyć mniej. Razem z nimi dołączasz całego .NET Frameworka. On waży swoje pare mb (sprawdź rozmiar plików w paczce i wszystko będzie jasne). Można wycinać z niego niepotrzebne części przy budowaniu, ale do tego potrzeba Unity Pro. Ewentualnie mógłbyś próbować podmienić libkę z nim na samodzielnie wykrojoną (tylko czym? jakieś narzędzia chyba do czegoś takiego są, ale ja ich nie znam).
To w sumie lipa, bo ostatnio naszło mnie na pisanie prostych gierek np. kółko i krzyżyk, trzy graficzki, parę kb kodu, a bulid około 50mb. 
Nie chciałbym zmieniać całkiem języka, ale robienie takich minigierek na PC jest strasznie nieopłacalne na Unity ze względu na masywną paczkę.
 
Życzę wam seksu analnego po stronie biernej.
Dropbox +500 mb na start
LowPoly
Wykonanie modelu niskopoligonowego to sztuka kompromisu. Nie jest to jedynie uproszczenie modelu wysokopoligonowego, ale głęboka modyfikacja oraz podejmowanie decyzji często zmieniających wygląd pierwotny obiektu, tak by przy najmniejszej ilości trójkątów uzyskać jak najwierniej odwzorowany kształt oryginału. Nie można też zapomnieć o tym iż musi nadal wyglądać przekonywająco i tak balansować by uzyskać efekt optymalny.

Podstawowym założeniem jest, że model nie powinien mieć zbędnych, niewidocznych dla gracza detali włączonych w geometrie. Większość obiektów jakie znajdują się w grze powinna prezentować się najlepiej z odległości około 3-5 metrów. Wszelkie detale, które zanikają, wydają się płaskie lub zlewają się z bryłą modelu należy uznać za zbędne i pozostawić je na normal mapie.

Fakt, iż gracz będzie w stanie podejść bliżej do obiektu i zobaczyć go z mniejszej niż 3m odległości nie powinno stanowić większego problemu, gdyż większą rolę odgrywają wtedy tekstury oraz dodatkowy detal zależny od materiału obiektu. To właśnie kompromis między wydajnością, a szczegółowością otoczenia.

Detal, którego nie widać z 3-5 metrów nie powinnien istnieć w geometrii modelu.
Krawędzie znajdujące się blisko siebie, które zlewają się z większej odległości należy uprościć do wspólnej płaszczyzny

inż. Avallach

inż. Avallach

Administrator
posty7706
Propsy5229
NagrodyV
ProfesjaProgramista
  • Administrator
No chyba żartujesz. Piszę że nie będą tak łatwo ważyć mniej, ale absolutnie nie zgadzam się z tym że są masywne jak na gry PC. Parę mb to prawie nic przy obecnych łączach internetowych. Bez problemu streamuje się je w przeglądarce. Trochę teraz gwiazdorzysz.

Jeszcze co do tego Paradoxa - ani mi się śni przerzucać z Unity, ale fajnie że ktoś robi im konkurencję i pokazuje ciekawe kierunki rozwoju :D

Sawik

Sawik

Użytkownicy
Rebel
posty4791
Propsy3193
ProfesjaNierób
  • Użytkownicy
  • Rebel
50mb na kółko i krzyżyk jest ok? :| 
 
Życzę wam seksu analnego po stronie biernej.
Dropbox +500 mb na start
LowPoly
Wykonanie modelu niskopoligonowego to sztuka kompromisu. Nie jest to jedynie uproszczenie modelu wysokopoligonowego, ale głęboka modyfikacja oraz podejmowanie decyzji często zmieniających wygląd pierwotny obiektu, tak by przy najmniejszej ilości trójkątów uzyskać jak najwierniej odwzorowany kształt oryginału. Nie można też zapomnieć o tym iż musi nadal wyglądać przekonywająco i tak balansować by uzyskać efekt optymalny.

Podstawowym założeniem jest, że model nie powinien mieć zbędnych, niewidocznych dla gracza detali włączonych w geometrie. Większość obiektów jakie znajdują się w grze powinna prezentować się najlepiej z odległości około 3-5 metrów. Wszelkie detale, które zanikają, wydają się płaskie lub zlewają się z bryłą modelu należy uznać za zbędne i pozostawić je na normal mapie.

Fakt, iż gracz będzie w stanie podejść bliżej do obiektu i zobaczyć go z mniejszej niż 3m odległości nie powinno stanowić większego problemu, gdyż większą rolę odgrywają wtedy tekstury oraz dodatkowy detal zależny od materiału obiektu. To właśnie kompromis między wydajnością, a szczegółowością otoczenia.

Detal, którego nie widać z 3-5 metrów nie powinnien istnieć w geometrii modelu.
Krawędzie znajdujące się blisko siebie, które zlewają się z większej odległości należy uprościć do wspólnej płaszczyzny

inż. Avallach

inż. Avallach

Administrator
posty7706
Propsy5229
NagrodyV
ProfesjaProgramista
  • Administrator
Coś ostro zjebałeś. Mój dużo większy projekt ma łącznie 30mb. Z czego biblioteki frameworkowe o których pisałem że do okrojenia ich potrzeba Unity Pro albo zastosowania jakiegoś własnego narzędzia, mają łącznie parę mb (parę to dla mnie więcej niż 1, ale mniej niż 10). Parę, nie kilkadziesiąt.
Razem z nimi dołączasz całego .NET Frameworka. On waży swoje parę mb (sprawdź rozmiar plików w paczce i wszystko będzie jasne).

Sawik

Sawik

Użytkownicy
Rebel
posty4791
Propsy3193
ProfesjaNierób
  • Użytkownicy
  • Rebel

Sawik

Silniki
#6 2015-03-31, 23:09(Ostatnia zmiana: 2015-03-31, 23:17)
Właśnie dlatego się zdziwiłem, już w poprzedniej wiadomości napisałem że waży ponad pięćdziesiąt megabajtów.
W sumie to mi chyba przyszło do głowy czemu - skybox.
Po usunięciu go spadło o do 47mb.
Po odznaczeniu "development bulid" - spadło o kolejne 5mb.
Zrobiłem prosty test i utworzyłem nowy projekt, usunąłem wszystko i zrobiłem build - 25mb.

EDIT:
Wpadło mi do głowy jeszcze jedno, zmieniłem compatybility mode z .NET subset na .NET i nagle zrobiło się 12.5mb z czym już mogę żyć :ok:
 
Życzę wam seksu analnego po stronie biernej.
Dropbox +500 mb na start
LowPoly
Wykonanie modelu niskopoligonowego to sztuka kompromisu. Nie jest to jedynie uproszczenie modelu wysokopoligonowego, ale głęboka modyfikacja oraz podejmowanie decyzji często zmieniających wygląd pierwotny obiektu, tak by przy najmniejszej ilości trójkątów uzyskać jak najwierniej odwzorowany kształt oryginału. Nie można też zapomnieć o tym iż musi nadal wyglądać przekonywająco i tak balansować by uzyskać efekt optymalny.

Podstawowym założeniem jest, że model nie powinien mieć zbędnych, niewidocznych dla gracza detali włączonych w geometrie. Większość obiektów jakie znajdują się w grze powinna prezentować się najlepiej z odległości około 3-5 metrów. Wszelkie detale, które zanikają, wydają się płaskie lub zlewają się z bryłą modelu należy uznać za zbędne i pozostawić je na normal mapie.

Fakt, iż gracz będzie w stanie podejść bliżej do obiektu i zobaczyć go z mniejszej niż 3m odległości nie powinno stanowić większego problemu, gdyż większą rolę odgrywają wtedy tekstury oraz dodatkowy detal zależny od materiału obiektu. To właśnie kompromis między wydajnością, a szczegółowością otoczenia.

Detal, którego nie widać z 3-5 metrów nie powinnien istnieć w geometrii modelu.
Krawędzie znajdujące się blisko siebie, które zlewają się z większej odległości należy uprościć do wspólnej płaszczyzny


wietrzyk

wietrzyk

Użytkownicy
Black Eye Games
posty440
Propsy390
ProfesjaGrafik 3D
  • Użytkownicy
  • Black Eye Games
Właśnie dlatego się zdziwiłem, już w poprzedniej wiadomości napisałem że waży ponad pięćdziesiąt megabajtów.
W sumie to mi chyba przyszło do głowy czemu - skybox.
Po usunięciu go spadło o do 47mb.
Po odznaczeniu "development bulid" - spadło o kolejne 5mb.
Zrobiłem prosty test i utworzyłem nowy projekt, usunąłem wszystko i zrobiłem build - 25mb.

EDIT:
Wpadło mi do głowy jeszcze jedno, zmieniłem compatybility mode z .NET subset na .NET i nagle zrobiło się 12.5mb z czym już mogę żyć :ok:
Jeśli chcesz dalej się pobawić w minimalizacje buildów gry to poczytaj to:
http://docs.unity3d.com/Manual/ReducingFilesize.html
 

mgr Fartuess

mgr Fartuess

Użytkownicy
Kiedyś to były czasy!
posty1486
Propsy890
ProfesjaProgramista
  • Użytkownicy
  • Kiedyś to były czasy!
Ale i pod wieloma względami wyprzedza Unity - jest CAŁY w C# (Unity jest w C++, tylko kod tworzonej gry jest w C#)
To chyba Unity wyprzedza C#. C++ jest lepszy do pisania silników.
 
Popisuje się ciągle menda jedna...

Sawik

Sawik

Użytkownicy
Rebel
posty4791
Propsy3193
ProfesjaNierób
  • Użytkownicy
  • Rebel
Jeśli chcesz dalej się pobawić w minimalizacje buildów gry to poczytaj to:
http://docs.unity3d.com/Manual/ReducingFilesize.html
Dzięki, ale akurat z dokumentacją Unity jestem znajomy, to było pierwsze miejsce w które się udałem po zobaczeniu wagi projektu. Po części dzięki temu build waży coraz mniej.

Fartuess, opensource.

No i to że ma potencjał bycia szybszym, niekoniecznie znaczy że jest lepszym.
 
Życzę wam seksu analnego po stronie biernej.
Dropbox +500 mb na start
LowPoly
Wykonanie modelu niskopoligonowego to sztuka kompromisu. Nie jest to jedynie uproszczenie modelu wysokopoligonowego, ale głęboka modyfikacja oraz podejmowanie decyzji często zmieniających wygląd pierwotny obiektu, tak by przy najmniejszej ilości trójkątów uzyskać jak najwierniej odwzorowany kształt oryginału. Nie można też zapomnieć o tym iż musi nadal wyglądać przekonywająco i tak balansować by uzyskać efekt optymalny.

Podstawowym założeniem jest, że model nie powinien mieć zbędnych, niewidocznych dla gracza detali włączonych w geometrie. Większość obiektów jakie znajdują się w grze powinna prezentować się najlepiej z odległości około 3-5 metrów. Wszelkie detale, które zanikają, wydają się płaskie lub zlewają się z bryłą modelu należy uznać za zbędne i pozostawić je na normal mapie.

Fakt, iż gracz będzie w stanie podejść bliżej do obiektu i zobaczyć go z mniejszej niż 3m odległości nie powinno stanowić większego problemu, gdyż większą rolę odgrywają wtedy tekstury oraz dodatkowy detal zależny od materiału obiektu. To właśnie kompromis między wydajnością, a szczegółowością otoczenia.

Detal, którego nie widać z 3-5 metrów nie powinnien istnieć w geometrii modelu.
Krawędzie znajdujące się blisko siebie, które zlewają się z większej odległości należy uprościć do wspólnej płaszczyzny

inż. Avallach

inż. Avallach

Administrator
posty7706
Propsy5229
NagrodyV
ProfesjaProgramista
  • Administrator

inż. Avallach
Administrator

Silniki
#11 2015-04-01, 10:37(Ostatnia zmiana: 2015-04-01, 10:55)
Ale i pod wieloma względami wyprzedza Unity - jest CAŁY w C# (Unity jest w C++, tylko kod tworzonej gry jest w C#)
To chyba Unity wyprzedza C#. C++ jest lepszy do pisania silników.
Jak napisał Sawik. Nie można mówić że C++ jest "po prostu lepszy". C++ ma swoje zalety. Główną z nich jest wydajność. C# jest tu rzeczywiście w tyle. Ale i on ma swoje zalety - kod jest prostszy, bardziej przejrzysty i nie ma potrzeby tworzenia "mostu" pomiędzy kodem silnika w jednym języku, a kodem gry w drugim.

Unity jest od wielu lat tworzone przez bardzo dobry profesjonalny zespół. Ten Paradox wydaje się być bardzo świeży, do tego ma być rozbudowywany na zasadzie projektu open source. Jestem niemal pewien że w C# ma on większe szanse na konkretny udział społeczności w jego rozwoju. Nawet jeśli ze względu na mniejszą wiedzę / doświadczenie hobbystów którzy będą go rozwijali będzie mniej wydajny, to nadal koszt jego stworzenia może być nieporównywalnie niższy.

Aha, jeszcze w sprawie wydajności. To na razie technologia eksperymentalna, ale C# może być kompilowany do kodu natywnego. Kto wie, jeśli ten kompilator zostanie odpowiednio rozwinięty i zoptymalizowany, to może cały silnik napisany w C# będzie dużo bliżej tego pisanego w C++.
https://msdn.microsoft.com/en-us/library/dn584397.aspx
https://msdn.microsoft.com/en-us/library/ht8ecch6(v=vs.90).aspx
http://blogs.msdn.com/b/dotnet/archive/2014/04/02/announcing-net-native-preview.aspx
https://msdn.microsoft.com/en-us/vstudio/dotnetnative
https://csnative.codeplex.com/

mgr Fartuess

mgr Fartuess

Użytkownicy
Kiedyś to były czasy!
posty1486
Propsy890
ProfesjaProgramista
  • Użytkownicy
  • Kiedyś to były czasy!
Jak napisał Sawik. Nie można mówić że C++ jest "po prostu lepszy". C++ ma swoje zalety. Główną z nich jest wydajność. C# jest tu rzeczywiście w tyle. Ale i on ma swoje zalety - kod jest prostszy, bardziej przejrzysty i nie ma potrzeby tworzenia "mostu" pomiędzy kodem silnika w jednym języku, a kodem gry w drugim.
No, ale w silnikach do gier, których mają używać zewnętrzne studia i mają się nadawać do gier high-endowych wydajność jest dużo bardziej istotna niż przejrzystość. Tym bardziej, że most już jest zrobiony i problemu z przejrzystością dla zwykłego usera nie ma. No chyba, że ma grzebać w kodzie silnika, ale wtedy to i tak trzeba już nieźle ogarniać. Nie widzę tu nigdzie tego, że wyprzedza Unity. Powiedziałbym, że jest w tyle i to mocno jeśli chodzi o przystosowanie do high endowych. Do mniejszych projektów to już bez różnicy.

Aha, jeszcze w sprawie wydajności. To na razie technologia eksperymentalna, ale C# może być kompilowany do kodu natywnego. Kto wie, jeśli ten kompilator zostanie odpowiednio rozwinięty i zoptymalizowany, to może cały silnik napisany w C# będzie dużo bliżej tego pisanego w C++.
W połączeniu z unsafe'ami może być naprawdę solidny boost wydajnościowy.
 
Popisuje się ciągle menda jedna...


Kazzmir

Kazzmir

O.D.A.L.
posty1003
Propsy1681
ProfesjaProducent
  • O.D.A.L.
to jest rekomendacja czy tylko info?
 
rekrutacja O.D.A.L, po 18:00 gg:10135138

inż. Avallach

inż. Avallach

Administrator
posty7706
Propsy5229
NagrodyV
ProfesjaProgramista
  • Administrator

inż. Avallach
Administrator

Silniki
#15 2016-02-09, 13:13(Ostatnia zmiana: 2016-02-09, 13:19)
Info, i tak uważam że Unity jest lepsze. Ale fajnie że pojawia się kolejna konkurencja, bo zmusza Unity do pracy nad swoim produktem i walki o klienta.

Z drugiej strony do pewnych typów gier ten silnik Amazona jest bezkonkurencyjny - konkretnie do gier z bardzo dużym naciskiem na multiplayer i interakcje z widzami streamu.

Sama integracja z dostarczaną przez producenta silnika dedykowaną chmurą nie pionierska - przed nimi zdążyło to zaoferować właśnie Unity :D Chociaż niewykluczone że Amazon zaoferuje to samo taniej, pod względem usług chmurowych po prostu rządzi rynkiem. Ten silnik kupili sobie tylko jako dodatek mający je dodatkowo promować.
To jest dosłownie jakby sieć stacji benzynowych zaczeła rozdawać za darmo samochody, które najlepiej tankować u nich.

Kazzmir

Kazzmir

O.D.A.L.
posty1003
Propsy1681
ProfesjaProducent
  • O.D.A.L.
chciałbym trafić na taką stację xD
ściągnąłem, może mi się przyda do testów
 
rekrutacja O.D.A.L, po 18:00 gg:10135138

mgr Fartuess

mgr Fartuess

Użytkownicy
Kiedyś to były czasy!
posty1486
Propsy890
ProfesjaProgramista
  • Użytkownicy
  • Kiedyś to były czasy!
Av uprzedził mnie :P

Sam zamierzam rzucić okiem.

Jak coś to tu link do ich strony: http://aws.amazon.com/lumberyard/downloads/
 
Popisuje się ciągle menda jedna...

Kazzmir

Kazzmir

O.D.A.L.
posty1003
Propsy1681
ProfesjaProducent
  • O.D.A.L.
Av uprzedził mnie :P

Sam zamierzam rzucić okiem.

Jak coś to tu link do ich strony: http://aws.amazon.com/lumberyard/downloads/

no weź, ty będziesz sprawdzał konkurencje? rozumiem że dobrze wiedzieć co się dzieje, ale ty masz swój xD
 
rekrutacja O.D.A.L, po 18:00 gg:10135138

mgr Fartuess

mgr Fartuess

Użytkownicy
Kiedyś to były czasy!
posty1486
Propsy890
ProfesjaProgramista
  • Użytkownicy
  • Kiedyś to były czasy!
No to raczej w ramach sprawdzania użytych rozwiązań. Jakbym miał grę tworzyć to i tak bym najprawdopodobniej wybrał UE4 lub Unity obecnie.
 
Popisuje się ciągle menda jedna...


0 użytkowników i 1 Gość przegląda ten wątek.
0 użytkowników
Do góry