Reduktion des Overdraws zur verhinderung von Wallcheats

[Demirug]

Das ganze begann hier:

http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=25678&pagenumber=6

@Haarmann:

Das ist nicht mein Server Model. Ich habe nur erwähnt das sowas schon gemacht wurde. Der Sound ist dabei aber nicht wirklich ein Problem. Die Gegnerposition muss nur dann geschickt werden wenn man ihn auch sieht. Beim Sound wird die Refelktionsposition gesendet. Das macht das Cheaten dann komplizierter.


Ansonsten sehe ich es nicht ein CPU Zyklen für etwas zu verheizen was die Grafikkarte viel besser und günstiger machen kann nur damit ein Cheat nicht mehr möglich ist. Wenn man ein Loch zu macht finden die Cheater ja doch wieder ein neues. Und ich sehe es nicht ein den ehrlichen Spieler mit Leistungseinbussen zu bestrafen.

[zeckensack]

Originally posted by Demirug
Ansonsten sehe ich es nicht ein CPU Zyklen für etwas zu verheizen was die Grafikkarte viel besser und günstiger machen kann nur damit ein Cheat nicht mehr möglich ist. Wenn man ein Loch zu macht finden die Cheater ja doch wieder ein neues. Und ich sehe es nicht ein den ehrlichen Spieler mit Leistungseinbussen zu bestrafen. *zustimm* :)

[Haarmann]

Demirug

Naja... bei Q3 ist der Sound sicherlich kein Problem - er funktionierte noch nie richtig ;). Ausser die A3D Variante - der Rest läuft so gut wie nie so, wie sie laufen sollte ... ev hat hier auch wer nach Deinem Vorschlag gehandelt *eg*

Aber das ist mal Nebensache. Für A3D 2.0 müsste man die exakte Position der Geräuschquelle kennen - EAX oder MS kenne ich nicht.

CPU Zyklen verbrätst Du auch z.B. für die Animation eines Models, welches danach zwar auch niemand mehr sieht, weils eh überschrieben wurde...


Das Detection Model funz im Endeffekt genau gleich wie die Kollisionsabfrage mit Aussenboxen. Die Idee dahinter ist ja sehr einfach und sicherlich bekannt. Boxen dreht man natürlich gegen den Beobachter (nur die der bewegten Objekte). Dann muss man nur noch 4 Punkte Rechnen statt 8.

Es gibt nun 2 Klassen an Objekten. A Objekte, die soviel Leistung fressen, dass ein wegschneiden lohnt (Q3 technisch mal alle Figuren und z.B. die Zunge aus DM1) und B Objekte, die so gross sind, dass die andere Verdecken können (Simpel gesagt z.B. ne Wand oder ne Kiste resp nen Gebäude - nix transparentes natürlich). Grösse hat nix mit Distanz zu tun.

Die Anzahl der für relevant befundenen Objekte ist also eigentlich ziemlich klein. Mehr denn ev 200 werdens also nie sein. Diese Objekte können ja nicht kollidieren, ergo sind Schnitte nicht möglich. Auch das ist danach wichtig, da ich nun teste, ob alle 4 Punkte eines A, durch ein B laufen, aufm Weg zum Beobachter. Ist dies der Fall kann mans wegschneiden. Mittels erstem Punkt holt man sich die Möglichkeiten (kleiner Zonenplan ala TBR ist ebenfalls mit eingebaut zur Vorselektion) aller B, die in Frage kommen (Ein Punkt daneben und das Objekt is eh nimmer relevant). Trifft der erste Punkt, so werden erst die 3 weiteren gerechnet und dann zum nächsten Objekt übergegangen (logisch, denn es reicht zu wissen, dass etwas davor steht, selbst wenn 10 Sachen davor stehen). Pro Punkt fallen glaubs 20 Operationen an.

Ein kleiner Nebeneffekt ist daher, man sieht nie mehr Gewehre durch geschlossene Türen oder Wände ragen...

