Nicht eingeloggt
Registrieren

Emitter und Partikelsystem

Vorwort und Begriffe

Dieses Tutorial handelt von Partikeln und dem Aktor, der sie aussendet: dem Emitter. Verwirrenderweise gibt es im Actor Class Browser derer zwei: *Emitter und xEmitter. Dies geht zurück auf den Zusammenhang der am Spiel beteiligten Firmen. Denn die Unreal Engine im aktuellen Build 2136 wurde von Epicgames hergestellt, das Spiel UT 2003 aber von Digital Extremes. Digital Extremes hat die Engine von Epic ihren eigenen Bedürfnissen angepaßt, und im Falle des Emitters tritt uns das klar vor Augen.

Epic hat nämlich ein Partikelsystem entwickelt, das durch den Aktor Emitter zum Einsatz kommt, Digital Extremes aber hat das Partikelsystem vereinfacht und einen neuen Aktor geschaffen: xEmitter. Was auch immer der Grund gewesen sein mag, der xEmitter bietet eine stark veränderte Auswahl der phantastischen Möglichkeiten an, welche der Emitter von Epic bereithält. Alle Waffeneffekte in UT 2003 z. B. wurden mit dem xEmitter gemacht.

Glücklicherweise hat Digital Extremes mit dem Spiel auch den originalen Emitter von Epic ausgeliefert. Dieser Emitter und die Art, wie er das Partikelsystem steuert, werden in den Tutorials von UDN (Unreal Developers Network) sehr anschaulich dargestellt. Aber das UDN-Emitter-Tutorial hat den Charakter einer Referenz, also eines Nachschlagewerkes, und nicht einer Einführung. Deshalb dieses Tutorial: Es will dem Anfänger Schritt für Schritt zeigen, wie man den Emitter-Aktor bedient.



Inhaltsverzeichnis

Vorwort Vorwort, Inhalt & Begriffe
1 Einführung in das Partikelsystem
1 1 Funktionsweise Einführung in das Partikelsystem
1 2 Die Aufgaben der Partikelemitter
1 3 Plazierung eines Partikelemitters
2 Grundlegende Einstellungen
2 1 Partikeln ein Aussehen verpassen Erste Schritte durch die Einträge
2 2 Partikeln in Bewegung versetzen
2 3 Die Lebensdauer einer Partikel und was sie verkürzt
2 4 Der Startpunkt von Partikeln
2 5 Partikeln die Kollision mit Architektur erlauben
3 Weiterführende Einstellungen
3 1 Den Partikelfluß rotieren: Richtungsänderung leichtgemacht Weiterführende Einstellungen aller Partikelemitter
3 2 Den Partikelfluß rotieren II: Rotation des Koordinatensystems
3 3 Der Spin von Partikeln
3 4 Partikeln einen Bewegungsspielraum zumessen
3 5 Partikeln von der Flugbahn ablenken
3 6 Partikeln verlangsamen
3 7 Die Geschwindigkeitsskala
Nachwort


Zur Begriffsverwendung


Als Grammatik-Fan (ja, sowas gibt?s!) habe ich hier die große Chance, zum Zeitpunkt der Einführung eines neuen Begriffs die ungewöhnliche, aber richtige Form vorzustellen. Es heißt auf Deutsch:


die Partikel (Sing. Fem.), mehrere Partikeln (Pl.)


Alle Einträge in den Eigenschaften eines Emitters werden von mir in Zitaten mit ihren englischen Namen zitiert. Aber wie Ihr vielleicht von mir wißt, schätze ich Begriffe in deutscher Sprache, weil man beim Lesen nicht über sie stolpert. Diese Übersetzungslust ist eine Schrulle von mir, und wenn möglich werde ich sie hier ausleben :-).


Particle, Particles Partikel, Partikeln
Properties Eigenschaften
Actor, Actors Aktor, Aktoren
Velocity Geschwindigkeit
ParticleEmitter Partikelemitter
Lifetime Lebensdauer






Funktionsweise

Ein Emitter sendet Partikeln aus. Partikeln stelle ich mir vor als Punkte, die von Koordinate zu Koordinate durch eine Karte gleiten können. Da man einen Punkt nicht sehen kann, muß man ihm etwas Sichtbares beiordnen: eine Textur oder einen Static Mesh.

Typischerweise sendet ein Emitter mehr als nur eine Partikel aus. Am häufigsten startet er mehrere Partikeln hintereinander. Dies kann beobachtet werden in der Karte ?TokaraForest?. Wenn die Spielfigur mit Blick auf einen der großen Kicker-Bottiche in die Karte eintritt, kann der Spieler über dem Bottich die Partikeln starten sehen. In rascher Folge wird eine Anzahl Partikeln gestartet, die als blaue Funken über dem Bottich aufsteigen und langsam verblassen. Die Zeit, bis die maximale Anzahl von Partikeln erreicht ist, heißt Warmup-Phase. Die Partikeln, die während dieser Phase gestartet werden, können im Gegensatz zu den nachfolgenden, regulären Partikeln in manchen Merkmalen gesondert eingestellt werden, deshalb unterscheidet man sie durch den Namen Initialpartikeln von den regulären Partikeln.


Die nachfolgende, reguläre Phase findet endlos, bis zu einem Höchstwert oder überhaupt nicht statt. Dadurch nämlich, daß man die Zahl der Initialpartikeln hoch, die regulären Partikeln aber auf Null setzen kann, läßt sich die Tätigkeit eines Emitters auf die Warmup-Phase beschränken. Setzt man aber für die regulären Partikeln einen Wert >0, so werden vom Emitter endlos Partikeln ausgesendet, um die älteren Partikeln durch neue zu ersetzen. Oder es wird eine Höchstzahl ausgesandt, weil man vielleicht das Ersetzen der alten Partikeln abgestellt hat.
Soviel vorab zur Einführung in die Funktionsweise. In späteren Kapiteln werden weitere Einträge besprochen: Wie man Partikeln eine Richtung und Geschwindigkeit gibt, wie man sie auf die Erde purzeln und von Wänden abprallen läßt u. a. m.


Die besonderen Einträge eines Emitters, mit denen sich die Partikeleffekte steuern lassen, sind zunächst verborgen. Sie werden erst zugänglich, wenn dem Emitter einer von vier Partikelemittern zugeordnet wird. Ein solcher wird nach seiner Plazierung im Aktor durch einem eigenen Eintrag im Emitter zugänglich. Jeder Emitter kann beliebig viele Partikelemitter beherbergen; mehr dazu im nächsten Kapitel.
Die Unterteilung in Emitter und Partikelemitter im selben Aktor ist notwendig, weil es neben den 24 gemeinsamen Einträgen der Partikelemitter auch einer Reihe spezieller Einträge gibt, die nicht miteinander harmonieren und jeweils nur in einem der vier Partikelemitter zur Verfügung stehen. In den jeweils anderen Partikelemittern sind diese Einträge dann nicht sichtbar. So werden Konflikte vermieden, die bei einer unglücklichen Handhabung der Einträge leicht auftreten könnten.

Die vier Partikelemitter heißen BeamEmitter, MeshEmitter, SparkEmitter und SpriteEmitter.

