Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 18:00

Foren-Übersicht » DGL » Feedback
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 19 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
BeitragVerfasst: So Aug 20, 2006 19:13 
Offline
DGL Member

Registriert: Do Mai 30, 2002 18:48
Beiträge: 1617
Ich habe heute folgende E-Mails erhalten, auf die ich gerne im Forum antworten möchte:

Zitat:
Hi Nico !

Ich hab Dein Tutorial zu LOD Terrain gelesen und auch das
Paper auf dem es aufbaut. In dem Paper steht das für effiziente
Berechnungen der Distanzen zwischen EyePoint und einer
QuadTree Node die L1-Norm verwendet wird ? =/

http://wwwvis.informatik.uni-stuttgart. ... ERRAIN.PDF

Irgendwie kann ich damit gar nix anfangen ;D Ich habe bisher
die Länge eines Vektors so berechnet :

Länge= Wurzel( x² + y² + z²)

Ich hab mal nach L1-Norm gegoogled, da kam irgendwie raus
das es was mit Imaginären Zahlen zu tun hat ? Mhm aber wie
ich jetzt solche L1-Normen konstruiere und damit rechne habe
ich nicht verstanden.

Kannst Du mir da weiterhelfen ? Ich hoffe es ist nicht so kompliziert
wie es sich anhört =D

Danke !!
Viele Grüße,
Christian


Zitat:
Sorry ich nochmal... ist das hier die L1 Norm ?
L1 = max(abs(vertx - viewx), abs(verty - viewy), abs(vertz - viewz));
Also einfach das Maximum der Differenzen in x, y und z Richtung ? :)
Gruß Christian


Antwort:
folgender Wikipedia-Artikel wird Dir helfen (beachte zuerst Abschnitt p-Normen):
http://de.wikipedia.org/wiki/Normierter_Raum#p-Normen

Daraus ergibt sich für die 1-Norm, daß du die Komponenten des Vertices Betragsweise addieren sollst:
v:= (x,y,z)
=> ||v||_1 = |x| + |y| + |z|

Der Abstand von 2 Punkten v_1, v_2 ist folglich:
dist(v_1,v_2) := ||v_1 - v_2|| = |x_1 - x_2| + |y_1 - y_2| + |z_1 - z_2|

Zum Thema l_p normen: Diese sind Sonderformen von Normen, die für Zahlenfolgen gedacht sind - auf unseren 3 Dimensionalen Raum zurückgezogen, setzt man einfach alle unnötigen Komponenten 0 und kommt wieder genau dort an, wie oben geschrieben - warum Roeder in seinem Artikel seine Normen mit einem l bezeichnet ist mir nach der üblichen Nomenklatur nicht klar - schlimmer noch: Er schreibt L_p normen, die für Funktionenräume gedacht sind - die also Abstände zwischen Funktionen berechnen. Ich bin sicher, daß Roeder p-Normen meint.

Anmerkung 1:
Die betreffende Stelle in Roeders Artikel ist die Stelle, an er er Abstände einsetzt, um die anzuzeigende Auflösung des Terrains berechnet ( Abschnitt 2.2 Generating the Triangulation ) - die Berechnung der Abstände kann durch geschickte Wahl einer Norm deutlich beschleunigt werden, weil keine Wurzelberechnung mehr nötig ist - trifft genau auf die 1-Norm und die unendlich-Norm zu - welche Christian in seiner 2. Mail anspricht. Die unendlich Norm führt aber sicherlich zu einem nicht für die visualisierung optimalen Ergebnis.

Anmerkung 2:
Roeders Algorithmus ist auf moderner Hardware nicht mehr State of The Art, ermöglicht es aber trotzdem große Landschaften mit brauchbaren Frameraten darzustellen. Ein weniger CPU lastiger, dafür stärker GPU lastiger Algorithmus wie ihn etwa Geometric Mipmapping richtig eingesetzt darstellt, ist auf moderner Hardware vorzuziehen. Dadurch wird Roetgers Algorithmus jedoch nicht schlechter, nur bremst er moderne GPUs etwas aus und die Zahl der darstellbaren Polygone nimmt ab - bei automatischer Detailanpassung im Roetger-Algorithmus ist das äquivaltent mit einem Detailverlust in der Anzeige (wird wahrscheinlich eh keiner merken, wenn man Geomorphing einsetzt ;-) ).


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Aug 23, 2006 18:01 
Offline
DGL Member