Wie gesagt, es is nix anderes, denn ne Erweiterung einer eh notwendigen Kollisionsabfrage und ist auf F P S Games hin optimiert. Fürn Weltraumsims also ned geeignet.

Mal gucken ob ichs so gesagt hab, wie ich denke resp obs jemand so versteht, wie ichs gemeint hab ;)

[Demirug]

Die Animation sind sehr einfach. Entweder sind sie bereist als Motiontracking datensatz hinterlegt oder werden über inverse Kinematik bestimmt. Da es sich dabei um lokal begrenzte Physik handelt geht das sehr schnell. Das eigentliche Skinning wird dann über die VS gemacht.

Das was du beschreibts ist ein normales Occulsion Culling. Ich hab mal 4 Wochen damit verbracht das Verfahren zu analysieren. Dabei bin ich auf folgende Problem gestossen:

1. Bei den Occuldern (die gossen Objekte) darf man keine Bounding Box verwenden. Es darf nur eine Innerbox benutzt werden. Bei Wänden ist das kein Problem im Outdoorbereich decken diese Innerboxes aber meistens die Objekte nur sehr unzureichend ab.

2. Man kann nur feststellen ob ein Object komplett von einem Occulder verdeckt wird. Die Prüfung ob mehrer Occulder gemeinsam ein Object verdecken ist wesentlich komplizierter.

3. Die Entfernung spielt durchaus eine Rolle. Eine Wand die nur aus ein paar Dreiecken besteht gibt einen guten Occulder ab wenn man direkt davor steht. Ist sie allerdings weit weg bringt sie nichts mehr. Desweiteren sollte man für die Modele ein entfernungabhängiges LOD benutzen.

4. Für Terrain ist das ganze überhaupt nicht zu gebrauchen.

Das ist auch der Grund warum ich mich auf EarlyZ Verfahren verlasse (wie bei DOOM III). Mit DX9 wird das ganze dann noch um passives Hardware Occulsion Culling (falls die Karte das kann) ergänzt. Damit habe ich dann Occulsion Culling auf Fragment ebene.

[Haarmann]

Demirug

Notebook abgeliefert - also noch Zeit für nen kurzen Reply, bevor ich auf die Inlines hoppse.

Zu 1

Man kann dort auch klug murksen mit den bewegenden resp kleinen Objekten - dann gehts trotzdem wieder. Kleiner Nebeneffekt ist noch, dass durch die Sortierung der Objekte ich locker die Daten von Vorne gegen Hinten übergeben kann. Das ist bekanntlich essentiel für Hyper-Z resp LMA.

Zu 2

Leichte adaption und man kriegts hin, indem man Occluder zusammenlegen kann. Ist eh notwendig in gewissen Fällen (Wand mit Fenster).

Zu 3

Das finde ich nun CPU Verschwendung (und diese ist ned so knapp) mitm dynamischen LOD - ev kriegen wir da allerdings auch mal HW Alternativen.

Zu 4

Terrain hat wesentlich weniger Overdrawprobleme - dort hatte ich meist andere Sorgen in den Games... zuwenig Grakaram für die Texturen z.B.


Wie gesagt 20 Operationen pro Punkt sind nötig. Im Zeitalter von ISSE2 und 3dnow kannste das z.T. gleich noch halbieren. Inkl Superskalar ev sogar noch weiter reduzierbar.

Jede Form der AGP Datenübertragung, die ich einsparen kann, ist auch gewonnene CPU Zeit, denn dann hat die CPU den Speicher für sich...

[Demirug]

Haarmann, viel spass beim skaten bei uns regnet es schon den ganzen tag.

1. Was hat die sortorder mit den der grösse des Occluder zu tun? Da kann ich dir nicht ganz folgen.

2. Wen du mehrer Occluder zusammenfast hast du einen unsymetrischen Körper. Das ist wie gesagt echt schwer zu prüfen.

3. Was ist den da CPU verschwendung. Einfach mehrer Indebufferdatenpackete die entfernungsabhängig genutzt werden. Die CPU kosten dafür sind minimal.

