Hintergrund Obejkt & Alpha Textur = Problem!

Hi Leute…

Ich bastle gerade an einer Unterwasser Scene rum, die hinterher animiert wird
(Also eine Kamerafahrt durch die Scene…)

Um dem ganzen ein wenig mehr Tife zu geben, habe ich beschlossen Algen Partikel zu nutzen, die ähnlich wie bei “Aquanox II” im Wasser schweben…

Leider ergab mein erster Test mit den Algenpartikeln einen unschönen “Alpha Bug”,
der AlgenTextur in bestimmten Bildausschnitten wo der Nebel des Umgebungs Objekts zu sehen ist… hier mal ein Bildchen:

Und hier mal eine abgespeckte Scene:
alpha_bug.zip (42.6 KB)

Ich hab einiges rumgespielt…
Von verschiedenen Bildformaten, zu 16Bit Farbtiefe… leider ohne Erfolg!
Auch das arbeiten mit dem Transparenz Kanal führt zu dem selben Effekt :frowning:

Vielleicht kennt ja jemand von euch diese Nervige Eigenart on C4D, oder kann
mir eine alternative zum Darstellen dieses Effektes vorschlagen…

Danke im vorraus :slight_smile:

soweit ich weis ist das ein offizieller bug, der maxon bereits gemeldet wurde.

du kannst es ja noch mal an den support schicken :slight_smile:

Och nö :frowning: :frowning: :frowning:
Wollte die Animation in 2 wochen fertig haben, da is das ja ganz doof…

Hat jemand vielleicht eine Ahnung wie man denn diesen “unter Wasser Nebel Effekt” sonst zaubern kann, so das dies dann für eine Animation zu nutzen ist??? Also volumetrischer Nebel mit Partikeln wäre hier wohl ein Killer für die Renderzeit …

Hmm… oder ne Idee wie man per Shader + Model sowas realisieren kann???

Dennoch thnx für die Info Freeman!

P.S.
Jop schicke ich mal an den Support, mit bissel sehr viel Glück sagen die “Nix los, mach dies & das, dann klappts!”, aber das ist auch eher doch seeeeehr unwahrscheinlich :frowning:

hey zom-b
so wie ich das jetzt verstanden hab hast du polygon-partikel mit alphamaps emittieren lassen und siehst dann den alpha-kanal obwohl der transparent sein soll.
für mich gibts da nur zwei möglichkeiten: entweder du lässt gleich runde flächen emittieren (was dann rechenlastiger wird, aber mit ner 8-eckigen scheibe ginge das eigentlich noch), oder du stellst einfach große ebenen in deine szene die über die film-ränder hinausgehen und auf denen animierst du dann ne alphamap. das bedeutet unterm strich weniger polys, aber zum einen isses dann schwierig diese optische täuschung gut hinzubekommen (ich mein du brauchst dann in relativ geringem abstand die ebenen und die müssen dann in nem bestimmten winkel zur cam stehen usw.) und diese alpha-map-fehler würde weiterhin in deiner animation vorkommen, nur denke ich dass es halt nich so auffällt wenn man die ränder gar nich sieht.
ich kann mir persönlich gar nich vorstellen dass es in cinema einen alpha-map-bug gibt der praktisch jede textur versaut. hab ich bisher noch nie gehabt. liegt das jetzt am umgebungsobjekt oder wie? wenn ja dann würd ich glatt mal das umgebungsobjekt streichen und per licht und setting die tiefe simulieren, zumal das mit den partikeln eigentlich ne schöne lösung is und sich auch im gamedesign lange bewehrt hat…
vll hab ich hier nich richtig durchgeblickt oder du hast längst selbst ne lösung gefunden im anbetracht der deadline. du kannst mich aber trotzdem mal aufklären was hier wirklich phase is, denn ich weiß dass mir das sicher auch passieren wird.
danke onetoe

ps: falls das jetzt wirklich noch zur debatte steht:
ich würd als alpha-map einen algen-partikel nehmen und dann im emitter die partikel zufällig skalieren, sonst hast du halt immer das gleiche partikelmuster vor der linse “großer punkt unter kleinem punkt”. also spiel einfach mit rotation und skalierung…