Registriert: Do Mai 30, 2002 18:48
Beiträge: 1617
Und auf ein neues:
Zitat:
Hi Nico !

Ich bins nochmal ;D

Warum wird denn bei der Berechnung der d2 Werte zweimal ein
"Höhendifferenz-Wert" für das Zentrum einer Node berechnet ?

Ich meine mir ist zwar klar das die Werte, die ich erhalte wenn ich
für je zwei gegenüberliegenden Ecken den Durchschnittswert bilde,
unterschiedlich sind.

Aber das ändert ja nichts daran das das Zentrum der Subnode
in der Realität trotzdem nur eine Höhendifferenz zum Parent hat.
Es gibt doch also faktisch im Zentrum auch nur einen Höhenunterschied.

Die eine Kante des Parents von dem im Paper der zweite Höhenwert
berechnet wird ist doch gar nicht vorhanden. Es gibt doch nur die
Kante vom Parent-Zentrum zum Parent-Corner.

Ich finde es voll komisch (*g*) das da noch eine imaginäre Kante von
einem Parent Edge-Mittelpunkt zu einem anderen Edge-Mittelpunkt
erfunden wird dessen Gerademittelpunkt-Höhe dann plötzlich als
6. Wert genommen wird der mit der Subnode Zentrumshöhe
verglichen wird.

*confused* =[

Ich hoffe Du kannst mich aufklären :)
Und ich hoffe meine komischen Wortkreationen sind verständlich ;D

1000 Dank ! Viele Grüße,
Christian


Antwort:

Hi,
es wäre gut, wenn du deine Fragen direkt ins Forum stellen würdest,
damit auch andere das sich ggf. durchlesen können. Diesmal werde ich
deine Frage nocheinmal an den letzten Thread anhängen, aber es wäre
wirklich besser, wenn Du dich im Forum anmelden würdest und wir das
nicht per E-Mail klären.

Du beziehst dich offensichtlich auf dieses Bild?
http://wiki.delphigl.com/index.php/Bild ... values.jpg

Ja Du hast nicht ganz Unrecht, aber die Berechnung der D2 Werte wird
deutlich einfacher, denn ich muss nicht beachten, ob in geringerer
Auflösung der Schnitt von Schräg nach rechts unten oder schräg nach
links unten verläuft (eigentlich könnte man das auch sehr leicht, weil
man ja rekursiv arbeitet und man dann die passende erwartete Höhe
einfach durchreichen kann). Ich denke trotzdem, daß sich die Anzahl
der zuviel angezeigten Polygone auch in starken Grenzen halten wird,
wenn man hier zuviele Dh Werte berechnet - sprich: rechne mit 5 Werten
wenn du magst, rechne mit 6 wenn Du dich an das Original halten willst
;-)
Schöne Grüße
Nico


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Aug 26, 2006 20:59 
Offline
DGL Member

Registriert: Sa Aug 26, 2006 18:26
Beiträge: 8
Ok eine weitere Frage ^^ :D

Ist das korrekt wenn da steht ein Triangle fan wird nur
am Ende bzw. Blatt des Quadtrees gerendert ? Ich würde
sagen nein, weil das obere linke Viertel hier zum Beispiel...
Bild
Bild
...nicht von einem Blatt gerendert wird sondern von einem
Node der 3 Subnodes hat.

Müßte es nicht korrekt so formuliert sein (wenn auch nicht schön):
Beim rekursiven traversieren des Baumes schaut man bei jedem
Node nach ob er Subnodes hat. Da wo er keine hat rendert man
den groben Triangle-Fan (bzw. nur einen Teil des Fans, in dem
Bild oben nur das obere linke Viertel). Da wo er welche hat geht
man den Baum weiter runter wo dann später verfeinert gerendert wird.

Ist das so richtig ? ^^ :roll: :?: :)

Viele Grüße,
Christian


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Aug 26, 2006 21:33 
Offline
DGL Member

