• 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.

Feine Textur für einen kleinen HUD, wie macht man das?

Wenn ich in Photoshop ein Bild mit 300DPI und 1024px erst einmal als PNG oder JPG (je nach dem was ich gerade benoetige) separat speichere, ist es erst einmal riesen gross.
Nun oeffne ich das neue gespeicherte Bild einfach und verkleinere es, siehe da, das 128px oder 256px oder 512px Bild hat ja immer noch 300DPI.
Das bedeutet, das die Quallitaet beim verkleinern nicht so gelitten hat, wie vergleichsweise eine Verkleinerung mit einem 72DPI Bild.

Das hat alles noch ueberhaupt nichts mit dem Upload nach Second Life zu tun. Mir ging es einzig und allein um die Verkleinerung vor dem Upload, um bei einem Eventuellen Upload in Second Life ein besseres Ergebniss zu erhalten. Welche Bildinformationen beim Umkomprimieren durch Second Life verloren gehen ist mir dann auch ziemlich egal, solange das Bild gut aussieht.

LG
Dae
 
Jenna, du bist in den Bereich der Iconzeichner eingetaucht.

Das Ausgangsmaterial ist quasi bedeutungslos, egal ob 300x300 oder 6000x6000.
Wir bewegen uns in Bereichen, wo wir etwas Komplexes in 16x16, 32x32 oder immerhin 48x48 Punkten hineinquetschen wollen.
Nahezu jedes "gute" Icon ist handgezeichnet, ein endloses Gefriemel mit manuell plazierten Punkten in allen erdenklichen Farbnuancen.
Wir simulieren 3D mittels Farbton und Grauwert. Das läßt sich nur ansatzweise programmiertechnisch erleichtern weil es ein sehr
subjektives visuelles Empfinden ist und nicht nur berechnete Farbwichtungen.

Deine dünnen Bogenlinien sind eine der schwierigsten Formen.

Wie hast du das Ausgangsbild erstellt?
Vesuche es mit Vektorgrafik, die bleibt verlustfrei skalierbar und bitte nicht zu klein erstellen, je grösser das Ausgangsmaterial desto besser.
(Skins für SL bearbeite ich zb in Auflösungen um die 5000x8000 herum)

Gerendert wird erst gegen Ende, dafür würde ich dann png empfehlen wegen der möglichen Transparenz

(PS: wo Dae es gerade anspricht, dieses Icon lädst du dann natürlich verlustfrei hoch, sonst ist die ganze Arbeit futsch)
 
Danke dir auch Diana :)

Jenna, du bist in den Bereich der Iconzeichner eingetaucht.

Ja, diesmal richtig :) Meine vorher erstellte Icons für Eigenbedarf-Programmchen waren meist zusammengeklaut.

Wir bewegen uns in Bereichen, wo wir etwas Komplexes in 16x16, 32x32 oder immerhin 48x48 Punkten hineinquetschen wollen...
Deine dünnen Bogenlinien sind eine der schwierigsten Formen.

Ja, bis die Größe 256x256 war das Bild noch perfekt erhalten. Bei der Größe 128x128 noch passabel, und bei 64x64 war der Effekt stark verschlechtert. Darauf hätte ich ableiten sollen, ich kann den Effekt nicht in die noch kleinere Größe quetchen durch Skalieren.

Wie hast du das Ausgangsbild erstellt?
Vesuche es mit Vektorgrafik, die bleibt verlustfrei skalierbar und bitte nicht zu klein erstellen, je grösser das Ausgangsmaterial desto besser.

Ausgang war eigentlich ein Gerät das ich schon habe seit Jahren, es besteht aus einer Reihe von Ringen, die eine Weltkugel (die SL Grid) in einem Kreis (ein Teleport) symbolisiert. Es wird normalerweise am Oberarm getragen, diesmal soll eine Weiterentwicklung sein und ich wollte sie am Hud tragen lassen. Primringe direkt am Hud sehen doof aus (zimmlich eckig), daher wollte ich ein schönes Icon dafür machen. Also habe ich die Kreise nachgezeichnet und mit Goldglanz aufgepeppelt.

