Nowe oblicze Virtual Bus - Page 22 - Programy - VirtualBus forum

Jump to content



Nowe oblicze Virtual Bus


  • Please log in to reply
436 replies to this topic

#421
Kiciuszek

Kiciuszek
  • Developerzy
  • 39 Posts:
23
Dzięki za research.
Z angielskim to niestety bieda znam tylko parę zwrotów.

>Szkoda, że nie napisałeś, której wersji Unity używasz, w wersji 5 fizyka opiera się na PhysX 3.3.

Unity 5. Ostatnio takie jaja mi wychodżą z fizą że mam wrażenie że PhysX jest słabszy od Bulleta. (ale równie dobrze może być to moja nieznajomość w konfiguracji PhysX)

>Samochód można stworzyć, używając Rigidbody (bryła sztywna) + WheelCollider.

No tak też zrobiłem, WhellColider używa metody raycastowej.

>Ciekawostka: Obecna wersja Unity umożliwia wykonanie wozów, które mają nawet 20 kół!

Na starszym Bullecie miałem wrażenie że liczba kół jest dowolna.

> jak ktoś chce się cieszyć w 100% możliwościami najnowszej wersji tej biblioteki, to powinien testować aplikację na komputerze z w miarę nową kartą graficzną GeForce
Na szczeście mam GT670, czyli jeszcze na czasie, PKS śmiga w realtime z kolizjami nawet w okienku testu

Mogę dla porównania powiedziec że edytor Unreala jest u mnie mniej wydajny, a edycja skryptów w Microsoft Visual Studio to już dramat totalny, jak w średniowieczu czekam nawet jak przełączam żródłówki.
Choć własnie z tym wiązałem nadzieje bo jest tam C++. Natomiast #C jest dla mnie strasznie ograniczony przez przyzywczajenie do możliwości C++ i się w nim męczę.

AdBot

  • Elita
  • Posts: ∞

#422
PKS

PKS
  • Użytkownicy
  • 104 Posts:
10
Czytałem, że PhysX 3.3 jest obecnie liderem, jeśli chodzi o szybkość. Porównywali go z Havokiem i z Bulletem. Ja tego nigdy nie testowałem, więc w sumie nie mam zdania.

Ostatnio trafiłem na ciekawy kanał na YT - gość zamieszcza filmy z serii Unity Realistic Vehicle Physics. Wygląda to naprawdę ciekawie, pod jednym z filmów napisał, że teraz używa Unity 5. Nie wiem, na ile korzysta z wbudowanej w silnik fizyki, a na ile sam ją pisze.
Kiedyś zobaczyłem BeamNG i byłem zachwycony możliwościami Torque3D. Okazało się jednak, że cały moduł fizyki w tym symulatorze to własny projekt jego twórców, a Torque3D był im potrzebny głównie do grafiki, GUI itp.
Torque3D ma otwarty kod, można z nim zrobić, co tylko się zechce (ale pozostaje w tyle pod względem możliwości i obsługiwanych platform). W silnikach bez kodu (CryEngine, Unity) pracuje się ze skryptami lub tworzy się własne rozszerzenia w postaci bibliotek .DLL.

Nie ma co ukrywać - stworzenie symulatora to najtrudniejsze zadanie z możliwych. Wszystko musi być zbliżone do rzeczywistości. Wymaga to umiejętności i mnóstwa czasu poświęconego na naukę i testy.

Na pewno w Unity (i w wielu innych silnikach) można stworzyć świetny symulator, ale silnik sam wszystkiego za twórcę nie zrobi.
Dobrym podejściem może być zrobienie planu - takiej "niby dokumentacji projektowej": można opisać, co chcesz uzyskać, jak ma wyglądać grafika, jak ma wyglądać fizyka, dźwięki, sieć, UI i cała reszta. Później porównać to z konkretnym silnikiem - w silniku X mogę zrobić to w ten sposób, korzystając z tego czy tego i na końcu określisz, czy możliwości silnika Cię zadowalają. Im bardziej szczegółowo wypiszesz sobie wszystkie potrzebne rzeczy/możliwości, tym łatwiej będzie Ci później określić, ile silnik zrobi za Ciebie, a ile musisz zrobić sam.

Tutaj jest dość obszerna wymiana zdań użytkowników Unity na temat nowego WheelCollidera. Piszą, że system jest niedopracowany, że auta (koła) się dziwnie zachowują i radzą cofnąć się do wersji 4.6, gdzie podobno było to lepiej zrobione.
Z drugiej strony kilku użytkowników pisze, że system zastosowany w Unity 5 jest dobry i że wszystkie błędy wynikają z tego, że użytkownicy nie potrafią dobrać prawidłowych wartości dla zmiennych. Ważny jest ten post, głos zabiera przedstawiciel Unity. Zamieścił skromny poradnik dotyczący obecnego WheelCollidera i (jak dobrze zrozumiałem) kreator prawidłowo zachowujących się samochodów.

Cytat

Finally, I wanted to share a project with you where I demo the concept of natural frequency and damping ratio. You can see how the WheelCollider settings are being worked out from these two parameters. Yes, only two parameters per whole vehicle, regardless of how many wheels it has. I created a really minimalistic wizard to create different cars with up to 20 wheels. Find it in Vehicles -> Create boxy car. Once a car is created, just lift it above the ground and hit play. EasySuspension script updates WheelCollider settings online. You can see how easy it is to create cars of any mass with that wizard. (...) Just open the scene playground, focus on car (select carRoot in hierarchy, and press F two times), then click in game view to give focus to controls. This is really a super minimalistic project and I believe it has a great customisation potential.
Jak chcecie, to przetestujcie.