Registriert: Do Mai 30, 2002 18:48
Beiträge: 1617
Ja, so ist das zu verstehen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Sep 02, 2006 17:27 
Offline
DGL Member

Registriert: Sa Aug 26, 2006 18:26
Beiträge: 8
Also so langsam nimmt das Terrain bei mir Gestalt an ;D

Das mit den cracks vermeiden klingt eigentlich auch nicht
so schwer, aber in dem ursprünglichen paper...
http://wwwvis.informatik.uni-stuttgart.de/~roettger/data/Papers/TERRAIN.PDF
...klingt es irgendwie komplizierter =/

Erstmal eine lange Einleitung mit Condition (4) und (5) und
dann steht da noch das die d2 values nur angepaßt werden
wenn d2_1/d2_2 <= K :? :?:

Kann mir das jemand genauer erklären worum es da geht
(mir fällt es etwas schwer die Herleitung jetzt nachzuvollziehen)
und wieso von dieser Formel und dem K z.B. nichts in dem
Tutorial hier auf DelphiGL erwähnt wurde ? :)

Ich würd gern verstehen was da abgeht, Condition (1),
(2) und (3) habe ich noch verstanden. Condition (4)
eigentlich auch aber danach hörts irgendwie auf bei
dem Text rund um Condition (5) :oops:

Danke !!


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Sep 02, 2006 18:58 
Offline
DGL Member

Registriert: Do Mai 30, 2002 18:48
Beiträge: 1617
weil er das K als L1/(2*L2)=C/(2*(C-1)) definiert hat und er das K nur als schreibweise einsetzt, steht davon nichts im tutorial. Wie das jetzt genau läuft und warum man gerade die 5. Bedingung braucht kann ich mom. nicht erklären, dafür müsste ich mich nochmal weiter einlesen und das ist nichts mehr, was ich heute abend machen möchte. wenn dir das lichtlein nicht noch aufgeht, kann ichs mir gerne nocheinmal wann anders ansehen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Sep 02, 2006 19:20 
Offline
DGL Member

Registriert: Sa Aug 26, 2006 18:26
Beiträge: 8
Zitat:
wenn dir das lichtlein nicht noch aufgeht, kann ichs mir gerne nocheinmal wann anders ansehen.


Mhm ja also bisher ist mir noch kein Licht aufgegangen wie er
jetzt mit Condition (4) + (5) etc darauf kommt das man einfach
nur die d2 values mit maximum bildung nach oben propagiert =[

Also würd mich freuen wenn das nochmal genauer erklärt werden
könnte :) In dem Paper ist es irgendwie (im Gegensatz zu dem
Rest) etwas kompliziert erklärt hab ich den Eindruck.

Eilt aber nicht, ich kanns ja erstmal einfach so hinnehmen und
coden und dann später hoffentlich verstehen ;D


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Sep 06, 2006 13:56 
Offline
DGL Member

Registriert: Sa Aug 26, 2006 18:26
Beiträge: 8
Mhm also irgendwie versteh ich nicht warum im Tutorial Code
bei DoCrackAvoid am Ende von 9 d2 Werten das Maximum
gebildet wird. Im Originalpaper steht nämlich das von den d2
Werten der benachbarten Nodes ein Level tiefer plus dem
lokalen d2 Wert das Maximum gebildet werden soll. Das macht
für mich 5 d2 Werte denn ein level tiefer hab ich ja nur 4 nodes :?: :roll:

Also so wie es im Paper formuliert ist, wird in jeder node
die kein blatt ist von den 4 kindernodes die d2 werte geholt.
Oder ist mein Englisch so schlecht ;D

Zitat:
"The d2-value of each block is the maxium of the local value
and K times the previously calculated values of adjacent blocks
at the next lower level."


In Figure 7 ist das auch nur mit 4 childnodes dargestellt =/
Oder bezieht sich das adjacent NICHT auf die nodes ein level
tiefer sondern auf das aktuelle level wo man ist ?
So wie es da steht mit dem Zusatz "at the next lower level"
würde ich es so verstehen das es sich auf die 4 kinder ein
level tiefer bezieht.

