--- tags: dibit, moved title: OPC vs OBJ --- # 20200708 OPC vs OBJ Datenstruktur OPC ist grundsätzlich nur eine Hierarchie, also ein Baum aus Knoten und eine dazugehörig Ordnerstruktur. Die Knoten in diesem Baum können beliebig aussehen, wir haben uns dazu entschieden, dass es reguläre Patches sind die sich implizit triangulieren lassen. Die Vertices dieser Patches sind zwar "Full 3D", beziehen sich aber in unserem Fall eine Projektionsrichtung und sind demnach nur 2.5D, wie ein Höhenfeld. OPC ist ein in Patches zerstückeltes Terrain. Nachteil: keine Hinterschneidungen möglich, Vorteil viele. Ein OBJ ist nicht hierarchisch, ein OBJ entspreicht quasi einem Patch im OPC. ``` # WavefrontOBJ spec von wikipedia # List of geometric vertices, with (x, y, z [,w]) coordinates, w is optional and defaults to 1.0. v 0.123 0.234 0.345 1.0 v ... ... # List of texture coordinates, in (u, [,v ,w]) coordinates, these will vary between 0 and 1. v, w are optional and default to 0. vt 0.500 1 [0] vt ... ... # List of vertex normals in (x,y,z) form; normals might not be unit vectors. vn 0.707 0.000 0.707 vn ... ... # Parameter space vertices in ( u [,v] [,w] ) form; free form geometry statement ( see below ) vp 0.310000 3.210000 2.100000 vp ... ... # Polygonal face element (see below) f 1 2 3 f 3/1 4/2 5/3 f 6/4/1 3/5/3 7/6/5 f 7//1 8//2 9//3 f ... ... # Line element (see below) l 5 8 1 2 4 9 ``` Demnach müssen wir unterscheiden OPC, OPC 2.5D, und OBJ. ## Stärken ### OPC * simples, hierarchisches format, es gibt keine existierenden Formate die Level-of-Detail hierarchien abbilden. * Levels-of-Detail im Format codiert * reguläre Patches - Generierung von Levels-of-Detail relativ einfach und gut kontrollierbar (zerschneiden von Bild, und Pyramide aufbauen) * sehr flexibel, OPC ist eigentlich nur ein hierarchy.xml (tree), patch.xml (nodes) ... könnte man sogar für Punktwolken verwenden oder nicht reguläre tins * möglichkeit texturen auf den laserscan zu mappen ![](https://i.imgur.com/VAKsOnn.png) (lübke) ### OBJ * extrem einfaches format (CG VU, erster parser) * sehr weit verbreitet, jedes tool kann objs erstellen * "flat", keine Hierarchien im Format möglich, ## Schwächen ### OPC * erstellung proprietär (JR Exporter) * offen aber nicht verbreitet * derzeit ein patch ein bild ... (Idee das zu entkoppeln) ### OBJ * extrem langsam im intial load durch ASCII format (caches on import, binary obj?) ... hoher speicherverbrauch * kein level-of-detail im format, letztendlich könnte man ein "OPC" aus OBJs machen (diskrete levels of detail) ![](https://i.imgur.com/zeSmZh8.png) (lübke01) * volles 3D mesh ohne constraints (Hinterschneidungen) ## Features ### beide * anzeigen mit texture * numerisch stabil - große Koordination ### OPC * dynamischer profilschnitt * implizit numerisch stabil - große Koordinaten, lokale Systeme * Inkrementelles nachladen von Details, Initial Detail sofort da (LoD) * Level-of-Detail skalierbar auch für schlechtere Hardware ## OBJ Problembehandlung ### Texturekoordinaten im OBJ Es kommt relativ häufig vor, dass es in einem OBJ mehr Texturkoordinaten als Vertices gibt. Das liegt daran, dass Texturkoordinaten häufig per Face und nicht per Vertex definiert werden. Im Rendering führt das allerdings zu Problemen, da hier pro Vertex nur eine Koordinate definiert werden kann. Anhand des Beispiels eines Würfels lässt sich leicht erkennen, woher die mehrfachen Koordinaten kommen, da jede Position an drei Faces angrenzt. Im Bild hat dadurch die Position C nur eine Texturkoordinate, B jedoch zwei und A sogar drei. Als Lösung wird hierbei im Rendering häufig eine Vervielfachung der Vertices genutzt, um alles noch korrekt anzeigen zu können. Dadurch hat dann jeder Vertex nur genau eine Texturkoordinate, wobei natürlich der Speicherverbrauch steigt. ![](https://i.stack.imgur.com/TdtX0.png) (Quelle: https://stackoverflow.com/questions/27777349/handling-obj-files-why-is-it-possible-to-have-more-vertextextures-vt-than-ve) ### Multiple Materialien im OBJ Bei den multiplen Texturkoordinaten kann es auch sein, dass diese durch mehrere Materialien entstehen. Hier im Beispiel gibt es 23 Vertices und in Summe 102 Texturkoordinaten (es sind 3 von 10 Abschnitten abgebildet) ``` usemtl Test_3D_Pfeiler_5_8192_10 f 15/15 13/13 8/8 f 9/46 10/47 3/48 f 21/80 18/81 22/22 f 13/100 15/101 12/102 usemtl Test_3D_Pfeiler_5_8192_101 f 4/4 20/20 17/17 f 16/49 10/50 9/51 f 14/70 11/71 12/12 f 21/77 19/78 18/79 usemtl Test_3D_Pfeiler_5_8192_102 f 6/29 4/30 17/31 f 5/5 7/7 9/41 f 3/3 5/42 9/43 f 20/97 18/98 17/99 ... ``` Pro Material kann dann auch eine eigene Textur (mit entsprechend eigenen Koordinaten) definiert sein. Die Lösung des Problems liegt entweder an der Erstellung eines Textureatlas (wobei Auflösung, Neuberechnung der Texturkoordinaten etc. beachtet werden muss) oder indem man pro genutztem Material eine eigene Geometrie erstellt (wesentlich gerinerer Aufwand, viele Einzelgeometrien können aber z.B. zu Performanceeinbußen führen, wenn falsch gehandhabt).