Hey guys, as the title suggests any and all blueprint events seem to treat the Anti Alias subsampling in Movie Render Queue when using Temporal samples - each sample is like an engine tick, and therefore if each frame is rendered with 8 samples and then played in sequence, animations for things like spawned niagara systems in blueprint or weather systems accelerate absurdly.
My work around has been using Spatial samples instead of Temporal - is this the correct way of going about it?? Or is there a better fix so Spatial can be used?
So by this I mean: the systems be it wind, environment controllers, or anything made with BP designed to run per event tick will treat every anti alias “temporal” sample as a tick, therefore 8x faster when played back after compiling the sequence of PNGs JPGs etc
My experience is consistent with this. Not only does it speed up any motion tied to blueprints but it creates ghosting artefacts due to actors moving in the ticks between frames. TAA can cause blurriness and ghosting normally but in this case it happens to every thing that moves with a blueprint as the movement is occurring on each sample rather than each frame.
I’m using niagra for schools of fish and other fish running ai blueprints, but i have other keyframed animation in the sequencer and am using movie render queue
Hi, a bit too late, but have you found any workaround for this?
I’m facing a similar issue when rendering Ultra Dynamic Sky rain particles. Whenever I increase Temporal Samples the rain particles multiply. I’m using UE 5.3.
Using Spatial Samples instead of Temporal works but the I wanted the motion blur as it’s a fast car animation.
I encountered this issue after creating a custom animation blueprint for spinning the wheels of a vehicle relative to its velocity. The render used 66 temporal samples for what should be excellent motion blur quality, causing the wheels to spin 66 times faster than they’re supposed to and causing awful motion blur artifacts.
I found a workaround that works perfectly for my case. The bone velocity > vector length is divided by the radius of the wheel to get the spinning speed. So to compensate for the temporal samples, I now multiply the radius with the sample amount first. To make it easier to adapt it to different settings, I made it a float variable that is Instance Editable and Exposed to Cinematics so I can edit it directly from the sequencer.
I don’t know how to apply the same solution to your cases, but the universal idea is to essentially divide whatever variable decides what speed things are going at with your chosen amount of temporal samples.
I’m on 5.3 to be clear. No clue if this is fixed in 5.4 or 5.5.