This post has been edited by PKS: 16 April 2015 - 20:52


#423
Kiciuszek

Kiciuszek
  • Developerzy
  • 39 Posts:
23
Powalczyłem trochę z Unity. Jest jeżdżący po placu autobus.

Tu widać otwierane drzwi i klapy:
http://zapodaj.net/d...1e5cee.jpg.html
Można robić dowolnie otwierane gadżety, lub zmieniane.
Nie wiem czy bardziej rozbudowywać o to program, ale da sie zrobić to co w niemieckim OMSI. To niestety wymaga bardziej szczegółowych modeli. Np. w Autosanie brakuje mi wizualnie zawiasów i jakichś wsporników dla klap bagażowych (oczywiscie animowanych, co też jest do zrobienia). Jesli ktoś wymodelowałby silnik to spokojnie można zrobić otwieraną klapę i drgajacy silnik podczas pracy. Tu możliwosci jest wiele, tylko czy jest sens isć w tę stronę?

Wnętrze:
http://zapodaj.net/9...8df2d8.jpg.html
Fajnie rozkłada się cień w obiekcie i materiały lepiej są eksponowane przez światło. Bardzo podoba mi się jak na zakrętach w widoku wewnątrz światło wpadające przez górne lufciki buszuje po wnętrzu autobusu.
Co do materiałów to żeby w pełni wykorzystac możliwośći silnika trzeba do tekstur dorobić tekstury normalnych (i tekstury wysokości jeśli chcemy żeby materiały wyglądał jakby były w  3d). To dodatkowa praca dla modelarzy i nie wiem czy ktoś w ogóle bedzie to robił?

Kolizje:
http://zapodaj.net/3...jpg.html#social
Kolizje są ze wszystkimi obiektami, można określić ich wagę i nawet spoko to działa. Np. w kolzji ciężej jest przepchnąć zaparkowane autobusy niż lżejsze auta osobowe. (czasami zdarzają sie takie kwiatki ze np. autobus rozpędzony do 20 km/h uderzył w 10 kilowy szlaban i podrzuciło go na 5 metrów w górę (autobus, nie szlaban :] )) Na szocie widac autobus po kilku zderzeniach z betonową scianą. Jakiś prosty skrypt do modyfikacji obiektu podłożyłem. Wygląda jak wygląda, ale działa. Gdyby chcieć isć w strone lepszych wgniot to trzeba by z autobusu wyodrębniać rózne materiały i np. reflektory robić innym już obiektem żeby się całe tłukły a nie zniekształcały. Zderzak też mógłby być innym obiektem. Tylko pytanie czy to ma sens, skoro jazda autobusem nie polega na zderzaniu się?

Autobus wjeżdża na rampę naprawczą:
http://zapodaj.net/7...c3f4bb.jpg.html
Można robić mapy z wysokoscią. Dużą część map z VBusa trzeba by przerobić (np. Kraków) tak zeby była uwzględniona wysokosć, szczególnie na skrzyżowaniach bezkolizyjnych, czyli mostach. Ale ogólnie żeby urozmaicić mapy fajnie by było nawet dodać na płaskich mapach rowy melioracyjne czy chodniki z krawężnikami.

Jestem już w stanie wczytywać i interpretować pliki tekstowe, a nawet zacząłem coś robić w kierunku wczytywania własnych assetów (w/g mnie podstawa takiego symka)
Teraz unknąłem w Unity 5 #c w rozpakowywaniu zipa z pamieci do pamieci i trochę mnie to zatrzymało. Niestety prawie nie znam angielskiego.

#424
fr0zi

fr0zi
  • Developerzy
  • 280 Posts:
34
Hej forumowicze.

Twoje prace, Kiciuszek, wyglądają bardzo obiecująco :) Widzę, że pojawia się wiele nowych możliwości w odwzorowaniu działania autobusów.

Zgadzam się z Tobą, że te wszystkie nowe możliwości - szczegółowe animacje drzwi, efekty świetlne na pojazdach itp. niosą za sobą potrzebę tworzenia lepszej jakości modeli - bardziej szczegółowych i bardziej dopracowanych. Sam pisałem o tym wiele razy. Nie da się wrzucić tutaj modelu wprost ze starego VBusa i od razu otrzymać "fajerwerki" na ekranie :) Ale ważne są możliwości. Jeśli one będą, to myślę, że ludzie zaczną ich używać :)

Chciałem się Ciebie zapytać, jak to jest właśnie z dodawaniem własnego kontentu do gotowej gry z Unity? Mam na myśli dorzucanie nowych pojazdów i map. Unity bawiłem się kiedyś i z tego co pamiętam, to nie bylo to takie proste bez pisania jakiś własnych dodatkowych modułów czy innych rzeczy. Jak to jest w Unity 5? Wspomniałeś, że zaczałeś już pracować nad tym tematem, czyli rozumiem, że jest to możliwe?
CPU & RAM: AMD FX 8120 @ 3.1 GHz & Kingston 8 GB DDR3
GFX: Sapphire Radeon RX 480 8GB GDDR5
OS: Windows 10 Professional 64-bit

Zasilacz: OCZ CoreXStream 500W
Obudowa: Fractal Design Define R3

#425
PKS

