Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Ahhh, tausend Dank Kerya
Hallo Miteinander,
Wahrscheinlich weiß das jeder nur ich wieder nicht.
Wenn ich ein Objekt, wie z,B. Pistole, Messer oder Axt einer Figur in einer der beiden Hände geben will und es dort kleben bleiben soll, wie stelle ich das an?
Vielen Dank für die Antworten.
Hi Commander,
relativ einfache Prozedur: wenn Du alles fertig positioniert hast, Rechtsklick auf den Gegenstand, der "kleben bleiben soll" (XYZ) und dann die Option "Change "XYZ" Parent..." linksklicken. In dem sich nun öffnenden Fenster den Körperteil der "Trägerfigur" auswählen, bei der der kleben bleiben soll. Im Fall von Waffen o. ä. Objekte wählt man da dann die linke oder rechte Hand, für Helme o. ä. Kopfbedeckungen den Kopf, usw. usw. (S. Bild "image_45"). Darauf achten, dass die Option "Parent in Place" angehakt ist.
Wenn man einen solchen Gegenstand öfter wiederverwenden will, empfiehlt es sich, das Ganze nach der vorangegangenen Prozedur als "Wearable(s) Preset..." abzuspeichern. Mit der Methode lässt sich z.B. die Pose der Hand mit einbinden, so dass man diese nicht jedesmal neu posieren muss/ein extra Pose Preset anwenden muss. Dann wird jedesmal, wenn man das Prop zuweist, auch die benötigte Griff-Pose automatisch angewendet.
Methode:
Im "Scene Tab" die "Tragerfigur" (G2F, G3F,etc.) auswählen, dann die Option "File", "Save As" und "Wearable(s) Preset..." anklicken, einen Dateinamen vergeben, und in dem nun aufploppenden Menü ausser bei dem gewünschten Gegenstand alle Haken entfernen. Dann auf den Reiter "Pose" klicken und einen Haken bei "Include Pose Settings in Preset" setzen.
In der darunterliegenden Node Liste auch erstmal alle Haken entfernen (sonst wird die komplette gegenwärtige Pose angewandt, und das wollen wir ja nicht, nur die Hand brauchen wir...) mittels linksklick auf den Figur Node (in diesem Beispiel Victoria 6). Dann wuseln wir uns durch die Node Liste, bis wir die Hand gefunden haben. Dort bei den Nodes "...Thumb 1", "...Carpal 1" und "...Carpal 2", "General" und "Pose Controls" einen Haken setzen, und dann auf "Accept" linksklicken. Schon hat man ein schickes WP mit eingebauter Pose. (S. Bild "image_48").
Die Hand an sich sollte man dabei nicht auswählen, da dann auch die Achsrotation der Hand ("Bend", "Twist", "Side-Side") mit in die Pose einfließt. Dadurch müsste man bei einer ansonst passenden finalen Pose wieder an der Handposition herumschrauben und diese wieder korrigieren. "Greifen" tun nur Daumen und Finger, nicht das ganze Patschehändchen...
Viel Spaß beim Ausprobieren.
P.S.: Falls die Frage aufkommt...
Das schicke "Glock 17" Prop in meinem Beispiel ist von FoRender.com, skaliert auf 87,3%. IMO wesentlich besser als das Renderosity Gegenstück (da vollständig texturiert) und mit schlappen $6.00 auch wesentlich günsticher. Unter "Free Products" findet man bei diesem Anbieter auch eine schicke, kostenlose HK USP inklusive Zubehör (Schalldämpfer, Lampe, Match-Aufsatz der Sport-Variante).
Vielen Dank für deinen tollen Kommentar. Werde ich ausprobieren. Super erklärt.
Hi ihr Lieben.
Weiß zufällig jemand welcher Charakter das ist? (Siehe Link)
https://www.daz3d.com/city-unseelie-for-genesis-2-female-s
Danke
Ich nehme an, dass der Charakter von Sickleyield selbst mit seinen Morphs gebastelt ist: http://www.daz3d.com/fantastical-features-for-genesis-3-female-s
Du kannst auch Sickleyield eine PM schreiben: http://www.daz3d.com/forums/profile/921322/SickleYield
Wieder mal ganz lieben Dank Kerya!
Hallo liebe Forumsleute,
ich habe da mal eine Frage. Ich habe mir die neueste Beta (4.9.3.37) installiert. Seit dem habe ich Probleme mit dem Emissive Shader. Ich versuche, diesen für leuchtende Flächen zu nutzen.
Seit der Installation funktiert genau das aber nicht mehr. In der Version 4.9.2 habe ich diese problem nicht.
Was mache ich falsch oder gibt es da ein anderes Problem?
Vielen Dank für eure Hilfe.
Hallo ihr Lieben.
Irgendwie verstehe ich nicht so ganz was man damit machen kann!?
http://www.daz3d.com/ultrascatter-advanced-instancing-for-daz-studio
Weiß jemand mehr?
Danke
Jörg
Könntest Du mal Deine Einstellungen im Surface Tab posten?
Du kannst damit von beliebigen Objekten Instanzen erzeugen, und diese nach verschiedenen Kriterien verteilen. Dazu kannst Du entweder Bilder (als Maps) nehmen, in denen du "Dichte" und Richtungen bestimmst, oder die Verteilung folgt Regeln wie "auf Gegenstand A basierende Instanzen mögen nicht nahe bei Gegenstabd X sein, auf gegenstand B basierende Insatnzen lieben Gegenstand X".
Das ist praktisch für Baum- und Pflanzenverteilung, oder bei Personen/Tiergruppen, etc.
http://www.daz3d.com/forums/discussion/101156/ultrascatter-advanced-instancing-for-daz-studio#latest
Hallo, kann mir hier jemand noch einmal die situation um die aktuellen Nvidia-Grafikkarten erklären? Ich beabsichtige mir einen neuen PC zuzulegen. Ich will nicht mehr als 500€ für die Karte ausgeben. Soll natürlich tadellos mit IRAy und OctaneRender laufen.
Mit "aktuell" meinst Du die neue GeForce 10er Serie? Die sind z.Z. nicht mit Iray kompatibel. Für Iray benötigen die Pascal GPUs CUDA 8, welches sich nach Auskunft von NVIDIA noch im "Release Candidate" Modus befindet, als auch die Iray 2016.2 SDK, die wohl eben davon abhängt, dass die CUDA 8 da endlich reingefriemelt haben. NVIDIA verlautet, dass die SDK wohl Ende September ausgeliefert werden soll. Ich würd' also noch 'n bissken warten und auf die Erfahrungswerte der Kollegen warten, die sich so'n Teil schon besorgt haben und jetzt mit langem Gesicht herumlaufen, weil's net funktioniert. Ende September is ja auch nicht mehr soo lang hin...
Die 1070 gibt's lt. Heise aktuell ab 419,- TEUROS. Die Techn. Daten sehen ganz ordentlich aus: 8 GB GDDR5 VRAM und 1920 Shader-Einheiten sind vier-/fünfmal mehr als bei meiner ollen GT 730. Alternative könnte die GTX 980 Ti sein, hat zwar 2 GB VRAM weniger, aber dafür 896 Shader-Einheiten mehr auf der Brust (insg. 2816) und kostet nur ab 'n Zehner mehr als die 1070er...
Hallo Masterstroke
Zu der Grafikkarte kann ich dir die 980 ti sehr empfehlen... ich hatte bis vor 2 Wochen die 960er drin und dann auf die 980ti gewechselt... habe sie für 456 geschossen.
Der Speed ist unglaublich, so das ich jetzt endlich Iray Vorschau habe und das Rendern ist Sauschnell. Denke aber daran, das sie zur 960 die nur einen 6poligen Zusatz-Stromanschluss vom Netzteil brauchte zwei x den 6 poligen Zusatzstrom braucht. Ausserdem musst du auf die Leistung des Netzteils rücksicht nehmen... es gibt 980ti welche mit 250 Watt auskommen und welche die sich 500 Watt reinsaugen. Meine ist die Asus Strix GTX 980 ti 6GB... die kommt mit 250 Watt aus und ist Flüsterleise... bei mir hat es auch viel gebracht, ein Noctua NH-D9L CPU-Kühler zu verbauen, womit ich meinen i7 3770 von 3,4 MHZ auf 4,2 Hochtakten konnte... Mein Motherboard ist ein Asrock mit 32 GB Hyperx-Ram, welches ein Overclockertraum ist.
Eine große Scene in Iray mit vielen Lichtern render ich mit dieser Combi in unter 5 minuten in Full HD... und unbedingt Optix-prime-acceleration im Render Menü einschalten, weil es einen Ordentlichen Schub bei dieser Karte gibt.
L.G. Bernd
Hallo Leute,
nach längerer Zeit habe ich mich heute "getraut", mein CMS auf PostgrSQL umzustellen.
Es gibt zwar einen Forums-Eintrag hier, wonach bereits die ZA-Version 0141_048 kompatibel sein soll, jedoch vertraue ich derzeit jetzt mal nur der Windows-Firewall.
Vom ZA-Support wurde mir in einem anderen Zusammenhang eine neuer Version 0141_057 zugespielt, die ich dann aber später testen will.
So - anscheinend läuft mein (noch altes) DAZ 4.8 jetzt mit PostgrSQL CMS. Woran erkenne ich in DAZ überhaupt, daß es mit PostgrSQL statt Valentina läuft?
Einen Geschwindigkeits-Unterschied im SmartContent konnte ich subjektiv nicht feststellen. Alle Objekte scheinen da zu sein.
Dank der Migrations-Install-Routine lief alles problemlos.
Merkwürdig: Im Task-Manager sehe ich 7 Instanzen von PostgrSQL-Server. Ist das normal?
Wenn weiterhin alles glatt läuft, werde ich demnächst auf DAZ 4.9 migrieren. Schon allein wegen der ewigen iRay-Abstürze. Sowie ich mal Szenen mit photorealistic konformer Umgebung erstelle, stürzt iRay regelmäßig mit unerwarteten Exceptions ab. Windows hat keine Probleme, da ich die verfügbare Cach auf max. 46 GB eingerichtet habe.
OK - realistische Oberflächen bedeuten bei iRay eben nun mal seeehhhrr viel Speicherplatz. So ein kleiner Strand mit echten plastischen Sandriffles, noch ein paar Characters und weitere Props, treibt den Rendermemory dann schon mal leicht auf über 20 GB.
Gruß
Andreas
So, als Ergänzung:
Es sieht so aus, als ob PostgrSQL CMS auch unter ZoneAlarm der aktuelleren Versionen läuft.
Hurra !!
Oh, Iray Vorschau kann man auch mit 'ner ollen GT 730 haben... dauert halt nur 'n bissken (rd. 50 Sekunden), bis die berechnet wird.
Indoor oder outdoor? Viele Lichter sind für Iray weniger ein Problem, eher wenige. Je heller die Szenerie, desto schneller gibt's ein Ergebnis und umso besser schaut's aus.
Iray liebt viel Licht und alles, was glänzt. Transluzenz/Transparenz und SSS mag's nicht so, auch Szenerien mit vielen reflektierenden Objekten (wie z.B. Spiegel). Ich hab' mich mal an einer Spiegelsaal-Szene probiert (Wände und Boden waren da alles Spiegel), und Iray renderte sich einen Wolf. Nach zwei Stunden hatte ich das dann abgebrochen, da war's immer noch bei unter 15%, Dieselbe Szene ohne Spiegel war in 18 Minuten durch.
Es würde sich neben Optix aktiv auch empfehlen, die Instancing Optimization von "Memory" auf "Speed" zu setzen. Bei der Beta 4.9.3.56 bekomme ich bei mir bei der "Material Ball" Szene einen Geschwindigkeitsschub von rund 31%, bislang die Version mit dem schellsten Iray-Plugin. Knapp ein drittel weniger Renderdauer find' ich nicht ohne. Mit der neuen Version 4.9.3.71 werd' ich gleich mal ein paar Testrunden drehen.
Am Task-Manager. Wenn da unter "Prozesse" 'ne Menge "postgres.exe" aufgeführt wird, läuft PostgrSQL. Studio nutzt nur entweder Postgres oder "Valensina". Scheint normal zu sein, bei mir sind's 8.
Bei einer CUDA GraKa ist Geometrie weniger ein Problem, selbst komplexe Objekte mit massenhaft Polygonen belegen nur vergleichsweise wenig Grafikspeicher. Was richtig reinhaut sind Texturen, je Pixel werden ungefähr 3 Byte VRAM belegt. Da können einem richtig viele und schöne hochaufgelöste Texturen schnell mal den VRAM ausgehen lassen.
Oh ja, Arnold
ist da also ein grundlegender Unterschied zu CPU only?
Das mit den Texture-Maps ist aber so eine Sache.
Ist die Texture nur "gering" auflösend, entstehen schnell häßliche diagonale Artefakte, wie im angehängten Beispiel zu sehen.
Leider muß man dann die Dimensionen des Texture-jpgs stark vergrößern, um die "Störung" vernachlässigbar klein werden zu lassen.
Dann aber wie Du sagst -> die Kapazität der Grafikkarte schnell überschritten. IRay fällt somit in CPU-only zurück und die Ausgabe für teure GPU-Cards useless.
Bitte nicht falsch verstehen. Ich finde die Darstellung der Ausleuchtung richtig gelungen. Aber die programmtechnische Umsetzung von nVidia ist wohl eher sub-optimal.
Gruß
Andreas
Was VRam und Speichermäßig auch ordentlich reinhaut sind Normalmaps. Die braucht man auf jeden fall für Hintergrundsachen nicht, und man kann damit ganz schön "Platz" gewinnen, wen man sie rauswirft.
Da ich ja "nur" mit CPU rendere, muß ich nicht so strikt Diät halten.
Außer: Die nVidia Developer haben mal wieder fixe Variablen-Arrays statt dynamische programmiert.
Bei den Oberflächen-Strukturen vereinfachen können vor allem User, die für Video-Spiele oder Animationen gestalten. Da hat der Bertrachter so gut wie keine Chance, die "Vereinfachungen" zu bemerken.
Wenn man allerdings auch Wert auf die kleinen Details im Set legt, also z. B. Sand-Ripples, Fugen zwischen den Fliesen liegen vertieft, usw, und das nicht nur mit "fake" Displacement, sondern real, dann kommt man um höhere Displacement-SubDs und bessere Texture Maps nicht herum. Wenn man schon "Photoreal" rendert, sollte dieser Anspruch auch für die Architektur des Sets gelten. Jedenfalls da, wo der Betrachter es bei größeren Bildern auch erkennen kann.
Allerdings sind selbst solche im Anhang gezeigten Details, die bei 3Delight ganz selbstverständlich ohne großen Speicherbedarf dargestellt werden, mit iRay absolut ein Ding der Unmöglichkeit. Jedenfalls solange man sie nicht in der Mesh selbst konstruiert. Das allerdings bedeutet dann ja auch wieder eine extreme Nodes-Dichte. Läuft unterm Strich also aufs selbe hinaus.
Über den Speicherbedarf bei "CPU only" kann ich nicht viel sagen, damit rendere ich im Grunde nicht, weil's so ewig lang dauert, bis da was "fertig gekocht" ist. Beim GPU-rendern kommt's ja immer auf den VRAM der verbauten Karte an. In 4, 6, 8 GB geht schon 'ne ganze Menge rein (in meine ollen 2GB nich' so,
aber es funktioniert trotzdem irgendwie... 
). Wenn's programmtechnisch anders ginge, Nutzung des PC-RAMs, dann hätten die das bei NVIDIA wohl auch schon so umgesetzt.
"Unmöglichkeit" ist ein großes Wort.
Solch "einfache" Displacement Maps wie in deinem Beispiel funktionieren auch in Iray, und selbst bei großen Szenerien hält sich bei bedachter Anwendung deren Speicherbedarf in Grenzen, da jede Textur nur einmal in den VRAM geladen wird, egal, wie oft sie wiederholt Verwendung findet. Für sich wiederholende achitektonische Strukturen wie in deinem Beispiel (auch für Deine "Sand-Ripples,") empfielt sich die Verwendung von "kachelbaren" (tileable) Displacement Maps. Da brauchst Du dann keine 8Kx8K oder 16Kx16K Wahnsinns-Trümmer. Und ich wage mal anzuzweifeln, dass Displacement in 3Delight gänzlich ohne jeden Speichermehrbedarf vonstatten geht.
Dazu ein kleiner Iray Rendertest mit einer einfachen 500x500 Pixel "Fugen-DispMap", nix schönes, nur etwas in ein paar Sekunden "selbstgestricktes". Wie man schön erkennen kann, wird die Geometrie durch die DispMap verändert. Speicherauslastung ohne Displacement Map war 1082 MB, und mit ebenfalls 1082 MB. Scheinbar fallen der rechnerisch 0,75 MB Speichermehrbedarf der lütten Textur und SubD Level 1 hier nicht großartig ins Gewicht. Selbst mit Tiling 10.0 und 100.0 gab's ebenfalls keinen meßbaren Unterschied, Speicherauslastung blieb bei 1082 MB.
Eine Veränderung gab's lediglich beim Drehen an der SubD-Schraube: 1098 MB bei SubD 2, 1216 MB bei SubD 3 und 1676 MB bei SubD 4. Aber verständlich, wenn man berücksichtigen muss, dass jeder SubD Level eine Vervierfachung der Polygonanzahl mit sich bringt. Als ich mal forsch SubD Level 12 angewählt habe, ist mir Studio dann abgestürzt.
Okay, 335.544.320.000 Polys war'n denn wohl doch etwas zuviel verlangt... aber mit der Menge hätte wohl selbst 'ne TitanX Probleme bekommen.
Hallo BeeMKay,
sorry für das späte Reply und Danke für deine angebotene Hilfe.
Nach ein wenig Suchen im Studio selbst und in den Rendereinstellungen konnte ich das Problem lösen.
Ich hatte den Interactiven Render Mode anstelle des Photorealen Modes eingestellt. Mit dem Photorealen Modus hat es dann auch wieder mit dem emissive shader funktioniert.
Ich wünsche dir einen wunderschönen Abend.
Gruß Fieser_electro
was passiert eigentlich wenn ich ein Bild ins Backdropfenster nehme ?
wenn ich ein 16:9 Bild für mein 16:9 Viewport reinstelle ist das unschärfer als das original
wieso ?
wird das noch irgendwie transformiert ?
Ich schätze mal, es geht um ein Iray Thema? Depth Of Field bei der Kamera evtl. aktiv? Wenn nicht, dann hat höchstwarscheinlich die Textur-Kompression ihre Finger im Spiel. Die Grundwerte "512" für Medium und "1024" für High für den Schwellenwert (Threshold) sorgen dafür, dass Texturen mit einer Auflösung von 512x512 Pixeln einer mittleren, und solche mit 1024x1024 einer hohen Kompression unterworfen werden. Die Methode dient dazu, VRAM einzusparen. Wenn man z.B. eine 4096x4096 Textur unkomprimiert haben will, gibt man als Schwellenwert sowohl für Medium als auch für High "4100" ein. Fortan werden alle Texturen, deren Auflösung darunter liegt, nicht mehr komprimiert.
ich mein ja nicht im render obwohl es dort dann auch so erscheint
man sieht das ja schon im Viewport
und die Vorschau unter Environment ist immer quadratisch
also bei 16:9 verzerrt
ich glaube das man bei quadratischen backdrops den Schärfeverlust nicht hat
Achso, sach' dat doch gleich. Nur wer die richtichen Fragen stellt, bekommt (meist) auch die richtichen Antworten.
Hab' mal probehalber bei mir ein 16:9 Backdrop eingefügt, kann da aber von einer Verzerrung nix erkennen. Wenn ein Bild oder eine Textur im OpenGL Viewport etwas unscharf und verpixelt ausschaut, liegt das mitunter an der "Texture Resources" Einstellung von DS ("Edit", "Preferences", "Interface" Tab). Je mehr man den Regler von "Quality" in Richtung "Performance" verschiebt, desto unschärfer werden Bilder/Texturen im Viewport. Das hat aber keinen Einfluß auf einen Render, nur auf den Viewport.
Hallo Arnold,
Du hast das Beispiel leider nicht richtig verstanden.
Natürlich kann man eine ensprechend "grobe" Map auf einer bereits klein genug unterteilten Grundfläche (hohe Anzahl der Nodes/Divisions) aufsetzen. Darum geht es hier aber nicht.
Im vorliegenden Beispiel geht es um die Umsetzung der vorhandenen Assets aus den Westpark Wänden. Hier hat die im Produkt mitgelieferte Fläche keine Unterteilungen. Die Struktur entsteht ausschließlich durch die Displacement-Map. iRay schafft es daher überhaupt nicht, Tiefenunterschiede auf dieser Fläche darzustellen. Erst wenn Du das Displace-SubD auf mindestens 9 stellst, also eine gewisse Knotendichte erzeugst, werden erste Unterschiede der Wandstärke sehr grob sichtbar. Für die Darstellung der Fugen mit entsprechender Auflösung müßte das SubD noch viel höher geschraubt werden. Da allerdings stürzt iRay gnadenlos ab.
Bei einer Neugestaltung des Produkts müßte der Autor die Wand also gleich mit einer entsprechenden Knotendichte für iRay ausstatten. Soweit ich aber verstanden habe, läuft es für die Render-Engine dann aufs gleiche raus, egal ob die Knotendichte nachträglich durch SubD erzeugt wird, oder bereits im Objekt vorhanden ist.
Im Anhang mal der "Wireframe", so daß Du die divisions der Wand siehst.
Zur Verdeutlichung:
Unter Anwendung der original-Textures:
Aussehen mit 3Delight: http://sta.sh/0q3s6v3utyd
gerendert mit iRay bei Disp.-SubD = 3 : http://sta.sh/01h1wll3l2hy ; Dickenunterschiede werden grob sichtbar.
Bei einer anderen Wand im Gang wurden die Fugenstrukturen zwar ganz gut sichtbar, wenn Displ.-SubD auf mindestens 8 stand, allerdings tauchten da noch andere störende Effekte auf : http://sta.sh/0o2rlskham3
Daß iRay bei höheren SubD gnadenlos abstürzt hat nichts mit dem verfügbaren RAM der Karte zu tun. Bei meinem System (CPU-only) kann die Render-Engine bis weit über 40 GB gehen, trotzdem stürzt sie ab SubD = 9 gnadenlos ab. Das ist wohl eher programmintern. Bei meinen outdoor Renders ging der Speicher schon mal auf 24 von garantierten 46 GB. Nach 1,5 Stunden war das Render erfolgreich fertig.
Und das eben auch bei einem so primitiven Beispiel.
Wenn ich mich auf ein spezifisches Beispiel hätte beziehen sollen, hättest Du eins nennen müssen.
Du hast just generell die Hypothese in den Raum geworfen, dass der Iray Renderer für die Anwendung von Displacement Maps nicht so geeignet wäre (von wegen dem "Ding der Unmöglichkeit"). Und ich habe just generell ein Beispiel gebracht, das diese Hypothese zu widerlegen imstande ist...
Wenn das nun mit einem bestimmten Produkt (welches nicht einmal mit eigens dafür vorgesehenen Displacement Maps geliefert wird) nicht so wie gewünscht funktioniert, liegt das doch wohl eher an der Unzulänglichkeit des Produkts als an der Unzulänglichkeit der Render-Engine. Wenn eine Oberfläche für Iray nachträglich mit genügend Polygonen ausgestattet würde, muss man dann auch nicht mehr großartig an der SubD-Schraube dran herumdrehen. Das "Plane Primitive" in meinem 1. Beispiel hatte 20.000 Polys (bei 100 Divisions). Aber selbst mit nur 10 Divisions, 200 Polygone, bekomme ich mit derselben D-Map bei "nur" SubD 3 (entspricht 12.800 Polys) ein relativ nettes Displacement hin. Anstatt nur einzig allein an der SubD-Schraube zu drehen, kann man auch mit "Displacement Strength" und Min./Max. etwas erreichen. Es würde bestimmt auch etwas mehr bringen, wenn man nach der Vorlage der Texturen eine eigens maßgeschneiderte, zum UV-Set passende Displacement Map entwirft.
Nein, mit dem VRAM Deiner Grafikkarte nicht, da der bei "CPU only" sowieso nicht verwendet wird... Dein System-RAM aber wohl schon. Jeder SubD-Level vervierfacht die Polygonanzahl, mit SubD 9 erhält man so das 262.144-fache der ursprünglichen Anzahl an Polygonen. Wenn ich da richtig liege, ist das die Nordwand von Jack Tomalins West Park Treatment Room. Die Wände dieses Raumes verfügen laut Decimator über gerademal insgesamt 854 Polygone. Das ist nun wirklich nicht sehr viel, aber das 262.144-fache von 854 Polys sind schon reichliche 223.870.976! Nach einer hier im Forum aufgestellten Faustregel belegen 100.000 Polygone ungefähr 10 MB (V)RAM. Das macht für Deine über 223 Mio. Polys umgerechnet 22.387 Megabyte, ~ 22 Gigabyte. Nur für die blanken Wände, die Texturen und das ganze andere Zeugs noch nicht eingerechnet.
Hallo Arnold,
ok, sorry. Aber ist liegt doch wohl auf der Hand, daß die "alten" Produkte mit der "neuen" Render-Engine weiter verwendbar sein sollten (mußte das explizit erwähnt werden?). Das schließt auch die Darstellung der Details ein.
nVidia hat da aber wohl eine ganz andere Philisophie.
Reicht die Dichte der Devisions nicht aus, wird das Detail nicht dargestellt. --> Daher unmöglich.
Will man nun die Details genauso dargestellt bekommen, hat man keine Möglichkeit, nachträglich die Dichte der Devisions auf das erforderliche Maß zu ändern. Da gibt es nur den Parameter der Displ.-SubD. Das allerdings sprengt dann ganz schnell die Kapazität der (erschwinglich) verfügbaren GPU-Karten, wie Du ja selber ausgerechnet hast.
Da kann man natürlich auf das Verwenden des "fake-" Displacements (bump) umschwenken. Allerdings nur in Bereichen, wo es auf die gewisse Detaildastellung nicht so genau ankommt, etwa bei Animationen, Videospielen oder im Hintergrund, wo es nicht mehr so genau erkennbar ist.
Soll man nun also, nur weil die Ausleuchtung der Szenen besser ("anders") ist, nochmals das Konto mit demselben hohen Betrag belasten, nur um auf iRay angepaßte Produkte zu erwerben?
Oder soll man bei den lieb gewonnenen alten Produkten auf gewisse Details in der Darstellung verzichten?
Und bisher ist ja noch kein Autor hingegangen und hat die Objekte seiner alten Produkte mit der notwendigen Devision-Dichte neu gestaltet.
Um auf das verwendete Beispiel zurück zu kommen:
Bei einer ca. 6 Meter langen Wand sind Details im Bereich mehrerer Millimeter darzustellen.
Für 3Delight kein Problem, selbst ohne Verwendung von Devisions, bei iRay sprengt es die Kapazität der Engine.
Hallo Arnold,
eine Nachfrage noch zu Deiner letzten Aussage:
Gilt diese Berechnungsformel auch für die Devision-Dichte, wenn diese gleich "native" bei der Konstruktion der Wand so eingebaut worden wäre?