Sind die Zeiten mit guter Kollisionserkennung mit Tesselation vorbei?

[Gast]

Wenn ich mir so ein Mauerwerk wie bei diesem Benchmark anschaue, dessen platte 2d Mauertextur durch Tesselation zu 3d wird, dann frage ich mich, ob diese 3d Aufbohrung überhaupt noch von der Spielephysik für die Kollisionserkennung verwendet wird.
http://unigine.com/press-releases/091022-heaven_benchmark/



Daher die Frage ist mit Tessellation, also DirectX > 10 die Zeiten der guten Kollisionserkennung vorbei?
Erste Ansätzte konnte man ja schon bei Unreal Tournament 3 sehen, da waren einige grafiklastige Bereiche nicht begehbar -> unsichtbare Wand.

[Coda]

Displacement-Maps verändern meiner Meinung nach die Modelle nicht so großartig als das man sich darüber einen Kopf machen müsste.

[Noebbie]

Hm, gerade bei Gefechten, bei der die Deckung nur wenige cm einer Kante ausmacht, könnte das schon zum Problem werden...

[Gast]

Was verstehst du unter guter Kollisionserkennung? Auch heute wird die Kollisionserkennung in der Regel nicht auf Polygonbasis sondern deutlich gröber gemacht.

Für Kollisionserkennung wie wir sie heute kennen stellt das ganze kein Problem dar.

[Gast]

Deshalb wird es niemals wieder so gute, schnelle und präzise MP-FPS geben wie Quake3 und UT. Man möchte manchmal würgen was und wie uns als Kollisionserkennung verkauft wird.

[blutrausch]

na dann wird an der fläche, die von bedeutung ist keine tesselation eingesetzt oder nur in geringem maße - wo ist das problem? es heißt doch nicht dass wegen einer techdemo und eines features dies zwangläufig überall so übertrieben eingesetzt werden muss?

ich bin der meinung dass es sich wie mit hdr entwickeln wird. am anfang wurde es auch total übertrieben eingesetzt um mit features protzen zu können auf verpackung und in slogans. die "progamer" hatten alle angst bei shootern die ganze zeit geblendet zu werden etc xD

time will show ...

ich denke tesselation wird die kollisionserkennung nicht negativ beeinflussen

[Ikon]

Ich habe nur wenig Erfahrung mit Kollisionserkennung, aber meines Wissens nach arbeitet man Quadern und Kugeln, die um die betreffenden Modelle herumgelegt werden. Obwohl ungenau ist selbst das schon ziemlich komplex und teuer im Bezug auf CPU-Zeit. Da macht etwas mehr Ungenauigkeit durch Tesselation wohl auch nicht mehr viel aus.

[Coda]

Deshalb wird es niemals wieder so gute, schnelle und präzise MP-FPS geben wie Quake3 und UT. Man möchte manchmal würgen was und wie uns als Kollisionserkennung verkauft wird.
Bei Quake 3 war die Kollisionserkennung bei Figuren äußerst grob. Selbst "Orb" hatte die gleiche wie allen anderen :ugly:

[Gast]

Bei Quake 3 war die Kollisionserkennung bei Figuren äußerst grob. Selbst "Orb" hatte die gleiche wie allen anderen :ugly:

Bei Quake 3 irrt der Gast ja auch, aber bei UT sieht es anders aus.
Jedes Modell hat seine eigene Kollisionserkennung gehabt und für die Levels gilt das erst Recht.

[Coda]

Jedes Modell hat seine eigene Kollisionserkennung gehabt und für die Levels gilt das erst Recht.
Ganz bestimmt nicht. Das wäre im MP einfach nur unfair.

[Neomi]

Ich habe nur wenig Erfahrung mit Kollisionserkennung, aber meines Wissens nach arbeitet man Quadern und Kugeln, die um die betreffenden Modelle herumgelegt werden.

Normal ist eine Dreieckssuppe (also ein normales Mesh) für statische Levelgeometrie. Für bewegliche Objekte nimmt man Compounds aus konvexen Polyhedra, Kugeln, ..., also eine Kombination aus simpleren Formen, die jeweils einfach zu berechnen sind.

Bei beweglichen Objekten ist das Kollisions-Compound fast immer nur approximativ, außer bei simplen Objekten wie einer quaderförmigen Kiste natürlich. Bei der statischen Levelgeometrie kann man die zur Darstellung benutzte Dreieckssuppe benutzen, oft wird aber auch hier nur eine Approximation benutzt. Der Grund ist nicht zwangsweise die Rechenzeit, sondern oft auch der Spielfluß. Man will ja nicht an jeder kleinen Ecke gleich hängenbleiben.

[Gast]

Ganz bestimmt nicht. Das wäre im MP einfach nur unfair.

Doch, und ja, es war unfair.