PKS
  • Użytkownicy
  • 104 Posts:
10
Wyrazy uznania dla każdego, kto próbuje cokolwiek zrobić dla rozwoju VirtualBusa i tworzy jakieś, jeszcze "nieśmiałe", zalążki nowej wersji. :D

Kiciuszek, screeny są rewelacyjne. Pomyśl też o nagraniu jakiegoś filmiku prezentującego to, co do tej pory zrobiłeś.
Jeśli chodzi o modele wyższej jakości - zobaczcie, ile ich wykonano dla niemieckiego symulatora. Choćby polskie "dzieła": Ikarus 260.04 Patrykosa, Neoplan N4016, Jelcz M125M Dana/Vecto/Vecto CNG KaJot_Teamu i wiele innych. Są one dostępne do pobrania, za darmo.
Pobierz je (jak potrzebujesz pomocy, to wyślij mi wiadomość prywatną), zaimportuj do swojego programu, efekty na pewno będą ciekawsze niż w przypadku tego Autosana. O, właśnie! Dostępny jest też bardzo fajny Autosan H9-21 by CoYoTeK i Ty-154 (autorzy to Polacy). Jeśli chciałbyś udostępnić swoją aplikację, wykorzystującą te modele, musiałbyś najpierw dostać od nich na to zgodę. Modele są "zakodowane" w formacie .o3d, czytelnym tylko dla niemieckiego symulatora, ale można poprosić autorów o udostępnienie plików .x, może ktoś się zgodzi.

Pytasz, czy jest sens pracować nad kolizjami, animowanymi detalami autobusu. Uważam, że "na dzisiaj" są ważniejsze rzeczy do wdrożenia, ale ogólnie jak najbardziej warto to zrobić.
Większość użytkowników dawno nie zaglądała na to forum, niektórzy już zapomnieli o VirtualBusie. Powrót do vBusa będzie miał dla nich jakikolwiek sens tylko wtedy, kiedy zaoferuje się coś, czego nie ma niemiecki symulator, choćby tryb multiplayer - to byłby hit! Podejrzewam, że dzięki tej jednej funkcjonalności wiele osób natychmiast pobrałoby nową wersję vBusa, pomimo innych niedoskonałości i niedoróbek.
Zainteresuj się tym: Photon Unity Networking Free.

No i pamiętaj też o polskich serwisach, które wymieniłem w tym poście. :) Tam otrzymasz pomoc dotyczącą Unity.

Powodzenia!

#426
MiK78

MiK78
  • Użytkownicy
  • 42 Posts:
7
Świetnie to wygląda, aż wraca nadzieja, że powstanie nowa wersja Vbusa. Oczywiście do tego jeszcze daleka droga, ale ogromnie cieszy już sam fakt, że ktoś coś robi w tym kierunku. :)

Co do wspomnianych modeli, one są w specjalnie stworzonym do tego symulatora formacie i skonwertowanie ich nie byłoby takie łatwe. Jednak i w samym Vbusie jest wiele dobrych modeli, ale obecne możliwości graficzne nie pozwalają na ukazanie wszystkich ich szczegółów, choćby modele Gocka. ;)

#427
PKS

PKS
  • Użytkownicy
  • 104 Posts:
10
Faktycznie, modele do niemieckiego symulatora mają swój format, zapomniałem o tym.
Chodzi o to, że pojazdy do vBusa były tworzone bez żadnych graficznych fajerwerków - twórcy wiedzieli, że silnik symulatora tego nie obsłuży, więc tego nie robili. Silnik, którego obecnie używa Kiciuszek, ma rozbudowane możliwości graficzne i modele z vBusa są dla niego (silnika) po prostu słabe.

P. S. W AssetStore masz sporo tekstur i materiałów, część z nich naprawdę wysokiej jakości.
Wchodzisz na stronę: https://www.assetstore.unity3d.com/en/ , po prawej masz menu. Wybierasz np. Textures & materials i zaznaczasz "Sort by: PRICE". Wtedy najpierw wyświetlane są darmowe dodatki z danej kategorii.
Uważam, że na początek nie zaszkodzi posiłkować się takimi darmowymi assetami, zanim potencjalni użytkownicy Twojej aplikacji nie zrobią czegoś lepszego. :)

This post has been edited by PKS: 10 May 2015 - 19:14


#428
Kiciuszek

Kiciuszek
  • Developerzy
  • 39 Posts:
23
>No i pamiętaj też o polskich serwisach, które wymieniłem w tym poście. :) Tam otrzymasz pomoc dotyczącą Unity.

Nie mogę się tam zarejestrować. Niby się rejestruję i ma wysłać do mnie maila dla potwierdzenia, ale nigdy ich nie dostałem.

>Chciałem się Ciebie zapytać, jak to jest właśnie z dodawaniem własnego kontentu do gotowej gry z Unity...

