Symulator EU07 (i nie tylko) > Poszukuję, chcę zrobić
Edytor Scenerii
marcinn:
Cześć.
1. Dziękuję Ra za objaśnienia. Nie dyskutuję, bo wszystko zostało napisane. Mój wniosek: nie powstanie drugi Rainsted
2. Podzielam zdanie @jakubg1, że prosty edytor scenerii / całości dałby więcej nowych tras i byłaby to wartość dodana. Mój młody chce się bawić, ale przecież nie Rainstedem. Niższa jakość tras? Bez znaczenia. Nie muszą trafiać do paczki. Zrobi się serwer z addonsami do pobrania, i kto będzie chciał to sobie polata po „gorszych”, ale będzie miał fun. Teraz mamy do wyboru: HQ raz na X lat, albo nic. A to co jest, już zostało oblatane do znudzenia.
3. Pośrednio związane: Dlaczego trzeba dodawać „ścianę lasu” a nie las? Potrzebny jest tylko mesh instancing z lod, a las proceduralnie wygeneruje edytor. Kosztem będzie tylko większy plik scn/inc, chyba że doda się generator do silnika a w scn/inc zadeklaruje tylko obszar, meshe, gęstość i ziarno. Ściana z lasem trąci latami 90-tymi.
4. Edytor musi być crossplatform lub platform independent, także dla devów. Nie musi a nawet nie powinien to być w c++, tylko w języku/-ach wysokiego poziomu. Edytor powinien mieć autosave i/lub commitlog - żadna robota nie może się stracić po crashu.
Z pkt. 1 i 2 wynika, że dodatkowy edytor nie będzie konkurował z Rainstedem, więc nie musi spełniać oczekiwań inżynierów (ci zostaną z Rainstedem). Co za tym idzie można go tworzyć niezależnie i mając na uwadze odbiorcę amatorskiego.
Pozdrawiam,
Marcin
marcinn:
--- Cytat: Toprus w 07 Maja 2023, 10:49:24 ---Popieram jednak bve2 pod tym względem, że największą bolączką scenerii jest dekorowanie.
--- Koniec cytatu ---
Analogicznie do wzmianki o „ścianie lasu” widziałbym proceduralne dekorowanie scenerii z opcją manualnego finetuningu (parametry, obszary exclude, ręczne sadzenie). Nie ma sensu siać traw i polnych kwiatków. To może ogarnąć edytor, a po stronie engine potrzebne minimum to wspomniany instancing plus jakieś rozwiązanie dedykowane dla trawska/zbóż.
Niech się ludzie skupią na dekoracji przestrzeni obiektów przemysłowych. Przy okazji - dobrze byłoby zrobić decale (bo chyba engine nie wspiera).
marcinn:
Odczytałem wstępnie pliki scn w Godot (całe levele, jeszcze bez torów). Na szybko wnioski: dopóki trawy, drzewa i inne złogi węgla będą wczytywane za pomocą includes z trójkątami, i zamiast jednego mesha obiekty będą poskładane z dziesiątek kąsków, to będzie lipnie z czasem ładowania a nawet renderingiem. A że format plików nie nadaje się do wczytywania sektorami, to ilość elementów powinna być jak najmniejsza. Edytora nie trzeba będzie pisać, bo Godot Editor daje się mocno rozbudowywać. Trzeba jednak ogarnąć edycję sektorami, bo edytor zamula przy rozbudowanych scenach.
Technika zapisu terenu w Maszynie jest ciekawa i została przemyślana pod kątem renderingu, choć nie czasu wczytywania (vide próby z sbt). Nie powinno się jej jednak używać do assetów statycznych czy zieleniny.
Parametryzowane meshe drzew czy traw są ciekawe, ale mało wydajne i lepiej mieć kilka modeli i dorzucić ich skalowanie w celu różnicowania (obok rotate).
Jak pozbędę się rażących baboli, to wrzucę jakiś filmik.
matek123:
Tu nawet nie chodzi o parametryzowanie drzew, tylko o wydajność, bo exe skleja wszystkie trawki o jednym materiale w jedno. Jakiś czas temu dopatrzyłem się, że na wrzosach było grass.t3d. Po zmianie na inc grywalność skoczyła.
Na upartego można w excelu albo zrobić mały programik, żeby przed edycją gras.inc podmienić na gras.t3d.
Najlepszym rozwiązaniem byłoby, żeby exe w t3d/e3d rozpoznawało czy obiekt zawiera jakieś animacje, czy nie (np kubły/ławki na peronach, trawa) i ich scalanie w jeden obiekt (tak jak geometrie na trójkątach terenu).
marcinn:
--- Cytat: matek123 w 25 Września 2023, 09:34:30 --- exe skleja wszystkie trawki o jednym materiale w jedno.
--- Koniec cytatu ---
To dobrze, choć to nie przyspieszy wczytywania. A odnosiłem się do użycia np. scenery/tree.inc, który ma parametryzowane wierzchołki trójkątów.
--- Cytuj ---Najlepszym rozwiązaniem byłoby, żeby exe w t3d/e3d rozpoznawało czy obiekt zawiera jakieś animacje, czy nie (np kubły/ławki na peronach, trawa) i ich scalanie w jeden obiekt (tak jak geometrie na trójkątach terenu).
--- Koniec cytatu ---
Edytor powinien mieć podobne rozwiązania. I dochodzimy do sytuacji, w której źdźbła w plikach scn/inc są niepotrzebnie podefiniowane jako pojedyncze obiekty z meshami inline. Każdy taki inc to koszt parsowania -> czas ładowania scenerii. Najtaniej byłoby zmienić sposób definiowania i renderowania trawska, a dla reszty powielanych modeli (lub kompromisem dla trawska na jakiś czas) - prostsze definiowanie w plikach scn (ew. w binarnym formacie) i renderowanie np z glDrawArraysInstanced (podzielonymi na sektory).
Przy czym exe w wątku edytora najmniej mnie interesuje - wskazuję tylko miejsca które są/będą przeszkodami przy wczytywaniu scenerii, bo dokładnie ten problem mam w edytorze - rendering jest szybki, ale wczytywanie scenerii jest czasochłonne. Szybciej jest wczytać jeden model i renderować go setki razy z nałożonymi transformami (obrót, przesunięcie, skala - oczywiście musi być shader do tego).
Nawigacja
[#] Następna strona
Idź do wersji pełnej