Klar, die Anzahl der Vertices gibst du über glDrawArrays an. Genaugenommen gibst du da sogar einen Bereich aus diesem VBO an der gerendert wird. Jedenfalls kann der VBO ruhig größer sein.

Bei mir sieht das so aus. Die Buffergröße wird automatisch beim Daten-Upload angepasst. Für deinen Fall ist es ggf. sinnvoll die obere Grenze für die Größe wegzulassen damit kein neuer Buffer angelegt wird falls du mal kurz keine Partikel hast:



Edit: Für deinen Fall ist es vermutlich besser glMapBuffer zu benutzen, damit du die Daten nicht zweimal kopieren musst:

_________________
Yeah!

cool danke, das werd ich gleich mal versuchen.

Kurze andere Frage:
Wäre es irgendwie möglich meine PointSprites mittels defferredShading zu beleuchten?

Ja, natürlich. Allerdings können diese dann nicht transparent sein. Es wird jeweils nur das Pointsprite beleuchtet was vorne ist. Du speicherst ja im Geometrybuffer die Position...da kann eben nur eine sein.

_________________
Yeah!

nun es geht ja um wasserfontainen... und die sind ja transparent...

im Tutorial steht ja was von Interferred Shading, doch ich finde dazu im iNet so gut wie nischt...

Wird dran liegen das es Inferred Lighting heißt. Zudem ist das Paper im Wiki verlinkt, allerdings ist deren Server wohl gerade down. So oder so hilft dir das nicht weiter, da "Inferred Lighting" nur einige wenige Transparenzebenen managen kann. Die machen das nämlich so das sie einen 2x2 Pixelbereich nehmen und jeden der vier Pixel für eine Transparenzebene benutzen, also bei 2x2 entsprechend bis zu 4 Ebenen. Geht natürlich auch mit 3x3 oder 4x4 aber dann leidet die Bildqualität natürlich um so mehr. Für Partikel ist das absolut ungeeignet.

_________________
Yeah!

mhh hab ich mir schon gedacht. Mhh andere Alternativen? Hab auch schon überlegt direkt beim Partikel Rendern zu pürfen wie weit ein Partikel von einer Lichtquelle entfernt ist und dann entsprechend beleuchten.. Allerdings bin ich dann wieder bei der Anzahl der Lichtquellen begrenzt oder muss mehrfach rendern.. Ich glaub das wird auch mist...

Hm, wenn du viele Lichtquellen hast haben diese bestimmt eine geringe Reichweite, oder? Um wie viele Lichtquellen und wie viele Partikel geht es?

Du könntest dir etwa eine Baumstruktur für die Lichtquellen in eine Textur kodieren. Alternativ ginge auch eine Grid-Struktur, ist ggf. einfacher zu implementieren, braucht aber mehr Speicher:
Wenn etwa deine Welt relativ breit und lang ist aber nicht so hoch könnte du eine einfaches 2D-Grid nehmen. Z.B. für Zellen von 10x10 Einheiten kodierst du die jeweils 4 nächsten Lichtquellen in eine 2D-Textur (z.B. den Lichtquellen-Index in eine RGBA-Textur kodieren...sofern du nicht mehr als 256 Lichtquellen hast). Für jeden Partikel berechnest du dann nur das Licht für diese 4 Lichtquellen....die restlichen ignorierst du einfach. Natürlich musst du mit der Zellengröße und der Anzahl der Lichtquellen pro Zelle etwas experimentieren. Die Grid-Textur darf nicht zu groß werden, sonst wird das zu langsam. Und wenn sich die Lichtquellen bewegen wird's natürlich erst recht schwer...

_________________
Yeah!

also es können schon 600 lichter und ca 300 fontänen mit je rund 1000 Partikeln vorkommen....
Ist das so machbaR?

Alleine schon die 300000 Partikel...auch ohne Licht.....sind schon viel Arbeit für die CPU. Hier solltest du ein GPU-Partikelsystem verwenden. Schau dir dazu http://wiki.delphigl.com/index.php/GLSL_Partikel_2 an.