Na razie idzie jak krew z nosa, ale coś się da zrobić, oczywiście najlepiej samemu pisać skrypty zrozumieć język i strukturę klas w Unity (po kodowaniu w C++ to w #c czuję się jakbym kodował ze związanymi rękami :) ). Ostatnio dodałem proceduralny obiekt z tutoriala, do tego dołożyłem czytanie z pliku vertexów i razem dało wczytywany obiekt z pliku. Jeszcze do końca nie wiem czy reszta się da, ale ci co zrobili Skyline Cities na Unity chwalą się że użytkownicy będą dodawać kontent sami.
Z tym się też wiąże opracowanie własnego (nowo-VBus'owego) formatu łączącego w sobie dobór obiektów, tekstur materiałów, animacji, dźwięków, stanów i innych takich. W Unity jest struktura drzewiasta obiektów i jest to dość dobre rozwiązanie, taką strukturę musiałby odzwierciedlać plik.

>choćby tryb multiplayer

Multiplayer do VBusa ma chyba średni sens – autobusy widzą się raz na jakiś czas. Każdy będzie miał inny ruch uliczny inne pozycje samochodów i pieszych, bo tego nie da się przesłać (np. Minecraft – jeden tłucze owieczki, drugi widzi tylko latającego z mieczem kolesia na pustej polanie).

>P. S. W AssetStore masz sporo tekstur i materiałów...

Tak, zauważyłem, liczę jednak na to że assety będą dodawać użytkownicy Vbusa a nie ja :), oczywiście chcę zrobić jeden max wypasiony autobus żeby pokazać co można zrobić. (sam wolałbym robić realne mapy swojej okolicy, ale niekoniecznie modelować). Co do autobusów to lubię „ogóra” bo jeździłem nim do szkoły, więc jak już będzie coś sensownego to może skontaktuję się z autorem modelu do OMSI.

OMSI, OMSI, OMSI,
w sumie pisanie nowego VBusa w dobie OMSI sprowadza się do konkurencji z tymże. Nie wiem czy to ma sens, czy po prostu nie poprosić autorów OMSI żeby wydali wersję na Polskę z napisem Vbus :)

>Uważam, że "na dzisiaj" są ważniejsze rzeczy do wdrożenia

To może zrobić jakąś listę?
(nie obiecuję że będę robił w/g niej, bo będą to prace w/g silnika, ale da mi jakieś pojęcie na czym się skupić):

#429
2242

2242
  • Użytkownicy
  • 23 Posts:
12
Witam :)
Widzę że nawet sporo się tu dzieje.
Mam pytanie dotyczące konwersji mapy i rozkładów - na jakiej zasadize miałoby to wyglądać? Wiem że jeszcze długa droga do tego ale np każdej ścianie czy pochylni trzeba by nadawać oddzielne współrzędne?

#430
Kiciuszek

Kiciuszek
  • Developerzy
  • 39 Posts:
23
Trzeba po prostu przerobić model - powyciągac w pionie powierzchnie. Model kolizji jest liczony automatycznie do modelu 3d i autor trasy nie musi się tym przejmować.

#431
PKS

PKS
  • Użytkownicy
  • 104 Posts:
10

Cytat

Nie mogę się tam zarejestrować. Niby się rejestruję i ma wysłać do mnie maila dla potwierdzenia, ale nigdy ich nie dostałem.
Przeczytaj prywatną wiadomość ode mnie.

Cytat

Multiplayer do VBusa ma chyba średni sens (…)
Nie znam się na tym. Kiedyś czytałem, że można zrobić serwer z bazą danych, gdzie przechowywane są następujące parametry:
- ścieżki, po których mogą poruszać się pojazdy – numer danej ścieżki + zbiór punktów (x,y,z) na niej leżących (w sumie te informacje nie muszą być przechowywane na serwerze, mogą być w pliku konfiguracyjnym danej mapy),
- numer ścieżki, po której porusza się dany pojazd,
- aktualne położenie pojazdu,
- aktualna prędkość pojazdu,
- jaki to konkretnie pojazd – który model 3d,
- malowanie pojazdu,

Użytkownik uruchamia symulator na swoim komputerze -> aplikacja pobiera powyższe dane z serwera, generując ruch uliczny – dla każdego gracza taki sam.
W takiej sytuacji użytkownik nie mógłby sam określić, jakie pojazdy są używane w ramach AI i jakie ma być natężenie ruchu – narzucałaby to baza danych.
Równie dobrze opisany wyżej mechanizm mógłby być aktywny tylko wtedy, kiedy użytkownik zaznaczy w opcjach „Tryb multiplayer” albo „Gra sieciowa”, a w przeciwnym razie ruch AI mógłby odbywać się na podobnych zasadach jak w niemieckim symulatorze.

Ja myślałem o trybie multiplayer bardziej w kontekście „wirtualnego CB Radia” związanego z daną mapą – przydatne w vFirmach. Kierowcy mieliby łączność z dyspozytorem i sobą nawzajem, informując się o wypadkach, objazdach itd.

Cytat

w sumie pisanie nowego VBusa w dobie OMSI sprowadza się do konkurencji z tymże.
Potencjał niemieckiego symulatora nie został wykorzystany. Przy tak wielkich możliwościach związanych z tworzeniem dodatków już dawno powinniśmy podziwiać w pełni funkcjonalne samochody osobowe, ciężarówki z naczepami, tramwaje, lokomotywy, a może i samoloty. Przecież w obecnej wersji znacznie zwiększono możliwości związane z infrastrukturą tramwajową/kolejową – tory, zwrotnice, trakcja. Już w wersji 1 mieliśmy możliwość wykonać m. in. w pełni funkcjonalną deskę rozdzielczą.

Własny, dla wielu niezrozumiały, język skryptowy; brak profesjonalnych tutoriali przygotowanych przez twórców symulatora; brak odpowiednich opisów plików konfiguracyjnych; niedostateczna liczba komentarzy w plikach ze skryptami. Konieczność kupna aplikacji, brak obsługi innych systemów operacyjnych, brak prawidłowej obsługi wielordzeniowych procesorów i wiele innych wad. O braku możliwości wsiadania pasażerów do autobusu przegubowego wszystkimi drzwiami czy o braku wykonania krzywego przegubu nawet nie wspomnę. :)

