3D Modelle ändern...

[Manfred Aabye]

anhand des Hubble Space Telescope unter Windows.

   

Ich nutze dazu 7Zip, IrfanView + Plugins, Notepad++, SketchUp und den Singularity Alpha Viewer.

http://www.7-zip.de/

http://www.irfanview.de/

https://notepad-plus-plus.org/

http://www.sketchup.com/de/download/all?...in&osv=6.2

http://alpha.singularityviewer.org/alpha/


Als erstes laden wir uns das Teleskop herunter und entpacken es mit 7Zip.
http://nasa3d.arc.nasa.gov/detail/hst-3ds

Die kostenlose Version von SketchUp kann 3ds und Collada dae Formate Importieren.

Wir Importieren das HST.3ds Modell in SketchUp wie wir sehen findet er keine Texturen.

Das ist weil der Pfad nicht gefunden wird.

Wir schauen uns nun das Verzeichnis textures an wie wir sehen sind das sehr große Bilder um 1,5 MB diese reduzieren wir nun drastisch mit IrfanView.

Wir öffnen die erste Textur mit IrfanView und öffnen Datei – Batch/Stapel Konvertierung.

Wir wählen alle Texturen aus.

Nun das Zielformat JPG auswählen und unter Optionen die Qualität um 70-80.

Jetzt klicken wir noch auf Zielverzeichnis das Verzeichnis wo sich die HST.3ds Datei befindet.

Nach einem klick auf Starten werden alle Bilder umgewandelt.

Aus den Texturen die 6,75 MB groß waren sind Texturen von 186 KB geworden.

Wenn man sich überlegt das oft mehrere hundert Modelle auf einer Region sind, haben wir das erheblich reduziert.

Damit wir nicht jede einzelne Textur einzeln auf dem Modell setzen müssen ändern wir einfach die HST.3ds Datei mit Notepad++.

Rechte Maustaste Edit with Notepad++.

Suchen > Ersetzen… dann Suchen nach .bmp Ersetzen durch .jpg und zum Schluss noch alle ersetzen auswählen.

Dies Speichern wir als HST2.3ds ab.

Wir Importieren das Modell wieder in SketchUp und siehe da wir haben unsere Texturen auf dem Modell und das sogar erheblich reduziert.

Alles auswählen dann Eport als Collada dae.

Jetzt können wir es mit dem Singularity Viewer wie gewohnt hochladen.

Natürlich müssen noch die Texturen etwas angepasst werden.

Mapping = Planar
scale = jeweils 0.3 etwa
Shininess = Low

   

Ergebnis steht auf der Sandbox in Metropolis zum mitnehmen für die nächsten Paar Tage.


.

[Sheera Khan]

Huhu Manny,

ich möchte noch gerne ergänzen, dass die Texturen auf dem Server als JPEG2000 Dateien gespeichert werden, daher zwar der längere Upload für die BMP-Grafiken anfällt, aber serverseitig nicht die vollen 6,7 MB benötigt werden. Je nach den Anforderungen kann es aber bei der Konvertierung von einem verlustbehafteten Format (JPG mit 70-80%) in ein anderes verlustbehaftetes Format (JPEG2000) zusätzliche Verluste geben. Für die Übertragung zum Viewer des Betrachters sind auf jeden Fall die kleineren JPEG2000 Dateien relevant (für die verwendete Bandbreite). Viewerseitig müssen die Grafiken natürlich beim Betrachter wieder entpackt werden und erfordern daher wieder den vollen Speicherplatz im Texturspeicher der Grafikkarte. Daher wäre es evtl. sinnvoll, die Texturen, die nicht so intensiv betrachtet werden zu verkleinern, da z.B. eine 64x64 Pixel große Textur wesentlich (16x) weniger Speicher benötigt, als eine 256x256. Der Texturspeicher ist sehr begrenzt, da OpenGL nur 512 MByte dafür verwenden kann, unabhängig vom vorhandenen Haupt- oder Grafikkartenspeicher (das ist zumindest mein aktueller Wissensstand).

Ciaoo

Sheera

[Christoph Balhaus]

Die Gründe für die Begrenzung auf 512 MB Texturspeicher in der GPU hat Bao Linden mal in diesem Jira https://jira.secondlife.com/browse/SH-2547 geliefert.

Im wesentlichen liegt es daran, weil der Viewer im Hauptspeicher das 1.5 fache an Swapspeicher für die Texturen reserviert um sie dort für die GPU vorhalten zu können. Das sind bei 512MB GPU Speicher 768 MB Hauptspeicher. Viel mehr geht nicht, weil das sonst, zusammen mit dem restlichen Bedarf des Viewers, die Grenzen für 32bit Programme sprengen würde.

[Manfred Aabye]

Also hier sitzen jetzt 20 Hyperventilierende Anfänger
völlig verzweifelt herum
und verstehen die Welt nicht mehr

.

[Shamara Yoshikawa]

Also, ich hyperelefantiere ned, sonder versteh sehr gut was die Leutz mir sagen wollen

Dat nämmlich scheiss egal ist, wie man kompromitiert, ab 512 Grafikspeicher dank openGL, kann man noch auf 0 kompromitieren, da gibt sich nix mehr ^^

und was auch noch gut zu knownen ist (knowning, sie werden kommen ) das insgesammt ca. 1,2GB an gesammt Grafikspeicher rum ist, 512mb fürs grafikkärtchen, und der rest der 768mb für Grafiken entpackerln, verpackerln, etc...

Oder einfach gesagt, ich kapiers
Und jipp, so früh am Morgen darf ich so schreibstüteln...
Sayonara die Shamara