Jede Lichtquelle für jeden Partikel zu berücksichtigen ist mit normaler Hardware wohl eher nicht in Echtzeit möglich. Für die Lichtquellen brauchst du eine räumliche Sortierung, damit du schnell die wichtigen Lichtquellen für jeden Partikel findest. Siehe meinen letzten Beitrag. Bei weiter entfernten Lichtquellen könnte es Sinn machen diese zusammenzufassen. Also irgendwie eine Quadtree-Struktur bauen und ab einer gewissen Entfernung gehst du nur noch in eine bestimmte Tiefe. Ggf. hilfreich um den Quadtree in eine Textur oder ein Uniform-Array zu packen ist dieses Tutorial.

Hier habe ich bei 262144 Partikeln jeweils 50 Texturzugriffe gemacht. Dies lief auf meiner auf meiner Nvidia GeForce 9800GT mit 39fps. Beachte das die Anwendung NICHTS anderes gemacht hat als die Partikel zu simulieren. Ich denke in deinem Fall kannst du ca. 50 Lichtquellen berücksichtigen. Du hast einen Vorteil weil die Datenmenge geringer (der GPU-Cache wird helfen) ist, dafür brauchst du aber die Baumstruktur um überhaupt zu wissen auf was du zugreifen musst.

_________________
Yeah!

ich finde diesen Ansatz ganz interessant, habs aber noch nicht ganz verstanden: http://download.unity3d.com/blogs/nf/fi ... ry73_1.pdf

bzgl GPU Partikel, meine aktuelle Engine macht ca 1000 Fontainen mit insg. 6mio Partikeln mit 30fps. Müsste reichen.
Bzw ist hier nicht die Berechnung die Bremse sondern das zeichnen der PointSprites. Hab schon VBOs drinne

Sobald du aufwendigere Berechnungen bzw. Texturzugriffe machst geht das schnell in den Keller.


Richtig, vermutlich sind deine Partikel alle nur 1x1 Pixel groß. Größere Partikel mit Alphablending ziehen wesentlich mehr Leistung. Logisch, weil z.B. ein 20x20 Partikel natürlich 400 mal soviel Schreibzugriffe auf den Framebuffer braucht und auch der Fragmentshader 400mal öfter ausgeführt wird. Aber man braucht auch nicht so viele Partikel, mit ein paar hundert Partikel kriegst du dann schon tolle Sachen hin.

_________________
Yeah!

vielleicht ist auc mein ansatz falsch..
wie wird denn so ein wasserstrahl erzeugt: http://www.youtube.com/watch?v=vnKX7CaY ... re=related
Wird da irgendwie ein Mesh erzeugt?


EDIT: Lässt sich das vielleicht irgendie mit Nurbs machen?

o.O....du willst also Fluidsimulation machen. Dafür ist ein normales Partikelsystem weniger geeignet. Flüssigkeiten lassen sich nämlich nicht komprimieren, wenn du das korrekt simulierst ist das schon die halbe Miete.

Bei Partikeln müsstest du quasi die für jeden Partikel den Abstand zu den Nachbarpartikeln berechnen und wenn diese zu nahe sind auf beide Partikel eine Kraft ausüben um sie zu trennen. Das primäre Problem ist dabei das du nicht einfach alle anderen Partikel betrachten kannst, der Aufwand wäre quadratisch. Eine Baumstruktur funktioniert auch nicht so leicht, weil sich die Partikel ja bewegen und der Baum ständig neu aufgebaut werden müsste.

Der aktuelle Standartansatz ist ein 3D-Grid von Zellen zu simulieren. Das wird glaube ich auch in dem Video gemacht. Jede Zelle kann eben eine bestimmte Menge Flüssigkeit enthalten. Für jede Zelle stellst du sicher das immer genauso viel Material hinein fließt wie auch hinaus fließt, also Summe der Ströme = 0. Um das hin zu bekommen muss ein Gleichungssystem gelöst werden, dieses Gleichungssystem hat so viele Variablen wie es Zellen gibt. Ich hoffe du hast in der Schule schon mal Gleichungssysteme lösen müssen. Also bei 128x128x32 Zellen hast du mal eben 524288 Variablen!! Es kommt hier also sehr auf den Algorithmus an der dieses System löst. Trotzdem, das ist der Grund warum man in solchen Realtime-Demos immer nur ein solch kleines Wasserbecken sieht und nie einen Ozean oder so.
Wenn man den Inhalt jeder Zelle kennt wird ein weiterer Algorithmus angewendet der daraus eine Oberfläche (Mesh) generiert. Hier könnte man z.B. MarchingCubes nehmen.

_________________
Yeah!