Erstellt habe ich eigentlich in Paint.Net, mit einem Plugin ("Bevel Selection") ist hier ein 3-dimensionaler Farbverlauf möglich. Das ist aber eine Pixelgraphik. Bei der Vektorgraphik hast Du recht, man könnte sie tatsächlich hoch und runter skallieren ohne dass die Qualität leidet. Habe mich aber ans Program dafür nicht getraut.

Ich habe mich bezüglich der Graphik umentschieden, die hübsche Nachzeichnung kommt auf die Produktbox als Symbol im großformat. Und am Hud kommt eine stilisierte Darstellung, also Icon das die Darstellung abstrahiert aber die gewählte Symbolik (Weltkugel im einem Ring) beibehällt. Am Design dafür grübbele ich noch. Der Hud muss nämlich noch die Gerätestati anzeigen (An, Aus, Restricted, Nachfrage.)

Es wird immer interessanter irgendwie
 
Wenn ich in Photoshop ein Bild mit 300DPI und 1024px erst einmal als PNG oder JPG (je nach dem was ich gerade benoetige) separat speichere, ist es erst einmal riesen gross.
Nun oeffne ich das neue gespeicherte Bild einfach und verkleinere es, siehe da, das 128px oder 256px oder 512px Bild hat ja immer noch 300DPI.
Das bedeutet, das die Quallitaet beim verkleinern nicht so gelitten hat, wie vergleichsweise eine Verkleinerung mit einem 72DPI Bild.

Öhm.. Dein 1024 Bild mit 300 dpi ist erst mal 1024 pixel/300 pixel pro inch = 3.3 inch x 3.4 inch also 8.6 x 8.6 cm groß.
Und wenn du daraus ein 256 x256 Bild machst, dann hat das immer noch 300dpi und ist 256 px/300dpi x 256px/300dpi = 0.8 inch x0.8 inch oder 2,1 x 2,1 cm groß.

Ein Bild in 72 dpi mit 1024 px ist erst mal 1024 pixel/72 pixel pro inch = 14.2 x14.2 inch groß, also 36,1 x 36,1 cm.
Das 256 x256 Bild daraus ist 256px/72dpi = 3.5 inch x 3.5inch = 9 x9 cm groß.
Wenn man diesen Bild nun aber Umstellt umstellt auf 300dpi, dann wird das Bild 0.8 inch x 0.8 inch oder 2.1 x2.1 cm groß. Und ist wieder identisch mit dem obigen Bild.
Da gehen also nirgendwo Bildinformationen verloren, es werden auch keine Bildimformationen erzeugt bei anderen DPI. Die Pixel werden lediglich beim Ausdruck über eine größere oder kleinere Fläche verteilt.

==> Die DPI sagen überhaupt nichts über die Qualität der Bilddatei selbst aus, sondern nur über die Pixeldichte selbst.
Maßgeblich für die Qualität eines jpeg oder png Bildes ist nur die Bildgröße selbst (hier: 1024x1024 px oder 512x512 px) und die Art udn Weise der Kompression durch den Codec.

2s67ndk.png
und
2nh233c.jpg


Einmal mit 72 dpi und einmal mit 300 dpi skaliert auf 256 px von 1024 px aus.
 
Warum beharrst du stur auf graue Theorie und akzeptierst nicht, das die Praxis einfach ganz anders aussieht?
Wiso willst du die Bilder eigentlich immer drucken? Das interessiert in Second Life nicht mal die schlecht gewordene Kaffee-Sahne.
Bis jetzt hat sich fuer die Darstellung in Second Life immer als Positiv erwiesen, bei einer einfachen Verkleinerung eines bestehenden Bildes eine hohe DPI-Zahl auf einem sehr Grossen Bild zu verwenden, welches man offline erst so abspeichert und dann vor dem Upload auf die entgueltige Groesse verkleinert.

Fuer die direkte Erstellung solcher kleinen Icons halte ich Diannas Vorschlag aus Beitrag #22 immer noch am geeignetsten.

LG
Dae
 
Ich will nix drucken, aber dpi beziehen sich nur auf den Druck nacher. Das sind die Dot Per Inch, Der Abstand der Pixel/Druckpunkte auf dem Papier, mehr nicht.
In SL wird aber Pixelgenau gerechnet und der Abstand zwischen den Pixeln ist wurscht, vermutlich deshalb seh ich da auch keinerlei Unterschiede in SL.