4. Terrain hat sehr wohl ein Overdraw problem. Sonst würde CLOD nicht so gut funktionieren. Was die Texturen angeht so blendet man das mit ca 6 Basistexturen zusammen. Das braucht gar nicht so viel Platz da die Basistexturen nicht so gross sein müssen.

[Haarmann]

Demirug

Ich glaub echt, dass ich oben nicht ganz ideal alles erklärt hab...

Unsere "Engine" war natürlich nicht nur 3D Engine... Sorgte gleichfalls für den Rest des Games. Also Physik und Collision (zu Deutsch wohl alles, was Du aufm Server machen würdest bei nem C/S). Sämtliche Objekte, benutzten wir dadurch wenns auch ging so oft wie möglich. Diese Boxen waren z.B. bereits für die Kollisionsabfrage notwendig, ergo zwangsweise vorhanden und waren bei den statischen Objekten bereits in der "Map" definiert. In diese Map wurden dann die dynamischen Objekte (Spieler resp KI) gesetzt.
Welche Objekte als überhaupt "im Weg" stehen konnten war natürlich auch schon in der "Map" definiert. Diese "Map" wiederum enthielt keine Details, nur diese Boxen und jede Box hatte quasi nen Pointer aufs Detailobjekt. Diese Boxen durften wie gesagt NIE kollidieren (konntens auch ned). Von daher hat das einigen Aufwand in den Berechnungen gespart. Wir haben auch ned 3D Verktoren gerechnet, sondern 2 mal 2D - auch das wiederum spart gewaltig Takte (so seltsam das klingen mag).

Der Renderteil besteht dann im Endeffekt nurmehr ausm Daten der Detailobjekte schicken, welche als Sichtbar definiert wurden resp in ner Sichtbarkeitsliste drin waren (Was man Heute wohl on the Fly machen würde). Wobei zu beachten ist, dass man nie das ganze Detailobjekt schickt, sondern nur die Forderseite.

Kleines BSP, weswegen Daten übern AGP die CPU locken... FastWrites lassen quasi die CPU Daten schaufeln... sicherlich nicht gerade ne Nutzbringende Rechenart.

Ev isses nun etwas klarer geworden, weswegen dieses Verfahren rel einfach ist und wo alles gespart wird.

[Demirug]

@Haarmann:

Das es sich nicht um eine reine Grafikengine handelt habe ich mir schon gedacht. Wäre für ein Spiel ja auch Blödsinn.

Bei einer Indoorengine die nur relative statische Level unterstützt dürfte die sache sogar gut funktionieren. Meine Tests waren auf Basis einer hoch dynamischen Indoor/Outdoor Engine.

Was aber definitive jede moderene Karte in die Knie zwingen wird ist das sofortige Rendern der Daten eines Objects nachdem man erkannt hat das es sichtbar ist. Die Karten mögen es wenn man seine Polys nach einen bestimmten Muster vorsortiert.

Wie soll den das mit der Vorderseite in der Realität funktionieren. Mein Model liegt im AGP Bereich oder im GraKa RAM schön grafikkartenfreundlich als Stribeset angeordnet. Da kann ich nicht einfach so einen Teil rausnehmen. Und beim Backfaceculling kann die CPU die GPU sowieso nicht schlagen

[Haarmann]

Demirug

"Das es sich nicht um eine reine Grafikengine handelt habe ich mir schon gedacht. Wäre für ein Spiel ja auch Blödsinn."

*nickt*

"Bei einer Indoorengine die nur relative statische Level unterstützt dürfte die sache sogar gut funktionieren. Meine Tests waren auf Basis einer hoch dynamischen Indoor/Outdoor Engine."

Läuft da sogar nahzu perfekt, aber man muss als Leveldesigner wesentlich weiter denken denn normal. Das is dann so ne Folge davon. Oder wo siehst Du genau die Probleme?

"Was aber definitive jede moderene Karte in die Knie zwingen wird ist das sofortige Rendern der Daten eines Objects nachdem man erkannt hat das es sichtbar ist. Die Karten mögen es wenn man seine Polys nach einen bestimmten Muster vorsortiert."

