Räder und Kurven

[Gast]

Hallo,

kann mir jemand mal sagen, warum es für die SPieleentwickler so schwierig ist, Kurven als nicht eckige Kurven und Räder als wirklich rund darzustellen?

[Henroldus]

bisher basieren alle spieleengines auf Polygone. das sind dreiecke. je runder und detailierter ein objekt sein soll desto mehr dreicke und rechenpower fordert es aber.
eine technologie für NURBS und B-Splines wie bei raytracern ist nach meines wissens in Echtzeit auf grakas noch nicht machbar, obwohl es auch entwicklungen in diese richtungen gibt.
auch mich k***t es an, dass autoreifen immer noch wie stopschilder aussehen :-(

[Henroldus]

bisher basieren alle spieleengines auf Polygone. das sind dreiecke. je runder und detailierter ein objekt sein soll desto mehr dreiecke und rechenpower fordert es aber.
eine technologie für NURBS und B-Splines wie bei raytracern ist nach meines wissens in Echtzeit auf grakas noch nicht machbar, obwohl es auch entwicklungen in diese richtungen gibt.
auch mich k***t es an, dass autoreifen immer noch wie stopschilder aussehen :-(

[Gast]

Weil aktuelle Grafik aus dreiecken besteht. Umso mehr Dreiecke du nimmst umso runder wird deine Kurve/dein Rad. Problem dabei ist das jedes Dreieck berechnet werden muss und du ja auch ncoh andere Sachen Darstellen willst. Deswegen musst du einen Mittelweg aus Aussehen und Geschwindigkeit gehen.

[Gast]

zu langsam

[RLZ]

bisher basieren alle spieleengines auf Polygone. das sind dreiecke.
Wie kommt man auf die Idee das Polygone Dreiecke sind?
Das ist nur in umgekehrter Richtung richtig.

[Neomi]

kann mir jemand mal sagen, warum es für die SPieleentwickler so schwierig ist, Kurven als nicht eckige Kurven und Räder als wirklich rund darzustellen?

Das ginge alles recht problemlos, wenn die Performance und der Resourcenbedarf mal ignoriert würden.

Einen Reifen kann man mühelos deutlich runder gestalten, man muß nur bestimmte Parameter (z.B. MeshSmooth Modifier in Max) raufziehen. 50.000 Dreiecke, herrlich rund. Straßen sind auch meistens "nur" Shapes, die an einem Spline entlang extrudiert werden. Wie fein da tesseliert wird, läßt sich ebenfalls gut parametrisieren. Dank des abnehmenden Ertrages müssen die Parameter aber gleich ordentlich aufgedröselt werden.

Leider hat das alles eine Menge Nachteile. Die Vertex- und Indexbuffer werden deutlich größer, die Ladezeiten steigen. Objektsammlungen in Sammelbuffern müssen evtl. auf mehr Buffer aufgeteilt werden, dadurch steigt der Resourcenbedarf nochmal. Alternativ (bzw. bei komplexen Einzelobjekten mit mehr als 65536 Vertices sowieso) kann es auch nötig werden, auf 32 Bit Indexbuffer auszuweichen, dadurch wird die Größe des Indexbuffers mit einem Schlag nochmal zusätzlich verdoppelt. Nicht nur die benötigte Geometrieleistung steigt, durch kleine Dreiecke sinkt auch noch die Effizienz des Rasterizers. Und da die Physikberechnung ebenfalls auf diese Geometrie zurückgreift, sinkt deren Performance noch dazu.

Bevor noch die Frage kommt, warum nicht optional...

1. Straßen werden nicht erst beim Laden in die Landschaft reingerechnet, das würde viel zu lange dauern. Der Speicherbedarf würde also sehr stark ansteigen, da alles mehrfach vorhanden sein müßte. Wenn dann auch noch das Spiel um eine DVD zusätzlich wächst (oder bei einer DVD von einem Layer auf zwei), dann ist das alleine schon ein sehr guter Grund dagegen. Es wäre schwieriger zu managen (wenn man keine Vollinstallation voraussetzt, was bei den Datenmengen auch niemandem aufgezwungen werden sollte) und verteuert die Produktion.

2. Sieh dir das Geschrei im "Schlechte Performance aktueller Spiele"-Thread ("PC-Spiele"-Forum) an. Vielen ist es egal, was sie absolut erreichen können, sie wollen grundsätzlich alles auf Maximum haben. Wenn ein Spiel mit maximalen Einstellungen gut aussieht und gut läuft, ist alles OK. Wenn es schon mit mittleren (oder hohen) Einstellungen gut aussieht und gut läuft, mit maximalen Einstellungen aber schon leicht ruckeln (und entsprechend besser aussieht), ist die Hölle los. Dann wird über das Spiel hergezogen, es sei schlecht optimiert, bloß weil auch Spieler ohne Highend-Hardware nichts unterhalb des Maximums akzeptieren wollen. Die Entwickler werden dann dafür abgestraft, daß sie etwas extra anbieten.

[Rhönpaulus]

dreiecke lassen sich besonderds leicht berechnen und sind das einfachste polygon das eine fläche auspannt.
deshalb wird jede geometrie bisher aus dreiecken interpoliert.
für "perfekte rundungen" braucht es unendlich viele dreiecke weswegen immer ein kompromiss aus optischer qualität und rechenaufwand gemacht werden muss.

[3d]

warum kann man nicht einfach ne verktor grafik nehmen?

oder irgendwelche parameter, die der karte sagen:" hier so und so abrunden" ?

[Neomi]

warum kann man nicht einfach ne verktor grafik nehmen?

Tut man doch. Was meinst du denn, was ein Dreiecksmesh sonst ist?

oder irgendwelche parameter, die der karte sagen:" hier so und so abrunden" ?

Dieser Parameter existiert und nennt sich "Normale". Für Geometrie ist das aber nicht praktikabel, weil an harten Kanten die Geometrie dadurch aufbrechen würde.

[Rhönpaulus]

...und das berechnen einer definierten rundung sehr aufwendig ist und damit zeit kostet.
trotzdem geht der trend dahin,siehe unreal engine 3.
dort haben spielecharaktere mehre millionen dreiecke und dann schaut natürlich alles rund aus was rund sein soll.
entsprechend hohe geschwindigkeit wird dann auch von der grafikkarte gefordert.
in unreal1 von 1997 hatte die gesammte grafik in extremszenen maximal 300 dreiecke was damals einzigartig detailiert war.
in ut2k3/k4 waren es dann schon bis zu 130000 dreiecke.

[Gast]

Outcast hat gezeigt was geht, genauso die Umgebungsgrafik in Comanche.

[Cyphermaster]

"Was geht", ist simpel: Praktisch ALLES. Die Frage ist eher, wieviel Performance frißt es dann? Irgendwo muß man für Spiele einen Kompromiß zwischen Grafik-Realismus/Effekten und der Vorgabe "flüssig spielbare Darstellung" erreichen. Und Kompromisse passen eben nicht immer jedem gleich gut.

[Neomi]

trotzdem geht der trend dahin,siehe unreal engine 3.
dort haben spielecharaktere mehre millionen dreiecke und dann schaut natürlich alles rund aus was rund sein soll.

Das sind die Highpoly-Modelle, aus denen die Normal- und Heightmaps errechnet werden. Mit den Ingame-Modellen hat das NICHTS zu tun.

in unreal1 von 1997 hatte die gesammte grafik in extremszenen maximal 300 dreiecke was damals einzigartig detailiert war.

Ich weiß nicht, wie viele es damals waren, aber 300 kann nie und nimmer stimmen. Bis zu 300 pro Charakter würde ich jetzt spontan als realistisch einschätzen.

[Rhönpaulus]

die ue3 kann die polygonzahl onthefly skalieren,die highmodelle werden eingesetzt wenn entsprechde hardware vorhanden ist.
die polygonzahl von unreal kannst mann aus den epicdokumentationen ersehen und außerdem auch im unrealeditor für eine beliebige gameszenario anzeigen lassen.

[Mr. Lolman]

Ich weiß nicht, wie viele es damals waren, aber 300 kann nie und nimmer stimmen. Bis zu 300 pro Charakter würde ich jetzt spontan als realistisch einschätzen.

Rhönpaulus hat recht. Meistens warens sogar unter 100 Polygone. (exklusive Waffenmodell):
http://img178.imageshack.us/img178/6954/glide200511181724260ky.th.jpg (http://img178.imageshack.us/my.php?image=glide200511181724260ky.jpg)

[Blaze]

Ich weiß nicht, wie viele es damals waren, aber 300 kann nie und nimmer stimmen. Bis zu 300 pro Charakter würde ich jetzt spontan als realistisch einschätzen.


Im Launchvideo zum NV40 wurde gesagt dass ein Charaktermodel der UE3 5000 Polygone hat und dass das mehr sind als ein komplettes Level in Unreal 1.

Also kommt schon ungefähr hin.

[Rhönpaulus]

mir ging es eigendlich auch nur darum zu untermauern,das der trend zu immer mehr polygonen anstatt neuer technolgoien wie retracing eindeutig abzusehen ist.
ab einer gewissen polygonzahl ist retracing aber effizienter und die modellierung mit dreiecken nachteilig.
midestens bis dahin wird wohl alles so weitergehen wie bisher.

[T86]

was is eigentlich mit true form von ATI :confused:

aber das gibts ja nichtmehr ;( damit sehen räder oder waffen auch rund aus
ut 2003/2004 zb unterstützen das

[Neomi]

Rhönpaulus hat recht. Meistens warens sogar unter 100 Polygone. (exklusive Waffenmodell):
http://img178.imageshack.us/img178/6954/glide200511181724260ky.th.jpg (http://img178.imageshack.us/my.php?image=glide200511181724260ky.jpg)

Wenn das so ist, hat mich die Erinnerung getrügt, ich hatte da deutlich komplexeres im Sinn. Allerdings meinte ich nicht nur den Level selbst, sondern die Gegner mit dazu. Und diese Fackeln verbraten wohl auch noch einige Dreiecke.

Unabhängig davon ist es aber weiterhin falsch, daß die Highpoly-Modelle bei der UE3 zur Echtzeitdarstellung genutzt werden.

[Aquaschaf]

bisher basieren alle spieleengines auf Polygone. das sind dreiecke. je runder und detailierter ein objekt sein soll desto mehr dreicke und rechenpower fordert es aber.
eine technologie für NURBS und B-Splines wie bei raytracern ist nach meines wissens in Echtzeit auf grakas noch nicht machbar, obwohl es auch entwicklungen in diese richtungen gibt.
auch mich k***t es an, dass autoreifen immer noch wie stopschilder aussehen :-(

Vor dem Rendern werden ja NURBS oder Splines auch wieder in Polygone umgewandelt.

[Coda]

Müssen sie nicht. Man könnte auch Rasterizer oder Raytracer entwerfen die Nurbs direkt zeichnen oder tracen.

[Rhönpaulus]

tureform erlaubt nur eingeschränkte kontrolle über die radien und führt zu problemen wenn andere flächen senkrecht auf diesen gekrümmten kanten stehen.
damit es optimal nutzbar ist muß es mit bedacht eingesetzt werden.
ich kenne nur ut2k3/2k4 wo es perfekt und ohne jedwehige grafikfehler eingesetzt wurde.
allerdings ist man kaum nahe genug an die anderen spielfiguren heranngekommen um das im spiel selber auch zu bemerken.
von daher hat es eigendlich keinen richtigen vorteil gebracht.
auf der 8500 war es aber gut spielbar.

die fackeln in unreal flyby-demo bestehen wie alle fackeln in unreal aus keinerlei polygonen.
die entwickler haben auf sehr hohen niveau viele tricks eingebaut um das spiel optisch auf der damaligen hardware aufzupeppen.
man muß sich nur die spielfiguren anschauen.
die sehen für die geringen polygonzahlen extrem gut aus was die körperformen angeht.