Aber wenn der DPI-Voodoo bei dir funktioniert, viel Spass damit. Und vergess nich den Router zu resetten ,-)
 
Dpi beziehen sich nur auf den Druck nachher, dem kann ich nicht zustimmen.---> Hätte ich tuen sollen.

Dpi sind also die Anzahl der Dots per Inch, dann gibt auch ppi Pixel per inch ist der Zusammenhang wieviele Pixel auf auf einem Inch verteilt sind. Soweit, sogut.---> Mal leicht geändert das es der Realität entspricht.

Es sind nicht nur Bildinformationen, bei einem Druck sieht man deutlich Qualitätsunterschiede, wenn das Bild in geringerer Auflösung als die erforderlichen 600 oder 300 Pdi gedruckt wird istes viel grobkörniger.

Zur Darstellung auf Webseiten nimmt man mindestens 72 dpi, bzw. (heute 96 dpi wegen neuer Monitorauflösungen), weil man die Unterschiede mit dem Auge nicht wahrnehmen kann und das Laden der Seite schlichtweg zu lange dauern würde. Geringer sollte die dpI Anzahl aber nicht sein, weil man auch da sonst Qualitätsverluste hätte.

Was die Bearbeitung betrifft, ist es für mich nur logisch, das man mit einer hohen Pdi Anzahl, sprich vielen Bildpunkten arbeiten sollte. Gerade auch wenn man auch in mehreren Durchgängen schärft. Verluste an Bildqualität ergeben sich durch die Bearbeitung schon genug.

Ich stelle auch beim Fotografieren fest das ich Raw Dateien, die in Megaauflösung sind einfach besser bearbeiten kann, es ist mehr möglich damit. Dabei geht es mir gar nicht um den Druck.

Auch wird die Qualität der Bilder mit mehr Megapixeln einfach besser, auch wenn ich dann immer sehr gründlich Staubwischen muss, möchte ich das doch gar nicht anders.

Was ich damit sagen möchte, für Vodoo halte ich das jetzt nicht.

Ergänzung:
Missgeschick bei der Aussage "DPi beziehen sich nur auf den Druck nachher, dem kann ich nicht zustimmen." Autsch. Stuss geschrieben. Mit PPi wäre die Aussage zutreffender gewesen.
Dann: von 90 dpi auf 96 korrigiert bei den Monitorauflösungen.

Mehr dazu später, wenn ich mir Shirleys Antwort komplett durchgelesen habe. Muss erstmal ein wenig arbeiten:razz:
 
Zuletzt bearbeitet:
sorry hier muss ich Shirley auch mal zur Seite springen.
Geesk lies doch bitte deinen eigenen Post noch einmal durch und reflektiere ihn auf den Sachverhalt hier....

"Ich gestalte eine Webseite und bringe ein Bild dort ein, das ein Inch gross ist (über html-tag)" ...
Normale Monitore die eine 72 DPI-Auflösung haben zeigen ein 72 DPI Bild in idealer Auflösung an.
Alle anderen DPI Einstellungen führen zu Umrechnungen ... Verschlechterungen.

Die Erwähnung des RAW-Formates ist hier auch unangebracht.
RAW ist im digitalen sowas wie ein Negativ des analogen Zeitalters. Klar stecken da mehr Infos drin durch die Bittiefe des Formates. ABER man MUSS diese Negative erst entwickeln (was die wenigsten können).
 
Zuletzt bearbeitet:
Die DPI, dots per inch, haben aber überhaupt nichts mit der physikalischen Auflösung, d.h. den Pixelmaßen zu tun. Das sind 2 völlig verschiedene Dinge.
Und ein Bild mit 500 pixel mal 500 pixel nur auf "72 dpi" einzustellen bringt auch nichts für das Web. Das ist im Browser auf dem Monitor immer noch 500 x 500 pixel groß,wenn man dem Browser nicht explizit sagt, dass er das auf x mal y cm skalieren soll.
D.h. die Qualität einer digitalen Bilddatei hängt eigentlich in erster Linie nur von der physikalischen Auflösung ab. Und ich spreche hier wirklich nur von der Bilddatei respektive ihrer Qualität.

