spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Meistens gibt es bei einer Engine Skalierungsangaben, z.B. bei Unreal ist 1 cm = 1 Unit, bei Unity kann ich es dir nicht sagen.
Du kannst das Modell im nachhinein natürlich auch in Unity skalieren, da geht keine Qualität verloren.

Es wurde ja bereits geschrieben, dass man Modelle in Unity nachträglich skalieren kann.

Welche Einheit bei Unity für die Positionierungen etc. verwendet wird, ist nicht fest vorgegeben. Man kann diese als Meter, Kilometer oder Millimeter behandeln. Bei einem intergalaktischen Spiel würde eine Einheit eine wesentlich größere Distanz darstellen, als bei einem Spiel, in dem man eine Ameise (normaler Größe) steuert. Es muss sich dabei aber auch nicht unbedingt um eine real existierende Einheit handeln, so könnte eine Einheit in Unity einer "Feldgröße" des zu entwickelnden Spiels entsprechen, welches wiederum 2 oder Pi Meter sein könnten.
Wichtig ist nur, dass im ganzen Spiel dann von der gleichen Größe der Einheit ausgegangen wird.

Ob die Einheiten Meter oder Einheit genannt werden macht ja eigentlich erst mal keinen Unterschied. Den Faktor den du nennst Bambi den sollte man auch nicht immer benutzen können. Unity hat wie gesagt beim Importieren verschiedene Einstellungen. Je nach Format skaliert Unity da teilweise automatisch, wobei du das einstellen kannst. Was du meinst Bambi ist vermutlich für blend Dateien die seit einiger Zeit ja auch direkt importiert werden können. Falls du die Modelle aus Blender aber als fbx oder was weiß ich welches Format exportierst und sie dann in Unity importierst sieht dieser Skalierungsfaktor wieder anders aus.
Ganz unwichtig ist die Größe deiner Modelle für ein Spiel übrigens nicht. Physik Engines gehen von einer bestimmten Skalierung aus um korrekt zu funktionieren. So ist es ja auch im echten Leben. Stell dir vor du wirfst einen Ball aus deinem Fenster. Je nach Höhe des Hauses dauert es dann ja verschieden lange bis der Ball unten ankommt. Oft gehen Physikengines von 1 Einheit = 1 Meter aus. Diese Werte kann man auch skalieren und so an die Modelle anpassen, einfacher ist es jedoch die Modelle direkt passend zu bauen.
Einen Tipp den ich wirklich hilfreich fand war es zuerst eine Figur anzulegen. Die muss nicht final texturiert und modelliert sein, wichtig ist eher dass die Maße einigermaßen stimmen. Die lädst du wenn du deine Häuser etc baust einfach mit in Blender. Jetzt hast du eine gute Referenz für Größen. Du kannst dich an der Größe dieser Figur orientieren wenn du deine anderen Modelle baust. So erreichst du dass die Modelle untereinander das selbe Größenverhältnis haben. Das hat den Vorteil dass du in Unity nur noch einen Skalierungswert brauchst der für alle Modelle gleich ist. Das macht es ein wenig einfacher als wenn jedes Modell für sich anders skaliert werden muss. Vor allem wenn du merkst dass du mit der aktuellen Skalierung nicht zufrieden bist und alle anpassen musst/möchtest.

Zitat von »Bambi«

und deswegen sag ich ja ... meter am besten verwenden. am besten immer reale welt dimensionen.

Am besten sind solche Einheiten, bei denen man keine Probleme mit der Genauigkeit der Fließkommazahlen bekommt. Wenn man bspw. eine Wirtschaftssimulation oder ein Strategiespiel entwickelt, kann es relativ einfach passieren, dass ein einzelnes Gebäude (mal angenommen das Bauen ist auf ein Raster beschränkt) 10 oder 20 Meter breit ist (hängt vor allem vom Setting ab), wo es schon Sinn ergeben könnte, eine Spielinterne Einheit mit 10 oder 20 Metern anzugeben. Für die Gravitation (sowie wahrscheinlich auch diverse andere Kräfte/Beschleunigungen) würde man den Wert entsprechend anpassen (statt 10 eher 1 oder 0,5 Einheiten je Sekunde²) und das Verhalten wäre wieder richtig.
Deutlicher wird das vor allem dann, wenn der Spieler keine Menschenähnliche Figur steuert, sondern etwas weit kleineres. Eine Ameise habe ich bereits als Beispiel genannt, deutlicher wird es aber mit "Nanobots". Statt mit Werten im Bereich von bspw. 0,0000001 m (bei 1 Einheit = 1 Meter) zu arbeiten, wären 0,1 µm (1 Einheit = 1 µm) oder 100 nm (1 Einheit = 1 nm) schon deutlich besser für die Genauigkeit.

