Größe eines Bildes

Es gibt 21 Antworten in diesem Thema, welches 8.000 mal aufgerufen wurde. Der letzte Beitrag (28. Februar 2017 um 12:38) ist von 3dfan.

1. offizieller Beitrag

    Was meinst du? ?( Wie viel 'Render-Speicher' (GPU/RAM) die gesamte Szene bei der letztendlichen Berechnung des Bildes belegt?

    Da meine Bilder nur für die Darstellung auf Bildschirmen gedacht sind orientiere ich mich meist an FullHD (1920x1020) oder WUXGA (1920x1200), dh. Landscape Bilder sind am Ende 1920 Pixel breit (Höhe kann variieren) und Portrait Bilder 1200 Pixel hoch (Breite kann variieren).

    Gerendert wird dann üblicherweise in der doppelten Auflösung also z.B. 3840x2400, für maximale Detailauflösung, und für die Publikation wird auf die Hälfte herunterskaliert. Man kann immer ohne Qualitätsverlust verkleinern aber nicht vergrössern.
    Für Bildschirmausgabe genügen üblicherweise 72 DPI, für Ausdrucke 300 DPI.
    Die JPEG - Kompression schwankt bei mir üblicherweise zwischen 60% und 80%, je nach Details im Bild.

    @Sven Ob man das nun in D|S vorab irgendwo konkret ablesen kann, weiß ich leider nicht.
    Es gibt ja bspw. auch das 'Scene Info'-Tab, in dem allerdings nur die Anzahl [lexicon]Polygone[/lexicon]/Vertices und Lichter angezeigt wird, was nicht zwangsläufig einen Schluss auf Dateigrößen zulässt. Zumal die Geometrie generell wohl auch eher selten problematisch sein dürfte. Zumindest, so lange nicht wirklich krasse Polygonmonster (bspw. 3D-Fraktale o.ä.) verwendet werden oder man es mit Sub-D übertreibt.

    Viel mehr Augenmerk ist sicherlich auf Displacement und Texturen ganz allgemein zu legen. Eine 4000x4000 Textur (eigentlich mittlerweile ja Gang und Gebe) benötigt i.d.R. gut 45 mb Speicher, bei einer Standard-DAZ-Figur sind meist wenigstens um die 20-30 Texturmaps am Start, häufig jedoch auch deutlich mehr (bis zu rund 50). (Kann man also zumindest 'grob überschlagen'.) Damit wären wir pro DAZ-Püppi etwa bei 1.0 -1.5 GB allein für die Texturen der puren Nackedei-Figur. (Eine Vic4 bspw., die ich nach Blender transferiere benötigt 600-700 mb RAM. Lässt sich dort sehr gut ablesen. Hat dann aber auch lediglich diffuse, bump und vielleicht noch 'ne specmap. Genesisen in D|S haben ja häufig auch noch zusätzliche Maps für SSS oder TraLu etc.) Dann kommen halt noch Haare und Klamotten dazu, die teilweise ebenfalls nicht ohne sind. Bspw. gibt es ja auch Klamotten, die Texturen bis zu 8000 Pixel verwenden (Mada's Anime-Manga-Batllesuit für G2F7G3F zum Beilstiel).

    Allerdings sind RAM-Arbeitsspeicher und Renderspeicher für die Bildberechnung nicht unbedingt identisch. Kann mal erheblich mehr, mal deutlich weniger sein. Läasst sich aber zumindest mal 'über den Daumern peilen'...

    • Offizieller Beitrag
    Zitat

    GB-Größe einer Szene


    Du meinst wahrscheinlich während des Renderns, nicht die Größe der abgespeicherten duf-Datei auf der Festplatte?
    Keine Ahnung, das ist irgendwie schwer zu sagen.
    Ich verwende GPU-Z zur Überwachung meiner Grafikkarte, das zeigt auch an, wieviel Speicher verbraucht wird.
    Z.B. rendere ich gerade eine Szene mit einer G3F, zwei Kleidungsstücken, einem Haar und einem Paar Schuhe, dazu eine Bodenfläche, ein Hocker und eine Rückwand. Laut GPU-Z verbraucht das 2649 MB. Habe allerdings keine Ahnung, wie genau diese Anzeige ist.

    esha: Du hast mich gerade auf einen Gedanken gebracht. Ich rendere gerade ein sehr großes Bild. Task-Manager aufgerufen und die Daten gecheckt. DAZ belegt im Moment 18 GB und die CPU ist 90% ausgelastet.
    Ist aber nur der Jetzt-Stand.
    Mir ging es wirklich darum, aber DAZ die Größe vorher berechnen kann und man es auslesen könnte. So könnte man noch die ein oder andere Reduzierung vornehmen.

    Also was DAZ im Speicher belegt hat wenig damit zu tun was am Ende im Grafikspeicher landet.
    Ich habe immer einen Ram Monitor nebenbei laufen und sehe dass ich bei komplexen Szenen gerne mal an 30 GB RAM verbrauche. Trotzdem kann ich diese Szene i.d.R Problemlos über meine beiden GTX060 mit 6 GB VRam rendern.
    Ein anderes mal brauche ich nur eine einizge Version von meiner Fia laden im Winterdress und die alleine passt beim Render nicht in den VRAM weil viele Fell materialien mit Unmengen an Displacement.
    Unter Octane gab immer eine Anzeige des Speicherauslastung der Grafikkarte. Das war hilfreich. Ausserdem hatte Octane dann auch die Möglichkeit einzielne Texturen einfach zu verkleinern. Eine Haus texture von einem Haus dass irgendwo im Hintergrund steht braucht nicht unbedingt die 8192x8192 Auflösung , vor allem nicht wenn DOF eingestellt ist.
    Alternativ gibt es ein kleines Tools welches diverse Hardware Daten ausliest und anzeigt - eben auch die Auslastungsdaten der Grafikkarten , Lüfter, GPU, VRAM usw.
    Nennt sich OpenhardwareMonitor : http://openhardwaremonitor.org/

    Zitat von Sven

    Ich habe mich wohl dumm ausgedrückt. Es geht wirklich um den GB-Größe einer Szene.

    Upps - hab ich mich verlesen :whistling:

    Zitat von Sven

    Mir ging es wirklich darum, aber DAZ die Größe vorher berechnen kann und man es auslesen könnte. So könnte man noch die ein oder andere Reduzierung vornehmen.


    Ich weis nicht so recht, warum das notwendig sein soll - wenn der Speicher knapp wird merkt man das ja relativ schnell auch so... :D

    Was generell viel Speicherplatz braucht sind Textur-Images. Ich glaube allein mit Polygonen wird man sein System kaum zum Platzen bringen.
    Um auf der sicheren Seite zu sein, empfiehlt es sich (besonders bei dem speicherhungrigen DS) Texturen von Charakteren und Objekten die man häufig benutzt herunterzuskalieren. Ich leg mir dafür üblicherweise 2 Unterverzeichnisse im Texturordner an, eins mit den Originalen und eins mit um 50% verkleinerten Images. So kann ich mir die jeweilige Version die ich benutzen will, ins root kopieren. Normalerweise belasse ich es allerdings bei den 50% Versionen - und schwupp - 50% Speicher and dieser Stelle gespart.
    Bei den Auflösungen, in denen ich rendere, bin ich noch nie in die Verlegenheit gekommen, eine 4K Textur benutzen zu müssen...

    Cleverer Szenenbau hift natürlich auch - alles, was keinen visuellen Beitrag liefert löschen.

    Wie schon erwähnt hat Octane eine entsprechende Anzeige und sogar eine Skalierungsmöglichkeit für die Texturen, aber bis jetzt hat noch alles so in meine 6GB gepasst :)
    (Ausser einem Kleidungsset, das doch wirklich einige 5000er(!) Images hat - wer in aller Welt braucht denn sowas?)

    • Offizieller Beitrag

    Nur so als Anmerkung: Ein auf 50% runterskaliertes Bild spart 3/4 der MB, weil du es in zwei Dimensionen um 50% verkleinerst.

    Andererseits: ich arbeite oft genug mit Close-Close-Ups und ärgere mich jedes Mal über schlechte Texturen schwarz. Letztens wollte ich den Atlantida Temple von DAZ benutzen. Gut, ist PC+, an irgendwas wird halt gespart, aber der Contentersteller hat - für einen großen Tempel SAMT Treppe und Vorplatz! - eine 4000x4000px Map oder so benutzt, was natürlich heißt, dass bei so vielen Sachen auf einem UV-Template für alle Unterteile nur noch 500x500px oder so zur Verfügung standen. Dementsprechend schlecht sahen die Texturen aus - und das noch aus mehreren "Metern" Abstand.

    Ich hab lieber zu viele zu große Texturen, die man dann kleinrechnen kann, wenns denn sein muss, als zu viel übrigen Speicherplatz und dafür ein bescheidenes Bild.

    Wobei ich dazu sagen muss, ich hab meine 32GB auch noch nie ausgereizt. An die ehemaligen 16GB bin ich aber schon rangekommen...

    • Offizieller Beitrag
    Zitat

    ich arbeite oft genug mit Close-Close-Ups und ärgere mich jedes Mal über schlechte Texturen schwarz


    Wie wahr! Nach 10 Jahren Content-Sammelei hab ich nicht ein Architekturset in der Library, wo die Bodentexturen hochauflösend genug sind, um einen Schuh darauf formatfüllend zu rendern.

    Kommt auf den Content an...
    Texturgrößen bei Charakteren oder Klamotten sind meist üppig groß und vertragen ein down-sizing, bei allem anderen geb ich euch recht, oft sind da die Maps nicht groß genug. Bei Architektur helf ich mir oft mit eigenen prozeduralen Shadern und cgtextures.
    Besonders PBR Renderer sind da unnachgiebig kleinlich was gute Materialien angeht... :)

    Zitat von Ehliasys

    Besonders PBR Renderer sind da unnachgiebig kleinlich was gute Materialien angeht... :)


    Ja, das ist wahr. :)

    Grundsätzlich finde ich's ja auch klasse, wenn die Originaltexturen möglichst hochauflösend sind. Auch wenn ich sie mir 'für den täglichen Gebrauch' vielleicht verkleinere. Das geht ja glücklicherweise immer. :D

    Wirklich nervig finde ich es nur, wenn die Texturen zwar eine 4000er Größe haben, die Qualität an sich jedoch arg zu wünschen übrig lässt, weil sie dabei toootal verpixelt oder matschig wirken. Habe ja manchmal echt den Eindruck, dass kleinere Texturen einfach auf 4k aufgeblasen werden, damit dies auch in der Produktbeschreibung angegeben werden kann. :rolleyes: .. ist dann halt nicht so das Gelbe ..

    also ehrlich gesagt: mir ist das überhaupt nicht recht, wenn jede Datei 4000x4000 Pixel hat.
    Grade bei kleinen Sachen, wie Augen. Genial wäre natürlich eine High- und eine LowRes version der entsprechenden Grafiken, aber sowas kann man vom Vendor nicht wirklich verlangen.
    Ich habe ja 16 GB RAM, aber es gibt viel Content, der so aufgeblasen ist, dass ich kaum die Maus bewegen kann. Z.B.

    der Dwarf für Genesis http://www.daz3d.com/dwarf-for-genesis
    Harpsburg: http://www.daz3d.com/harpsburg-for-daz-studio
    Chateau Blance: http://www.daz3d.com/chateau-blanche

    ich weiß nicht, was für Endgeräte die Entwickler haben, aber mein noch relativ neuer PC mit gar nicht so schlechter Ausrüstung ist damit völlig überfordert.
    Nachdem ich mich schon ca. 100 Jahre mit Platzsparen, Komprimieren, effektiv Programmieren etc. beschäftige habe ich den Verdacht, dass die Vendors gar nicht wissen, was sie da tun.

    Kann ich einfach die Grafikdateien raussuchen, Kopie machen und diese von 4000 x 4000 auf z.B. 2000 x 2000 verkleinern und dann über Surface laden, oder muss ich da auf was acht geben?

    Computer sind hinterhältig und gemein

    Zitat

    Kann ich einfach die Grafikdateien raussuchen, Kopie machen und diese von 4000 x 4000 auf z.B. 2000 x 2000 verkleinern und dann über Surface laden, oder muss ich da auf was acht geben?

    Da die Textur beim laden auf ihren exakten Namen "hört", muss die verkleinerte Kopie exakt so benannt sein wie die Originalvorlage und sich dann auch dort am gleichen Speicherort bzw. im Originalverzeichnis befinden. Daher unbedingt das Original in einem anderen Ordner sichern, um es nicht versehentlich zu überschreiben!

    Zitat

    dass die Vendors gar nicht wissen, was sie da tun

    Doch, das wissen sie. Sie versuchen halt, so vielen Kunden wie möglich gleichermaßen gerecht zu werden (um auch noch bei dem entstehenden Arbeitsaufwand ein wenig Verdienst heraus zu holen) - und das erfordert Kompromisse... :P

    vg
    space

    Geist ist geil!

    • Offizieller Beitrag

    Ich würde Kopien der Texturen im selben Ordner anlegen, sie umbenennen (also z.B. bei allen Dateinamen "LR" anhängen) und dann verkleinern.
    Dann würde ich die Dateien in der Library in einem Texteditor öffnen, mit Suchen-Ersetzen alle Dateinamen ändern (also ".jpg" auf "LR.jpg" ändern, und für .png genauso) und unter einem neuen Dateinamen speichern.
    So hättest du beide Versionen zur Verfügung.

    Und ja, wir wissen durchaus, was wir tun. Die meisten von uns jedenfalls ;)
    Es ist sinnvoller, die bestmögliche Qualität anzubieten, weil man die Daten nötigenfalls leicht herunterrechnen kann, aber nicht hochrechnen, wenn die nötige Auflösung einfach fehlt.

    Zitat von esha

    Wie wahr! Nach 10 Jahren Content-Sammelei hab ich nicht ein Architekturset in der Library, wo die Bodentexturen hochauflösend genug sind, um einen Schuh darauf formatfüllend zu rendern.

    Hi, nach dem ich ja schon wieder in Urlaub fahren musste (hihi), komme ich erst jetzt zum Lesen der letzten Themen.

    Zur obigen Anmerkung muss ich mal, zugegeben vielleicht zu laienhaft, folgendes Anmerken:

    Ist für Close-Ups vom Boden denn eine Textur überhaupt der richtige Ansatz?

    Eine Nahaufnahme bedingt, nach meiner Meinung, immer einen echt gemodelten Boden.
    Der muss doch "in 3D" sein, sonst sieht das doch immer nur nach Foto-Tapete aus, oder denke ich da falsch?

    OK, "Fliesen und Fugen" sind da ggf. leicht zu realisieren, aber mit "Gras und Dreck" wird's dann schon aufwändig und wohl auch sehr "polygonnös".

    Also wären doch vielleicht "gute Fußböden" eher was für Content-Ersteller?

    Konstruktive Bildkritik, Hinweise auf Fehler und /oder bessere Arbeitsweise immer erwünscht.

    "Besser auf neuen Wegen etwas stolpern, als auf alten Pfaden auf der Stelle zu treten!"

    oder

    "Wer immer tut, was er schon kann, bleibt immer das, was er schon ist."

    Zitat von 3dfan

    Eine Nahaufnahme bedingt, nach meiner Meinung, immer einen echt gemodelten Boden.
    Der muss doch "in 3D" sein, sonst sieht das doch immer nur nach Foto-Tapete aus, oder denke ich da falsch?


    Üblicherweise genügen da eine gute Diffus- und Displacment Map in genügend hoher Auflösung.
    Erst für grössere Objekte wie Gras sind dann Meshes (und Instanzen) gefragt.

    Ah, danke, @Ehliasys
    Ich habe ja erste Übungen mit Vue gemacht. Da ist ein glaubhafter "Ground" in Nahaufnahme aber ein echtes [lexicon]Polygon[/lexicon]-Monster. Das sind dann schnell mal "Milliarden".

    Konstruktive Bildkritik, Hinweise auf Fehler und /oder bessere Arbeitsweise immer erwünscht.

    "Besser auf neuen Wegen etwas stolpern, als auf alten Pfaden auf der Stelle zu treten!"

    oder

    "Wer immer tut, was er schon kann, bleibt immer das, was er schon ist."

    Zitat von 3dfan

    Ah, danke, @Ehliasys
    Ich habe ja erste Übungen mit Vue gemacht. Da ist ein glaubhafter "Ground" in Nahaufnahme aber ein echtes [lexicon]Polygon[/lexicon]-Monster. Das sind dann schnell mal "Milliarden".


    Vue benutzt LOD (level of detail) Subdivision, dh. nah viele Polys, fern wenig.
    Für Fälle, die nicht so in die Ferne gehen reicht meist eine lowpoly Grundlage und entsprechende Texturen:

    Externer Inhalt youtu.be
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    :top Oh, prima Tutorial für mich.

    Konstruktive Bildkritik, Hinweise auf Fehler und /oder bessere Arbeitsweise immer erwünscht.

    "Besser auf neuen Wegen etwas stolpern, als auf alten Pfaden auf der Stelle zu treten!"

    oder

    "Wer immer tut, was er schon kann, bleibt immer das, was er schon ist."