1. Diese Seite verwendet Cookies. Wenn Sie sich weiterhin auf dieser Seite aufhalten, akzeptieren Sie unseren Einsatz von Cookies. Weitere Informationen

Wir basteln uns den RenderService 3.0

Dieses Thema im Forum "RenderService" wurde erstellt von leMaik, 24. September 2016.

?

Am wichtigsten am RenderService wäre mir...

  1. eigene Chunky-Szenen von meinem PC hochzuladen

    5 Stimme(n)
    55,6%
  2. Chunky-Szenen vom Server aus zu erstellen

    6 Stimme(n)
    66,7%
  3. Videos erstellen zu können

    4 Stimme(n)
    44,4%
  4. VR-Bilder rendern zu können

    3 Stimme(n)
    33,3%
Eine Auswahl mehrerer Antworten ist erlaubt.
  1. leMaik

    leMaik Administrator Mitarbeiter

    Aktueller Status:
    [​IMG]
    ~~~
    Die Geschichte vom RenderService 3.0

    Die Entwicklung vom RenderService 3.0 beginnt. Und diesmal möchte ich natürlich alles "richtig" machen: Der RenderService soll gut skalieren, keine Probleme mit langen Jobs haben und auch nicht abstürzen, nur weil mal ein Renderer ausfällt.

    Dazu werde ich die einzelnen Teile des RenderService mehr trennen. Zur Verteilung der Arbeit auf die Renderer (euch!) kommt RabbitMQ zum Einsatz. Das ist ein Broker, der für uns eine Warteschlange anbietet. Wir können Aufgaben hinzufügen, sie abarbeiten und, falls sie erfolgreich bearbeitet wurden, aus der Warteschlange entfernen. Es ist relativ aufwendig, das zuverlässig hinzubekommen (wie man am alten RenderService sieht) und deshalb ist es sinnvoll, das Rad hier nicht neu zu erfinden.

    Ich schweife ab. Jedenfalls habe ich mir gedacht, dass ich hier ein wenig darüber schreibe, wie der RenderService so programmiert wird und warum. Sind ja immerhin ein paar (angehende) Informatiker hier und für die anderen ist es ja vielleicht auch ganz interessant, wie RenderService technisch geht. Fragen, Anregungen, Code, Ideen und so weiter sind natürlich immer willkommen! Viel Spaß! :)
     
    Zuletzt bearbeitet: 17. Oktober 2016
  2. leMaik

    leMaik Administrator Mitarbeiter

    Teil 1: Der Master-Server

    Der Master-Server ist im neuen RenderService dazu da, eine (offene!) REST-Schnittstelle anzubieten. Über diese kann der Status des Services abgefragt werden, es können Jobs abgerufen werden und natürlich können auch neue Jobs über diese Schnittstelle erstellt werden. Wer programmieren kann (oder es lernen möchte), kann gerne coole Programme entwickeln, die sinnvolle Dinge mit der REST-API machen (Graphenzeichnen, Statistiken erstellen, neue Bilder anzeigen, ...).
    Außerdem kümmert sich der Master-Server darum, dass neue Jobs in die Warteschlange (Queue) geschickt werden und die Daten gespeichert werden. Das sind nicht nur die Daten, die beim Erstellen eines Jobs anfallen, sondern auch die fertig gerenderten Bilder oder Bildteile.

    Da der Master-Server im Prinzip nur auf die Datenbank (MongoDB) und die Queue (RabbitMQ) zugreifen muss und ansonsten eine REST-Schnittstelle anbieten soll, habe ich beschlossen, diese in NodeJS zu implementieren. Das geht wesentlich schneller als in Java und ich habe mit den Technologien in der Kombination schon etwas Erfahrung.

    [20:00] Mittlerweile kann der Master-Server Jobs annehmen (hat etwas länger gedauert), indem man ihm einfach Dateien schickt. Später wird das wohl noch komplizierter, mit Authentifizierung oder zumindest Angabe des Spielers, der den Job erstellt.
    Der Job wird direkt vom Master-Server in handliche Tasks unterteilt, die dann in die Queue gepackt werden. Sieht dann in RabbitMQ so aus (wenn man zwei Jobs mit je 1000 SPP erstellt):
    [​IMG]

    Damit es von neuen Jobs möglichst schnell eine erste Vorschau gibt, bekommen die ersten 100 SPP (also die erste Task) eine höhere Priorität in der Warteschlange. Später wird es eventuell eine zweite Warteschlange geben, in der Bilder mit (absolut) schlechter Qualität gerendert werden, damit man wenigstens eine einfache Vorschau hat.
    Jetzt brauche ich (erstmal) eigentlich nur noch ein paar API-Requests, um die Dateien eines Jobs abzufragen und um fertig gerenderte Bilder (bzw. Dumps) an den Master-Server zu schicken. Das wäre dann schon ein (sehr einfacher) Master-Server.

    Für das Zusammenführen der Dumps wird es eine weitere Queue geben, und einen (zunächst genau einen) weiteren Prozess geben, der dann die Dumps aus dieser Queue nimmt und diese mit dem finalen Bild zusammenfügt.

    [23:48] Eigentlich wollte ich anfangen, den Renderer zu programmieren. Leider muss ich dazu Jobs abrufen können, wozu die Jobs IDs benötigen, wozu ich die Datenbankanbindung benötige. Das bedeutet, dass Jobs jetzt abgerufen werden können, inklusive der Daten.

    Als nächstes kommt das Programm, das dann Chunky startet und Tasks abarbeitet. Das wird dann, falls ihr möchtet, auch auf euren PCs und Servern laufen.


    Teil 2: Die Render-Node (aka. der Worker)

    Weiter geht's mit dem RenderService 3.0! Aber erst brauche ich einen Kaffee. So... Weiter geht's mit der Render-Node, oder auch dem Worker. Das ist ein kleines Programm, das sich Tasks aus der Queue holt, diese abarbeitet und die Ergebnisse an den Master-Server schickt. Dieses Programm werde ich in Java schreiben, weil ich dann einige Bestandteile des alten RenderServices wiederverwenden kann.

    An dieser Stelle vielleicht noch einmal die Begriffe (verwirren mich selbst auch jedes Mal). Ein "Job" ist eine Szene, die man beim RenderService erstellt. Diese kann auch aus mehreren Bildern bestehen, beispielsweise bei Filmen oder stereoskopischen 3D-Bildern. Eine "Task" ist dann ein Teil von einem Bild von einem Job, die dann von einem Worker bearbeitet wird. Darum, aus den ganzen fertigen Tasks einen fertigen Job zu machen (ggf. müssen die Bilder z.b. zu einem Film zusammengefügt werden), kümmert sich der Master-Server.

    Eine kleine Optimierung (die aber gerade bei Nutzern mit Bambusleitung ganz praktisch sein dürfte): Falls ein Rechner mehrere Tasks des selben Bildes gleichzeitig berechnet, kann das erkannt werden und es muss nur noch ein Bild (das aus den beiden anderen Bildern zusammengesetzt wurde) hochgeladen werden. Das spart bei zwei Bildern bereits ca. 50% des Uploads.

    [Der nächste Tag, 11:00] Ich glaube mittlerweile, ich wäre schneller gewesen, wenn ich den Renderer neu geschrieben hätte. Aber das habe ich nicht, sondern stattdessen das alte Programm umgebaut. Hat ewig gedauert, aber immerhin: Er startet jetzt, bekommt Jobs und macht damit... noch nichts.
    Als nächstes kommt dann jetzt das Herunterladen der Daten einer Szene und das Rendern. An sich ganz einfach, aber ich wollte die Dateien ja effizient cachen (und möglichst nur einmalig herunterladen). Aber ich habe da schon eine Idee...

    [14:40] Herunterladen und Rendern läuft, sogar mit Cache für die Dateien. Jetzt kommt das Hochladen, aber erstmal ganz einfach, ohne die Optimierung oben.

    Die Dumps, also die einzelnen Bild-Teile wird ein weiteres Programm zusammenführen, das ansonsten nichts anderes macht. Dazu kommen die fertig gerenderten Dumps dann in eine weitere Queue. Zum Glück sind die Dumps relativ klein (< 20 MB), sodass ich sie direkt in die Queue schmeißen kann.

    [16:35] Hurra hurra, der Dump-Processor ist da. Somit könn(t)en die Render-Nodes bereits arbeiten, wenn sie alle Dateien für eine Szene bekommen würden. Aber das ist nur noch eine Kleinigkeit, um die ich mich später kümmere.
    Ein viel wichtigeres Problem ist, dass es später Jobs mit mehreren Bildern geben wird und ich noch nicht ganz weiß, wie diese dann funktionieren werden. Eigentlich möchte ich den RenderService so simpel wie möglich halten.

    Ich hab übrigens ein Bild gemalt, wie der RenderService jetzt funktioniert:
    [​IMG]

    [29.09.2016, 23:30]
    Und schon ist fast eine Woche vergangen, seit ich mit dem neuen RenderService angefangen habe. Gestern habe ich noch die fehlenden Funktionen zum Upload der Dumps und des Bildes und zum Download der Szenen-Dateien zum Master-Server hinzugefügt.
    Ein kleines Problem ist, dass die Dateien aktuell einfach nur auf der Festplatte gespeichert werden. Ich werde das wahrscheinlich auf GridFS umbauen, sodass die Dateien zusammen mit den Jobs in der MongoDB stecken. Das macht Backups, Anfragen, Skalierbarkeit und eigentlich wirklich alles außer den Code einfacher.

    [30.09.2016, 22:30] Gestern habe ich endlich angefangen, die ganzen Projekte auf Bitbucket zu stellen, zunächst aber privat. Bald wird der Quellcode dann auch veröffentlicht. Für das erste Release fehlen eigentlich nur drei Dinge: Skymaps, Texturepacks und GridFS für den Master-Server. Ich werde jetzt mal mit den ersten beiden Probleme angehen, dann kann ich das ganze nämlich erstmal richtig lokal testen.

    [02.09.2016, 19:15] Das Default-Texturepack wird jetzt von Mojangs (bzw. Amazons) Servern heruntergeladen. Chunky macht das auch so, denn die Texturen gehören ja Mojang und dürfen im Prinzip nicht einfach so verbreitet werden.

    Andere Texturepacks und auch Skymaps sind etwas problematisch. Zum Rendern müssen diese nämlich an alle Render-Nodes geschickt werden, was die meisten Texturepack-Autoren nicht möchten und auch mit vielen Skymaps nicht gestattet ist. Alternativ müsste sichergestellt werden, dass alle Render-Nodes das zu nutzende Texturepack bzw. die Skymaps heruntergeladen haben, wobei der Betreiber der Node diese manuell hinzufügen müsste. Auch blöd.
    Alternative Texturepacks werde ich daher ganz einfach zunächst nicht unterstützen (aber eventuell später einprogrammieren, sodass andere nicht-öffentliche Instanzen des RenderServices das Feature nutzen können). Bei den Skymaps komme ich nicht so einfach davon. Ich werde auch hier die Funktion für beliebige Skymaps implementieren, aber im öffentlichen RenderService deaktivieren. Man wird aus einigen freien Skymaps wählen können. Schade ist, dass es kaum freie HDR-Skymaps gibt. Falls da jemand etwas findet, gerne melden!

    Kommen wir zu den guten Nachrichten: Alle Dateien werden jetzt in GridFS (also in der Datenbank) gespeichert, sodass Backups deutlich einfacher sind. Die Dateien können auch mehrfach benutzt werden, sodass z.b. für Filme nicht für jedes Einzelbild alle Dateien separat in der Datenbank stehen müssen.

    Die Fortsetzung gibt es hier!
     
    Zuletzt bearbeitet: 7. Oktober 2016
  3. computergott

    computergott Forenmoderator (Moderationsteam)

    Hört sich vielversprechend an :)
     
  4. Horstexplorer

    Horstexplorer Crafter

    @leMaik, wäre es evtl möglich die Einzelbildteile die dann 'versendet' werden, möglichst klein zu halten, also das es z.bsp immer 1/500 des Gesamtbildes ist?
    Ich kenne die Größe die die letzten hatten nicht genau, aber so könnte man 'nach horstexplorers theorie' auf noch mehr Rechnern gleichzeitig an dem Bild arbeiten, sodass das Bild insgesamt schneller fertig wird, aber man z.bsp auch wie du meintest eine Vorschau Recht fix durch bekommt.
     
  5. leMaik

    leMaik Administrator Mitarbeiter

    Es wird immer das gesamte Bild gerendert, aber nur auf 1/10 des Gesamtfortschritts (10 Tasks bei 1000 SPP). Somit rechnen bis zu 10 Rechner an einem Bild. Soll das Bild in noch höherer Qualität berechnet werden, können noch mehr Rechner dazukommen, weil das Bild in noch mehr Tasks aufgeteilt wird.
    Die Vorschau kommt schneller, weil die jeweils erste Task eines Jobs einfach eine höhere Priorität hat und somit immer ganz vorne in der Queue landet.
     
  6. Michael

    Michael Novice Crafter

    Mit RabbitMQ und NodeJS haste auf jedenfall schon mal zwei sehr trendige Technologien erwischt :)
     
    • Stimme ich zu Stimme ich zu x 1
    • Liste
  7. Horstexplorer

    Horstexplorer Crafter

    Wäre es möglich das man die Leistung die der RS bekommt wieder 'begrenzen' kann, also wie beim letzten? Weil irgendwie hat das nie so richtig funktioniert.
     
  8. computergott

    computergott Forenmoderator (Moderationsteam)

    Bei mir schon
     
  9. Horstexplorer

    Horstexplorer Crafter

    Bei mir lief der immer auf 100% egal was ich eingestellt hatte
     
  10. leMaik

    leMaik Administrator Mitarbeiter

    Ja, das wird möglich sein. Man wird aber nur die Anzahl der gleichzeitig laufenden Prozesse und die Anzahl der Threads pro Prozess begrenzen können.

    Das liegt daran, dass Chunky die Kerne echt gut ausreizt. Jeder verfügbare Thread von jedem Prozess ist 100% ausgelastet. Hast du also 4 Kerne und lässt 2 Prozesse à 2 Threads laufen, läuft dein Rechner auf 100%.
     
  11. Horstexplorer

    Horstexplorer Crafter

    Dann mach ich die in ne Vm ;D Da kann ich anpassen was genutzt werden soll
     
  12. leMaik

    leMaik Administrator Mitarbeiter

    Das wäre vermutlich auch die einfachste Variante, um den Renderer laufen zu lassen. Ich werde ihn auch als Docker-Container laufen lassen.
     
  13. leMaik

    leMaik Administrator Mitarbeiter

  14. Horstexplorer

    Horstexplorer Crafter

    Ich persönlich kenne das nicht. Aber ich frag mal paar die sich damit besser auskennen.
     
  15. computergott

    computergott Forenmoderator (Moderationsteam)

    Also "Quellen" kenne ich keine. Aber wenn es nicht diese "Kugeln" sein müssen, kann ich dir welche machen.
     
  16. leMaik

    leMaik Administrator Mitarbeiter

    Naja, es müssen schon diese "Kugeln" sein. :D
     
  17. Horstexplorer

    Horstexplorer Crafter

    Aber auch das lässt sich machen. Für was gibt es den Blender mit den Tausenden Funktionen und Addons ;?
     
  18. computergott

    computergott Forenmoderator (Moderationsteam)

    Dann musst du wohl auf "meine" verzichten müssen :(

    Kann dir aber "meine" Quelle geben, die ich in meiner aktiven C4D Zeit genutzt hab und auch heute ab und an mal nutze, wenn ich sowas brauche:

    http://www.cgskies.com/


    Manche Samples sind kostenlos, aber ich persönlich habe auch schon mal den ein oder anderen Skin gekauft (10 Dollar sind (zumindest für mich) nicht die Welt)
     
  19. Horstexplorer

    Horstexplorer Crafter

    Naja brauchen tu ich ja nur ne Bilddatei C: Das geschiebse, gestauche und so, je nachdem das machst von alleine bzw muss man etwas nachhelfen. Aber da kuck i morgen mal rein. Und kuck ob ich Maik da paar Kugeln bauen kann. (@leMaik wie hättest die Kugeln gern, also das Dateiformat?)
     
  20. leMaik

    leMaik Administrator Mitarbeiter

    Am liebsten hätte ich HDR-Skymaps.