Hi,

ich bastle mal wieder nach langer pause an meiner Engine welche jetzt auch große fortschritte macht

hab aber mal ein paar fragen:

1.) Was leistet eine Engine heutzutage..??
Ich habe eine nVidia GeForce FX 5900XT.. also nix wirklich tolles...
Bei 90.000 Triangles mit 2-Texturen (Multitexturing), Shading (glSlang) (inkl 2 lichtern, ohne schatten) schafft meine z.Z. ~37FPS bei einer Auflösung von 1024x768x16 in Fullscreen. (ausserdem noch ein paar animierte Objekte)

Ist das gut oder schlecht??? (Ok ich weiß sowas is schwer zu sagen)

2.) Kann es sein das DisplayLists mittlerweile langsamer als VBOs sind??? Ich habe meine Statischen objekte testweise mal als DisplayList und nicht als VBO dargestellt und die FPS ist niedriger geworden...

3.) Woran kann es liegen das meine FPS um ca. 10 fps runtergeht wenn ich meine Objekte nach der Textur sortiere so dass ich nicht ständig die textur binden muß.. also ich zeichne die objekte einfach sortiert nach ihrer Textur..

Komischerweise ist die FPS um 10 runtergegangen.. (ich hab das ganze nur am anfang einmal sortiert.. also für das sortieren geht keine FPS drauf..)

4.) ich hab recht oft glEnable(GL_TEXTURE_2D) und glDisable(GL_TEXTURE_2D) drin... sollte ich versuchen das wegzubekommen oder macht das nichts aus???

Au'revoir,
Aya~

Ich baue auch von Zeit zu Zeit an meiner Engine und musste feststellen das das wichtigste erstmal das Levelfomat ist so sollte das Level schon im vorhinein optimal sortiert sein.
Also erst Nach Boxen durch ein Octree und dann diese anschliessend nach Texturen Sortieren.
Praktisch ist auch Catmull-Rom(abart von Berzier) einzubauen um PCs mit unterschiedlicher power entgegen zu kommen.
Eine Praktische sache ist noch Objekte mit sehr hoher Polygonzahl vorkommen vom Octree abzukapseln und einzeln zu prüfen(bei heutigen engines ist meist die CPU nicht der Flaschenhals).
Lightmaps so oft wie möglich einsetzten und ne überprüfung ob Lichtquellen überhaupt sichtbar sind also ein radius festlegen wenn der nicht drin ist Licht ignorieren .
Praktisch denke ich ist momentan auch kein GLSLang zu nutzten da wie ich öffter sehe es immer noch langsamer ist als der Vorgänger PS,VS.
LOD system ist auch hilfreich auf einzelne dynamische objekte oder höher polygonierte feste objekte.
Wenn eine Physik vorhanden ist versuch deine Komplexen Objekten durch ein vereinfachtes Gitter berechnen zu lassen zwar nicht 100% korrekt aber viel schneller.
Und das meiste sollte am besten schon im Fileformat drin sein da das Ladezeiten spart was auch sehr lästig sein kann.
Diese Funktionen hab ich für mein 3D Fileformat XDL eingeplant oder teilweise schon realisiert.
MfG TAK2k4

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hi,

ok.. danke erstmal

das meiste von den dingen die du aufgezählt hast hab ich eigentlich schon eingebaut... Octree, TextureSorting etc ist alles schon integriert und läuft einwandfrei

Wobei ich jetzt herausbekommen hab das bei mir auch glSlang das hauptproblem ist... sobald ich einen Shader drauflege auf die objekte.. und sei er noch so klein (selbst nur durchschleifen ohne iegenen berechnungen) lässt die FPS rapide absacken...

Beispiel:
Eine Scene mit 750.000 Triangles, 2x Multitexturing schafft die Engine bei mir mit ~30 FPS...
Sobald ich einen glSlang Shader dazupacke sackt es ab auf ganze 6 FPS...