Hey OneToe…
Vielen Dank das du dich meinem Problem hier angenommen hast!!!1!

Ja, es ist noch ein Thema, und leider muss ich sagen das die Ansätze für mich nicht funktioniert haben :frowning:
Das der Bug auch wirklich ein Bug ist, erkennst du wenn du dir die im ersten Posting verlinkte C4D Datei mal anschaust…
Da ich eine Lösung des Problems nicht gefunden habe (aka es ist ein bug) muss also ein Workaround her…

Dieser funktioniert derzeit anhand von Xpresso indem die Partikel je nach Entfernung zur Kamerra eingefärbt werden und Transparenz aufweisen.
Also um das Umgebungs Objekt zu simulieren…
Dann wird die Kammerafahrt mit Nur diesen Partikeln gerendert, mit einem Alpha BG, und später im Postwork auf den ersten RenderVideo der Unterwasser Scene gelegt!

Dies hat natürlich zum Problem, das Objekte aus der Ursprungssequenz die Algen nicht verdecken können, davon gibt es aber nicht so viele und in der Animation ist der Effekt wichtiger als dieser Fehler… (oder hat da wer ne Idee???)

Ich habe dieses Problem zum Anlass genommen mich mit Expresso mal auseinander zu setzen, und bin auch sehr stolz auf mein Fixes Vorrankommen, werde aber wohl noch ein Thread dazu eröffnen da ich an 1 bis 2 Sachen verzweifle… Natürlich Poste ich die C4D Quelldatei hier, damit auch andere was davon haben!!

Gruss & Dank

Zom-B

Doch den gibt es, seit jeher, und der hat schon viele Menschen zur Weisglut gebracht aber es gibt wie überall genügend Workarounds so dass es zwar irgendwie ärgerlich ist, aber auch nicht wirklich Schlimm. Das selbe gilt für das Himmelsobjekt: Alpha-Textur+Himmel=Image-Alpha Schnodder. Das selbe passiert hier. Der Effekt verschwindet in den RGB Kanälen sobald du hierbei den Boden löschst, allerdings bleibt der Image Alpha Schnodder da die Intensität des Nebels mit in den Alpha geschrieben wird, dort nämlich, wo die Planes sind. Im Grunde genommen ist das sogar richtig, und alles im Composting fixbar wenn man sich noch nen extra alpha layer rausrendert.

k das klingt ja echt ziemlich verfluxt
ich halte mich mal davon ab zu glauben cinema sei ein besonders buggy-artiges programm im vergleich.. aber so was is nach 9 auflagen schon n bissl peinlich..

aber damit ich das jetzt richtig verstanden hab: der bug tritt auf wenn ne alpha-map aufm objekt liegt, das vor einem volumetrischen objekt liegt (nebel/wolke etc). stimmt so?
ich würd der sache gern technisch auf den grund gehen…
also so weit ich das peile liegt das an der verarbeitung der ansicht der partikel durch den alpha-kanal, die nich auf dem welt-system basiert sondern für die fläche neu berechnet wird und somit das ganze aussieht als ob jeder aplha-kanal-bereich ein kleines format des ganzen bildes is.. aua mein schädel. nee proggen war nie mein ding, erklärts mir einfach

die compositing-lösung gefällt mir aber du zom-b hats ja selbst gesagt mit den objekten und so..

onetoe

ps: wenigstens find ich das ganze spannend.

Ähm…ich sach jetzut mal einfach so “Nein” weil ich ehrlich gesagt echt nicht verstanden habe was du da sagen wolltest :wink:

Mit den Partikeln hat das ganze wenig zu tun…genausowenig mit dem Alphakanal an sich. Mehr mit Renderingrundlagen und der Implementation deren. Da ich Cinema nunmal nicht programmiert habe, kann ich dir auch keine genaue Antwort geben warum im Detail das Ganze auftritt (da ich den code nicht vor mir habe), das ist nämlich vollkommen abhängig von der Implementation der Grundlegenden Techniken im speziellen Cinemas Raytracing Algo und wie dieser mit Transparenzen umgeht bzw danach weitertraced. Möglicherweise gibt es da nen Beispiel zu im SDK aber ich programmiere nicht für Cinema wüsste also nicht ob da spezifischere Info zu finden wäre bezüglich dessen (hab das letzte mal vor knapp zwei Jahren ins SDK geschaut).

Das Ganze verhält sich grundlegend folgendermaßen:
Zuersteinmal tritt der (mutmaßliche) Bug mit allen Transparenzen und Volumeneffekten auf, immer dann, wenn hinter einem transparenten (oder alphgemappten) Objekt weitere folgen (Beispielsweise der Boden – ansonten würde auch einfach die env color zurückgeliefert). Da du nach Details fragst gehe ich davon aus das dir das grundlegende raytracing Prinzip bekannt ist – Ist das transparente Objekt “innerhalb” des Nebels getroffen worden, scheint der danach ausgesandte secondary ray nichtmehr korrekte Farbwerte, sondern dunklere zurückzuliefern. Woran das im einzelnen liegt ist schwer abzuschätzen … es könnte durch eine einfache falsche oder ungenaue addition/division/multiplikation zum Beispiel im multi-sampling entstehen, bereits beim hit des primary ray sodass der secondary falsche infos bekommt oder irgendwo im Kern von Cinema verbuddelt sein und damit eher ne Limitation als nen wirklicher Bug (ausserdem unterstelle ich den Jungs bei Maxon mal dass es nichts simples ist). Der Image Alpha wird ebenfalls “inkorrekt” dargestellt. Hierzu muss man sich den Nebel einfach als Depthmap (Z-Kanal) vorstellen, denn im Grunde genommen ist Nebel nicht wirklich was anderes. Cinemas Umgebungs-Nebel ist im Alpha überlicherweise nicht sichtbar (ansonsten hätte man auch nen komplett weissen (oder grauen wenn nebelintensität < 100%) Alpha). Haben wir ein transparentes Objekt bekommen wir den unangenehmen Effekt dass die Nebelintensität mit in den Alpha geschrieben wird … ergo Transparent ist nichtmehr Transparent sondern der Alpha unsere Nebels. Im Grunde geommen ist diese Situation aber sowieso keine wo wir nen vernüftigen Alpha rausbekommen können, um vernüftiges Compositing zu betreiben (Was ist der Alpha einer Fläche die sagen wir 50% durchsichtig ist und halb vom Nebel verdeckt wird – das Problem lässt sich nur mit Kompromissen lösen und mit Vorgaben wie du das ganze zu compositen hast.)

Einen ähnlichen Bug haben wir beim Himmelsobjekt und Alphas: Gesetzt dem Fall du hast einen geblurrten Rotor auf eine Scheibe gemappt um schnelle Bewegung zu simulieren. Nun hast du für Reflektionen ein Himmelsobjekt und schaltest bei diesem Sichtbarkeit für die Kamera aus. Renderst du nun dein Bild ist dein Image-Alpha Schnodder. Die Luma des Himmelsobjektes wird mit in den Alpha geschrieben. Eine logische Erklärung dafür gibt es nicht und das ganze ist einfach dämlich. Schiebe ich aber eher in die Kategorie Limitation, ausserdem lässt sich das ganze einfach abwenden wenn man ne Kugel anstatt dem Himmel nennt. Alles in Allem sind das derart kleine Macken dass sich darüber nu wirklich keiner beschweren sollte. Lustig ist vor allem letzterer Bug allerdings schon :wink:

hallo LennO
vielen dank für die ausführliche erklärung, echt nett dass du dir die zeit genommen hast. ja ich denke das mit den rays peil ich, macht auch alles ziemlich sinn und wenn das wirklich so is würd ich dir zustimmen mit der “limitation”, auch wenn ichs halt schade find. ich schau mich mal um was andere progs so machen und ob die ähnliche probleme haben..
dass der alpha-channel bei der scheibe nich die reflektion des himmels begrenzt is eigentlich die essenz dieses bugs wie mir scheint. ja k, man kanns scho lustig finden..
du schriebst dass dies recht kleine zu vernachlässigende bugs sind. ich denke jedoch dass sich dieser “berechnungsfehler” auch an anderer stelle auswirken kann, weil er halt doch recht elementar zu sein scheint. ich denke dass man in cinema öfter mit fehlern rechnen muss wenn man mit alpha hantiert. zum beispiel hab ich halt beim backen (anderer thread) festgestellt, dass beim backen einer textur die sich aus alpha-layern zusammensetzt fehler auftreten. ich bin mir ziemlich sicher dass das eher mit menschlichen versagen bei den settings zu tun haben muss, aber weniger sicher bin ich mir, ob es nicht etwas mit unserem alpha-bug hier zu tun hat.

disclaimer: was ich eben geschrieben habe mag vll ein zeichen dafür sein dass ich tatsächlich nicht gepeilt habe was nun der fehler ist. ich werde mich einfach nochmal belesen über 3d-app-algos..

danke onetoe
applaus dem lennO

Die machens richtig(er). Die Alpha Sache ist nen grundsätzliches (geradezu philosophisches :wink: Problem und wie gesagt nur dadurch zu lösen dass man sich auf Standards einigt wie man so ne Sache im Compositing angeht (auch ob Nebel generell im alpah erscheint etc). Im Grunde genommen sind Sachen wie Nebel, überlagernde Transparenzen sowieso in den meisten Fällen ne Sache die man besser im Compositing handhabt als in einem 3d Programm das nunmal bei allem was volumetrisch ist Limitationen haben muss. Das der Fehler auch im Colorlayer auftritt ist ganze allein ein Cinema-spezifisches Problem und hat wenig mit der Theorie an sich zu tun – die machts richtig. Genauso wie die Himmelobjekt Sache ein Bug, den man als Limitation bezeichnen kann sofern er denn irgendwo tief in Cinema verbuddelt ist. Änderbar ist das ganze allemal … Änderungen tief im Kern macht man aber als programmierer nur äuuuuuusserst ungern.

Was (jetzt nich speziell auf dein problem mit Alpha Baking bezogen) man sehr oft beobachtet ist das viele Leute einfach unglaublich komplexe Dinge zusammenschustern (massig alphas, nebel–posteffekte), dann aber ganz schnell Probleme beim Render kriegen, und Fehler entstehen – Natürlich entstehen diese. Wenn man alles in eine Szene wirft kann das alles nichmehr reibungslos funktionieren. Ich persönlich finde diese bugs alles andere als schlimm da ich aus den meisten apps viel gravierende Sachen gewöhnt bin – klar sind die hinderlich wenn diese Dinge oft vorkommen, aber wenn man mit diesen oft zu tun hat sollte man sich auch eine funktionierende Pipeline aufbauen die a) einfacher und damit effizienter und b) über die Grenzen cinemas (Post) funktioniert. Aber ja, Cinema war bislang was Alphas angeht (matte objekt erst ab r9.6 :o) schon immer etwas hinterher.

seh ich ein.
kannst du mir mal erklären wie du zom-bs problem löst mit deiner “Pipeline”? soll jetzt nicht ungläubisch klingen, ich würde dich nur gerne bitten die groben arbeitsschritte auf zu zählen und die nötigen progs / prog-typen aufzuzählen.

dazu:
für den heimwerker is das nämlich nicht erschwinglich ein rendering in mehreren schritten in der post zu bearbeiten (könnte dem zom-b jetzt sicher auch ungelegen sein, vll auch wegen know-how). klar, da kommen die heimwerker halt an ihre grenzen, aber da werden ja einige vll auch eine cinema-internen workaround gefunden haben.. wie auch immer.

ich find das sehr interessant. ich hab kaum ahnung von compositing und ich fänds nett wenn du uns hier einen feinen überblick gibst.
danke onetoe