[Klarabella Karamell]

Kreatives Schreiben am Morgen is doch in Ordnung
Ich versteh zwar nur Bahnhof, aber dem zementiert mir nicht, so lange mir bewusst ist:
Punkt Punkt Komma Strich fertig ist das Mondgesicht
ist deutlich kürzerer als:
Die funkelnden Sterne in ihren von perfekten Brauen gesäumten schwarzen Augenseen standen wie Lagerfeuer rastender Wanderer vor dem steilen Aufschwung des Nasengebirgs, das von seinem Gipfel steil abfiel zu einem Schlund wie aus Rosenblättern geformt, in dem wie Mondstein leuchtende weisse Zähne schimmerten, über die ab und an das rosafeuchtglänzende Zungentier fuhr, damit nichts ihren glatten Schein stören konnte.
Uff

[Sheera Khan]

Huhu Manni,

dann mal für die 19 verbleibenden hyperventilierenden Anfänger ^^

egal in welchem Grafikformat man seine Texturen erstellt und wie groß sie auf der eigenen Festplatte sind: der Viewer skaliert die Grafik so, dass die Kantenlänge des Bildes 8, 16, 32, 64, 128, 256, 512 oder 1024 Pixel beträgt. Anschließend konvertiert der Viewer das Bild in das JPEG2000 Format und lädt die Datei dann auf den Server, wo sie als Asset vorliegt (Regions-Cache usw. lasse ich gerade mal außen vor). Ein Betrachter dieses Bildes muss natürlich diese Datei erst herunterladen (das macht der Viewer schon für ihn). Dabei wird eine gewisse Bandbreite benötigt - um so mehr, je größer die Datei ist. Es wird aber nicht die Originaldatei übertragen, sondern nur die komprimierte JPEG2000-Datei. Um die Datei anzeigen zu können muss der Viewer die Datei wieder entpacken und im Grafikspeicher vorrätig halten. Die entpackte Datei kann dabei vergleichsweise groß werden:
1024x1024 => 3 MiByte ohne Transparenz, 4 MiByte mit Transparenz
256x256 => 0,8MiByte / 1 MiByte
64x64 => 12 kiByte/ 16 kiByte
Da nur max. 512 MiByte Texturspeicher zur Verfügung stehen, können die also mit 128 vollformatigen Grafiken bereits ausgeschöpft sein! Ab dann müssen die Texturen immer wieder neugeladen werden, weil zwischendurch der Platz für andere Grafiken benötigt wird. Das dürfte sich dann bemerkbar machen u.A. durch einen ständigen unscharf/scharf-Wechsel der Texturen und allgemein durch "Lag"...

Möglicherweise verwendet die Grafikbearbeitungssoftware bessere Algorithmen für die Skalierung der Grafiken als der Viewer, daher lasse ich diese Arbeiten üblicherweise durch Gimp erledigen. Um weiteren Qualitätsverlusten vorzubeugen, erstelle ich meine Grafiken in einem verlustfreien Format (meist TGA, aber auch BMP und - mit entsprechender Einstellung - PNG) und lasse diese Dateien dann durch den Viewer in das JPEG2000-Format konvertieren und hochladen.

Außerdem behaupte ich mal, dass nicht die Qualitätseinstellung beim Speichern der Grafik entscheidend ist, sondern die Größe der Textur. Wenn ich auf Details verzichten kann verwende ich also lieber eine kleinere Textur mit hoher Qualität als dass ich die große Textur mit einem höheren Kompressionsgrad abspeichere, denn dadurch spare ich der Grafikkarte unnötige Speichermengen ein.

Gerade bei den Meshes, die ja bis zu acht Texturen verwenden können kommt da einiges zusammen. Außerdem können Mesh-Kleidungsstücke die volle Auflösung nutzen, während die Systemklamotten auf 512x512 Pixel begrenzt sind. Daher sehen Meshes - richtig gemacht - sehr viel besser aus, können aber die Grafikkarte deutlich stärker belasten. Es hängt eben stark davon ab, wie der Ersteller mit den Möglichkeiten umgeht.

Ich hoffe, dass ich das nun halbwegs verständlich und dennoch zutreffend darstellen konnte...

Ciaoo

Sheera

[MoniTill]

Ich lege noch ne Schippe drauf
Bei Meshes spart man am meisten mit Recycling von Texturen. Meine Balkentextur habe ich inzwischen 4x komplett neu gemacht. Im rechten Teil neben dem Kopfholz ist nun noch altes Eisen. 512 Pixel sind für einen einzelnen kleinen Hammer zwar ziemlich überdimensioniert, aaaaber wenn die gleiche Textur für alle Holz-Eisen Werkzeuge und bei allen Möbeln in der mittelalterlichen Werkstatt verwendet wird, hätten es auch locker 1024 sein können. Einmal übertragen und in der GPU gelandet, ist sofort alles da. Und beim Texturspeicher spart man mit einer großen Textur für viele Objekte auch wesentlich mehr ein als mit vielen kleinen Texturen

[Manfred Aabye]

Also @Sheera das ist mal eine klasse Erklärung, dafür hast du dir einen Pokal verdient.
Schade das nicht alles so toll erklärt wird.

   

Den Pokal stell ich in der Metro auf die Sandbox.

Nein das ist kein Sarkasmus das ist ehrlich gemeint.

[Uwe Furse]

Da nur max. 512 MiByte Texturspeicher zur Verfügung stehen, können die also mit 128 vollformatigen Grafiken bereits ausgeschöpft sein!

Wo durch wird den der Texturspeicher limitiert? Durch den Viewer?