Du sprichst wahrscheinlich von Mist. Der leichte oder auch dichtere Dunst, der bei bestimmten Wasserbewegungen und/oder Temperaturen auf dem Wasser liegt, Nebelschwaden-artig, und mitgezogen wird. Der ist wirklich fluffig und wird am besten als Volumen erzeugt.
Du kannst beispielsweise also locker einfach spheres auf die import_whitewater particles per CopySOP verteilen und Alembic rausschreiben und die dann entsprechend im Host shaden, oder ne VDB von den particles generieren und die dann Meshen.
Sicher, aber ich rendere FLIP Sims bisher wie gesagt lieber in Mantra als in C4D. Auch da habe ich mehr Möglichkeiten. Octan in H ist auch eine Sache für sich, aber es geht langsam. Es fehlen nur m.E. immer noch einige Einstellungsmöglichkeiten vor allem für Pyro/Fire: Octane liest zwar die Volumes alle brav ein, nutzt aber nur Temperature und Density. Es gibt daneben noch Hand gemachte Verläufe, die man über Volumes legen kann, aber da war bisher immer der Wurm drin. Smoke/Mist/Dust usw. werden aber schon sehr fein gerendert.
Ebenso sollte es doch in C4D möglich sein, die particles oder points aus einer alembic zu lesen, werden die nicht als TP interpretiert wie ich jüngst doch irgendwo gesehen habe?
Ja, das geht, aber Cinema scheint von alleine keine Alembic Sequenz zu lesen, zumal Alembic ja ganze Animationen einpacken könnte. Bei der o.g. Methode werden aber von H Sequenzen gespeichert und nicht die ganze Sim in einer Datei. Auch wenn es geht (Export per File Menü), macht das bei vielen, jedenfalls den meisten Large Scale Sims und anderen, hochzahligen Partikelobjekten keinen Sinn, und damit bin ich wieder bei Sequenzen.
Über verschiedene Hilfen geht das: der XParticles Cache, das RF Plugin, der Riptide Importer, die können alle Sequenzen lesen. M.W. lesen die auch alle nur Geometrie: bgeo, obj. Für die Eigenschaften der VDBs sind Alembic Dateien vermutlich die einzige Möglichkeit. Fehlt also noch die, ABC per Plugin als Sequenz zu importieren.
Zusammen mit beispielsweise churn, curvature, vorticity oder velocity des liquids exportiert als textur/vertexmap (oder wie auch immer das der Engine für c4d reinkommen würde) würde sich da dann einiges anstellen lassen. Normalerweise nutzt man ja nochmal die vorticity zusammen mit dem whitewater für die wavecaps. uff also für meine Belange würde ich diese Volumes garnicht erst bis nach C4D bringen, bin mir auch nicht sicher was davon wirklich nutzbar ist in Cinema. Und in brauchbarem Tempo, sorry @Maxon wenn ich das immer wieder aufs Tapet bringe. Ich fang glaube erst an da genauer reinzuschauen was geht, wenn jemand mit den entsprechenden Assets unterwegs sein muss. Vertexmaps wären in der R18 eine Idee *, ansonsten halt TP. Das ist aber nicht meins ^^
Ha! Hab grad mit den neuen “Vertex Farben” angefangen, in einer Punkewolke rumzupinseln. Verrückt
Mist ist fluffig ja. Du kannst ja auch extra nochmal zusätzlich zum whitewater Mist erzeugen. Den könnte man dann als VDB raushauen.
Was ich aber meinte: Primär ist ja das whitewater standardmässig in H ja auch erstmal fluffig (partikel von denen dann ne VDB generiert wird) und daher eben auch fluffig erscheint (mit steigender Auflösung wird das auch weniger fluffig (voxelsize…), Könnte man also auch als VDB raushauen). Für akkurates und detailliertes whitewater(also foam und bubbles und spray) rendert man ja üblicherweise die Partikel eher als Points (Spray könnte man auch als Volumen rendern wenn man das trennen möchte) mit nem sehr kleinen Radius, und nach belieben isotropic anstatt standard-shading. Eben jene feinen Partikel kriegt man ja (wenn nicht eh schon als TP - was die Engine auch macht, würde ich erwarten?) dann nach Cinema wenn man darauf Geomtrie erstellen lässt, wie beschrieben die copysop’ten Spheres. (Ist aber natürlich damit n hart grosses Alembic und man sollte gucken einfach die Partikel/Points nach C4D zu kriegen).
Kann ich auch voll nachvollziehen, aber da du den export ansprachst in punkto “per frame nach c4d bekommen” dachte ich ich erwähne einfach mal die obigen möglichkeiten.
Natürlich macht es nicht unbedingt Sinn, schon garnicht bei großen Sims, aber so kriegt man es rüber. Eben dann notfalls in einer großen Alembic. So ist ja Alembic auch gedacht, ansonsten sollte man halt cache formate nehmen die per Frame schreiben und gelesen werden. Allerdings bin ich einfach davon ausgegangen dass C4D Alembic import auch per-Frame lesen kann. Sowas schaut man ja nicht nach, da geht man von aus das das geht, auch wenn ein alembic cache eigentlich ein file sein sollte.
Allerdings ist es ja durchaus schon so, dass bei ner Large Scale Sim durchaus auch schon das gemeshte Objekt zig GB an Alembic file erzeugen kann (und so exportiert man ja üblicherweise liquids…). Wenn man dann den Rest auch noch als Alembic raushaut, ist es auch egal ob es 50 oder 700 GB sind. Der Sinn eines Alembic caches ist es ja, alles in einer Datei zu haben (einer der Hauptgründe für das Format.). Klar, ist das ärgerlich wenn der Rechner bei Frame 1024 beim alembic export abschmiert und das file kaputt ist, das passiert aber eigentlich in der Regel nicht, solange man nicht nebenbei dran rumfummelt. Mehrere 10 bis 100erte GB Alembic caches sind jetzt nicht unbedingt Produktionsunüblich. Einzelfiles haben eigentlich keinen Vorteil dabei.
Das sollte sich eigentlich ja leicht scripten lassen… nicht das ich jemals in c4d nachgeschaut hätte, ob alembic pfade geändert werden dürfen @ runtime. Aber so prinzipiell.
Nö, ich würd mir das auch nicht einfallen lassen das zu tun Aber mir gings ja eher darum auf deine Antwort auf shapes Frage hinzuzusetzen, was man tun könnte, um das ganze nach c4d zu kriegen. Nach Maya krieg ich den Spass ja auch zurück, wenn ich will
Aber, wenn jetzt jemand alle das in C4D rendern will, wird ers halt rüberbringen müssen. Was aber Churn, Vorticity etc angeht…das sind ja eh halt nur Vertexmaps für das gemeshte Liquid, das holste dir ja eh zumeist rein (wenn du halt eben nicht gänzlich in H renderst, was die meisten die die Brücke benutzen halt nicht wollen), irgendwie wird man die sicher rüberbringen können (alembic speichert CPV sets… ob c4d die liest weiss ich nicht). Ob die Engine die an C4D weitergibt, weiss ich auch nicht. Wie man mit dem whitewater umgeht, haben wir ja oben eigentlich alle optionen durch Mal rein aus interesse als nicht-c4d user: Gibt denn die Engine die whitewater partikel an C4d weiter, oder garnicht? Ich dachte da kommen dann TP oder Punktwolken an? Da ich mit Houdini nicht in c4d arbeite, korrigiere mich dann hier mal wenn ich falsch liege, Kurt
Edit: Aber irgendwie…
…jetzt haben wir viele Worte verloren, und eigentlich wollte shape mal ursprünglich wissen ob das über die Engine läuft.
Also @ shape
Nochmal in simplen Worten damit du auch ne Antwort auf die Frage kriegst (und ignorier einfach die Diskussion oben die dich vielleicht nur mehr verwirrt ^^):
Du kannst deine Simulation in ein Houdini Digital Asset verpacken und in Cinema laden. Damit ist es sogar gänzlich unnötig den Cache auf der Platte zu haben, da du aus Cinema heraus simulierst durch die Houdini Engine simulierst. Du kannst deine Simulation aber auch vorher in Houdini Cachen, und das Asset in c4d laden. Was ankommt, ist der “Ausgang” des Assets dass du abspeicherst. In deinem Fall wäre dieser “Ausgang” einfach die gemeshte FLIP-Simulation.
Nochmal ausführlicher:
Grundsätzlich ist es halt so: Eigentlich ist es mit den Assests halt so gedacht dass du aus dem Host Dinge an Houdini übergeben kannst, welche dann meinetwegen als Collider in einer Fluidsim dienen, und dann bekommst du ein Mesh deiner Fluidsim zurück. Die Engine berechnet dann natürlich die Sim neu, wenn du die entsprechenden Objekte im Host meinetwegen verschiebst. Man kann natürlich die Engine auch einfach nur als simplen “Importer” benutzen, und sie einfach ein Asset laden lassen, welches eine vollständige fertige, cached Houdini Simulation ist, die du vollständig nur in Houdini erstellt hast, und die in Cinema keine Parameter hat. Somit ist absolut kein File auf Festplatten nötig, ausser die Houdini eigenen Caches. Du könntest damit auch um es richtig simpel zu machen einfach ein Houdini gesimtes Mesh als bgeo speichern, und dir n ganz simples HDA mit nur nem bgeo loader bauen, der die Houdini sim liest. In Cinema importieren, Voila: Houdini Sim. Willst du sie ändern machst du das in houdini, überschreibst die bgeo und gut ist.
So gesehen ist also der Umweg über Alembic und ähnliche Formate nie wirklich nötig.
Aber ehrlich gesagt ist es einfacher für das fertige Fluid Mesh einfach ne Alembic zu exportieren aus Houdini und in C4D zu laden, wenn du keine Interaktivität brauchst. Für das eigentliche Mesh, würde ich eigentlich nicht zu Einzelframe-Formaten greifen sondern immer zu Alembic.
Deine Posts sind immer eine Bereicherung, die ich gerne lese.
Momentan haben wir folgende Situation bei uns im Team: aufwändige Sachen werden bei Rebus gerendert mit Vray. Man müßte also erstmal in Erfahrung bringen, ob Rebus die Houdini Engine unterstützt. Dann wäre da natürlich auch die Frage des Uploads, bei einer Dateigröße von bis zu 5-7 GB kann man noch mit der Uploadzeit leben, aber alles, was darüber hinausgeht wird mühselig. Wenn man dann man eine detaillierte Largescaleanimation von sagen wir 1000 Frames hat, die man in verschiedenen Sequenzen von maximal 200 Frames aus verschiedenen Kameraperspektiven rendern möchte, wäre es blöd, wenn man jedesmal eine riesige Alembicdatei mit dem Gesamtinhalt für diese kurzen Sequenzen auf die Farm hochschieben müßte. Hat die R18 da bei Alembic zugelegt? In der R17 kann man IMHO keine Alembicsequenzen aus Einzeldateien laden, wie auch schon im Thread gesagt wurde.
Import über Xparticles wäre machbar, da ist aber die Frage, ob es vernünftig zusammenarbeitet. Wir hatten mal einen Test mit der Realflowdemo gemacht und versucht, Xparicles im Realflowformat zu cachen und dort zu importieren, um sie dann zu meshen, da gab es aber Probleme, das müßte man noch genauer prüfen.
Interessant wäre auch zu wissen, ob Vertexmaps von Flüssigkeiten aus Houdini in Cinema ankommen und dann auch entsprechend gerendert werden können, wichtig, wenn man verschiedenfarbige Flüssigkeiten mischen möchte. Bei Realflow geht das ja nur mit dem uralten Partikelsystem und nicht mit Hybrido und Dyverso.
Kann man diese Sachen alle mit der Houdini Apprentice ausprobieren oder sind solche Exportmöglichkeiten da auch beschnitten?
Wenn ich richtig gelesen habe, tolerierst du meine Ausflüge (und die anderer) ins Reich der linguistischen Krümelkackerei, wärst aber glücklicher, wenn es sie nicht gäbe.
Tatsächlich schickt man in so einem Fall eine HDD dort hin.
Wenn man dann man eine detaillierte Largescaleanimation von sagen wir 1000 Frames hat, die man in verschiedenen Sequenzen von maximal 200 Frames aus verschiedenen Kameraperspektiven rendern möchte
Ein und dieselbe Sequenz mit verschiednen Kameras? Bleibt faktisch auch ein und dieselbe Alembicdatei.
Ohne das ausprobiert zu haben, bin ich mir ziemlich sicher, dass die Jungs von Rebus da eine Lösung für anbieten, wenn verschiedene Szenen auf die gleiche Alembic zugreifen wollen. Am besten mal unverbindlich nachfragen.
In der R17 kann man IMHO keine Alembicsequenzen aus Einzeldateien laden, wie auch schon im Thread gesagt wurde.
Die gesamtgröße der Dateien bleibt etwa gleich, von daher ist es leider kein Gewinn, per Frame oder eine große Einzeldatei hochladen zu müssen.
Alembic hat im Sinne vom Inhalt, also was C4D damit anfangen kann, in der R18 zugelegt.
Import über Xparticles wäre machbar, da ist aber die Frage, ob es vernünftig zusammenarbeitet.
Dazu kann ich leider nichts sagen. Ich lese nur im XP Cacheobjekt, dass es u.a. die beiden Houdiniformate geo und bgeo laden und speichern kann. Wie gut, wie umfangreich, wie sauber und wie man es dann weiter verarbeiten kann, weiß ich nicht. Aber ich würde nicht den Mesher von XP nehmen, sondern ein Asset, welches auch schon existiert. Leider auch mit Absturztendenz und nicht mit allen Möglichkeiten, die das Meshen in H direkt bieten würde.
Interessant wäre auch zu wissen, ob Vertexmaps von Flüssigkeiten aus Houdini in Cinema ankommen und dann auch entsprechend gerendert werden können, wichtig, wenn man verschiedenfarbige Flüssigkeiten mischen möchte.
Und dann, färbst Du die Partikel ein und renderst die als kleine Kügelchen? Hast Du mir da mal ein Beispiel zu, wie das aussieht?
Kann man diese Sachen alle mit der Houdini Apprentice ausprobieren oder sind solche Exportmöglichkeiten da auch beschnitten?
Hm, nein. Die Apprentice kann schon einiges an Simulationsdaten speichern und laden, *.sim und *.bgeo auf jeden Fall, und volumeneigenschaften wie temperature, density oder farbwerte von Mischungen müssten auch dabei sein. Mir fällt im Moment nur die Rendergröße, Watermark im Rendering und ein anderes Datenformat ein, weiß aber grad nicht wie weit sich das auch auf die o.g. Exporte auswirkt. Es wäre naheliegend, wenn die auch entweder verändert oder beschnitten wären.
Soo … ich habe gerade ein wenig durchprobiert mit der Apprentice, musste dafür erstmal schauen ob die Lizenz nicht doch aktiviert wird. Wird sie nicht.
Aber irgendeinen Haken muss die Sache ja haben, und siehe, da war er Und zwar kann man eine Szenedatei nicht über File/Export… speichern. Im Klartext bedeutet das: FBX und auch Alembic Dateien, die eine komplette Animation in einem einzelnen File enthalten, können damit nicht geschrieben werden.
Schreiben und Lesen über die Filesnodes innerhalb einer Datei funktioniert aber und scheint auch nicht verschlüsselt oder in einem anderen Code geschrieben. Im Klartext bedeutet das: *.sim, *.abc, *.geo und *.bgeo Dateien (und gefühlte 200 weitere Formate. Es sind aber “nur 58”, und davon einige 2D und CAD ;)) können mit einem Filenode rausgeschrieben werden. Das ist im Normalfall wie oben gehabt 1 Datei/Frame. Ob man die irgendwie überreden kann, alle in eine Datei zu schreiben, weiß ich nicht, würde aber davon ausgehen, dass das mit der Apprentice dann auch irgendwo beschnitten ist. Sonst gäbe es ja kaum nennenswerte Limitierung für eine kostenlose, nichtkommerzielle Software.
Ne, die kriegst du nicht in ein File. In der Apprentice ist der Export tatsächlich nicht beschnitten, ausser abc und fbx. Aber eine nennenswerte Limitierung ist beispielsweise schonmal das .hdanc nicht in der Engine gelesen werden kann
Was shape meint, sind entsprechende Vertexmaps für den gemeshten Liquid. Also beispielsweise falls du irgendwelche Daten deiner Sim oder die Farbe der Flüssigkeit(en) in Cd schreibst. Oder halt Velocity, Vorticity, etc Vertexmaps raushauen möchtest. Wie gesagt, ob CPV-Daten in C4D über die engine ankommen, weiss ich nicht. Alle float3 color oder float4 color per Vertex-Attribute werden aus Houdini in eine Alembic rausgeschrieben, also auch beispielsweise Cd. Die können dann auch ausgelesen werden, falls die entsprechende App das hinkriegt im Alembic Import (Maya, ja – C4D, weiss nich)
Hallo Kurt, LennO,
ich bin jetzt gerade mitten drin eine Wolkenstruktur zu basteln - Frage: gibt es eine Möglichkeit über die “copy” und "“scatter”-Nodes auch objekte statistisch zu verformen, ähnlich dem C4D-Zufallseffektor?
Vergleichbar mit dem Effektor weiß ich nicht, aber Du kannst ja immer und überall mit VEX und Co. reingehen
Hier ist ein Beispiel, wie das grundsätzlich mit dem Copy-Node und dem “Stampen” geht, Du musst es nur für Dich übertragen:
Du wirst ja irgendwo links vom Copy Node Deine Wolke liegen haben. Dazwischen würde ich einen Transform Node legen und dort dann unter Rotate und Scale den stamp-Befehl einfügen. In einem Test funktionierte
stamp(“copy1”,“rotate”,1)
weil der Copy Node im gleichen Node liegt wie der Transform Node. Achte auf die korrekte Schreibweise. Die letzte 1 ist wie im YT Film der Faktor. Da der rnd schon auf 360 (Grad) steht, braucht es hier keinen besonderen mehr. Und überlege Dir, wie weit um welche der drei Achsen überhaupt gedreht oder skaliert werden muss
Unter Stamp im Copy Node wäre noch die 2. Variable rotate hilfreich: Variable 2: rotate, Value 2: rand($PT)*360
Edit2: das mit der gleichen Wolke war insofern Blödsinn, als dass man den fluffy noise da erst nachher über alle verteilten Wolken laufen lassen kann. Was u.U. weniger Rechenleistung kostet, wenn man eine geringere Auflösung akzeptiert.
Das hielt ich für nicht erwähnenswert, da man die Engine ohne Lizensierung, also Kauf oder Miete einer Version von H oder der Engine, in Cinema nicht nutzen kann. Sobald man aber eine Lizenz hat, ist man auf die Apprentice nicht angewiesen. Konvertierung ist ja kein Problem.
Hatten wir auch schonmal überlegt, ist aber aus unserer Sicht nicht so praktikabel, weil es nicht mal schnell gemacht ist, gerade bei kurzfristigen Kundenwünschen.
Bei einer großen Alembicdatei hast Du Recht, aber beim Realflowimport kannst Du beispielsweise einen Framebereich von 0-100 angeben und es werden dann auch nur 101 Frames hochgeladen und nicht 1000, wenn sowas auch mit Alembic ginge, wäre das perfekt.
hab nur mal generell getestet, ob sowas geht, ich meine ähnlich wie in diesem Beispiel hier:
ok, heißt also, von Houdinis Seite könnte man mit der Apprentice den Export in Einzelframes testen, jetzt bleibt nur die Frage, ob Cinema in R18 die Einzelframes irgendwie samt relevanter Datenkanäle importiert bekommt. Aber solange Vray für die R18 noch nicht optimal funktioniert, ist es eh müßig.
Da fällt mir gerade noch was anderes ein. Kann man in Houdini sagen wir eine 1000 Frame lange Flüssigkeitsanimation simulieren, das Ergebnis dann als bgeo auf die Platte speichern und am Ende gezielt sagen, daß nur von Frame 200-400 daraus eine Alembicdatei erstellt werden soll?
Ja, wobei der Umweg über die Platte hier nicht notwendig ist. Wie beim Rendern von Einzelframes ist es in Falle eines Absturzes natürlich immer schöner, wenn man nicht alles von vorne beginnen müsste. Notwendig ist es aber nicht.
Der Export für die Gesamtdatei erwartet jedenfalls die Angabe Start- und Endframe so wie einem Inkrement, das idR. bei 1 liegt. Takes und Objektangaben sind ebenfalls möglich, aber das sollte erstmal reichen
Edit: wie o.g. nicht in der Apprentice, falls das Teil der Frage war.
Ja, wie oben beschrieben in meiner Antwort auf Kurt beschrieben, geht das auch in Houdini. Die “Vertex Color” für die Fluids würdest du dabei in ein Attribut schreiben welches sich in Houdini “Cd” nennt, Color Diffuse. Man könnte auch ein beliebiges anderes 3 float Attribute mit eigenem Namen dafür verwenden. Was ich dir nicht sagen kann (keine c4d, keine engine für c4d ^^) ist, ob die Attribute über die Engine in c4d als Vertex Maps ankommen. Das kann aber Kurt vielleicht mal testen?
Früher hat Cinema ja sowieso nicht wirklich Color per Vertex supported, und ich hab länger nicht nachgeschaut, was sich so getan hat in dem Bereich
Ganz aktuell, seit der R18 kann C4D Vertex Color Maps importieren, malen, exportieren. Ganz frisch, sosagen. Eine wenige Formate wie FBX und Alembic, wenn mich mein Sieb nicht täuscht.
Die “Vertex Color” für die Fluids würdest du dabei in ein Attribut schreiben welches sich in Houdini “Cd” nennt, Color Diffuse.
Man könnte auch ein beliebiges anderes 3 float Attribute mit eigenem Namen dafür verwenden. Was ich dir nicht sagen kann (keine c4d, keine engine für c4d ^^) ist, ob die Attribute über die Engine in c4d als Vertex Maps ankommen.
Der erste Teil ist glasklar, wie ich das testen soll, null Plan ^^ Ich habe keine Ahnung ob H sowas wie Vertexmax kennt und benutzt und wie ich das in einem Asset umschreibe.
Wenn es Vertex Maps gibt, sollte es schon gehen, die Cd’s die ja eh schon per Punkt/Partikel vorliegen, darauf “umzumappen”. Wenn das überhaupt nötig ist. Bin aber die Woche wieder etwas knapp an Zeit
Ja in der Featureliste seh ich das auch, ob sie aus einer Alembic in C4D importiert werden, ist ne andere Frage ;), Ich test das mal nachher in der C4d R18 Demo EDIT: So habs direkt getestet anstatt später, Cd wird nun neuerdings aus ner Alembic gelesen in Cinema, also alles gut also für euch In R17 gehts natürlich nicht.
Na ganz einfach. Ne Alembic aus Houdini speichern. Alle attribute die 3fc oder 4fc sind werden in die Alembic geschrieben und von Alembic importern als Color per Vertex erkannt, sofern der entsprechende Importer die Daten aus der Alembic lesen kann und umsetzen kann. Du musst allerdings das Cd Attribut (oder beliebige andere float mit size 3 oder 4) per Attribute Promote zu nem Vertex Attribut machen (standardmässig sind die Point-Attributes). Hängt also nur am Importer. Houdini schreibt bei Default alle Vertex Attribute in einer Alembic. Ob die dann ausgelesen werden ist Sache der anderen Software. Maya liest die, logischerweise.
Eine “Color Per Vertex Map” ist nichts andere als eine 3 oder 4 Array diemit einem entsprechenden Point oder Vertex assoziiert ist. Das Cd Attribut in Houdini ist eine Color per Vertex Map
Ich mach mal später n Video auch für die anderen Ich denke, mit der Erklärung oben, weisst du bereits wie es geht.
Alle attribute die 3fc oder 4fc sind werden in die Alembic geschrieben und von Alembic importern als Color per Vertex erkannt
Das muss man natürlich erstmal wissen ^^
Ja, so theoretisch. Ich bastel mir das dann beizeiten zurecht Thx again!
So, morgen gibts 40 Minuten Tutorial Video, oder auch schon früher wenn youtube ma hinne macht. Hat ich heute abend Bock drauf.
Kleine Einführung in Houdini Flip Fluids (also Beginner-Level), und danach dann zu Custom Attributes und Alembic Export von Daten.
Tonquali wird grausam sein und ich hab den abend über immer nur Stückchen aufgenommen, aber wann mach ich auch schonmal Videotuts.
Das sollte das auf jedenfall groben Fragen beantworten die bislang da waren @Shape (Color Mix etc…), vielleicht ist für dich auch noch viel neues dabei Udo…und Kurt kann ja mal durchscrubben, aber vermutlich ist da nichts absolut neues bei für dich
Teaserbild so lange youtube läd…
Achja, auf englisch. Hät ich das Deutsch gemacht wärs nach 3 Sekunden in komisches denglisch ausgeartet. 3D geht einfach nicht auf deutsch ^^
OK, die sind wie das XP Beispiel auch opak
Ich musste bei der Frage an die Mischung von farbigen Flüssigkeiten an transparente Liquids denken, und dann muss man volumetrische Lösungen finden. Finde auf die schnelle nix anderes als das Phoenix-Beispiel hier ^^
Wobei die gefärbten Partikel bleiben mögen, aber wie von Dir angedeutet eine 3. Farbe “erreichen” müssten. Sonst bleiben gelbe Partikel gelb und blaue blau.
Dann komme ich jedenfalls zu meinen o.g. Punktewolken, die irgendwie auch in Cinema volumetrisch gerendert und gemixt werden müssten. deshalb die Frage nach den Kügelchen ^^