Hallo,

ich bastel gerade an einer Fluid Partikel Simulation basierend auf PhysX und habe probleme mit dem Rendering.
Sobald ich um die 65k Spheres Rendere welches die Fluid Partikel darstellen soll bricht die Framerate ein. GTX580M 2GB, 16 GB DDR3, Core i7 Extreme Edition.

Habe es auch mal simpel ohne PhysX ausprobiert, einfach mit Freeglut 64x64x64 Spheres Rendern lassen mit folgenden konstrukt:



Was kann man denn hier tun, um wirklich mehr als 65k Partikel zu Rendern? Oder packt die Karte das einfach nicht, kann ich mir ja fast nicht vorstellen.

Hab da mal eine liste angefertigt für sachen die mir einfallen, ich aber nichts davon ausprobiert habe.
Wollte lieber mal fragen, nacher mach ich wieder unnötigen mist rein, der eh nix bringt oder es noch schlimmer macht.

- glPush/PopMatrix ersetzten durch eigene Matrix routinen (GL3 Kompatibel)
Würde das viel Performance bringen?

- glutSolidSphere() durch was eigenes ersetzten?

- VBO anstatt Displayliste?
Ob ich jetzt nen VBO nehme, oder ne Displayliste, macht das hier an der Stelle einen großen Unterschied?

- Idee die Partikelpositionen zur Laufzeit in eine Texture zu schreiben und mit GLSL die eigentlichen Partikel rendern
Das klingt für mich nach einem sinnvollen aber aufwendigen weg, bin ich mir hier auch nicht sicher ob das soviel bringen könnte.
Weil ich ja für jedes Frame, oder bzw in einem bestimmten Zeitinterval die Partikelpositionen in eine Texture schreiben müsste.
Vermutlich wäre hier PBO und FBO der richtige ansatz? PBO habe ich schonmal benutzt, FBO allerdings nicht.

- Eigenlich hätte ich ja gerne richtig aussehendes wasser, siehe: http://www.geeks3d.com/20100809/siggraph-2010-screen-space-fluid-rendering-for-games/
Wie ich schon oben geschrieben habe, von FBO habe ich noch keine Ahnung, und wie das später alles dann zusammenfügen kann ebenso wenig
Klingt für mich ähnlich wie das Deffered Rendering...

- Point Sprites? Anstatt Spheres??

- Occlusion Culling um nicht sichtbare Spheres nicht zeichnen zu müssen?
Also z.b. die Spheres die in der Mitte vom Wasser sind z.b.

Gruß,
Final

Das beste wäre wohl, wenn man Instancing und eine Textur oder ein Texture Buffer Object benutzt um die Positionen via Shader zu verändern.

Ansonsten gibt es noch ein paar kleine Sachen die man schnell mal probieren kann:
Man könnte das glPush- und glPopMatrix aus der Schleife entfernen (das verbraucht auch einiges an Zeit) und vllt gegen ein glLoadMatrix ersetzen.

65k mal glCallList dürfte auch einiges an geschwindigkeit fressen. Das ist das selbe bei VBOs. Wenn die zu wenig Vertices haben lohnt sich das nicht wirklich. Möglicherweise wäre es sogar schneller die ganzen Kugeln in einen großen glBegin...glEnd Block zu zeichnen. Kommt aber wohl auf den Detailgrad an.

Billboards statt Kugeln dürften auch einiges bringen. Damit man die später auch ordentlich beleuchten kann, packt man da einfach eine Normalmap drauf. Wenn man der einen Alphakanal gibt, kann man auch die Grenzen von den Partikeln verschwimmen lassen, wodurch man einen "flüssigen" Übergang erhält und keinen Haufen Kugeln. Das Problem dabei ist bloß die Sortierung nach der Tiefe. Wenn man das nicht machen will, kann man auch harte Übergänge nehmen (Alpha-Test) und das resultierende Bild blurren.

Occlusion Culling macht denke ich nur Sinn, wenn die zu zeichnende Geometrie aufwändiger ist als ihr Bounding Volume, was bei einer Kugeln nicht wirklich gegeben ist. Ansonsten wüsste ich nicht wie man in Hardware testen will ob eine Kugel sichbar ist ohne sie nicht selbst gleich zu zeichnen.

Kugeln kann man im Shader sehr einfach und effizient per Raytracing berechnen - alles was du benötigst sind parallel zur Kamera ausgerichtete Quads. Dabei kann man Z-Test, Alphakanal, Normale komplett im Shader ohne Textur durchführen. Damit erreicht man selbst auf integrierter Grafik und >60k Kugeln interaktive Frameraten.

Siehe: http://web4.cs.ucl.ac.uk/staff/t.weyric ... /pbg06.pdf

_________________
http://audorra.sourceforge.net//http://andorra.sourceforge.net

Hallo,

