I have a pyro simulation baked out that calculates dual rest frames every 50 frames.

I am then bringing this simulation into another file with lowrespyro dop import, using load from file with `$F+173` in the file string, to offset the files by 173 frames.

The problem is that I have a huge amount of popping in my renders, and i think this must be due to there being a discrepency between the Pyro shader rest fields and the actual rest fields generated during the simulation.

I'm having huge trouble trying to figure out what number I should place into the Pyro shader rest field start frame to get it to correctly sync with the simulation. The Pyro sim was simulated from 1-600 frames, so I can't just put 173 in the shader rest field, as there wouldn't have been a rest field calculated then, right?

Maybe I'm over complicating this and confusing myself… Can anyone lend an insight?

Cheers,
Gary

Any idea's guys? I'm still having major issues with the renders popping every 25 frames.

I've attached a quick animation to show what I'm getting.

The pyro animation on this is set to $F+140, so in the shader dual rest field I put -140. Unfortunately this doesn't seem to make any difference. No matter what number I put in here I always get popping on frames 12/13 and 36/37. Could it be that it doesn't recognise start frame values less than 0?

Ponge
Any idea's guys? I'm still having major issues with the renders popping every 25 frames.

I've attached a quick animation to show what I'm getting.

The pyro animation on this is set to $F+140, so in the shader dual rest field I put -140. Unfortunately this doesn't seem to make any difference. No matter what number I put in here I always get popping on frames 12/13 and 36/37. Could it be that it doesn't recognise start frame values less than 0?

If it the sim was saved starting at frame 1, and its rest cycle was 50 frames long (also starting at frame 1), but the files are now being read back starting at frame 141 (you said “$F+140”), then setting the shader's dual rest to start at frame 141 with a cycle length of 50 (or whatever the sim's cycle length was) should work I think. Have you tried that?

I gave it a shot and it didn't seem to work unfortunately :-(

No matter what values I put in the ‘start frame’ it seems to always pop on frame 12 and 37.

I've also tried without Dual Rest Frames and it still seems to pop on these frames. When I flipbook just the simulation there isn't any popping, but then I don't know if this would be visible in the flipbook.

Cheers,
Gary

Ponge
I gave it a shot and it didn't seem to work unfortunately :-(

hmm…
Oh; hold on. I think I misread that.
Try setting the start frame to -139 instead (which is 1-140).

I would really need to set up a test to see what's going on, and I'm in a bit of a crunch at the moment so it's going to take me a while before I can get to it in any depth.
In the meantime though, assuming nothing has changed in the way the sim puts out the dual fields, then this is why I think (-139) should work:

Here (in pseudo-code) is how the shader treats the two rest positions (lines 2237-2239 in the vex code):
t = modulo($F-start_frame, reset_rate) / reset_rate;
rest1_weight ~= cos(t*360)*.5+.5;
rest = lerp(rest2,rest1,rest1_weight);
So… you set the sim to have a 50-frame cycle, which means that the cycle boundaries are at frames , and so at frame 141 (frame 1 of the render sequence which reads the sim with “$F+140”) we should be 40 frames into the 3rd 50-frame cycle, and if you set the shader's start frame to -139 and the reset rate to 50, at frame 1 ($F=1) we should get:
modulo($F-(-139), 50)
= modulo(140,50)
= 40

Which is what we'd expect, so, in theory at least, I think should work…

crossing fingers…

Hmmm, I've tested it in another scene without the file offset (so just input as $F) and it looks like it's still flickering. This time on frame 52.

That is with shader dual frames turned on, set to Start Frame 1 and reset every 50 frames.

So now, i've no real idea what could be causing this. Could it be an issue with my initial simulation? I could re-simulate I guess with a reset rate of 60 (I've heard that works better in some cases).

The only other thing I can think of is that when I initially simulated, I'd heard that large scale smoke looks nicer when you slow down the simulation to about 0.825 (in the AutoDopNetwork/simulation/scale time option), so would this have an effect on the Rest fields? Maybe I should scale my rest field refresh *0.825 (so instead of 50, it would be 41.25).

Sorry, I was in the middle of editing my previous post when you added this last…

Try -139 as I suggested last. If that doesn't work (I think it should), then something else is going on and I'll need to do some actual tests to find out.

Cheers.

I just tried, and unfortunately it doesn't seem to work :-( (with either -140 or -139). With both it still flickers on frame 37.

At this point I'm starting to think it might not have anything to do with the shader rest field. I tried rendering from frame 50 without the file offset (and shader set to start frame 1, reset 50) and I still get this issue. This time on frames 52 and 77.

So even when the file is setup as default it's still popping. Very very strange.

Another thing is the strange frames that it seems to pop on, when the file is offset by 140 it always pops on 12 and 37, no matter what value is placed in the shader start frame.

Trying to figure this out, when $F=37, then the file being read in is 177.bgeo.gz The nearest rest frames in this sim would be 150.bgeo.gz and 200.bgeo.gz. If the shader swaps rest frames every 25 frames then this would happen on 175.bgeo.gz (or $F=35), not 177.bgeo.gz right? And then when I run without the file offset the frames pop on 52 and 77, instead of 50 and 75 where you would expect them, again 2 frames out.

Hmm, I'll try rendering with start frame = -137 (trying to compensate for this wierd 2 frame discontinuity) and see if that helps. Meanwhile I'm re-simulating with different rest field settings so I can see if that makes any difference.

Thanks for your help Mario, I really appreciate it!

Alright. I'll take another look when I get a chance.

Well, I think I can provisionally say that -137 fixed it! I've rendered off 50 frames and there's no real visible popping, so hopefully that's done it!

I have no idea where the 2 frame discrepency came from though, very strange. I have several other sims in the same shot, so hopefully this solution can be transferred to those without too many issues.

Thanks again for your help Mario, I really appreciate it.

Ponge
Well, I think I can provisionally say that -137 fixed it! I've rendered off 50 frames and there's no real visible popping, so hopefully that's done it!

Yay!
Well, I'm very glad that you found a workaround, but I have to say… that 2-frame fudge factor doesn't make me very happy at all :evil:

Good luck with the rest of the sims!

still crossing fingers…

It still pop's :-(

Only on frame 12 so far though… Not on frames 37 or 62 as you'd expect. Very, very, very strange. The bigger issue now is that there are blocks of white pixels appearing on every other rendered frame (i've attached a single frame to see what I mean). In Nuke there is no colour information (although there is an alpha value) on these white pixels and there doesn't seem to be any correlation between the placements of them, they're totally random and sometimes not even on the smoke. If I load the exr's in as linear colourspace they appear white, if i load in with sRGB they appear black (as in the attached jpeg). It's affected maybe 1/3 of my frames so far.

Very frustrating as I'd like to get to the bottom of these issues, but my deadline is very quickly approaching so I don't have time to trouble shoot, merely treat the symptoms rather than the underlying problem. Re-rendering the offending frames doesn't seem to fix the problems, so I think I'm just going to have to paint over them.

I've had so many issues with this shot, I'll be very happy to just move on!

I seemed to have given this thread the kiss of death by calling it ‘quick rest field problem’.

I seem to have fixed the white/black spot issue by changing the depth map shadow settings. I put the shadow pixel samples to 2x2 as I was having a strange strobing effect and I thought this might help. As soon as I put them back down to 1x1 it seems to have fixed the issue.