Hallo alle zusammen,
ich habe wieder ein problem mit dem motionblur im physical-renderer. bei allen kameramappings die ich bis jetzt getestet habe taucht immer dieses seltame problem auf als ob die textur mit einem oder 2 frames delay auf die geometrie gemappt wird. kann man schwer beschreiben deshalb habe ich schnell was rausgerendert wo man den fehler gut erkennen kann:
ganz deutlich ist dieses “texturshifting” zu beginn am fensterrahmen links und die ganze zeit am boden -übergang-Zierleiste zu sehen. der boden wabert strange rum. bei dem rendering unten OHNE motionblur sitzt die kameragemappte textur bzw. bildsequenz 1a auf der geometrie.
ich hatte so ein ähnliches problem schon mit geometriebasierten shadern ( z.b. wireshader usw) das problem wurde auch schon als bug von maxon bestätigt. vielleicht ist das auch in diesem fall der grund warum es nicht richtig funktioniert mit dem kameramapping. das war damals die antwort vom maxonsupport:
Leider handelt es sich derzeit um eine Limitation zwischen dem phys. Renderer und den Shadern, die einen eigenen Geometrie-Cache erzeugen der auf dem Startpunkt des Renderings beruht.
Hierbei kommt es zwischen den Bildern zu einem Versatz des Shader-Caches und dem des phys. Renderers.
Es wird hierfür nach eine Lösung gesucht. Da es sich aber wohl um ein sehr komplexes Problem handelt, wird keine schnelle Lösung zur Verfügung stehen!
Mh… sieht schlimm aus
Ist mir selbst noch nicht aufgefallen - habe allerdings auch noch nie den Phsyk. Renderer bei Kameramappings genutzt.
Die Bewegung scheint erstmal nicht so komplex zu sein, daher die Frage: Warum den Motionblur nicht in der Post?
Bei der “Zeitverkrümmung” in AfterEffects hab ich nicht soooo viel zu meckern.
ja, zur not mach ich den motionblur in der post drauf. das sind auch noch alles testshots. hier noch ein beispiel mit dynamics wo es auch sehr gruselig ausschaut:
Mh. Ist halt blöd wenn sowas nicht funktioniert. Sei froh dass du nicht mitten im Job steckst.
Ich drücke mal mit die Daumen, dass es bald gefixt wird!
hi matthias. das mit den uvws geht nicht weil die bewegung der kamera zu stark ist. sonst hätte ich ja immer das gleiche frame auf der geometrie oder? das hatte ich schon ausprobiert. geht wohl nur wenn man ein still per kameraprojektion animieren will. aber vielleicht kann man ja eine brauchbare textur in syntheyes generieren per textureextraction. mal schauen.
Okay, wenn ich das File vorher runtergeladen hätte, hätt ich`s gewusst
Aber bei der Szene könntest du dir ja zum Glück nochmal mit klassischen Kameramapping behelfen - auch wenn`s nicht Sinn der Sache ist.
Bin gespannt was draus wird.
sorry, das mit dem tracking hätte ich noch dazu schreiben sollen…
mal gucken was maxon dazu sagt…aber da es wirklich wie ein frameversatz ausschaut denke ich mal das es der gleiche bug ist. nur dieses mal mit einem etwas anderen flavour…
Vielleicht ist es auch gar kein Bug, sondern technik-bedingt. Ich hab noch ein bisschen drüber nachgedacht und das ist aus meinem Hirn raus gekommen:
Der Physical MotionBlur rendert ja einen halben Frame vor und zurück. Also wenn du Frame 20 renderst, rechnet er Motionblur von Frame 19,5 bis 20,5. Die Kamera bewegt sich da auch (wegen der kontinuierlichen F-Curve). Allerdings bewegt sich dein Film nicht. Der ist statisch in den Subframes. Daher wäre es eine logische Folge, dass sich der MotionBlur seltsam verhält wenn eine animierte Kamera (im subframe Bereich) auf ein statisches Bild trifft das sich auch noch mitten im Frame verändert (wenn er von Frame 19,9 auf 20 geht im Sampling)
ok, dann ist das vielleicht kein bug sondern eine “echte” limitation. aber exakt das gleiche problem hat man ja auch mit shadern die einen geometrie-cache pro frame erzeugen. da hat man auch immer den effekt das die textur plötzlich auf dem mesh zu “schwimmen” beginnt.
