Hallo zusammen,
meine Frage wendet sich einmal an die Technikexperten unter Ihnen/Euch. Ich plane derzeit die Neuanschaffung eines Notebooks. Aktuell arbeite ich mit einem HP ZBook G3, 4k Dreamcolor, mit einer Quadro M1000M Grafikkarte. MObjects in 4k ist damit so gerade möglich, ich bin aber schon limitiert in der Auswahl der Objekte... Schnelles Aufzoomen oder ein "Bildband" mit rascher horizontaler Bewegung werden manchmal schon ruckelig.
Aktuell stehen Geräte zur Auswahl, die entweder eine RTX A4000 Laptop GPU oder eine RTX A3000 Laptop GPU haben. Diese unterscheiden sich im G3D Mark nur unwesentlich (A4000: 15202; A3000: 14347), wohl aber im "Max. Memory Supported" von 16 GB vs. 6 GB. Frage, falls es jemand weiss: Ist das Memory der Grafikkarte ein möglicher Bottleneck bei MObjects, oder zählt da im Wesentlichen der G3D Mark?
Vielen Dank für Eure Antworten!
Karsten
Grafikkarten Notebook
Re: Grafikkarten Notebook
Hallo Karsten,
das ist eine gute Frage.
Allerdings bin ich der Meinung, dass sie eher umgekehrt gestellt werden muss.
Und zwar: Ist m.objects in der Lage mehr als 4GB Grafikspeicher zu nutzen? (Ob nötig oder nicht)
Man wird wohl davon ausgehen können, dass die meisten Anwender mittlerweile ein 64bit Betriebssystem verwenden, denn nur damit ist erst die Adressierung von mehr als 4GB Haupt oder Grafikspeicher möglich.
m.objects selbst ist meines Wissens keine 64bit Anwendung (?). Damit könnte auch hier eine Limitierung bestehen.
Ein gewisses Indiz sind für mich die Angaben unter "Leinwand>>Grafikinfos anzeigen" . Dort wird bei mir - Egal welche m.objects Version, welcher Rechner, welche Grafikkarte (auch mit 6 bzw. 8GB bestückt) neben der Auflösung und Framerate immer "4095MB" (=4GB) angezeigt.
Die Speicherverwaltung von m.objects ist aber offensichtlich so optimiert, dass das (bisher) auch für 4K Anwendungen ausreicht.
Ob ich mit meiner EInschätzung richtig liege und ob es Planungen gibt, dies in zukünftigen Versionen zu ändern, kann uns wohl nur Hr. Richter beantworten.
Mich würd's interessieren ;-).
VG
Horst
Vielen Dank für die Antwort zum Thema Speicherverwaltung und Architektur von m.objects in Form eines Online-Seminars ;-)
siehe folgender Beitrag:
das ist eine gute Frage.
Allerdings bin ich der Meinung, dass sie eher umgekehrt gestellt werden muss.
Und zwar: Ist m.objects in der Lage mehr als 4GB Grafikspeicher zu nutzen? (Ob nötig oder nicht)
Man wird wohl davon ausgehen können, dass die meisten Anwender mittlerweile ein 64bit Betriebssystem verwenden, denn nur damit ist erst die Adressierung von mehr als 4GB Haupt oder Grafikspeicher möglich.
m.objects selbst ist meines Wissens keine 64bit Anwendung (?). Damit könnte auch hier eine Limitierung bestehen.
Ein gewisses Indiz sind für mich die Angaben unter "Leinwand>>Grafikinfos anzeigen" . Dort wird bei mir - Egal welche m.objects Version, welcher Rechner, welche Grafikkarte (auch mit 6 bzw. 8GB bestückt) neben der Auflösung und Framerate immer "4095MB" (=4GB) angezeigt.
- grafikinfos_mo.JPG (20.26 KiB) 5675 mal betrachtet
Ob ich mit meiner EInschätzung richtig liege und ob es Planungen gibt, dies in zukünftigen Versionen zu ändern, kann uns wohl nur Hr. Richter beantworten.
Mich würd's interessieren ;-).
VG
Horst
Vielen Dank für die Antwort zum Thema Speicherverwaltung und Architektur von m.objects in Form eines Online-Seminars ;-)
siehe folgender Beitrag:
Zuletzt geändert von hora58 am 13.09.21, 13:00, insgesamt 1-mal geändert.
m.objects X2024 (2639) Creative, XMG Neo 32GB und Nvidia GTX2070 Super 8GB , Win10/64 Pro ... | Mitglied bei www.av-dialog.de | ...
-
m.objects
- Site Admin
- Beiträge: 1284
- Registriert: 20.06.02, 15:27
- Wohnort: Münster (Westf.)
- Kontaktdaten:
Re: Grafikkarten Notebook
Guten Tag zusammen!
Zunächst die kurze Antwort auf die Frage von Karsten:
Es ist richtig, dass die NVidia RTX A3000 sowie RTX A4000 ungefähr fünf mal so schnell rechnen können wie die Quadro M1000M. Damit ist die geplante Neuanschaffung ein sinnvoller Schritt, um rechenintensive Effekte auch in UHD/4K ruckelfrei darstellen zu können. Die Größe der verfügbaren Videospeichers ist für die ruckelfreie Darstellung nicht direkt von Bedeutung, jedoch für die mögliche Komplexität von Shows bei hoher Auflösung. Für reale aktuelle Anwendungsfälle (UHD-Ausgabe, UHD-Video und ggf. gleichzeitige Darstellung und Animationen sehr hoch aufgelöster Fotos) mit m.objects sind die möglichen 6 GB Videospeicher einer RTX A3000 allerdings bereits reichlich bemessen.
Der ausführlichere Hintergrund für technisch interessierte Anwender (und Lesestoff für alle, die unsere ausführlichen Präsenz-Seminare etwas vermissen ;-):
Effekte wie Animationen von Bildern/Texten/Videos mittels Zoom, Bildfeld, 3D-Animation verursachen während der Wiedergabe kaum zusätzliche Rechenlast.
Zu den Spezialeffekten innerhalb von m.objects, die hingegen einen erhöhten Bedarf an Rechenleistung haben, zählen vor allem:
- dynamische Unschärfe (B)
- Schatten/Schein (S)
- Passepartout (F)
Werden diese also zusätzlich zu Animationen von Bildern oder Videos eingesetzt, kann das auf "kleineren" GPUs insbesondere bei hoher Ausgabeauflösung zu einer hohen Auslastung führen, die sich wiederum durch sogenannten Frame Drops und damit sichtbarem Ruckeln bemerkbar machen kann.
Allerdings ist die Anforderung an die Grafikhardware, 60 fps (Bildern pro Sekunde, das ist der Regelfall) auch ohne Spezialeffekte in UHD-Auflösung zu rendern, bereits nicht zu unterschätzen. Das gilt insbesondere bei aktiver Glättung von Bildfeldkanten in den Leinwandeinstellungen, die per Default eingeschaltet ist. Diese Funktion zeigt sichtbare Vorteile lediglich an den Kanten rotierter oder vergleichsweise langsam animierter Bildobjekte durch eine Glättung der sonst auftretenden Aliasing-Effekte, die um so deutlicher auftreten, je geringer die Auflösung ist. Bei der Wiedergabe in UHD ist diese Glättung aufgrund der hohen Auflösung deutlich weniger wichtig. Sie können die Glättung von Bildfeldkanten auf Ihrer aktuellen Hardware also probehalber einmal auf aus stellen. Das führt auf weniger performanten GPUs oft auch bei hoher Ausgabeauflösung schon zur gewünschten konstanten Framerate von 60 fps.
Die Kapazität des verfügbaren Grafikspeichers hat praktisch keine Auswirkung auf die Rechenleistung des Renderers, unter Umständen jedoch auf die maximal nutzbare Auflösung bzw. die maximale Anzahl der gleichzeitig darstellbaren Objekte. Dabei wird Grafikspeicher automatisch nach folgenden Kriterien belegt:
- Das Betriebssystem verlangt pro angeschlossenem Bildschirm/Projektor dessen Auflösung entsprechend Speicher für die Darstellung und den sog. Desktop Window Manager (Windows) bzw. WindowServer (macOS).
- m.objects legt bestimmte Hintergrundresourcen im Videospeicher je nach eingestellter Auflösung des Echtzeit-Renderers bereits beim Öffnen der Leinwand an.
- Für Bilder, Texte und ggf. Videos belegt m.objects kurz vor dem Erreichen des Objekts auf der Timeline zusätzliche Grafikresourcen. Bei Bildern und Texten gilt, dass die Menge des benötigten Speichers abhängig von der Ausgabeauflösung und dem Vergrößerungsfaktor (z.B. durch Zoom, Bildfeld, 3D-Animation) und zudem von der Frage ist, ob die Darstellungsgröße eines Standbildes während seiner Anzeigedauer um mehr als etwa Faktor 1.8 variiert, z.B. durch dynamischen Zoom oder Bildfelder.
- Für Spezial- und Maskierungseffekte benötigter zusätzlicher Speicher wird erst belegt, wenn ein solcher Effekt tatsächlich wirksam wird.
- Ein Sonderfall ist die Wiedergabe von Video unter Windows: Die Decodierung bestimmter Typen von Video kann durch geeignete Grafikhardware unterstützt werden (die meisten modernen GPUs beherrschen das), was wiederum den Hauptprozessor entlastet und damit auch auf weniger leistungsfähigen Prozessoren eine ruckelfreie Videowiedergabe ermöglicht. Diese Unterstützung der Videodecodierung durch die GPU verlangt entsprechend ebenfalls Videospeicher kurz vor und während der Wiedergabe des Videoclips.
m.objects X zeigt übrigens im Gegensatz zu älteren Versionen in den Betriebsmodi Pause und Wiedergabe die aktuelle Framerate (fps), anhand derer man eine zu hohe Last der GPU erkennen kann, unten rechts in der Statuszeile an. Diese Neuerung gibt es, da die zuvor angebotene Technik zur Einblendung der Grafikinformationen innerhalb des Screens zwei Nachteile hatte:
- Die Einblendung selbst beeinflusste die Framerate je nach Grafikhardware bereits deutlich negativ.
- Die aktuelle Framerate konnte zuvor während der laufenden Vorführung nicht beobachtet werden.
Die von Horst erwähnte zusätzlich angezeigte Größe des noch verfügbaren Videospeichers war leider ohnehin nicht korrekt und wurde fälschlich stets mit 4 GB beziffert, daher entfällt diese Anzeige nun.
Warum ist m.objects trotz der vermeintlichen Einschränkung auf 4 GB Adressraum zur störungsfreien Verarbeitung komplexer Arrangements in sehr hohen Auflösungen in der Lage?
Neben seinem sehr hohen Optimierungsgrad verfügt m.objects über eine besondere Architektur, die verschiedene Aufgaben automatisch auf mehrere einzelne Prozesse verteilt, von denen jeder über einen eigenen Adressraum verfügt. Am Auffälligsten ist dabei die Splittung auf die Hauptapplikation mit dem Editor einerseits und die Leinwand (den Renderer bzw. in größeren Anwendungen mehrere Renderer) andererseits. Letzterer wiederum ist sogar dazu in der Lage, eine Verteilung seines Speicherbedarfs auf Hauptspeicher und Videospeicher so vorzunehmen, dass effektiv die Grenzen des Adressraums erweitert werden. Schließlich werden Prozesse wie Analyse und Extraktion von Videodaten, Trimming, Videoexport u.a. in weitere Prozesse ausgelagert. Damit diese Architektur seine Vorteile ausspielen kann, ist allerdings der Einsatz eines 64-Bit Betriebssystems unabdingbare Voraussetzung. In einer 32-Bit Umgebung wird es m.objects schnell zu eng, wenn die Anforderungen steigen.
Aufgrund dieser speziellen Architektur konnte m.objects schon vor etlichen Jahren performant mit UHD-Auflösungen umgehen und bietet auch heute im Vergleich zu anderen Anwendungen für Echtzeit-Rendering nachprüfbar überlegene Leistungswerte bei einem erstaunlich geringen Resourcenbedarf. Wir arbeiten bereits seit einigen Jahren intern auch mit reinen 64-Bit Renderern, die jedoch in aktuellen Anwendungsszenarien überhaupt keinen Performancevorteil bieten, allerdings immer einen deutlich höheren Bedarf an Speicher mit sich bringen. Dennoch - und mit weiterhin steigenden Speichergrößen und Rechenleistungen zu fallenden Preisen - wird m.objects mittelfristig auch als reine 64-Bit Applikation angeboten werden. Im ersten Schritt wird das den Renderer betreffen, in einem weiteren die Arbeitsoberfläche.
Mit freundlichem Gruß
Steffen Richter
Zunächst die kurze Antwort auf die Frage von Karsten:
Es ist richtig, dass die NVidia RTX A3000 sowie RTX A4000 ungefähr fünf mal so schnell rechnen können wie die Quadro M1000M. Damit ist die geplante Neuanschaffung ein sinnvoller Schritt, um rechenintensive Effekte auch in UHD/4K ruckelfrei darstellen zu können. Die Größe der verfügbaren Videospeichers ist für die ruckelfreie Darstellung nicht direkt von Bedeutung, jedoch für die mögliche Komplexität von Shows bei hoher Auflösung. Für reale aktuelle Anwendungsfälle (UHD-Ausgabe, UHD-Video und ggf. gleichzeitige Darstellung und Animationen sehr hoch aufgelöster Fotos) mit m.objects sind die möglichen 6 GB Videospeicher einer RTX A3000 allerdings bereits reichlich bemessen.
Der ausführlichere Hintergrund für technisch interessierte Anwender (und Lesestoff für alle, die unsere ausführlichen Präsenz-Seminare etwas vermissen ;-):
Effekte wie Animationen von Bildern/Texten/Videos mittels Zoom, Bildfeld, 3D-Animation verursachen während der Wiedergabe kaum zusätzliche Rechenlast.
Zu den Spezialeffekten innerhalb von m.objects, die hingegen einen erhöhten Bedarf an Rechenleistung haben, zählen vor allem:
- dynamische Unschärfe (B)
- Schatten/Schein (S)
- Passepartout (F)
Werden diese also zusätzlich zu Animationen von Bildern oder Videos eingesetzt, kann das auf "kleineren" GPUs insbesondere bei hoher Ausgabeauflösung zu einer hohen Auslastung führen, die sich wiederum durch sogenannten Frame Drops und damit sichtbarem Ruckeln bemerkbar machen kann.
Allerdings ist die Anforderung an die Grafikhardware, 60 fps (Bildern pro Sekunde, das ist der Regelfall) auch ohne Spezialeffekte in UHD-Auflösung zu rendern, bereits nicht zu unterschätzen. Das gilt insbesondere bei aktiver Glättung von Bildfeldkanten in den Leinwandeinstellungen, die per Default eingeschaltet ist. Diese Funktion zeigt sichtbare Vorteile lediglich an den Kanten rotierter oder vergleichsweise langsam animierter Bildobjekte durch eine Glättung der sonst auftretenden Aliasing-Effekte, die um so deutlicher auftreten, je geringer die Auflösung ist. Bei der Wiedergabe in UHD ist diese Glättung aufgrund der hohen Auflösung deutlich weniger wichtig. Sie können die Glättung von Bildfeldkanten auf Ihrer aktuellen Hardware also probehalber einmal auf aus stellen. Das führt auf weniger performanten GPUs oft auch bei hoher Ausgabeauflösung schon zur gewünschten konstanten Framerate von 60 fps.
Die Kapazität des verfügbaren Grafikspeichers hat praktisch keine Auswirkung auf die Rechenleistung des Renderers, unter Umständen jedoch auf die maximal nutzbare Auflösung bzw. die maximale Anzahl der gleichzeitig darstellbaren Objekte. Dabei wird Grafikspeicher automatisch nach folgenden Kriterien belegt:
- Das Betriebssystem verlangt pro angeschlossenem Bildschirm/Projektor dessen Auflösung entsprechend Speicher für die Darstellung und den sog. Desktop Window Manager (Windows) bzw. WindowServer (macOS).
- m.objects legt bestimmte Hintergrundresourcen im Videospeicher je nach eingestellter Auflösung des Echtzeit-Renderers bereits beim Öffnen der Leinwand an.
- Für Bilder, Texte und ggf. Videos belegt m.objects kurz vor dem Erreichen des Objekts auf der Timeline zusätzliche Grafikresourcen. Bei Bildern und Texten gilt, dass die Menge des benötigten Speichers abhängig von der Ausgabeauflösung und dem Vergrößerungsfaktor (z.B. durch Zoom, Bildfeld, 3D-Animation) und zudem von der Frage ist, ob die Darstellungsgröße eines Standbildes während seiner Anzeigedauer um mehr als etwa Faktor 1.8 variiert, z.B. durch dynamischen Zoom oder Bildfelder.
- Für Spezial- und Maskierungseffekte benötigter zusätzlicher Speicher wird erst belegt, wenn ein solcher Effekt tatsächlich wirksam wird.
- Ein Sonderfall ist die Wiedergabe von Video unter Windows: Die Decodierung bestimmter Typen von Video kann durch geeignete Grafikhardware unterstützt werden (die meisten modernen GPUs beherrschen das), was wiederum den Hauptprozessor entlastet und damit auch auf weniger leistungsfähigen Prozessoren eine ruckelfreie Videowiedergabe ermöglicht. Diese Unterstützung der Videodecodierung durch die GPU verlangt entsprechend ebenfalls Videospeicher kurz vor und während der Wiedergabe des Videoclips.
m.objects X zeigt übrigens im Gegensatz zu älteren Versionen in den Betriebsmodi Pause und Wiedergabe die aktuelle Framerate (fps), anhand derer man eine zu hohe Last der GPU erkennen kann, unten rechts in der Statuszeile an. Diese Neuerung gibt es, da die zuvor angebotene Technik zur Einblendung der Grafikinformationen innerhalb des Screens zwei Nachteile hatte:
- Die Einblendung selbst beeinflusste die Framerate je nach Grafikhardware bereits deutlich negativ.
- Die aktuelle Framerate konnte zuvor während der laufenden Vorführung nicht beobachtet werden.
Die von Horst erwähnte zusätzlich angezeigte Größe des noch verfügbaren Videospeichers war leider ohnehin nicht korrekt und wurde fälschlich stets mit 4 GB beziffert, daher entfällt diese Anzeige nun.
Warum ist m.objects trotz der vermeintlichen Einschränkung auf 4 GB Adressraum zur störungsfreien Verarbeitung komplexer Arrangements in sehr hohen Auflösungen in der Lage?
Neben seinem sehr hohen Optimierungsgrad verfügt m.objects über eine besondere Architektur, die verschiedene Aufgaben automatisch auf mehrere einzelne Prozesse verteilt, von denen jeder über einen eigenen Adressraum verfügt. Am Auffälligsten ist dabei die Splittung auf die Hauptapplikation mit dem Editor einerseits und die Leinwand (den Renderer bzw. in größeren Anwendungen mehrere Renderer) andererseits. Letzterer wiederum ist sogar dazu in der Lage, eine Verteilung seines Speicherbedarfs auf Hauptspeicher und Videospeicher so vorzunehmen, dass effektiv die Grenzen des Adressraums erweitert werden. Schließlich werden Prozesse wie Analyse und Extraktion von Videodaten, Trimming, Videoexport u.a. in weitere Prozesse ausgelagert. Damit diese Architektur seine Vorteile ausspielen kann, ist allerdings der Einsatz eines 64-Bit Betriebssystems unabdingbare Voraussetzung. In einer 32-Bit Umgebung wird es m.objects schnell zu eng, wenn die Anforderungen steigen.
Aufgrund dieser speziellen Architektur konnte m.objects schon vor etlichen Jahren performant mit UHD-Auflösungen umgehen und bietet auch heute im Vergleich zu anderen Anwendungen für Echtzeit-Rendering nachprüfbar überlegene Leistungswerte bei einem erstaunlich geringen Resourcenbedarf. Wir arbeiten bereits seit einigen Jahren intern auch mit reinen 64-Bit Renderern, die jedoch in aktuellen Anwendungsszenarien überhaupt keinen Performancevorteil bieten, allerdings immer einen deutlich höheren Bedarf an Speicher mit sich bringen. Dennoch - und mit weiterhin steigenden Speichergrößen und Rechenleistungen zu fallenden Preisen - wird m.objects mittelfristig auch als reine 64-Bit Applikation angeboten werden. Im ersten Schritt wird das den Renderer betreffen, in einem weiteren die Arbeitsoberfläche.
Mit freundlichem Gruß
Steffen Richter
Re: Grafikkarten Notebook
Hallo Herr Richter,
zunächst einmal (Horst hat es ja schon angesprochen) auch von meiner Seite ganz herzlichen Dank für die tiefreichende Erläuterung zur (Grafik)Ressourcenverwaltung von MObjects! Als kurze Antwort entnehme ich den Ausführungen, dass ich bereits mit der RTX A3000 einen guten Schritt nach vorne mache (so dass es diese Karte wahrscheinlich werden wird)...
...die weiteren Erläuterungen erklären einige Beobachtungen, die ich auch selbst schon gemacht habe (z.B., dass die dynamische Unschärfe sehr ressourcenhungrig ist), und sie werden mir zunächst einmal dabei helfen, mit meiner aktuellen Hardware noch etwas weiter zu kommen (Stichwort z.B. "Glättung von Bildfeldkanten"). Denn die geplante Neuanschaffung existiert bisher nur im Katalog, Liefertermine stehen in den Sternen (--> anderes Thema).
Dem Wunsch, bald endlich wieder Präsenzseminare besuchen zu können, kann ich mich nur anschließen - bin gerne dabei, wenn es wieder losgeht.
Besten Dank nochmal und herzliche Grüße,
Karsten
P.S. EINE kleine technische Nachfrage vielleicht noch...: ist eigentlich die Auflösung des Bildmaterials von großer Bedeutung für die Perfomance von MObjects? Da ich mit dem Auflösungsmonster Nikon D850 arbeite, liegen meine Bilder meist in 45 MP (meist Overkill) vor - würde es MObjects hier entlasten, die Bilder z.B. so herunterzuskalieren, dass sie bei maximalem Hereinzoomen nur noch ein wenig über der Ausgabeauflösung liegen? Oder ist überhaupt eher die Ausgabeauflösung als die Auflösung des Bildmaterials entscheidend für die Performance? Danke auch hier nochmal für einen kurzen Tip...
zunächst einmal (Horst hat es ja schon angesprochen) auch von meiner Seite ganz herzlichen Dank für die tiefreichende Erläuterung zur (Grafik)Ressourcenverwaltung von MObjects! Als kurze Antwort entnehme ich den Ausführungen, dass ich bereits mit der RTX A3000 einen guten Schritt nach vorne mache (so dass es diese Karte wahrscheinlich werden wird)...
...die weiteren Erläuterungen erklären einige Beobachtungen, die ich auch selbst schon gemacht habe (z.B., dass die dynamische Unschärfe sehr ressourcenhungrig ist), und sie werden mir zunächst einmal dabei helfen, mit meiner aktuellen Hardware noch etwas weiter zu kommen (Stichwort z.B. "Glättung von Bildfeldkanten"). Denn die geplante Neuanschaffung existiert bisher nur im Katalog, Liefertermine stehen in den Sternen (--> anderes Thema).
Dem Wunsch, bald endlich wieder Präsenzseminare besuchen zu können, kann ich mich nur anschließen - bin gerne dabei, wenn es wieder losgeht.
Besten Dank nochmal und herzliche Grüße,
Karsten
P.S. EINE kleine technische Nachfrage vielleicht noch...: ist eigentlich die Auflösung des Bildmaterials von großer Bedeutung für die Perfomance von MObjects? Da ich mit dem Auflösungsmonster Nikon D850 arbeite, liegen meine Bilder meist in 45 MP (meist Overkill) vor - würde es MObjects hier entlasten, die Bilder z.B. so herunterzuskalieren, dass sie bei maximalem Hereinzoomen nur noch ein wenig über der Ausgabeauflösung liegen? Oder ist überhaupt eher die Ausgabeauflösung als die Auflösung des Bildmaterials entscheidend für die Performance? Danke auch hier nochmal für einen kurzen Tip...
-
sailorfred
- Beiträge: 90
- Registriert: 27.11.13, 16:49
Re: Grafikkarten Notebook
Ich bin zwar nicht Hr. Richter, aber meines Erachtens ist die Frage einfach zu beantworten.
M.objects rechnet ja immer Texturen (zu finden im Verzeichnis mob_Auto) für die gewählte Ausgabegröße. Und diese werden auch für die Darstellung verwendet, nicht die Original Bilder. Die Texturen sind genau so groß (oder klein), wie es für die optimale Darstellung notwendig ist. Wenn ein anderes Ausgabegerät (z.B. mit einer höheren Auflösung) gewählt wird, werden die Texturen automatisch neu errechnet.
Daher ist aus meiner Sicht die Größe der originalen Bilddateien unerheblich. Ich denke sogar, dass im Handbuch steht, dass man die Foto Dateien immer in bester Qualität verwenden soll.
lG Fredy
M.objects rechnet ja immer Texturen (zu finden im Verzeichnis mob_Auto) für die gewählte Ausgabegröße. Und diese werden auch für die Darstellung verwendet, nicht die Original Bilder. Die Texturen sind genau so groß (oder klein), wie es für die optimale Darstellung notwendig ist. Wenn ein anderes Ausgabegerät (z.B. mit einer höheren Auflösung) gewählt wird, werden die Texturen automatisch neu errechnet.
Daher ist aus meiner Sicht die Größe der originalen Bilddateien unerheblich. Ich denke sogar, dass im Handbuch steht, dass man die Foto Dateien immer in bester Qualität verwenden soll.
lG Fredy
-
m.objects
- Site Admin
- Beiträge: 1284
- Registriert: 20.06.02, 15:27
- Wohnort: Münster (Westf.)
- Kontaktdaten:
Re: Grafikkarten Notebook
Das kann ich genau so bestätigen. Die Wiedergabeleistung ist durch das automatisch arbeitende Texturdaten-Management von "übergroßen" eingebundenen Bildern vollkommen unbeeinträchtigt. Der Vorteil der Verwendung voller Auflösung liegt natürlich darin, dass auch stärkere Vergrößerungen und höhere Ausgabeauflösungen möglich sind, ohne dass es zu einem Mangel an Bildschärfe bzw. -details kommt.
Mit freundlichem Gruß
Steffen Richter
Mit freundlichem Gruß
Steffen Richter