ps: hättest dir ja denken können :stuck_out_tongue:

Naja…ich rede auch garnichtmal von kompliziertem oder umfangreichem Compositing – mir ist schon klar das man gerade als Hobbyuser sehr limitiert ist. Der Kostenfaktor, und die Erfahrung sind ein Problem, aber auch die vielen unterschiedlichen und teilweise falschen Informationen mit denen man bombadiert wird. Aber jeder der Animation rendert wird um irgendeine Form der Nachbearbeitung (und sei es nur die Einzelbildsequenz zu nem movie zusammenzusetzen) nicht herumkommen, und mitlerweile gibt es auch im Bereich Compositing Open Source Lösungen wie Jahshaka, oder Trials oder abgespeckte Versionen. Je mehr man sich mit Compositing befasst, desto mehr wird man unweigerlich einsehen das für vieles ein 3d-Programm einfach nicht geeignet ist. Natürlich stehen dir mit größerer Programmvielfalt mehr Optionen offen, aber auch im kleinen Rahmen ist ne Menge möglich.

Du wolltest wissen wie soetwas beispielsweise aussehen könnte. Für diesen konkreten Fall habe ich dir mal ein Bild angehangen wie man es hier mit den vorhandenen Elementen lösen kann, um diesen ärgerlichen Bug zu umgehen (in diesem Fall ist ja wirklich ärgerlich, da er schon bei etwas sehr simplen auftritt – aber that’s life).

Angehangen ist ne Datei mit allen benötigten Layer, hier eine Erklärung dazu und alternative Möglichkeiten (noch als Anmerkung: der Einfachheit halber habe ich hier die Partikel bzw deren Shader mal 100% deckend gemacht und die Kreistextur als Alpha verwendet– die originalpartikel waren noch leicht Tranzparent, damit gehts auch aber ist natürlich evtl umständlicher):

Zuersteinmal haben wir den Backgroundlayer, das ist Umgebung (Nebel)+Boden. Rendern wir raus, den brauchen wir später als eigentlichen Hintergrund (ist hier nen simples Dingen kann uU komplexer sein oder selbst aus mehreren Passes bestehen).

Full Beauty, ist in diesem Fall eigentlich unser Partikellayer, denn nur dafür brauchen wir ihn. In diesem Fall gäbe es zwei Möglichkeiten (Achtung, aufpassen, jetzt kommt vielleicht ne wichtige Info ;)):

Wir rendern nur die Partikel+Nebel raus (den Nebel brauchen wir in jedem Fall da er die Partikel verdeckt), in diesem Falle ist der Nebel blau. D. h. wir haben einen Layer in dem nur rote Partikel plus blauer Nebel wären. Die Partikel stellen wir später frei. Wenn wir das aber nun tun, müssen wir wissen das wir hier mit einem premultiplied (premultiplizierten) colorlayer arbeiten, premultiplied against (falls man das zum googlen braucht) blau – wenn wir diesen nun mit dem Alpha freistellen, müssen wir angeben das er premult ist und die entsprechende Hintergrund-Farbe wählen. Wäre hier kein Problem, der Nebel ist einfarbig. Dies müssen wir machen, da wir sonst einen leichten blauen Saum um die Objekte bekommen (das hängt mit grauwertem im Alpha zusammen, beispielsweise durch das Antialiasing entstanden oder wenn ein Alpha vielleicht stellenweise nicht 100% deckend ist).
Ich hab hier aber einfach den Color-Pass genommen dann müssen wir da nicht mit premultiplied rumspielen (generell sollte man sowieso nur premultipliziert mit schwarz verwenden, sofern möglich, oder irgendwie gucken dass man nen straight alpha rauskriegt, hier aber nicht möglich), und brauchen uns keine Gedanken um den Saum machen (jedenfalls keine großen ;).

Als nächstes mal ein Bild des Alphas den Cinema beim reinen Partikelpass (hierbei mal ohne den Boden) aber mit Nebel ausgeben würde – wie man sieht reinster Schnodder den man für nix gebrauchen kann.