Das ist wieder ne Frage der Models, obs Sinn macht es zu cullen Heute, weiss ich ned - damals sicherlich ja.

Heute könnte man da sicherlich viel verbessern - aber die Grundzüge bleiben gleich.

[Demirug]

Haarmann,

also problem direkt sehe ich nicht. Denke aber das bei statischen Indoor Levels eine Portal engine besser funktioniert und dem Leveldesigner weniger probleme bereitet da man das einfügen der Portale im Editor weitgehen automatisieren kann. Ist im Endeffekt aber etwas ähnliches wie das von dir beschriebene Verfahren. Bei Portalen wird halt eine positive Prüfung durchgeführt.

Was das Cullen angeht: Immer die GPU machen lassen. Alles andere würde zu einer zu starken Zerstückelung des Models führen. Die Karten mögen aber grosse Batches von Dreiecken und nicht immer nur ein paar einzelne nacheinander.

Es kommt heute nicht mehr so darauf an einzelne Dreiecke zu entfernen. Man wirft nur ganze Objekte raus. Für Indoor Bereiche gibt es dafür ja ausreichend gute Verfahren nur Outdoor mangelt es da doch noch sehr (gutes Beispiel dafür ist MW).

[Haarmann]

Demirug

Bei ner Portal Engine sehe ich das auch ein. Portale sind in freier Wildbahn einfach seltener zu finden, denn in z.B. nem Haus ;).

Das is auch ne Frage, wie das Model aufgebaut wurde - ich denke mal, dass es durchaus möglich ist z.B. wie im Q3 Models als 3 Models zu haben, die je 9 Teile haben. Egal wo ich hinsehe, fallen minimum 8 Teile weg - praktisch.

Outdoor Levels sind oft auch ziemlich kläglich designt - ich denke mir nen paar animierte Sprites sind zZ z.B. noch die beste brauchbare "Grasemulation".

[Demirug]

Haarmann,

Model zu zerstückeln ist bei aktuellen Karten (DX8) echt keine gute Idee. Wenn das Object eine Animation hinterlegt hat treibt das einem zum Wahnsinn. Da heute die meiste Zeit beim erzeugen des Content verbraten wird ist es unmöglich den Designer noch mehr arbeit aufzuhalsen und dabei das Buget einzuhalten. Was also nicht automatisch gemacht werden kann wird einfach nicht gemacht.

Fürs Grass finde ich die UT Technik ganz gut.

[Haarmann]

Demirug

Als wir das entwickelten, war alles, was es gab mal grade ne ATI Mach8 oder so... Also vergiss gleich alle Gedanken an sowas modernes wie DX8 ;).

Praktisch alles wird erst per render to Texture zusammengeschustert worden und danach geblittet worden. Aus Heutiger Sicht klingt das wohl wie Steinzeit ;). Aber wenn nur nen 64KB Framebuffer bei 320*200 mit satten 256 Farben hast, wirst erfinderisch. CPU Power war auch nicht gerade im Übermass vorhanden. Ne FPU? Was ist das?

Am Ende haben wir das ganze dann mal als Freiflug um nen Texturierten Würfel resp ne Kugel ausgeproggt. Objekt Designtools hatten wir ja auch ned. Also alles Handarbeit. Aber spannender als Geo oder sowas in der Art wars alleweil ;). Alleine die Mathe Murkse finde ich bis Heute lustig.

[Demirug]

Haarmann,

ja die alten Zeiten. Zu meinen 486 Zeiten hab ich auch mal einem Softwarerenderer rumgefummelt. Das Problem dabei ist nur das mir ein großteil der damals gemachten Erfahrungen eher hinderlich waren als ich dann in die 3d-geschichte wieder eingestiegen bin. Was damals gut war hat sich bei den 3d-Karten als unbrauchbar erwiesen und umgekehert.

[Haarmann]

Demirug

