Another flicker/glitch thread


#1

I have been plagued by the flickering issue mentioned by so many others here for years now. One really weird thing I wanted to mention is things will stop flickering if you set the Velocity render element. Instead it completely changes the values of any magmascript that uses the Velocity input. Maybe that would be helpful for the developers… But is Krakatoa even under development any more?


#2

Can you provide a simple test scene/PRT data set that shows the Velocity Render Element effect on flicker and the Velocity channel values?


#3

I would be happy to. I am making it now, what’s the best way to get it to you? Thanks!


#4

I put it online, check it out here: https://we.tl/t-vLNN9YT3gj

The colors in these particles should not change at all since they have the same velocities, and the velocity is powering the diffuse and emission channels. In actuality though, they pulse in and out over the course of the 200 frames. Also take note that it’s only 2 frames of particles, but they’re graphed over 200 frames. The goal would be a consistent result throughout the entire animation where only the position changes ever so slightly.

Hope that helps!


#5

That is not a flicker! That is a totally unexpected gradual change in the color due to incorrect Velocity interpolation over 200 frames. So it is a bug, but not in the shading. It is in the “Interpolate Sub-Frames” feature of the PRT Loader.

You have the Playback Graph set to animate over 200 frames from frame 499 to 500. Here is what the Velocity of particle with ID 1 looks like on frames 0,50,100,150 and 200:

0:   [-1.71502,-8.60451,-7.53233]
50:  [-0.193806,-0.967548,-1.92887]
100: [0.342636,1.6343,-0.0679779]
150: [-0.105915,-0.798805,-1.94982]
200: [-1.53947,-8.26687,-7.5744] 

Obviously, given that the Velocities on frame 0 and 200 are nearly identical, you would expect a very slight change of the vector over time. However, due to some mathematical strangeness that our developers will have to look into, it does a lot of scaling around, and since your Gradient Ramp’s U value is dependent on the Velocity Magnitude which on the above frames goes through 11.5635, 2.16662, 1.67121, 2.10976 and back to 11.3174, the colors shift accordingly.

I went ahead and tested an even more extreme case where frame 501 is identical to 500 (just copied the PRT file). Then I set the Point Z Position animation to go to 501 on frame 300. As I feared, instead of producing a consistent Velocity over the 100 frames from 200 to 300, I got a vector that gradually stretches in the opposite direction and the returns.

Thanks for the bug report, I will make sure it is logged and hopefully fixed.

You mentioned something about Velocity Render Element changing the outcome, but I could not reproduce that.


#6

Nice! I’m glad I was able to help catch the bug, and I hope to see the patch in action :smiley: The Velocity Render Element may have not worked in this example, just something I thought I noticed in the past…