Difference between revisions of "Koordinatenbezugssysteme im Viewer"

From Second Life Wiki
Jump to: navigation, search
(Translation in progress)
(Region)
Line 10: Line 10:
  
 
=== Region ===
 
=== Region ===
Origin is the origin of the [[Land#Region|region]] which "owns" the object.
+
Der Ausgangspunkt ist der Ursprung der [[Land#Region|region]], die das Objekt "besitzt".
  
 
=== Agent ===
 
=== Agent ===

Revision as of 06:25, 20 July 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 Coder 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 ~109 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

Currently, the origin is the origin of the agent's current region. THIS DOES NOT necessarily have to be the case in the future. This should be used only for code involving rendering (pipeline, visibility/frustum calculations)

Local

Currently a catch-all for coordinate frames which are not one of the ones above. Generally object-relative positioning.

The local frame is used in two ways in LSL:

Child Prims

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.

Attachments

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.

Naming conventions

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.

For example:

mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent

Conversion functions

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

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

4cs, 6502acme, 6502kickass, 6502tasm, 68000devpac, abap, actionscript, actionscript3, ada, algol68, apache, applescript, apt_sources, arm, asm, asp, asymptote, autoconf, autohotkey, autoit, avisynth, awk, bascomavr, bash, basic4gl, bf, bibtex, blitzbasic, bnf, boo, c, c_loadrunner, c_mac, caddcl, cadlisp, cfdg, cfm, chaiscript, cil, clojure, cmake, cobol, coffeescript, cpp, cpp-qt, csharp, css, cuesheet, d, dcl, dcpu16, dcs, delphi, diff, div, dos, dot, e, ecmascript, eiffel, email, epc, erlang, euphoria, f1, falcon, fo, fortran, freebasic, freeswitch, fsharp, gambas, gdb, genero, genie, gettext, glsl, gml, gnuplot, go, groovy, gwbasic, haskell, haxe, hicest, hq9plus, html4strict, html5, icon, idl, ini, inno, intercal, io, j, java, java5, javascript, jquery, kixtart, klonec, klonecpp, latex, lb, ldif, lisp, llvm, locobasic, logtalk, lolcode, lotusformulas, lotusscript, lscript, lsl2, lua, m68k, magiksf, make, mapbasic, matlab, mirc, mmix, modula2, modula3, mpasm, mxml, mysql, nagios, netrexx, newlisp, nsis, oberon2, objc, objeck, ocaml, ocaml-brief, octave, oobas, oorexx, oracle11, oracle8, oxygene, oz, parasail, parigp, pascal, pcre, per, perl, perl6, pf, php, php-brief, pic16, pike, pixelbender, pli, plsql, postgresql, povray, powerbuilder, powershell, proftpd, progress, prolog, properties, providex, purebasic, pycon, pys60, python, q, qbasic, rails, rebol, reg, rexx, robots, rpmspec, rsplus, ruby, sas, scala, scheme, scilab, sdlbasic, smalltalk, smarty, spark, sparql, sql, stonescript, systemverilog, tcl, teraterm, text, thinbasic, tsql, typoscript, unicon, upc, urbi, uscript, vala, vb, vbnet, vedit, verilog, vhdl, vim, visualfoxpro, visualprolog, whitespace, whois, winbatch, xbasic, xml, xorg_conf, xpp, yaml, z80, zxbasic


() - i.e. getPosAgentFromGlobal() converts from the global coordinate frame to the agent coordinate frame.


= Type conversion =
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.


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.