Spark-, Mesh- und BeamEmitter erfüllen ganz spezielle Aufgaben: An ihre Partikeln werden Funken, StaticMeshes oder Strahlen angeheftet (welche zu einem Gewitterblitz geknickt werden können). Der SpriteEmitter aber ist so universal verwendbar, daß er für die allermeisten Aufgaben benutzt werden kann, die man mit Partikeln lösen will.

Funken können aus einer defekten Maschine schlagen, aus einem prasselnden Lagerfeuer oder aus einer großen Explosion. Mit den Funken des SparkEmitters kann aber auch ein Sylvester-Feuerwerk simuliert werden, der Schaden verursachende Stromschlag eines defekten Lichtschalters oder eines Elektrozauns.

Ein MeshEmitter ist nützlich für dreidimensionale Waffenprojektile, wie ein Raketenwerfer sie ausspuckt. Theoretisch kann man vom Low-Poly-Schrotsplitter der Flak bis zum High-Poly-Raumschiff alle möglichen Arten von Static Meshes an eine Partikel heften, oder, wie im nebenstehenden Bild aus den UDN-Tutorials, Ringe aus Stahl, die eine Kette bilden.


Der Blitz eines BeamEmitters kann Knicks und Verzweigungen aufweisen, die mit jedem neuen Blitz anders angeordnet sind. Der Blitz kann senkrecht in den Boden einschlagen oder gezielt in einen Baum. Aus Hochspannungsleitungen können Blitze in vorüberfahrende Fahrzeuge einschlagen; aus den Kufen eines landenden Raumschiffs können die Blitze nach der Metallplattform darunter zucken und sich mit dem Schiff zusammen absenken, bis es steht und die Blitze damit nicht mehr sichtbar sind.





Der SpriteEmitter schließlich bezieht seine Vielseitigkeit aus der schlichten Art der Darstellung: Jeder Partikel wird einfach eine Textur beigeordnet, die dem Betrachter standardmäßig ihr Gesicht zuwendet, egal von wo er auf die Partikel schaut. Dieses Phänomen ist schon von Coronas bekannt, nur daß die Corona bei zunehmender Entfernung ihre Größe behält, das Sprite hingegen zusammen mit der Umgebung kleiner wird. Schneeflocken und Regen können durch Sprites simuliert werden. Das Sekundärfeuer der ShockRifle ist ein Sprite.

Viele Partikeln mit einer kleinen Rauchwolken-Textur können zusammen in einer großen Rauchsäule aufsteigen, eine Feuersbrunst aus mehreren Flammen-Sprites bestehen, eine Fontäne oder ein Wasserfall sich aus Wasser-Texturen zusammensetzen, die als Sprites an die Partikeln geheftet sind und einer genau definierten Flugbahn folgen.



Öffne den Actor Class Browser und selektiere den Emitter. Achte darauf, daß Du nicht den von DigitalExtremes modifizierten *xEmitter erwischst! Epics originaler Emitter-Aktor darf nur ein Sternchen ohne x im Namen tragen.

Klicke im 3D-Ansichtsfenster mit der rechten Maustaste auf die gewünschte Stelle, wo der Emitter zu finden sein soll. Klicke im Pop-Up-Menü mit der linken Maustaste auf den Eintrag ?Add Emitter Here?.


Nun ist der Emitter in die Karte eingefügt; er wird dargestellt von fünf verschiedenfarbigen Punkten.

[left]Im Folgenden wird ein Partikelemitter in den Emitter-Aktor eingesetzt:

Selektiere den Emitter-Aktor mit der rechten Maustaste und klicke im Pop-Up-Menü mit der linken Maustaste auf den Eintrag ?Emitter Properties?.

Öffne den Eintrag Emitter und klicke auf die Schaltfläche Add.




Mit der Empty-Schaltfläche lassen sich auf einen Schlag alle Partikelemitter aus dem Aktor entfernen.

Die Schaltfläche Clear löscht den ausgewählten Partikelemitter, nicht jedoch den numerierten Platzhalter. Dieser muß mit Delete entfernt werden.

Damit wird ein Platzhalter im Emitter-Aktor geschaffen, der mit einer Nummer versehen ist.





Die Insert-Schaltfläche öffnet einen neuen Platzhalter direkt vor demjenigen, bei dem die Schaltfläche angeklickt wurde. Die Numerierung aller nachfolgenden Platzhalter wird damit um eins nach hinten verschoben. Dies ist wichtig, wenn man wie im obigen Beispiel für eine Explosion mehrere Partikelemitter synchron betreiben will, denn die Verknüpfung erfolgt über die Nummern der Platzhalter. Deshalb ist es besser, einen neuen Platzhalter mit der Add-Schaltfläche statt Insert zu schaffen, denn Add fügt den Platzhalter ans Ende der Liste und nicht mitten hinein.


Öffne den neuen Eintrag [0], um für diesen Platzhalter im Drop-Down-Menü einen der vier Partikelemitter auszuwählen.

Verankere den Partikelemitter im Aktor mit der Schaltfläche New.


Eine weitere Möglichkeit, Partikelemitter im Emitter-Aktor zu verankern, eröffnet die Windows-Funktion Kopieren & Einfügen. Hiermit wird der kopierte Partikelemitter mit allen Eigenschaften, die schon eingestellt wurden, in einen neuen, noch leeren Platzhalter eingefügt.

Der Partikelemitter mit all seinen Einträgen steht nun zur Verfügung.


Partikelemitter werden automatisch im MyLevel-Archiv gespeichert. Hat man also schon einen Emitter mit SpriteEmitter0 und SpriteEmitter1 plaziert, so wird diese Liste in einem anderen Emitter-Aktor in der Karte mit SpriteEmitter2 fortgesetzt, obwohl es sich dort um den ersten Eintrag handelt.


Der Vorgang läßt sich ab Punkt 4 beliebig oft wiederholen, falls man mehrere und/oder verschiedene Partikelemitter im Emitter-Aktor einzusetzen wünscht. Natürlich kann man auch für jeden Partikelemitter einen eigenen Emitter-Aktor setzen; sollen aber mehrere Partikeleffekte miteinander verknüpft werden (z. B. eine Explosion mit sich ausdehnenden Feuerwolken (1), sprühenden Funken (2) und herumfliegenden Trümmern (3), die eine große schwarze Rauchsäule (4) zurückläßt), so müssen die Partikelemitter für eine perfekte zeitliche Abstimmung alle im selben Emitter-Aktor sein, damit sie sich gegenseitig aktivieren können.
 


Da der SpriteEmitter der am meisten verwendete PartikelEmitter ist, werde ich die folgenden Kapitel mit ihm als Beispiel gestalten. Die besonderen Einstellungen der anderen Partikelemitter sollen späteren Kapiteln vorbehalten bleiben.
Dieser Abschnitt der ersten Schritte soll nicht nur die Einträge erklären, sondern den Leser auch mit Beispielen an die Hand nehmen. Deshalb empfehle ich, daß man beim Lesen gleich auch den Editor offen hält, um die Beispiele nachzubauen.




Partikeln ein Aussehen verpassen

Dies ist der erste und wichtigste Schritt. Was immer man später mit den Partikeleffekten alles erreichen will, es muß wenigstens sichtbar sein, um den Erfolg überprüfen zu können.

So wird der richtige Eintrag vorgenommen:

Öffne den Texture Browser und selektiere die gewünschte Textur. Für unsere Zwecke ist ein Punkt geeignet.

z. B. BurnFlare1 -> Flares -> EpicParticles.utx



Rufe die Eigenschaften des Emitter-Aktors auf.

Öffne im Partikelemitter den Eintrag Texture.



Unter den Einträgen dort findet sich ein weiterer Eintrag Texture, der selektiert werden muß. Ein Klick auf die Schaltfläche Use trägt die zuvor selektierte Textur in das Feld links daneben ein und verankert die Textur im Partikelemitter.


Damit wurde die Textur allen Partikeln dieses Partikelemitters zugewiesen.




Partikeln in Bewegung versetzen

Als nächstes sollen die Partikeln sich bewegen. Es soll aussehen, als würde der Emitter einen ständigen Strom von Partikeln abfeuern, die sich mit konstanter Geschwindigkeit vom Emitter entfernen.

Öffne den Eintrag Velocity -> StartVelocityRange.

Öffne darin die Einträge X, Y und Z, um an die Einträge Max und Min zu gelangen, denn nur dort werden Geschwindigkeit und Richtung eingestellt.






Das Koordinatensystem


Mit X, Y und Z sind wir schon bei einem wichtigen Prinzip des Emitters angelangt: dem Koordinatensystem. Die Arbeit mit Top-, Front- und Sideview ist dem erfahrenen Kartendesigner schon so in Fleisch und Blut übergegangen, daß er über die zugrundeliegenden Achsen nicht mehr viel nachdenkt. Ein Wert wie Z= -950 kann jeder Kartendesigner automatisch als Standardeinstellung für normale Schwerkraft identifizieren (denn ein negatives Z weist abwärts).


Wir bewegen uns beim Erstellen einer Karte wie selbstverständlich im Koordinatensystem des Editors, dabei lehrt uns schon das Erstellen eines Kubus mit Height, Width und Breadth, daß jeder Aktor sein eigenes Koordinatensystem hat, welches bei Bedarf sogar rotiert werden kann.

Mit dem Emitter ist das nicht anders, nur daß er anders als ein Kubus nach dem Hinzufügen zur Karte nicht an die CSG gebunden ist. Seine Partikeln gehorchen eigenen Gesetzen. Wenn sie von einer Wand abprallen, dann deshalb, weil es vom Kartendesigner als eine zusätzliche Eigenschaft eingestellt wurde. Kollision ist für Partikeln kein Normalzustand, wie etwa für Spielfiguren oder Waffenprojektile! Die Partikeln sind frei, und ihr Koordinatensystem ist es auch. Es kann rotiert werden, es kann sich die genaue Mitte der Karte zum Bezugspunkt nehmen oder auch einfach den Emitter-Aktor.

Unser Koordinatensystem in diesen Ersten Schritten weist die Standard-Voreinstellung auf. Die Vogelperspektive zeigt die Richtung von X und Y: Positive Werte weisen nach Osten bzw. nach Süden.
Man darf bei der Arbeit mit diesen Einträgen nicht seiner Erinnerung auf den Leim gehen. Das Koordinatensystem des Unreal Editors ist nicht äquivalent demjenigen, das wir aus der Schule kennen, als wir die Werte aus Differentialgleichungen in eine Grafik an der Tafel überführten! Hier weist das positive Y nach Süden statt wie in unserer bildhaften Erinnerung nach Norden.

Es ist sehr nützlich, sich diesen Sachverhalt einzuprägen, weil wir das Koordinatensystem für den Emitter an den unterschiedlichsten Stellen brauchen und sogar verändern werden.


In der 3D-Ansicht ist die Ausrichtung der Z-Achse zu erkennen: Positive Werte führen aufwärts, negative abwärts (ganz wie im obigen Beispiel mit der Schwerkraft).
Die Ausrichtung des Emitters ist in der Standardeinstellung identisch mit dem Welt-Koordinatensystem des Editors. Der Bezugspunkt aber, also die Koordinate (0,0,0), ist in der Standardeinstellung nicht die Mitte der Karte, sondern der Emitter-Aktor selber, egal, wo er plaziert wurde.

Die Höhe des eingetragenen Werte bestimmt die Geschwindigkeit der Partikeln. Mit X=100 fliegen sie doppelt so schnell nach Osten als mit X=50. Die Richtung hingegen ergibt sich aus dem Verhältnis der Werte zueinander.

Im Folgenden wollen wir die Geschwindigkeit von Partikeln verändern, ohne daß davon die Richtung betroffen wäre. Dies wird zuerst anhand der X- und Y-Achse besprochen, dann für das Koordinatensystem des Emitters auch die Z-Achse hinzugefügt. Zugleich wird daran deutlich, wie man mit den X-, Y- und Z-Werten umgehen muß.

Beachte, daß alle Werte in den folgenden Beispielen eine theoretische Einführung in das Koordinatensystem darstellen!


Welche Werte in den Einträgen praktisch nutzbar sind, kommt erst als zweiter Schritt.


Einführung in das Koordinatensystem mit zwei Dimensionen X und Y



Nehmen wir an, die Partikeln sollen nach Nordost fliegen. Dies wird erreicht durch X=2 und Y=-2.



Sollen die Partikeln doppelt so schnell sein, aber die gleiche Richtung behalten, so müssen beide Werte im selben Maße erhöht werden zu X=4 und Y=-4.

Das bedeutet: Jede Partikel erreicht vom Startpunkt (0,0) ihr Ziel in derselben Zeitspanne (z. B. 2 Sekunden). Im Falle von (2,-2) kann sie bummeln, bei (4,-4) aber muß sie sich sputen, denn bei konstanter Zeit muß die Partikel ihre Geschwindigkeit anpassen, wenn die Distanz sich vergrößert.



Dies gilt für alle Richtungen: Ändert man (4,-2) zu (8,-4), so bleibt die Richtung dieselbe, nur die Geschwindigkeit der Partikeln wird verdoppelt.




Einführung in das Koordinatensystem mit zwei Dimensionen X und Y



Jetzt betrachten wir nicht zwei-, sondern dreidimensionale Koordinaten, wie wir sie für den Emitter brauchen.

Wenn die Z-Achse hinzukommt, gilt dasselbe Prinzip: (4,-2,3) haben dieselbe Richtung wie (8,-4,6). Die beiden Koordinaten geben keine andere Richtung an, sondern eine andere Geschwindigkeit!

Es ist also nicht wie beim Autofahren, wo man nur einen einzigen Wert im Auge behalten muß, um dem Blitzer zu entgehen (nämlich die km/h bei der Tachonadel). Vielmehr muß man mit drei Werten jonglieren, will man die Geschwindigkeit der Partikeln korrigieren, ohne die Richtung zu verändern: X, Y und Z.

Die Einträge in den Eigenschaften

Als wäre das nicht schon kompliziert genug, hat Epic auch noch jeder Achse die Einträge Max und Min beigesellt. Wenn man im obigen Beispiel (4,-4) wirklich als eine eindeutige Richtung vorgeben will, dann muß man in beiden Einträgen denselben Wert eintragen:
X(Max)=4 Y(Max)=-4

X(Min)=4 Y(Min)=-4