Warto spróbować stworzyć nową (zaawansowaną technologicznie – a to zapewnia użycie gotowego silnika) wersję vBusa, ale bez jakiejś dzikiej konkurencji z Niemcami. VirtualBus jest starszy od ich produktu, zawsze był darmowy, tworzony przez hobbystów. Niech tak zostanie. Tamten symulator żyje swoim rytmem, pojawiają się do niego nowe dodatki, ale to wcale nie wyklucza możliwości stworzenia czegoś innego. :D

Cytat

To może zrobić jakąś listę?
Nie wiem, czy to ma sens. Obecnie Ty prowadzisz prace, to Twoja aplikacja i Ty decydujesz, co i kiedy zrobisz. Ja mógłbym napisać, jaka jest moja koncepcja i jak mógłby wyglądać nowy VirtualBus, ale nie mam wiedzy z zakresu informatyki i nie napiszę Ci, za pomocą jakiej techniki możesz zrobić to czy tamto.
Na pewno warto już teraz zadbać o to, żeby aplikacja była dostępna w wielu językach - czyli wszystkie elementy GUI, menu itd. wykonać tak, żeby napisy, komendy itd. były wczytywane z odpowiedniego pliku językowego.
No i warto skorzystać z tego, że Unity obsługuje wiele platform i postarać się, żeby aplikacja była dostępna również dla posiadaczy Linuxa.

#432
Kiciuszek

Kiciuszek
  • Developerzy
  • 39 Posts:
23
>Użytkownik uruchamia symulator na swoim komputerze -> aplikacja pobiera powyższe dane z serwera, generując ruch uliczny – dla każdego gracza taki sam....


Nawet nie rozważałem takiego rozwiązania. Gównie z tego powodu że wtedy samochody powinny się poruszać tak samo bez względu na zachowanie kierowcy autobusu - co jest niemożliwe bo autobus ma wpływ na ruch. Np. jeśli wyjeżdżam z zatoczki to albo przepuszczę więcej samochodów, albo brutalnie wyjadę korzystając z tego ze samochody powinny mnie puścić. Na następnych światłach zdążę i przejadę na żółtym, albo się zatrzymam i już jest desynchronizacja ruchu, której skutki (inaczej jadące samochody) będą się powiększać i rozprzestrzeniać.




>Ja myślałem o trybie multiplayer bardziej w kontekście „wirtualnego CB Radia” związanego z daną mapą – przydatne w vFirmach.

Można mieć odpalonego w tle Team Speak'a.

Na razie żeby to ogarnąć widzę opcje którą można by zrobić (jak zaqumam siec w unity):
Zignorować całkowicie ruch uliczny i inne autobusy. Zrobić opcję postawienia serwera przez dyspozytora i opcję dołączenia się do serwera po IP (stawiający serwer musiałby zadbać o udostępnienie portu za NAT'em – czyli skonfigurować port na swoim „modemie”).

Wtedy dyspozytor maiłby widok na mapę z góry i pozycję autobusów. Gdyby to bardziej rozwijać to można by dodać jakieś włączane przeszkody typu remont ulicy (losowo lub przez dyspozytora).

>już dawno powinniśmy podziwiać w pełni funkcjonalne samochody osobowe, ciężarówki z naczepami, tramwaje, lokomotywy, a może i samoloty.

Tylko czy to ma sens. Jak to mówią jeśli coś jest do wszystkiego to jest do niczego :)

>Własny, dla wielu niezrozumiały, język skryptowy;

No tu musiałbym zastosować też jakiś język skryptowy (co i tak jest dużym osiągnięciem programistycznym) i problem byłby podobny, bo interpretera jakiegoś rozbudowanego języka istniejącego bym nie napisał.



Ogólnie to trochę przeraża mnie implementacja wszystkiego i dojście do poziomu VBusa. Chyba lepiej wolę podchodzić do tego że piszę sobie takiego wirtualnego PKS'a, a co z tego wyjdzie zobaczymy.

#433
PKS

PKS
  • Użytkownicy
  • 104 Posts:
10
Nie znam tajników tworzenia serwerów i baz danych. Nie wiem, czy w ogóle jest sens poświęcać więcej czasu rozmowie o multiplayerze. Być może jest tak, jak piszesz. Ja wyobrażałem to sobie tak, że sposób zachowania AI w różnych sytuacjach jest zawarty w aplikacji zainstalowanej na komputerze. To, że samochód AI zatrzymuje się, żeby wypuścić mnie z zatoki, jest określone w kodzie odpowiadającym za AI. Do serwera przesyłane jest wtedy info typu:

Cytat

Pojazd[10]: obecna lokalizacja (x,y,z), obecna prędkość (0)
W odpowiedzi na to auta AI znajdujące się za naszym pojazdem 10. zatrzymują się - i ich pozycja i prędkość również są na bieżąco aktualizowane w bazie danych. Jednocześnie dane są aktualizowane i odczytywane. <- To tak na "chłopski rozum", a czy to się da zrobić i jak - nie wiem.

Twój pomysł odnośnie sieci też jest bardzo dobry.

Cytat