Ist das normal??? oder mach ich irgendwas falsch dabei???

Au'revoir,
Aya~

Wenn du indoor Level hast, kannst du noch Portale einbauen. (siehe Wiki)

_________________
Blog: kevin-fleischer.de und fbaingermany.com

...ich hätte da eine ähnliche Frage: Man liest oft in Handbüchern oder in Readmes, dass ein Spiel für AMD64-CPUs oder für Hyperthreading optimiert worden ist. Wie optimiert man denn ein Spiel für einen Prozessor, wofür es noch gar keine Unterstützung gibt? Und wie kann man überhaupt eine Engine für einen bestimmten Prozessortyp optimieren, und für andere Typen nicht?

Mfg, Gran

_________________
Der Bump Mapping User ist nur zu faul, selbst eine Wand mit Tesselation zu erstellen

Hyperthreading: Der Prozessor kann mehrere Aufgaben (Threads) gleichzeitig abarbeiten. Damit soll man angeblich ein Spiel spielen und gleichzeitig fast ohne Geschwindigkeit zu verlieren zB eine DVD rippen können. Aber das glaub ich ist ned ganz so ernstzumeinen. Aber zu Threads haben wir ein gutes Tutorial:
http://www.delphigl.com/script/do_show.php?name=multithread&action=2

64 Bit CPUs: Rechnen genauer und schneller, da sie auch prinzipiell einfach mehr auf Speed getrimmt wurden (zB viel feinere Fertigung). Normalerweise compiliert dein Compiler automatisch (?) eine 64Bit-Exe, die aber im Allgemeinen größer sind, als 32 Bit-Exes.

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

na du kannst zum Beispiel deinen Code so aufbauen, daß er hochgradig paralell ablaufen kann und nimmst mehrere threads und das eignet sich dann für eine CPU mit multithreading.
Oder wie im Fall vom P4 hat man seinen code so gestrickt, dass möglichst wenige Sprünge vorkommen, da der P4 eine sehr lange Pipe hat, ich glaub 32 oder 40 (also Befehle im Vorraus aus dem Speicher holt). Wenn aber viele Sprünge drin sind, dann muß er das gelesene wieder wegschmeißen und verliert seinen Geschwindigkeitsvorteil. Im übrigen wird dadurch z.b.: der Athlon nicht langsamer, daß der Code für P4 optimiert wurde, der P4 nur schneller.
Vereinfacht ausgedrückt schreibst Du nicht

sondern

(man schreibt nicht seine Quellen um, aber der Compiler übersetzt es anders)
CPUs mit Hyperthreading haben alles doppelt (cache, Register, stack) ausser der ALU und dem Steuerwerk und gaukeln dem BS zwei volle Prozessoren vor, daher sind diese Systeme de facto multiprozessing systeme und aus sicht des Betriebssystems können hier tatsächlich zwei prozesse gleichzeitig laufen

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Das beispiel mit dem Print A ist so net korrekt.
Die Prozessoren betreiben eine Sprungvorhersage und bei Zählischleifen wird immer angenommen, das gesprungen wird. Das heißt, bei einer 20er For schleife liegt er nur einmal (ganz am schluss) daneben. Das was du schreibst würde ja den Code unglaublich aufblähen und hätte performance nachteile, da riesige mengen Code zb gecached werden müssten. Und obwohl die Befehle alle dasselbe tun hätten sie verschiedene Addressen im Speicher und würden somit mehrfach gecached werden...

Das mit den virtuellen DualProcessoren stimmt aber soweit. Und wer schonmal mit nem Dualsystem gearbeitet hat kann bestätigen, dass der Workflow um etliches besser ist. Wir dürfen uns also freuen...

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Hi,


aber auch nur bedingt.. ich hab daheim nen Dual rechner und hier in der uni nen P4-HT... und ich würde den dual nich gegen denhier eintauschen wollen... HT is zwar schon 1000x besser als SingleCPU aber auch nochnet so gut wie dual

