Hi,
was hälst Du von spacebones Shuttle:
http://www.sharecg.com/v/63187…MPS2A-Beaver-.obj-version
Gibt es auch noch in Versionen für Bryce, Carrara und Vue.
rk66.
Jau, du kannst ja noch ein paar Technikteile anpappen... 
Mit der Inneneinrichtung haperts etwas, aber ein schönes Cockpit ist vorhanden.
Ja.
So war's.
Ich hab's gesehen.
: 
Weiß grad nicht, wer, aber jemand hier im Forum hat die Signatur "Jedes Werkzeug ist nur so gut wie sein Benutzer." Das stimmt. In sofern kann man aus beiden Programmen lausige und hochqualitative Bilder rausholen, die man mit PW vermurksen oder verbessern kann.
So isses.
Man kann - und hat - auch in Carrara, Vue, Luxrender oder Octane grausige Sachen fabrizieren/fabriziert.
*Schauder*
Ob Poser lohnend ist für dich oder nicht, kannst du nur selbst entscheiden.
a) Ausschlaggebend ist in erster Linie wie dir das Programm "in der Hand liegt" - sprich wie gut du mit dem Bedienkonzept zurecht kommst. Findest du schnell die Funktionen die du brauchst, ist die Bedienung für dich intuitiv und logisch, kannst du nach 15 Minuten etwas damit anfangen oder suchst du noch...
Das Zweite ist dein Workflow - wie reiht sich das Programm in deine Umgebung ein, willst du es exklusiv nutzen, sprich Szenen und Animationen in einem Programm erstellen und Rendern, oder es nur als Zwischenschritt benutzen? Für letzteres sind die Schnittstellen wichtig.
Für Poser gilt üblicherweise die Kombination Poser -> (ZBrush) -> Vue/Luxrender/Octane als Weg des geringsten Widerstands während für DAZ Studio eher Hexagon -> DS -> (ZBrush) -> Carrara/Luxrender üblich ist. Querverbindungen sind möglich, aber meist nur über Collada oder OBJ Austausch.
Tools zur Arbeitserleichterung gibt es einige für Poser, alle in der Scriptsprache Python, viele kostenlose, einige zum bezahlen, und, bei Kenntnis, zum selber schreiben.
Posers Rigging System hat sich seit Version 4 dramatisch weiterentwickelt, und das implementierte Weightmapping ist meiner Ansicht nach aufgrund des zusätzlich vorhandenen "Bulge-mapping" dem von DAZ leicht voraus, aber das relativiert sich schnell, da es außerhalb des Poser-nativen Contents keine Rolle spielt und üblicherweise mit DAZ kompatiblem Content gespielt wird.
b) Was das eine nicht hat, hat das andere, und umgekehrt. Was davon als "Killerfeature" zu werten ist hängt wiederum von deinem persönlichen Gebrauch ab (für mich zum Beispiel ist das Morphing Tool eins, und die Möglichkeit einfach Morphs auf andere Figuren zu kopieren). Eine Auflistung der Möglichkeiten gibts hier.
c) Poser kommt mit ca 1.5 GB an Inhalten, glaub ich, wobei gut die Hälfte "altes Zeug" ist, sprich Poser 5 aufwärts. Die Figuren in Poser sind nicht besonders geglückt, und werden auch kaum mit Inhalten unterstützt. Die neuesten, Rex und Roxie, sind ganz in Ordnung aber auch hier ist das Problem der mangelnde Support.
Die Standardfiguren in Poser sind heute Victoria4 und Michael4 und vielleicht noch Dawn. Die DAZ Genesis Serie wird unterstützt, jedoch nur behelfsweise, und längst nicht alles was in DS damit machbar ist geht auch in Poser, oder nur mit Haken und Ösen.
d) sh unter a)
Ich beobachte bei einigen aus Poser exportierten 3D-Szenen bei Figuren, die über Transmaps bei Haare und Wimpern verfügen, Störungen beim Rendern in Octane (1.53.1). Wimpern werden in manchen Fällen gar nicht mit Transmap dargestellt, d.h., ich sehe dann in Octane nur den Mesh der Wimpern mit schwarzem Hintergrund und weißen Wimpern, also die Transmap im fertigen Bild. Das lässt sich zwar leicht korrigieren, aber es nervt, weil Octane ständig als Standard eine Alphamap verwenden will (PNG), die es aber nicht gibt. In Poser selbst werden die Wimpern mit der Transmap (JPG) korrekt dargestellt.
Das kenn ich nicht so, üblicherweise sollte im Opacity Kanal dieselbe Transmap stecken wie auch in Poser/DS. Unter Umständen muss sie in seltenen Fällen invertiert werden.
Viel schlimmer ist das bei Haaren, die in Poser absolut korrekt dargestellt werden, in Octane aber irgendwie mit dem Charakter /Kopf interferieren, d.h., die Transmap läuft offensichtlich irgendwie durch die Hautschicht mit deren Map hindurch und verursacht da eine Störung, die sich in schwarzen Linien oder ganzen Feldern zeigt.
Das war bis vor kurzem (Octane 1.2) nicht so, aber jetzt sind meine Files im 1.5-Format gespeichert und lassen sich in 1.2 nicht mehr öffnen.
BTW, das Problem tritt nicht bei ALLEN Haar-Files auf; Auffällig ist, dass es in nahezu jedem Haar von SAV/Artvartanian auftritt, also z.B. in Moikania und Alpha-Scalp - siehe Bild.
Das liegt vermutlich am rayepsilon Wert, der neuerdings per Default auf 0 gesetzt ist. Erhöhe ihn leicht (0.00001), das sollte die Streifen eliminieren.
Na hey - nich meckern!
Wann bekommt man schon mal ein Irrenhaus mit Strand für lau? 
Nachteil: das Mesh hat eine ganz eigenartige Tris-Struktur. Beim Weightmappen in DS und Poser werden die Symmetrietools voraussichtlich nicht funktionieren, da diese auf ein 100%ig exakt gespiegeltes Mesh angewiesen sind. Und soweit ich gesehen habe, muss man die UVMaps nachbearbeiten.
Ich denke, mit MD erstellte Sachen eignen sich mehr für dynamische Kleidung. Hier kommt auch die Tri-Struktur sinnvoll zum tragen, da Falten in unterschiedlichsten Richtungen damit besser möglich sind als mit Quads.
beim kleinen Finger scheint es auch etwas durchs Mesh zu gehen ?
Hübsches Mädel
....am Scheitelansatz ist aber etwas nicht so wie es sein sollte, glaube ich.
Pffffrrrrt - euch zeig ich nochmal 'ne hochauflösende Version....
Ernsthaft: hab ich gesehen, ließ sich aber aufgrund anderer anstehender Verpflichtungen (Arbeit) nicht mehr ändern.
Ist jetzt korrigiert. Danke für's genau hinschauen!
Alles anzeigen
Das ist ja das Gute hier im Board - die Leute schauen wirklich hin!
vg
space
Ja, sehr ärgerlich ist das.
ausserordentlich gut geworden, Haaransatz und Finger sind schon erwähnt worden.. Ich würde die Dame gerne mal mit einer im gleich Farbton gehaltenen Strumpfhose sehen, dieweil mich das irgendwie stört, dass die braun ist...lol...aber das ist Geschmäcklerei..lol
Ich weiß nicht, alles in einheitlichem Ton erscheint mir eintönig und langweilig.
Ich kenn mich da jetzt nicht so aus, aber tragen die Damen immer farblich übereinstimmende Wäsche?
Die verchromten Ladies sind eine nette Idee.
Irgendwie Goldfingerisch.... 
Verwendete(s) Programm(e): Poser, Octane, PS
Bin heut morgen mal wieder 3 Stunden zu früh(!) aufgewacht 
Zeit genug für ein schnelles Pinup.
Für mich sieht der Blur OK aus.
Es ist ja nicht so, dass die Verwischung immer über den gesamten Bewegungsbereich geht. Betroffen ist immer nur ein kleiner Bereich vor und ggfs nach der momentanen Position, so dass die Bewegung nicht abgehackt erscheint. Wenn du hier also an der Endposition der Arme bist, ist die Einbeziehung des vorletzten Frames (und vielleicht dem davor) meiner Meinung nach völlig ausreichend.
LOL - keine Sorge!
Manchmal denk ich nur, dass ich mich im CGI Bereich einigermaßen gut auskenne, ich komm sogar mit Nodes klar, zumindest im Shaderbereich von Octane, und dann kommt sowas.
Das holt einen ganz schön auf den Boden der Tatsachen zurück
War gerade am überlegen, ob ich mir das Modo 801 Update gönnen soll....
Dabei bin ich über das hier gestolpert.
Man achte auf den auf den benötigten Erfahrungslevel: "Beginner" 
Ich geh dann jetzt ins Wasser.
Das seltsame ist, dass diese Verschiebung beim Spiegeln auch auftritt, wenn ich irgendein Poser-Objekt (einen Charakter, ein Kleidungsstück - egal) in Poser "nulle" - also alle Posen rausnehme und es dann nach 3DSMax exportiere.
Wenn ich dagegen die eigentliche Geometriedatei (OBJ, auf die die CR2 in Poser referenziert) in 3DSMax importiere und testweise z.B. den linken Oberarm lösche und dann den rechten an seine Position spiegele, ist alles so, wie's sein sollte und der Körperteil sitzt korrekt.
Scheint mir ein Fehler in Posers Export zu sein.
Wie überträgst du? Per Export/Import einer OBJ Datei oder mittels COLLADA oder 3DS Plugin?
Das wusste ich noch nicht. Mir ist zwar klar, dass, je größer (px) die Textur ist, desto "schwerer" (MB) ist sie auch. Aber mir war nicht klar, dass die physikalische Speichergröße weniger entscheidend ist als die Anzahl der Pixel. Oder hab ich was falsch verstanden?
Beispiel:
1 Textur, 1000x1000 = 1.000.000 Pixel = bei RGB 8Bit = 3 x 8 x 1.000.000 = 24.000.000 Byte Speicherbedarf.
1 Textur, 500x500 = 250.000 Pixel = bei RGB 8Bit = 3 x 8 x 250.000 = 6.000.000 Byte Speicherbedarf.
Ob eine Textur mit 1000x1000 Auflösung nun 24Mb oder durch Kompression z.B. nur 16MB groß ist, spielt nur für den Speicherplatz auf der Festplatte oder die Übertragung durchs Netz eine Rolle, jedoch nicht für die Anzeige, die ja alle Pixel unkomprimiert darstellen muss.
Für die Anzeige gilt: 1/2 Auflösung = 1/4 Speicherbedarf, doppelte Auflösung = 4facher Speicherbedarf, unabhängig von der Bildkompression.
Heißt also, dass das GK Speichervolumen genauso, wenn nicht sogar wichtiger ist, als die Anzahl der Cudas. Meine GTX 660 hat "nur" 2 GB und ich habe testweise eine vollbekleidetete V6 (die ist nicht das Problem) und einen voll ausgestatteten Wohnraum versucht zu laden, woraufhin Octane (bzw. mein Kartenspeicher) schlapp machte.
Ja, je mehr Speicher umso besser.
Die Anzahl der ladbaren Texturen ist allerdings immer gleich. Bei weniger Speicher muss man dann eben kleinere Texturen verwenden um die volle Anzahl Images laden zu können.
Also, DAZ-Studio rechnet in cm und °, was Größe und Rotation angeht...
Die Standalone Version von Octane hat eigene Skalierungseinstellungen für den Import von DS und Poser Szenen, die man ja erst als OBJ exportieren muß.
Die Plugins machen's ohne Umweg intern.
Jo- klingt eigentlich auch logisch. Da sieht man wieder mal, wie sehr man doch schon beeinflusst ist vom Umgang mit den diversen Programmen, denen diese Echtwelt-Metrik sch...egal ist...
Ja, im Umgang mit unbiased Rederern muß man all das Getrickse ganz schnell vergessen und mehr wie ein Fotograf im wirklich echten Leben arbeiten.
Das wird ungemütlich hier, meine Entscheidung, Octane links liegen zu lassen, gerät etwas ins Wanken.
Mir geht es nicht so sehr um schnelle Renderzeiten, sondern vor allem darum:
- physikalisch korrektes Verarbeiten des Lichts, d.h. kein künstlicher Viele-Lampen-Ansatz wie bei 3Delight. Sozusagen "Sonne reicht", wie bei Vue oder LuxRender
- beim Einsatz des Renderers nicht alles aus DAZ individuell anpassen zu müssen. Reality/LuxRender mag scheinbar manche DAZ Maps und Shader nicht so, ich bin zugegeben bei der Anpassung überfordert; wobei ich noch nie total komische Ergebnisse hatte, wie scheinbar manche hier.
1. Octane ist ein physikalischer Renderer, das bedeutet der Ausdruck "unbiased".
2. Shader- und Materialanpassungen sind bei externen Renderern IMMER nötig weil jede Renderengine auf ihrem eigenen Shadersystem aufbaut und für dieses optimiert ist. Plugins können die vorhandenen Shader zu einem gewissen Grade "übersetzten", allerdings sind dem Grenzen gesetzt, und man muß des öfteren nacharbeiten. Anderereseites kann man sich im Laufe der Zeit einen eigene Materialsammlung aufbauen und für Octane gibt es auch eine Online Bibliothek mit vorgefertigten Materialien.
Dafür kann man in DS oder Poser die Materialien links liegen lassen. Hat auch was gutes. 
Das scheint Octane zu bieten? Ich habe nur eine GTX 570 mit angeblich 480 Cudas, wäre das für Octane ok? D.h. es läuft nicht nur mit Müh und Not, sondern komfortabel.
Das sollte für den Anfang reichen. Im Zweifel mal mit dem kostenlosen Demo antesten.
Was bedeutet es denn konkret, wenn mit Graphikkarten der 500er Serie "64 LDR oder/und (?) 4 HDR RGBA Texturen" verarbeitet werden können? Sind das 64, bzw. 4 Objekte oder wie soll man das verstehen? Sagen wir mal, es sind 7 voll mit Kleidung, Waffen etc. ausgerüstete Genesis 2 Figuren im Bild plus Szene, was heißt das dann?
Grafikkarten können nur eine begrenzte Anzahl an Imagedateien (JPG, PNG) laden, getrennt nach Graustufen/Farbe und niedriger- (LDR = low dynamic resolution) bzw. hoher (hdr = high dynamic resolution) Farbauflösung. LDR ist so das übliche was man im Web an Bildern vorfindet, HDR sind spezielle Bilder für die man einen geeigneten Betrachter braucht und die in 3D üblicherweise als Umgebungslichtquelle dienen.
Konkret: Deine Karte kann 64 normale Texturdateien und 4 HDRI Dateien laden, dh, wenn deine Szene mehr Texturen enthält (auch Bump und Specularmaps zählen dazu) dann können nicht alle im Octane-Rederer benutzt werden.
Danke.
Ich denke darüber nach, mir das Plugin für DAZ zuzulegen; Das Exportieren von Animationen von Poser, mit dem ich ja hauptsächlich arbeite, nach DAZ sollte ja eigentlich kein Problem sein, und dann müsste ich's halt im Alembic-Format exportieren und in Octane importieren. Mich reizt diese Möglichkeit - die paar Animationen auf meiner HP sind ja schon uralt, in Poser gerendert und m.E. absolut nicht mehr zeitgemäss.
Das ist ein bisschen um 5 Ecken....
Wenn du eh in Poser animierst, dann nimm das Plugin für Poser, in dem kannst deine Animationen direkt ohne Umweg rendern - und das Plugin läuft stabil.
Es macht keinen Sinn bei Octane auf die Zeit zu schauen, wichtig sind die Samples.
Für Stills im HD Format als Erfahrungswerte:
Daylight: 100-500 Samples,
Pathtracing: 2000-4000 Samples,
PMC: 200-400 Samples
(wenn's nicht langt - weiterrendern lassen )
PMC rendert etwas langsamer, braucht dafür aber vergleichsweise wenig Samples und ist gut für Innenräume mit hohem Anteil von indirektem Licht, Pathtracing rechnet schneller, braucht aber mehr Samples um alle Unreinheiten auszubügeln, gut für hohen Direktlicht-Anteil in Außenszenen.
Daylight ist mehr so der "Quick'n'Dirty" Modus, aber z.B. gut für Animationen.
Octane bezieht sich auf "Echtwelt"-Dimensionen. Wenn du also im Modeller deiner Wahl im Meterbereich gemodelt hast musst du auch Meter importieren usw.
Das ist wichtig zum einen für Shadereinstellungen (z.B. Eindringtiefe bei SSS) als auch realitätsnaher Beleuchtung (Wattzahlen, Wirkungsgrade von Leuchtmitteln). Daher die Skalierungsmöglichkeit bei Import.
Im Prinzip lässt sich also mit realen Verhältnissen arbeiten - is ja schließlich ein unbiased Rederer 
Willkommen im Club!