Tylko czy to ma sens. Jak to mówią jeśli coś jest do wszystkiego to jest do niczego :)
To już kwestia indywidualnego podejścia i oceny. Ja uważam, że powinno się wykorzystać wszystkie możliwości, jakie nam daje aplikacja. Wykonanie przez kogoś porządnej osobówki czy ciężarówki w żaden sposób nie uniemożliwia innym tworzenia w tym czasie nowych autobusów i map. Każdy robi swoje.
Jeśli miłośnicy np. pojazdów szynowych zobaczą, że dana aplikacja pozwala symulować również ich ulubiony środek transportu, to ją pobiorą - zwiększy się popularność symulatora. Większe zainteresowanie -> więcej użytkowników -> więcej dodatków. Skorzystają chyba wszyscy.

Cytat

No tu musiałbym zastosować też jakiś język skryptowy (co i tak jest dużym osiągnięciem programistycznym) i problem byłby podobny, bo interpretera jakiegoś rozbudowanego języka istniejącego bym nie napisał.
No przecież skrypty dla Unity tworzy się w C#, Java Script lub Boo, są to języki (zwłaszcza dwa pierwsze) ogólnie znane, jest mnóstwo kursów itd.

Cytat

Chyba lepiej wolę podchodzić do tego że piszę sobie takiego wirtualnego PKS'a, a co z tego wyjdzie zobaczymy.
No jasne. Najgorzej to sobie z góry założyć, że zrobi się nie wiadomo ile i się później rozczarować. Rób swoim tempem, dodawaj takie funkcjonalności, które Ty uważasz za potrzebne. Nie ma sensu robić wszystkiego na raz.

Kończę się wymądrzać, bo i tak nie znam się na tej informatycznej stronie całego projektu. Ty ogarniasz temat, pewnie wiesz, co robisz.
Powodzenia! :)

#434
2242

2242
  • Użytkownicy
  • 23 Posts:
12
Na większości istniejących map między asfaltem a trawą czy znakami poziomymi są przeskoki kilkucentymetrowe, dzięki którym nie migają tekstury.
I czy takie zbudowanie tras mogłoby powodować np tzw "niewidzialne ściany"?

#435
Kiciuszek

Kiciuszek
  • Developerzy
  • 39 Posts:
23
>Na większości istniejących map między asfaltem a trawą czy znakami poziomymi są przeskoki kilkucentymetrowe, dzięki którym nie migają tekstury.
I czy takie zbudowanie tras mogłoby powodować np tzw "niewidzialne ściany"?

Wystarczy wyselekcjonować jeden obiekt żeby miał ciało fizyczne, a pozostałe zostawić tylko jako wizualne. (Swoją droga można używać offsetu bufora Z zamiast podnoszenia obiektu, ale nie wiem czy VBus to wykorzystuje)


>No przecież skrypty dla Unity tworzy się w C#, Java Script lub Boo, są to języki (zwłaszcza dwa pierwsze) ogólnie znane, jest mnóstwo kursów itd.

Tak, tylko do tego żeby używać skrypty Unity trzeba mieć cały projekt w unity i pisać skrypty. Większość użytkowników zrezygnuje jeśli będzie miało przegryźć przez taki kombajn jak Unity i w dodatku myśleć obiektowo i znać mechanizmy języka i struktury.

Liczba dobrych grafików/modelarzy a zarazem programistów jest niewielka.

Jeśli by wyrzucić to poza Unity, to musiałbym napisac interpreter danego jezyka, a to jest poza moimi mozliwościami jesli chodzi o C#, JS, Boo.

#436
fr0zi

fr0zi
  • Developerzy
  • 280 Posts:
34
Właśnie ta sprawa "modowania" gier w Unity mnie zastanawiała. Unity udostępnia C#, Java Script oraz Boo, ale to są zwykłe języki programowania - kod zostaje "wkompilowany" w plik wynikowy gry i nie można go już potem modyfikować. To jest po prostu kod gry, który mówi co i jak ma się zachowywać.

Skryptowanie zewnętrznych dodatków, to zupełnie co innego. Torque 3D używa w tym celu swojego języka skryptowego - Torque Script. Można zdziałać nim sporo rzeczy, od konfiguracji obiektów do określenia ich zachowań. W Unity trzeba by to jakoś inaczej rozwiązać. Pisanie języka skryptowego, to faktycznie nie jest kaszka z mleczkiem. Można by wziąć pod uwagę użycie np. Lua. Wtedy zostałoby "jedynie" podłączenie pod grę interpretatora tego języka :) Zwracam uwagę na słowo "jedynie". Zrobienie czegoś takiego w swoim kodzie jest dość proste (sam robiłem to jeszcze za czasów zabawy Irrlicht + Bullet), ale podłączenie tego pod gotowy silnik, np. Unity, jest trochę bardziej skomplikowane. Ale chyba warto to rozważyć.

Ja osobiście bawię się silnikiem Torque 3D. W dużej mierze pod kątem wykorzystania go pod grę typu VBus lub podobną. Grzebię w kodzie silnika, modyfikuję... Może coś mi z tego wyjdzie :)
Unity jest ciekawe i z Twoich pokazowych screenshootów widać, że ma duże możliwości. Jednak trochę nie podoba mi się właśnie ta jego "zamkniętość" :)

Mimo wszystko życzę Ci powodzenia w pracach :)

