Błąd wyświetlania lokomotyw z widocznym wnętrzem od zewnątrz, ale tylko w nocy.

[HTD]

Na TD, na sceneriach dziennych ta lokomotywa wygląda prawidłowo. Można się przykładowo wychylić przez okno i nadal widać haslera. Na scenerii Całkowo noc niestety wychylenie przez okno powoduje, że wnętrze lokomotywy znika w miejscu zasłoniętym przez okno. Widok od zewnątrz jest OK. Problem występuje tylko gdy siedzi się wewnątrz kabiny i wychyla przez okno.

[Stele]

Kolejność renderowania elementów zależna od oświetlenia atmosferycznego? Paranoja. Sprawdź jak jest w 4e. Mają wnętrze zrobione identyczną metodą. Dziś już nie mam siły tego badać.

[HTD]

Paranoja! Faktycznie jest tak jak piszesz. Ustawiłem sobie 23:50 w TD, ustawienia nieba "night" (wklejone z Rainsted.ini).
Wkleiłem sobie 4E-150, i ten sam efekt. Kabina od zewnątrz (F4) wygląda normalnie, od wewnątrz też normalnie. Ale jak zapalisz światło w środku i strzałką wyjedziesz za okno, wtedy jest ten sam efekt co na poprzednim screenie - część za oknem jest niewidzialna, ale tak jakby ktoś wyciął dziurę w całym modelu.

Nie będę wklejał screena teraz, bo na musiałbym pokombinować z trochę jaśniejszą nocą, zrobiłem ciemną jak w d. u Murzyna więc od zewnątrz ledwo co widać, a z wychylaniem przez okno jest dokładnie taki sam efekt jak na Całkowie.

Oczywiście na td w dzień nie ma tego problemu i kabina jest widoczna z każdego położenia prawidłowo.

[Stele]

W dzień nie widać szyb z zewnątrz przy wyjściu za okno w kabinie. Tylko one powinny być w lowpoly i nigdy się nie wyświetlać z kabiny. Tajemnicza sprawa. Obadaj proszę na jakimś exeku ze starą smugą albo z parametrem na starą smugę w ini. Choć wątpię by tu coś się psuło, ale nic innego zależnego od oświetlenia w renderowaniu mi nie przychodzi do głowy. Zapalenie światła w kabinie nie ma znaczenia u mnie. Przy zgaszonym też kabina znika.

[HTD]

Sprawdziłem na exe 472, jest stara smuga, ten sam błąd. W dzień bangla, w nocy nie bangla.

Tak na marginesie - czy jest jakaś szansa, że smuga będzie jeszcze poprawiona? Jechałeś z nową smugą na Quarku? W niektórych sceneriach nowa wygląda dużo lepiej, ale w niektórych mocno kaszani kolory. Wydaje się jakaś zbyt jaskrawa. Część semaforów wygląda w niej całkowicie dobrze, a część zamiast czarnej obudowy ma jakieś pstrokate zacieki, okropne pixle, do tego wszystkie światła robią się białe i tylko po położeniu komory można rozpoznać jaki sygnał dają. Co mnie uderzyło w starej smudze - że rozświetla delikatniej, bez przepalania kolorów czy zastępowania czarnych rzeczy pstrokatymi. Ogólnie światła na sceneriach wyglądają paskudnie (niezależnie od smugi), ale z nową smugą - jeszcze gorzej. Jedyny plus, że faktycznie nowa smuga poprawia widoczność - jest brzydziej, ale widać więcej.

[Stele]

Stara smuga nie rozświetla. Nowa albo będzie idealnie biała, co nie wygląd dobrze nigdy, albo będzie przekłamywać barwy. Jak ktoś ma pomysł jak zrobić lepszą na OGL bez shaderów, to jestem otwarty na propozycje.
Obecna działa na funkcji glBlendFunc(GL_DST_COLOR, GL_ONE); czyli tworzy sumę bitową wartości RGB piksela sceny i piksela smugi. Smuga jest żółtawa, więc barwy są fałszowane w tym kierunku. Jest to nakładane po renderowaniu świata, więc nijak świetlistość obiektów tła na to nie wpływa. Obiekty świecące są bliskie bieli, więc dodatkowo oświetlone się przepalają.
Stara działała na glBlendFunc(GL_ONE_MINUS_SRC_ALPHA, GL_ONE); czyli tylko nakładała świecący placek na scenę, zakrywający tło.
Mam kilka pomysłów na ficzery związane ze smugą, ale nic tego kluczowego problemu nie rozwiązuje. Myślę nad wydzieleniem smug świateł statycznych do osobnej fazy renderowania, ale byłaby z tym masa roboty, nie wiem czy bym podołał, nie wiem jaki efekt by to dało i czy nie zbiłoby fpsu o 1/3.