Daher basteln wir unsern eigenen Alpha für die Partikel wie auf dem nächsten Bild: Einfach einen weiss leuchtenden Shader nehmen, schwarzen Hintergrund, alles andere raus aus der Szene. Fertig. Da wir die Partikel in unserem Partikel Pass auch vom Nebel bedeckt haben brauchen wir uns hier um Transparenz keine gedanken machen).

Im Final Composite fügen wir dann alles zusammen. Der Background Layer in den Hintergrund, darüber den Partikel-Layer, als dessen Maske unsere eigens für die Particle erstellten Alpha – et voila, Nebel Partikel und Alpha ohne irgendwelchen sichtbaren Mist den wir nicht brauchen.

Zum Schluss sei noch gesagt dass ich in komplizierten Situationen natürlich vor allem den Nebel und andere Elemente getrennt rausrendern würde für größtmögliche Kontrolle, um es dann nachher zusammenzufügen. Dafür muss man dann Stellenweise auch tricksen oder auch mal den Nebel quasi ganz in der Post machen mithilfe eines Z-Passes (oder einfach mit weissem Nebel vor schwarzem Hintergrund ;))
Da könnte man noch unendlich tief rumwühlen, aber die Zeit habe ich nicht. Vielleicht hilft das ja weiter – zugegebenm, Sinn macht sowas nur bei komplizierteren Dingen als sowas. Aber wenn man keine Wahl hat, muss man sich auch bei sowas scheinbar einfachem irgendwie behelfen. Oft sind es die einfachen Dinge die in der CG haken.

BTW, auch wenn das ganze jetzt schon fast weitab vom eigentlichen Problem steht von der Diskussion her, ich hoffe das hilft dir hier vielleicht auch irgendwie weiter Zom-B. Theoretisch könntest du das hier sogar in C4D compositen.

hier fehlt cinema ein node-basiertes compositing-system denk ich, stell ich mir generell schwer vor das zu handhaben in nem 3d-app. man müsste vll verschiedene szenen übereinander gelegt rendern können mit den typischen Verrechnungs-Techniken. Wenn ich mich recht erinnere sind dazu schon 3d-apps in der lage..

Blend Channels
Multiple animation channels can be mixed with each other or with constraints into a single result.
[maya]

find ich recht interessant, aber es sicher viel handlicher und überschaubarer die verschiedenen layer in einem separatem prog zu verrechnen, dass auch nur sperziell für diese aufgabe konzipiert ist.
was ich an deiner erklärung sehe, is, dass compositing auf dem niveau viele gemeinsamkeiten mit der einzelbild-verarbeitung in photoshop. was mich immer nur fasziniert hat war, dass man dann animationen zusammen gelegt hat und dann alle layer über einen zeitraum hinweg perfekt aufeinander abgestimmt sein müssen. aus angst vor monumentaler komplexität wich bisher der faszination meist verweigernde furcht.
ich werd mal mit kleinen animation ein bisschen rumtesten in einem compositing-prog.. sehr interessant.

danke für deine schöne übersicht über deine vorgehensweise und die erklärung der layer. ich würde das hier nochmal fix mit eigenen worten zusammenfassen, damit ich jetzt nichts falsch verstanden hab.
+++

  1. man rendere die komplette animation.
  2. man rendere einen alpha-kanal für die partikel, indem man den partikeln ne leuchttex gibt und den hitnergrund rausnimmt.
  3. man rendere den hintergrund mit nebel
  4. man benutze die in 2. gerenderte alpha-animation als maske für die animation aus 1. und erhalte damit die freigestellten partikel in einem neuen animation layer den man dann nur noch über den hintergrund-background-animation-layer legen muss.
    [man beachte dass das filmformat den alpha-channel unterstütze (?)]
    +++
    so hab ichs verstanden und so entmystifiziert sich für mich die große dunkle masse “compositing”. mein tip dazu: man lese die digital production 04:06

danke onetoe

