91
Tabor / Odp: Błędy związane z lokomotywą BR285
« dnia: 03 Lutego 2014, 13:04:52 »
A może to kwestia metody wyświetlania trójkątów z alphą?
Pokaż wiadomości
Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.
92
Bieżące Symulatorowe / Odp: Kwestia tekstur zimowych taboru
« dnia: 29 Stycznia 2014, 19:37:50 »
No ale z takim podejściem, to można iść dalej. Badziewnie wygląda lokomotywa wyjeżdżająca spod dachu (np. z lokomotywowni), cała ośnieżona.
Rzecz w tym, że śnieg jest nieco bardziej dynamiczny niż cała reszta, czasem się gromadzi, czasem odpada, czasem jest biały, czasem szary. Generalnie, jeśli ktoś by chciał przygotować kompleksowe opracowanie tego problemu, to oczywiście droga wolna, ale raz, że to będzie bardzo rozległe opracowanie, jako że problem jest dość złożony, a jest kilka rzeczy, które należałoby potraktować nieco bardziej priorytetowo. Z takich "dupereli" (nie mówię, że to są małe części symulacji, mam raczej na myśli to, że są daleko jeśli chodzi o priorytety), to może najpierw należałoby popracować nad symulacją efektów deszczu i śniegu na szybie/szybach oraz wpływie warunków atmosferycznych na te efekty (temperatura, względna prędkość wiatru), jak również wpływie zastosowania wycieraczek.
Rzecz w tym, że śnieg jest nieco bardziej dynamiczny niż cała reszta, czasem się gromadzi, czasem odpada, czasem jest biały, czasem szary. Generalnie, jeśli ktoś by chciał przygotować kompleksowe opracowanie tego problemu, to oczywiście droga wolna, ale raz, że to będzie bardzo rozległe opracowanie, jako że problem jest dość złożony, a jest kilka rzeczy, które należałoby potraktować nieco bardziej priorytetowo. Z takich "dupereli" (nie mówię, że to są małe części symulacji, mam raczej na myśli to, że są daleko jeśli chodzi o priorytety), to może najpierw należałoby popracować nad symulacją efektów deszczu i śniegu na szybie/szybach oraz wpływie warunków atmosferycznych na te efekty (temperatura, względna prędkość wiatru), jak również wpływie zastosowania wycieraczek.
93
Wydział zamówień / Odp: Zdjęcia na tekstury jednostek.
« dnia: 27 Stycznia 2014, 02:51:09 »
A i teraz chyba nie Warszawa Wola, a Warszawa Zachodnia Peron 8. Poza tym, z tego co pamiętam, na L009 była też relacja W-wa Wola - Nasielsk.
94
Tabor kolejowy / Odp: "Typy" dachów w L45H
« dnia: 23 Stycznia 2014, 03:16:51 »
Po czym wnosisz, że geometria dachu się czymś różni? Ja tam widzę wyraźną różnicę w malowaniu: biały pas jest wyższy (albo szerszy, jak kto woli) od szarego, stąd może bierze się złudzenie różnych wysokości. Zauważ sam, ze biały dach sięga do uchwytów oraz prawie do "końca" reflektora czołowego, natomiast szary jedynie do połowy klosza.
Merytorycznie Ci niestety nie pomogę (jeśli ktoś się wypowie, kto posiada jakąś wiedzę w temacie, to post ten można usunąć), natomiast na podstawie samych zdjęć, im dłużej na nie patrzę, tym bardziej wydaje mi się, że te dwa pojazdy nie różnią się wysokością, czy też kształtem dachu.
Merytorycznie Ci niestety nie pomogę (jeśli ktoś się wypowie, kto posiada jakąś wiedzę w temacie, to post ten można usunąć), natomiast na podstawie samych zdjęć, im dłużej na nie patrzę, tym bardziej wydaje mi się, że te dwa pojazdy nie różnią się wysokością, czy też kształtem dachu.
95
Bieżące kolejowe / Odp: E6ACT dla Lotos Kolej
« dnia: 22 Stycznia 2014, 15:28:51 »Do złudzenia przypomina malaturę PKP IC...Myślę, że nie tylko ja mógłbym z tym stwierdzeniem polemizować.
PKP IC ma również niebieskie czoło, z tym że na boku "niebieskie kropeczki" zajmują tylko pas w dolej połowie pudła, natomiast LK ma "niebieskie kropeczki" na całą wysokość boku pudła.
Nie jestem specem od malatur, ale wydaje mi się, że na przedstawionych zdjęciach Dragon nie odbiega malaturą od tej, którą nosi ten Traxx, nie jest też w żadnym stopniu bardziej podobny malaturą do tej, którą noszą loki PKP IC.
Reg. obowiązki 2.
Użyj opcji załącz, jeśli chcesz pokazać jakieś zdjęcia.
Benek
96
EU07 Simulator English forum / Odp: Amazing work thanks
« dnia: 20 Stycznia 2014, 00:25:19 »
Well, technically MaSzyna is based on Polish rail and it is in Polish language, but there is a Hungarian team that develops some kind of Hungarian MaSzyna. I can't tell you much apart from the fact that they are Hungarians (I didn't go through their forums, which I'm quite sure are in Hungarian, so that might not be possible for me anyways, apart from google-translated version of it). But what I think they do is they adapt MaSzyna to Hungarian rail system, in terms of vehicles, infrastructure, scenery style, etc.
And what it takes me sooo long to get at is, that I guess we are always open to new people (kinda) and I guess we're also open to new teams like the Hungarian one. So if there comes a group of people that would like to make a train sim based on MaSzyna and British rail system, or any other for that matter, I guess we could make it work.
As for graphics, I think that, of course, simulation part is by far most important and it should be (though some may argue that fact), though I can't agree with a statement, that a good sim mustn't look as good as it simulates. Moreover, I'm pretty sure, that appearances are very much persuasive as for the new 'clients' or community members. The graphics are actually the first thing that literally catches the eye. So they can't be neglected.
And good graphics are two things. They are good models, hi-poly with nice textures and stuff, but they are also good graphics engine, with shaders and all the other eye-candy, though still efficient, and in a way everything that comes in between the two, like the level of detail politics and many many more.
I am not really sure why did I elaborate that much on it, though I'd guess I tried to say we can do much in the second department, I mean the models, textures and stuff, but still we need someone who would be interested in working on improving the graphics engine.
I will definitely go through the sims you suggested as a research.
I gotta admit, though, I'm not a very big simulation person... : D I always admired the way this game is - let's say - 'complicated' in terms of gameplay and controls, and there have even been a time I could do all the procedures and operate the train like a pro driver (maybe not a pro, a layman rather, but still, it was fun), but getting inside of the game, as a dev, it just is a plenty of new ways rewarding and interesting and everything fun. Also, the simulation and the procedures developed, so I'm way behind and not sure if I could get a train running without a walkthrough.
And what it takes me sooo long to get at is, that I guess we are always open to new people (kinda) and I guess we're also open to new teams like the Hungarian one. So if there comes a group of people that would like to make a train sim based on MaSzyna and British rail system, or any other for that matter, I guess we could make it work.
As for graphics, I think that, of course, simulation part is by far most important and it should be (though some may argue that fact), though I can't agree with a statement, that a good sim mustn't look as good as it simulates. Moreover, I'm pretty sure, that appearances are very much persuasive as for the new 'clients' or community members. The graphics are actually the first thing that literally catches the eye. So they can't be neglected.
And good graphics are two things. They are good models, hi-poly with nice textures and stuff, but they are also good graphics engine, with shaders and all the other eye-candy, though still efficient, and in a way everything that comes in between the two, like the level of detail politics and many many more.
I am not really sure why did I elaborate that much on it, though I'd guess I tried to say we can do much in the second department, I mean the models, textures and stuff, but still we need someone who would be interested in working on improving the graphics engine.
I will definitely go through the sims you suggested as a research.
I gotta admit, though, I'm not a very big simulation person... : D I always admired the way this game is - let's say - 'complicated' in terms of gameplay and controls, and there have even been a time I could do all the procedures and operate the train like a pro driver (maybe not a pro, a layman rather, but still, it was fun), but getting inside of the game, as a dev, it just is a plenty of new ways rewarding and interesting and everything fun. Also, the simulation and the procedures developed, so I'm way behind and not sure if I could get a train running without a walkthrough.
97
Bieżące Symulatorowe / LoD a rozdzielczość
« dnia: 27 Września 2012, 20:12:28 »
Panowie, chciałem zwrócić waszą uwagę na pewną kwestię, dotyczącą LoD - mianowicie, dyskryminuje on duże rozdzielczości renderowania.
W czym jest problem? Otóż, jak wszyscy wiemy, u jednego hipotetycznego użytkownika, który korzysta z symulatora w rozdzielczości 1280x960px, dany model przechodzi z jednego LoD (Level of Detail) w drugi, kiedy odległość między kamerą a obiektem przekroczy wartości min-/maxdistance* kolejnych LoD, zajmując przy tym (model) określoną liczbę pixeli na ekranie. Natomiast u innego użytkownika, który korzysta z symulatora w rozdzielczości 2560x1920px, ten sam model, przy tej samej przejściowej odległości, będzie zajmował dwukrotnie większą ilość pixeli. Tzn. czterokrotnie większą - rozmiary (wys. i szer.) podwoją się, a jak wszyscy wiemy 2^2=4.
Teraz, zadajecie sobie waszmoście pytanie - okej, wymądrzył się za dwóch, a teraz niech powie czego chce.
Otóż, proponuję szeroko pojętą redefinicję systemu LoD MaSzyny. Rozwiązanie powyższego problemu jest dość proste, na dobrą sprawę wystarczy przeskalować podane wartości min-/max distance w zależności od używanej rozdzielczości ekranu, wcześniej przyjąwszy jakąś rozdzielczość za wyjściową (taka, której używamy przy testowaniu LoD, którego celem jest dobranie odpowiedniej bariery min-/maxdistance) - z zasady ludzie którzy używają symka w dużej rozdzielczości dysponują lepszym sprzętem, niż ci, którzy grają w mniejszej rozdzielczości, ponadto zmniejszanie rozdzielczości wyświetlania często służy zwiększaniu fps - dzięki takiemu skalowaniu ten efekt wzmógłby się dodatkowo; nie występuje natomiast żadne optyczne czy to polepszenie, czy pogorszenie grafiki albowiem wyjściowo rozdzielczość rasterowania poszczególnych trójkątów w tej samej scenie pozostaje taka sama niezależnie od rozdzielczości.
Skoro przedstawiłem proste, zarówno koncepcyjnie jak i w metodyce wdrożenia rozwiązanie - dlaczego proponuję szukanie bardziej zawiłych rozwiązań?
Pragnę w tym momencie zauważyć, że aktualny system LoD jest systemem bardzo prostym, takim, który nie bierze pod uwagę wielu czynników, natomiast nasza percepcja opiera się na dalece większej ilości owych. Weźmy na przykład prędkość względną obiektu, względem obserwatora - w rzeczywistości, przy prędkości 250km/h (inna rzecz, czy patrzymy z bocznej szyby, czy czołowiej) nie dostrzegamy wielu detali obrazu, widzimy go bowiem zbyt krótki czas.
Tu pojawia się kwestia, którą ktoś poruszał jakiś czas temu - modelując nastawnię dla niezelektryfikowanego (jeśli dobrze pamiętam), starego szlaku, po którym skład miał się poruszać z prędkością 40 czy 20km/h, zastanawiał się ten jegomość, czy wymodelować jej wnętrze i w ogólnej dyskusji tego zagadnienia dotyczącej stwierdził, że na takiej trasie warto to wnętrze wymodelować, ponieważ jadący 20km/h obserwator będzie miał czas, żeby po pierwsze dostrzec, po drugie przyjrzeć się bliżej, a po trzecie docenić detale. Analogicznie wiele obiektów przy dużej prędkości rozmywa nam się w motion blurze, nie dostrzegamy detali, a gdy jedziemy powoli, to te detale cieszą nas niezmiernie.
Innym przykładem niech będzie skład jadący równolegle z nami - wysoki poziom detali na takim wpływa bardzo pozytywnie na odbiór produktu, jakim jest symek, kto z nas, widząc inny skład, jadący równo z nami, w bocznej szybie, nie ma ochoty popatrzeć sobie nań, przyjrzeć się wszystkim detalom, których być może nie dostrzegliśmy w ujęciu statycznym - analogicznie powinien działa symulator, pozwalając nam nacieszyć się tymi smaczkami.
Proszę panów szanownych o przemyślenia w tym temacie, bardziej, lub może lepiej mniej luźne oraz ogólnie rzecz biorąc propozycje - od czego waszym zdaniem powinien uzależniony być LoD?
Apeluję też, by zastanowić się nad tematem w dwójnasób, czy może nawet rozważyć trzy punkty widzenia. Pierwszym niech będzie percepcja samego użytkownika, efekt wizualny. Drugim niech będzie wpływ na wydajność pracy. Na przytoczonych powyżej przykładach - piękny model nastawni, z wymodelowanym wnętrzem, etc, kiedy go mijamy z dużą prędkością, wyświetla się na ekranie tylko przez kilka klatek. Jaki jest więc sens po pierwsze ładować na żądanie wszystkie modele i tekstury LoD po kolei, tylko po to, by zaraz je wyrzucić, po drugie pokazywać model w detalu, którego przez prędkość właśnie nie dostrzeżemy, ergo pozytywny pływ na wydajność i fps, bo kiedy jedziemy tą samą trasę szybko, to ta sama ilość modeli musi wyświetlić się w krótszym czasie, a żeby się wyświetliły, modele muszą zostać wysłane do GPU, a zmieniając (w funkcji prędkości) LoD zmniejszamy ilość modeli do przesłania (szczególnie tych o dużej rozdzielczości siatki - obszerne i bardziej flopochłonne w renderowaniu) i tym samym odciążamy sprzęt.
Trzecim punktem widzenia niech będzie metodyka wprowadzania udoskonaleń do systemu LoD. Przytoczony na początku przykład skalowania LoD w zależności od rozdzielczości, jest bajecznie prosty - trzeba przeskalować (jak to @Ra określił - po chamsku) wartości min-/maxdistance i w sumie roboty jest dość. Bardziej zawiłe systemy, jak np. uzależnianie LoD od prędkości, są dużo bardziej skomplikowane w realizacji (pamiętajmy, że renderer nie widzi w ogóle takich rzeczy jak prędkość (chyba, że jako parametr wejściowy dla motion blura, czy innego efektu post-rastrowego) niezależnie czy względna, czy bezwzględna, fizyka zresztą też się w małym stopniu interesuje takim zagadnieniem, jak prędkość względna (chyba, że zderzają się dwa wagony i fizyka chce wiedzieć jak bardzo ma animować zderzaki), więc poza pomysłem ogólnie, potrzebny jest też pomysł na realizację zagadnienia.
* inna kwestia, że bardzo łatwo popsuć - np. podać rozbieżne wartości min-/maxdistance w kolejnych LoD
P.S. Proszę o poważne posty.
Zamykam.
adsim
W czym jest problem? Otóż, jak wszyscy wiemy, u jednego hipotetycznego użytkownika, który korzysta z symulatora w rozdzielczości 1280x960px, dany model przechodzi z jednego LoD (Level of Detail) w drugi, kiedy odległość między kamerą a obiektem przekroczy wartości min-/maxdistance* kolejnych LoD, zajmując przy tym (model) określoną liczbę pixeli na ekranie. Natomiast u innego użytkownika, który korzysta z symulatora w rozdzielczości 2560x1920px, ten sam model, przy tej samej przejściowej odległości, będzie zajmował dwukrotnie większą ilość pixeli. Tzn. czterokrotnie większą - rozmiary (wys. i szer.) podwoją się, a jak wszyscy wiemy 2^2=4.
Teraz, zadajecie sobie waszmoście pytanie - okej, wymądrzył się za dwóch, a teraz niech powie czego chce.
Otóż, proponuję szeroko pojętą redefinicję systemu LoD MaSzyny. Rozwiązanie powyższego problemu jest dość proste, na dobrą sprawę wystarczy przeskalować podane wartości min-/max distance w zależności od używanej rozdzielczości ekranu, wcześniej przyjąwszy jakąś rozdzielczość za wyjściową (taka, której używamy przy testowaniu LoD, którego celem jest dobranie odpowiedniej bariery min-/maxdistance) - z zasady ludzie którzy używają symka w dużej rozdzielczości dysponują lepszym sprzętem, niż ci, którzy grają w mniejszej rozdzielczości, ponadto zmniejszanie rozdzielczości wyświetlania często służy zwiększaniu fps - dzięki takiemu skalowaniu ten efekt wzmógłby się dodatkowo; nie występuje natomiast żadne optyczne czy to polepszenie, czy pogorszenie grafiki albowiem wyjściowo rozdzielczość rasterowania poszczególnych trójkątów w tej samej scenie pozostaje taka sama niezależnie od rozdzielczości.
Skoro przedstawiłem proste, zarówno koncepcyjnie jak i w metodyce wdrożenia rozwiązanie - dlaczego proponuję szukanie bardziej zawiłych rozwiązań?
Pragnę w tym momencie zauważyć, że aktualny system LoD jest systemem bardzo prostym, takim, który nie bierze pod uwagę wielu czynników, natomiast nasza percepcja opiera się na dalece większej ilości owych. Weźmy na przykład prędkość względną obiektu, względem obserwatora - w rzeczywistości, przy prędkości 250km/h (inna rzecz, czy patrzymy z bocznej szyby, czy czołowiej) nie dostrzegamy wielu detali obrazu, widzimy go bowiem zbyt krótki czas.
Tu pojawia się kwestia, którą ktoś poruszał jakiś czas temu - modelując nastawnię dla niezelektryfikowanego (jeśli dobrze pamiętam), starego szlaku, po którym skład miał się poruszać z prędkością 40 czy 20km/h, zastanawiał się ten jegomość, czy wymodelować jej wnętrze i w ogólnej dyskusji tego zagadnienia dotyczącej stwierdził, że na takiej trasie warto to wnętrze wymodelować, ponieważ jadący 20km/h obserwator będzie miał czas, żeby po pierwsze dostrzec, po drugie przyjrzeć się bliżej, a po trzecie docenić detale. Analogicznie wiele obiektów przy dużej prędkości rozmywa nam się w motion blurze, nie dostrzegamy detali, a gdy jedziemy powoli, to te detale cieszą nas niezmiernie.
Innym przykładem niech będzie skład jadący równolegle z nami - wysoki poziom detali na takim wpływa bardzo pozytywnie na odbiór produktu, jakim jest symek, kto z nas, widząc inny skład, jadący równo z nami, w bocznej szybie, nie ma ochoty popatrzeć sobie nań, przyjrzeć się wszystkim detalom, których być może nie dostrzegliśmy w ujęciu statycznym - analogicznie powinien działa symulator, pozwalając nam nacieszyć się tymi smaczkami.
Proszę panów szanownych o przemyślenia w tym temacie, bardziej, lub może lepiej mniej luźne oraz ogólnie rzecz biorąc propozycje - od czego waszym zdaniem powinien uzależniony być LoD?
Apeluję też, by zastanowić się nad tematem w dwójnasób, czy może nawet rozważyć trzy punkty widzenia. Pierwszym niech będzie percepcja samego użytkownika, efekt wizualny. Drugim niech będzie wpływ na wydajność pracy. Na przytoczonych powyżej przykładach - piękny model nastawni, z wymodelowanym wnętrzem, etc, kiedy go mijamy z dużą prędkością, wyświetla się na ekranie tylko przez kilka klatek. Jaki jest więc sens po pierwsze ładować na żądanie wszystkie modele i tekstury LoD po kolei, tylko po to, by zaraz je wyrzucić, po drugie pokazywać model w detalu, którego przez prędkość właśnie nie dostrzeżemy, ergo pozytywny pływ na wydajność i fps, bo kiedy jedziemy tą samą trasę szybko, to ta sama ilość modeli musi wyświetlić się w krótszym czasie, a żeby się wyświetliły, modele muszą zostać wysłane do GPU, a zmieniając (w funkcji prędkości) LoD zmniejszamy ilość modeli do przesłania (szczególnie tych o dużej rozdzielczości siatki - obszerne i bardziej flopochłonne w renderowaniu) i tym samym odciążamy sprzęt.
Trzecim punktem widzenia niech będzie metodyka wprowadzania udoskonaleń do systemu LoD. Przytoczony na początku przykład skalowania LoD w zależności od rozdzielczości, jest bajecznie prosty - trzeba przeskalować (jak to @Ra określił - po chamsku) wartości min-/maxdistance i w sumie roboty jest dość. Bardziej zawiłe systemy, jak np. uzależnianie LoD od prędkości, są dużo bardziej skomplikowane w realizacji (pamiętajmy, że renderer nie widzi w ogóle takich rzeczy jak prędkość (chyba, że jako parametr wejściowy dla motion blura, czy innego efektu post-rastrowego) niezależnie czy względna, czy bezwzględna, fizyka zresztą też się w małym stopniu interesuje takim zagadnieniem, jak prędkość względna (chyba, że zderzają się dwa wagony i fizyka chce wiedzieć jak bardzo ma animować zderzaki), więc poza pomysłem ogólnie, potrzebny jest też pomysł na realizację zagadnienia.
* inna kwestia, że bardzo łatwo popsuć - np. podać rozbieżne wartości min-/maxdistance w kolejnych LoD
P.S. Proszę o poważne posty.
Zamykam.
adsim
98
Pomoc doraźna / Odp: Zwrotnice ręczne 34m r300. MaSzyna 08.13
« dnia: 09 Stycznia 2014, 09:48:25 »
W kwestii Rainsteda, to ten program wspiera koncepcję rozdzielenia warstwy projektowej scenerii od realizacji projektu w maszynie. Mówiąc po ludzku, w Rainstedzie możesz zaprojektować różne rzeczy, jak np. układ torowy (program jest w fazie rozwoju, więc wszystkiego nie da się tam zaprojektować), używając standardowych elementów, w tym wypadku są to tory, rozjazdy, etc., ale projektujesz tylko sam układ torowy, natomiast projektując w 3ds maxie lub podobnych nie tylko projektujesz układ torowy, ale musisz również poukładać elementy realizujące ten układ w symku, tzn. modele rozjazdów, tory zwykłe akurat są "zautomatyzowane". W Rainstedzie możesz dziś zaprojektować układ torowy, a za rok, kiedy np. będzie dostępny nowy model rozjazdu przypisać ten model do już utworzonych rozjazdów.
Ergo konkretne modele nie są niezbędne, żeby tworzyć scenerię, a zakładając, że elementy dostępne w Rainstedzie są zgodne wymiarami z rzeczywistością, co implikuje zgodność z przyszłymi modelami, nie będziesz musiał już niczego zmieniać.
Tzn. ja rozumiem, że jak ktoś zaczyna, to woli sobie popatrzeć na kawałeczek toru który przed chwilą zbudował, to przynosi motywację do dalszego działania, rozumiem więc też wybór 3ds maxa (przyjmując, że ten wybór był świadomy), natomiast jeśli zechcesz budować coś większego, dla masowego odbiorcy, to pomyśl o Rainstedzie.
Zamykam.
Rozi
Ergo konkretne modele nie są niezbędne, żeby tworzyć scenerię, a zakładając, że elementy dostępne w Rainstedzie są zgodne wymiarami z rzeczywistością, co implikuje zgodność z przyszłymi modelami, nie będziesz musiał już niczego zmieniać.
Tzn. ja rozumiem, że jak ktoś zaczyna, to woli sobie popatrzeć na kawałeczek toru który przed chwilą zbudował, to przynosi motywację do dalszego działania, rozumiem więc też wybór 3ds maxa (przyjmując, że ten wybór był świadomy), natomiast jeśli zechcesz budować coś większego, dla masowego odbiorcy, to pomyśl o Rainstedzie.
Zamykam.
Rozi
99
EU07 Simulator English forum / Odp: Amazing work thanks
« dnia: 14 Stycznia 2014, 22:05:45 »
Also, if you need some guidence or maybe translation of some docs into English (maybe I'll manage to do it a bit better than google translate) feel free to hit me with a pm or an email (olafchujko@gmail.com). It comes to me as a shock, that someone actually called this models very good looking (with all due respect to the ones who created said models), although I'm not really surprised with the part about simulation being good, actually I'd say that's what MaSzyna is all about.
Please do tell me where are you from and what you do. I ask out of sheer interest. Also please make an effort to interest your friends with the simulator.
We are kinda desperate for an opengl/shaders dev that we could use for refreshing the graphics engine a bit. So if you know anyone by that profession, please let us/him know. ;-)
Please do tell me where are you from and what you do. I ask out of sheer interest. Also please make an effort to interest your friends with the simulator.
We are kinda desperate for an opengl/shaders dev that we could use for refreshing the graphics engine a bit. So if you know anyone by that profession, please let us/him know. ;-)
100
Pomoc doraźna / Odp: Zwrotnice ręczne 34m r300. MaSzyna 08.13
« dnia: 09 Stycznia 2014, 00:16:12 »
Ucz się Rainsteda.
101
Bieżące Symulatorowe / Odp: Sieć trakcyjna w Maszynie.
« dnia: 09 Stycznia 2014, 00:13:22 »
"ilość rzeczy do poprawienia w sceneriach przerasta możliwości jednej/kilku osób" == "nie ma chętnych rąk do pomocy"
Pytanie z mojej strony, @sebastianie82, czy skarbnicą wiedzy jedynie w zakresie zagadnień elektro-energetycznych związanych z siecią trakcyjną, czy również specem od konstrukcji sieci łańcuchowych?
Pytanie z mojej strony, @sebastianie82, czy skarbnicą wiedzy jedynie w zakresie zagadnień elektro-energetycznych związanych z siecią trakcyjną, czy również specem od konstrukcji sieci łańcuchowych?
102
Bieżące Symulatorowe / Odp: Rozważania na temat przyszłości spotkań MaSzynowców.
« dnia: 05 Stycznia 2014, 00:16:19 »Jak to powiedział Ra, "potrzeba co najmniej dwóch lat, żeby obecne scenerie zostały dostosowane pod obecne exe", czy jakoś tak :P Moje spojrzenie na obecne scenerie, fizykę lokomotyw, czy scenariusze jest takie, by zajmowała się tym grupa osób, z której połowa świetnie ogarnia realia symulatorowe, a druga rzeczywistą kolej, choć grupę tych drugich ludzi ze świecą szukać...Wybacz, ale nie wydaje mi się, żeby @Ra tworzył tu nową złotą regułę magicznego opóźnienia w rozwoju, bardziej wygląda mi to na trzeźwe spojrzenie na obecny stan rzeczy i wynikające z niego bolączki. A stan rzeczy jest taki, że scenerie nie nadążają za exe, bo raz że nie ma żadnego planu rozwoju, twórcy robią pod stan dzisiejszy, który, nie trudno się dziwić, ulega wkrótce zmianie, a po kilku latach staje się stanem sprzed kilku lat. Z drugiej strony, brakuje ludzi, którzy gotowi byliby podjąć się pracy związanej z dostosowywaniem produktu pod zmieniające się standardy. Gdyby choć jeden z tych aspektów uległ zmianie, to już można by liczyć na dużo bardziej dynamiczny rozwój, choćby w zakresie wdrażania (w formie użytecznej) nowych funkcjonalności.
Nie wydaje mi się też, że potrzebna jest ogromna ilość osób o bardzo rozległej wiedzy. Wiele złożonych działań można rozbić na drobne, powtarzalne czynności, które śmiało wykonywać może osoba o bardzo wąskiej i płytkiej wiedzy, którą pozyskać może od odpowiedniej osoby o głębszej i szerszej znajomości danego zagadnienia bezpośrednio, bądź poprzez jakąś formę opracowania.
103
Bieżące Symulatorowe / Odp: Mapowanie trawy
« dnia: 15 Listopada 2013, 12:12:44 »
No i jeszcze pytanie, czy siatka 5x5m ma funkcjonować wyłącznie w płaszczyźnie xy, co skutkuje de facto rozciągnięciem tekstury na trójkątach nie prostopadłych do osi z, czy też może siatka 5x5m w płaszczyźnie równoległej do trójkąta terenu (brak rozciągania teksutry) i co za tym idzie jakieś "radzenie sobie" z ewentualnymi niezgodnościami na spojeniach trójkątów? W przypadku rozciągania - wiadomo - wszystko zależy od tego jak mocno pochylony jest teren. Przy pochyleniu rzędu 30 stopni jeszcze będzie to jakoś wyglądać, gorzej przy większych spadkach, rzędu 60 stopni.
104
Bocznica / Odp: Hamowanie pojazdu
« dnia: 05 Listopada 2013, 00:44:26 »Wbrew pozorom istota sprawy nie jest tak bezsensowna, jak się niektórym wydaje. Od jakiegoś czasu chodzi mi po głowie pomysł na liczbową ocenę techniki jazdy, która uwzględniałaby również hamowanie i stawanie pojazdu. Myślę, że ustawienie kubka, w którym zwierciadło cieczy reagowałoby na przyspieszenie jest możliwe, niemniej jednak wolę symulować tylko pociąg, zaś herbatę mieć prawdziwą.Mamy rozumieć, że prowadząc pociąg w MaSzynie zawsze trzymasz w dłoni kubek z herbatą, a w przypadku zbyt silnego hamowania karzesz sam siebie rozlewając ukrop na spodnie?
105
Poszukuję, chcę zrobić / Odp: Linia 11 Łowicz Główny - Skierniewice
« dnia: 23 Października 2013, 23:36:19 »
Torowisko tworzysz w 3dsie, czy może w edytorze rainsted?
106
Bieżące kolejowe / Odp: Dyskusja na temat wygody w wagonach bezprzedziałowych
« dnia: 11 Września 2013, 11:26:34 »Normalnie. Można sobie przesunąć drzwi i już nie masz przedsionków.Jeśli jesteś głuchy, bądź głuchym chcesz zostać, lub ewentualnie jeśli lubisz doznania płynące z wkładania głowy w wózek.
W kiblu fotele nie są ustawione jeden na drugim, że prawie siadasz na osobie przed tobą i obok Ciebie. Spokojnie można wstać z miejsca przy oknie i się wydostać, a osoba siedząca obok nie musi się podnosić.No tak jak już ktoś wcześniej wspomniał, w kiblu jest regularny problem ze zbyt długimi nogami, w bezprzedziałowcach jeszcze problemów nie miałem, też jakoś nigdy nie było konieczne wstawanie osoby siedzącej od korytarza, żeby osoba siedząca od okna mogła wyjść. A nawet jeśli, to chyba nie będziesz się kręcił jak kot z pęcherzem w tę i w tę (jeśli współpasażer by się tak zachowywał, to bym zaproponował zamianę miejsc).
A jeśli idzie o okna, to w nowszych przedziałowych też są hermetycznie zamknięte + A/C, a na zachodzie to już dawno jest standardem.
107
Bieżące kolejowe / Odp: Kontrakt na zakup 20 składów PKP Intercity dla Stadlera i Newagu
« dnia: 28 Sierpnia 2013, 23:04:08 »
Konkurencja dla TGV? Sprytnie.
108
Na warsztacie / Odp: Projekt 750mm
« dnia: 15 Sierpnia 2013, 11:56:58 »
http://eu07.pl/forum/index.php/topic,22195.msg321836.html#msg321836
Polecam na przyszłość uważną lekturę forum... ;-)
Polecam na przyszłość uważną lekturę forum... ;-)
109
Bieżące kolejowe / Odp: Sprawa Pendolino
« dnia: 15 Sierpnia 2013, 10:29:52 »
No to jak budują, a nie zbudowali, to chyba muszą jeszcze poczekać, czy może się mylę? ;D Problemy robicie nie wiadomo o co.
A grudzień 2014, panowie mądre głowy, bo w grudniu właśnie, o ile mi wiadomo, zmienia się rozkład, który obowiązuje następnie przez cały rok (pomijając nieudane rozkłady, ale to inna bajka), a widać na grudzień 2013 się nie wyrobią.
A grudzień 2014, panowie mądre głowy, bo w grudniu właśnie, o ile mi wiadomo, zmienia się rozkład, który obowiązuje następnie przez cały rok (pomijając nieudane rozkłady, ale to inna bajka), a widać na grudzień 2013 się nie wyrobią.
110
Bocznica / Wydzielone z: Może nowoczesne pociągi? Typu Elf, Flirt, 19WE ...
« dnia: 13 Sierpnia 2013, 05:12:10 »
A, ciekawość, jakim sprzętem dysponujesz?
Reg. Obowiązki: 9
Bocznica.
Rozi
Reg. Obowiązki: 9
Bocznica.
Rozi
111
Symulator / Odp: Klatki na sekundę (FPS)
« dnia: 11 Sierpnia 2013, 01:19:14 »
Proszę o komentarz w kwestii wydajności w kontekście zwiększania/zmniejszania liczby submodeli. W miarę możliwości proszę o nieco bardziej dogłębne wytłumaczenie (nie chodzi mi o tłumaczenie wszystkiego po kolei, tylko o wskazanie bezpośrednich i pośrednich przyczyn oraz ciągu przyczynowo-skutkowego). Interesują mnie zarówno sytuacje w których zwiększamy sumaryczną ilość submodeli wyświetlanych jednocześnie oraz sumaryczną ilość submodeli ogólnie (np. model podkładu mający dwa submodele LoD w kontraście do modelu podkładu posiadającego pięć submodeli LoD).
Pytam o to, ponieważ spotykam się z różnorodnymi, niekiedy sprzecznymi opiniami na ten temat i chciałbym rozwiać pewne wątpliwości, a może przy okazji sprowokować jakąś dyskusję / umotywować zmiany w programie.
Pytam o to, ponieważ spotykam się z różnorodnymi, niekiedy sprzecznymi opiniami na ten temat i chciałbym rozwiać pewne wątpliwości, a może przy okazji sprowokować jakąś dyskusję / umotywować zmiany w programie.
112
Bieżące Symulatorowe / Odp: Modele do sieci trakcyjnej
« dnia: 14 Lipca 2013, 19:15:50 »
Ja mogę Ci odpowiedzieć w następujący sposób, generator wysięgników przyjmuje kilka podstawowych danych, a konkretnie:
- współrzędne punktów zaczepienia przewodów i lin oraz punktów zaczepienia wysięgnika do słupa (współrzędne hv na płaszczyźnie na której leży (w pozycji neutralnej względem kompensacji) wysięgnik) oraz
- kilka danych dodatkowych, dotyczących ułożenia (rotacji) pewnych elementów (które to dane obliczyć można na dobrą sprawę tylko mając pełny model matematyczny statycznej sieci trakcyjnej, którego ja nie posiadam i raczej w najbliższym czasie nie posiądę), natomiast jak najbardziej można je zebrać, w dużym przybliżeniu, z materiału foto/wideo.
- Dochodzą też dane dotyczące samych słupów: przede wszystkim typ, dalej wysokość oraz "rozmiar" (rozmiar kształtowników, z których słup został wykonany). O ile wysokość jest dość oczywista, to rozmiar już nie jest tak oczywisty. No i oczywiście współrzędne położenia słupa w przestrzeni.
Jeśli stworzysz rzeczone ince słupów/wysięgników oraz ustawisz je odpowiednio w przestrzeni xyz (bądź thv) to nie powinno być problemu, żeby te słupy/wysięgniki później zamienić na nowe - wygenerowane (tzn. wygenerować kilka modeli i zamienić stare modele na nowe).
Pytanie zasadnicze brzmi: jak dokładnie chcesz odwzorować sieć trakcyjną? Jeśli wystarczającym jest dla Ciebie wygenerowanie kilku standardowych wysięgników i użycie ich wielokrotnie, to zasugeruję jedynie, żebyś rozróżnił wpisy różnorodnych wysięgników, co ułatwi późniejszą ich podmianę. Jeśli natomiast chcesz odwzorować sieć trakcyjną i jej konstrukcje nośne w 100%, to sugeruję zebranie i skompilowanie danych w łatwo-edytowalnym formacie. Te podstawowe informacje (punkty zaczepienia) oczywiście wyciągniesz również z inców tymczasowych słupów, natomiast dane dodatkowe będziesz musiał gromadzić oddzielnie.
Jeśli chcesz dowiedzieć się więcej na temat tych danych dodatkowych, to z chęcią napiszę o tym kolejnego posta, przyjmuję jednak, że jeśli nie ma takiej potrzeby, to nie ma co rozwlekać tego posta i pisać o czymś niepotrzebnym.
- współrzędne punktów zaczepienia przewodów i lin oraz punktów zaczepienia wysięgnika do słupa (współrzędne hv na płaszczyźnie na której leży (w pozycji neutralnej względem kompensacji) wysięgnik) oraz
- kilka danych dodatkowych, dotyczących ułożenia (rotacji) pewnych elementów (które to dane obliczyć można na dobrą sprawę tylko mając pełny model matematyczny statycznej sieci trakcyjnej, którego ja nie posiadam i raczej w najbliższym czasie nie posiądę), natomiast jak najbardziej można je zebrać, w dużym przybliżeniu, z materiału foto/wideo.
- Dochodzą też dane dotyczące samych słupów: przede wszystkim typ, dalej wysokość oraz "rozmiar" (rozmiar kształtowników, z których słup został wykonany). O ile wysokość jest dość oczywista, to rozmiar już nie jest tak oczywisty. No i oczywiście współrzędne położenia słupa w przestrzeni.
Jeśli stworzysz rzeczone ince słupów/wysięgników oraz ustawisz je odpowiednio w przestrzeni xyz (bądź thv) to nie powinno być problemu, żeby te słupy/wysięgniki później zamienić na nowe - wygenerowane (tzn. wygenerować kilka modeli i zamienić stare modele na nowe).
Pytanie zasadnicze brzmi: jak dokładnie chcesz odwzorować sieć trakcyjną? Jeśli wystarczającym jest dla Ciebie wygenerowanie kilku standardowych wysięgników i użycie ich wielokrotnie, to zasugeruję jedynie, żebyś rozróżnił wpisy różnorodnych wysięgników, co ułatwi późniejszą ich podmianę. Jeśli natomiast chcesz odwzorować sieć trakcyjną i jej konstrukcje nośne w 100%, to sugeruję zebranie i skompilowanie danych w łatwo-edytowalnym formacie. Te podstawowe informacje (punkty zaczepienia) oczywiście wyciągniesz również z inców tymczasowych słupów, natomiast dane dodatkowe będziesz musiał gromadzić oddzielnie.
Jeśli chcesz dowiedzieć się więcej na temat tych danych dodatkowych, to z chęcią napiszę o tym kolejnego posta, przyjmuję jednak, że jeśli nie ma takiej potrzeby, to nie ma co rozwlekać tego posta i pisać o czymś niepotrzebnym.
113
Infrastruktura kolejowa / Odp: Dyskusja na temat przebicia w szynie
« dnia: 14 Lipca 2013, 13:51:42 »Co to za brednie opisujesz.Przepraszam, że off topic, ale motyw, gdzie ktoś w ten sposób toromistrza ciśnie - polewka prima sort. I tak, drogi @Anreju, napiszę po raz kolejny (choć nie wiem co to zmieni) szyna jest odizolowana od ziemi.
@Niebogucław
Konkretnie to są przekładki podszynowe oraz:
- wkładki izolacyjne dla przytwierdzeń typu SB,
- gniazda pod śruby zabudowane w podkładach, wykonane z tworzywa sztucznego dla przytwierdzeń typu K oraz SKL.
114
Infrastruktura kolejowa / Odp: Dyskusja na temat przebicia w szynie
« dnia: 13 Lipca 2013, 20:16:18 »Jednym z przewodów jest szyna, który jest uziemiony. Dotykanie szyny niczym nie grozi.Szyna nie jest uziemiona. Wręcz przeciwnie, jest odizolowana od ziemi.
Za napięcie bezpieczne przyjmuje się 25V AC oraz 60V DC, wyłączając sytuacje wyjątkowe.
Warto też zauważyć, że termin WN jest dwuznaczny: w "zwyczajnych" obwodach elektrycznych dolną granicą jest 1kV AC i 1,5kV DC, natomiast w elektroenergetyce jako dolną granicę przyjmuje się 60kV (jako górną 400kV).
115
Pomoc w tworzeniu / Odp: Peron jako road - zmienna szerokość
« dnia: 06 Lipca 2013, 01:05:57 »
No dobra, ale co to w praktyce oznacza? Mieliśmy dotąd budynki wysokie na 2 albo na 10 metrów? To co, róbmy dalej tak samo? Robiliśmy źle, róbmy tak samo? Albo i gorzej? Ja powtórzę - może tym razem uda mi się to zmieścić w bardziej przystępnych i jasnych słowach: postęp zmian nie jest ograniczony tylko tym, jakie zmiany są wdrażane od strony programu. W dużo większej mierze te zmiany są ograniczone tym, czy zostaną one uwzględnione przez twórców scenerii i scenariuszy. Mamy przed sobą (i za sobą) sporo zmian, tzn. rozszerzeń funkcjonalności. Dojdą nowe wysięgniki (tego akurat nikt nie musi używać), dojdzie nowa sieć trakcyjna, do tego mamy już teraz taką czy inną symulację obciążeń odbieraka. Odbierak pod źle ustawioną siecią pada i będzie padał. Jeśli nikt nie wprowadzi do scenerii poprawnej sieci, to mimo iż ta funkcjonalność znajdzie swoje miejsce w programie (już znalazła) to będzie nieużyteczna. Bo nie pojeździmy, skoro po 200 metrach połamie nam się pantograf? A jeśli obecni twórcy scenerii nie będą tego uwzględniać i to uwzględniać już dziś, to za rok, za dwa, za pięć, ciągle będziemy mieli piękne scenerie, na których nie pojedziemy z symulacją patyka, bo ten się po 200 metrach połamie.
Czy dalej chcesz mi wmawiać, że zmiany programowe idą wolno i nie trzeba się na nie oglądać? Któregoś dnia przyjdzie miły pan, w dwa tygodnie wdroży nam shadery (choć pewnie dużo bardziej prawdopodobne, że Jarek kupi sobie nowy monitor i nagle zobaczy grafikę Maszyny w większej rozdzielczości i się przerazi, w efekcie czego te shadery zrobi), a tu nadal dupa, bo mamy pięknie zoptymalizowane modele. Zoptymalizowane tak, bo mój tato tak robił. I jego tato, i tato jego taty, wszyscy tak samo robili. To dlaczego ja miałbym robić inaczej.
Nie tędy droga.
Czy dalej chcesz mi wmawiać, że zmiany programowe idą wolno i nie trzeba się na nie oglądać? Któregoś dnia przyjdzie miły pan, w dwa tygodnie wdroży nam shadery (choć pewnie dużo bardziej prawdopodobne, że Jarek kupi sobie nowy monitor i nagle zobaczy grafikę Maszyny w większej rozdzielczości i się przerazi, w efekcie czego te shadery zrobi), a tu nadal dupa, bo mamy pięknie zoptymalizowane modele. Zoptymalizowane tak, bo mój tato tak robił. I jego tato, i tato jego taty, wszyscy tak samo robili. To dlaczego ja miałbym robić inaczej.
Nie tędy droga.
116
Pomoc w tworzeniu / Odp: Peron jako road - zmienna szerokość
« dnia: 04 Lipca 2013, 16:55:02 »
Przecież choćby kolega @_KAT_ się uczy robić, wnoszę, że robi to, bo tego chce (a nie, na przykład dlatego, że ktoś mu kazał).
Ja mam odmienne zdanie na poruszony przez Ciebie temat, choć nie jest to raczej właściwe miejsce, by prowadzić tę dyskusję.
Edit: Względem shaderów.
Ja nie twierdzę, że shadery będą jutro, nie twierdzę, że będą za tydzień. Być może ich nigdy w ogóle nie będzie. Trudno mówić tu o pewnikach, można tylko mówić o prawdopodobieństwie. Ja natomiast daję Ci, @Benku, stu-procentowy pewnik - jeśli już (o ile, kiedyś) będą shadery, to trzeba będzie przerabiać te wszystkie "zoptymalizowane" bryły, bo nie będą one właściwie cieniowane. A obserwując od jakiegoś już czasu wasze podejście do zmian w czymkolwiek, to najprawdopodobniej autorowi shaderów się najbardziej oberwie, że niepotrzebnie komplikuje sprawy (no, może troszkę przekoloryzowałem w tym przypadku, ale mam nadzieję, że choć część zrozumie moje intencje).
A jeszcze, pozwolę sobie wkraść jedną dygresję, odnośnie tego co pisałeś na facebooku, mianowicie nie wydaje mi się, żeby nasz silnik miał problemy z wyświetlaniem trójkątów, jeśli już, to ma problemy z wyświetlaniem, czy może raczej z przygotowaniem do wyświetlenia, submodeli. Niestety nie dysponuję jeszcze odpowiednimi danymi na ten temat, niemniej jak tylko uda mi się je zgromadzić, nie omieszkam się podzielić.
Ja mam odmienne zdanie na poruszony przez Ciebie temat, choć nie jest to raczej właściwe miejsce, by prowadzić tę dyskusję.
Edit: Względem shaderów.
Ja nie twierdzę, że shadery będą jutro, nie twierdzę, że będą za tydzień. Być może ich nigdy w ogóle nie będzie. Trudno mówić tu o pewnikach, można tylko mówić o prawdopodobieństwie. Ja natomiast daję Ci, @Benku, stu-procentowy pewnik - jeśli już (o ile, kiedyś) będą shadery, to trzeba będzie przerabiać te wszystkie "zoptymalizowane" bryły, bo nie będą one właściwie cieniowane. A obserwując od jakiegoś już czasu wasze podejście do zmian w czymkolwiek, to najprawdopodobniej autorowi shaderów się najbardziej oberwie, że niepotrzebnie komplikuje sprawy (no, może troszkę przekoloryzowałem w tym przypadku, ale mam nadzieję, że choć część zrozumie moje intencje).
A jeszcze, pozwolę sobie wkraść jedną dygresję, odnośnie tego co pisałeś na facebooku, mianowicie nie wydaje mi się, żeby nasz silnik miał problemy z wyświetlaniem trójkątów, jeśli już, to ma problemy z wyświetlaniem, czy może raczej z przygotowaniem do wyświetlenia, submodeli. Niestety nie dysponuję jeszcze odpowiednimi danymi na ten temat, niemniej jak tylko uda mi się je zgromadzić, nie omieszkam się podzielić.
117
Pomoc w tworzeniu / Odp: Peron jako road - zmienna szerokość
« dnia: 04 Lipca 2013, 12:25:16 »
Tak, dzięki takiej optymalizacji oszczędzamy niecałe 25% trójkątów, za to zapewniamy sobie przerabianie każdej zoptymalizowanej w ten sposób bryły w momencie, kiedy do silnika wejdą shadery. Bo jeśli ktoś nie zdaje sobie z tego sprawy, cieniowanie działa poprawnie tylko na bryły zamknięte (o topografii kuli bądź torusa). Myślałem, że te czasy (takiego optymalizowania) minęły bezpowrotnie dobre 5 lat temu.
118
Pomoc w tworzeniu / Odp: Peron jako road - zmienna szerokość
« dnia: 04 Lipca 2013, 11:02:27 »
Że się tak zapytam, jaki jest cel instrukcji zawartej w punkcie numer 8:
Cytuj
extrude od linii do krawędzi, usunięcie niewidocznego spodu, detach "środka" peronu(jeśli ktoś się nie domyślił, chodzi mi o instrukcję wyróżnioną pogrubieniem)?
119
Pomoc w tworzeniu / Odp: Trasopisarstwo - moje problemy
« dnia: 29 Czerwca 2013, 20:19:48 »
Jeśli się wstrzymasz tydzień-dwa, to powinna być już w miarę funkcjonalna wersja generatora. Tekstur jak nie było tak nie ma, więc wydać tego nie wydasz, ale pracuję nad tym, żeby wysięgniki (oraz słupy i cała reszta tego bajzlu) były.
120
Pomoc w tworzeniu / Odp: Edytor RAINSTED - kilka pytań
« dnia: 12 Czerwca 2013, 21:52:56 »
Jeśli mogę dodać coś od siebie:
- słupy są wymodelowane, czekają na tekstury
- jest koncepcja wysięgnika w 100% edytowalnego, który dostosowywać się będzie do wyliczonych wymiarów lokalnych (nowa generacja generatora), modele czekają na tekstury, koncepcja programu generatora dopracowana w 95%, czeka na realizację
- z uwagi na koncepcję połączenia tekstur (i nie tylko) dwóch powyższych elementów raczej nie przewiduje się wydania rozłącznego
- przęsła naprężania wymagają dopracowania koncepcji w zakresie rozwiązania tymczasowego, przy czym w planach są bardziej rozbudowane twory, ciężko stwierdzić co pierwsze ujrzy światło dnia
- uwzględnienie przechyłki toru (zarówno w kwestii punktu podwieszenia jak i profilowania przęsła) nie jest wielkim problemem, pozostają jednak pewne braki koncepcyjne (w zakresie zapisu takiego przęsła), ma to być częścią generatora przęseł - tu niestety mam spore braki "programowe" i nie jestem w stanie dopracować koncepcji, także ten element odchodzi na razie na dalszy plan (przynajmniej w docelowej formie), koncepcja rozwiązania tymczasowego jest raczej dość prosta, aczkolwiek mam jeszcze pewne braki merytoryczne, które muszę uzupełnić
- zamiast weryfikować poprawność zygzakowania, segmentację, czy rozstaw słupów raczej docelowym rozwiązaniem jest po prostu zestaw skryptów, który będzie uzupełniał odpowiednie dane według zadanych parametrów (sugerowane umieszczenie kolejnego słupa, automatyczne sugerowanie punktu zawieszenia trakcji w przestrzeni - uwzględniając zygzakowanie właśnie)
- w temacie różnych typów sieci vide generator przęseł
Do tego wszystkiego na pewno będę tworzył dokumentację, choć nie wykluczam, że przyda się pomoc, także zapraszam na gg, jeśli masz ochotę.
- słupy są wymodelowane, czekają na tekstury
- jest koncepcja wysięgnika w 100% edytowalnego, który dostosowywać się będzie do wyliczonych wymiarów lokalnych (nowa generacja generatora), modele czekają na tekstury, koncepcja programu generatora dopracowana w 95%, czeka na realizację
- z uwagi na koncepcję połączenia tekstur (i nie tylko) dwóch powyższych elementów raczej nie przewiduje się wydania rozłącznego
- przęsła naprężania wymagają dopracowania koncepcji w zakresie rozwiązania tymczasowego, przy czym w planach są bardziej rozbudowane twory, ciężko stwierdzić co pierwsze ujrzy światło dnia
- uwzględnienie przechyłki toru (zarówno w kwestii punktu podwieszenia jak i profilowania przęsła) nie jest wielkim problemem, pozostają jednak pewne braki koncepcyjne (w zakresie zapisu takiego przęsła), ma to być częścią generatora przęseł - tu niestety mam spore braki "programowe" i nie jestem w stanie dopracować koncepcji, także ten element odchodzi na razie na dalszy plan (przynajmniej w docelowej formie), koncepcja rozwiązania tymczasowego jest raczej dość prosta, aczkolwiek mam jeszcze pewne braki merytoryczne, które muszę uzupełnić
- zamiast weryfikować poprawność zygzakowania, segmentację, czy rozstaw słupów raczej docelowym rozwiązaniem jest po prostu zestaw skryptów, który będzie uzupełniał odpowiednie dane według zadanych parametrów (sugerowane umieszczenie kolejnego słupa, automatyczne sugerowanie punktu zawieszenia trakcji w przestrzeni - uwzględniając zygzakowanie właśnie)
- w temacie różnych typów sieci vide generator przęseł
Do tego wszystkiego na pewno będę tworzył dokumentację, choć nie wykluczam, że przyda się pomoc, także zapraszam na gg, jeśli masz ochotę.