Hallo
Also ich habe nachdem ich mir das particle dem genauer angeschaut hab, es etwas verändert und versucht in eine kleine engine einzubauen. da Zeigte sich ein gravierendes Problem: die Partikel werden immer vorne hingezeichnet, egal ob da noch ne fläche kommt, oder nicht. Wie schaffe ich es, dass ich trotz den Partikel den Depth Buffer verwenden, kann, so dass er erkennt ob die Partikel irgendwo dahinter sind

Für Hilfe wäre ich sehr dankbar, das dürfte doch net schwer sein, oder?

IO-sys/MathiasH

Also ohne mich jetzt auf ein spezielles Demo zu beziehen:

Du musst beim Zeichnen der Partikel nur drauf achten, dass der Z-Buffer auch aktiviert ist und die Partikel auch an der richtigen (Tiefen-) Position aufscheinen.
Wenn du Partikel willst, die in größerer Entfernung kleiner werden, nimmst du entweder BillBoards oder verwendest (ab OpenGL 1.4 oder als ARB-Extension) PointParameter - was natürlich schneller ist, weil weniger Daten gesendet werden müssen.

Wie bei allen durchsichtigen Objekten, solltest du bei Partikeln das Schreiben in den Z-Buffer (GL_DEPTH_WRITE) ausschalten und diese als letzte und tiefensortiert zeichnen (nicht vergessen, das Schreiben danach wieder einzuschalten - und GL_DEPTH_WRITE nicht mit GL_DEPTH_TEST verwechseln :rolleyes: .

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

@schneller: nein, bei partikeln ist nicht die datenmenge cpu->graka ausschlaggeben, die fällt eh relativ geringer aus.... das große problem ist die füllrate, die wird durch die partikel nämlich extremst beansprucht

die Partikel tiefensortiert zu zeichnen ist relativ aufwändig und beansprucht den Prozessor ziemlich stark. Man muss erst manuell die Vertices mit der Modelview-Matrix multiplizieren (zumindest teilweise) um die Endgültige Z-Koordinate zu erhalten und dann müssen alle Partikel auch noch sortiert werden - auch die besten Algorithmen benötigen dafür relative viel zeit. (Ich benutzte in PixelprachtFX Merge sort mit O(n log n) d.h. um 1000 Partikel zu sortieren wird 3000 mal eine Methode aufgerufen die jeweils einen ganzen Haufen Verzweigungen und Kopiervorgänge enthält. Bei einfachen Sortieralgorithmen wie z.b. Bubblesort O(n^2) ist der Aufwand noch viel höher)
Deshalb musst du dir gut überlegen ob du überhaupt die Partikel sortieren musst: Dies ist nämlich nur nötig bei Transparenten Partikeln. Bei opaquen oder welchen die per additivem Blending (Feuer, Licht das meiste eigentlich...) verarbeitet werden kannst du dir und deinem Rechner die Mühe sparen.

_________________
Selber Denken macht klug!

@durchsichtige Objekte:
stimmt, Sortierung gilt natürlich nur für durchsichtige Partikel - aber eigentlich sollte es auch dann meist ausreichen, nicht jedes Partikel zu sortieren, sondern die einzelnen Partikelströme

@schneller
ich dachte dabei weniger an die Geometriedaten (die auch bei Quads relativ gering ausfallen - obwohl es bei sehr vielen Partikelströmen schon etwas ausmachen könnte), als vielmehr daran, dass man sich über GL_POINT_PARAMETER evtl. Alphamaskierte Texturen sparen könnte (um z.B. Kreise darzustellen, die nach außen in den Hintergrund übergeblendet werden). Allerdings sind die halt erst ab OpenGL 1.4 standardmäßig dabei, zuvor nur als Extension.

Ich muss aber zugeben, dass das alles eher theoretische Überlegungen sind, weil ich bis jetzt nicht besonders viel mit Partikeln gearbeitet habe (nur so ein bisschen rumprobiert). Ich bin aber so nebenbei schon dran interessiert, weil ich irgendwann auch Partikel in Mcad einbauen möchte, und dazu eine möglichst allgemeine Partikelklasse plane, die so angelegt ist, dass sie ohne mordsmäßig aufwendige Änderungen möglichst viele Effekte darstellen kann (weil das Ganze ja auch als Source exportiert werden soll).

@Lithander
Nachdem du dich ja schon länger mit Partikeln beschäftigst, wär's eigentlich toll, wenn du ein Demo ins Projektforum stellen würdest, indem du die einzelnen Fähigkeiten der Engine aufzeigst und zu jedem Effekt kurz die angewandte Technik und evtl. dabei auftretende Schwierigkeiten darstellen würdest.
Muss ja nicht supertoll-genial aussehen, zumindest ich würde mich aber sehr dafür interessieren, welche Effekte du in PixelPracht mit wieviel Aufwand umsetzt.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

ihr habt mich etwas verwirrt *g*

also meine Partikel engine muss nicht allzu leistungsfähig sein, (Screenshots: <a href='http://www.kernelz.de/game' target='_blank'>www.kernelz.de/game</a>) ich werde wahrscheinlich maximal 300 partikel pro antrieb haben, wobei jeder antrieb die selben partikel etwas gedreht und verfärbt hat. Ein weiterer einsatzzweck werden explosionen sein, die aber nicht allzu toll werden müssen....(später....)

so wie ich euch verstanden hab muss ich einfach statt gl_Depth_test ab, bzw anzuschalten gl_depth_write an bzw abschalten und die Partikel nach allen anderen polys zeichnen, stimmt das so?

IO-sys/MathiasH

Nur wenn deine Partikel durchsichtig sind. Ansonsten kannst du sie zeichnen wie jedes andere Objekt.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Ich hab auf meiner Website ne Partikel-Demo, die kannst du dir gerne mal ansehen.

PixelprachtFX ist keine Partikelengine im herkömmlichen Sinne sondern eher ein Toolkit zum erstellen von Partikeleffekten. Du hast als nicht wie üblich einen haufen Parameter über die du deine System deinen Wünschen anpassen kannst sonder erbst von einer Grundklasse und implementierst den Rest selbst. (Unterstützt durch zahlreiche Methoden die physikalische Effekte nachbilden oder allgemein Partikel manipulieren und generieren)
Deshalb kann ich auch nicht sagen welche Effekte man machen kann und welche nicht. Im Prinzip kannst du alles machen.

Wenn du's aber trotzdem noch für sinnvoll hälst, dann kann ich gerne ein Paar Takte zu den Features und zum Aufbau im Projektforum posten...

-lith

_________________
Selber Denken macht klug!

Vielen Dank für den Link (ich sollte manchmal echt ein wenig aufmerksamer sein).
Natürlich wären einige Zusatzinformationen im Projektforum (z.B. Laufzeitverhalten, Optimierung bestimmter Routinen durch Assembler u.ä.) auf jeden Fall interessant.

Ich habe mir aber den Header (PixelprachtFX.pas) angesehen, und denke schon, dass ich das Prinzip, nach dem du vorgehst nachvollziehen kann (was einiges über die Qualität des Sourcecodes aussagt, wenn dieser auch ohne Dokumentation leicht verständlich ist!). Dennoch bleiben bei mir noch einige Fragen offen:

Reichen, deiner Erfahrung nach, die Eigenschaften von TFxParticle für eine allgemein gültige Partikelengine aus (mir würde auf die Schnelle zwar auch nichts zusätzliches einfallen, habe aber bis jetzt auch nur mit dem Gedanken gespielt, eine Partikelengine zu entwerfen, vielleicht bist du aber bereits auf einige Begrenzungen gestossen) ?

Mir gefällt besonders die Idee, über zwei Methoden (Init und Advance) das Verhalten beliebiger Partikelströme steuern zu können (das lässt sich nämlich ohne viel Aufwand in einem Sourcecodegenerator umsetzen). Die ganzen Hilfsroutinen (ParticleActions) dienen ja, soweit ich sehe, eher dazu, schnell den gewünschten Effekt zu erzielen.
Da mir die ganze Klasse durchaus sinnvoll aufgebaut zu sein scheint, werde ich mich bei einer eventuellen Implementation in Mcad daran orientieren (wenn's dich nicht stört - aber keine Angst, ich bin wirklich nicht der Copy&Paste Typ, würde aber gerne deinen Aufbau adaptieren und mir nicht unnötigerweise den Kopf darüber zerbrechen, was nun reinkommen soll und was nicht, wenn es eh schon eine gute Lösung gibt). Immerhin wäre ich um Hinweise auf eventuelle Schwachpunkte dankbar.

Wenn ich kurz zusammenfassen darf, realisierst du Partikel also folgendermaßen ?

TFxParticle: Eigenschaften jedes einzelnen Partikels

TFxGroupSettings: Eigenschaften eines Partikelstroms

TFxGroup: Ein Partikelstrom, der selbst aber noch nix kann

TFxDepthList: Wrapperklasse für Tiefensortierung sämtlicher Partikel

TFxTemplateLib: Wrapperklasse um verschiedene Standardpartikel festlegen zu können, ohne diese explizit als globale Variablen zu definieren

TFxGroupLib: Verwaltet mehrere Partikelströme, kann aber immer noch nix

TFxSystem: Verwaltet mehrere Partikelströme und verschiedene Standardvorlagen, aller Partikel verhalten sich aber gleich (festzulegen über Init und Advance) - d.h. für jeden Effekttyp benötigt man ein eigenes TFxSystem, ein TFxSystem langt aber für mehrere Effekte des gleichen Typs aus.


Wie gesagt - das erscheint mir durchaus durchdacht (bitte mich auf evtl. Fehler hinzuweisen) - ich werde es in Ogl evtl. ähnlich realisieren (vereinfacht unter Weglassung einiger Klassen, die meiner Ansicht nach so nicht wirklich notwendig sind: TFxDepthList, TFxGroupLib, TFxTemplateLib), nur dass innerhalb von Mcad Templates und Funktionen vergeben werden können, die in Mcad (für die Darstellung) über einen Funktionsparser laufen, im erstellten Source aber direkt als Code angelegt werden.

Templates brauche ich keine, da ich den Vorteil habe, mit einem Sourcecodegenerator globale Variablen definieren und benennen zu können soviel ich will . Dynamische Arrays werden durch Zeiger auf dynamisch angelegten Speicher ersetzt (ist eh das selbe), da das ganze auch unter C/C++ laufen soll. Ich denke aber dass dies sicher das nächste größere Feature in Mcad wird, für eventuelle Tipps wäre ich sehr dankbar.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Im moment ist die ganze Sache noch relativ unoptimiert - bei Partikeln fallen mir allerdings soviele Sachen nicht ein. Aber ein Paar Ideen hab ich noch....
Zum sortieren benutze ich Mergesort - ein relativ schneller Algorithmus der sich gegenüber Bubblesort bereits bezahlt gemacht hat. Assembler verwende ich (noch) gar keinen.
Aber das ist ja auch noch Version 1.0 - eine neuere Version ist bereits geplant, die schneller sein wird, ein paar mehr Optionen haben soll und vorallem mit allem Quellcode kommt. Evtl fällt bekomm ich dann ja optimierungsvorschläge von Seiten der Community.


Schönen Dank! *freu*


Also im Prinzip ist die Engine ja so aufgebaut das siche fehlende Funktionalität einfach in den Advance-Methoden selbst ergänzen lässt. Außerdem sind die Rendereinstellungen ziemlich flexibel. Ich denke also das mein Ansatz für eine ziemlich flexible Engine sorgt, was allerdings etwas auf Kosten der Performance/Optimierbarkeit geht...



Die Actions nehmen dem Benutzer die Implementation der am meisten gebrauchten Physikalischen Effekte ab. Das vereinfacht das die Erstellung von Effekten enorm und ermöglicht auch den weniger Physik-interessierten ganz mit einem paar Dutzend Codezeilen schon ansehnliche Effekte machen...


Nein, natürlich stört's mich nicht... lieber wäre mir allerdings wenn du eine möglichkeit findest PixelprachtFX selbst in Mcad zu integrieren. Dein Vorteil wäre das du dir a) Arbeit sparst und B) von meinen Erweiterungen gleich mit profitierst.


Alles korrekt!

_________________
Selber Denken macht klug!

Vielen Dank, wenn ich dann tatsächlich Partikelsysteme in Mcad integriere, werde ich mich sicher an den Pixelprachtpartikeln orientieren. Leider komme ich aber um eine eigene Implementation nicht herum, da die Mcad neben Delphi auch Source in C++ und Ansi C generieren kann. Da die sowohl die C als auch die C++ Variante der Ausgabe betriebssystemunabhängig sind (neben der Windows API kann die Initialisierung des OpenGL Treibers auch über GLUT erfolgen, dann können die erstellten Programme z.B. auch unter Linux kompiliert werden), kann ich auch nicht auf eine DLL zurückgreifen. Das ist übrigens mit ein Grund, warum bei Mcad die vollständige OpenGL Bibliothek als Source dabei ist.

Ich bin ohnehin noch am "brainstormen", was alles hineinkommen soll - eine Überlegung tendiert dahin, Partikeln die Möglichkeit zu geben herauzufinden, wieviele Partikel des eigenen Stroms innerhalb einer bestimmten Distanz liegen. Damit ließe sich dann relativ einfach z.B. Schwarmverhalten von Fischen oder Vögeln realisieren (werde ich aber wahrscheinlich dennoch nicht machen, da zu speziell).
Eine andere Überlegung ist, das ganze überhaupt so einfach wie möglich zu halten, sodass Partikel auch keine Eigenrotation haben können, sondern nur als Punkte und/oder BillBoards realisiert werden.

Was aber auf jeden Fall noch hinzukommen wird, ist, dass man festlegen kann, dass Partikel bis zu einem festzulegenden Grad sozusagen die History ihrer bisherigen Aufrufe zwischenspeichern können, die dann bei einer weiteren Darstellung in abgeschwächter Form ebenfalls gezeichnet werden. Damit müssten sich auch bei wenigen Partikeln schöne Überblendeffekte realisieren lassen.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Das wäre allerdings nicht das Problem, denn die DLL soll beim nächsten Release sowieso verschwinden...

Aber ich versteh schon wenn du dein eigenes Ding machen willst! Halt mich auf dem laufenden vielleicht kann ich die ein oder andere Sache dann ja auch bei mir einbauen...

_________________
Selber Denken macht klug!

Werde ich machen (bzw. habe ich ohnehin vor, den Fortschritt von Mcad 2 auch im Projektforum zu kommentieren).



Tja, da hast du mich durchschaut . Ich verwende höchst ungern Komponenten und Programmteile, die ich nicht selbst geschrieben habe (und in Mcad, das so eine Art Hobby von mir ist, schon gar nicht).
Zu meiner Rechtfertigung kann ich in deinem Fall immerhin anbringen, dass, selbst wenn der ganze Sourcecode von PixelprachtFX 2 bereits zur Verfügung stehen würde, ich das Ganze immer noch nach ANSI C sowie C++ portieren müsste, um den Leistungsumfang von Mcad und Ogl zu erhalten. Vielleicht stellst du aber den Entwicklungsstand von PixelPracht 2 ebenfalls ins Projektforum - dann kann man dort einen Meinungsaustausch abhalten.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

=) geht mir genauso. Alle interessanten Sachen will ich auch selber machen - und Partikelsysteme sind definitiv interessant.



Wohl eher Pixelpracht 1.1

Aber wenn es soweit ist werde ich's im Projektforum kundtun! Dann schreib ich auch noch ein bissl mehr zu den Features.

-lith

_________________
Selber Denken macht klug!