oh man das ist so verwirrend ;D Hilfeeeeee !!
Was ich auch nicht verstehe ist wieso im Tutorial Code das K
an die d2 werte multipliziert wird. Im Paper steht das K in
dem Zusammenhang das die d2 werte nur angepaßt werden
sollen wenn d2_1/d2_2 <= K. Hat das damit was zu tun ?
Wenn ja, wieso multipliziert man deswegen das K an jedes
d2 value ?

oh man so langsam wirds irgendwie doch etwas verwirrend alles,
sorry ich hoffe ich nerve nicht aber ich wills doch blos verstehen =D

Danke !!! :)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Sep 06, 2006 14:40 
Offline
DGL Member

Registriert: Sa Aug 26, 2006 18:26
Beiträge: 8
Also ich glaub so ist es gemeint, oder ?
Das würde dann auch den Tutorial Code mit 8 nachbarn erklären :

Bild

Von dem großen Block mit dem gelben Punkt in der Mitte
und dem dicksten schwarzen Rand sind dann z.B. nicht
die 4 (für sich benachbarten) Kinder eine Stufe tiefer
relevant sondern die an den großen block benachbarten
blöcke ein Level tiefer (aber mit ein level tiefer sind halt
nicht die Kinder ein level tiefer gemeint).

Ist das so korrekt ? Ich finds etwas unglücklich im originalen
Paper formuliert, oder ich bin eifnach zu blöd *g* aber ich
finde man könnte es so und so verstehen =/

Na ja egal, also wenn es so richtig jetzt ist (?) dann
hab ich das zumindest kapiert. Bleibt dann nur noch die
Sache mit dem ranmultiplizierten K :?: :?

Im Originalpaper steht auch noch was von wegen das ganze
würde bisher nur für den 2D case betrachtet worden sein,
könnte aber auch leicht für 3D erweitert werden. Mehr und
vor allem was denn noch getan werden muß wird dazu aber
nicht geschrieben =[ Ich weiß gar nicht was das jetzt bedeutet,
das man (mal abgesehen von geomorphing später) noch nicht
fertig ist und noch irgendwas anders machen muß ? Oder
weiß jemand wie man diesen letzten Teil verstehen soll ? :

Zitat:
So far, we have only considered the 2D case, but with
some care we can adopt it for 3D. In this case, the elevation
of the view point needs to be taken into account
relative to the center of quadtree cells. However, since
height fields usually have small elevation compared to
their size, this distance can be approximated by the
difference between the elevation of the view point and
the average elevation of the quadtree nodes.
An example of the influence of the propagation of d2-
values throughout the height field, and its impact on
the triangulation is given in Figure 8. Here a few small
peaks are placed on an otherwise flat surface.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Sep 06, 2006 15:07 
Offline
DGL Member

Registriert: Do Mai 30, 2002 18:48
Beiträge: 1617
irendwie scheinst du durcheinanderzukommen. ein level tiefer bedeutet im baum eine rekursionsstufe tiefer, also höhere Auflösung.
so. nun hat jede node erstmal 4 nachbarn:
Code:
  1. -1-
  2. 2N3
  3. -4-

Die - liegen nicht nebenan und bei Cracks im Mesh sind sie auch nie beteiligt, wie man sich leicht überlegt. Cracks entstehen nur, wenn die nachbarn eine zu hohe auflösung anzeigen - genau dann wenn die Kinder der Nachbarn noch unterteilen. Also ist für die Betrachtung der Zustand der Kinder unserer Nachbarn interessant - davon gibt es acht:
Code:
  1. --uu--
  2. --12--
  3. u3NN4u
  4. u5NN6u
  5. --78--
  6. --uu--

Also das Bild zeigt eine Stufe tiefer im Baum die nachbarn von oben. die u markierten Quads sind uninteressant, weil nicht anliegend. Die anderen sind die beschriebenen nachbarn ("adjacent blocks at the next lower level" = die an den kanten liegenden Blöcke der nächst tieferen (Rekursions)Ebene).

*Eigenen Tutorialcode anschau... Ja hab ich damals genauso verstanden*
So dann schauen wir mal auf Fig. 7... Tja... äh... keine Ahnung. Verwirrung. Es treffen den mittleren Knoten der da wohl betrachtet ist jedenfalls 8 Pfeile, aber mich verwirrt dieses Bild etwas. Für mich passt das Bild nicht so ganz zu seiner Beschreibung.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Sep 06, 2006 15:16 
Offline
DGL Member

Registriert: Do Mai 30, 2002 18:48
Beiträge: 1617
der 2D Case ist wie folgt zu verstehen: er geht bei seinen ganzen gerechne davon aus, daß die landschaft flach ist und die kamera auch mittendrin ist und er dann die abstände zur kamera in dieser ebene berechnet. ich hab damals daran imho keine zeit verschwendet und die kamera einfach auf diese flache ebene runterprojeziert und dann die abstände in dieser Ebene normal berechnet... (Hab das jetzt im Code nicht nachgeprüft ) Für den Anfang kann man das aber in jedem Fall so lassen wie es ist - man muss nur bedenken, daß man die Abstände immer durchgehend mit der sleben Norm berechnen sollte und sie nicht ändert - was uns zur allerersten Frage zurückbringt.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Sep 06, 2006 16:11 
Offline
DGL Member

Registriert: Sa Aug 26, 2006 18:26
Beiträge: 8
Zitat:
Code:
  1. --uu--
  2. --12--
  3. u3NN4u
  4. u5NN6u
  5. --78--
  6. --uu--


Ja danke :D Das ja genau das was ich etwas weiter oben in dem png bild
auch aufgepixelt habe ^^ Gut dann weiß ich jetzt das ich es nachträglich
noch richtig kapiert hab *gg* thx !

Zitat:
So dann schauen wir mal auf Fig. 7... Tja... äh... keine Ahnung. Verwirrung. Es treffen den mittleren Knoten der da wohl betrachtet ist jedenfalls 8 Pfeile, aber mich verwirrt dieses Bild etwas. Für mich passt das Bild nicht so ganz zu seiner Beschreibung

Ja dieses Bild hat mich auch komplett verwirrt, das hat auch
irgendwie dazu beigetragen das ich dachte mit next lower level
meint er die 4 kinder und DIE sind ja auch adjacent...
na ja drauf geschissen :)