Jedesmal wenn man Musik hört und was aufwendigeres startet springt die musik kurz.. (ok auf sinlge CPU würde sie komplett ausgehen.. aber.. egal

Au'revoir,
Aya~

Hi nochmal

Eine frage noch bezüglich Octree... bzw... soetwas in der art..

Nehmen wir an ich hab eine ewig lange häuserreihe... wenn ich nun davor stehe sind eventuell nur 3 Häuser sichtbar = dank Octree werden auch nur diese 3 gezeichnet...

wenn ich mich aber nun so hinstelle das ich die komplette reihe von der seite sehe.. also so das ich auf das erste haus von der seite draufgucke und alle anderen dahinter verschwinden.. dann sind sie ja dennoch im Frustum und werden dementsprechend auch gezeichnet..

gibt es da ne tolle methode das zu verhindern???

Also kann man irgendwie rausfinden ob Objekte die weiter weg sind durch objekte die direkt vor der kamera sind verdeckt werden???
Ich dachte da bisher an so sachen wie alles direkt vor der Kamera zeichnen und dann per OcclusinQuery die hinteren sachen (bzw die hinteren Octree-Leafs) zu überprüfen ob was von gezeichnet wird... aber irgendwie erscheint mir das nich so als das wahre

Hat da jemand ne idee???

Au'revoir,
Aya~

PS: Nochwas.. nehmen wir an ich habe ein level das so aussieht: (_ = leere fläche, # = Wand)

#############
#______#_______#
#__ A __#___ B __#
#______#_______#
#______#_______#
#______#_______#
#______#_______#
#______#_______#
#______#_______#
#______#_______#
#______________#
#_____ C _______#
#______________#
#############

So... wenn ich an Position A stehe kann ich alles bei B nicht sehen und umgekehrt.. kann aber an stelle C einfach von A nach B gehen...
Wenn ich jetzt auf A stehe und richtung B gucke würde ja alles von B gezeichnet werden weil es ja im frustum ist.. aber durch die Wand nicht sichtbar... wie verhindere ich das am besten???

Occlusion Queries sind die einzige Möglichkeit echte Sichtbarkeitsprüfungen durchzuführen. Und warum sollen die nicht das "Wahre" sein? Mit OQs kann man reichlich tolle Sachen machen, da man ja die Anzahl der sichtbaren Pixel geliefert bekommt. So kann man nicht nur festsellen ob Geometrie sichtbar ist, sondern auch wie viel davon bzw. wie groß und kann dann noch gleich die OQs für LOD benutzen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Die Occlusion Query kostet natürlich auch etwas Zeit. Daher ist es günstiger, die Queries nur durchzuführen, wenn man weiß, dass das Objekt die letzten 50 Frames, oder eine ähnliche Zeit, nicht sichtbar war. Dann zeichnet man zwar immer ein wenig zu viel, muß aber viel weniger Queries machen und im Endeffekt ist es schneller weil sich die Kameraposition meistens nicht sprunghaft ändert.
Mit den Occlusion Queries ist das Sichtbarkeitsproblem allgemein gelöst. Das einzige was man benötigt, ist eine Datenstruktur um grob von vorne nach hinten zu sortieren.

Hi,

ok... dann hab ich nurnoch eine letzt frage zu den OQs..
Wann werden die gezeichneten pixel gezählt...?? Also wenn ich erst das objekt weiter weg und dann das vordere (welches das weiter weg verdeckt) zeichne... zählt der OQ direkt nach dem zeichenn von dem obj weiter weg = es sind dann alle pixel zu sehen.. oder erst wenn auch das vordere gezeichnet ist???

Ich nehme mal stark an er zeichnet sofort = ich müßte die Objekte noch nach entfernung sortieren... gibt es da nen tollen algo für?? Weil ich glaube die sortierverfahren die ich so kenn sind nich unbedingt sehr optimiert

Au'revoir,
Aya~

Also wenn du wirklich Occlusion Culling verwenden willst kannst gleich mal deine Zielplatform hochschrauben, denn das ist dermaßen langsam da gibs varianten die sind bei weitem schneller und effektiver.
1)Raycastintersection:du lässt 8 Raycast(wenn ein punkt testest auch nur 1) auf die Ecken des Octree schiessen wenn was dazwischen ist weisst du es.
2)mach in dein Levelformat ein Vis Tree rein was speichert welche Octreesegmente sichtbar sind von dem aktuellen punkt
3)mach eine distanvariable rein wenn du Fog für überblenden in den Horizont nutzt setzt dein dis ein bischen größer als diesen wert und überprüfe ob das centrum vom Octreesegment drin ist
4)nutzte Primitive collisionserkennung für das auslselektieren
das sind erstmal ein paar varianten aber gibt bestimmt noch einige mehr Ansätzte.
Wegen Occlusion Culling ich hab mal gelesen das es probleme in der unterstützung und in der geschwindigkeit gibt und es ungenau wird wenn man AA nutzt. In 1-2 test hat sich das bestätigt hatte vor dieses für meine Lichtquellen zu nutzten naja danach hab ich dann Raycast verwendet.
MfG TAK2k4

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Zu nv_occlusion_query gibt's ein Tutorial. Die ARB Queries funktionieren genauso, nur das die Funktionen leicht andere Namen haben.