Und was die geänderten dpi angeht: Angenommen du hast ein Bild mit 1000 x 1000 Pixeln, bei dem "600 dpi" eingestellt sind. Dann ist das Bild 4.2 x 4.2 cm groß.
Wenn du nun einfach die dpi änderst, dann ist das Bild immer noch 1000 x 1000 Pixel groß, hat aber nur noch "300 dpi", womit es aber 8.4 x 8.4 cm groß wäre.
Wenn das Bild aber nacher noch genau so groß sein soll mit 300 dpi, dann musst du es umrechnen. Dann ist es immer noch 4.2 x 4.2 cm groß - aber du hast auch nur noch 500 x 500 Pixel. Und weil du weniger Pixel hast wird das Bild dann mit "weniger dpi" auch grobkörniger. Das ist ganz einfache simple Mathematik. 4. Klasse, Grundrechenarten. Bildgröße (in Maßeinheit) = Pixelmaße (in pixel) geteilt durch Pixeldichte (in pixel pro Maßeinheit).

Hier geht aber eigentlich erst mal nur um das Umrechnen von einem Pixelmaß (1024 px) in ein anders Pixelmaß (512 px).
Dafür gibt es mehrere Methoden, die hier: Interpolation (Fotografie) bestens erklärt werden.
Und wie man da wunderschön sieht spielt weder bei der Pixelverdoppelung, noch bei der einfachen Interpolation noch bei der bikubischen Interpolation die Pixeldichte überhaupt irgendeine Rolle. Nicht die geringste. Ein Bild mit den selben Pixeln und den selben Pixelmaßen, das auf die selbe Methode skaliert wurde hat immer die selben Pixel, egal ob das Bild nun 10 000 dpi oder 1 dpi hat.

Und auch in SL spielt die im Bild eingestellte Pixeldichte überhaupt keine Rolle. Denn die z.B. 1024 x1024 pixel einer Textur werden auf eine 2 Dimensionale Fläche auf dem Monitor projiziert. Dazu wird das Bild einmal entsprechend verzerrt und dann eben noch skaliert. Und je nach geometrischer Verzerrung der Winkel und größe der Fläche werden die 1024 Pixel x 1024 Pixel eben entsprechend skaliert. Aber gehen wir mal von einem Idealfall aus, um die optimale Qualität zu erhalten. Nehmen wir einfach mal an, das angezeigte Bild des Viewer sei genau 1024 pixel hoch. Und man attached ein Prim mit 1x1m als Center HUD. Der füllt dann die komplette Höhe des Viewer Bildes genau aus. Wenn man da nun eine Textur mit 1024x1024 pixeln drauf macht, dann entspricht 1 Pixel der Textur genau 1 pixel auf dem Monitor - und zwar egal, ob das Bild mal mit "1 dpi" gespeichert wurde, oder mit "100000 dpi". Einfach weil das a) sowieso nicht ausgelesen wird aus dem jpeg und weil b) diese Information in SL eh verloren gehen würde, da werden die DPI der Texturen mit jeder Kamerabewegung neu berechnet (und damit auch die Pixelmaße..), d.h. ein Objekt weiter hinten hat halt nur noch 23 x 30 Pixel, auch wenn da eine 1024x1024 Textur drauf ist, die man mit 1024 x 1014 Pixeln sehen kann, wenn man das Ding als Hud attached.

Die DPI sind wirklich nur Meta-Informationen im Bild, die einem Ausgabegerät sagen können, auf welche Fläche die x mal y Bildpunkte verteilt werden sollen, d.h. die hängen nur mit der Ausgabegröße zusammen - mit der Qualität des digitalen Bildes selbst hat das überhaupt nichts zu tun. Diese hängt, wie gesagt, nur vom Pixelmaß ab. Und kann allenfalls durch eine verlustbehaftete Kompression noch weiter gemindert werden.
 
Zuletzt bearbeitet:
@ Sumi

Reflektion auf das Thema (????- Autsch, diese Belehrung klingt jetzt schon etwas nach Frau Rottenmeier und hätte nicht sein müssen). Es ging bei diesem Tread um die Bildqualität. Ich versuchte eine Logik herzuleiten, warum bei höherer Punktedichte eine mögliche bessere Bearbeitung gewährleistet sein kann.

