Bump Mapping ?

Da ich jetzt mehrmals gesehen hat, was hier für Polybomben im Showroom präsentiert werden, wo jede kleine Ecke und Spalte ausmodeliert ist, wollte ich wissen ob Omsi sogenanntes Bump Mapping/Normal Mapping unterstützt?

Das wäre nämlich ein riesen Vorteil um Details mit Hilfe einer Relieftextur zu erzeugen, ohne die Kanten zu modelieren. Das spart wiederrum Polys und Ressourcen.

OMSI unterstützt Bump-Mapping in Verbindung mit Reflexionstexturen, somit kann man sich reliefmäßig austoben, ohne das Mesh zu sehr vollzustopfen. Und nebenbei fällt für die genieteten SD-Seitenbleche noch ein netter Wellen-Effekt an

Hallo Rüdiger, ich danke dir für deine Antwort. Was meinst du mit Wellen-Effekt. Im positiven oder negativen Sinne?

Was verbraucht ihr so an Polygone in euren Modellen? Damit man sich darauf einstellen kann was möglich ist und auch eine Grenze gesetzt wird.

Positiv natürlich ;-) Die Außenbleche beim SD sind ja immer leicht gewellt bzw. eingedellt, vergleichbar mit der Beblechung der alten S-Bahnwagen (aber natürlich nicht ganz so stark *g*). Diesen Effekt kann man in OMSI sehr schön über Bump-Maps erzeugen.

Was die Polyzahl angeht: Der SD hat etwa 30.000 Polys. Das ist denke ich ein guter Kompromiss zwischen Optik und Performance. Mehr Polys sind natürlich möglich, nur sollte man dann besonders darauf achten, möglichst wenig Einzelmeshs zu verwenden, da diese die Performance relativ stark beeinflussen.

*bump*

Both bump maps and reflection maps are supposed to be in greyscale, right?

Btw, 30k polys, but what about the textures used for the SD? How many/what size did you use? Just so we've got some rough guidelines

Zitat :

Both bump maps and reflection maps are supposed to be in greyscale, right?

Not quite. Bump maps are greyscale but reflection maps can also be coloured. Generally, a reflection map is the image of the surrounding landscape mapped on the model in order to make it look shiny. At the moment, OMSI uses static reflection maps for performance reasons, but it still looks very believable. So you can just take a picture of some generic landscape and use it as a reflection map.

Sometimes it can be useful though to convert the image to greyscale and tweak the contrast settings: The black bakelite-style steering wheel of our SD80 uses a greyscale reflection map making it look darker for the reflection is only a shade of black and white which resembles the appearance of the original much closer that a coloured reflection map would do.

Oops, forgot the 2nd question...

The SD uses the following ones:
1024*1024 main body
1024*1024 main body, interior parts
1024*1024 interior body
1024*1024 interior surfaces, small interior parts
1024*1024 dashboard
512*512 driver's seat
512*512 ticket counter
256*256 front wheel
256*256 rear wheel
64*256 tires
...and some more for registration plates, destination display, etc.

Ah, thanks for your answers!

Are 2048x2048 texture maps also supported or would you advise against those for performance/backward compatibitily reasons?

We haven't set any maximum texture size so 2048*2048 will certainly work. Exceeding this size may lead to some incompabilities with older graphic cards which (including mine) only support textures up to 2048*2048.
In general, few large textures should always be preferred to many small textures (less materials used).

Frage zu den Texturen:

Hat es einen speziellen Grund, warum ihr die Texturen "quadratisch" erstellt? z.B. für die Außentexturen des SD 1024*1024? Im Prinzip kann man die ja entsprechend länglicher machen, oder?
Gibt es da Probleme mit der Unterstützung?

Quadratische Texturen sind eigentlich die übliche Variante. Ob nicht-quadratische Texturen langsamer verarbeitet werden, kann ich nicht sagen, aber manche Grafikkarten sollen damit wohl Probleme haben (u.a. hinsichtlich des Speicherverbrauches). Generell sollte darauf geachtet werden, soviele Teiltexturen wie möglich in einer gemeinsamen Datei zusammenzufassen, um Materialien zu sparen (jede Textur ist ja letztendlich ein eigenes Material). Und da bietet quadratische Texturen natürlich eine sehr vielseitig nutzbare Platzaufteilung. Aber prinzipiell sind natürlich auch nicht-quadratische Texturen möglich, bei uns z.B. die Reifentextur als eine der wenigen, wo dieses Format wirklich sinnvoll ist.

Welche Auflösung habt ihr denn für die Häuser und Umgebungen genommen? Als Anhaltspunkt, um womöglich nicht zu große Texturen zu verwenden.

wir haben keinen besonderen Richtwert - wir gehen eher danach, wie dicht man das Gebäude sehen kann.

Grundsätzlich verwende ich stets "Mastertexturen", also ich schnippele meine Textur in großer Auflösung zusammen, mache eine Kopie, verkleinere die und verwende die als Textur. Dadurch kann ich dann später noch variieren, muss aber nach Änderungen im Master nochmal die verkleinerte Version erstellen.

Außerdem gilt folgendes zu beachten: es gibt eine Funktion, dass Omsi auf verkleinerte Texturen zurückgreift, um die Ladezeit auf schwächeren Rechnern zu verringern. Hierzu muss lediglich ein _#low.bmp jeweils angehängt werden. Also wenn die große Textur "bla.bmp" heißt, muss die verkleinerte Version "bla_#low.bmp" heißen.

Für die Altbauten in der Klosterstr. (aktuelle Screens) habe ich 512x512 oder 512x1024 (bei breiten Häusern) für die Front inkl. Giebel verwendet. Neben den Giebeln fanden dann noch Nebentexturen wie Marqiesen Platz. Für die _#low-Version nehme ich eine auf 25% reduzierte Textur, dann spart man 93% Ladezeit (die Fläche geht ja in der 2. Potenz ein, also nur noch ein Sechzehntel der Fläche!) aber es sieht nicht soo schlecht aus.

OK danke!
Nur damit ich jetzt beim Texturieren in Blender gleich alles richtig mach...

Eines hab ich noch vergessen:
Kann OMSI auch .jpg-Formate erkennen, oder müssen die Texturen .bmp sein?

also, da bin ich mir jetzt nicht sicher - das ist ja eine Frage von DirectX, weniger von Omsi. Es bringt aber nicht sooo viel, weil der Flaschenhals nachher sowieso das Halten im Speicher ist - natürlich unkomprimiert, da machts also keinen Unterschied.