Ja, das Zielsystem sollte mindestens GF3 oder Radeon200 sein.

Die Queries sind nicht langsam. Das Problem ist, dass man nicht zu oft auf das Ergebnis einer Query warten darf, weil dadurch natürlich Zeit verloren geht und die Grafikkarte und die CPU dann nicht mehr parallel arbeiten. Außerdem sollte man es auch hierachisch machen, also nicht für jedes Objekt einzeln. Deshalb reicht es völlig aus nicht bei jedem Frame ein Query durchzuführen, wie oben beschrieben. Besonders sinnvoll ist es bei mehreren Renderpass. Der erste Pass ist normalerweise einfach und da kann man dann zusätzlich nochmal eine Query starten und dann viel später beim Rendering der nachfolgenden Pass, wenn die Query sogut wie sicher fertig ist, abfragen. Oder man balanciert das aus,denn man kann auch prüfen, ob das Ergebnis der Query bereits fertig ist und eventuell gar nicht mehr drauf warten.
Falls eine Box unsichtbar ist, kann man auch gleich den Teil des Baumes, der vom Betrachter aus gesehen hinter der Box liegt, als unsichtbar markieren, so dass man dort auch keinen Test mehr benötigt.



Funktioniert im Allgemeinen nicht, weil es sein kann, dass alle Eckpunkte verdeckt sind, aber trotzdem der Rest der Box sichtbar ist.


Lange Vorberechnungszeit. Mal abgesehen davon, dass man auf jeden Fall zu viele Objekte zeichnet, wenn so ein Eintrag immer pro Segment gilt.


Ist keine Lösung, ab einer Entfernung auszublenden und funktioniert auch nur, wenn die Geometrie überal gleich verteilt ist wie z.B. bei Landschaft. Verhindert keinen Overdraw.


Das funktioniert wie oben gezeigt nicht. Ein Objekt ist nur dann unsichtbar, wenn es keinen Strahl von dem Betrachter zu irgendeinem Punkt gibt. Wo eine Box/Kugel/... einer bestimmten Größe nicht mehr durchpaßt, kann man immer einen Strahl konstruieren, der noch durchgeht.



Ja aber mit den Queries ist man auf die wenigsten Vorraussetzungen angewiesen. Man braucht keine Portale, oder Anti Portale, sondern nur eine hierachische Struktur, in der man sortieren kann.



Occtrees kann man genauso wie BSP Trees sortiert ausgeben, indem man jeweils die (8)Unterknoten entsprechend dem Abstand vom Betrachter sortiert.