Beiträge von maXem

    .. soweit ich mich erinnere: Nein :(

    Danke! esha  =) .. sowas hatte ich ja schon befürchtet. Doof, das!


    Was ich bei dieser ganzen Faceroom-Geschichte zumindest schonmal mitgenommen habe, ist, dass es 'ne gaaanz blöde Idee ist, 'apply' zu klicken, anstatt ein Morphtarget zu spawnen. Durch Letzteres hat man zumindest auch später die Möglichkeit, die Intensität zu variieren oder die Shape auch ganz rauszunehmen .. bei 'apply' sind die Sachen scheinbar irgendwie/irgendwo 'versteckt' was die ganze Geschichte schon 'n büüsch'n unflexibel macht. Nervig!.. mit den Targets kann man ja an und für sich ganz gut werkeln ..


    Ist eben nur aus 'Plattenspeicher'-mäßiger Sicht nicht wirklich der Knaller, für jeden Pups ein komplettes Char-File ablegen zu müssen, da ich - auch aus dem bereits von dir genannten Grund - kein allzu großer Freund von 'externen binary'-Morphs bin. Also sind die bei mir generell in die Figur injiziert und dann als 'klassisches' .cr2 gespeichert. So lässt sich der Spaß dann u.U. eben auch im |Studio nutzen. Haken dabei ist eben: die Dinger sind u:U. halt mehrere hundert MB groß :rolleyes2:.. dat läppert sich!


    (War btw. seinerzeit der ausschlaggebende Grund, warum ich mir in einer Minute der Schwäche :gap dann doch noch Poser10 unter den Nagel gerissen habe. =) Afaik gibt's für D|S 4.x ja keine Möglichkeit mehr, irgendwie die Poser-Binärmorphs nachträglich zu injizieren. Und das Bearbeiten der .cr2 - oder auch .pp2/.hr2 - Files, damit sie gleich beim Laden solche Morphs mitnehmen, war - zumindest bei mir - i.a.R. auch bestenfalls in einem Drittel der Fälle oder so von Erfolg gekrönt :gaehn ..)


    Wenn man nun aber ohnehin nicht ums ver-.cr2-en drumrum kommt, tut's ja auch der gute, alte MorphManager .. um die Targets von einem .cr2 in ein anderes zu kopieren. Vielleicht ließe sich ja auch mit 3DU's Injection Magic oder DAZ'ns Injection Pose Builder ein Pose-File erstellen, aber das wäre wohl auch eher 'was für Leute, die ihre Shapes weitergeben wollen.


    Irgendwie verstehe ich immer mehr, warum du esha die Fronten gewechselt hast. =)

    Tjoaaa .. nameless or not .. vote ebenfalls für no.3 .. hat - neben dem 'rundesten' BG - auch den schönsten Lichteinfall / Schattenwurf. =)


    Nummer 2 hat imho auch 'was .. so rein von der Licht- und Hintergrund-Kombination her .. ist so'n bisschen 'cyber-like' .. und passt deshalb vielleicht nicht gaaanz so gut zu dieser Art Protagonistin. Mach' dat maa mit 'ner etwas 'girly'-mäßigen 'Techno-Schnalle' :DD..

    Dankeschön! esha & Thunder666  =)

    .. das wird über den Shader geregelt ähnlich wie das smooth-shading und funktioniert auch bei Objekten die keine UV-Map haben

    Ahh .. lles klar. Ist doch mal nice ..:].. danke!


    Und ja, ich kenne die TexTools :DD.. hab' sie auch in der .79b-er Version, aber wie bereits angemerkt: brauch' ich für meine aktuellen Geschichten eigentlich nicht wirklich. =)

    Huhu '^^


    blöde Frage: lassen sich für die nativen Poser-Figuren im Face-Room (Poser10) erstellte Shapes in irgendeiner Form als auf-die-Basis-Figur-erneut-anwendbares Preset speichern bzw. exportieren?


    Ist ja doch schon 'n bisschen blöd, entweder die ganze Figur immer wieder als .CR2 speichern oder die entsprechenden Geometrien (für Head, Neck, Eyes) umständlich einzeln exportieren zu müssen, um sie dann wieder als Morph-Target importieren zu können. :gaehn .. die Face-Presets (.FC2) speichern afaik ja lediglich die 'Expression'-Morphs, die im Parameter-Panel des Pose-Rooms verfügbar sind ..


    Gibt's irgendeine andere - und eventuell etwas praktikablere - Möglichkeit?

    Aus meiner Sicht müssen es nicht immer aufwendige Szenen sein. Manchmal ist weniger mehr.

    Finde ich auch. =)

    Von der Kamerapostion hätte ich wohl einen flacheren Winkel bevorzugt und ein, zwei unterschiedliche Kristalle .

    Naja .. erstmal mehrere Krsitallformationen haben :gap.. war der erste Versuch (und breche mir in Sachen Modeling ja ohnehin immer einen ab :whatever). War ja auch eeeigentlich nur mal als Testrender gedacht, um zu sehen, ob ich's so machen kann .. dann kam die Glas-Shader-Test-Nummer hinzu .. wie's eben manchmal so ist =) ..

    Deswegen ist der Winkel auch ein bisschen steiler .. 'Begutachtung' der Caustics und so. Außerdem wäre für einen flacheren Winkel wieder etwas für den Szenen-Hintergrund nötig gewesen:DD..


    Danke! =)



    Kushanku

    Danke!.. auch hier nochmal für die Hinweise. =)

    Wie kann ich das verstehen?.. werden durch die Nodes dann quasi Displacement- bzw. Normalenmaps generiert?


    Allerdings bräuchte ich in diesem speziellen Fall und für den vorgesehenen Bestimmungszweck keine 'geometrischen' Details dieser Art. Die Objekte sind letztendlich vergleichsweise klein sichtbar .. und dazu noch selbstleuchtend. Hier liegt die Priorität tatsächlich eher auf möglichst geringen Polycount, um viele dieser Teile in der späteren Szene nutzen zu können .. und 'ne hübsche diffuse/illumination-Map, natürlich. :monster2

    Danke für den Tut-Link! =)


    Ja, hab' auch schon gesehen, dass die 3er Version dieses Plugins nun offenbar nur noch Nodes nutzt.


    Auch, wenn ich von Blender's Nodesystem ja generell sehr! angetan bin, finde ich ziemlich schade, dass die Tool-Paletten-Option nun nicht mehr gegeben ist. War zum groben Testen und Erstellen eigentlich 'ne schöne Sache, da man - so man wollte - ja wirklich auch alles direkt im Viewport machen konnte, ohne 'nen Node-Editor andocken zu müssen. (Bin deshalb auch wieder zu Version 2.9.1 zurück ..)


    PS*

    Hänge zusätzlich noch mal den direkten Link zur Homepage des Addons auf GitHub mit an .. dort gibt's btw. auch 'ne kurze Node-Referenz.

    Ich weiss ehrlich gesagt gar nicht was das für ein Programm sein soll ..

    Autodesk 3ds max' natives Dateiformat


    nach - egal was - konvertieren

    Kannst es ja mal mit einem Online-Objekt-Konverter probieren, z.B. diesemjenigenwelchen hier: https://www.yobi3d.com/3d-file-convert

    Keine Ahnung, ob das funzt .. hab' ich nicht ausprobiert.


    Generell ist es so, dass eigentlich alle 'programmspezifischen' Formate (.max, .c4d, etc) eigentlich nur wirklich gut mit der dafür vorgesehenen Applikation in ein anderes Format exportiert werden können. Selbst Konverter, die vielleicht sogar mal solche Formate lesen können, liefern i.a.R. eher bestenfalls durchwachsene Ergebnisse.


    sind für jeden Hinweis dankbarst!

    Ja, eine ".max converter" Suche mit der SuMa des Vertrauens könnte dabei gelegentlich hilfreich sein. ;)

    So habe ich jetzt gerade auch auf die Schnelle den o.g. Online-Konverter gefunden ..

    *tzes* ... Bildbeschreibung für die Galerie zu lang .. na sowas aber auch!.. :gap .. also dann eben hier:tongue: ..



    [ Cinema 4D CE+6 | Blender/CYCLes 2.76b ]


    Ich wollte mal ein paar schlichte Kristallformationen für die Verwendung in einer Game-Engine verbrechen .. und da die Meshes für ebendiese ohnehin trianguliert sein müssen, ausschließlich mit Trigonen werkeln, anstatt - wie gewohnt - Quads zu nutzen und diese nachträglich zu triangulieren. Dadurch lässt sich die Oberfläche ja bereits von Grund auf etwas 'facettierter' gestalten.

    Jaajaa, schon klar .. eeeigentlich kein großen Ding, aber für einen Modeling-Dau (wie mich) schon eine kleinere Herausforderung :gap..


    Persönliche Vorgabe war, hierfür möglichst wenige Polys zu verwenden.

    Fand das reine Trigon-Handling schon etwas gewöhnungsbedürftig .. irgendwie ist man(n) ja doch eher auf Quads eingeschossen.


    Habe für den 'Bau' mein reichlich betagtes C4D bemüht .. komme damit für solche Geschichten nach wie vor etwas besser zurecht, als mit Blender, aber dann zum 'Testrendern-und-Angucken' nach b/Cycles verfrachtet. Außerdem möchte ich auch später die Texturmaps aus Cycles-Mats backen.


    Durch die Schlichtheit der Szene, bot sich dann auch eeendlich mal die Gelegenheit, ein paar unterschiedliche Glas-Shader-Setups / Nodegroups (darunter auch 'kommerzielle') sowohl hinsichtlich der eigentlichen Mesh-Optik selbst, der Caustics-'Distribution', als natürlich auch der benötigten Renderzeit zu vergleichen. Interessanterweise war es dabei mal wieder so, dass aaausgerechnet die Shader, die in ihrer 'Produktbeschreibung' am lautesten "PBR!" schreien, in der Praxis am wenigsten überzeugten .. teils sogar in allen drei o.g. Punkten. War für mich allerdings nicht wirklich 'ne Überraschung. :ausheck


    Um die scharfen Kanten der Meshes für's Cycles-Rendering etwas zu 'entgraten', kommt temporär der Bevel-Modifier zum Zuge .. für den eigentlichen Bestimmungszweck der Objekte allerdings unpassend. Beleuchtung lediglich über ein Low-Rez-HDRi im Umgebungs-Kanal. Bild-Vignettierung und leichter 'Tint'-Effekt entstehen durch eine von mir auf Filmic! angepasste Stöpselei von Blender-Compositor-Nodes.


    Cycles-Freestyle-Wireframe-Render:



    Alternative Bildvariationen hab' ich in einem bLog-Post ver-Slideshow-t.

    Konstruktive Tipps von Modeling-Experten sind (wie immer) gern gesehen =) .. *mit-Zaunpfahl-wink*


    Donköö für's Gucken! :gap

    .. unter "Point at" wählt man eben die o.g. Camera 1 aus. Jetzt könnt ihr mit der Kamera beliebig um eure Figuren herumfahren, sie werden immer in die Kamera schauen.

    Ja, allerdings ist diese Option eher ein zweischneidiges Schwert, da die Figuren hierdurch im überwiegenden Teil der Fälle zum Schielen neigen. ;) 


    Hat etwas mit den Pivot-Punkten und der entsprechenden Rotation der Augäpfel zu tun. Wenn schon 'Point at', dann am besten tatsächlich auf zwei Null-Objekte/Empties/what-ever, die etwa 'augenbreit' auseinader stehen .. und diese dann ggf. an die Kamera parenten.


    [/ot]

    Falls sie das für Poser wieder zersägt haben... auaua.

    Kann ich nicht wirklich etwas zu sagen, da ich mich schlichtweg zu wenig mit Poser auskenne. Ist für mich eben nur das Programm, um nicht-D|S-kompatibles Püppigedöns zu händeln. =) Möglicherweise läuft das dort jetzt - und bei den neueren Figurgenerationen - ja auch anders, aber die 'alte' Methode funzt trotzdem auch nach wie vor noch.


    An D|S'ns MorphLoader hab' ich mich bisher noch nicht so recht 'rangetraut, obwohl ich eeeigentlich ja schon ganz gern mal eine schöne Goblin- oder Pixie-Shape für Genesis1 zurechtstümpern würde. Gibt's ja so gar nicht .. naja, oder zumindest keine, die meiner - ganz persönlichen - Vorstellung davon, wie Goblins oder Pixies auszusehen haben :DD entspricht .. oder dem auch nur nahe kommt. Tun aber auch Shapes solchen Namens bei anderen DAZ-Generationen oder irgendwelche Standalone-Figuren IMHO nicht wirklich ..

    Aber hat bei mir ja ganz offensichtlich (noch) nicht soo hohe Priorität .. ansonsten würde ich mich sicherlich etwas intensiver mit dieser Materie befassen :gap ..

    was und wie muss man sich das vorstellen ? Ich habe bis dato immer nur ein ganzes Mesh und keine Körperteile

    Naja, bei Poser war's (und ist es eigentlich auch immer noch) so, dass jedes Körperteil einer Figur wie ein 'Einzelobjekt' gehandhabt wird. Keine Ahnung, ob es in dieser Hinsicht auch eine bessere Lösung gibt .. dies ist jedoch die einzige, die ich kenne und je genutzt habe.


    Praktisch exportiere ich bspw. den 'Head' solo als .OBJ, importiere ihn in den Modeler, schiebe ein paar Vertices in der Gegend herum, exportiere das dann wieder als .OBJ und lade diesesjenigewelche dann in Poser als Morphtarget wieder direkt in den Figur-Head. Möchte ich auf diese Weise ggf. mehrere Körperteile ver-morphen, muss das für jedes einzeln gemacht werden. Sind diese dann alle wieder importiert, lässt sich daraus auch in der Figur selbst ein FBM erstellen.


    Ja, ich weiß .. alles andere als effektiv :DD .. aber eine andere Möglichkeit kenne ich nicht. Hab' mich allerdings auch nie wirklich näher mit dieser Materie auseinander gesetzt, weil ich als 'Samstagnachmittags-Möchtegern-Morpher' ohnehin nur selten mal in die Verlegenheit kam, sowas nun uuunbedingt 'brauchen' zu wollen =) ..

    Woran liegt das, das manche Gebäude und Szenen Licht richtig fressen und andere nicht?

    Ich nehme jetzt mal das letzte Promo-Bild aus deinem Link als Basis.


    Beleuchtest du dieses Objekt ausschließlich mit einem reinen Environment-Light (bspw. HDRi im Umgebungs-Kanal), werden uuunheimlich viele (Licht-)Strahlen unnötig an Stellen verbraten, die für die Szene eigentlich irrelevant sind: die Unterseite der Brücke, die unteren Träger/'Füße', die Außenseiten der Container .. und im Inneren des Ganges, in dem sich dann womöglich die Kamera befindet, kommen vielleicht lediglich noch 10-15% eben dieser an. Das ist natürlich zuhöchst ineffektiv, da deshalb entsprechend ein Vielfaches an Samples in die gesamte Szene gejagt werden müsste, damit man auf ein gutes Niveau kommt.


    Deshalb ist reine Environment-Beleuchtung für sowas auch eher suboptimal.

    Esha hat's schon geschrieben: ein SunSky-System wäre hier schon etwas besser .. der 'Sky', der ja durchaus auch eine Environment-Textur sein kann, beleuchtet zwar immer noch so, wie oben beschrieben, aber wenn die Sonne dann im Winkel in den Innenraum knallt, hat die Renderengine hier auch schon deeeutlich mehr Lichtstrahlen (an der 'richtigen' Stelle), mit denen sie arbeiten kann.


    Noch besser wäre hier der Einsatz von Light-Portals.

    Glaube, D|S'ns iRAY-Implementierung hat sowas nicht mit an Bord, oder? (iRAY Photoreal für Maya kann das afaik ..)


    In der Regel läuft so ein Light-Portal über ein Area-Light, bei dem diese entsprechende Option aktiviert wird. Dieses wirkt dann faktisch nicht mehr als Area-Light, sondern 'sagt' der Renderengine, welcher Bereich der Szene beleuchtungstechnisch bevorzugt behandelt werden soll. Die restliche Szenerie wird zwar dennoch (auch indirekt) beleuchtet, aber auf diese Weise markierte Bildbereiche bekommen dennoch u.U. deeutlich mehr Licht ab.


    Normalerweise benutzt man sowas eher für Innenräume, die vielleicht nur eine Fensterfront haben, durch die das Licht von Außen eindringt. Ginge aber wohl auch in diesem Container-Szenen-Fall. Würde hier wahrscheinlich einfach fünf Lichtportale setzen, quasi als Quader(form) um die 'Container-Aufbauten' (jeweils eines an den Seiten und eins von oben).

    Erstellen kannst du einen Morph in jedem beliebigen Modellingprogramm.

    Ja, erstellen geht schon .. ob man sie dann aber auch sauber transferiert bekommt, ist nochmal eine andere Sache. :DD


    Ich hatte daaamals mal Morphs für Poser in Cinema4D erstellen und dann eben auch auf die seinerzeit typische Weise als Target ins jeweilige Körperteil laden wollen. Hat bspw. nicht geklappt .. dadurch hat's mir das Zielkörperteil komplett zerlegt .. wobei .. 'gesprengt' wäre wohl der passendere Ausdruck. :gap Ich nehme ja an, das liegt/lag an C4D's bedäpperten build-in-.OBJ-Exporter, denn sowohl Skalierung als auch Normalen etc. haben an und für sich schon gepasst. :schiel 

    Nachdem ich's dann in Blender gemacht hatte, ging's ..

    Habe nochmals einen duf-Import (originale Genesis1 Figur ohne Klamotten) ausprobiert . Dafür in Blender das plugin , diesmal Version 1.3 neu installiert, aktiviert und bei DAZ das aktuellere Script (dsa-file) von 1.3 eingesetzt, Ergebnis: gleiche Fehlermeldung.

    Das ist ärgerlich .. und schade.


    Hatte oben ja schon erwähnt, dass der Import von Genesis1 auch für mein Empfinden auffallend 'problembehafteter' zu sein scheint, als bei den neueren Versionen. Genesis3 ging - gefühlt - deutlich besser. Habe den Verdacht, dass bei meiner G1 irgendetwas (vielleicht bei der Referenzierung einiger Morphs?.. oder auch der 'Übersetzung' des TriAx-Weightmappings) nicht so ganz passt, was dann zu den - für mich teils auch recht unverständlichen - Fehlermeldungen führt. Hatte auch schon bei teleblender3 das Problem, dass in Pfaden innerhalb des DAZ-Content Sonderzeichen vorhanden waren, die dann auf Blenderseite fehlinterpretiert wurden. Läuft dort halt alles über Python und das kann ja bekanntermaßen ein bisschen empfindlich sein, was solche Sachen betrifft.


    Ist von Entwicklerseite wahrscheinlich nie wirklich mit G1 getestet worden, da es dieses Plugin noch nicht soo lange gibt und der überwiegende Teil der vermutlich ohnehin recht geringen Userschaft, die überhaupt Verwendung für sowas hat, ganz allgemein eher die neueren Genesis-Generationen nutzt .. wie ich mutmaße, einschließlich des Entwicklers selbst. (Allerdings bringen solche Spekulationen wohl im aktuellen Fall - und praktisch gesehen - rein gar nichts.)


    Muss aber auch gestehen, dass ich diesen .DUF-Importer lediglich mal kurz angetestet hatte, dabei allerdings auch recht schnell merkte, dass er für mich - da ich i.a.R. nur Stills rendere - nicht soo brauchbar ist. Armatures sind mir da meist mehr im Weg, als dass sie nutzen.


    teleblender3 für D|S ist an und für sich eigentlich recht simpel und was den reinen Objekt-Transfer betrifft, wirklich komfortabel =) .. vielleicht klingt es in meinem Posting dort nur komplizierter, als es ist. Neige schon dazu, ein bisschen 'weiter auszuholen'. Im Grunde nur DAZ-Skript und Blender-Module entpacken und an die entsprechenden Stellen verfrachten. 'Der Rest' läuft dann über den Export-Dialog in D|S, der eigentlich auch, einmal an die persönlichen Bedürfnisse angepasst, so gut wie nie und wenn, nur geringfügig angepasst werden muss. (Nutze dies seeehr ausgiebig seit rund 3 Jahren und kann das somit beurteilen.) War an dieser Stelle aus meiner Sicht nur eher zweite Wahl, da es lediglich die reine Objektgeometrie verfrachtet. Der .DUF-Importer wäre für deine Zwecke sicherlich die sinnvollere Wahl (gewesen).


    Aber für den Fall, dass du teleblender dennoch mal ausprobieren möchtest, kann ich dir die Prozedur auch gern nochmal etwas kompakter vermitteln oder ggf. auch bei Problemen helfen. (Nur so als Idee ..)



    PS*

    Du könntest hier ja ggf. mal dein Fehler-Log (daz_importer_errors.txt) als Anhang mit hochladen.

    Vielleicht finde ich ja was .. obwohl ich in dieser Hinsicht auch nicht aaallzu optimistisch bin..

    Bis ich auf die Idee gekommen bin, die Cookies zu löschen. Jetzt funzt es wieder =)

    Ist vielleicht sogar die generelle Lösung?.. ich hatte nämlich in dieser Hinsicht gar keine Probleme.


    Mein Startlink (in Firefox) ist schon ewig einfach http://www.3d-board.de/ .. also auch nicht einmal https oder sowas und bei mir lief's rund. Allerdings werden beim Beenden meines Browsers standardmäßig immer alle Cookies gelöscht.

    Da du aktuell wieder etwas offensichtlicher hier im Forum unterwegs bist, djblueprint , nutze ich die Gelegenheit, um mal ein bisschen zu nerven:

    seit dem letzten Update werden ja die Bilder, die (auf die neue Weise) direkt in Beiträge eingebettet sind, nicht mehr dargestellt, wenn der Leser nicht im Forum registriert bzw. eingeloggt ist. Und auch für den Zugriff auf die jeweiligen Links, fehlt dann die 'Zugriffsberechtigung'.

    Soll das so?.. vielleicht aus Traffic-Gründen oder ähnlichem?

    ??

    Es bedarf nicht unbedingt exotischer Datei - Formate, um Inkompatibilität wahrscheinlicher zu machen. "Png" ist z.B. nicht gleich "png", denke da an Sachen wie unterschiedliche bit-Tiefe, Transparenz und vor allem an alpha channels.

    Jap, sowas meinte ich eigentlich auch mit 'exotisch' .. also im Prinzip alles, was vom im Normalfall üblichen Standard - wenn vielleicht auch nur geringfügig - abweicht. Das (layered) .EXR-Format ist auch so ein typischer Fall, der u.U. schon gern mal zu Huddeleien führt oder auch normale .TIFs, je nachdem, welche Komprimierungsmethode verwendet wird (LZW, ZIP, etc.).


    Falls Dir, maXem (oder irgendeinem anderen) noch was zu dem Gesamtthema einfällt, gerne, werde mich dann wieder melden.

    Im Prinzip eigentlich schon .. da gäbe es bspw. auch noch mcjTeleblender3 .. meine - ganz persönlich - präferierte Methode, um Objekte (für Stills) von D|S nach Blender zu verfrachten. (Der Link führt zu einem Forumsthread in dem ich hier mal ein bisschen was dazu geschrieben habe.) Habe aber gerade die vage Befürchtung, dass dir diese Möglichkeit wahrscheinlich auch zu komplex, kompliziert oder umständlich sein wird ..



    Edit/Nachtrag:


    Obwohl dein Posting für mich so klingt, als hättest du den .DUF-Importer bereits abgeschrieben, empfehle ich dir - für den Fall, dass nicht - mal die 1.3er Version des Plugins zu probieren. Habe vorhin probehalber eine Genesis1 mit etwas Kleidung und Haaren importieren wollen und sowohl mit Version 1.1 als auch 1.2 hat's nicht geklappt, mit 1.3 allerdings schon.

    Ja, ich kann gut nachvollziehen, dass 'Testprozeduren' wie diese schon ein bisschen anstrengend werden können. =) .. könnte selbst auch das ein oder andere Liedchen davon trällern :gaehn..

    Bei dem ersten Test damit (" Genesis Import") meldet Blender, dass der Pfad zu "My library" nicht existiere, was kein Wunder ist, denn ich habe vor Jahren diese Pfade zugunsten meiner eigenen Ordnung geändert (was das "duf" plugin natürlich nicht weiß).

    Sollte an und für sich kein Problem sein, denn so lange dein Ordnungs-System in D|S selbst funktioniert, dürfte dies auch hier keinen negativen Einfluss haben. Die Pfade zu Geometrie- oder Textur-Dateien sind ja nicht im Plugin 'ge-hardcoded', sondern werden aus der importierten .DUF-Datei gelesen und übernommen.


    Allerdings benötigt das Plugin den generellen Pfad zu deinem DAZ-Content-Ordner, also dem Hauptordner, in dem sich auch die 'data'-, 'Runtime'-und 'wie-auch-immer-du-sie-ggf.-(um)benannt-hast'-Preset-Unterordner befinden. Der oder die Pfad/e - je nachdem, ob du vielleicht auch mehrere Hauptcontent-Ordner am Start hast - müssen in der Settings-Sektion des Plugins (3. von oben) eingetragen werden (s. Screenie)..



    .. nutzt du evtl. mehrere Hauptcontent-Ordner, einfach 'Number Of DAZ Paths' erhöhen und darunter erscheinen dann entsprechend viele zusätzliche Pfadeingabefelder.


    Sollte das ein Lösungsansatz für mein generelles Problem sein ? Möglicherweise, so meine Spekulation, finden ja auch andere Programme bestimmte files nicht, die sie für korrekten Import benötigen.

    Nö, halte ich eher für unwahrscheinlich.

    Ist ja im Prinzip das Gleiche, wie bereits oben von mir geschrieben: die eigentliche Objektgeometrie wird in das jeweilige Geometrie-File (.OBJ) exportiert und die Pfade zu den anderen benötigten Dateien (bspw. Texturen) werden entsprechend angepasst. So lange das zu exportierende Objekt zum Zeitpunkt des Exports korrekt in D|S angezeigt wird, sollte es auch nach dem Export passen.


    Was hier eventuell mal zu Problemen führen könnte, wäre bspw. ein etwas 'exotischeres' Datei- oder Kodierungs-Format (zB. für Texturen), das vielleicht u.U. nicht vom Zielprogramm gelesen werden kann. Aber da wir hier in D|S ja i.a.R. mit den ganz normal üblichen Formaten wie .JPG, .PNG etc. arbeiten, ist dies wohl auch eher unwahrscheinlich.

    Ich möchte die exportierten Genesis Figuren, mitsamt ihren Animationsframes und Texturen, letztlich wieder für kurze 3D Animationen in einem anderen 3D Programm verwenden. Da dieses Programm nur directx - files, zudem mit limitierter Polygonenanzahl, importieren kann, benutzte ich als erstes die Zwischenstation "Blender" ( verfügt über ein "directx " plugin und ein "decimate" Tool), um zu konvertieren und zu reduzieren.

    Na, DAS sind doch mal Nägel mit Köpfen! :]


    Vielleicht habe ich hier ja sogar genau das, was du brauchst: DAZ-File Importer-Plugin für Blender

    Zugegeben, das Teil ist schon 'n bisschen 'sperrig' und auch ziiiemlich pingelig, was Ungereimtheiten aller Art in den D|S-Dateien betrifft, aber man kann damit dennoch recht häufig D|S-'native' Figuren (Genesise und andere, die im .duf/.dsf-Format vorliegen) inklusive Rigging!, Haaren, Klamotten, Props direkt importieren und auch nachträglich bspw. Materialien, Expression-Morphs, Posen oder Animationen anwenden. Morphs werden dann in Blender bspw. zu Shape-Keys .. nicht so komfortabel, wie in D|S, aber immerhin. Ist eigentlich auch ganz ordentlich dokumentiert .. nur eben - wie's für mich scheint, insbesondere im Zusammenspiel mit Genesis1 - gerne ein bisschen zickig. (Kann dann leider mit den Error-Logs auch nicht allzu viel anfangen :gaehn..)


    Da ich in Blender aber keine Texturen sah, probierte ich es mit diversen anderen Programmen, um überhaupt erstmal zu sehen, ob irgendeins meiner Programme den DAZ Export versteht.

    Ich gehe jetzt mal davon aus, dass du für deine beschriebenen Zwecke im 'Blender ('internal') Render'-Modus werkelst und nicht etwa Cycles, oder? Unter Cycles werden bei mir nämlich auch keine Texturen angezeigt, da beim ganz normalen .OBJ-Import keine Shader-Nodes generiert werden. Mit Blender Internal läuft's.

    Zunächst wäre es eigentlich schon recht schön, wenn du etwas konkreter sein könntest, was das oder die 'Zielprogramm/e' betrifft. Ebenso, ob du die Objekte für Stills oder Animationen exportieren möchtest. Dies würde es potentiellen Helfern schon erheblich erleichtern, der Problematik ggf. am eigenen System mal auf den Zahn zu fühlen.


    Generell würde ich empfehlen, beim .obj-Export die 'Collect Maps'-Option zu aktivieren, da die Texturpfade hier in D|S recht häufig Leer- oder Sonderzeichen enthalten, mit denen andere Programme mitunter nicht klarkommen. Somit lässt sich zumindest schonmal diesbezüglichen Problemen vorbeugen. Danach eventuell mal einen Blick in den Maps-Unterordner beim exportierten Objektfile werfen und schauen, ob die Dateinamen selbst nicht auch von solchen Sachen betroffen sind. Dann ggf. die Texturnamen korrigieren und diese Veränderungen natürlich auch im .mtl vornehmen.


    Ansonsten könnte ich jetzt so aus dem Stehgreif nichtmal raten, woran es bei dir konkret liegen könnte .. denn bei mir geht's: Genesis1 aus D|S 4.8 exportiert und danach probehalber wieder in D|S 4.8 selbst, Poser10, Blender Render ('Internal') Hexagon und Sculptris importiert und auch mal im GLC-Player angeguckt. Texturen sind überall vorhanden, wenn vielleicht vereinzelt auch mit kleineren Fehlern. Also .. tjoa .. keine Idee ..