Mit einem unterschiedlichen Max und Min kann man die Richtung der Partikeln entlang jeder Achse um den Mittelwert herum streuen. Bei identischem Max und Min aber wird überhaupt nicht gestreut, und das wollen wir in obigem Beispiel ja erreichen.

Mit diesem kurzen Hinweis auf die Bedeutung von Min- und Max-Werten wollen wir es aber jetzt belassen. Hier soll es genügen, daß durch identisches Max und Min den Partikeln eine eindeutige und gerade Flugbahn zugewiesen wird.


Ein praktisch nutzbarer Wert für den Eintrag Velocity -> StartVelocityRange ist z. B.
X(Max)=440 Y(Max)=0 Z(Max)=0

X(Min)=440 Y(Max)=0 Z(Max)=0


Mit diesen Werten haben die Partikeln in Richtung +X ungefähr dieselbe Geschwindigkeit wie eine laufende Spielfigur.



Dieser Screenshot aus dem Editor zeigt den Emitter und die Partikeln, die er emittiert.
Der Emitter ist ein SpriteEmitter, und die Textur ist dieselbe wie diejenige, die im Kapitel [2.1] vorgeschlagen wurde. Um den Emitter besser sichtbar zu machen, habe ich unter Display -> DrawScale = 2 eingetragen und das Fünf-Punkte-Symbol damit vergrößert.

Vielleicht wunderst Du Dich, daß nicht die gesamte Textur mit schwarzem Hintergrund abgebildet wird. Der Grund ist eine Voreinstellung des Emitters, alle Partikeln transparent abzubilden. Wie man das ändert und welche Möglichkeiten im Eintrag Texture -> DrawStyle zur Verfügung stehen, ist aber Gegenstand eines späteren Abschnitts.




Die Lebensdauer einer Partikel und was sie verkürzt

Wie lange eine Partikel existiert, bevor sie verschwindet, muß in einem eigenen Eintrag eingestellt werden. Die LifeTimeRange ist die reguläre Lebensdauer, die jeder Partikel bemessen ist.

Öffne in den Eigenschaften des Partikelemitters den Eintrag Time.

Gib unter LifeTimeRange -> Max und Min denselben Wert an. Mit ihnen wird die Anzahl der Sekunden beziffert, die eine Partikel existieren soll.



Auch hier gilt wieder, daß für alle Partikeln derselbe Wert gilt, wenn Min=Max. Ist Min<Max, dann trifft der Emitter für jede ausgeschickte Partikel eine Zufallsauswahl zwischen den beiden Werten. Das Beispiel im obigen Bild zeigt die Voreinstellung, dank derer wir dem Emitter schon beim Arbeiten zusehen konnten, ohne erst die Lebensdauer einstellen zu müssen. Jede Partikel hat eine exakte Lebensdauer von vier Sekunden.
Warum dieser Unterschied? Nun, wenn man Min=Max setzt, dann folgen alle Partikeln in der gleichen Zeitspanne ihrer Flugbahn, und sie verschwinden auch alle gleichzeitig an genau derselben Stelle: dort, wo ihre Lebensdauer endet. Mit Min<Max aber haben die Partikeln unterschiedliche Lebensdauern; der Partikelfluß wird damit innerhalb eines genau bestimmbaren Abschnitts auf der Flugbahn ausgedünnt, nämlich je weiter sie sich von ihrem Startpunkt am Emitter-Aktor entfernen.

Die Lebensdauer ist Teil der Bewegung. Mit Hilfe der Lebensdauer kann man festlegen, wo ein Partikelfluß enden soll, weil die Partikeln ja erst dann zu existieren aufhören, wenn das Ende der Lebensdauer erreicht ist. Das klingt vielleicht ein bißchen verrückt: Um einen Ort festzulegen, nimmt man Einfluß auf die Zeit! Es funktioniert jedoch wunderbar.


Beispiel

Verändere den Wert im Eintrag Time -> LifeTimeRange, indem Du die Lebensdauer auf Min=Max=8 einstellst und sie damit verdoppelst.



Nun passiert folgendes: Jede Partikel sagt dem Emitter ?Hey, laß mich bitte die vollen 8 Sekunden existieren, bevor Du eine neue Partikel aussendest, die mich ersetzen würde?. Die beiden Bilder zeigen jeweils aus derselben Perspektive einmal den Partikelfluß mit 4 Sekunden, darunter mit 8 Sekunden Lebensdauer.



Wie man ungefähr an der Anzahl der Wiederholungen der Bodentextur ablesen kann, hat sich die Strecke tatsächlich verdoppelt. Da die Geschwindigkeit im Eintrag Velocity -> StartVelocityRange immer noch X(Max/Min)=440 beträgt, schreiten die Partikeln mit demselben Tempo voran. Wie man an den beiden Bildern aber sehen kann, hat sich etwas anderes verändert: der Abstand zwischen den Partikeln! Mach Dir den Spaß und zähle die Partikeln auf beiden Bildern. Hier ist nämlich der Grund für den vergrößerten Abstand zu finden. In den Eigenschaften des Partikelemitters ist irgendwo eine Höchstzahl von 10 gleichzeitig sichtbaren Partikeln verborgen.



Der Emitter-Aktor macht folgendes: Er berechnet automatisch, wann er eine neue Partikel starten darf, indem er zu Beginn erstmal die Initialpartikeln bis zur Höchstgrenze startet und danach reguläre Partikeln hinterherschickt, und zwar immer erst dann, wenn die jeweils älteste Partikel ihre volle Lebensdauer abgeschritten hat. Diese Automatik ist voreingestellt und erfüllt den Zweck, eine vernünftige Performance zu gewährleisten. Stellt Euch ohne diese Automatik 10.000 Partikeln gleichzeitig auf dem Monitor vor! Das gäbe eine Dia-Show...

Diese Automatik läßt sich auch abstellen, aber dazu später mehr.






Bisher sind wir einfach davon ausgegangen, daß alle Partikeln ihren Startpunkt beim Emitter haben, weil sie ja schließlich auch vom Emitter ausgesandt werden. Der Startpunkt aber muß nicht mit dem Emitter-Aktor identisch sein; man kann ihn vom Aktor wegschieben! Dies ist z. B. nützlich, wenn man Partikeln innerhalb eines Static Mesh starten will, jedoch für die Arbeit im Editor bequem auf das Fünf-Punkte-Symbol des Aktors zugreifen möchte, weil er neben dem Static Mesh ist.
In diesem Fall verschiebt man einfach den Emitter-Aktor zur Seite und definiert den Startpunkt an der gewünschten Stelle.

Öffne in den Eigenschaften des Emitters den Eintrag Location -> StartLocationOffset und trage unter X, Y und Z die Distanz des Startpunkts zum Emitter ein.


Die Werte X, Y und Z orientieren sich am Koordinatensystem des Emitters.



Die beiden nachfolgenden Bildern zeigen den Partikelfluß und den Emitter-Aktor, und zwar einmal mit dem voreingestellten Startpunkt (direkt beim Aktor) und darunter mit der Veränderung, die ich oben vorgeschlagen habe.

Man kann deutlich sehen, daß der Startpunkt schräg zur Seite verschoben wurde.







Partikeln die Kollision mit Architektur erlauben

