The way this scene is set up may be part of the issue… It’s using two PRT loaders which load Realflow data, and then a Stoke instance that adds some additional detail, and has some other velocity influences. There’s around 30 million particles.
All three systems are being re-timed, and have the sub-frame interpolation set to on. Perhaps this is the issue?
Also for reference, this is being rendered at 2560x1440px, 30FPS, on a 6-core (12 thread) machine with 32gb of ram.
So far I have tried these things, and they do not fix the problem:
Setting the memory allocation to float 32 for absorption, velocity, color, and lighting.
Redoing the entire Realflow simulation with more particles.
Tweaking the coloring
Adding/removing lights
Adding the velocity mamgaflow mentioned below
Hi lostpixels.
We’ve seen similar issues before when rendering particles generated from Realflow simulations. In those cases, it was caused by the velocity channel of the particles being in the incorrect units. If that’s the case here, adding a Magma modifier to the particles to divide the velocity channel by the framerate (most likely 30) might fix it.
Thanks for the tip Evan, I’m gonna try that right now!
The weirdest thing ever is that I think I found the issue, but it’s totally unrelated. When I turn off “Multi-threaded Lighting” in the preferences, it will fix my problematic frame!
I have to render out a sequence to validate this, but it has fixed one glitchey frame so far. This also increases my render time by quite a bit
Edit: This removed like 90% of the flicker, but it still pulsates for no apparent reason.
Thanks for the flowers, and sorry for the inconvenience!
Are the files BIN or PRC files, or are they PRT files saved from RealFlow? If you are saving PRT files from RealFlow, try not to. See if loading native RealFlow files will make a difference. If they still have an issue, we can discuss the next steps.
Also please provide the exact version numbers of 3ds Max, Krakatoa MX and RealFlow so we can attempt to use a similar setup when testing.
As Evan suggested, the problem is most probably related to the retiming / interpolation of the particles. Try rendering the straight sequence without retiming and Interpolate turned off, and see if the flicker will disappear. If it does, we will know where to dig deeper…
Oh woh, I have been using the PRT export from Realflow 10 this whole time! I will avoid using that next time. My setup in 3dsmax 2016 and v2.6.1.
I will try re-render without any retiming, but that’s a bit of a bummer because it’s such a great feature! Do you think retiming the PRT loaders -before- I use Stoke would make any difference? I can retime in Realflow too but it takes quite a bit of time.
I am not suggesting to avoid using the RealFlow PRTs, or the retiming. I am suggesting to TEST which one might be causing the issue. There have been a few issues with PRTs written from RealFlow in the past, for example the ID channel could be named “id” (lower case), which would prevent the interpolation feature from working correctly, or the Density channel could be 0 where it should be at least 1.0. I believe these were fixed in RealFlow 10, but we better make sure. So testing with the native RealFlow output (BIN or RPC) would help us determine whether the PRT files themselves are the issue. (If you want, you could upload 3 or 5 frames from your sequence somewhere so I can test with them and find out what is going on).
Then I suggested you disable the retiming and try to render a few frames to see whether the retiming is the cause of the issue - last time we had this kind of problem reported, it was an issue with interpolation, but it was an actual bug in our code which we fixed. If you can confirm that the interpolation is causing the issue, we would know where to look.
Once we have found (and hopefully fixed) the issue, you can go back to retiming RealFlow PRT files in the PRT Loader (assuming the RF PRTs are not the cause of the trouble).
Hmm so turning off retiming has helped remove the flicker. What would be my next step in order to be able to retime + no flicker? Also, thank you so much for the assistance with this problem, it means a lot!
Do you think if I used stoke to basically merge all three particle sources together and boost the particle count it would help?
Was this last test with PRTs written by RealFlow?
Next step: Do you have the simulation in another format inside of RealFlow? Particle BIN or RPC? If yes, try loading that, enable Retiming again and compare. If you don’t have native RealFlow files, can you simulate a few frames (save only the RealFlow files, no PRTs), and test with them?
Also, can you share with us 3 consecutive files from the sequence you just tested with? I can give you an upload link on our server, or you could send us via any method you want.
We don’t know yet what is causing the flicker when retiming, although we have a suspicion. Stoke would not help. The problem is not in the particle count, but in the particle data itself, or in the way it is being used to interpolate. So let’s not look for workarounds, but let’s try to get to the exact cause.
Also, did you try the test Evan suggested (Magma Modifier with InputChannel:Velocity->Divide (30.0)->OUT:Velocity )?
Notice the flicker, I believe that’s actually from an omni placed directly in the middle of the cloud. I removed it and redid some frames and it didnt seem to flicker any more, so I am not too worried about it.
I only have PRTs for this realflow simulation But I can probably resim tonight.
What consecutive files would you want? Just image files??? I can pass along whatever you’d like.
I did try Evan’s method on all of my particle objects, but it unfortunately did not change the result.
I should mention the Stoke sim uses velocity from a fumefx simulation along with the realflow PRTs. Makes for cool wispy effects, but perhaps that is making this wonky.
What is the Attenuation Map Size of that light (the Shadow Map Size)? Does the flickering pattern change if you increase it? Sometimes the attenuation map resolution can cause moire effects…
It would help to compare, even if it is a small segment…
I meant 3 PRTs from the RealFlow sim from the range where it flickers when retimed. I want to retime them myself and see what renders. Of course, I expect the files to be huge, so I would understand if you cannot upload them.
Alternatively, you could select the PRT Loader, then go to the Krakatoa menu and open the Particle Data Viewer. Resize it horizontally so I can see as many channels as possible. Post a screenshot (or two, if all columns don’t fit on one screen) - I am mainly interested in the names of the channels, and what typical values look like.
Negative results are also useful results. We know now that the velocity scale is likely not the problem.
I would highly recommend simplifying your setup for testing purposes and not including the Stoke particles at all, just a single PRT Loader with RealFlow particles. We are debugging now, not trying to produce beautiful art (it looks awesome btw, but that’s not the point )
Okay Bobo, we can rule out retiming as the issue now. The normal speed animation also is subjected to flickering, as observed here: gfycat.com/ColossalElatedBumblebee
I took particle data samples from frames 132-135, and includes the raw output frames for you to take a peek at: imgur.com/a/9MAyP
Where can I see thew attenuation map size? I have not tried that yet. I am use two target spotlights for lighting here.
I hope this helps, I will be on vacation for a few days but when I get back I will be happy to provide you with any additional assets or help that you need. Thanks again for taking the time to assist me, it’s so awesome that this forum exists!
If you set your lights to Shadow Maps, the Shadow Map Size controls the Attenuation Map Size. The default is 512, which might be too low for high-detail work. You can try increasing it to 1024, 2048, 4096 and rerender to see if the nature of the flicker changes. If it still flickers, but in a different way, then we would know the attenuation map size has something to do with this. If nothing changes, then we will look elsewhere.
There is an alternative way of setting the Attenuation Map Size via a Krakatoa Shadow Generator, but you don’t need to go there.
When you come back from vacation, can you please post a screenshot of the Max viewport showing where the particles are, and where the lights are placed in relation? What are the cone angles of these lights?
Shadow Maps On controls whether MATTE objects will cast shadows onto particles. Particles always cast shadows onto particles, no way to turn that off anyway. Just thought I should mention it.
Out of curiosity, does the “Absorption is turned on” play any role in the issue? I would expect it to flicker with Absorption turned off, too. Can you render a few frames without Absorption to confirm?
If I remember correctly, you mentioned that forcing rendering on a single thread solved the problem? If that’s the case, it would mean that some of the lighting threads are producing incorrect attenuation, or the merging of the lights into the end result is wrong.
I think at this point you should stop trying to tweak the scene, and we should start looking into reproducing it on our side, and fixing the code. I believe I saw this once in the past, but it wasn’t easily reproducible. Since you are getting this consistently, we might have to figure out 1) can we reproduce the same flickering if we render your scene on our machines and 2) if not, what is the difference between your machines and ours.
The PRT Loader is supposed to get the scaling of the particles from the metadata encoded in the RPC file. If you make two PRT Loaders, pick two RPC sequences saved by RealFlow, and one is 100x smaller than the other, then it is a bug in RealFlow’s export of the two domains, not our bug.
So the next step will be to send us a few frames of the RPC files (not the whole sequence, I would say 10 consecutive frames would be enough), as well as your MAX file. Let me know if you want a dedicated upload folder on our Box server, or whether you want to email me a link from your storage (if you have one on Dropbox, Box, WeSendIt, or whatever you might use). Please ZIP all files together, and we will try to render here and see if we can get it to flicker the same way.
Another thing to confirm - if you render the same scene with the same Krakatoa settings twice to two image sequences and compare in RAM player, do they have identical flickering, or are they random? My guess would be the flicker would be random and not deterministic. If it is random, then the problem is threading-related and not related to any rendering settings of Krakatoa (except probably the Multi-Thread Lighting option).
Good news. After tweaking the shadow map size param that was in my last post, it removed the flicker! I am going to try this will all the fancy effects in my original post next, but my simple scene has been re-rendered and it is nice and smooth now!
I think you could reproduce this on your machine if you set the shadow map size to something small like 500, render at 2560x1440px, and use absorption. If you want, I can try and send you the assets I have too.
This is awesome news. Let me try to suggest what was happening.
As I mentioned, an Omni light renders internally as 6 90-degrees spots. In the current implementation, the attenuation map resolution is the same everywhere along the -Z axis of each of these spot lights. This means that as a particle is moving closer to the light, the precision of the map increases significantly. When a particle is moving away from the light, the quality of the shadow will be reduced, as one texel of the map represents larger and larger areas of the cone’s cross-section. Since the angle is 90 degrees, this quality falloff is significantly faster than in a Spot or Direct light where the cone is either much smaller in most cases, or not a cone at all (Direct lights preserve the same quality along the ray as their cross-section is constant).
So as your particles move relative to each cone’s axis, one texel might affect one particle, a thousand particles, or a million particles depending on how far from the Omni the calculation is performed. This might be causing abrupt changes in the shadowing when the number of texels in the map is relatively low. Increasing the Map resolution would let you preserve higher quality shadows farther away from the source of the light.
In general though, we recommend avoiding Omni lights and using Spot and Direct lights when possible because
this gives you better control over how the map resolution affects quality (you can adjust the cones to include only the particles it needs to illuminate)
uses 6x less memory during attenuation map calculations
works in Voxel mode too (Omni lights are not supported by the Voxel render mode)
Any advice?
)
