| Ankieta: Czy odczuwasz jakąś zauważalną różnicę w OMSI między Windowsem/Linuxem? Nie posiadasz uprawnień, aby oddać głos w tej ankiecie. |
|||
| Linux zdecydowanie lepszy | 9 | 30.00% | |
| Linux jest nieco lepszy | 4 | 13.33% | |
| Bez różnicy | 4 | 13.33% | |
| Windows jest nieco lepszy | 6 | 20.00% | |
| Windows jest zdecydowanie lepszy | 7 | 23.33% | |
| Razem | 30 głosów | 100% | |
| *) odpowiedź wybrana przez Ciebie | [Wyniki ankiety] |
| OMSI + Linux = połączenie idealne? | |||
|
Co do plików z rozszerzeniem .x zvibecodowalem skrypt ktory je konwertuje na .o3d, jednakże zauważyłem kłopot z przeźroczystościami. Część drzew (np. Sceneryobjects/Ruede/Tree_Street_01.sco) traciły przeźroczystość. Zerkałem do nich i samemu nie jestem w stanie wytłumaczyć czemu tak się dzieje. Załączam wspomniany skrypt: https://infolink.ovh/shared/convert_scenery_x_to_o3d.py
Miejsce na twoją reklamę.
Ostatnio konwertowałem testowo niektóre obiekty za pomoca OmsiXConv z SDK tools. Niektóre (Sceneryobjects/Verkehrszeichen_MC/StreetSign_1sm.sco i StreetSign_1lg_pole.sco) miały problem z przezroczystością tylko w drugą stronę - zyskały przezroczystość. Zmieniłem w sco wartość [matl_alpha] z 2 na 1 i było git. Widocznie niektóre obiekty po przekonwertowaniu „czytają” te wartości na opak.
Nie, kolejność materiałów w o3d ma znaczenie na to jak są renderowane, by znak poprawnie się wyświetlił należy zamienić je miejscami.
Miejsce na twoją reklamę.
To znaczy, że przy konwertowaniu niektórych obiektów materiały się zamieniają miejscami?
| |||
| Użytkownicy przeglądający ten wątek: |
| 1 gości |