[HTD]

Zauważyłem. Ciekawe dlaczego część semaforów wygląda całkowicie dobrze w nowej smudze (np światła nie zmieniają kolorów w ogóle), a część wygląda tragicznie. Takie np drzewa i krzaki na Całkowie wyglądają dobrze, część wskaźników wygląda całkiem dobrze, ale część (w szczególności We9) wyglądają źle.

Ogólnie rozwijanie czegoś tak archaicznego to syzyfowa praca i wygląda przygnębiająco. Nic, trudno, w tym roku nie ma szans, żebym mógł z tym powalczyć, ale może w przyszłym się uda.

Jak myślisz, czy wymiana silnika graficznego na inny jest w ogóle możliwa, czy wymagałaby raczej napisania symka od nowa?

[firleju]

Teoretycznie się da. Ale tylko jeśli to jest osobna biblioteka a nie cały silnik, gdyż wtedy to jest przepisywanie od nowa. Zresztą i tak to jest przepisywanie gdyż Borland raczej nie skompiluje się z nowymi bibliotekami (chociaż mogę się mylić). Ja ogólnie trafiłem na taką, która kompiluje się wraz z kodem i klops.
Nadzieja jest taka, że właśnie bawię się w konwersję kodu na C++ więc jest szansa, że ruszy coś z miejsca. Ale patrząc na tempo to jeszcze rok potrwa.

[HTD]