486 war dann etwas später ... waren 386er 25MHz von CPQ. Also definitiv keine Renner. Aber es lief soso lala...
Die Ideen dahinter funzen zum grossen Teil sicher noch, alleine mitm SSE2 kannst wohl damit schnell zur Sache kommen. Wie gesagt oft nur 20 Integer Operationen und man war fertig. Klaro müsste man dann die Details mitm Rendern neu anpassen, aber das Game Model taugt noch - ev kriegt man bei nem P4 2GHz sogar schon bis zu 1000 Objekte hin, wovon rund 100 geprüft werden können. Müsste das aber mal genau nachrechnen.

Leider hab ich bekanntlich nimmer viel mit 3D und Games am Hut und wenn ich progge, dann z.B. CGIs und zwar Delphi only ;). Ev wird sich das mal wieder ändern, wenn ich irgend ne geniale Erleuchtung hab, wie ich proggen kann, ohne dass ich die Finger bewegen muss ;).

[vogel]

Unser server sendet dem client alle Spieler die in naechster Zeit sichtbar werden koennen und sendet alle Spieler die vor kurzem sichtbar waren (und natuerlich alle sichtbaren) um das ploetzliche erscheinen eines Spielers bei hohem Ping zu verhindern.

Perfektes occlusion culling lohnt sich heutzutage nicht mehr. Die meisten Objekte in modernen Spielen haben viele "Loecher", grosse bounding boxes und und und. Die Zeiten des Spannbuffers sind endlich vorbei da Grafikkarten mittlerweile schnell genug sind :) Z.b. war UT relativ schneller als Q3 da Grafikkarten damals verhaeltnismaessig langsamer waren und UT spanbuffering benutzte wohingegen Q3 einfach alles renderte. Heute sieht das Bild komplett umgedreht aus da GPUs sehr viel schneller schneller wurden als CPUs.

Wir benutzen ein auf Portalen basierendes PVS Schema in dem in einem Raum einfach alles im view frustum das nicht explizit von einem Anti- Portal ueberdeckt wird gerendert wird. Funktioniert sehr gut indoor da man einfach die Tueren als Portale benutzt. Outdoor benutzt man dann Anti- Portals (Occluders) um mit grossen Objekten (Terrain, Gebaeude) andere zu verdecken. Alles in allem fuehrt dies in Outdoor Levels zu einem durchschnittlichen Overdraw zwischen 5 und 8. Indoor ist es weniger. Sehr sehr sehr sehr sehr viel schneller als span buffering :)

-- Daniel, Epic Games Inc.

[Demirug]

Hi Daniel,

ich bin mir zwar nicht sicher ob die UT Engine daraus vorteile ziehen könnte aber fragen kostet ja nichts.

Plant ihr irgendwas in der Richtung Hardware Occulssion Culling mit DX9 bzw wollt ihr überhaupt auf DX9 updaten?

[vogel]

Originally posted by Demirug
Hi Daniel,

ich bin mir zwar nicht sicher ob die UT Engine daraus vorteile ziehen könnte aber fragen kostet ja nichts.

Plant ihr irgendwas in der Richtung Hardware Occulssion Culling mit DX9 bzw wollt ihr überhaupt auf DX9 updaten?
XBox kann hardware occlusion culling, lohnt sich aber nicht wirklich fuer uns - vor allem da man Resultate nur deferred erhaelt (z.B. das naechste Frame) wenn man die HW nicht stall'en will. Fuer Coronas und so Zeugs ist es aber interessant.

-- Daniel, Epic Games Inc.

[Demirug]

Originally posted by vogel

XBox kann hardware occlusion culling, lohnt sich aber nicht wirklich fuer uns - vor allem da man Resultate nur deferred erhaelt (z.B. das naechste Frame) wenn man die HW nicht stall'en will. Fuer Coronas und so Zeugs ist es aber interessant.

-- Daniel, Epic Games Inc.

