llmesh was ist das genau

Manfred Aabye
Manfred Aabye

Ich frage mich was genau llmesh ist.

Ist das vielleicht ein Komprimiertes allseits bekanntes Mesh Format?

Ich finde im Internet nicht eine Seite, die das Format mal richtig erklärt.


Endung in OpenSim ist ************_mesh.llmesh.


Comments

  • Manfred Aabye
    Manfred Aabye
     Member edited November 2018

    Überblick

    Dieses Dokument ist eine Spezifikation des von Second Life verwendeten Mesh Formats. Auf der höchsten Ebene ist ein Mesh Asset eine Sammlung von Datenblöcken, die über eine Datei verteilt sind. Die Größen, Positionen und Typen der Datenelemente werden im Header am Anfang der Datei beschrieben. Dieses Dokument beschreibt das Format des Headers und alle Datenblocktypen, auf die er sich beziehen kann.

    Header

    Der Header ist eine unkomprimierte, binär codierte LLSD-Map mit folgenden Elementen:

    Versionierungs- und Erstellerinformationen

    • "version" -- integer -- Eine Versionsnummer für das gesamte Asset, die vom Simulator nach dem Import eingegeben wird. Drei niedrigstwertige Ziffern sind für die untergeordnete Version reserviert, wobei Hauptversionsänderungen auf eine Formatänderung hinweisen, die nicht abwärtskompatibel ist und nicht von Zuschauern analysiert werden sollte, die diese Version nicht speziell unterstützen. Wenn beispielsweise die ganze Zahl "1" vorhanden ist, lautet die Version 0,001. Ein Viewer, der Version 0.001 analysieren kann, kann auch Versionen bis 0.999, jedoch nicht 1.0 (Ganzzahl 1000) analysieren.

    • "creator" -- UUID -- Agenten-ID des Agenten, der das Asset hochgeladen hat, wird vom Simulator ausgefüllt

    • "date" -- LLDate (als LLSD, Sekunden seit UTC Zeit) des Uploads, gefüllt vom Simulator

    Detaillierungsgrad Level of Detail

    Es können bis zu vier Detailebenenblöcke angegeben werden. Detailblocknamen sind:

    • "high_lod" - Höchste Detailgenauigkeit für dieses Asset MUSS bereitgestellt werden

    • "medium_lod" - Optional, mittlerer Detailgrad

    • "low_lod" - Optional, geringe Detailstufe, darf NICHT vorhanden sein, wenn "medium_lod" nicht vorhanden ist

    • "Lowest_lod" - Optional, niedrigste Detailstufe, darf NICHT vorhanden sein, wenn "low_lod" nicht vorhanden ist


    Jeder Detailebene-Eintrag muss die folgenden Elemente enthalten:

    • "offset" -- integer -- der Offset (in Bytes) der Detailblockebene im Asset, beginnend am Ende des Headers

    • "size" -- integer -- die Größe (in Bytes) der Detailblockebene

    Physik

    Jeder Physikeintrag muss zur Validierung einen "hash" enthalten. Der Hashwert wird vom Simulator zum Zeitpunkt des Uploads ausgefüllt und für jede nachfolgende Ladung verwendet, um zu überprüfen, ob das Asset gültig ist. Jeder dieser Einträge muss außerdem einen "offset" und eine "size" enthalten, wie im Abschnitt "Level of Detail" oben beschrieben. Es gibt vier Physikdatenblöcke:

    • "physics_mesh" - Optional, ein Netz, das die physische Form dieses Objekts darstellt

    • "physics_convex" - Erforderlich: Eine einzige konvexe Hülle, die das gesamte Mesh-Asset umfasst, und eine (optionale) Gruppe konvexer Hüllen (als konvexe Zerlegung bezeichnet) für detailliertere Kollisionen. Wenn der Datenblock "physics_convex" eine solche Zerlegung enthält, MUSS "physics_mesh" nicht vorhanden sein, da er niemals verwendet wird.

    • "physics_havok" - Wird vom Simulator beim Hochladen ausgefüllt und enthält einige für Havok spezifische Daten im Cache, um die Ladezeit des Simulators zu verbessern.

    • "physics_cost_data" - Daten, die zur Ermittlung der Physikkosten dieses Assets für einen bestimmten Maßstab benötigt werden - enthält eine einzige LLMatrix3 ("mesh") im LLSD-Format, die die Netzkonstanten für die Physik definiert, wenn ein Mesh verwendet wird.

    Skin

    Ein "Skin" Block kann vorhanden sein und muss einen "offset" und eine "size" enthalten, wie im Abschnitt Level of Detail oben beschrieben. Details finden Sie unten.

    Mesh Level of Detail Block

    Jeder Detailblock ist eine gzip-binäre, kodierte LLSD-Liste mit Subnetzwerken. Jedes Submesh wird in Second Life einem "Gesicht" zugeordnet, und jede Detailebene MUSS dieselbe Anzahl von Submeshes aufweisen. Jede Detailebene muss eine niedrigere Anzahl von Dreiecken haben als jede höhere Detailebene. Jedes Subnetz enthält die folgenden Felder:

    • "NoGeometry" - optional, boolean, muss true sein - Wenn vorhanden, ist keine Geometrie für dieses Subnetz vorhanden. Dieses Submesh ist nur ein Platzhalter, um den Simulator / Betrachter darauf hinzuweisen, dass für dieses Submesh ein Textureintrag ohne Geometrie an diesem LoD vorhanden ist. Wenn "NoGeometry" vorhanden ist, dürfen keine zusätzlichen Felder angegeben werden.

    • "Position" - Erforderlich, LLSD-Byte-Array mit vorzeichenlosen 16-Bit-Positionswerten (6 Byte pro Position).

    • "PositionDomain" "Min" / "Max" - optionales LLSD-Vektor3-Paar, das die Domäne der Positionswerte angibt (Domäne wird als [-0.5, 0.5] angenommen, wenn "PositionDomain" nicht angegeben ist). Domäne muss innerhalb von [-0.501, 0.501] liegen.

    • "Normal" - optionales LLSD-Byte-Array, das vorzeichenlose 16-Bit-Normalwerte enthält ([-1.0, 1.0] -Domäne, nicht unbedingt Einheitennormalen). Muss dieselbe Länge wie das "Position" -Array haben.

    • "TexCoord0" - optionales LLSD-Byte-Array mit vorzeichenlosen 16-Bit-Texturkoordinatenwerten (2-dimensional, 4 Byte pro Texturkoordinate). Muss dieselbe Anzahl von Texturkoordinaten wie Positionswerte haben.

    • "TexCoord0Domain" "Min"/"Max" - Erforderlich, wenn "TexCoord0" vorhanden ist. Das vector2 Paar bezeichnet eine Domäne, in der 16-Bit-Texturkoordinatenwerte entpackt werden.

    • "TriangleList" -- required , LLSD-Byte-Array mit vorzeichenlosen 16-Bit-Scheitelpunktindizes. Muss mindestens einen Verweis auf jede Scheitelpunktposition enthalten und darf NICHT Indizes enthalten, die größer als die Anzahl der Scheitelpunktpositionen sind. Kein einzelnes Dreieck in der Liste darf denselben Knoten zweimal referenzieren (keine entarteten Dreiecke).

    • "Weights" - required , wenn der Header "skin" vorhanden ist. LLSD-Byte-Array, das gemeinsame Einflüsse enthält.

     

    Thanked by: Pius Noel
  • Manfred Aabye
    Manfred Aabye
     Member

    Vertex-Gewichtskodierung (Weight Encoding)

    Jeder Gewichtseintrag entspricht einer Position im Positionsarray. Jeder Eintrag kann bis zu 4 Einflüsse enthalten. Jeder Einfluss wird als vorzeichenloser 8-Bit-Index definiert, gefolgt von einem vorzeichenlosen 16-Bit-Gewichtungswert (niederwertigstes Byte zuerst). Ein gemeinsamer Index von „0xFF“ zeigt an, dass für diesen Eintrag keine Einflüsse mehr vorhanden sind. Mit Ausnahme von 0xFF darf kein gemeinsamer Index einen Wert> 31 haben. Wenn für den aktuellen Eintrag 4 Einflüsse gelesen wurden, wird davon ausgegangen, dass für diesen Eintrag keine Einflüsse mehr vorhanden sind.

    Ein Eintrag, der Gewichtungen für die Verbindungen 2 und 3 angibt, enthält beispielsweise die Werte:

    0x02 0xWWWW 0x03 0xWWWW 0xFF

    Dabei steht 0xWWWW für einen beliebigen Gewichtungswert. Ein Eintrag, der Gewichte für die Verbindungen 1, 2, 3 und 5 angibt, enthält die Werte:

    0x01 0xWWWW 0x02 0xWWWW 0x03 0xWWWW 0x05 0xWWWW

    Bei Angabe von 4 Werten ist kein abschließender Joint-Index erforderlich. Die Anzahl der gemeinsamen Einflusseinträge muss mit der Anzahl der Positionen aus dem Feld "Position" oben übereinstimmen.

    Skin Block

    Der Skinblock kann optional das gesamte Second Life-Skelett ganz oder teilweise ändern. Eine partielle gemeinsame Liste enthält eine Teilmenge dieser Verbindungen: mPelvis, mTorso, mChest, mNeck, mHead, mCollarLeft, mShoulderLeft, mElbowLeft, mWristLeft, mCollarRight, mShoulderRight, mShlRReadright, mWristRight, mWristRight, mWristRight Ein vollständiger Avatar-Ersatz wird alle diese Verbindungen enthalten und referenzieren.

    Der Skin-Block ist eine gzip-binäre, kodierte LLSD-Karte mit folgenden Einträgen:

    • "joint_names" - Liste der gemeinsamen Namen für diesen Skin. Enthält gemeinsame Namen aus der obigen Liste.

    • "bind_shape_matrix" - Matrix, die vom Modellraum zum Weltraum transformiert. Einer pro Haut.

    • "inverse_bind_matrix" - Matrix, die den lokalen Hautraum (Weltraum) in den gemeinsamen lokalen Raum transformiert. Eine pro Gelenk mit Einflüssen.

    • "alt_inverse_bind_matrix" - optional, wenn gemeinsame Offsets verwendet werden, enthält die alternative Bindematrix Translationsinformationen, die das standardmäßige Second Life-Skelett überschreiben. Rotations- und Skalierungskomponenten werden zu diesem Zeitpunkt nicht verwendet.

    • "pelvis_offset" - optional, um eine Beckenfixierung für Avatar-Rigs bereitzustellen, die das standardmäßige Second Life-Skelett ändern.

    Physics Mesh Block

    Ein Physik mesh block ist derselbe wie ein Block mit Detailebene oben, jedoch mit der zusätzlichen Einschränkung, dass er keine entarteten Dreiecke im Maßstab 0,5x0,5x0,5 enthalten darf, wie durch die Funktion ll_is_degenerate in llfloatermodelpreview.cpp definiert.

    Physics Convex Block

    Dieser Block definiert eine einzige konvexe Hülle in "BoundingVerts" und eine Liste von konvexen Hüllen in "HullList" und "Positionen". Wenn Sie den physischen Formtyp eines Netzobjekts auf "Prim" setzen, werden (in der bevorzugten Reihenfolge) die "HullList", die Detailebene "physics_mesh" oder die "BoundingVerts" als physische Form des Objekts verwendet.

    • "HullList" -- optional, LLSD byte array, Liste der U8, die die Anzahl der Punkte in jeder Hülle angibt. "0" bedeutet hier 256 Punkte.

    • "Positions" -- required, wenn "HullList" vorhanden ist, LLSD-Byte-Array, Liste der U16-Werte von Hull-Punkten - Dekomprimieren Sie die von "Min" / "Max" angegebene Domäne. Muss so viele Punkte enthalten wie die Summe der Punkte, die mit "HullList" gekennzeichnet sind

    • "BoundingVerts" -- required, LLSD-Byte-Array, Liste der U16-Punkte von Punkten in einer einzigen konvexen Hülle für die gesamte Form - Dekomprimieren Sie die in "Min" / "Max" angegebene Domäne.

    • "Min"/"Max" -- optional, LLSD vector3 pair, Domäne zum Entpacken der Positionswerte. Wenn nicht angegeben, wird angenommen, dass die Domäne [-0,5, 0,5] ist.


    "HullList" und "Positions" dürfen NICHT vorhanden sein, wenn der Header einen Eintrag "physics_mesh" enthält.

    Physik-Havok-Block

    Nur ausgefüllt und nur vom Simulator verwendet.

    Physik-Kostendaten

    ???


    Thanked by: Pius Noel
  • Manfred Aabye
    Manfred Aabye
     Member
    Aber ist das auch das gleiche wie im OpenSimulator?
  • Pius Noel
    Pius Noel
     Moderator
    Super recherchiert! Vom Prinzip her ist es dasselbe. Ob es im Detail genau das gleiche ist, weiss ich auch nicht. Ich kenne .llmesh-Dateien nur aus den "assets" von IAR-Exporten und dort haben sie zumindest ähnliche Strukturen.
Sign In or Register to comment.

Welcome

It looks like you're new here. If you want to get involved, click one of these buttons!

Discussions

© Copyright 2019 - Metropolis Metaversum
All times are GMT