Dabei ist mit einfach nicht klar warum ich Pixel schon vor der Bildbearbeitung verschenken soll, die Bildinformationen enthalten.

Dazu hätte ich mir eine Antwort gewünscht. Diese Antwort hat Shirley ja nun ziemlich ausgeführt und ich beschäftige mich auch immer noch damit…

Wenn man allgemein über Punktedichte redet, dann zählt Raw und die hohe Auflösung da doch ebenfalls herein. Diese Beispiel sollte verdeutlichend wirken. Von daher passt es zum Thema.

Und übrigens:
Kameras, die RAW Dateien erstellen können, denen liegen auch in den meisten Fällen verbraucherfreundliche Software zur /Entwicklung und Bearbeitung von Raw Dateien bei. Ebenfalls kann man diese käuflich erwerben.
Somit ist der Punkt, das RAW Dateien nur wenige entwickeln können, nicht mehr zeitgemäß.

Äh, und was unangebracht ist in einem Tread zu schreiben oder nicht, solle man das nicht besser dem Schreiber überlassen?
 
@ Shirley: Ja, irgendwie wollte ich es so ausdrücken, dass nur die Pixel zählen, nicht die DPIs. War schlecht formuliert (man sollte nach der Spätschicht wohl nicht mehr Posten :oops:)
@ Geeske: Es geht doch hier in dem Thread nicht um allgemeine Bildqualität sonder um eine spezielle. Daher bleibe ich dabei (wer ist Frau Rottenmeier, bitte um Aufklärung, habe keine Lust zu googlen). Die Tatsache, dass Software bei den Cams dabei liegt, hat auch nur theoretisch etwas damit zu tun, dass man RAWs bearbeiten kann, die meisten können es trotzdem nicht (oder grottig schlecht :D).
 
.................(wer ist Frau Rottenmeier, bitte um Aufklärung, habe keine Lust zu googlen)...................

noch nie Heidi gesehen ? *g*
vergessst doch einfach mal das es DPI gibt da es nur mit "drucken" zu tun hat und Vektor basierten Grafiken.
Bei guten Grafikprogs kann man die komprssionsrate von JPG einstellen so das sie qualitatif so gut wie RAW sind aber viel weniger Speicher brauchen.
Ausserdem ist RAW nicht nur grafik sondern auch Text mit drin (Kameraeinstellungen)
 
@Sumy:
Wenn ich vorher gelesen hätte, dass du was geschrieben hattest hätte ich wohl nichts mehr geschrieben, gabs wohl eine Zeitliche Überschneidung bzw. ich hatte die Seite zu lange offen und nicht neu geladen vor dem Schreiben ,-)


Ansonsten:

RAW-Dateien: Im Prinzip ein Rohdatenformat aus der Kamera, d.h. im Header der Datei stehen Dinge wie verwendete Brennweite, Blende, Zeit/Empfindlichkeit, Datum, Kameramodell usw. und im Datenteil sind direkt die Messwerte der einzelnen Pixel in der Kamera gespeichert, ohne dass sie bearbeitet wurden. D.h. die einzelnen Pixel haben eben noch keine Farben, sondern sind rot, grün und blau mit Unterschiedlicher Helligkeit. Um daraus ein Bild aus bunten Pixeln mit je bis zu 16 Mio Farben zu machen muss die Software in der Kamera das erst noch umrechnen. Und noch Schärfen. Und statt der Kamera kann das auch eine Software am PC machen, so dass man den Weißpunkt, die Schärfung usw. individuell anpassen kann.
Ansonsten haben RAWs aber keinen weiteren Vorteil gegenüber einem anderen Bild bei der weiteren Verarbeitung.

Bitmap: Das Raster des digitalen Bildes. Jeder Pixel ist eigentlich nur ein Zahlenwert an einer definierten Position. Im einfachsten Fall hat man nur weiß oder schwarz, und dann kann ein digitales Bild z.B. so aussehen: {<0,0,0,1,1,0,0,0><0,0,1,0,0,1,0,0><0,1,0,0,0,0,1,0><1,0,0,1,1,0,0,1><1,0,0,1,1,0,0,1><0,1,0,0,0,0,1,0><0,0,1,0,0,1,0,0><0,0,0,1,1,0,0,0>}
( Dabei ist dann <...> eine Zeile, 1 steht für schwarz und 0 für weiß.)
Und das Bitmap sieht so aus:
33w5npz.png