Hm, to jak już robisz konwersję (czyli w zasadzie przepisujesz od nowa?) może warto pomyśleć o oddzieleniu grafiki od reszty? Właśnie na tym polega główne ograniczenie: napisanie własnego silnika graficznego to wyzwanie niemożliwe do wykonania, a nawet gdyby znalazło się kilka genialnych osób dysponujących nieograniczonym czasem - to i tak silnik nie będzie odporny na starzenie, dodawanie nowych możliwości będzie trwało wieki i będzie to mogła zrobić tylko garstka najgenialniejszych developerów, prawdopodobnie - sami autorzy. Pisanie silników graficznych czy robienie grafiki 3D od zera kojarzy mi się z pisaniem własnych systemów operacyjnych (vide TempleOS). MaSzyna ma własny silnik. Odpowiednik TempleOS-a. Nawet nieskończenie ulepszony oryginalny silnik będzie nadal tak samo oporny w dalszym rozwoju. Ba - w pewnym momencie ten rozwój musi się zatrzymać bo rozbije się o niekompatybilność z nowym sprzętem.
Tak już jest. Jak ktoś ma zacząć pracę od "narysuj trójkąt" - to masz tyle chętnych do pracy ile masz. Czyli mija kilka lat, wychodzą kolejne generacje komputerów i kart graficznych, a w MaSzynie dalej to samo. Z gotowym silnikiem zaczynasz od "wgraj modele i tekstury, ustaw oświetlenie...", kończysz na "przesuń punkt lub bryłę". Światła? Nie musisz robić, są. Szyby, lustra? Nie musisz robić, są. Chcesz deszcz i śnieg? Masz. Chcesz zderzenia i uszkodzenia? Masz PhysX (albo odpowiednik). Chętnych do pracy więcej. Po roku pracy (oczywiście po godzinach) masz coś co wygląda lepiej od Trainza. Nie widziałem Trainza na żywo, tylko recenzje. Z tego co widziałem i słyszałem - fizyka maszynowa jest lepsza. Gdyby dało się ją wydzielić do osobnych, najlepiej wysokopoziomowych modułów - to byłby początek MaSzyny 2.0. Do tego masz rozwój silnika graficznego przez lata gratis. Duże silniki graficzne są darmowe dla projektów niekomercyjnych. Gdyby myśleć o wersji komercyjnej - to byłaby wystarczająco mocna rzecz żeby opłacało się nawet zapłacić za silnik. Pisząc "mocna" mam na myśli możliwości szybkiego, dynamicznego rozwoju przez dużą bazę developerów. Przy okazji - mając silnik i moduł zdolny po prostu wyświetlać scenerie - zrobienie edytora 3D byłoby w zasadzie "przy okazji" tworzenia samego symka. Podstawowe funkcje "gratis", zaawansowane robią już ludzie, którzy mogą nie mieć bladego pojęcia o shaderach i grafice, za to pojęcie o budowie torowisk, trakcji, SRK itd. To jest IMHO możliwe do zrobienia. Taki POC do upgradu grafiki wyglądałby tak: wgraj T3D/E3D, wgraj tekstury od dowolnego obiektu i wyświetl. Od tego punktu już z górki. Z tego co wiem to kwestia konwersji formatów, do zrobienia właściwie przez każdego programistę, bez względu na specjalizację. Każdy silnik ma jakiś format modeli i tekstur. Kolejny etap to zbudowanie 2 warstw i API pomiędzy nimi. Tą drugą, na razie malutką jest dziś Python. Ja bym tam wolał C# (dużo szybszy, lepsza współpraca z kodem natywnym), ale może wystarczy. Jeśli możesz z wysokiego poziomu dać "przesuń obiekt nr xxy do x, y, z" - to w zasadzie pozamiatane. Cała fizyka mogłaby działać na wysokim poziomie. Przede wszystkim - całe sterowanie - w stylu ten przycisk czy gałka zmieniają tę lub inną zmienną. Rzeczy w stylu otwieranie drzwi, czy nawet wyjeżdżające schody w ED250 byłyby trywialne do napisania z wysokiego poziomu. Problem świateł peronowych czy pojazdów po prostu by zniknął. Kwestie pogody i pory dnia by zniknęły. Światło i cień gratis. Jeśli model miałby ruchomą część - animujesz z wysokiego poziomu. Dodatki powstawałyby w takim tempie, że trudno byłoby nadążyć.

Rozumiesz o co mi chodzi? Jest tysiące developerów ogarniających game-dev, ale takich, co ogarniają techniczne aspekty kolejowe w stopniu wystarczającym - na palcach jednej ręki. Dodatkowo wiedza magików tworzących modele i scenerie trafia na ścianę siermiężnych narzędzi, przez którą muszą włożyć ogrom mrówczej pracy żeby zrealizować swoją wizję. To co opisałem to trudny, wymagający scenariusz, ale chyba jedyny zdolny reanimować MaSzynę tak, żeby nie stała się na wpół opuszczonym zabytkiem w ciągu najbliższych kilku lat. Wiem, popłynąłem w fantazję ;)

[Mariusz1970]

Kierunek dobry, wielokrotnie poruszany, ale jest maly problem - brak chetnych do realizacji. Moze chcialbys sie podjac tego malego zadanka? ;)

[HTD]

Jasne, że byłbym, tyle że nie mam szans w tej chwili, tj w tym roku. W skrócie - założyłem firmę (IT), jak się rozkręci, będę mógł pomóc. Póki co mogę tylko jeździć i zgłaszać bugi, względnie dzielić się wariackimi pomysłami. Nie mogę się doczekać kiedy będę miał wreszcie trochę czasu żeby zacząć działać w temacie. Od wyświetlenia słynnego EU07-424 oświetlonego realistycznie piękną lampą peronową pójdzie z górki ;)

[Mariusz1970]

To zycze powodzenia w rozkrecaniu firmy :), a Maszyna, a Maszyna poczeka na Ciebie, bo raczej nikt inny nie podejmie sie tego. No chyba, ze zdarzy sie cud :)

[firleju]

Adam, nie żebym był jakimś prorokiem, ale właściciele firm raczej nie znajdują więcej czasu wraz z rozwijaniem się biznesu.

[HTD]

Masz rację, to jest trudne, aczkolwiek wykonalne.