Das hat nichts mit Realtime zu tun , denn wie du ja schreibst braucht OC 3-4 sekunden zu Berechnung , aber eine Realtimeengine zeigt immer das Ergebnis in Echtzeit
Du möchtest das dir das ein DAZ Contentersteller dir für deine Externe Engine alles fertig aufdröpselt, ....
Will man mehr hat ...
Vielleicht reden wir aneinander vorbei, Vidi
Nach meinem Wissen heißt Realtime beim Rendern fotorealistischer Bilder, dass sofort ein aussagefähiges Bild da ist,
nicht, dass der Render, der je nach Qualitätsanspruch tausende von Samples benötigt "fertig gerendert" ist. So eine Wundermaschine gibt es nicht. Das kann nur ein Filmkamera und das ist bekanntlich 2D.
Mit Realtime beim PB Rendering ist - meiner Meinung nach - gemeint, dass, nicht wie bei iRay, die Engine erst mal Sekunden braucht um überhaupt etwas zu zeigen. Hier ein Octane Beispiel. Siehe Renderzeit Voranzeige für das fertige Bild (bei 3000 Sampels) und aktulle Renderzeit (0 Sekunden!). Logischerweise ist das Bild noch minimal verschneit, weil erst 2 Samples in 0,...irgendwas Sekunden durch sind. Ich konnte auch nicht schneller den Pause Button drücken. Glaub mir einfach, dass das Bild auch bei Sampel 1 bereits da war. Das nennt man Echtzeit...

Bewege ich nun die Kamera, verändert sich nur das Bild (Bewegung im Render View) und, je nach dem wie viele Samples schon durch waren, beginnen diese wieder bei 0, weil die Engine ja, durch die Kamerabewegung, permanent neu berechnen muss. Wie hier am Ende der Kamera Bewegung...

Und ich erwarte nichts von den Vendoren, vidi Ich predige jedem Anfänger hier sich frühzeitig mit Texturen auseinander zu setzen, weil es ready to Render Texturen
von den Herstellern nicht gibt, bzw. das jeweils verwendete Lichtsystem hier eine große Rolle mitspielt. Was aber die Hersteller vielleicht begreifen sollten
- und ich denke Esha hat das schon - ist, dass wenn wir über PB Render sprechen, und das werden wir zukünftig nur noch, das vormals existierende, selbst gestrickte Licht und Farbchaos, endlich ein Ende findet. Denn "physikalisch korrekte Lichtsimulationen" ist physikalisch korrekes Licht. Es gibt kein anderes. Woraus folgt, eine physikalisch korrekt ausgebautes Material (Oberflächeneigenschaft), ob mit UV oder prozedural, erscheint in jeder PB Rendermaschine und unter jedem (physikalisch korrekten) Licht, wie z.B. GI über HDRI, als korrekt wiedergegebene Textur. Und die meisten PB Engines bringen eben haufenweise von diesen physikalisch korrekten Materialien mit. Ich brauche nichts kaufen. Ich brauche Modelle, die mich nicht behindern diese einzusetzen.
Wenn es ready to render Texturen gibt, dann sind es genau diese. Vendoren die diesen Zug verpassen, nämlich die Erkenntnis, zukünftig weniger auf wer weiß wie aufwändige Texturen zu basteln, anstelle möglichst hochwertiger Meshes, samt möglichst vieler Materialzonen, schauen früher oder später in die Röhre.
Nochmal für alle: gerade bei Kleidung, ist auf Grund der Meshformen (zzgl. Beweglichkiet / Rigging) eine UV basierte Textur fast immer erforderlich.
Die Billigteile im Shop, die nur aus einer Meshebene bestehen und nur bekachelt sind, nicht gerechnet. Sobald die Materialbereiche aber unkompliziert,
weil gleichförmig und unbeweglich, und die Textur in sich auch noch gleichmäßig (Glas, Chrom, Lack etc. etc. ...) oder kachelbar sind, brauchen wir nur Materialzonen, sonst nichts. Beispiel: ausgenommen der Zucker im Pott und die Kekse, benötigen wir für die Sachen die hier (Bilder) auf dem Tisch stehen, weder UV Maps, noch eine gestrickte Textur. Alle Materialien (Glas, Chrom, Porzellan, Plastik usw.) sind in OC (und anderen PBRs) vorhanden. Alleine Glas gibt es in OC geschätzt in 50 Varianten.
Und ja
@maXem , ich weiß was eine UV-Map ist
Habe ich bereits (wenn auch sehr krüppelig) unter Esha's und Vidi's Anleitung, selber gebaut. Siehe Blender Forum.
Ohne entsprechende UV-Informationen können (zumindest in den Programmen, die ich nutze oder kenne) eigentlich i.d.R. nur 'echte 3D'-Prozedural-Texturen wirklich gut unabhängig von UVs genutzt werden, weil sich diese eben in erster Linie am '3D-Raum' der Renderengine orientieren und nicht an den Mesh-UVs.
Ok, da hast Du jetzt mit Sicherheit weit mehr Wissen als ich. Hatte ich bisher nicht so gesehen, weil noch nicht wirklich intensiv genutzt 
Danke 