Richtig. Mit nem tatsächlichen Alpha-Channel arbeitest du hier aber nicht – im endeffekt ist ja bei layer 2 die alpha information in der farbe enthalten (weisse partikel vor schwarzem hintergrund). Ist im Grunde genommen eine sog. Luma Matte da wir die Helligkeit (Luminance<->Luma) Informationen als Matte(Alpha) benutzen. Mit nem Filmformat solltest du garnicht arbeiten…besser Einzelbildsequenzen (tif, tga, exr)

Naja, was heisst fehlt – man sollte nicht alles in eines packen. XSI hat nen leistungsfähigen Compositor build in der direkt einzelne aus XSI gerenderte Passes laden kann etc, allerdings ist das wirklich wenig genutzt. Gibt Compositing Programme (AfterEffects, Combustion, Shake, Fusion, Nuke, Flame Flint Inferno etc) nicht ohne Grund.
Auch Maya hat ein solches System seit Version 7 bei dem man direkt renderlayer mit den aus Photoshop gewohnten Blendmodi überlagern kann – aber ganz ehrlich, wirklich in der Produktion benutzen tut das keiner. Im Print/Werbung Bereich sicherlich ab und an, aber auch da eher selten. Die Passes/Layer alle in einem Szenenfile zu verwalten (da kommt nichts and XSI ran, Maya schliesst was das angeht auf) ist vorteilhaft (aber auch bug-herausvordernd g), allerdings wirst du üblicherweise den Teufel tun das alles gleich im Renderer zusammensetzen zu lassen … die einzelnen Layer/Passes auszugeben erlaubt dir halt die größtmögliche Kontrolle in der Nachbearbeitung. Was Multi-Passing (Framebuffer-Style) angeht ist Cinema ungeschlagen – Kein Programm rendert dir mit einem Rendering (standardmässig) soviele Informationen mit einem Rendervorgang (Specular, Reflection, Object IDs, GI, Ambient Occlusion, Motion Vector etc) raus. Dafür hing Cinema etwas hinterher wenn man sich die einzelnen Layer als individuelle Szenen basteln musste (fehlendes Matte Objekt etc). Die meisten anderern Renderer haben keine so vernüftige Framebuffer Verwaltung von Haus aus – in der Produktion haben wir aber natürlich Mittel (sprich – entsprechende Shader) die es uns in Renderern wie Mental Ray oder renderman complianst ermöglichen alles was wir brauchen (zumindest einen Großteil) mit einem Rendervorgang rauszuhauen (auch selbstdefinierter Shadersysteme).
In wiefern man das wirklich “braucht” hängt ganz allein von der Komplexität das Projektes ab. Manchmal renderst du ne Menge Passes raus, manchmal nur den Beauty weils reichen wird.

Übrigens, das Zitat was du dir rausgesucht hattest bezog sich nicht aufs Rendern, sondern auf Animation. Channels in Maya sind alle “Kanäle” die animierbar sind (also quasi jeder Parameter den es irgendwo gibt…eigentlich alles ;)), diese können hierbei gewichtet geblendet werden. Ich könnte also das Ergebnis einer Keyframeanimation (oder auch zweien) und eines Constraints (Zum Beispiel Orientierung) nehmen, und diese gewichtet mixen lassen, Beispielsweise 50%/50%.

Compositing ist auch nichts anderes als Photoshop für bewegte Bilder. Genau die gleichen Prinzipien gelten hier und prinzipiell kannst du alles (und mehr) was du in PS machen kannst auch auf jede Animation anwenden. Bestimmte komplexe Szenen können gut und gerne mal 50-200 Layer verschlingen. Was man natürlich ungerne macht was bewegte Bilder angeht ist painten – aber auch hier gibt es masken, bluescreens etc etc zum freistelen und ähnliches. Das machen dann die Rotoscoper. Hat nichtsmehr mit Compositing an sich zu tun, trägt aber nen ungemeinen Teil zum fertigen Produkt bei wenn du real+cg Aufnahmen mischst.

Schön, dass ich dich dem Thema näher bringen konnte!

Lennart