Auf nachfolgendem Bild gelten folgende Einstellungen:
Lebensdauer Time LifeTimeRange = 23
Maximale Anzahl der sichtbaren Partikeln General MaxParticles = 20
Startpunkt ist beim Emitter-Aktor Location StartLocationOffset X = 0, Y = 0, Z = 0
Richtung & Geschwindigkeit Velocity StartVelocityRange X(Min) = 440, X(Max) = 440
Y(Min) = -200, Y(Max) = -200

Außerdem habe ich den großen Testraum ein zweites Mal in die Karte gesetzt und seine Höhe drastisch reduziert. Mit einer Lebensdauer von 23 Sekunden kann man eine ordentliche Strecke für den Partikelfluß erwarten. Genau das ist auch der Fall. Folgendes Bild ergibt sich mit den neuen Einstellungen:
Man kann leider wegen der großen Distanz den Emitter-Aktor nicht sehen; er ist ungefähr dort, wo die Pfeile links unten das Koordinatensystem angeben.



Das besondere am Bild ist, daß die Partikeln durch die solide Materie zwischen den beiden Räumen hindurchgleiten! Im Kapitel [2.2] habe ich ja schon behauptet, daß Partikeln sich völlig unabhängig von der CSG bewegen, daß sie vielmehr ihren eigenen Gesetzen gehorchen. Das Bild oben liefert nun den Beweis. Eine solide Wand ist für sie kein Hindernis.
Das ist ein bißchen mißlich; denn man will ja die bunten Blasen aus dem blubbernden Zauberkessel tunlichst auf den Raum beschränken, in dem sie entstehen! Also muß man den Partikeln per Hand ein Verhalten aufzwingen, bei dem sie von soliden Wänden, Decken und Fußböden abprallen.

Dies erreicht man mit dem Eintrag Collision -> UseCollision.





Öffne den Eintrag Collision.

Setze den Eintrag Collision -> UseCollision auf den Wert True.


Jetzt verhalten sich die Partikeln wie im nebenstehenden Bild:

Es ist deutlich zu erkennen, daß die Partikeln von den Wänden abprallen wie Billiardkugeln über die Bande.
Doch Moment ? würde eine Blase aus dem Zauberkessel-Beispiel von der CSG abprallen? Würde sie nicht vielmehr zerplatzen? Man sieht, es gibt Gründe, daß eine Partikel nur eine einzige Kollision haben darf, um sofort danach zu verschwinden.




Partikeln mit der Kollision verschwinden lassen

Dies stellt man so ein:

Stelle den Eintrag UseMaxCollisions auf den Wert True.



Gib dem Eintrag MaxCollisions unter Max und Min jeweils den Wert 1.


Wie erwartet, prallen die Partikeln nicht ab, sondern verschwinden sofort nach Berührung der Wand:



Dabei gibt es aber ein kleines Problem. Das Bild zeigt einen merkwürdigen Rhythmus in der Emission: Die sechs zuletzt ausgeschickten Partikeln fügen sich nicht in den gleichmäßigen Rhythmus ihrer Vorgänger! Den Grund dafür kann man auf dem Bild nicht erkennen, aber es liegt an einer weiteren wichtigen Einstellung des Partikelemitters, der mit den maximal sichtbaren Partikeln zusammenhängt.



Wir erinnern uns: Der Eintrag MaxParticles ist nach wie vor auf den Wert 20 eingestellt. Das heißt, der Emitter wird maximal 20 sichtbare Partikeln zulassen; danach müssen ältere Partikeln den neuen weichen. Ein solcher Fall kann im obigen Bild aber gar nicht auftreten, denn es sind vom Emitter-Aktor bis zur Wand höchstens 10 oder 11 Partikeln sichtbar, danach erfolgt schon die Kollision mit der Wand.

Tatsächlich macht der Emitter folgendes: Jedesmal, wenn durch die Kollision eine Partikel verschwindet, ohne daß die maximale Anzahl Partikeln schon erreicht wäre, sendet der Emitter zum Zeitpunkt des Aufpralls der alten Partikel eine neue aus. Dabei nimmt er keine Rücksicht darauf, ob die neue Partikel sich in den Partikelfluß einfügt. Der Emitter sendet auf diese Art den normalen Rhythmus regulärer Partikeln, und zusätzlich sendet er die just per Kollision gekillten.
Es gibt einen Eintrag, in dem man dieses Verhalten abstellen kann. Das Erscheinen von Partikeln heißt auf Englisch ?Spawn?, das Wiedererscheinen ?Respawn?, und weil es sich um wiederkehrende tote Partikeln handelt, heißt der Eintrag RespawnDeadParticles. Dies kann für jeden Partikelemitter gesondert eingestellt werden; deshalb ist es im Eintrag Local zu finden.




Öffne den Eintrag Local -> RespawnDeadParticles, und ändere den Wert auf False.


Wie man am untenstehenden Bild sieht, hat jetzt mit dem Rhythmus alles seine Richtigkeit, jedoch hört der Emitter nach der zwanzigsten Partikel einfach auf zu senden, weil er die verschwundenen Partikeln nicht mehr ersetzt:
Mit den obigen Einstellungen schickt der Emitter ungefähr nach einer Sekunde die nächste Partikel raus, bei maximal 20 Partikeln ist also nach 20 Sekunden Schluß.

Wenn man eine Karte 15 Minuten lang spielen will, muß der Emitter aber 15 x 60 = 900 Partikeln senden! Man nimmt also zur Sicherheit einen doppelt so hohen Wert (MaxParticles=2000), und schon hat man sein Ziel erreicht: Die Partikeln verschwinden per Kollision, ohne daß die Performance unter einem hohen MaxParticles-Wert leiden müßte. Ein Bild dazu spare ich mir, denn es zeigte den Emitter, wie alles nach Wunsch funktioniert. Das probiere lieber selber aus!



 
 


Hiermit wird nach der Einführung und den ?Ersten Schritten? das dritte Kapitel des Emitter-Tutorials eingeläutet. Wer das Kapitel [2] vollständig gelesen hat, der wird sich nun bestens zurechtfinden, denn alle wichtigen Grundlagen wurden schon in den Ersten Schritten gelegt.
Die nachfolgenden Kapitel sind thematisch sortiert. Wir beginnen mit der Flugbahn der Partikeln, und was man alles damit anstellen kann.


Bewegung


Den Partikelfluß rotieren: Richtungsänderung leichtgemacht

Im Kapitel zur Geschwindigkeit wurde schon anhand von Zeichnungen und Koordinatensystemen demonstriert, wie man die Geschwindigkeit ändert, ohne dabei die Richtung anzutasten. Wir erinnern uns: Man mußte dafür die Einstellungen für X(Max/Min), Y(Max/Min) und Z(Max/Min) alle im selben Maße erhöhen, d. h. alle Werte von StartVelocityRange mit demselben Faktor multiplizieren. Geschwindigkeit soll verdoppelt werden? Alle sechs Werte x2!

Richtungsänderung auf die schwierige Art