Zitat:
der 2D Case ist wie folgt zu verstehen: er geht bei seinen ganzen gerechne davon aus, daß die landschaft flach ist und die kamera auch mittendrin ist und er dann die abstände zur kamera in dieser ebene berechnet. ich hab damals daran imho keine zeit verschwendet und die kamera einfach auf diese flache ebene runterprojeziert und dann die abstände in dieser Ebene normal berechnet... (Hab das jetzt im Code nicht nachgeprüft ) Für den Anfang kann man das aber in jedem Fall so lassen wie es ist - man muss nur bedenken, daß man die Abstände immer durchgehend mit der sleben Norm berechnen sollte und sie nicht ändert - was uns zur allerersten Frage zurückbringt.


Mhm achso...also d.h. nur das man eigentlich seine Distanz-Funktion (momentan
benutze ich ja die L1 Norm, wie Du schon sagst siehe allererste Frage) noch
anpassen müßte ? Frage1: Aber die L1 Norm berücksichtig doch eigentlich auch den
Höhenabstand zu einer Node.. =/ Darum frag ich, versteh nicht warum er also
sagt das "the elevation of the viewpoint" bisher nicht eingeflossen ist :?:

Frage2: Hast Du die Camera damals einfach imaginär auf die kleinste Höhe der Heightmap
runtergesetzt und X,Z der Camera so gelassen oder hast Du Dir vorher den Durchschnitt
aller Höhenpunkte berechnet und dann als Eyepoint
(CameraX, DurchschnittshöheDerHeightmapVertices, CameraZ)
verwendet ?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Sep 06, 2006 16:30 
Offline
DGL Member

Registriert: Do Mai 30, 2002 18:48
Beiträge: 1617
nein, wenn ich mich recht erinnere müsste es zum abstand berechnen so gehandhabt sein, daß alles auf höhe null liegt - die nodes haben also nur x,z position, genauso wie die kamera nur x,z hat und die höhe geht einfach NICHT in die abstandsberechnung ein...
aber wenn du die 1-norm benutzt, dann ist alles wunderbar, dann brauchst du auch nichts daran zu ändern.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Sep 06, 2006 16:47 
Offline
DGL Member