NVIDIA hat in einer CUDA Demo einen Shader benutzt um Punkte als Kugeln zu rendern (http://developer.download.nvidia.com/co ... ation.html die Particles Demo). Vielleicht einfach mal reinschaun aber mit der Methode sind >300K Kugeln kein Problem.

Der Shader:


Die Rendermethode:

Dein Bottleneck dürften die DrawCalls sein. Mit Instancing dürftest du daher schon recht weit kommen. Einfach deine Partikel-Positionen in einem TBO speichern und im Vertexshader darauf zugreifen. In der Shadersammlung gibts sogar ein Beispiel.

_________________
Yeah!

Ich habe ein interessantes Instancing Paper gefunden und direkt umgesetzt.
Das paper habe ich von hier: http://www.slideshare.net/acbess/instancing-presentation

Aber es funktioniert nicht, er zeichnet irgendwie nur ein bruchteil davon was er zeichnen soll.

Habe mal den kompletten source (VC++ 2010) dazu gepackt, bitte schaut euch das teil mal an.
Das meiste in main.cpp, und VBO, GLSL kram ist seperate files umgeteilt.

Mit 'R' könnt ihr zwischen Instancing und nicht Instancing Rendern wechseln.
Nicht instancing funktioniert einwandfrei und ist bei 32k Spheres sogar wesentlich flotter als mit...

Habs so umgesetzt wie in dem Paper gestanden ist, aber dennoch tut es nicht wirklich.

Siehe Bilder für Vergleiche oder schaut euch einfach die demo an. SM 4.0 ist voraussetzung.

Hier der source: http://xenorate.com/tl_files/somekram/Instancing.zip

Danke fürs Helfen bisher,
Final

Achja, das Instancing Beispiel in der Shadersammlung basiert ja auch auf dem Instancing was hier verwendet wird,
nur das halt die Positionen in ner Texture gespeichert werden und nicht einfach direkt im Speicher.

Wenn das mit dem Instancing klappt, dann werd ich das mitem TBO´s noch zusätzlich einbauen um herauszufinden, was am schnellsten ist,
weil ich am ende ja in PhysX die Positionsdaten pro frame eh irgendwo hinschreiben muss, ob jetzt ein TBO oder direkt im speicher ist eigentlich egal.

Was meinst du mir direkt im Speicher? Ein TBO ist doch einfach nur ein Array auf das du per Index zugreifen kannst? Haben die mittlerweile noch was direkteres erfunden? (Edit: Oder meinst du Uniforms?)

_________________
Yeah!

Jop, über Uniform Buffer das ebenfalls ab OGL 3.1 verfügbar ist.
Aber um ehrlich zu sein, weiss ich zu wenig darüber um da genau was zu sagen.

Das Paper hat sich relativ einfach und verständlich gelesen, daher habe ich es nicht wirklich hinterfragt.
Das werde ich wohl jetzt nachholen.... da es ja nicht läuft

Und dann werd ich das mit dem TBO und dem texelFetchBuffer probieren.

k ich habe wohl eine einfache Antwort auf mein Problem.

Max Uniform Buffer Größe ist bei meiner GTX 580M - 65536 Bytes.

Brauche aber für 262144 Spheres exakt 4194304 bytes, stell ich die Anzahl der Spheres runter so das ich im bereich der 65kb bleibe...
...geht das instancing einwandfrei.

Das reicht genau für 4096 Spheres (Wegen alignment problem, kann man nicht vec3 nehmen), ist also zuwenig.

Ich werd das nun mit den TBO´s umsetzten. Das unterstützt 128MB und mehr speicher =)

Gruß,
Final

Hallo,

ich nehme mal an, dass die 65k Spheres nicht zur selben Zeit sichtbar sind. Front-To-Back sorting und Occlusion Culling (mit einfacher Bounding-Box) dürften auch hilfreich sein.

Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Yay, habs hingekriegt mit den TBO´s. Funktioniert wunderbar.

Nachdem ich meinen PPL shader durch einen normalen GL Directional Light getauscht habe ist auch die TBO methode immer schneller =)

Aber am meisten bringt es, wenn mein VBO nicht so viele dreiecke hat.

Daher eine Frage, wie kann man eine halbweg gutaussehende Kugel Rendern mit wenigen Dreiecken.
Aktuell mach ich das über eine Erzeugung von einem Octahedron mittels Subdivision.

Hier ein paar infos...

262144 Instanzen mit 288 Dreiecken:
Ohne TBO: max 12 fps
Mit TBO: 25 fps

262144 Instanzen mit 72 Dreiecken:
Ohne TBO: max 12 fps
Mit TBO: 80-90 fps

Habe mal den Source + Demo hochgeladen, könnt ihr gerne mal ausprobieren und verbessern =)
Ich bau das auf jedenfall mal in meine PhysX Fluid Simulation ein...

http://xenorate.com/tl_files/somekram/Instancing.zip

Hast du es schon mal mit entfernungsabhängigem Level of Detail probiert? Dabei zeichnet man nähere Objekte mit mehr und weiter entfernte mit weniger Dreiecken. Wenn man die Dreiecksanzahl für jede Detailstufe optimiert, müsste die Gesamtanzahl an Dreiecken runtergehen (ganz weit entfernte Kugeln würden dann nur noch als Punkte gezeichnet werden). Vielleicht lassen sich Kugeln mit irgendeinem Trick auch mit einem Geometry-Shader erzeugen

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Lass dir z.B. mit Blender eine Kugel erzeugen und lade diese als Mesh (Add -> Mesh -> Icosphere)

Level of Detail ist schwierig, weil die Idee von Instancing ja ist das alles gleich ist.

Culling könnte man aber im Geometry-Shader mit Transform-Feedback implementieren. D.h. du jagst deine Partikel-Positionen durch den Geometry-Shader, d.h. deinen TBO als VBO mit GL_POINT interpretieren. Sichtbare Punkte werden dann via Transform-Feedback in einen neuen Buffer (TBO) geschrieben. Der Fragmentshader kann hier abgeschaltet werden. Das eigentliche Rendern passiert dann in einem zweiten Pass ganz normal, nur eben mit dem neuen TBO.

Die Kugeln im Geometryshader zu erzeugen ist weniger sinnvoll, da man hier nur wenige Vertices schreiben darf. Der Tesselierungs-Shader bringt hier wohl schon mehr, da geht wahrscheinlich auch Level-of-Detail. Ist aber Shader-Modell 5.0, habe ich noch nicht benutzt.

_________________
Yeah!