Hallo alle miteinander!

Ich habe da eine Frage zum Thema Culling:

Ich lade eine BSP Map (Ein einfaches Rechteck mit Textur) und möchte
Culling benutzen. Ich kenne zwar die Befehle aber das funktioniert nicht
so richtig. Dann rendert er zwar nur wirklich das was ich sehe, aber wenn
ich in das innere des Rechtecks gehe sehe ich gar nichts mehr. Könnte
mir jemand ein Beispiel Code mit BSP und Culling geben?

Vielen Dank im voraus.

Also BSP ist ein wenig komplexer... www.stefanzerbst.de sollte IMAO ein recht gutes sein. Was Culling angeht, schau mal bei Tut5 vorbei da wirds angeschnitten.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Was ich vergessen habe zu sagen ist, dass ich mit OpenGL und Delphi arbeite Aber trotzdem Danke.

Ich will eine Engine programmieren mit so allem nötigen schnick-schack
dem man(n) sich vorstellen kann (Bump Mapping, Multitexturing, ...).
Ein Spiel was auf dieser Engine basiert programmiere ich parallel.
Das nötige Wissen besitzte ich bereits. Das was im moment im Spiel
funktioniert ist, dass man BSP Levels laden kann, dass man rumfliegen
kann, die Texturen der BSP Struktur werden mit Detail-Texturen überzogen und die Konsole ist grad im Aufbau.

Sollte ich wirklich BSP Trees oder Frust Culling einsetzten? Ich will sowohl Indoor als auch Outdoor Levels mit guter Qualität und guter Performance rendern können.

Danke im voraus.

*schaut nachdenklich* War das eine anspielung auf irgendwas???

Na ja *g* Aber mal zum Thema... ich kann zwar keinen direkten lösungsvorschalg liefern, aber 2 dinge liegen mir auf dem herzen..

1. MultiTexturing: Gut, es ist schön, es ist gut etc... aber, ist es nicht viel besser für die Performance wenn man die Textur schon im Vorhinein mit einem GrafikProgramm zusammenbastelt???

Bei Texturen wo sich die 2te Textur die darüberliegt verändert, ok Aber bei welchen die eh immer gleich bleiben..?

2. BSP-Tree: Ich benutze für mein Spielchen z.Z. Octrees... aber würd mich freuen wenn mir mal wer BSP-Trees erklärt

Au'revoir,
Aya~

1. Worauf soll das eine Anspielung gewesen sein?

2. Das ist eine gute Idee und werde ich direkt mal ausprobieren.
ABER wieso arbeitet Legend Entertaiment bei Unreal 2 mit
4 Texturen die übereinander gelegt werden. Ich kann mir kaum
vorstellen, dass das alles Lightmaps sind...

3. Ich kenne Octrees, habe sie aber noch nicht benutzt... Meine kleine
BSP-Unit kann auch bis jetzt nur alles ohne Lightmaps und sowas
rendern.

1. Na ja... ich meinte das "man(n)"..

2. Ich denke mal, das eine ist normale Textur, Lightmap, Shadowmap und dann manchmal eine 2te Textur die sich während des Spiels ändert

3. Octrees sind total einfach, nur ich würd gern mal wisse wie BSP Trees funktionieren

ne... die sogenanten Detail-Texturen haben dann einen Sinn, wenn du an die primäre Textur so dicht ran gehst, dass sie ganz verschwommen ohne große details wäre (bei Landschaften z.b.) Dafür gibt es dann die Detail-Texturen die sich in relativ geringem Abstand wiederholen, und dadurch auch aus nächster Nähe noch Detailreich sind. Durch das Blending fällt es überhaupt nicht auf, dass du zwei Texturen verwendest und es sieht aus jeder Entfernung gut aus!

-lith

_________________
Selber Denken macht klug!

Naja... Bin ich mal wieder ein bisschen klüger!

Also:
Sollte ich jetzt BSP-Trees oder OCTrees benutzen? Die BSP-Trees
sterben ja nach und nach aus. Also bin ich kurz davor auf OCTrees
umzusteigen. Ich will gute Qualität und gute Performance. Was
sollte ich den nun nutzen?

Bsp Trees sind auf aktueller Hardware viel zu CPU lastig. Sie arbeiten per Polygon, wenn ich mich da richtig erinnere. Sinnvoll sind sie, wenn du z.B. feste Polygone immer von hinten nach vorne zeichnen willst, zwecks blending, aber um damit grössere Welten zu rendern sind sie schlicht unbrauchbar geworden. Octrees, nicht zu fein aufgelöst sind da wesentlich besser. Du kannst schnell sagen, dieser Klotz an 1000 Polys fällt komplett weg. Ein anderer Klotz ist nur zum teil sichtbar, dann rendern wir einfach alle(oder gehen noch ein bischen tiefer in den baum). Das ist bei Grafikkarten mit integrierter Geometrieeinheit(alles was sich T&L schimpft und auch schon einige Profi Karten Jahre vorher, z.B. einige FireGL von 1996 etc.) einfach schneller, als alles mit der CPU fein säuberlich vorher einmal duchzubasteln - die Zeiten der Software renderer und reine Hardware Rasterizer sind vorbei. Alles was auf Vertex Ebene läuft können sie schneller, als die im System verbaute CPU, das sollte man entsprechend nutzen und ihnen immer gleich ganze Häppchen zu fressen geben.
Das ist im übrigen auch der Grund warum Geometrical Mipmaps so viel schneller sind, als andere LOD Algorithmen für 3D Landschaften. Wenn ich zeit und lust schreibe ich mal ein Sample - ein tutorial ist denke ich nicht nötig, das original Skript dazu ist wirklich gut genug.

Hab vor geraumer Zeit dazu selbst mal ein kleines Programm geschrieben, das ein auf Heightmaps basierendes Terrain mit Hilfe von Geomip-maps darstellt.
Geschwindigkeitstechnisch bringts einiges, besonders im Zusammenhang mit Frustum-Culling.
Das Problem ist nur bekanntermaßen der Übergang zwischen zwei MipMap-Stufen.

Als Anhang noch'n Pic vom Programm.Die Farben repräsentieren verschiedene MipMap-Stufen :
[/img]

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