• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

Geblendertes Meshmodell wird in SL3.6.6 nicht mehr angenommen

Jenna Felton

Superstar
Hallo,

Habe ein Modell in Blender erstellt (eigentlich was einfaches) und konnte es ohne Problemme mit dem aktuellen Firestorm hochladen. Auch der offizielle SL 3.6.5 (280370) nimmt das Modell an und berechnet alle Unterstufen ohne Problemme. So, nun wollte ich es im Betagrid mit dem Betaviewer 3.6.6 (280939) hochladen, und der zeigt mir das Modell ist fehlerhaft und berechnet keine Unterstufen.

Ok, der Viewer soll eigentlich den Code für neue Partikel enthalten, also dachte ich, es ist ein Bug in diesem Betaviewer, also mache ich den Bugreport, und (da Ihr dieses nicht lesen könnt) antwortet Graham Linden dies:

PlaceH.dae appears to have invalid indices as well which refer to verts outside those present in the DAE data.

PlaceH.dae ist das Modell, was ich uploaden wollte, es ist mit dem Blender 2.68.0 r58537 erstellt. Anscheinend wurde der Uploader seit 3.6.5 korrigiert, so dass fehlerhafte Modelle nicht mehr angenomen werden. Irgendwann werden auch TPV folgen dann.

So, wie kommt es aber, dass Blender eine ungültige Ausgabe produziert? Kann man diese irgendwie korrigieren? Ich habe versucht, das Modell zu durchforsten aber so manuell kann ich keine ungültigen Indizen finden. Dabei hat es 'nur' 104 Vertices.

LG
Jenna
 
1. Hast du auch andere Meshs hochzuladen versucht ?

2. Ansonsten kann es sein, das es sich um einen versteckten (Konstruktions)Fehler des Meshs handelt. So etwas hatte ich auch schonmal. "...which refer to verts outside..." könnte auf sich überlappende Faces hindeuten.
 
Hallo Argus

1. Andere Modelle habe ich auch versucht, bei einigen gab das Problem nicht. Habe aber nicht viele ausprobiert.

2. Interessanterweise funktioniert "Remove Doubles" nur wenn das Model ausgewählt ist. Es hat 20 Vertices beseitigt. Allerdings besteht das Problem immer noch..

Das Modell schaut so aus:

original.png

Ich versuche es mal zu vereinfachen, bzgl. Materialienzahl und Flächenzahl. Ob das Problem sich so eingränzen lässt.
 
Du kannst ja eines der nicht uploadfähigen Meshes hier als Anhang mitgeben, wenn du willst. Mit "überlappenden" Faces meinte ich eine Art "über-kreuz"-Verbindung zwischen Vertices. Das passiert schnell bei Optimierungsarbeiten und man sieht es kaum.
 
Danke Argus :)

wusste gar nicht, dass man hier auch .dae Dateien anhängen kann. Ich kann aber nicht direkt, sondern nur verzippt.

Ich glaube über kreuz habe ich nichts gemacht. Aber um Zylinder zu schließen, die extrudierte Reie zu einem Punkt verschmolzen. Ich habe das Modell nun auf fast minimum verkleinert, also nur 2 Materialien und je 4 dreieckige Faces. Blender sagt auch, 10 Vertices, 16 Edges, 8 Faces/Tris:

verkleinert.png

Das exportierte Modell wird immer noch abgewiesen.

Anhang anzeigen PlaceTest1.zip

Weise ich aber allen Faces nur ein Material zu, auch wenn das überflüssige Material noch im Slot bleibt, wird das Model angenommen.

Anhang anzeigen PlaceTest2.zip

Von der Datei selbst bzw. den Textvergleich werde ich aber nicht schlau.

Edit. Falls meine Modellverkleinerung kontraproduktiv var, hänge ich noch das Originalmodel, also fast welches ich im Bugreport angegeben hatte, an, ich habe nur Dubletts entfernt. der SL mag es aber trotzdem nicht :)

Anhang anzeigen PlaceTest.zip

Möglicherweise war das Problem wo ich in den äußeren Hülle in der Mitte zwei Zylinder zusammengeführt habe. Da treffen sich zwei Faces des Sculpty. Aber eigentlich sollte das kein Problem machen. Und bei der Minimierung hab ich ja die Stelle beseitigt. Verbindung zwischen den Halbdiamanten im minimalen Modell gibt es keine. Ich versuche später mit einem anderen Blender.
 
Zuletzt bearbeitet:
Ich kann keine kritischen Stellen bei deinen Meshs entdecken. Sie sind sauber konstruiert. Ich glaube eher, das der neue Lindenviewer noch buggy ist. Zumal man "Blender-Meshs" auch andernorts hochladen kann. Ich glaube also nicht, das LL bislang dae-Funktionen mit einem speziellen Fehler einsetzte, sondern das jetzt erst ein solcher Fehler enthalten ist.

(Das die dae-Funktionen generell noch nicht ganz ausgereift sind , ist sowieso klar. Ich höre von zu vielen Leuten, das mehrere Uploads ein und desselben Meshs machmal unterschiedliche Resultate zeigen.

Geht was schief, hängt sich der dae-importer auf und der Viewer frisst fast 100 % CPU. Dann hilft nur noch, den Task mit Gewalt zu beenden.
 
Danke Argus und auch für das Kompliment :)