Dürft ihr das mit den XBox eigenschaften überhaupt so öffentlich verraten??? Ich dachte immer für das XDK mus man einen NDA unterschreiben. Wobei die occlusion culling Geschichte ja aus der OpenGL erweiterung von NVIDIA mehr oder minder bekannt ist. Das mit dem deferred Ergebnissen ist schon etwas ärgerlich scheint aber bei DX9 noch nicht genau festgelegt sein.

Bei einer Engine im DOOM III Stil dürfte es aber sehr brauchbar sein wenn man das occlusion culling wärend des Z-Only Pass durchführt und die Ergebnisse dann bei den Light Passes zur verfügung hätte.

[Haarmann]

vogel

Falls das beantwortbar is...
Und wie löst ihr das mitm Sound? Man sollte doch die Geräusche des anderen hören, weit bevor man den sehen kann? Wie gesagt, nix gegen diese Idee mitem Server, löst definitiv das Wandwirddurchsichtigproblem, aber der Sound müsste bei dem Verfahren einfach untern Tisch fallen, was mich persönlich nicht gerade erfreut...

Schön wärs ja auch, wenn man die Detection von Treffern auf den Client auslagern könnte... Aber das ist wohl dann zu cheatanfällig, aber eigentlich das einzig Brauchbare.

Was mich allerdings mehr Wunder nimmt... Viel viel schneller heisst genau was?
Wir brauchten nur nen paar DIV/MULs und vor allem ADDs (Compare is auch ADD) - etwa 20 Operationen pro Objekt resp Punkt (max 4 Punkte je Objekt). Natürlich nun mit AntiPortals (passe mich mal der Ausdrucksweise an) gerechnet. Wie kriegt man denn sowas noch schneller hin? Da fehlten mir nun nämlich echt die Ideen für.
Und weswegen ich eigentlich der Meinung bin, das dies Sinn ergibt (nebst Cheatblock und keine Clippingfehler mehr), ist eben vor allem wegen extrem Detailierten Spielfiguren, die dadurch möglich wären. Alleine Ein sehr gutes, animiertes Gesicht oder ne animierte Waffe frisst ja Polys wie blöd (also so sah das bisher bei den Models der Kollegen jedenfalls aus) - machts auch bei sagen wir Figuren mit je 200k Polys keinen Sinn mehr?

[Haarmann]

Demirug

Mit etwas mehr Aufwand, kann man auch detecten, ob ein Objekt durch mehrere Objekte abgedeckt wird. Hab ich inzwischen noch schnell mal überprüft und der Aufwand ist zwar grösser, aber hält sich im Rahmen und lässt sich auf das andere Verfahren aufsetzen - spricht minimal bleibt die erforderliche Leistung ca gleich.

Wie löst man eigentlich nun das Auftragen einer Textur auf ne Kugel (als Freiformfläche - oder geht sowas noch immer nicht vernünftig?)? 3D Texturen sinds ja wohl nicht, weil einfach zu gross. War für uns jedenfalls ein ziemliches Gemurkse, bis wir das sauber draufgeschaufelt haben... Kugeln kannten wir eben als Objekte, daher die Frage. Freiformflächen sind ja nun angeblich auch möglich.

[vogel]

Sound wird seperat vom Spieler uebertragen.

Spanbuffering ist ist sehr CPU intensiv - ich meinte das als Vergleich da es die beste (und langsamste) Variante ist um Overdraw zu vermeiden. Mittlerweile wird nur noch die Boundingbox durch den BSP und view frustum gefilteret und dann werden noch Portals/ Anti- Portals in betracht gezogen und wenn es immer noch sichtbar ist gerendert => ziemlich viel Overdraw aber schnell.

Unser occlusion culling ist auf Objekt und nicht auf triangle- Basis also ist es egal (so lange wir nicht durch triangle throughput limitiert sind) wieviele Polygone ein Objekt hat. Im Augenblick sind wir stark Fillrate- limitiert auf low end Maschinen also koennte vielleicht noch das eine oder andere Polygon ohne mehraufwand mitgerendert werden - ist aber ziemlich schwer die perfekte Balance auf allen Systemen zu finden.

