# Arbeitspaket 4a (Eingabe / Ausgabe)
Im 5. Praxisquartal wurden offene Problemstellungen bearbeitet, die während der vorherige Implementation entstanden sind.
Es wurde ein Problem bei der Koordinatenkonvertierung entdeckt, die eingegeben Werte stimmten am Schluss nicht mehr mit den konvertierten Daten über ein.
Des Weiteren wurde nach einer Alternative zu UV-Maps geforscht.

## Inhaltsverzeichnis
1. [Korrektur der Koordinatenkonvertierung](#Korrektur-der-Koordinatenkonvertierung)
1.1 [Problematik bei der bisherigen Koordinatenkonvertierung](#Problematik-bei-der-bisherigen-Koordinatenkonvertierung)
1.2 [Lösung zur Problematik der Koordinatenkonvertierung](#Lösung-zur-Problematik-der-Koordinatenkonvertierung)
2. [Decals als Alternative zu UV-Maps](#Decals-als-Alternative-zu-UV-Maps)
2.1 [Was sind Decals](#Was-sind-Decals)
2.2 [Wie funktionieren Decals](#Wie-funktionieren-Decals)
2.3 [Sind Decals eine mögliche Alternative zu UV-Maps](#Sind-Decals-eine-mögliche-Alternative-zu-UV-Maps)
2.4 [Welche Möglichkeiten bestehen, um mit Decals Striche zu ziehen](#Welche-Möglichkeiten-bestehen-um-mit-Decals-Striche-zu-ziehen)
3. [Refaktorisierung Bladder.jsx](#Refaktorisierung-der-Bladderjsx)
3.1 [Konvertierung in .tsx](#Konvertierung-in-tsx)
3.2 [Auslagern von Komponenten](#Auslagern-von-Komponenten)
4. [Bestehende Problematiken und Konzeptideen für die Harnröhre](#Bestehende-Problematiken-und-Konzeptideen-für-die-Harnröhre)
4.1 [Implementierung der Kugelkoordinaten dem Konzept nach anpassen](#Implementierung-der-Kugelkoordinaten-dem-Konzept-nach-anpassen)
4.2 [Zeichnen in der Harnröhre](#Zeichnen-in-der-Harnröhre)
6. [Einheitenfehler bei der Strichstärke von eingezeichneten Flächen](#Einheitenfehler-bei-der-Strichstärke-von-eingezeichneten-Flächen)
## Korrektur der Koordinatenkonvertierung
### Problematik bei der bisherigen Koordinatenkonvertierung
Nach dem Exportieren und Importieren von Blasenpositionen / Koordinaten kam es zu deutlichen Abweichungen, welche sich auf die fehlerhafte Umrechnungen zurückführen lassen.
Zunächst wurde vermutet, dass die Berechnung der kartesischen Koordinaten zu Kugelkoordianten korrekt sei und der Fehler in der Rückrichtung läge. Nach einiger Nachforschung und Überprüfung hat sich herausgestellt, dass bereits die erste Berechnung fehlerhaft war.

<table>
<tr>
<td>
<img src="https://fhdwdev.ha.bib.de/gitea/attachments/6c90d2e8-e52e-48c3-b3de-53c763c3b8cc" alt="drawing" width="400px"/>
</td>
<td>
<img src="https://fhdwdev.ha.bib.de/gitea/attachments/4b3acd97-52e9-45a0-9e00-9add0be5a995" alt="drawing" width="400px"/>
</td>
</tr>
</table>

Des Weiteren hat sich unsere Konvention der Blasenposition (Winkel, Tiefe) als eine Komplikation herausgestellt, da sich diese zwar sehr an der Kugelkoordinaten-Darstellung orientiert, allerdings nicht vollständig äquivalent ist. Der Unterschied liegt in der Zählrichtung des Polarwinkels und der Blasentiefe. Bei den Kugelkoordinaten wird dabei von oben (0°) nach unten (180°) gezählt, die Zählrichtung der Blasenposition hingegen verläuft genau entgegengesetzt (unten = 0°, oben = 180°).

Eine zusätzliche Abweichung unseres Projektes gegenüber der mathematischen Konventionen ist die Darstellung von kartesischen Koordinaten. Der Grund dafür lässt sich auf THREEJS zurückführen. Dort werden die Y- und Z-Werte gegenüber der mathematischen Darstellung vertauscht. Mathematische Punkte (X | Y | Z) entspricht in ThreeJS (X | Z | Y). Dies stellte kein größeres Problem bei der Konvertierung von kartesischen Koordinaten in Blasenpositionen dar. Es musste jedoch darauf geachtet werden, keine Flüchtigkeitsfehler beim Implementieren der Formeln zu machen. Außerdem musste dies als mögliche Fehlerquelle beim Debugging betrachtet werden.

### Lösung zur Problematik der Koordinatenkonvertierung
Die ursprünglich Fehlerquelle wurde bei der Konvertierung von Kugelkoordinaten zu Kartesischen vermutet, sodass wir diese an die von [StudyFlix](https://studyflix.de/mathematik/kugelkoordinaten-1519) angegebenen Formeln angeglichen haben.

**Vorher:**

const x = this.unsignZero(this.round(-Math.cos(azimuth)));
const y = this.unsignZero(this.round(-Math.cos(polar)));
const z = this.unsignZero(this.round(-Math.sin(azimuth)));

**Nachher:**

const x = this.unsignZero(Math.sin(polar) * Math.cos(azimuth));
const y = this.unsignZero(-Math.cos(polar));
const z = this.unsignZero(Math.sin(polar) * Math.sin(azimuth));

Die `unsignZero()`-Methode wird aufgerufen, da in JavaScript zwischen `0` und `-0` unterschieden wird, sodass es bei Berechnungen unteranderem zu unerwarteten Ergebnissen kam, wenn mit `-0` gerechnet wurde.

Nachdem wir die Konvertierung in diese Richtung angepasst hatten, kam es trotzdem noch zu fehlerhaften Konvertierungen. Daher haben wir die Konvertierung von kartesischen Koordinaten in Kugelkoordinaten genauer betrachtet und diese ebenfalls an die Formeln von [StudyFlix](https://studyflix.de/mathematik/kugelkoordinaten-1519) angepasst. Dabei musste lediglich die Berechnung des Azimut-Winkels bzw. Winkel der Blasenposition überarbeitet werden.

**Vorher:**

const azimuth = (): number => {
  // Center Top or Center Bottom
  if (coord.y / r === 1 || coord.y / r === -1) {
    return 0;
  }

  // Anywhere else on the Bladder
  if (coord.z <= 0) {
    return ((-Math.PI / 2) * coord.x) / r + Math.PI / 2; // -90° * x / r + 90°
  } else if (coord.z > 0 && coord.x <= 0) {
    return ((Math.PI / 2) * coord.z) / r + Math.PI; // 90° * z / r + 180°
  } else {
    return ((Math.PI / 2) * coord.x) / r + (3 / 2) * Math.PI; // 90° * x / r + 270°
  }
};

**Nachher:**

const x = CoordinateConverter.unsignZero(coord.x);
const y = CoordinateConverter.unsignZero(coord.y);
const z = CoordinateConverter.unsignZero(coord.z);

const azimuth = (): number => {
  // Center Top or Center Bottom
  if (y / r === 1 || y / r === -1) {
    return 0;
  }

  // Anywhere else on the Bladder
  if (x === 0 && z > 0) {
    return 90;
  } else if (x === 0 && z < 0) {
    return 270;
  }
  
  if (x > 0 && z >= 0) {
    return Math.atan(z / x);
  } else if (x > 0 && z < 0) {
    return Math.atan(z / x) + 2 * Math.PI;
  } else if (x < 0) {
    return Math.atan(z / x) + Math.PI;
  } else {
    throw coord;
  }
};

Die <strong>oberste If-Abfrage</strong> dient zum Prüfen, ob der Punkt sich exakt auf dem höchsten oder tiefsten Punkt der Kugel befindet. In diesem Fall spielt die Ausrichtung des Azimut-Winkels keine Rolle und wird von uns daher auf `0°` gesetzt und zurückgeliefert.

// Center Top or Center Bottom
if (y / r === 1 || y / r === -1) {
    return 0;
}

Die <strong>erste If-Else Verzweigung</strong> prüft, ob der Punkt sich an einer Position mit eine X-Wert von `0` befindet. Sollte dies der Fall sein, dann ist der Azimutwinkel abhängig vom Vorzeichen des Z-Wertes entweder `90°` oder `270°`. Diese If-Else Verzweigung muss nur durchgeführt werden, da die Formeln von [StudyFlix](https://studyflix.de/mathematik/kugelkoordinaten-1519) mit dem X-Wert dividieren und es somit zu Divisionen durch `0` kommen kann.

if (x === 0 && z > 0) {
    return 90;
} else if (x === 0 && z < 0) {
    return 270;
}

Die <strong>zweite If-Else Verzweigung</strong> ist abschließend die Implementierung der von [StudyFlix](https://studyflix.de/mathematik/kugelkoordinaten-1519) aufgelisteten Formeln.

if (x > 0 && z >= 0) {
    return Math.atan(z / x);
} else if (x > 0 && z < 0) {
    return Math.atan(z / x) + 2 * Math.PI;
} else if (x < 0) {
    return Math.atan(z / x) + Math.PI;
} else {
    throw coord;
}

## Decals als Alternative zu UV-Maps
### Was sind Decals
Decals (deutsch: "Aufkleber, Abziehbilder") stellen eine mögliche Alternative zu dem aktuellen Vorgehen des direkten Zeichnens auf der Textur des Blasenmodells über die UV-Map dar. Mit Decals wird nicht mehr auf der Textur des Modells gezeichnet, sondern ein separates [`Mesh`](https://threejs.org/docs/index.html?q=mesh#api/en/objects/Mesh) erzeugt, das sich über das Mesh des Blasenmodells legt. Diese Technologie ist vergleichbar mit dem Aufkleben eines Abziehbildes auf einem Objekt.

### Wie funktionieren Decals
Um ein Decal zu erstellen, wird ein Quader an einer beliebigen Position von beliebiger Größe generiert. Anschließend werden alle Ecken (`Vertices`) des Meshes des Quaders geprüft, ob diese das Mesh des Blasenmodells schneiden. Alle Ecken, die keine Überschneidung mit dem Blasenmodell aufweisen, werden verworfen, währenddessen die restlichen Ecken als separates Mesh überbleiben. Diesem Mesh kann dann eine eigene Textur zugewiesen werden.

|  |  |  |
| -------- | -------- | -------- |
| 1. Zeichnen des Quaders | 2. Schnitte der Meshes bestimmen | 3. Textur hinzufügen |

### Sind Decals eine mögliche Alternative zu UV-Maps
Mit dieser Technik können ohne größeren Aufwand dank der von [ThreeJS](https://threejs.org/) zu Verfügung gestellten [`DecalGeometry`](https://threejs.org/docs/index.html?q=decal#examples/en/geometries/DecalGeometry), Texturen exakt auf dem Blasenmodell platziert werden. Dies bietet gegenüber dem direkten Zeichnen auf der Textur des Blasenmodells den Vorteil, dass die UV-Map vollkommen vernachlässigt werden kann. Somit würden alle Komplikationen mit der UV-Map, die sich während der Entwicklung aufgezeigt haben, vermeiden lassen.

Unteranderem würde somit das Krümmen von längeren Strichen sowie die Verzerrung an dichteren Stellen der UV-Map, wie z.B. am Blasenhals oder am Blasendom, vollkommen umgangen werden können.

| <img alt="Krümmung einer längeren Linie" src="https://fhdwdev.ha.bib.de/gitea/attachments/94440d3c-903b-4fa3-b460-457190c4e9c8" height="300px"/>| <img alt="Verzerrung der Linie an Stellen mit höherer Dichte" src="https://fhdwdev.ha.bib.de/gitea/attachments/c6e6d20e-cab7-4d84-ae03-fbf77208e8bc" height="300px"/>|
| -------- | -------- |
| Krümmung einer längeren Linie | Verzerrung der Linie an Stellen mit höherer Dichte |

### Welche Möglichkeiten bestehen, um mit Decals Striche zu ziehen
Wie in den obigen Bilder zu sehen ist, haben wir bereits eine Implementierung für das Platzieren einzelner Decals umgesetzt. Nun ist es notwendig, eine Möglichkeit zu finden, Linien in das Blasenmodell einzuzeichen. Dadurch könnte das aktuelle Vorgehen, das Zeichnen auf der Textur, abgelöst werden.

#### Möglichkeit 1 - Generieren eines Verbindungs-Decals
Eine Möglichkeit mit der Verwendung von Decals Linien in das Blasenmodell einzuzeichnen, ist das Erstellen eines Quaders, der vom Ausgangs- bis zum Endpunkt verläuft. Allerdings ist dieses Vorgehen mit den von [Three](https://threejs.org) zur Verfügung gestellten [`THREE.DecalGeometry`](https://threejs.org/docs/index.html?q=decal#examples/en/geometries/DecalGeometry) mit einem erhöhten Programmieraufwand verbunden. Ein Ansatz dies zu realisieren ist durch das Erzeugen eines Quaders, der mindestens zwei fixe Dimensionen (Breite, Höhe, Tiefe) und eine variable Dimension besitzt, die den Abstand vom Ausgangs- bis zum Endpunkt entspricht. Dieser muss zwischen den beiden Punkten positioniert werden. Anschließend muss der Quader so rotiert werden, dass er die beiden Punkte miteinander verbindet.

**Beispiel:**
Dieses Beispiel zeigt anhand von Skizzen den Kerngedanken dieses Verfahrens im zweidimensionalen Raum.

Werden zwei Punkte bzw. Decals in das Modell gezeichnet, so wird der Quader des verbindenden Decals genau in der Mitte der beiden Punkte gezeichnet. Dieser Quader hat in diesem Beispiel die Breite und Tiefe als fixe Werte und die Höhe entsprechend dem Abstand der beiden Punkte.

| <img alt="Striche zeichnen mit Decals" src="https://fhdwdev.ha.bib.de/gitea/attachments/ce12b04e-ed58-43ac-a325-46b011017bd4" height="300px"/> | <img alt="Striche zeichnen mit Decals" src="https://fhdwdev.ha.bib.de/gitea/attachments/ca0d94ec-1655-4518-a69f-97ba487a5df7" height="250px"/> |
| -------- | -------- |
| Quader im Mittelpunkt beider Punkte | Quader rotiert um beide Punkte zu verbinden |

#### Möglichkeit 2 - Zeichnen vieler Decals als Verbindung
Eine weitere Möglichkeit Striche mithilfe von Decals zu zeichnen orientiert sich am Zeichnen mit einem Stift auf einem Blatt Papier.
Bei diesem Vorgehen werden die zwei zu verbindenden Decals durch weitere Dicht beieinander liegende Decals miteinander verbunden. Um dies zu erreichen kann mittels Einsatz von RayCasting ([`THREE.RayCaster`]([https:/](https://threejs.org/docs/index.html?q=Raycaster#api/en/core/Raycaster)/)) das Einzeichnen weiterer Punkte simuliert werden und somit eine zur Stift und Papier analoge durchgehende Bewegung abgebildet werden.

**Potentielles Risiko:**
Dieses Verfahren kann mit einem vergleichsweisen geringen Programmieraufwand umgesetzt werden, indem in einem kleinen fixen Intervall zwischen Anfangs- und Endpunkt weitere Decals positioniert werden. Jedoch kann dies potenziell dazu führen, dass die Performanz des Programms darunter leidet. Dieses Vorgehen Bedarf daher eine sorgfältige Untersuchung, Prüfung und Evaluierung effektiv genutzt zu werden.

| <img alt="Initiale Punkte" src="https://fhdwdev.ha.bib.de/gitea/attachments/45cc2524-2e6f-458a-9df3-fcabd938eb67" width="200" /> | <img alt="Vektor zwischen Punkten" src="https://fhdwdev.ha.bib.de/gitea/attachments/bdbe1e64-6fa6-454b-9a55-7488b7f3b553" width="200"/> | <img alt="Grobe Verbindung" src="https://fhdwdev.ha.bib.de/gitea/attachments/82ae7182-3954-4c68-8a8f-a9b5371119d1" width="200"/> | <img alt="Feine Verbindung" src="https://fhdwdev.ha.bib.de/gitea/attachments/f18e309c-8245-4cd6-b821-245fddff42ef" width="200"/>|
| -------- | -------- | -------- | -------- |
| 1. Markieren von Start- und Endpunkt | 2. Bestimmen des Verbindungsvektors | 3.a Einzeichnen der Decals entlang des Vektor (grob) | 3.b Sehr dicht platzierte Decals als Verbindung |

## Refaktorisierung der Bladder.jsx
Um die Wartbarkeit und Lesbarkeit des Codes zu gewährleisten, haben wir beschlossen, die Bladder.jsx zu Refaktorisieren. Dabei haben wir einige Methoden in eigene Klassen ausgelagert. Zusätzlich haben wir die .jsx in eine .tsx überführt.

### Konvertierung in .tsx
Aufgrund von anfänglich fehlenden Kenntnissen über React, TypeScript und ThreeJS haben wir uns ursprünglich an den Dokumentationen und Beispielen von [`@react-three/fiber`](https://docs.pmnd.rs/react-three-fiber/getting-started/introduction) orientiert. Diese wurden alle anhand von .jsx-Dateien demonstriert, sodass wir uns, um einen einfacheren Einstieg zu erhalten, dazu entschieden haben, die Bladder-Komponente zunächst ebenfalls als .jsx zu implementieren.

Allerdings haben wir nun die im letzten Semester gelernten Kenntnisse über React, TypeScript und ThreeJS einsetzten können, um die Bladder.jsx um Typisierungen zu ergänzen und diese in eine .tsx umzuwandeln.

Dabei gab es kleinere Komplikationen beim Einlesen des Blasenmodells als `.glb`/`.gltf`. Dies konnte darauf zurückgeführt werden, dass TypeScript nur das Importieren von [`Modules`](https://www.typescriptlang.org/docs/handbook/modules.html) erlaubt. Dadurch kam es bei dem folgenden Import zu Fehlern.

import raw from "../assets/Bladder_blasenbereiche_v13.glb";

Um diesen Fehler zu beheben, musste im `src`-Verzeichnis des Projektes die Datei [`global.d.ts`](https://www.typescriptlang.org/docs/handbook/declaration-files/templates/global-d-ts.html) erstellt werden. Diese enthält den folgenden Code.

declare module "*.glb" {
  const value: any;
  export default value;
}

declare module "*.gltf" {
  const value: any;
  export default value;
}

In dieser Datei werden alle `.glb`/`.gltf`-Dateien als `Module` deklariert, sodass der obige Import nun als Import eines `Modules` akzeptiert wird und somit die Bladder.tsx kompiliert.

### Auslagern von Komponenten
Aufgrund der stetigen Weiterentwicklung der Bladder.jsx, wie z.B. durch Verbesserungen des Zeichnens der Textur oder das Befähigen der Komponente Operationen (`Surgery`) zu Importieren oder Exportieren sind die Komplexität und Größe dieser Komponente ausgeartet. Die Bladder.jsx besaß über 700 Zeilen Code. Wir haben daher beschlossen Funktionen, insofern es sich angeboten hat, in separate Klassen zu extrahieren.

#### Zeichen-Varianten
Eine Funktion, die sich optimal zum Auslagern angeboten hat, ist das Zeichnen in das Blasenmodell.

Das Zeichnen fand vorher über die `draw()`-Methode der Bladder.jsx statt. Diese Funktion haben wir nun in die abstrakte Klasse `DrawingTool` ausgelagert, dass eine abstrakte `draw()`-Operation besitzt. Das Zeichnen auf der UV-Map haben wir in die `UVDrawingTool`-Klasse extrahiert. Diese Klasse erweitert die `DrawingTool`-Klasse und implementiert damit die `draw()`-Operation. Das Gleiche gilt für das Einzeichnen von Decals. Diese Funktion kann mittels der neu erstellten `DecalsDrawingTool`-Klasse eingesetzt werden.

**Vorher:**
<img alt="Refaktorisierung - Vorher" src="https://fhdwdev.ha.bib.de/gitea/attachments/8ffe7106-abb7-4a61-8b66-c1c17320727f" />

**Nachher:**
<img alt="Refaktorisierung - Nachher" src="https://fhdwdev.ha.bib.de/gitea/attachments/c6ab8e2a-7b0c-4640-a89b-1588f0039de5"/>

#### Erstellen der ShapeUtils (Factory-Pattern)
Die Bladder.jsx besaß zunächst die Methode `getShapes()`. Diese wurde dazu verwendet, um aus allen Tabs die eingezeichneten Punkte in die entsprechenden Shapes (`Point`, `Line`, `PolyLine`, `PolyArea`) zu konvertieren und ein Array an Shapes zurückzuliefern.

Wir haben die Logik zur Bestimmung des jeweiligen `Shape` in die statische Funktion `getShape()` der `ShapeUtils`-Klasse ausgelagert. Somit kann diese Klasse als Factory von Shapes betrachtet werden. Die statische `getShape()` Funktion kann nun für alle Punkte aller Tabs über die Bladder.jsx aufgerufen.

#### Anzeigen des Normalenvektor für leichteres Debugging
Zu Beginn des Projektes haben wir einen [`THREE.ArrowHelper`](https://threejs.org/docs/index.html?q=arrowhelper#api/en/helpers/ArrowHelper) verwendet, um uns den Normalenvektor auf der Oberfläche des Blasenmodells zu visualisieren. So wurde uns das Nachvollziehen und Debuggen des RayCastings vereinfacht. Zum Ende des letzten Theoriequartals haben wir diesen wieder entfernt, da er nicht länger benötigt wurde. Jedoch haben wir beschlossen, diesen, für ein besseres Verständnis der Decals, wieder einzuführen.

Wir haben den ArrowHelper in eine eigene Komponente Namens `CustomArrowHelper.tsx` ausgelagert. So kann durch das Einbinden dieser Komponente ohne größeren Aufwand das Anzeigen des Normalenvektors erreicht werden.

#### Skalierung des Blasenmodells in Config-Datei auslagern
Um die Kamera immer korrekt im Blasenmodell positionieren zu können, sollte das Modell skalierbar sein. Die Größe des Ausgangsmodells kann varieren, sodass möglicherweise eine Skalierung vorzunehmen ist. Hierfür haben wir eine `BladderConfig.ts`-Datei erstellt, mit welcher die Individualisierbarkeit des Skalierungsfaktors erreicht wird.
Dadurch wurde die Möglichkeit geschaffen, von außerhalb, z.B. der Benutzeroberfläche, auf den Wert zuzugreifen.

Zusätzlich arbeiten wir daran eine Unterscheidung zwischen Produktiv- und Entwicklungsbetrieb einzubinden. Damit können verschiedene Konfigurationen für verschiedene Betriebsarten erstellt und eingesetzt werden.

## Bestehende Problematiken und Konzeptideen für die Harnröhre
### Implementierung der Kugelkoordinaten dem Konzept nach anpassen
Im aktuellen Arbeitspaket haben wir die Umwandlung von kartesischen Koordinaten in Blasenpositionen bzw. Kugelkoordinaten umsetzten können. Trotzdem entsprechen diese Positionen noch nicht den konzeptionierten Blasenpositionen. Nach dem Konzept sollte die Zählung des Tiefenwinkels bei 0° am Blasenhals beginnen und bis 180° am höchsten Punkt des Blasendoms zählen. Alle Stellen innerhalb der Harnröhre sollen einen negativen Winkel haben. In der aktuellen Implementierung hat der tiefste Punkte der Harnröhre den Tiefenwinkel bei 0°

Hierfür muss also noch eine Anpassung der aktuellen Implementierung an das gewünschte Konzept stattfinden.

### Zeichnen in der Harnröhre
Das Einzeichnen von entnommenen Tumoren in der Harnröhre ist in dem aktuellen Blasenmodell schlecht bis gar nicht möglich. Der Größenunterschied von der Harnröhre zur Blase ist so groß, dass eine Abänderung der Kameraposition nicht ausreicht, um vernünftig in der Harnröhre einzeichnen zu können.

Das folgende Bild zeigt die aktuell mögliche Kameraansicht in der Harnröhre:

<img alt="Einzeichnen_Harnröhre" src="https://fhdwdev.ha.bib.de/gitea/attachments/9526ab6d-8bbf-4cb1-8e85-e7338132b45f" width="600"/>

Bei dieser Kameraposition ist es nur möglich, eine Seite der Harnröhre zu betrachten. Drehungen sind an dieser Stelle nicht möglich, da die Kameraansicht nicht mehr in der Harnröhre ist. Zusätzlich ist bei dieser Kameraperspektive das Einzeichnen nur schwer möglich. Wird versucht bei einer solchen Kameraansicht zu zeichnen, dann werden die Einzeichnungen an der gegenüberliegenden Wand gesetzt, die sozusagen von der Kamera überdeckt wird. Das passiert aus dem Grund, dass die Kamera so weit außen ist, dass die "unsichtbare" Wand zuerst mit dem Raycast getroffen wird.

Im Folgenden sind zwei mögliche Ansätze beschrieben, die das Einzeichnen in der Harnröhre ermöglichen können.

#### Skalierung des kompletten Blasenmodells
Als Problem für das Einzeichnen in der Harnröhre haben wir die Größe der Harnröhre in Bezug auf die Blase identifiziert. Die komplette Blase inklusive der Harnröhre ist nach Originalgrößen modelliert, dadurch ist die Harnröhre im Vergleich zur Blase sehr dünn.
Wir haben bereits einen Positionswechsel der Kamera zwischen verschiedenen Sichten in der Blase geplant, mit dem diese Hin und Her gewechselt werden kann. Hierbei könnten wir realisieren, dass bei der Kameraansicht für die Harnröhre das komplette Modell um ein vielfaches größer skaliert wird. Dadurch ist es möglich, die Kamera vernünftig in der Harnröhre zu positionieren und auch dort entnommene Tumore einzeichnen zu können.

Zu einem Problem könnte es kommen, wenn das Modell so groß dimensioniert werden muss und die Länge der Harnröhre so groß wird, dass mit einer Kameraposition nicht die Harnröhre komplett abgedeckt werden kann. So könnte es unter Umständen wieder darin resultieren, dass auch hier das Einzeichnen nicht gut funktioniert.

#### Zweites Modell für die Harnröhre
Als zweite Lösungsmöglichkeit für die bestehende Harnröhrenproblematik bietet sich ein zusätzliches Modell für die Harnröhre an. Dadurch, dass wir ohnehin einen Positionswechsel der Kamera anstreben, würde es nicht auffallen, wenn bei einer bestimmten Kameraposition ein zusätzliches Modell für die Harnröhre verwendet wird. Dieses Modell kann im Vorhinein so modelliert werden, dass das Einzeichnen dort ohne zusätzliche Skalierung möglich ist.

## Einheitenfehler bei der Strichstärke von eingezeichneten Flächen
Während des Debuggings der Koordinatenkonvertierung ist aufgefallen, dass die Textausgabe nicht zu dem eingezeichneten Punkt passt. Die eingezeichnete Fläche ist kleiner als die in der Textausgabe beschriebene Fläche.
Dies lässt sich darauf zurückführen, dass die Größe des eingezeichneten Punktes in Pixeln bemessen ist und die Textausgabe die Größe des Punktes in Millimeter rechnet.
Hier ist das Angleichen zu einer festgelegten Einheit notwendig.