Sven hat mir gerade das mit dem 3.6.6 hochgeladene Modell gegeben, also funktioniert der Upload doch oder jetzt. Was ich aber auch entdeckt habe, wenn ich das DAE Modell in Blender importiere und nochmal exportiere, bekomme ich eine Datei mit vielen Unterschieden in den Indexlisten, gegenüber dem importierten Modell. Evtl sortiert Blender die Vektoren beim Import um, und das könnte das mögliche Problem auch beseitigt haben.

Mit dem 3.6.6 (280939) kann ich aber nicht mehr hochladen, wegen dem Zwangsupdate ist es jetzt auch der andere Viewer. Ich versuche damit mal das Originalmodel und die Minimodelle, wenn ich dazu wieder komme. Wird lustig, wenn ich nochmal einen Bugreport abgeben muss, wo der Linden meinte, da ist nur Fehler in der Datei :)
 
setz auch mal probeweise beim Upload LOD1-3 auf 0 bzw
LOD1 auf "use LOD above" und 2+3 auf 0

ich habe die Erfahrung gemacht, das die vom Importer berechneten Zwischenstufen einfach nur Murks sind, je komplexer (20k-100k Polys), desto mehr


und nicht zu vergessen das UV-Mapping, da reagiert das Uploading auch recht empfindlich.
Wie "schön" gelayoutet ist egal, aber es sollten auf keinen Fall Flächen ausserhalb dem UV-Map-Quadrat liegen
 
und nicht zu vergessen das UV-Mapping, da reagiert das Uploading auch recht empfindlich.
Wie "schön" gelayoutet ist egal, aber es sollten auf keinen Fall Flächen ausserhalb dem UV-Map-Quadrat liegen

Nur um ganz sicher zu gehen: Du meinst die Arbeitsfläche im Blender-UV/Image-Editor ? Das da Flächen ausserhalb liegen ist doch normal und lässt sich nicht vermeiden. Allein schon die Skalierung bringt das mit sich. Und wie oft schiebe ich Flächen nach aussen, um die Übersicht zu wahren.

Ist das deine Vermutung, oder ist das gesichert, dass das Probleme in Verbundung mit SL macht ?
 
Zunächst Eins vorweg, ich benutze kein Blender, was aber hier völlig irrelevant hier ist.

Ich schiebe selbst stundenlang die UV-Schnipsel "aussenherrum" bis alles fein angeordnet ist und grössenoptimiert ist.
Bei Multifaceobjekten, wie hier in SL üblich, darf jedes Material durchaus die gesamte UV-Fläche für sich ausnutzen.
Das lässt zwar die UV-map aussehn wie Kindergekrakel funktioniert aber perfekt, gebakt (die Texturen, insbesondere AO) wird dabei vorm Zusammenkleben der Objekte (dannach UV-map aber nicht mehr ändern)

Nun aber endlich zu deiner Frage betreffs mapping-"outside": das kann klappen, oder auch nicht (MAV_BLOCK_MISSING: leider eine Meldung für diverse verschiedene Meshfehler)
Empfehlenwert ist es auf keinen Fall, außer du bevorzugst Planarmapping in SL.
 
Im Blender gibt es eine Option, dass man die Umrisse auf dem UVMap nicht aus dem Bild herausschieben kann. Ich halte die immer an. Dadurch kann nur dann was herausragen, wenn ich manuell dort Koordinaten eingebe. Dabei achte ich immer darauf, dass es nicht passiert, weil ich immer dachte es gäbe einen Fehler deshalb.

UVMaps überlappen sich bei mir allerdings oft, wenn das Objekt verschiedene Faces hat, dann nutzt jedes mehr von einem Bild. Z.B. die Standardprims, die haben überlppende UVMaps. Nicht überlappende UVMaps haben auch einen Vorteil, wenn man ein Kleidungsstück macht, dann kann man mit nur einem Bild es komplett texturieren obwohl es mehrere Faces hat.

Aber egal, in dem besagten Modell ist die UVMap überlappend aber nicht 'rausragend'. Der Second Life 3.6.7 (281385) hat es auch brav angenommen. Denke, wenn es einen Fehler im Uploader gab, den haben sie beseitigt. An der Sim müsste es nicht gelegen haben, und den Graphiktreiber habe ich auch nicht aktualisiert.

setz auch mal probeweise beim Upload LOD1-3 auf 0 bzw
LOD1 auf "use LOD above" und 2+3 auf 0...

Hm, ich glaube ich habe es von anfang an falsch beschrieben. Also so sah das Dialog bei mir aus, als das Modell abgelehnt wurde (ich musste es manipulieren damit ich es so bekomme, einen Index von 7 auf 7123 geändert, damit der wirklich aus der Vertexliste fällt,):

attachment.php

Oder du meinst ich hätte die Nachstufen trotz dem Fehler in oberen Stufe trotzdem ändern sollen?
 
Zuletzt bearbeitet:
nein, meinte ich nicht
Einen Fehler wie ich dort in deinem Bild sehe hatte ich noch nie.
Bei dir hat der Uploader das Modell selbst (LOD 0) nicht akzeptiert.
Da nützt nachträgliches Ändern (falls möglich) auch nichts mehr.

Ich bezog mich auf Fehlermeldungen, die bei "Calculate Weights" auftreten, die haben meisst ihre Ursache in der Berechnung der (LOD)-Zwichenstufen
 

Users who are viewing this thread

Zurück
Oben Unten