Das kann man für eine Richtungsänderung natürlich genauso machen, also mit den Werten solange jonglieren, bis die Richtung stimmt. Denn die Richtung ergibt sich aus dem Verhältnis der Werte zueinander. Wenn wir in der StartVelocityRangedie Koordinate (4,2,8) eingeben, dann werden die Partikeln bei (8,4,16) nur ihre Geschwindigkeit verändern, aber nicht ihre Richtung! Wenn wir hingegen (4,2,8) zu (4,4,8) verändern, dann ist die Geschwindigkeit nur unwesentlich betroffen ? sowas sieht das Auge nicht. Die Richtung aber hat sich verschoben, weil das Verhältnis der Werte ein anderes ist!
Ich habe bisher noch keinen Grund gefunden, diesen schwierigen Weg zu wählen. Es geht nämlich viel leichter auf die andere Weise...


Richtungsänderung auf die vernünftige Art

Weise den Partikeln im Eintrag StartVelocityRange auf nur einer Achse die gewünschte Geschwindigkeit zu.

Im Beispiel werden die schon bekannten Werte verwendet.



Setze den Eintrag Advanced -> bDirectional auf den Wert True.



Öffne den Eintrag Rotation -> UseRotationFrom und setze den Wert auf PTRS_Actor.



Markiere in einem 2D-Fenster den Emitter-Aktor und rotiere ihn, indem Du die STRG-Taste + die rechte Maustaste gedrückt hältst und dann mit der Maus den Pfeil in die gewünschte Richtung ziehst.



Jetzt sieht der Partikelfluß so aus, wie auf dem nebenstehend sichtbaren Bild.



Die Einstellungen bedeuten folgendes:

Daß wir dem Eintrag StartVelocityRange auf nur einer Achse einen Wert zuordnen, hat einen ganz einfachen Zweck; denn auf diese Weise läßt sich die Geschwindigkeit viel leichter kontrollieren, als wenn man mit zwei oder drei Achsen hantieren müßte!


Indem wir den Eintrag Advanced -> bDirectional auf den Wert True setzen, erhalten wir Zugriff auf das Koordinatensystem des Emitter-Aktors. Der Pfeil weist dabei in die Richtung ?positives X?.


Das alleine reicht aber noch nicht. Jeden anderen Aktor könnte man jetzt bequem drehen; doch der Emitter-Aktor ist ja nur ein Platzhalter! Wir müssen also jedem Partikelemitter im Aktor einzeln sagen, ob er von der Rotation betroffen ist. Deshalb haben wir im Eintrag Rotation -> UseRotationFrom den Wert auf PTRS_Actor geändert. Erst jetzt weiß der Partikelemitter, daß sich sein Partikelfluß am Koordinatensystem des Emitter-Aktors orientieren soll.

Im letzten Schritt haben wir den Aktor auf die übliche Weise rotiert. Wir haben in der 2D-Ansicht ?Front? den Pfeil um 45° gekippt. Da man in der ?Front?-Ansicht aus der Position des ?positiven Y? auf die X- und die Z-Achse blickt, bedeutet der Pfeil hier die X-Achse, auch wenn natürlich die Z-Achse ebenfalls gekippt wurde. Sie wird aber nicht durch einen Pfeil dargestellt; man muß sie sich dazudenken. Mit den Ansichten ?Top? und ?Side? verhält es sich genauso: Der Pfeil bezeichnet immer die X-Achse.
Man nimmt nur drei Einstellungen vor, und schon kann man den Partikelfluß paßgenau an die gewünschte Position drehen! Das ist viel einfacher, als mit sechs Werten im Eintrag StartVelocityRange zu jonglieren.



Den Partikelfluß rotieren II: Die Rotation des Koordinatensystems


Wir haben jetzt eine der möglichen Einstellungen kennengelernt, mit denen sich das Koordinatensystem des Emitter-Aktors rotieren läßt. Es gibt aber noch weitere.

Für alle diese Einstellungen ist wichtig, daß mit ihnen der Partikelfluß und der Startpunkt rotiert werden. Betroffen sind demnach die Einstellungen in Velocity -> StartVelocityRange sowie Location -> StartLocationOffset. Es gibt noch einen weiteren Eintrag, der mit der Richtung des Partikelfluß? in Zusammenhang steht: Acceleration (damit simuliert man z. B. Schwerkraft). Aber dieser Eintrag ist nicht betroffen! Wenn wir also den Partikelemitter oder den Emitter-Aktor nach oben kippen, zieht die Schwerkraft weiterhin alle Partikeln geradewegs nach unten. Dieser Eintrag wird in einem späteren Kapitel genauer besprochen.

Im Eintrag Rotation -> UseRotationFrom öffnet man ein Drop-Down-Menü mit verschiedenen Möglichkeiten der Auswahl. Die Buchstaben PTRS sind eine Abkürzung für ?Particles: Rotate the Coordinatesystem?.

PTRS_None Das Koordinatensystem wird überhaupt nicht rotiert.
PTRS_Actor Die Rotation erfolgt durch das Drehen eines Pfeils in den Ansichtsfenstern des Editors.
PTRS_Offset Die Rotation wird durch die Eingabe von Werten im Eintrag RotationOffset eingestellt.
PTRS_Normal Die Rotation wird durch die Eingabe von Werten im Eintrag RotationNormal eingestellt.

Hierbei wird dem Sprite des SpriteEmitters eine Normale zugeordnet, welche die X-Achse bezeichnet.
Näheres siehe weiter unten in diesem Kapitel.


PTRS_None
Dieser Wert ist selbsterklärend. Das Koordinatensystem kann nicht rotiert werden.

PTRS_Actor
Wie man mit diesem Wert umgeht, wurde schon im Kapitel [3.1.1] erklärt, auf das ich hiermit verweise: ?Richtungsänderung leichtgemacht?.

PTRS_Offset

Mit diesem Wert kann man die Einstellungen nutzen, die im Eintrag Rotation -> RotationOffset vorgenommen wurden. Das werde ich jetzt genauer behandeln.

Wer schon mal einen Flugsimulator geflogen ist, wird mit den Begriffen Pitch, Roll und Yaw etwas anfangen können. Es handelt sich hier (wie bei jeder Rotation) um das Drehen entlang einer Achse, wobei sich die Werte der anderen beiden Dimensionen verändern. Prinzipiell muß man sich dafür mathematisches Wissen aus frühen Schultagen vergegenwärtigen:

Ein 0-dimensionales Objekt ist ein Punkt (z. B. das Innere eines Schwarzen Lochs).
1-dimensionale Objekte sind Geraden (die Flugbahn einer Sylvesterrakete),
2-dimensional sind Flächen (z. B. ein Bild),
3-dimensionale Objekte sind Körper (z. B. die Grundkörper ?Würfel?, ?Pyramide?, ?Kugel?).

Hier geht es darum, daß Rotation sich nur in zwei Dimensionen abspielt, die dritte Dimension hingegen die Aufgabe einer Achse übernimmt, um die herum die Rotation stattfindet. Es wird also die Vorstellung einer Fläche benötigt, in deren Mitte eine Achse genau im rechten Winkel absteht.

Und außerdem müssen wir die Begriffe Pitch, Roll und Yaw in das Koordinatensystem unseres Emitter-Aktors übertragen. Dafür konstruiere ich ein Beispiel.

Stell Dir vor, Du sitzt in einem Flugzeug und fliegst horizontal Richtung +X. Das bedeutet, daß Dein Kopf nach +Z weist, Deine Füße aber nach ?Z. Die Y-Achse hingegen verläuft quer durch Deine Hüfte: von links (-Y) nach rechts (+Y).



