Latest revision as of 06:06, 11 November 2010

Koordinaten Bezugssysteme

Es gibt derzeit vier verschiedene Bezugssysteme, die im Viewer verwendet werden. Beachten Sie bitte, dass es einige Fälle gibt, in denen der Programmcode im Viewer diesen Konventionen NICHT folgt: Der Code, der im Rendering verwendet "World" und "W" für den Agent und Teile des Character/Verbinden Codes haben kein Bezugssystem festgelegt, aber das wird im Agent definiert. Auch allgemeine Bibliotheken (LLCamera und LLPrimitive im speziellen) verwenden die Konventionen auch NICHT. Seien Sie besonders vorsichtig, wenn Sie Werte direkt aus diesen heraus verwenden.

Global

Absolutes globales Koordinatenbezugssystem, im F64 Format angegeben. Das ist vom U32 Format der x und y Koordinaten der Angaben der Region plus dem Offset der Region abgeleitet. Es ist genau genug, um ~10⁹ Regionen mit der gleichen Genauigkeit übereinander auszurichten, wie es mit lokalen Regionenkoordinaten möglich wäre.

Region

Der Ausgangspunkt ist der Ursprung der Region, die das Objekt "besitzt".

Agent

Derzeit ist der Bezugspunkt der Ursprung der Region, in der sich der Agent momentan befindet. DAS BEDEUTET NICHT UNBEDINGT, dass das auch in Zukunft so sein wird. Dieser Bezugspunkt sollte nur für Programmcode verwendet werden, der im Zusammenhang mit dem Rendering steht (Renderpipeline, Sichtbarkeits-/Frustumberechnungen)

Lokal

Derzeit ein Sammelbegriff für Bezugssysteme, die nicht eines der oben erklärten sind. Im Allgemeinen die Positionierung relativ zu einem Objekt.

In LSL wird das lokale Bezugssystem auf zwei Arten genutzt:

Childprims

Childprims (nicht Rootprims) werden lokal zum Rootprim positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Rootprims beeinflusst.

Attachments

Objekte, die angezogen werden, werden lokal zum Tragepunkt positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Avatars und den abgespielten Animationen beeinflusst.

Namenskonventionen

ALLE Variablen/Klassenmitglieder, die mit Werten aus einem dieser Bezugssysteme zu tun haben, sollten in Namen nachgestellt das Bezugssystem haben, das verwendet wird. BITTE tun Sie das - es hilft großartig dabei, Fehler zu vermindern.

Zum Beispiel:

mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent

Konvertierungsfunktionen

In LLAgent und LLViewerRegion sind Konvertierungsfunktionen zur Umwandlung von einem Bezugssystem in ein anderes implemetiert. Sie haben eine Syntax der Form getPos<Ziel>From<Quelle>() - zum Beispiel konvertiert getPosAgentFromGlobal() vom globalen in das Agent Bezugssystem.

Typumwandlung

Um den sehr genauen globalen Koordinaten gerecht zu werden, gibt es die neue Klasse LLVector3d, der Name kommt von LLVector3, doppelte Genauigkeit. das ist zwar in gewisser Hinsicht nicht konsistent zur bisherigen Namensgebung, aber die einzige andere Alternative wäre es gewesen, ALLE mathematischen Klassen umzubenennen, um die aus GL kommende Typkonvention mit dem letzten Buchstaben zu verwenden, wozu ich nicht in der Lage gewesen wäre.

ALLE Berechnungen, die mit globalen Koordinateen durchgeführt werden, sollten unter der Verwendung von LLVector3d gemacht werden. Derzeit geben alle Funktionen, die globale Koordinaten als Rückgabewerte haben, diese im Typ LLVector3d zurück. Die momentan EINZIGE Ausnahme dazu ist Audio, bei dem ich die Werte in normale LLVector3 umwandle, bevor ich sie an die Audioengine übergebe - Ich denke, das wird auch so lange der Fall bleiben, bis wir die Audioengine dahingehend unstellen, daß sie Agentkoordinaten verwendet.

Die Klasse LLVector3d enthält ABSICHTLICH KEINERLEI Form einer automatischen Typumwandlung zwischen ihr und der Klasse LLVector3. Weil die Umwandlung hin und zurück nicht einfach ist (und wahrscheinlich auch zum Verlust von Genauigkeit führt), müssen Sie explizit einen setVec() zu der anderen Klasse setzen, um in die eine oder andere Richtung umzuwandeln.

@@ Line 13: / Line 13: @@
 === Agent ===