Man sollte fuer den worst- case optimieren und da sind 200k Polygone pro Spielfigur bei weitem nicht drin. Rendern koennte man sie aber das skinning ist ziemlich CPU intensiv. Mit 'ner GF3 ist es auf der CPU schneller und wir benoetigen das Ergebnis fuer Kollision und fuer render- to texture Effekte (Schatten) also passiert das fuer UT2003 auf der CPU. Mit DX9 koennte HW skinning interessanter sein da es mehr Konstanten gibt und man nicht mehr auf x 'bones' pro pass limitiert ist. Mal sehen. Was eher moeglich ist (und mehr Sinn macht) ist ein high poly model zu basteln und es dann auf 'ne normal map und ein "lower" poly model runterzurechnen a la Doom III.

-- Daniel, Epic Games Inc.

[Demirug]

Originally posted by Haarmann
Demirug

Mit etwas mehr Aufwand, kann man auch detecten, ob ein Objekt durch mehrere Objekte abgedeckt wird. Hab ich inzwischen noch schnell mal überprüft und der Aufwand ist zwar grösser, aber hält sich im Rahmen und lässt sich auf das andere Verfahren aufsetzen - spricht minimal bleibt die erforderliche Leistung ca gleich.


Bei uns wurde das ziemlich wild da wir oft Fälle hatten bei denen 4 oder noch mehr Occuluder benötigt wurden um ein Object komplett abzudecken.


Wie löst man eigentlich nun das Auftragen einer Textur auf ne Kugel (als Freiformfläche - oder geht sowas noch immer nicht vernünftig?)? 3D Texturen sinds ja wohl nicht, weil einfach zu gross. War für uns jedenfalls ein ziemliches Gemurkse, bis wir das sauber draufgeschaufelt haben... Kugeln kannten wir eben als Objekte, daher die Frage. Freiformflächen sind ja nun angeblich auch möglich.

Ja Kugeln sind nach wie vor eine problematische Sache. Es gibt dafür bei DX zwar Normen für Freiformflächen. Aber derzeit gibt es nur einen Chip der sowas unterstützt (R200 -> N-Patches bzw Truform). Allerdings hat man mit N-Patches auch so seine Probleme darüber gibt es bereits einen Thread.

Die alternative ist die CPU die Tessellation machen zu lassen.

[Legolas]

Mal eine dumme Zwischenfrage meinerseits, die eigentlich etwas OT ist :):

Was ist eigentlich Spanbuffering??? Hab den Begriff noch nie gehört. Wäre mal nett, wenn sich jemand erbarmen könnte, um mir das zu erklären :).

[Demirug]

@legolas:

Bin gerade etwas faul: http://www.foxfiber.net/dica/3dica4.htm Kapitel 4.4

[Legolas]

Danke Demirug! :)

[Quasar]

Originally posted by Demirug
Aber derzeit gibt es nur einen Chip der sowas unterstützt (R200 -> N-Patches bzw Truform).

GF3/4 können das auch, wenn auch nur inoffiziell. Bezier-Patches werden da glaube ich u.a. genutzt.

[Demirug]

Originally posted by Quasar


GF3/4 können das auch, wenn auch nur inoffiziell. Bezier-Patches werden da glaube ich u.a. genutzt.

Es sind RT-Patchs. Ist aber aus irgendeinem Grund in den aktuellen Treibern gespert. Für RT-Patches braucht man aber eine komplet neue ART-Pipeline und das lohnt selbst bei der derzeitigen Verbreitung von GF3/4 Karten nicht.

[Haarmann]

Demirug

Krieg ich auch hin mit mehr denn einem Objekt - bisher war mir da nur der Sinn nicht klar. Ebenso kann man die Entfernung der Objekte noch berücksichtigen - bist ca 200 is das auch sehr schnell sortiert (vor allem, da der Moni eh schon quasi 4 Tiles hat). Kannst sogar die Objekte, die cullen willst in 4 Teile zerlegen, ohne dass es dabei viel zu rechnen gibt. Brachte nur ned soo viel für damals.