Pitch Hier wird im Unreal Editor um die Y-Achse herum rotiert. Pitch ist die Bewegung, wenn Du die Nase des Flugzeugs nach oben oder nach unten ziehst. Die Rotation findet dabei entlang der Y-Achse statt, die im Flugzeug quer durch Deine Hüfte geht.

Roll Die Achse der Rotation ist bei Roll die X-Achse. Stell Dir vor, Du fliegst bei einer Flugschau geradeaus, und wenn Du über die Köpfe des Publikums fliegst, dann wackelst Du mit den Flügeln.

Yaw Es bleibt die Z-Achse, die von unten in Dich eintritt und oben aus Deinem Scheitel wieder austritt. Diese Bewegung Yaw kann auch ein Flugzeug leisten; aber stell Dir besser einen Ferrari vor, der während einer Autoausstellung auf einem Drehteller steht.

Nach diesen kleinen Erklärungen will ich mit Bildern zeigen, wie sich entsprechende Einstellungen auf den Partikelfluß auswirken. Ich habe zu diesem Zweck einen Partikelemitter so eingestellt, daß er 100 Partikeln gleichzeitig Richtung +X aussendet; außerdem streut er die Partikeln auf der Z-Achse. Der Partikelfluß folgt also einem Fächer; er sieht aus wie ein Geodreieck, das auf einer Seite steht. Die folgende Abbildung zeigt die Werte im Eintrag Velocity -> StartVelocityRange. Markiert ist dabei der Eintrag, der die Streuung auf der Z-Achse hervorruft:



Die Werte, die man im Eintrag Rotation -> RotationOffset unter Pitch, Roll und Yaw einträgt, sind sehr große Zahlen. Der Wert 8192 bezeichnet einen 45°-Winkel, entsprechend 16384 einen Winkel von 90°. Mit einer so feinen Abstufung kann man den Partikelfluß viel genauer rotieren als mit der in Kapitel [3.1.1] beschriebenen Methode, wo man den Pfeil rotiert.

In den nächsten Schritten werden die nötige Einstellungen mit Beispielen jeweils für Pitch, Roll und Yaw erklärt.



Öffne den Eintrag Rotation -> UseRotationFrom und setze den Wert auf PTRS_Actor.


Im Folgenden zwei Bilder: zunächst ohne, dann mit Rotation.



Der Fächer, der sich durch die Streuung entlang der Z-Achse ergibt, ist deutlich zu sehen. Ausgehend vom Emitter-Aktor fliegen die Partikeln in Richtung +X (grüner Pfeil), steuern ihre Ziele aber auf einer Linie an, die zwischen zwei verschiedenen Z-Werten verläuft.Ich habe zwei Achsen des Koordinatensystems gepunktet eingetragen: X und Z. Diese Fläche, die in ihrer Ausrichtung identisch ist mit dem Fächer, wird für die Rotation wichtig sein.



Hier das Ergebnis der Rotation: Die Y-Achse wurde rotiert und damit die Werte von X und Z verändert. Mit unserer Einstellung Pitch=8192 wurde ein 45°-Winkel geschaffen. Das ?Geodreieck? liegt nun nicht mehr auf einer der Katheten; diese wurde vielmehr um 45° angehoben. Der Fächer steht auf der Spitze, weil die Bewegung auf einer Fläche erfolgt ist, die durch die X- und die Z-Achse bestimmt wurde.


Oben wurde gesagt, man müsse sich eine Fläche vorstellen, auf der die zu rotierende Achse im 90°-Winkel absteht. Nun, diese Fläche wird hier durch die X- und die Z-Achse definiert, während die Y-Achse als Rotationsachse dient.

Nun derselbe Emitter mit rotiertem Roll:



Roll verändern:Trage unter Rotation -> RotationOffset -> Roll den Wert 8192 ein.



Die Roll-Bewegung war beim Flugzeug das ?Wackeln mit den Flügeln?. Wir dürfen also eine Art ?seitliches Ankippen? des Fächers erwarten.Wieder habe ich die relevanten Achsen der Fläche gepunktet eingezeichnet. Diese Achse bilden eine Fläche, über die der Fächer mit der Rotation schrammen wird.



Hier das Ergebnis der Rotation: Die X-Achse wurde rotiert und damit die Werte von Y und Z verändert. Der Fächer liegt immer noch auf derselben Kante, weil diese Kante identisch ist mit der X-Achse. Ein kreisförmiger Pfeil zeigt wieder die Achse an, um die herum rotiert wurde.


Die Ausgangsbasis ist für Yaw identisch, nur daß diesmal die übriggebliebene Z-Achse als Rotationsachse dient:



Yaw verändern:

Trage unter Rotation -> RotationOffset -> Yaw den Wert 8192 ein.



Die Yaw-Bewegung war der Ferrari, der auf einem Drehteller steht. Die gepunkteten Achsen bezeichnen wieder die Fläche, über die der Fächer gleich schrammen wird.



Wie erwartet rotiert im Bild die Kante auf dem Fußboden, sie nimmt für den Wert 8192 den 45°-Winkel ein.



PTRS_Normal

Mit diesem Wert wird der Eintrag Rotation -> RotationNormal relevant. Bisher haben wir zwei Methoden der Rotation kennengelernt, bei der entweder ein Pfeil in der 2D-Ansicht oder sehr feistufig eine Achse wie im Flugsimulator rotiert wurde. Diese dritte Methode nun bringt uns auf vertrautes Terrain zurück: Hier wird nämlich der Partikelfluß nicht rotiert, sondern ausgerichtet, als wolle man nachträglich die Richtung bestimmen wie im Eintrag Velocity -> StartVelocityRange.
Stellen wir uns vor, wir hätten in der StartVelocityRange mit Absicht nur einer Achse einen Wert zugewiesen, vielleicht weil wir die Geschwindigkeit der Partikeln aufs Genaueste festlegen wollten. Nun würden wir ja gerne die Richtung ändern, wie es uns aus Kapitel [2.2] bekannt ist, aber wir wissen leider, daß sich beim Verändern der Werte im Eintrag StartVelocityRange dann die Geschwindigkeit wieder verringert oder erhöht.

Mit dem Eintrag Rotation -> RotationNormal steht uns deshalb ein Werkzeug zur Verfügung, wo man für die Achsen X, Y und Z (ohne Max und Min!) eine Koordinate eingibt, ohne die Velocity zu berühren. Der Partikelfluß wird einfach gemäß der neuen Werte "herumgebogen". Das Verhältnis der Zahlen entlang der drei Achsen bestimmt dabei die Änderung der Richtung. Dabei gilt außerdem, daß die Richtung der Partikeln aus dem Eintrag StartVelocityRange automatisch als X-Achse im Eintrag RotationNormal behandelt wird ? völlig egal, in welche Richtung die Partikeln gemäß der Velocity abgefeuert werden, diese Richtung ist das positive X für die Rotation.




Schicke den Partikelfluß ohne Streuung nach Norden, indem du im Eintrag Velocity -> StartVelocityRange für Y(Min) und Y(Max) den Wert ?440 eingibst.



Damit ist zunächst ein ganz normaler und auch erwarteter Partikelfluß zu sehen:

Die beiden blauen Pfeile weisen in die Richtung, in der die X- und Y-Werte vom Koordinatensystem des Emitter-Aktors positiv ansteigen.
Der Partikelfluß liegt auf der Y-Achse und strebt negativen Werten entgegen; aber das ist ja zu erwarten.




Zur Erinnerung füge ich hier nocheinmal die Grafik ein, die im Kapitel [2.2] in das Koordinatensystem eingeführt hatte. Es sind genau diese Pfeile, die den Werten der StartVelocityRange zu Grunde liegen und im oberen Bild blau eingezeichnet sind. So weit, so gut.


Als nächstes verändere ich die Einstellungen im Eintrag RotationNormal. Und zwar benutze ich die Werte, die auch schon aus einem früheren Bild bekannt sind:



Da der Eintrag keinen Einfluß auf die Geschwindigkeit hat, sondern einfach nur die Richtung ändert, kann ich die Werte im Bild direkt nebutzen. Denn es kommt ja jetzt nicht mehr auf die Höhe des Wertes an, sondern ausschließlich auf das Verhältnis der Zahlen zueinander.


Ich überführe also diese Werte in den Eintrag zur Rotation.



Trage im Eintrag Rotation -> RotationNormal die Werte X=4 und Y= -4 ein.



Das bewirkt nun folgendes:
Der Partikelfluß sieht aus, als würde er auf der falschen Seite der Y-Achse stattfinden! Bei X=4 und Y= -4 hätte man die Zielkoordinate nicht in Richtung Nordwest, sondern Nordost vermutet. Der Grund für diese ?falsche? Richtung liegt am Begriff Normal.

Jedes Triangel bzw. Polygon an einem 3D-Objekt hat eine sogenannte Normale. Das kann man sich vorstellen wie einen Stachel, der in einem perfekten rechten Winkel aus der Mitte der Fläche herausragt. Da ein 3D-Objekt nur aus solchen dreieckigen Flächen besteht, kann man es sich auch stachelig vorstellen.
Dieses Prinzip macht sich das Rotationsverfahren PTRS_Normal zunutze. Es verwandelt die aktuelle Richtung des Partikelfluß? in eine Normale, macht den Startpunkt also zu einer Fläche, auf der der Partikelfluß draufsitzt wie der Stachel einer Normalen auf dem Triangel. Wenn man jetzt die Richtung ändern will, setzt man die Normale mit einer X-Achse gleich, pfropft also ein Koordinatensystem auf den Emitter, das nichts weiter leisten soll, als eine neue Richtung für diesen speziellen Partikelemitter zu definieren.



Im folgenden Bild ist das Koordinatensystem des Emitters blau, das der Rotation über die Normale rot:


Im roten Koordinatensystem der Funktion PTRS_Normal ist außerdem das Verhältnis der beiden Werte eingezeichnet, die wir vorhin im Eintrag RotationNormal festgelegt hatten.

Man kann sich vielleicht vorstellen, daß man zuallererst Richtung und Geschwindigkeit im Eintrag StartVelocityRange festhält und dafür das blaue Koordinatensystem beansprucht. Wenn man danach aber unzufrieden ist mit der Richtung und etwas ändern möchte, dann kann man ein zweites Koordinatensystem aufrufen (das rote), das sich nur an der Richtung des Partikelfluß? orientiert und im Eintrag RotationNormal auf die gewohnte Weise mit Zahlenverhältnissen die Richtung der Partikeln einfach umbiegt.

 



Auch hierbei handelt es sich um Rotation, und alle relevanten Einträge sind unter Rotation versammelt. Es wird aber nicht der gesamte Partikelfluß rotiert, sondern jede einzelne Partikel selbst. Und während die Rotation des Partikelfluß? eher eine neue Festlegung der im Spiel unbeweglichen Richtung ist, handelt es sich nun um eine im Spiel sichtbare Bewegung: Die Partikeln drehen sich die ganze Zeit über. Um dies kenntlich zu machen, rede ich im Folgenden nicht von ?Rotation?, sondern vom ?Spin?.

In der Voreinstellung ist der Spin abgeschaltet. Man muß ihn zunächst aktivieren.



Ändere im Eintrag Rotation -> SpinParticles den Wert auf True.



Weise den Sprites einen Spin zu im Eintrag Rotation -> SpinsPerSecondRange.

Im Eintrag habe ich den Wert 0,2 gewählt: Pro Sekunde vollführt das Sprite an der Partikel also eine Fünftel-Drehung; Es bräuchte also fünf Sekunden für einen vollen Spin. Da die Lebensdauer nur vier Sekunden beträgt, schafft das Sprite die Drehung nicht ganz. Achte im folgenden Bild auf die Stellung der letzten Partikel ganz hinten in der Reihe:




Die Partikeln legen sich zunächst auf den Rücken, drehen sich dann wieder in ihre Ausgangsstellung.
Aber eben nicht ganz! Die letzte Partikel ist noch fast seitlich geneigt. Spin und Lebensdauer passen nicht vollständig zueinander.


Wählen wir andere Werte, dann ändert sich auch das Bild:



SpinsPerSecondRange Max=0.25 / Min=0.25



Mit diesen Werten vollführt das Sprite eine Viertel-Drehung pro Sekunde, und das paßt zur eingestellten Lebensdauer.
Jetzt hat die letzte, hintere Partikel ihre Ausgangsstellung erreicht. Spin und Lebensdauer sind perfekt aufeinander abgestimmt.

Man wird eine solche Feinabstimmung nur bei wenigen Gelegenheiten brauchen. Ein Bot, der im Weitsprung einen Salto schlägt, muß natürlich perfekt auftreffen. Bei den allermeisten Gelegenheiten aber wird man ein unstimmiges Verhältnis von Lebensdauer und Spin der Partikeln nicht sehen können, zumal mit der Möglichkeit, in Max und Min verschiedene Werte einzutragen, die Zufallsauswahl an Spin-Geschwindigkeit das Bild belebt und damit sowieso jede Feinabstimmung zerstört.



Uhrzeigersinn und Gegenuhrzeigersinn

Wie man an den Bildern erkennen kann, verläuft der Spin im Gegenuhrzeigersinn. Das habe ich so eingestellt, um den Spin besser zeigen zu können. Die Voreinstellung ist jedoch anders.
Der Eintrag, in dem die Drehrichtung eingestellt wird, heißt SpinCCWorCW. Diese Abkürzung löst sich auf wie folgt:

Spin CounterClockWise or ClockWise.

Die untergeordneten Einträge erlauben es, die Richtung des Spin für jede Achse einzeln einzustellen. Wie aber oben schon erwähnt, ist nur die X-Achse für Sprites sinnvoll, also können wir Y und Z ruhig vernachlässigen. Werte in diesen beiden Einträgen haben keine Auswirkung auf die Drehrichtung eines Sprites, sie werden erst für Meshes brauchbar.


Die Werte, die man einträgt, liegen zwischen 0 und 1. Sie bezeichnen die Chance, daß eine Partikel im Gegenuhrzeigersinn gestartet wird.

Fangen wir mit dem Uhrzeigersinn an:



Trage im Eintrag Rotation -> SpinCWWorCW -> X den Wert 0 ein.



Der Wert 0 bedeutet, daß keine einzige Partikel sich im Gegenuhrzeigersinn drehen wird. Es ergibt sich deshalb folgendes