PS. Co to listy rzeczy do zrobienia, to myślę, że to dobry pomysł :) Dobrze jest mieć coś, to będzie kierunkować Twoją pracę. Czasami taki plan, choćby ogólny, pomaga skupić się na problemie :)
CPU & RAM: AMD FX 8120 @ 3.1 GHz & Kingston 8 GB DDR3
GFX: Sapphire Radeon RX 480 8GB GDDR5
OS: Windows 10 Professional 64-bit

Zasilacz: OCZ CoreXStream 500W
Obudowa: Fractal Design Define R3

#437
PKS

PKS
  • Użytkownicy
  • 104 Posts:
10

Wyświetl postUżytkownik fr0zi dnia 24 May 2015 - 13:16 napisał

Można by wziąć pod uwagę użycie np. Lua. Wtedy zostałoby "jedynie" podłączenie pod grę interpretatora tego języka :) Zwracam uwagę na słowo "jedynie". Zrobienie czegoś takiego w swoim kodzie jest dość proste (sam robiłem to jeszcze za czasów zabawy Irrlicht + Bullet), ale podłączenie tego pod gotowy silnik, np. Unity, jest trochę bardziej skomplikowane. Ale chyba warto to rozważyć.

Niektórzy to już rozważyli :D
Za darmo:
SLua - dość aktualne
Unity Lua Interface Library - trochę starsze od powyższego, ale może działa z Unity 5.0.X

Płatne:
Lua Framework 15$
uLua Tu trochę zaszaleli z ceną - 40$, ale ten dodatek obsługuje różne platformy, jest rozbudowany.

Właśnie to jest jedna z niepodważalnych zalet Unity - olbrzymia społeczność i różne gotowe dodatki/rozszerzenia. Niestety te najlepsze kosztują i to nie mało.

Przy okazji:
Całkiem fajne darmowe narzędzie do tworzenia dróg:
EasyRoads3D Free

:)

A na temat modowania gier stworzonych w Unity można poczytać tutaj:
Kilka słów o Cities: Skylines
O modowaniu gier w Unity
Wszystko po angielsku, niestety.

Wszystko jest możliwe, ale nie jest proste i niesie za sobą ograniczenia - np. co do obsługiwanych platform.
Użytkownik może tworzyć własne skrypty dzięki Lua, ale należy się zastanowić, jak rozwiązać problem wczytywania np. nowych modeli 3D (np. nowe autobusy). Pewnie trzeba napisać samodzielnie jakąś zewnętrzną aplikację albo DLLkę. Ktoś tam wspominał, że zrobił takie narzędzie w Unity.

Nie wygląda to za ciekawie. Najlepiej byłoby pracować z całym projektem, ale - jak już Kiciuszek zauważył - komu się będzie chciało instalować całe Unity i cały projekt nowego VirtualBusa tylko po to, żeby np. zmienić jeden domek na mapie albo dodać drzewo/lampę.

**********EDYCJA**********

Trochę dzisiaj poczytałem na temat możliwości Unity związanych z wczytywaniem zawartości "z zewnątrz gry" w runtimie (podczas gry). Nie jest wcale tak strasznie... :D
Przede wszystkim polecam stronę:
http://it-ebooks.info
Jest tam dostępnych dużo eBooków dotyczących m. in. Unity.

W książce "Unity 4.x Cookbook" są 2 rozdziały poświęcone wczytywaniu kontentu z zewnątrz (przykłady - gotowy kod).

W katalogu gry mamy folder Resources, gdzie wrzucamy dane, które wykorzystuje nasza aplikacja.
Za wczytywanie tych danych odpowiada klasa WWW.
Opis klasy WWW
Wczytywane mogą być: AssetBundle (o tym niżej), plik audio (format .ogg), pliki .byte (służą m. in. do szyfrowania danych), filmiki (Ogg Theora), zawartość pliku tekstowego, tekstury (różne rozszerzenia).
Klasa WWW umożliwia wczytywanie danych z internetu lub bezpośrednio - zapisanych na dysku twardym.
Jak widzicie, nie można w ten sposób wczytać modelu 3D, ale:

Bardzo interesującą opcją jest tzw. AssetBundle. Tworzysz np. autobus -> model 3d + tekstury/materiały + animacje + dźwięki + ustawienia oświetlenia + skrypty. Tworzysz z tego AssetBundle, np. JelczPR110DbyAutor. To tak jakbyś wszystko spakował do .zipa albo .rara. Użytkownik pobiera dodatek, umieszcza go w odpowiednim folderze i korzysta :)
Oczywiście to samo dotyczy map. Prawda jest taka, że to Ty decydujesz, co umieścisz w danym AssetBundle, może to być autobus, mapa, a może to też być jedynie kierownica albo drzewo. Jest to po prostu dodatkowa zawartość, którą dodajesz do gotowej gry, bez ingerencji w źródła aplikacji.

Warto się z tym zapoznać:
Obszerny tutorial dotyczący AssetBundles + dyskusja na forum
AssetBundle w Unity5
Dokumentacja

Do stworzenia AssetBundle konieczna jest instalacja Unity, z drugiej jednak strony: To jest wbrew pozorom dobre rozwiązanie, bo wrzucasz wszystkie elementy składowe do Edytora, możesz je przetestować, po czym "pakujesz" je w całość i udostępniasz innym użytkownikom.