Pixelmaße: Die Anzahl der pixel im Bild. das oben hat z.B. 8x8 Pixel = 64 Pixel insgesamt.

DPI
: Pixel pro Zoll, die Pixeldichte.
Das Bild hier
11kbde8.png
hat nur halb so viele DPI wie das Bild oben, aber immer noch 8x8 Pixel. Deswegen sind die Pixel einfach weiter auseinander.
Man kann sie daher auch größer machen
xftfrp.png
- Aber weniger Details oder eine Schlechtere Qualität hat man dadurch eben nicht.
Und umgekehrt bringen hohe DPI erst mal keine bessere Qualität. Das Bild wird einfach nur kleiner dadurch.

Wenn man mehr Details im Bild will, eine bessere Qualität, muss man eben das Pixelmaß ändern, und statt 8x8 eben 16x16 Pixel benutzen.
f8dmv.png


Und genau deswegen sieht das HUD Element, um das es hier geht, in SL gleich aus, egal ob man es mit 300 dpi oder 72 dpi speichert, einfach weil die 64x40 oder 128x80 sichtbaren Pixel der Textur im besten Fall auf die 64x40 oder 128x80 Pixel auf dem Monitor abgebildet wird. Und im schlechtesten Fall auf z.B.60x73 oder 120 x 75 Pixel, womit die Textur durchs Skalieren leider unscharf werden wird. Die Dpi, die letztendlich dabei verwendet werden sind dann die DPI des jeweiligen Monitors.
 
Zuletzt bearbeitet:
Ich weiß nicht ob der DPI Trick funktioniert hat, weil ich in einer größeren auflösung nachgezeichnet habe oder weil ich überhaupt nachgezeichnet habe. Also prinzipiell verstehe ich auch, dass DPI nur für den ausdruck relevant ist, und außerdem ist bei mir die Bildgröße bitgenau dieselbe wenn ich ein Bild mit 72dpi oder 300dpi erstele und als bmp und png abspeichere. Nur beim zweiten Mal war das bild besser geworden am bildschirm. Aber nicht für den HUD, da ist die Qualität nachgelassen ab verkleinerung auf sichtbare 78 oder so Pixeln. Bei Vendorbilder machen ist die Vorgehensweise jedenfalls gut (so groß wie möglich erstellen und dann ein oder zweimal verkleiner mit schärfen)

Als Zwischenbericht, vieleicht sogar Endbericht. Ich habe das Bild als Vectorgraphik gemacht. In Vektoren zeichnen ist doch nicht so schlim, wie ich dachte. das Grundgerüst oder Glaseffekt geht fix, sofern man Tutorial findet. Nur die Piktogramme, davon kriegt man Zahnschmerzen. Auch in mm rechnen statt in Pixeln ist etwas gewöhnungsbedrftig :)

Das neue Bild ist natürlich anders, nur die Symbolik ist dieselbe. Hier als Beilsipel das Musterbild für einen von 4 Zuständen:

attachment.php

Ich habe es 100 mm groß gemacht (bei 300 dpi, hier also im Original Vektorbild habe ich schon die hohe DPI Zahl genomen), für das Forum auf 128 Pixelbreite dann skalliert, sonst würde es aus dem Bildschirm fallen.

Dabei muss man doch reichen bei Linienbreiten. Wenn der HUD-Bereich 1m hoch ist und der Viewer im Fenster der Höhe 768 Pixel läuft, dann kommen knapp 77 Pixel pro 10cm am HUD. Oder 35 im Bereich, den das Icon einehmen wird. Wenn das Bild im Vektorprogram also 100mm groß ist, dann müssen die Linien mindestens 3mm breit sein, damit sie nicht verschwimmen. Das war also meine Mindestbreite, bei Piktogrammen habe ich sogar etwas dicker gemacht. Ich habe dan das Bild in Größen 32 bis 256 Pixel pro Teilbild exportiert und die hochgeladen. So sehen die Bilder dann am Hud aus:

attachment.php