Registriert: Sa Aug 26, 2006 18:26
Beiträge: 8
Zitat:
aber wenn du die 1-norm benutzt, dann ist alles wunderbar, dann brauchst du auch nichts daran zu ändern.


Das ist ja gerade was mich wundert, denn er benutzt ja auch
die L1 Norm, ziemlich am Anfang schreibt er ja :
Zitat:
In order to allow for efficient computations, distance
measurement is performed using the L1-norm.


Wenn er also auch die L1 Norm benutzt, muß er doch eigentlich
schon die ganze Zeit mit x,y,z gerechnet haben ? :?: Oder hat er
da von der L1 Norm für den 2D Fall gesprochen ?

Irgendwie merkwürdig... =/


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Sep 08, 2006 19:22 
Offline
DGL Member

Registriert: Sa Aug 26, 2006 18:26
Beiträge: 8
Zitat:
irendwie scheinst du durcheinanderzukommen. ein level tiefer bedeutet im baum eine rekursionsstufe tiefer, also höhere Auflösung.
so. nun hat jede node erstmal 4 nachbarn:
Code:
  1. -1-
  2. 2N3
  3. -4-

Die - liegen nicht nebenan und bei Cracks im Mesh sind sie auch nie beteiligt, wie man sich leicht überlegt. Cracks entstehen nur, wenn die nachbarn eine zu hohe auflösung anzeigen - genau dann wenn die Kinder der Nachbarn noch unterteilen. Also ist für die Betrachtung der Zustand der Kinder unserer Nachbarn interessant - davon gibt es acht:
Code:
  1. --uu--
  2. --12--
  3. u3NN4u
  4. u5NN6u
  5. --78--
  6. --uu--

Also das Bild zeigt eine Stufe tiefer im Baum die nachbarn von oben. die u markierten Quads sind uninteressant, weil nicht anliegend. Die anderen sind die beschriebenen nachbarn ("adjacent blocks at the next lower level" = die an den kanten liegenden Blöcke der nächst tieferen (Rekursions)Ebene).

*Eigenen Tutorialcode anschau... Ja hab ich damals genauso verstanden*
So dann schauen wir mal auf Fig. 7... Tja... äh... keine Ahnung. Verwirrung. Es treffen den mittleren Knoten der da wohl betrachtet ist jedenfalls 8 Pfeile, aber mich verwirrt dieses Bild etwas. Für mich passt das Bild nicht so ganz zu seiner Beschreibung.


So ich hab jetzt nochmal Stefan Roettger per email gefragt wie das
zu verstehen ist und als Antwort habe ich bekommen das weder
Deine Version noch meine Version richtig ist *g*

Deine produziert aber dennoch ein lückenloses Gitter, sei aber
nicht wirklich optimal. Und so wie er es beschrieben hat, paßt
es dann auch mit Figure 7 :wink:

So ist es korrekt laut Stefan Roettger:
"...man braucht nicht 8 sondern nur 4 Knoten (siehe auch Original-Code
auf stereofx.org). Man braucht alle 4 Kinder des Vaterknotens..."


Und dann hab ich ihn auch noch gefragt wegen der L1 Norm und
seine Antwort auf...
Schnulla hat geschrieben:
Zitat:
aber wenn du die 1-norm benutzt, dann ist alles wunderbar, dann brauchst du auch nichts daran zu ändern.


Das ist ja gerade was mich wundert, denn er benutzt ja auch
die L1 Norm, ziemlich am Anfang schreibt er ja :
Zitat:
In order to allow for efficient computations, distance
measurement is performed using the L1-norm.


Wenn er also auch die L1 Norm benutzt, muß er doch eigentlich
schon die ganze Zeit mit x,y,z gerechnet haben ? :?: Oder hat er
da von der L1 Norm für den 2D Fall gesprochen ?

Irgendwie merkwürdig... =/

...war:
"An dieser Stelle im Text ist die 2D L1 Norm gemeint"

So damit sollten die zwei Sachen geklärt sein ;D :)


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 19 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » DGL » Feedback


Wer ist online?

Mitglieder in diesem Forum: Google [Bot] und 11 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.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.052s | 19 Queries | GZIP : On ]