-Derzeit ist der Bezugspunkt der Ursprung der Region, in der sich der Agent momentan befindet.  DAS BEDEUTET NICHT UNBEDINGT, dass das auch in ZUkunft so sein wird.  This should be used only for code involving rendering (pipeline, visibility/frustum calculations)
+Derzeit ist der Bezugspunkt der Ursprung der Region, in der sich der Agent momentan befindet.  DAS BEDEUTET NICHT UNBEDINGT, dass das auch in Zukunft so sein wird.  Dieser Bezugspunkt sollte nur für Programmcode verwendet werden, der im Zusammenhang mit dem Rendering steht (Renderpipeline, Sichtbarkeits-/Frustumberechnungen)
-=== Local ===
+=== Lokal ===
-Currently a catch-all for coordinate frames which are not one of the ones above.  Generally object-relative positioning.
+Derzeit ein Sammelbegriff für Bezugssysteme, die nicht eines der oben erklärten sind.  Im Allgemeinen die Positionierung relativ zu einem Objekt.
-The local frame is used in two ways in LSL:
+In [[LSL]] wird das lokale Bezugssystem auf zwei Arten genutzt:
-:<h4> Child Prims </h4>
+:<h4> Childprims </h4>
-:Child prims (not root prims) are positioned local to the root prim; their global position and angle effected by both the root prims rotation and position.
+:Childprims (nicht Rootprims) werden lokal zum Rootprim positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Rootprims beeinflusst.
 :<h4> Attachments </h4>
-:Objects that are attached are positioned local to the attach point; their global position and angle are affected by the position and rotation of the avatar and the playing animations.
+:Objekte, die angezogen werden, werden lokal zum Tragepunkt positioniert; ihre globale Position und Winkel werden durch Beides, die Rotation und Position des Avatars und den abgespielten Animationen beeinflusst.
-= Naming conventions =
+= Namenskonventionen =
-ALL variables/class members dealing with values in one of these coordinate frames should be post-fixed appended with the coordinate frame that it's being used in.  PLEASE do this - it greatly reduces errors.
+ALLE Variablen/Klassenmitglieder, die mit Werten aus einem dieser Bezugssysteme zu tun haben, sollten in Namen nachgestellt das Bezugssystem haben, das verwendet wird. BITTE tun Sie das - es hilft großartig dabei, Fehler zu vermindern.
-For example:
+Zum Beispiel:
 <pre>
 mPositionGlobal, pos_global
@@ Line 34: / Line 34: @@
 </pre>
-= Conversion functions =
+= Konvertierungsfunktionen =
-In LLAgent and LLViewerRegion there are conversion functions for converting from one coordinate frame to the other.  They have syntax of the form getPos<target>From<source>() - i.e. getPosAgentFromGlobal() converts from the global coordinate frame to the agent coordinate frame.
+In LLAgent und LLViewerRegion sind Konvertierungsfunktionen zur Umwandlung von einem Bezugssystem in ein anderes implemetiert. Sie haben eine Syntax der Form getPos<Ziel>From<Quelle>() - zum Beispiel konvertiert getPosAgentFromGlobal() vom globalen in das Agent Bezugssystem.
+= Typumwandlung =
+Um den sehr genauen globalen Koordinaten gerecht zu werden, gibt es die neue Klasse LLVector3d, der Name kommt von LLVector3, doppelte Genauigkeit. das ist zwar in gewisser Hinsicht nicht konsistent zur bisherigen Namensgebung, aber die einzige andere Alternative wäre es gewesen, ALLE mathematischen Klassen umzubenennen, um die  aus GL kommende Typkonvention mit dem letzten Buchstaben zu verwenden, wozu ich nicht in der Lage gewesen wäre.
-= Type conversion =
+ALLE Berechnungen, die mit globalen Koordinateen durchgeführt werden, sollten unter der Verwendung von LLVector3d gemacht werden. Derzeit geben alle Funktionen, die globale Koordinaten als Rückgabewerte haben, diese im Typ LLVector3d zurück. Die momentan EINZIGE Ausnahme dazu ist Audio, bei dem ich die Werte in normale  LLVector3 umwandle, bevor ich sie an die Audioengine übergebe - Ich denke, das wird auch so lange der Fall bleiben, bis wir die Audioengine dahingehend unstellen, daß sie Agentkoordinaten verwendet.
-In order to support the high-precision global coordinates, there is a new class LLVector3d, standing for LLVector3, double precision.  It's somewhat inconsistent, but the only other alternative was renaming ALL of the math classes to use the GL style last-letter type convention, which I wasn't up to doing.
-ALL math being done in global coordinates should be done using LLVector3ds.  Currently, all functions which return global coordinates do so in LLVector3ds.  The ONLY current exception to this is audio, which I am converting to regular LLVector3s before handing them off to the audio engine - I guess this will be the case until we convert the audio engine to use agent coords.
+Die Klasse LLVector3d enthält ABSICHTLICH KEINERLEI Form einer automatischen Typumwandlung zwischen ihr und der Klasse LLVector3.  Weil die Umwandlung hin und zurück nicht einfach ist (und wahrscheinlich auch zum Verlust von Genauigkeit führt), müssen Sie explizit einen setVec() zu der anderen Klasse setzen, um in die eine oder andere Richtung umzuwandeln.
-The LLVector3d class DELIBERATELY does not have ANY form of automatic type-conversion between it and the LLVector3 class.  Since conversion back and forth isn't cheap (and potentially loses precision), you have to explicitly do a setVec() on the other class to convert back and forth.

Difference between revisions of "Koordinatenbezugssysteme im Viewer"