spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"Wümpftlbrümpftl"«

@ Osram
Soll das jetzt heißen das man für jeden Quadtreeleaf einfahc nur ein Model hat?

Das ist definitiv eine Möglichkeit (für nicht bewegte/animierte Teile).

Zitat

Außerdem kommt man um massig Texturswitches wohl auch nich herum.

Nein, damit würdest Du Dir den ganzen Sinn ja wieder kaput machen. Denk dran: Die Geschwindigkeit (fps) wird wesentlich durch die Zahl der Draw-Aufrufe bestimmt. Wenn Du also für alle paar Polys eine andere Textur hast und von daher einen neuen Aufruf brauchst, hast Du nichts gewonnen. Wir machen das so:
Wir haben eine 2kx2k Textur "Land". Da kommen Pferde, einzel stehende Bauernhäuser, vielleicht eine Mühle etc rein.
Eine 2kx2k Textur "Dorf" mit Pub (ist in einer englischen Landschaft immer am wichtigsten ! :lol: ), kleinem Post office, dörflichen Häusern, der Kirche etc.
Eine weitere Textur ist für Innenstädte mit Woolworth (gabs damals auch schon), UBahn station, recht grossen Stadthäusern etc.
Dadurch ist bei nebeneinanderstehenden "logischen" Objekten die Wahrscheinlichkeit gross dass sie die selbe Textur nehmen und man daraus ein "Grafikkarten Objekt" machen kann.

Zitat

Zumal man dann zb einen Baum nicht mehrmals verwenden kann und so mehr Speicher braucht.

Ja, in einen sauren Apfel musst Du beissen:
- Verschmelzen -> viel Speicherverbrauch
- Alle einzeln per Drawxxxx zeichnen -> wenig fps
- Instanzing -> Braucht Graka ab Sm 3.0 oder aber ATI mit - ich glaube - 2.0b.

Zitat

Du meinst nicht wirklich, dass ich von einer großen weiten Welt alle Modelle nur mit den BBs gegens Frustum testen soll?

Es sei denn Du hast die Quadtrees schon implementiert, kann es durchaus Sinn zu machen es erst mal auf die einfache Art zu programmieren und dann per Profiler die wirklichen Daten zu bekommen um zu sehen wo man optimieren muss. In deisem Fall ist ja alles was Du schreibst (BB eines Objektes bestimmen, BB gegen Frustum testen) auch später nötog, falls Du auf Quadtrees umsteigen solltest.

Zitat

Was macht dann deiner Meinung nach wirklich was aus?

Zahl der Draw Aufrufe
Zahl dr Switches
Grosser VRAM Verbrauch
Schlechte Ausnutzung des Caches der Graka
Zu hoher Overdraw
Andere Module (AI, Physik etc)

malignate88, beeindruckend, aber ich denke das wird sich stark ändern wenn der Horizont im Bild ist - und das ist ja sowohl bei Flusis als auch bei Bodengebundenen Spielen normal.

Bei Deiner Perspektive, wenn die Tiger bis zum Horizont reichen, so kannst Du wirklich einen extrem hohen Prozentsatz wegcullen.

@Phili: Gezählt habe ich sie wirklich nicht, aber du willst wohl nicht behaupten können, dass 30 Tiger 120 FPS ergeben und 40 Tiger 30 FPS?

Ich behaupte jetzt mal, dass du die Geschwindigkeitsvorteile von geeigneten Culling-Strategien mangels Erfahrung gar nicht beurteilen kannst, bitte belehre mich eines besseren, indem du ein paar Werte aus der Praxis bringst. Das theoretisch auszurechnen bringt nämlich gar nix.

@Osram: Faktor 1000 daher, weil ich mit den ersten vier Tests ja 3/4 eines Quadtree cullen kann. Das sind bei 4000 Objekte also 3000 Objekte, von denen ich sicher sein kann, dass ich sie nicht rendern muss.

Der Vorteil von Quadtree geht bei Spielen mit FPS-Kamera wirklich ein bisschen flöten, wichtig ist er aber dennoch.

Ich trotzdem ne Frage wie funktioniert das mit den Quatrees. Habt ihr da die Modelldateine ladet sie und render dann nur die die in dem Quatree sind.

@Phili: In den neuen Screens zähle ich im ersten Bild 37 und im zweiten 40. Vielleicht zeigt dein Browser noch die alten an.

@Fred: Ich render die, die im Frustum sind. Ein Quadtree ist ein Algorithmus um schneller entscheiden zu können, welche innerhalb sind, und welche ausserhalb.

40.000, aber das ist in meinem Fall schon ein sehr realistischer Test, weil die Map ziemlich groß ist. Das ist ja das schöne an einem Quadtree. Die Geschwindigkeit des Cullen ist nahezu unabhängig von der Größe der Karte.
NAHEZU!