Ist schon was ganz anderes als am Anfang :) Nur an den Rändern muss ich noch arbeiten. Diesmal fallen die hellen Punkte bei dunklen Huntergründen auf, bei hellen Hintergründen ist der rand perfekt. Wobei sie weder im Original noch in den skallierten Ergebnisbldern vorhanden sind. Daran muss ich noch tüfteln, aber die Frage wie man die Icons macht ist somit erledigt, man macht direkt kleine Icons statt große Bilder herunterskallieren.

Danke jedenfalls für Eure Tips und Informationen.

Andere Sache. Wie man am Musterbild sieht, 32x32 Pixel pro Bild nehmen ist zu wenig, aber ab 64x64 machen die Bilder gar keinen besonderen Unterschied. Daher ist mir fraglich, warum die Huds die ich habe (AOs usw) alle Bilder von 256 Pixelbreite für Icons benutzen. Freebybilder fürs Tapezieren von Wänden oder Dekos können auch 16x1 sein aber nicht die Iconbilder für den HUD :) dabei sind die Bilder trotzdem in der Graphikkarte und zwar ständig.

Die Größe von 64 würde bei starken vergrößerung noch leiden, aber die Größe von 128 Pixel sollte schon bei weitem langen.
 
Zuletzt bearbeitet:
Die hellen Hintergründe können vom png (oder tga) mit Transparenz kommen, das hochgeladen wurde.
Manche Programme (--> Photoshop z.B., bei Illustrator weiß ich es nicht) speichern 100% transparente Pixel immer als weißes Pixel ab, da sich das Bild dann als (png oder tga) viel kleiner komprimieren lässt. Man spart so ein paar Bytes bei der Dateigröße, und transparente Pixel sieht man eh nicht. Allerdings gibt genau das Probleme beim Interpolieren, wenn man ein Bild skaliert. Und die Texturen in SL werden ständig skaliert, mit jeder Kamerabewegung anders. Dann muss die GPU zwischen das Transparente Pixel und das dunkle Pixel ein neues Pixel rein rechnen. Oder ein Pixel herausrechnen. Womit das neue Pixel nicht nur halb transparent wird, sondern auch nicht schwarz, sondern grau, weil das transparente Pixel daneben eigentlich weiß ist. Und in SL sieht man eben diesen Halo-Effekt.