Zugegebenermaßen macht sich das bei großen "Grundwerten" eher bemerkbar, da die Größe der Umgebung (Sternensystem, Galaxien, ...) ebenfalls mit rein spielt. Während der Entwicklung ist es aber grundsätzlich angenehmer, mit Zahlen zu hantieren, die sich mit einer geringen Anzahl von Dezimalstellen darstellen lassen.

Bei Fließkommazahlen treten dadurch keine Probleme mit der Genauigkeit auf!
Die Dinger heißen nicht ohne Grund Fließkommazahl. Das liegt daran, dass das Komma nicht fest ist. Die Dimension ist praktisch völlig irrelevant. Fließkommazahlen wurden genau deshalb erfunden, damit die Wahl des Wertebereiches automatisch passiert und nicht vom Programmierer abgenommen wird. Fließkammazahlen einfacher Genauigkeit bestehen aus 7 Bit Expontent der es ermöglicht, Zahlen automatisch im Bereich von extra -10^37 bis 10^38 zu skalieren. So zu sagen der genaue Wert selbst, die Mantisse besteht aus 24 Bit und wird immer in den Bereich 1 ... 2 skaliert. (abgesehen von denormale Zahlen, aber die sind in diesem Wertebereich nicht relevant). Dabei ist es egal, ob du bei -10^30, 3f, 100 oder 10^35 liegst.

Probleme mit der Genauigkeit gibt es immer nur bei mehreren Zahlen relativ zueinander. Die kleine Zahl ist dann so klein, dass sie schlicht keine Auswirkungen aufeinander hat. Rechnet man zum Beispiel 1 + 16777216 kann wieder 16777216 raus kommen. 16777216 ist 2^24, wegen der Anzahl Bits in der Mantisse. Das genaue Ergebnis ist auch von den aktuellen Rundungseinstellungen abhängig, so könnte theoretisch bei spezieller Konfiguration auch 16777218 rauskommen, aber es gibt keine Gleitkommazahl einfacher Genauigkeit die 16777217 repräsentiert.
Das Problem ist aber nicht an die Dimensionierung gebunden und tritt auf exakt die selbe Weise mit 0.0000000000001 und 0.0000016777216 auf. (Abgesehen davon, dass natürlich schon 0.0000000000001 nicht exakt dargestellt werden kann, weil es im Binärsystem ein periodischer Dezimalbruch ist)

Wenn du Genauigkeit nicht reicht kann man entweder "double"-Zahlen nehmen die deutlich weiter gehen oder Festkommazahlen. Nimmt man Festkommazahlen muss man zwar tatsächlich aufpassen, dass auf der einen Seite die Dimensionierung stimmt(Das Komma ist dann ja fest, nicht mehr automatisch bewegt) als auch auf der anderen Seite, dass keine Überläufe auftreten. Allerdings sparte man die Bits für den Exponenten und erhält so noch 7 Bit Genauigkeit geschenkt, sollte man den Dynamikumfang gar nicht benötigen. Häufig ist es eigentlich theoretisch nämlich nicht sinnvoll, dass Objekte mit zunehmender Entfernung in sich ungenau werden. Man nimmt floats einfach aus Faulheit wegen den Automatismus und braucht überall theoretisch die gleiche Genauigkeit.

Fazit:
Nimmt man floats ist die Dimensionierung technisch vollkommen egal. Folglich kann man die Zahlen komplett nach Nutzerfreundlichkeit skalieren. Ich würde mich daher immer am Meter orientieren.

Zitat von »Bambi«

und deswegen sag ich ja ... meter am besten verwenden. am besten immer reale welt dimensionen.

Etwas ungeeignet für ein Strategiespiel alles in realen Koordinaten und Dimensionen abzubilden, findest du nicht? Das sähe dann weniger wie Starcraft aus, sondern eher wie Sim-City - Age of Empires ist irgendwas dazwischen.