Da hoffe ich mal, dass sich Kugeln dann besser mit Displacement Maps machen lassen (mir gefällt das Verfahren sehr... erinnert mich an was). Aber ich denke keiner wirds so machen.

Ev mach ich dann mal nen paar Formeln hier rein, wenn ich Zeit hab, die mir wieder aus den Tasten zu saugen... Die Takte stehen ja bisher einfach so leer im Raum und wenn ich den S-Buffe angucke, wird mir ab der CPU Load schlecht ...

[vogel]

Originally posted by Demirug
Dürft ihr das mit den XBox eigenschaften überhaupt so öffentlich verraten???
Das XBox occlusion culling hat ist langlaeufig bekannt.

-- Daniel, Epic Games Inc.

[Haarmann]

vogel

Ich warte eigentlich doch noch immer auf ne gute Erklärung, wieso Q3 r_faceplaneculling 1 doch einiges an Leistung bringt gegenüber r_faceplaneculling 0. Ich denke Du kennst die Engines der Konkurrenz vom Aufbau her sicherlich sehr gut, da ihr doch alle mitm gleichen Wasser kocht.
Würde mich persönlich interessieren, welches Verfahren da genau benutzt wird, denn das konnte ich bisher noch nirgends lesen.

THX

P.S. Hab ich schon im Xabre Cheater Thread gefragt, aber noch keine Antwort bekommen.

[vogel]

Man hat mich eines besseren belehrt. NV_occlusion_query ist garnicht so uebel :)

http://www.inf.bme.hu/~kenez/occl.html

-- Daniel, Epic Games Inc.

[vogel]

Originally posted by Haarmann
r_faceplaneculling 1 doch einiges an Leistung bringt gegenüber r_faceplaneculling 0. Ich denke Du kennst die Engines der Konkurrenz

Sorry, keine Ahnung was r_faceplaneculling macht.

-- Daniel, Epic Games Inc.

[Demirug]

Originally posted by vogel
Man hat mich eines besseren belehrt. NV_occlusion_query ist garnicht so uebel :)

http://www.inf.bme.hu/~kenez/occl.html

-- Daniel, Epic Games Inc.

Der Meinung bin ich ja schon länger.:D Wird halt leider mit DX erst ab 9 gehen. Wobei natürlich die Frage bleibt ob das ein NVIDIA only feature sein wird. In dem Fall hätte NVIDIA bei Engines die das nutzen IMO einen erheblichen Vorteil.

Hier gibts noch ein bischen was dazu:

http://www.cis.ohio-state.edu/~hwshen/888_sp02/gao.ppt

[RadioactiveMan]

@ Demirug

das Feature wird sicherlich nicht ewig NVIDIA only bleiben, wie erklärst du dir sonst dies hier:

/*
** GL_NV_occlusion_query
**
** Support:
**
** Rage 128 based : Not Supported
** Radeon 7xxx based : Not Supported
** Radeon 8xxx based : Supported
*/

http://www.ati.com/developer/sdk/RadeonSDK/Html/Info/Extensions/glATI.h

Die Treiber unterstützen jedenfalls schon HPs Occlusion Extension,

Humus: Cool! This driver supports the HP_occlusion_test OpenGL extension
http://www.rage3d.com/board/showthread.php?s=&threadid=33620181

möglicherweise gibt es noch rechtliche Schwierigkeiten(IP) die verhindern, dass diese Extension im ATI Treiber aktiviert wird.

Name

NV_occlusion_query

IP Status

NVIDIA Proprietary.

http://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_occlusion_query.txt

[Demirug]

@RadioactiveMan:

Danke,

komme eher von der DX Seite deshalb schaue im mir die OpenGL Header nur sehr unregelmäsig an.

Sieht dann ja so aus als ob schon der R200 das kann und bei DX gibts ja keine rechtlichen Problem.

HP_occlusion_test ist eher unbrauchbar da man damit die Pipe blockiert.