Kerbal Space Program Forum | Polska Społeczność Gry
Off-topic => Dyskusje na dowolne tematy => Wątek zaczęty przez: Kadaf w Czw, 10 Gru 2015, 01:16:02
-
Space Engineers, Elite Dangerous i kilku innych twórców gier zrobiło ostatnio lądowania na planetach. Planety wyglądają mniej lub bardziej dobrze, ale wszystkie bez wyjątku wyprzedzają te z KSP o eony.
I teraz pytanie do tych z was mam, którzy cokolwiek się znają na Unity. Bo może narzekam na jakość planet zupełnie bezpodstawnie, może prawda jest taka, że na Unity nie ma możliwości zrobienia ładnych, zróżnicowanych powierzchni. Jak to jest? Z chęcią zobaczyłbym nie tylko wypowiedzi tych, którzy wiedzą coś na temat możliwości silnika, ale również jakieś może przykładowe filmiki z prezentacjami co można wyciągnąć z U5. Bo może to kompletny szajs i nie da się na nim zrobić nic. Mod scatterer ostatnio prezentowany na forum zdaje się nie potwierdzać tej tezy. Ale to "tylko" efekty atmosferyczne, a ja bym się chciał dowiedzieć, czy istnieje możliwość zrobienia planet tak, jak to się ma w tytułach wspomnianych na początku. Możliwe? Niemożliwe? Może ktoś napisze coś mądrego.
-
Myślę, że możliwość jako taka jest. Problem tkwi w sprzęcie przeciętnego gracza-szaraka który ledwo ciągnie statek złożony z pięciuset części. Każdy dodatkowy efekt to dodatkowy narzut nie tylko na kartę graficzną ale też na pamięć i procesor - który już w KSP i tak jest dość mocno obciążony obliczaniem fizyki statków w czasie rzeczywistym.
-
No dobra, w porządku. Tyle że przy planecie nie ma żadnego obliczania fizyki międzyczęściowej w czasie rzeczywistym. Jedyne co jest, to siatka kolizji (tak mi się wydaje) i dużo pracy dla karty graficznej. A wydaje mi się, że w KSP proc wypruwa z siebie flaki, natomiast karta graficzna siedzi na metaforycznym papierosie, bo prawie nic nie ma do roboty.
Na YT jest sporo filmików z tworzenia widoczków w unity 5, na przykład ten:
https://youtu.be/LPIRAJcM1JU
Ja bym chciał wiedzieć, co by się stało, gdyby z niewiele mniejszą dokładnością odwzorowano na przykład Minmusa. (oczywiście bez drzewek). Zdaję sobie sprawę, że w miarę zbliżania się do obiektu powinny być wczytywane kolejne fazy dokładności, od badziewnie niedokładnej kulki jaką mamy teraz, przy locie na orbicie, do czegoś o dokładności terenu jak na filmiku, gdy już wylądujemy. Co by było obciążone najbardziej? Proc czy karta graficzna? I czy jest możliwość zrobienia tak całego globu?
-
No właśnie obliczanie fizyki w KSP jest cały czas obecne - a na powierzchni nawet bardziej - bo dochodzi grawitacja (mam na myśli właśnie kolizje z terenem - bo ta jest obecna i w przestrzeni) i aerodynamika która jest obecna niezależnie od tego czy to łazik czy samolot, czy inne dziwaczne ustrojstwo. KSP nadal wszystko liczy. A przy ładnych widoczkach karta graficzna byłaby obciążona - to fakt, ale proporcjonalnie do tego obciążyła by się też pamięć i proc. Co przy obecnym stanie rzeczy, wydaje mi się, że wymagało by bóg wie jakiego komputera aby dało się komfortowo grać.
-
Ale w takim razie jak z płynnością radzi sobie Elite? Tam są miliony (!) planet. A wszystko bangla, mimo, że też jest siatka kolizji. A Space Engineers? Nie dość że siatka, to jeszcze można w tym terenie dziury robić. Jak się przywali statkiem o grunt to zostaje krater. I jest jednak pewna uproszczona fizyka również.
-
Witam to mój pierwszy post wiec się przywitam :)
Unity 5 wykorzystuje PhysX czyli fizykę liczoną przez gpu (grafikę ) a ona jest o wiele bardziej wydajniejsza niż procesor
w tym zwiastunie Unity nawet jest pokazane :)
https://www.youtube.com/watch?v=AJ6Mkx1KEns
1:12
bo jak by nie patrzeć to kerbale dławi procek każda część ma swoja fizyke itp i porostu procesor nie wyrabia
ale jest jeden minus PhysX jest nVidi wiec zbytnio to czerwonych nie ratuje ale sam nie wiem jak jest z tym amd
-
Krzychu, w KSP PhysX nie jest aktualnie używany - więc nie ma o czym mówić. Kadaf, w Elite fizyka statku ogranicza się do... jednej "części"? To jest statku jako całość. Do tego miliony planet nie są wyświetlane na raz. Kolejna rzecz, że tam jest inny silnik gry - zapewne przystosowany do tamtejszej mechaniki gry. W Space Engineers jeśli dobrze pamiętam, fizyka statków to jakiś żart w porównaniu do Kerbali. Zniszczenia są efektowne ale nadal działają na zasadzie niszczenia poszczególnych klocków. Nic tam się tak naprawdę nie wygina i nie ma to żadnego wpływu na to jak dany statek lata. A jak się robią te kratery to nie wiem - bo nie widziałem. Przypuszczam, że zbyt dużo do liczenia prócz jakiegoś skryptu co kieruje tym gdzie postawić kolejny wierzchołek modelu przy takim a takim uderzeniu.
-
Krzychu, w KSP PhysX nie jest aktualnie używany - więc nie ma o czym mówić.
wiem ze nie jest używany ale w na nowym silniku będzie :)
-
Ale w takim razie jak z płynnością radzi sobie Elite? Tam są miliony (!) planet.
Autorski engine zapewne. Dostosowany, ba pisany specjalnie pod wymagania elite. I skupiający się zapewne na ładnym wyglądzie a nie na fizyce. Mamy tam przygotowane przez autorów statki z gotowymi parametrami, które dodatkowo nie zmieniają się zbytnio w trakcie gry. ot, masz tego np. Vipera czy jak się tam statki nazywają o takiej prędkości, takim przyspieszeniu, zwrotności, ewentualnie -5 do zwrotności jak go załadujesz.
W Kerbalach wykorzystany jest uniwersalny engine. Napisany do miliona różnych rzeczy i milionem różnych rzeczy się zajmuje - w tym pewnie kilkoma dla Kerbali zbędnymi. Ale najbardziej męczy go nieustanne "fizykowanie" obiektów. Statki zmieniają się w locie - spalają paliwo, odrzucają człony, łamią się i rozsypują. Do tego się grzeją, napotykają atmosferę co owocuje dalszym łamaniem i rozsypywaniem ;) Śmiem więc sądzić, że przez to ilość obliczeń fizyki w Kerbalach jest nieporównywalnie większa niż w innycvh podobnych grach - może z pominięciem Space Engineers, bo w to nie grałem, a to też klocki.
Ale, skoro wspomniałem o uniwersalnym Unity i autorskich enginach to jeszcze. Jak coś jest do wszystkiego to jest do niczego. Nieważne czy to engine, jakikolwiek soft, czy wręcz maszyna, jak jest stworzona w jednym celu, będzie to robiła wydajniej niż urządzenie do wszystkiego. Magiczne słowo to optymalizacja. Pamiętacie Frontiera? Chodził na Amidze, która miała swój system operacyjny skrojony na miarę podzespołów - pierwszy zysk. Po drugie gra także była skrojona do możliwości sprzętu, dało się więc wyciągnąć co się da. Obecnie, kiedy każdy komp jest inny ten sam soft musi działać na pierdylionie różnych konfiguracji w czym pośredniczy cała masa innego softu - sterowniki, OS, API, GPU, CPU, C3PO, PKP i CHWD. Urodzaj sprzętu PC jest zarazem jego przekleństwem marnującym wydajność. Popatrzcie jak wiele można było wyciągnąć z poprzedniej generacji konsol (PS3, a nawet PS2) które miały mocno nietypową architekturę, ale gry były optymalizowane pod nią.
-
No ale do meritum. Pytanie moje było, czy jest fizyczna możliwość zrobienia planet na wysokim poziomie. Powiedzmy, że gdyby jakość tekstur była wyższa, to z ogromnym bólem można by znieść jednak jakość wykonania Muna. Chociaż brak jakichkolwiek ostrych krawędzi w miejscu gdzie nie występuje erozja uważam za porażkę. Tam wszystkie urwiska i brzegi kraterów powinny być poszarpane i ostre jak szczęki rekina. W porządku, Mun jest niewiarygodnie słaby, ale to i tak cudo w porównaniu z resztą planet, które są zrobione niedopuszczalnie źle. Więc jak sądzicie? Przy locie na Muna nie ma wczytywania i czkawek większych. Czyli się da. Ale czy to jest tak, że silnik Unity wytrzyma tylko jeden taki obiekt? Czy chodzi tu o lenistwo Squadu (z którego notabene wyrzucono ostatnio jedynego człowieka, który popychał projekt ostro do przodu. Dla nieznających historii KSP - taka sytuacja ma miejsce już drugi raz), czy są przesłanki techniczne, które uniemożliwiają zrobienie tego porządnie?
-
Moim zdaniem - fizyczna możliwość zrobienia ładnych planet jest. Wymagałaby jednak dużego (jeśli nie ogromnego) nakładu pracy. Mowa wszak o skali planety.
-
jak by się im chciało modyfikować silnik u5 to pewnie by dużo to dało , przykład star citizen na CRYENGINE z tego co czytałem gdzieś twórcy go zmodyfikowali.
jak pisano wcześniej trzeba dużo pracy aby zrobić nowe tekstury dla planet i je " udekorować " i tak dalej :)
-
W sumie to zrobienie planet na poziomie wyższym nić obecny jest nawet więcej niż możliwe. Na munie już raz poprawiano modele. Ale to nie jest tak , że squad siedział i modelował wszystko ręcznie , wykorzystano narzędzia proceduralne , część pracy wykonał za nich komputer. Czemu nie zrobili tego dla pozostałych planet ? Nie wiadomo. Ludzie od moda Outer planets , już ich prześcignęli i zrobili całe planety od zera wraz z księżycami o teksturach które są tylko nieco gorsze niż powierzchnia muna. Można? Można!
-
Wymagałaby jednak dużego (jeśli nie ogromnego) nakładu pracy. Mowa wszak o skali planety.
W momencie gdy kilkanaście gier i programów oferuje szczegółowe generowanie terenu dla dowolnej liczby ciał niebieskich, ten argument wydaje mi się nietrafiony.
Jedyne co mi przychodzi do głowy to to, że oszczędzają środki/moc obliczeniową na umożliwienie budowy większych konstrukcji, ale przydałby się wybór, np. paczka assetów o niższej jakości dla słabszych maszyn.
-
A ja się zastanawiam na ile taka planeta obciąża. Powiedzmy, że wylądowałem w fajnie wygenerowanym terenie. I co, ten teren obciąża mojego kompa jak statek składający się z 10, 100 czy 500 części?
-
Wszystko się da. W Unity można zrobić naprawdę piękne rzeczy. Kwestia tylko tego, czy społeczność jest w stanie się "poświęcić".
@UP
Modele są generowane za pomocą trójkątów (voxeli). Więcej trójkątów = większe obciążenie komputera. Oczywiście da się zrobić ładny teren bez dużej ilości trójkątów, ale nie jest to proste.
-
No to ja wiem, że trójkąty. Ale co te trójkąty terenu obciążają? Kartę graficzną czy proca? Bo wciąż przypominam, że w KSP karta graficzna nie ma prawie nic do roboty. To są ogromne wolne zasoby obliczeniowe, które się zwyczajnie marnują.
-
Nie jestem żadnym informatykiem, ale z tego co kojarzę nie cały teren musi być wczytywany jednocześnie jeśli gra jest dobrze zoptymalizowana. Wystarczy wczytywać obszar, który widzi gracz + ew. jakiś margines spoza ekranu. Więc w teorii przy starcie i lądowaniu najbardziej byłoby wszystko obciążone, bo ma się szeroki zakres widoczności. Na gruncie zdecydowanie mniej byłoby obiektów do wczytywania. Tylko mam pytanie czy taka funkcja stoi po stronie squadu czy ekipy od unity?
-
To są ogromne wolne zasoby obliczeniowe, które się zwyczajnie marnują.
To nie jest tak że w jednostce komputerowej procesor robi sobie, RAM sobie, karta grafiki sobie - ta ostatnia jest także kontrolowana przez procesor.
Co nie zmienia faktu że KSP jest bardzo niewydajne, ale z drugiej pozwala na takie zabawy jak zmienna geometria skrzydeł liczona na bieżąco. Tak naprawdę nic nie stałoby na przeszkodzie by każdy pojazd był przeliczany wstępnie i zmieniany w jedną fizyczną bryłę, ale mocno ograniczyłoby to unikalność mechaniki tej gry. Tak czy siak, możliwości by obejść te problemy jest sporo - nie wczytywać najlepszej jakości terenu gdy prędkość względem powierzchni jest ogromna, odblokowywać najwyższą szczegółowość tylko w sytuacji "landed" itd.
Jak dużym problemem jest fakt, że Unity wczytuje wszystkie assety na początku? Wiem że Winged usuwa tekstury wysokiej rozdzielczości w swojej instalce by zaoszczędzić miejsce, to też jest spory problem. Wczytywanie na bieżąco mocno odciążyłoby RAM i pozwoliło użyć dużo lepszych tekstur, bo bez nich ciężko zrobić coś ciekawego.
-
Zapominacie o jednej rzeczy.
Porównujecie różne gry, z których ani jedna nie jest podobna do innych.
Space Engineers - Skupia się na eksploracji otoczenia i interakcji z nim.
Elite Dangerous - Skupia się na działaniach gracza, a świat jest niemal wyłącznie dekoracją.
KSP - Skupia się na fizyce oddziaływania elementów na siebie, oraz środowiska na elementy.
W każdej z tych gier, moc obliczeniowa idzie na co innego. Co innego jest ważne.
Owszem - KSP mogłoby mieć więcej elementów scenerii, ale jest ona w tej grze najmniej istotna.
Chcesz grę do oglądania? To jest ED. Ale za wygląd płacisz szczątkową fizyką i brakiem interakcji ze światem.
W SE, fizyka jest nieco bardziej rozbudowana, ale nadal szczątkowa w porównaniu z KSP. Wygląd jest sporo lepszy, a ilość dostępnych części idzie w tysiące. Dochodzi też zmieniane otoczenie.
Za to płacimy gorszym wyglądem otoczenia i mniej zaawansowanymi obliczeniami fizycznymi.
Gdybyśmy chcieli połączyć wszystkie te elementy w jedną grę, to byśmy płakali jak kiedyś nad Flight Simulator X - do którego maszyny domowe, zdolne dźwignąć w pełnej gamie, pojawiły się kilka lat po premierze gry, a Ms renderował "gameplaye" do pokazów, bo faktycznego się nie dawało pokazać, nawet na wypasionych kombajnach.
Silniki gry pozwala na wiele. Ale nawet najlepszy silnik jest ograniczony zasobami komputera. Dlatego zadaniem twórcy gry jest postawienie nacisku na to co istotne dla gry, kosztem rzeczy mniej istotnych.
A w KSP istotna jest fizyka zachowania się grupy obiektów, w aktualnych warunkach.
-
Nie do końca się z Tobą zgadzam Madrian. Owszem, rozumiem, że to inne gry, na innych silnikach, mające na celu coś całkiem innego. Ale zupełnie się nie mogę zgodzić z twoim twierdzeniem, że wygląd planet jest nieistotny. KSP jest najbardziej wypasioną na rynku grą o podróżach kosmicznych, tyle, że, no, warto mieć do czego podróżować. Czegoś innego niż pomaranczowawa kulka (Duna). Na podstawie przykładu Muna wiemy, że da się stronę wizualną nieco podkręcić. Bill też potwierdza, że planety z moda z tym tam Sarnusem wyglądają o niebo lepiej. Więc wydaje mi się, że się da. Wydaje mi się też, że po prostu Squad ma to zwyczajnie w pompie. Co do Muna jeszcze. Z osobistego doświadczenia wiem, że wczytywanie powierzchni na Munie, Dunie czy Kerbinie nie ma powoduje wykrywalnego przeciążenia. Załóżmy, że mamy statek 500 części i już nas boli klatkowanie. Powiedzmy, 10fps. Ten statek na orbicie Kerbinu, w przestrzeni międzyplanetarnej, jak i na orbicie Duny cały czas będzie klatkował mniej więcej podobnie. Gdy nim wylądujemy na Munie, to nie zauważymy znaczącego spadku FPS, o ile w ogóle zauważymy jakikolwiek. Więc? Planety w tej chwili w mikroskopijnym jedynie stopniu obciążają kompa. Ja bym był bardzo szczęśliwy, gdybym nawet za cenę znacznie bardziej odczuwalnego spadku FPS mógł się rozejrzeć po pięknie wymodelowanej planecie. Po prostu latałbym mniej skomplikowanymi statkami, albo zaprzyjaźnił się bliżej z ubiozurem. Tu chodzi o tę frajdę, lecimy gdzieś, lądujemy, wysiadamy załogą i naszym oczom ukazuje się fantastycznie wykonany krajobraz... W tej chwili tej frajdy moim zdaniem nie ma w ogóle. Jest frajda że wylądowaliśmy. Wzieliśmy oczywiście łazik. No i? Chce nam się do niego zapakować i zobaczyć, co też jest za tą górą na horyzoncie? Powiem za siebie. Za chiny nie. Przejechałem kiedyś Dunę od równika po biegun i była to najnudniejsza wyprawa jaką kiedykolwiek w jakiejkolwiek grze przedsięwziąłem.
-
@up
O to przecież pytamy (znaczy, ja, Kadaf, inni którzy aż tak w komputerach nie siedzą).
Wciąż, to jak wyglądają stockowe planety zakrawa na żart.
Darmowa zawartość wykonana przez moddera, losowe miejsce na planecie:
(http://i.imgur.com/6Q2syOT.png)
(http://i.imgur.com/wBLiNEA.png)
(Z wyłączonymi scattersami, z nimi jest jeszcze ciekawiej).
Stockowe planety, podczas gdy już wiele wersji temu wykorzystano proceduralne generowanie terenu:
(http://103.imagebam.com/temporarylink/retsjEdxQMu3Cgko8pujgA/1449857363/25596/255950810/screenshot1459.jpg)
(http://i.imgur.com/l7s3BD3.png)
Skąd aż taka różnica? Przez hardware?
-
Może zacznę od wyprowadzenia Was z błędu. Nie jest prawdą, że Unity nie korzysta z PhysX. Korzysta z niego od najwcześniejszych wersji.
Prawdą jest, że jak coś jest od wszystkiego, to jest do niczego.
Unity nie jest od wszystkiego. Unity jest silnikiem gry.
Silnikiem fizyki wykorzystanym w Unity jest PhysX.
Inne silniki gry, też wykorzystują ten silnik fizyki.
Silnik fizyki gry, wykorzystuje akcelerację sprzętową karty graficznej do obliczania trajektorii ruchu ciał, detekcję kolizji, mechanikę płynów itp.
W KSP, ruch w polu grawitacyjnym jest sporo uproszczony, ale i tak na najwyższym poziomie wśród wszelakich gier komputerowych.
Bo gdyby ruch obliczany był w 100% według praw Newtona, to nie ma takiego komputera, który by to udźwignął. Przypominam, że dla stabilnej symulacji, obliczane są na bieżąco wszystkie ciała niebieskie, pojazdy na orbicie i śmieci.
Najistotniejszą sprawą dla wyglądu powierzchni planety jest wsparcie sprzętowe shaderów (pixel i vertex shader), czyli potrzebna jest jednostka cieniująca. Układ taki, oprócz obliczania oświetlenia wspiera obliczanie powierzchni (Transform&Lighting), jej wypukłości, czy jak to zwał. Programista nie musi się przejmować czy elementy poza sceną, lub ukryte za obiektami są liczone przez GPU, czy nie, ponieważ jednostka cieniująca zrobi to za nas.
Transformacje obrazu i jego oświetlenie, jest obliczane przez inną jednostkę niż reszta fizyki, dla tego Kadaf nie zauważa spadku wydajności przy zbliżaniu się do powierzchni Muna.
Powierzchnie planet nie są więc dopracowane nie ze względu na oszczędność karty graficznej, ale ze względu na lenistwo pewnych panów z pewnego studia.
-
Trzeba mieć nadzieję, że lenistwo w końcu przejdzie.
A co do tematu-silnik Unity jest popularny wśród twórców niezależnych, ponieważ jest względnie nieskomplikowany w obsłudze, a zapewnia niezgorszą jakość grafiki. Większość ,,dużych'' tytułów korzysta z bardziej zaawansowanych silników, często specjalnie konfigurowanych lub tworzonych od zera na potrzeby danej produkcji; a to zupełnie inna para kaloszy. Gdyby Squad robił KSP na własnym silniku, zapewne gra byłaby jeszcze bardziej realistyczna i o wiele bardziej szczegółowa graficznie. Ale na pewno byłoby to okupione wzrostem wymagań sprzętowych i czasu produkcji.
Off-top: Ponoć w sieci ma zostać udostępniona-lub już została udostępniona-darmowa wersja Unreal Engine'a.
-
Gdyby Squad robił KSP na własnym silniku, zapewne gra ...
...by nie powstała, bo nie byłoby na czym zrobić prototypu który zachęcił Squad to zostawienia Harvestera w firmie. Well, było to w czasie kiedy licencje silników Unreala czy Cry Engine jeszcze nie były tak liberalne jak teraz, a produkcja silnika gry, mimo że brzmi bardzo fajnie, to potężna, skomplikowana inwestycja a Squad nie jest doświadczonym studiem, ani dużym studiem. Nierealne*, szczególnie że tak łatwo teraz o profesjonalne narzędzia developerskie.
Ponoć w sieci ma zostać udostępniona-lub już została udostępniona-darmowa wersja Unreal Engine'a.
Najnowszy Unreal jest za darmo, płaci się dopiero gdy sprzedana zostanie odpowiednia ilość egzemplarzy. I to nie od wczoraj.
_________
*Pun not intended
-
O widzisz obywatelu Robson, niezmierna ucieszność we mnie się pojawiła, gdy zauważyłem żeś się wypowiedział. Tak, tak, zakładając ten wątek sobie pomyślałem, Robson wychynie z miski milczenia i swoje trzy grosze dorzuci. Bo się zna, robi wojskowe cuda, ma pińcset procesorów w kompie, to jak się wypowie, to będzie wiadomo, że oświeci. I faktycznie, oświecił, że aktualna tandeta planetarna to tylko i wyłącznie lenistwo twórców. Dokładnie tak, jak przypuszczałem :)
Gdyby tak jakiś juniciarz się znalazł, to ja bym się chętnie pobawił. Na początek z Minmusem. Bo mnie akurat nie nudzi wypełnianie setek kilometrów kwadratowych "czymś". Tylko trzeba by wykonać ze 30 prostych modeli 3d jakichś skał, żlebów, żebym ja potem mógł się pobawić w układanie tego. I jeszcze tekstur takich, żeby się dało malować jak pistoletem. Ale widziałem, że U5 taką opcję jak najbardziej przewiduje. Co wy na polski mod planetarny do KSP? Chociaż może moje euforyczne podejście w danym momencie wynika z faktu, że bardzo pijany jestem. (Ale i tak piszę, kurde flaki, porządnie)
-
...bardzo pijany jestem.
Hehe, to tak jak ja :)
A co się tyczy mojego milczenia, to przyznam się bez bicia, że dom wybudowałem i czasu za bardzo nie było. A obecnie widzimy jaka jest sytuacja na świecie, więc zajęty jestem pracą na maksa.
Pewnie tak do wiosny. Ale nie próżnuję i z KSP jestem na bieżąco.
Kończąc offtopa powiem, że taki mod jest jak najbardziej możliwy, ale to młodzież niepracująca niech się wypowie, bo roboty przy tym będzie co nie miara.
-
Nie jestem pewien czy przypadkiem w kerbalach, dostęp do modeli planet nie jest w jakiś sposób ograniczony. Zdaje mi się, że jednak jest dlatego większym modyfikacjom ich jeszcze nie poddano. Offtopem kończąc - zaczynam mieć wrażenie, że zaraz tu założymy jakieś kółko niepraktykujących abstynentów.
-
@up
Możliwe jest schowanie faktycznych planet i wrzucenie własnych bądź podmianka, ulepszanie istniejących - nie.
-
Drogi Robsonie,
Podejrzewam, że obecny model ruchów planet jest wynikiem tego, że nikomu nie chciało się zrobić lepszego, a nie, że komputer by tego nie uciągnął. Orbiter jakoś działa sprawnie, a rozwiązuje numerycznie równania różniczkowe. Sam pisałem kiedyś symulator ruchu planet i bez problemu działał nie tylko w czasie rzeczywistym, ale nawet w przyspieszeniu czasu x1.000.000 (i to na moim badziewnym laptopie). Da się zrobić selektywną grawitację tak, żeby uwzględniać tylko te siły, które rzeczywiście coś wnoszą (tzn. pomijać np. oddziaływanie rakieta - śmieć orbitalny).
Tak tylko swoje trzy grosze chciałem dorzucić :)
-
Bo w Orbiterze obliczenia zmiennoprzecinkowe dla symulacji ruchu w polu wykonuje jednostka T&L. Tam jest inny silnik fizyki.
Zresztą, satysfakcjonująca płynność tej gry zaczęła się długo po jej premierze, bo nie było takich kart, które by to pociągnęły.
-
Podejrzewam, że obecny model ruchów planet jest wynikiem tego, że nikomu nie chciało się zrobić lepszego, a nie, że komputer by tego nie uciągnął.
Czy rodzaj fizyki o którym mówicie nie jest dostępny w Universe Sandbox?
Anyway, w grze nie chodzi o to żeby oddać zjawisko w sposób dokładny. Robiąc shootera "Ziemia" nie musi mieć odpowiedniej masy, bo dużo łatwiej jest napisać to tak, by na bohatera ciągle działała siła = G skierowana w podłogę. Tak samo w KSP, można by bez problemu symulację orbit planet (tak jak to działa dla aktywnych statków), ale wygląda to jak kopalnia mnóstwa potencjalnych problemów z minimalnymi zyskami w postaci jeszcze bardziej skomplikowanego manewrowania w ciasnych układach Joola czy Duny.
-
Czy ja wiem czy byłaby to kopalnia problemów? Ogólne sformułowanie grawitacji, według praw Newtona, oznaczałoby koniec np. z błędami przy przejściach przez SOI (na dowolnym warpie), bo nie byłoby żadnych SOI.
A układ Joola w normalnych warunkach by się szybko rozleciał :P
-
A układ Joola w normalnych warunkach by się szybko rozleciał
...No? Akurat projektując taką grę nie chciałbym żeby planety przy warpie mi szalały, zmieniając pozycję. Szyny wymagają wyłącznie zaprogramowania najprostszych opcji a pisanie fizyki dla planet byłoby zbędne. No i czy oddziaływanie nie jednego obiektu, a kilkunastu na każdy statek i wszystkie części naraz naprawdę byłoby obojętne dla zużycia zasobów? Średnio w to wierzę.
-
Moim zdaniem planety na szynach to doskonałe rozwiązanie. Próba wytrącania któregokolwiek ciała z jego orbity to zdroworozsądkowo patrząc kompletny debilizm. Nie mówiąc o tym, że liczona fizyka dla wszystkich ciał naraz. zeżarła by kompy na procesy, których i tak nikt nie zauważy.
-
Nie twierdzę, że byłoby to obojętne, ale że to nie jest coś z czym komputer nie mógłby sobie poradzić. Co do oddziaływania planet na siebie nawzajem albo rakiet na planety to ok, przyznaję rację Kadafowi, ale oddziaływanie wielu planet na rakietę? To by było ciekawe, mielibyśmy punkty Lagrange'a, orbity wokół Muna nie byłyby stabilne itp.
-
Pytanie moje było, czy jest fizyczna możliwość zrobienia planet na wysokim poziomie.
Pewnie, że jest ale tekstury wyższej jakości mają potężny wpływ na zużycie RAMu tak samo Scaterrer, dlatego uważam, że obecny wygląd planet to nie tylko kwestia lenistwa Squadu ale też ograniczenia wynikające z 32-bitowej wersji. Na szczęście Maxmaps zapowiedział overhaul graficzny po wydaniu 1.1 choć nie wiem czy miał on też dotyczyć wyglądu planet czy tylko części (części na pewno zostaną poprawione).
Czy chodzi tu o lenistwo Squadu (z którego notabene wyrzucono ostatnio jedynego człowieka, który popychał projekt ostro do przodu. Dla nieznających historii KSP - taka sytuacja ma miejsce już drugi raz)
Kogo wyrzucono?
Podejrzewam, że obecny model ruchów planet jest wynikiem tego, że nikomu nie chciało się zrobić lepszego, a nie, że komputer by tego nie uciągnął
Tutaj to akurat prawda. Po prostu ta kwestia nie jest priorytetowa dla Squadu i było już mówione wiele razy, że nie będą się za to zabierać. Ale to miał być temat o wyglądzie planet.
-
Dla Kadafa jakakolwiek zmiana na stanowisku w Squad jest "wyrzuceniem". Czy został wyrzucony czy odszedł sam nie wiem, ale Maxmaps nie pracuje już w Squad.
-
Po wyjściu wersji 18.3 ze dwa lata temu ze Squadu odszedł lead designer. Koleś, któremu zawdzięczamy prąd elektryczny i dokowanie w Kerbalach. Zanim odszedł zapowiadane było, że zaraz pojawią się koła, oraz o ile mnie pamięć nie myli wyszły pierwsze informacje na temat wydobycia. I to w systemie "dla dorosłych" Mnóstwo surowców, mnóstwo narzędzi przetwarzania, skomplikowany diagram. Po zniknięciu lead designera prace się zatrzymały. Kolejne updaty nie przynosiły nic ciekawego i były pełne karygodnych bugów. Zapowiadano rozmaite rzeczy, których nikt jednak nie realizował. Jak chociażby pas asteroidów, który miał się pojawić już już, za tydzień, dwa i nie ma go do teraz. Pojawił się maxmaps. Nagle prace dynamicznie ruszyły do przodu. Dostaliśmy w końcu wydobycie (z opóźnieniem ile, dwa lata?), poprawiono aerodynamikę, pojawiły się ładownie, nowe kokpity, zaczęto przeprowadzać lifting części. Oraz rozpoczęto żmudną przesiadkę na U5 i 64 bity. To był człowiek mam wrażenie, który wziął za pysk tych ludzi i zmusił ich do pracy. Teraz opuścił Squad. Zastanawiam się dlaczego wcześniej tamten (nazwiska nie pamiętam), a teraz ten się pożegnał z firmą. Nie oszukujmy się, KSP w kwestii lotów kosmicznych jest grą topową na rynku nie posiadającą żadnej realnej konkurencji. A tymczasem z pracy rezygnują dwaj ludzie, którzy mieli spory wkład w rozwój gry. Kto się zwalnia z firmy, która robi taki produkt, który jest na dodatek niesamowicie wręcz rozwojowy? Powody mogą być trzy; albo jakieś dramatyczne zmiany w życiu, albo pieniądze, albo popierdoleni współpracownicy.
Sądzę, że gdyby miał miejsce powód numer jeden, to połowa dewnołta była by mu poświęcona, skoro pierdzielą tam takie bzdety jak to kto miał grypę, a kto se kupił nowe biurko. Zostaje powód nr 2 albo 3. Oba te powody tematycznie są zawsze pewnym tabu w firmach. O nich się nigdy nie mówi oficjalnie, bo to się może skończyć w sądzie i być bardzo kosztowne dla którejś ze stron. Jeśli właściciele Squadu nie wypłacają terminowo wypłat, albo robią inne tego typu problemy, to wiadomo, można ich zaskarżyć. Ale żaden rozsądny były pracownik, który posiada doświadczenie w byciu osobą odpowiedzialną za jakiś odcinek prac na wyższym stanowisku nie będzie tak głupi, żeby pozywać byłego pracodawcę. Bo każdy przyszły pracodawca będzie miał świadomość, że, o, to był facet, który pozwał byłego szefa. Kurde, może lepiej go nie zatrudniajmy, bo kto wie, noga nam się powinie, z czymś się spóźnimy, a ten na nas doniesie i zaskarży.
Trzeci powód, fatalna atmosfera pracy, czyli kretyni współpracownicy. Tutaj już w ogóle nie ma mowy o sądach, bo udowodnienie czegokolwiek, szczególnie jeśli jeden człowiek staje przeciwko kilku, jest praktycznie niemożliwe i jeszcze bardziej ryzykowne. Powiedzieć publicznie też za bardzo nie można, bo sytuacja znowu jest podobna do powodu nr 2. (O, ten im dupę odsmarowywał publicznie, no przecież go nie zatrudnimy, bo kto wie jak to tam było naprawdę).
Tak więc uważam, że jeśli ktoś piastujący wysokie stanowisko, ktoś czyje zaistnienie wyraźnie popchnęło projekt do przodu, nagle ni z tego ni z owego opuszcza firmę i jest cisza o powodach takiego odejścia, to dla mnie jest jasne jak słońce, że bardzo nie gra coś, o czym powiedzieć nie można. Czyli powód nr 2 albo 3.
-
Po prostu operuję na faktach, a zdarzenie jest takie, że Maxmaps nie pracuje już w Squad, cała reszta to mniej lub bardziej uzasadnione domysły. Nie rzuciło mi się w oczy by nowy lider coś robił w ostatnich Weekly. Ma ktoś jakiekolwiek informacje o nim, czy wypowiadał się już na blogu? Wiadomo że musi się wdrożyć, ale ja nawet kurka jego nicku nie mogłem znaleźć.
@Winged
A bez tekstur lepszej jakości trudno coś zrobić, a nie wiadomo czy wersja 64 bit będzie priorytetowa. Mam nadzieję że tak, wystarczy już opierania technologii tej gry na ograniczeniach Windowsa XP