Ja to obecnie widzę tak:
- skrypty - Lua, bez wrzucania ich do AssetBundle, żeby użytkownik mógł je modyfikować bez instalowania całego Unity,
- modele3D (meshe) - jako AssetBundle (te pliki mogą być szyfrowane, jak w niemieckim symulatorze),
- tekstury - te, które użytkownicy będą przerabiać (jak np. malowania) - wczytywane bezpośrednio, inne - mogą być jako AssetBundle.
Nad resztą się trzeba zastanowić.

Jak widać, modowanie gier stworzonych w Unity wcale nie musi być takie karkołomne. (Chociaż to się jeszcze okaże :D )
AssetBundle jest dostępne dla każdego dopiero od Unity 5.0.0, wcześniej wchodziło w skład wersji PRO, dlatego mało o tym pisali na różnych forach.

********** EDYCJA 2 **********
Są dostępne gotowe narzędzia dla Unity do importu modeli 3D/tekstur w różnych formatach w runtimie, ale zazwyczaj są one drogie i nie zawsze działają jak należy (jak np. to).
Znalazłem jednak pewne repozytorium na Githubie, jest to importer .fbx. Nie ma do tego niestety żadnej instrukcji ani licencji. Jest tylko opis - plik readme.

Jeśli chodzi o Torque3D to na pewno bardzo przydatne jest to, że edytor wbudowany jest bezpośrednio w naszą aplikację - po prostu w menu jest opcja "Edytor".
BeamNG (darmowe demo - można sobie pobrać i zobaczyć, jak działa aplikacja wykonana dzięki Torque3D - na fizykę nie patrzcie, bo to jest efekt pracy deweloperów BeamNG, a nie Torque3D, więc trzeba sobie ją samemu napisać) jest dowodem na to, że w tym silniku można wykonać "samochodówkę" z bardzo atrakcyjną grafiką. Nie ma też żadnych problemów z importem wszystkiego w runtimie (= możliwe modowanie).
Jeśli ktoś chce przetestować, proszę: Torque3D 3.8
Silnik udostępniony jest na licencji MIT.

Uważam, że Kiciuszek może nadal walczyć z Unity (jeśli chce). W końcu wykonał już kawał dobrej roboty i szkoda byłoby to tak od razu zostawiać przez te problemy z modowaniem. Warto zastanowić się nad tymi AssetBundles, o których ostatnio pisałem (w kotekście wczytywania modeli 3D w runtimie). Z drugiej jednak strony należałoby sprawdzić, czy można tak po prostu odpalić Unity, zaimportować jakiś model 3d, zrobić z niego AssetBundle i wkleić to później do folderu z assetami dla naszej aplikacji (żeby się przekonać, czy twórca dodatków na pewno nie musi mieć u siebie na kompie całego projektu nowego VirtualBusa).

Jest jeszcze jedna kwestia, która mnie zastanawia: Praca z edytorem Unity jest bardzo wygodna - wczytuję model 3d, umieszczam go w odpowiednim miejscu sceny. Ładuję również odpowiednie tekstury, mogę eksperymentować z materiałami, shaderami itd. Piszę i od razu testuję skrypty odpowiadające za różne zachowania obiektów, przypisuję optymalne wartości różnym zmiennym itd. Pracuję z dźwiękami. Wszystko mam w jednym miejscu - w edytorze Unity, a poszczególne elementy tworzą razem konkretną całość (np. autobus).
Pytanie brzmi: Jak Waszym zdaniem użytkownik ma bez korzystania z edytora Unity stworzyć kompletny i dopracowany dodatek? Ja uważam, że to jest po prostu niemożliwe.
Główny problem polega na tym, że edytor nie jest wbudowany w naszą aplikację, lecz stanowi inne, znacznie bardziej rozbudowane i skomplikowane w obsłudze narzędzie. Tutaj pole do popisu będą mieć twórcy tutoriali - jeżeli użytkownikom wytłumaczy się wszystko krok po kroku, to zainstalowanie Unity i korzystanie z niego w celu stworzenia dodatku nie będzie problemem, pod warunkiem że nie będzie konieczna ingerencja w projekt całej gry i tworzenie własnego kodu w C#. Jeśli chodzi o skrypty w Lua, można napisać przykładowe gotowce, na których będą bazować moderzy (tak jak było z niemieckim symulatorem - większość do dziś używa skryptów dołączonych "fabrycznie" do tamtego symka, jedynie je modyfikując).
Zastanawia mnie jeszcze jedno - czy użytkownik będzie mógł tworzyć nowe funkcjonalności dla różnych assetów? Czy to wszystko musi być najpierw zrobione w C#, żeby później było osiągalne z poziomu skryptu stworzonego przez użytkownika w Lua? Chodzi mi o skrypty odpowiadające np. za różne awarie pojazdu. Przykład: Po kilku latach eksploatacji (w realu np. 300 tys. przejechanych kilometrów - w symulatorze mogłoby być mniej, bo chyba nikt nie będzie jeździł codziennie przez 9h :D  ) zmniejsza się dynamika pojazdu (maleje przyspieszenie itd. - pojazd się "starzeje"). Albo: Jeżeli otwieram/zamykam drzwi podczas jazdy (częsty błąd kierowców PKS, tak się psuje drzwi w autobusach!), to po jakimś czasie drzwi nie domykają się (uszkodzone/wypaczone prowadnice). <- ja wiem, że to brzmi "egzotycznie", ale chciałbym wiedzieć, czy twórca dodatku mógłby bez problemu to oskryptować w Lua, bez ingerencji w główny kod gry w C#.

This post has been edited by PKS: 18 November 2015 - 15:19