Wenn man noch mit tga arbeitet, dann kann man mit einem Solidify-Filter von Flaming Pears arbeiten, eine Alpha Layer braucht man sowieso, weil tga keine Transparenzen kennt. (https://www.robinwood.com/Catalog/Technical/SL-Tuts/SLPages/WhiteHalo.html)

Arbeitet man mit png, dann braucht man diesen Filter nicht, wenn man die Farbwerte auch bei Transparenten Pixeln mit speichert. Geht z.B. mit Gimp. Und wenn man mit PS arbeiten möchte, dann muss man das Bild eben als psd speichern um es dann z.B. in Gimp zu öffnen und dann dort als png zu exportieren (mit beibehaltung der Farbwerte), dann werden die transparenten pixel ebenfalls nicht "weiß".
 
Ich habe da mit der Transparenz auch so meine Probleme und was komisches gefunden:
Bei diesem Bild sieht man den Textaufbau, könnte auch mal ein HUD werden. Vorne 2 Klötze mit den blauen Punkten und dahinter ein weißer Klotz. Beide Punkttexturen sind um den Punkt außenherum 100% transparent, der Punkt selbst ist 0% transparent. Beim linken Punkt ist als Unterschied zum rechten Punkt noch ein 50% transparenter Kreis in der Mitte. Und der macht echt den Unterschied. Siehe 2. Bild.
7758372116_1f26a547a2.jpg


Beim 2. Bild schaut man nun genau von vorne auf den Versuchsaufbau. Was fällt auf? Genau, der Rand des blauen Kreises im rechten Bildteil ist nicht weichgezeichnet, links schon. Kann das einer von euch erklären? Es liegt an den 50% transparenten Kreis links, aber wieso?
7758372230_20be99879a.jpg


Aber ich habe noch mehr gefunden: Wenn ich beim rechten Würfel im Baumenü die Transparenz der Fläche z.B. auf 2% stelle, dann ist plötzlich der Rand weichgezeichnet und sieht exakt so aus wie auf dem linken Würfel. (Nur ist logischerweise jetzt auch der blaue Punkt leicht transparent, was ein ungewünschter Nebeneffekt ist. Aber es geht ja um die Weichzeichnung der Ränder und die Gründe für dessen Scheitern.)
7758458860_d3980100a5.jpg


Als würde die Alphamap erst jetzt als Graustufenmap interpretiert und im ersten Fall nur als S/W-Map. Das bedeutet, die Alphamap in der Textur, so wie sie bei SL nun auf dem Server liegt, hat 8 Bit (Graustufen), wird nur nicht richtig interpretiert. Dann kann es also nicht an meinem PNG-Original-Bild liegen, auch nicht an der JPG2000 Umwandlung bei SL, sondern irgendwo später passiert da was.

Das brachte mich auf eine weitere Idee: Ich mache für den rechten Würfel, in der Textur, die Transparenz des Hintergrunds nicht 100%, sondern z.B. nur 95% und brauche nicht im Baumenü tricksen. Ja, schön gedacht, aber das Ergebnis ist genau das gleiche, nicht weichgezeichnete Ränder. Der 95% transparente Hintergrund wird wieder als 100% transparent dargestellt. Das korrigiert sich quasi erst, wenn ich im Baumenü wieder die 2% einstelle.

Der linke Würfel zeigt aber, wenn die Transparenz in der Textur nicht all zu hoch ist, bzw. ein (größerer*) Teil der Textur eine mittlere Transparenz hat, wird es korrekt dargestellt. So als ob der Viewer denkt, jetzt kann er es sich nicht mehr einfach machen mit nur 0% und 100% durchsichtig, jetzt muss er mal wirklich Teil-Transparenz darstellen. Der geschilderte Effekt tritt übrigens mit Firestorm und SL-Viewer identisch auf.

Übrigens, wenn ich das Testteil als HUD anziehe, wird es in allen Testfällen korrekt dargestellt! Mir scheint das Transparenzproblem eines zu sein, das nur in der 3D Welt beim Rendern auftritt.


*) Ja, ich habe mal zum Testen in die Textur einen einzigen Pixel mit 50% Transparenz in eine Ecke gesetzt. Das hatte keinen Effekt. Offenbar müssen hinreichend viele Pixel eine hinreichend mittelere Transparenz aufweisen, damit der Viewer das kapiert.
 
Zuletzt bearbeitet:
Hast du schon mal mit verschiedenen Einstellungen im Grafiktreiber rumgespielt?
Eventuell musst du SL dafür neu starten, aber je nach Einstellung der Texturqualität, der Art und Weise des Antialiasing und der Anisotropen Filter kann ein gerendertes Bild etwas anders aussehen.
 
Ich würde sämtliche Filter komplett abschalten, die verfälschen nur die Ergebnisse oder erzeugen eigene Effekte.
(also insbesondere Anisotropischer Filter, Antialiasing, lokales Licht, ggf sogar noch die Shader) oder direkt in der "Nvidia Systemsteuerung" wie sich das Ding neuerdings hochtrabend nennt, sämtliche Filter (in 3D Einstellungen) auf aus (dh: NICHT anwendungsgesteuert)
 
Hast du schon mal mit verschiedenen Einstellungen im Grafiktreiber rumgespielt?

Hi Shirley. Das habe ich zwar noch nicht, aber der Effekt tritt ja in einem Objekt auf, das zwei verschiedene Texturen beinhaltet. Ich meine damit, beide Texturen werden zur selben Zeit dargestellt, die eine richtig, die andere nicht. Ich probiere das aber gerne mal aus.

Da ich vorhabe, Uhren mit teil-transparenten Scheiben zu bauen und zu verkaufen, wäre es aber schlecht, wenn mancher User sich bei mir beklagt, weil die Uhr schrottig aussieht. Ich kann ja schlecht eine Liste der Grafikeinstellungen beipacken. :) Für mich ist das entweder ein Bug oder eine Einsparung von Rechenleistung im Sinne eines "akzeptablen" Kompromisses bei Texturen mit in Relation zur Gesamttextur wenigen teil-transparenten Pixeln.
 

Users who are viewing this thread

Zurück
Oben Unten