---
# System prepended metadata

title: Kevin Visionary / PRo3D

---

# Kevin Visionary / PRo3D

1. 1-2 Datensätze (z.B. HomePlate / Gale Crater - oder eben andere. Kann gerne getestet mit einer Festplatte vorbeikommen wenn es doch an den Datensätzen liegt)
    1. die in der aktuellen Pro3D Version funktionieren
    2. Einer sollte klein sein (theoretisch kann es auch "ein OPC" aus einer größeren Szene sein, es ist halt deutlich schöner wenn es zwei unterschiedliche Datensätze wären und kein Subset)
    3. Einer muss auf jeden fall so groß sein, dass er nicht mehr in den normalen Speicher passt, damit Streaming auch notwendig ist. Der Gale Crater mit 200GB war dafür natürlich super.
2. Definition wie ich die Vergleichsmessungen zwischen Visionary (mein Tool) und Pro3D umsetzen kann. Es wird nie ganz vergleichbar sein, aber es sollte zumindest "ein bisschen" Plausibilität haben
    1. z.B. Flyover mit gleichen Kamera-Punkten, Average FPS und Average Triangle pro Frame (ist natürlich nicht ganz vergleichbar, weil beide Werkzeuge unterschiedlich viel Nachladen müssen)
    2. z.B. Dauer einer Messungen mit den selben Ausgangspunkten und selber Projektionsrichtung und der Menge an resultierenden Punkten (weil die Menge an Subdivisions natürlich wichtig ist). Ggf. auch die resultierenden Punkte in beiden Fällen
3. Erklärung wie die Referenzwerte gemäß Cheatsheet zu verstehen sind (z.B. wie bestimmte ich "Norden" für Dip & Strike) und wie True/Vertical Thickness zu verstehen sind
4. Austausch ob du noch andere Ideen für KPI hast anhand denen ich die Werkzeuge vergleichen kann: Was ich habe sind:
    1. Vergleich Unity Game Objects Basis-Implementierung zu meiner DOTS Implementierung
    2. Vergleich Average FPS Flyover einer Kamerafahrt Visionary vs Pro3D
    3. Vergleich Storage Size OPC+KD Tree vs DOTS Binary Serialization Format
    4. Zeit für Preprocessing (auch wenn Chris betont hat, dass ich das natürlich nicht vergleichen kann, weil das bei Pro3D ja im Grunde schon passiert bevor ihr die OPC Datensätze bekommt

## ad 1. 1-2 Datensätze (1.1-1.3)

![](https://i.imgur.com/xNsD9wS.png)

4.6.1-prerelease1 kann gale crater einwandfrei anzeigen. mögliche Fehler, 
* der `main` branch ist broken. es muss von `develop` gebuilded werden
* gale crater ist nicht sichtbar aufgrund des frustum bug ... workaround near oder far plane kurz verändern, dann ist die ganze range sichtbar

kleinere datensätze finden sich hier https://pro3d.space/#started

## ad 2. Definition wie ich die Vergleichsmessungen zwischen Visionary (mein Tool) und Pro3D umsetzen kann. Es wird nie ganz vergleichbar sein, aber es sollte zumindest "ein bisschen" Plausibilität haben


### ad 2.1 Messung Performance Rendering

Genau, Performance ist die Frage weil das stark von der Lod Metrik abhängt, man könnts natürlich eben normieren auf die triangles pro frame. Stellt sich die nächste Frage wie man misst in PRo3D. Weiters gibts in PRo3D zur Zeit nicht die Möglichkeit einen Kamerapfad nach einem bestimmten Format abzufliegen. Gibt nur bookmarks die in PRo3D definiert und dann nach der Reihe abgeflogen werden. Also wie bekommt man exakt diesselbe Kamerafahrt in beiden tools hin? Wir haben auch eine relativ schwindliche Screenspace Metrik die die LODlevel bestimmt

### ad 2.2 Messung Performance Intersection

Läuft letztendlich auf die Frage hinaus wie lange dauert eine Ray/Surface Intersection, vom klick bis zu dem Zeipunkt wo man einen Punkt sieht, bzw. die Koordinaten in der Hand hat.

## ad 3. Erklärung Cheat Sheet

Ich nehm an, dass die Idee hier ist die Genauigkeit der Messung zu überprüfen. Nordrichtung berechnen wir mit einer externen dll, wo etwas hinzeigt in bezug auf norden ist dann einfach nur ein dotproduct. Vertical/Truethickness basiert auf planefitting. Das sind alles komplexere aufbauten bzw. allgemeine Algorithmen bei denen es nicht so sinnvoll ist sie zu evalulieren. Alles basiert auf der Genauigkeit der geklickten Punkte ... welchen Plane-Fit Algorithmus man dann verwendet hat wenig mit Unity vs. PRo3D zu tun. Selbiges gilt für Ermittlung des Nord-Vektors. 

## ad 4. KPIs

hören sich recht sinnvoll an. Du kannst schon auch das Preprocessing vergleichen, müssen nur schauen, dass wir ein timing für die kd-tree erstellung kriegen. bzw. die trees selber erstellen. Es könnt noch interessant sein, wie lang brauch ich wenn ich ganz nah bin einen horizon zu laden der bis aufs höchste detail runter geht. weil wenn ich drüberflieg kanns sein dass ich so langsam lade dass nie was fertig wird und dann bin ich schon wieder vorbei und hab letztendlich bessere performance als ein system das schneller lädt.



























