Hab gerade mal nachgemessen : Bei 5000001 Partikeln braucht die 2 Random Variante
173 ms
und die mit einem 63 ms (auf einem Athlon XP 28000+, mit Winamp nebenherlaufen). OK, dass ist eine sehr große Partikelanzahl, aber vom verhältnisher dürfte klar sein, dass 1*Random um einiges schneller ist.
Komm aber so ziemlich das gleiche dabei raus, da es random ist, ists egal, weil er eh keine bestimmte zahl will.
Vergleich mal die beiden Zeilen:
1. Random(10)
und
2. Random(5)+Random(5)
Beim 1. kommen alle gleich häufig vor.
Beim 2. sind für jedes Random die Wahrscheinlichkeiten auf alle Zahlen von 0 bis 4 gleich aufgeteilt. Aber wenn man sie Addiert, dann gibt es
1 Möglichkeiten für eine 0
2 Möglichkeiten für eine 1
3 Möglichkeiten für eine 2
4 Möglichkeiten für eine 3
5 Möglichkeiten für eine 4
4 Möglichkeiten für eine 5
3 Möglichkeiten für eine 6
2 Möglichkeiten für eine 7
1 Möglichkeiten für eine 8
0 Möglichkeiten für eine 9
(5^2 = 25 = 1+2+3+4+5+4+3+2+1 hab mich also nicht verzählt)
und somit sind nicht alle Zahlen gleich wahrscheinlich.
Also das mit dem random ist nicht nur ein drastischer Unterschied, er beeinflusst auch maßgeblich das Aussehen des Effekts.
z.B. die random funktion sorgt für Richtungsänderungen:
Wenn man den Fall mit Random(10) ansieht, dann sind alle Möglichkeiten gleich wahrscheinlich und demzufolge auch alle möglichen neuen Richtungen für die Partikel, d.h. bei vielen Partikeln wird das Gesamtbild breitgefächert aussehen und die Partikel werden sich auch eventuell in kleinen Kreisen Fortbewegen.
Im Fall von Random(5)+Random(5) sind die mittleren Zahlen (also der Durchschnitt) wesentlich häufiger zu erwarten als die Extrema. Das sorgt dafür, dass sich die meißten Partikel annähernd gleich bewegen und nur leichte Ausfächerung entsteht.
Man kann also durch geschickten Einsatz der Random Funktionen durchaus das Aussehen eines Effektes beeinflussen.
_________________ 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.
Hab mir das Tut dazu mal durchgelesen un ich denke es würde sich für ne PE lohnen.
allerdings könntes da ein prob geben: die anzahl der partikel ändert sich in den meisten fällen mehrmals in der sekunde.
kann ich den reservierten speicher dynamisch anpassen, OHNE dabei nen geschwindigkeitsverlust > 10-20 fps zu bekommen?
_________________ I'm not the signature, I'm just cleaning the floor...
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Also wenn sich die Anzahl der Partikel nicht extrem nach oben verändert würde ich den Speicher für die Höchstzahl der Partikel reservieren den nur soweit füllen wie er gebraucht wird. Der muss ja nicht immer genau passen. Du kannst ja auch durchaus nur die ersten 100 zeichen oder so.
Wenn die Anzahl doch schon ein bisschen schwanken kann würde ich evtl. empfehlen, dass du die VBO größe ein bisschen beruhigst. Also sagen wir mal du gehts zu Anfangs von 1000 Partikeln aus. Benutzt zu erst aber nur 700. Dann hast du noch genügend puffer übrig. Jetzt sollen auf einmal 1100 dargestellt werden. Dann musst du den Speicher vergrößern. (Bzw alten löschen und neu anlegen. Weiß gerade nicht aus dem Kopf ob man den einfach so in der Größe verändern kann.) Und dann in etwa eine Größe von 1300. Und wenn dann diese Zahl überschritten wird, dann würde ich noch mal 30% drauf rechnen oder so. Genau so natürlich dann entsprechend auch wenn du weniger Partikel hast. So musst du nicht ständig den Puffer anpassen. Hast aber sicher gestellt, dass du immer genügen Platz hast und nicht zu viel vergeudest.
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Also das sollte nicht passieren. Wenn du in dem Arbeitsspeicher drüber schreibst, dann geht der ja auch nicht gleich kaputt. Das dürfte sich so äußern, dass der Treiber dir ne Exception vor die Füße wirft. Und zwar eine AccessViolation (Zugriffsverletzung). Es kann dann auch sein, dass du deine OpenGL Initialisation zerschießt. Also nachdem du dann das Programm neu gestartet hast sollte es wieder gehen. Oder halt wenns richtig kaputt ist dann eben halt den Rechner neu starten.
Aber nach Möglichkeit solltest du ziemlich genau darauf achten was du tust. Das gilt im übrigen für ALLE Pointeroperationen. Egal ob Arbeitsspeicher oder Grafikkarte.
dh ungefähr so wie wenn ich über die dimensionen von nem array versuch zu schreiben?
das is mir schon zu oft passiert >-<
edit:
noch ne frage:
wenn ich aber das ganze 30% mehr mach, werden doch dann auch anstatt die gesetzten 1200 partikel 1500 partikel gerendert, wobei die letzten 300 nur verticen im ursprung sin. inwieweit lohnt sich das?
_________________ I'm not the signature, I'm just cleaning the floor...
nur eins:
wie speicher ich farb, textur un modelviewmatrix veränderungen??
ansonsten kann ich vbos vergessen...
warum is ja klar: nur eine textur, keine alphawerte, billboards nur so, wie ich se net kann xD (und rechenaufwendiger) keine unterschiedlichen farben.
edit:
ok, rotationen un transformationen bekomm ich noch so hin, aber farbänderungen und texturen sind absolut unabdinglich!
_________________ I'm not the signature, I'm just cleaning the floor...
OK habs teilweise selbst rausgefunden - ich denke das zauberwort heißt
GL_T2F_C4UB_V3F
sogar das mit den billboards hat geklappt ^^
meine letzten 2 probleme wären denne:
- Texturen ändern
- Partikel um die Z-Achse drehn
da ich mich wahrscheinlich mit ersterem punkt abfinden muss, wärs mir lieb, wenn ihr mir eine formel oder eine funktion o.ä geben könntet, ich schaff solche rotationen nur in 2D =/
_________________ I'm not the signature, I'm just cleaning the floor...
Registriert: Sa Nov 13, 2004 11:00 Beiträge: 229 Wohnort: Steinhude
Texturänderungen könnte man vll. noch einigermaßen effektiv über 3d-texturen realisieren. Dürfte jedenfalls effektiver sein, als jedesmal ne neue textur zu binden. wobei man dafür dann vll. über die Stride-Angaben bei den GL*Pointern gehen sollte, anstatt über die festen interleaved formate
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Pack doch alle Partikeltexturen in eine einzige Texture (kann man ja zur Laufzeit machen, z.B. über Pixelbuffer). Dann sparst du dir nicht nur Statechanges, sondern hast auch das Problem "Texturwechsel und VBO" nichtmehr, du musst dann halt nur entsprechend die Texturkoordinaten variieren. Und da man für Partikel im Normalfall auch keine riesigen Texturen braucht (64x64, oder gar kleiner, sollte meist reichen) dürften die auch alle auf eine Textur passen.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Dafür kann man dann einen Vertexshader benutzen und die Rotation z.B. als Vertexattribut übergeben. ARB-Vertexshader werden inzwischen selbst auf TNT-Karten (via CPU) unterstützt.
Mitglieder in diesem Forum: 0 Mitglieder und 9 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.