Einige haben z.B. diese dämlichen UT-Kühe in UT99 gespielt (meistens ahnungslose Quaker), das war ungern auf UT 99 Servern gesehen, denn die waren wegen dem unterschiedlichen Treffermodell viel schwieriger zu treffen.

Die Quaker auf den UT Servern wußten das natürlich nicht, denn die waren das ja von Quake gewohnt, daß es dort egal war, in UT99 war es aber nicht egal und ein Admin hat solche Leute dann zu Recht vom Server gekickt wenn sie ihr Spielermodell nicht in ein normales Human Modell nah einer Aufforderung geändert haben, wegen unfairem spielen.

[=Floi=]

Bei Quake 3 war die Kollisionserkennung bei Figuren äußerst grob. Selbst "Orb" hatte die gleiche wie allen anderen :ugly:

weil es fair nicht anders geht. wenn man solche models und auch solche wie hunter und tank jr. unterbringen will, dann ist es nicht anders möglich. ich fand und finde diesen weg noch immer gut. imho war carmack (?) schon an einer genauen hitbox dran, aber die war dann zu genau und man schoß durch das model durch. (weil man eben nicht genau den arm getroffen hat.) :rolleyes:

normalerweise schreibst du ja ganz brauchbar, aber hier hast du nicht gerade weit gedacht und ich will nicht nur games, wo alle models gleich aussehen. gerade das machte Q3A aus. es muß nicht alles mit der goldwage aufgewogen werden. Q3A war unrealistisch und unecht und das macht es aus.

[Gast]

Was verstehst du unter guter Kollisionserkennung? Auch heute wird die Kollisionserkennung in der Regel nicht auf Polygonbasis sondern deutlich gröber gemacht.
Bei Doom3 (und folglich vermutlich auch bei Q4 und Prey) ist zumindest die Projektil/Gegner-Kollision wirklich aufs Polygon genau.

[Spasstiger]

Die Entwickler können ja im Singleplayer ggf. unterschiedliche Hitboxen für Modelle mit und ohne Tessellation verwenden. Beim Drachen in der Unigine-Heaven-Demo wäre das z.B. sinnvoll. ;)

[RavenTS]

Wie sieht das denn bei Titeln aus die auch wettkampf-/ligenmäßig gespielt werden? Gibts da auch Probleme oder Vorgaben seitens der Veranstalter?

[Nasenbaer]

Die Entwickler können ja im Singleplayer ggf. unterschiedliche Hitboxen für Modelle mit und ohne Tessellation verwenden. Beim Drachen in der Unigine-Heaven-Demo wäre das z.B. sinnvoll. ;)
Naja die angesprochene Grafikdemo ist ja auch ein Extrembeispiel. Normalerweise (siehe AvP3, Dirt2) dient die Tesselierung ja nur dazu, dass alles runder wieder - und man keinen Klotzkopf mehr hat. Der Kopf wird bei Hitboxen dabei dennoch als Quader dargestellt. Ob Tesselation in späteren Spielen sinnvoller genutzt wird muss man natürlich abwarten - kann man ja auch gut als LoD-System nutzen. ;)

[Gast]

Der Kopf wird bei Hitboxen dabei dennoch als Quader dargestellt.

Normalerweise nimmt man eher Zylinder/Kugeln oder andere "runde" Konstrukte.

Ansonsten hättest du das Problem, dass du überall im Level hängen bleibst.

[Nasenbaer]

Normalerweise nimmt man eher Zylinder/Kugeln oder andere "runde" Konstrukte.

Ansonsten hättest du das Problem, dass du überall im Level hängen bleibst.
Aber nicht für Hitboxen AFAIK. Für die Approximation des Spielermodels bei Level<->Player-Kollision nimmt man dann IMO auch nur eine Approximation und dann halt ein Ellipsoid o.Ä. Für Ragdoll-Effekte werden natürlich dann auch die einzelnen Gliedmaßen etc. berücksichtigt aber bei FPS hat man ja meist keinen richtigen Körper.

[Gast]

Das ist doch ein schlechter Witz.

Als Doom damals Pixelgenaue Hitboxes einführte hat sich jeder drüber aufgeregt und es wurde wieder rausgepatcht. Für wen soll das ganze bitte schön interessant sein? Für unsere "Pro-Gamer" etwa? Das dürften wohl die einzigen sein bei denen das, neben den restlichen Onlinespielen, für Probleme sorgen könnte. Und selbst da gibt es ernsthaftlich andere Sachen zu lösen. Würde es wieder eine richtige, also Pixel/Polygongenaue "Hitbox" geben, wäre das Geschrei mit Sicherheit wieder groß.

[Nasenbaer]

Doom und pixelgenaue Hitboxen? Das glaub ich nicht. Man konnte doch nichtmal richtig zielen - einzig die X-Koordinate wurde doch geprüft so wie ich das erlebt habe. Und natürlich ob zwischen Spieler und Object nichts im Weg ist.