Jumpy shapes when animating certain flames
When sequencing and rendering the attached flame, parts of the flames jump around. Like with #6, the artifacts still happen every few frames even at high frame counts like 5000, so this seems to be an issue rendering or sequencing, not in determining the appropriate shape at a given point in time. For your convenience, I've attached a render from Fractorium as well as the original sheep for reference.
This happens with SP and DP, on CPU and GPU, and with the GUI and CLI.
This seems like a render issue anyone could encounter, so I'm leaving the priority at the default medium setting (Why Atlassian thinks "Major" is a good description for the middle setting, I have no idea).
Comments (31)
-
repo owner -
reporter I sequenced it using the GUI. Will wait for test release.
-
repo owner This has been released in version 1.0.0.4. Please get the latest from fractorium.com
-
repo owner - changed status to resolved
-
repo owner Not sure if you're still interested in this, but as a result of a similar issue another user posted, I've found and fixed several bugs. I've temporarily made a test build available for download:
https://bitbucket.org/mfeemster/fractorium/issues/17/sudden-jumpy-frame-at-the-end-of-a-blend
See my comment toward the end there. These problems should be fixed now.
-
reporter - attached x264-24.mkv
Render with new test version
-
reporter - attached no rotations.mkv
Same, but with 0 rotations per blend
-
reporter The test version is better, with fewer components jittering, but some still do. Interestingly, turning rotations off results in no jitter.
-
repo owner I think the small jitter might have had something to do with not normalizing large rotation angles upon loading the flame from xml. I've fixed that, give it another try with this new build:
https://drive.google.com/open?id=1maKRqveCBy9FnOfSRBG1lpHeKdwtVOyu
-
reporter No visible difference in the new version, aside from sampling noise.
-
reporter - changed status to open
-
repo owner I used animtest.xml as the source for flam3-genome.exe to generate a 20 frame blend sequence with no rotations, then used it to generate a sequence in Fractorium, then diffed the output files. I can clearly see a difference in the affine values. It's late right now, so I will get to this in the coming days. But at least we know there are still some bugs lurking. Thanks for alerting me to this.
-
repo owner I made a small fix and get identical results to those produced by flam3-genome:
https://drive.google.com/open?id=1maKRqveCBy9FnOfSRBG1lpHeKdwtVOyu
Note that the default for flam3-genome is to do one rotation per blend. So to duplicate that behavior in the Fractorium sequencer:
Rotations 0
Frames per rot 1
Blend frames 20 (You can make this more if you want)
Rot per blend 1
-
repo owner Please test and verify so I can close this.
-
reporter You need to render at about 60 frames per interpolation to see any juddering.
Do you happen to know where can I get a Windows binary for flam3? The official site and GitHub releases page don't have any, there are no instructions for building from source, and the most recent build I could find online is 2.7.18, which is 9 years old.
-
repo owner You were right again! There was indeed yet another bug. I've fixed it, so try downloading from here again:
https://drive.google.com/open?id=1maKRqveCBy9FnOfSRBG1lpHeKdwtVOyu
As for getting a build, I thought electricsheep.org made downloads available? If not, perhaps I can make a build for you if you absolutely need it.
-
reporter Thanks for the offer for a build, but I've opened an issue on the flam3 GitHub. 'Randomly find a guy who knows how to build it on a completely different site' is not a useful way to distribute software for anyone. I don't know what the hell they're thinking not offering builds.
Testing new version now.
-
repo owner Yeah, it's sort of a dead project. Scott Draves moved onto other things about a decade ago. Erik Reckase took it over for a bit and got it to a stable working point (I commend their efforts, since I'm barely getting my implementation correctly working 6 years later). So its main use these days is the electric sheep project, which people still run. Long story short, it runs good enough, so there's not much more to be done.
-
reporter Okay, I'm not seeing any difference between the most recent build and the one before it. I've started testing with these commands for better repeatability and easier comparison:
EmberGenome.exe --sequence=animtest.xml --interploops=1 --interpframes=159 --loopframes=0 --loops=0 > out.xml
EmberAnimate.exe --in out.xml --opencl --prefix=buildX_ --verbose
and using ImageMagick to do comparisons with the Windows equivalent of:
for i in `seq --equal-width 0 159`; do magick composite build3_$i.png build4_$i.png -compose difference diff_$i.png; done
-
repo owner But are you actually seeing the jumpy frames? And if so, can you tell me roughly which frame the jump happens in?
While finding and fixing that last bug, when using 60 frames, I found it started happening around the 44th frame (frame 43 when using 0 indexing).
I'm positive I fixed that bug because the output flame parameters are now the same as flam3-genome generates.
*Note, mine will be slightly different because they include the "Flatten" variation, which is related to other Apo compatibility stuff, but it shouldn't matter because that only deals with 3D params, and flam3 doesn't support those, so flatten is unused in this case. All other variations and affines in the sequence frames should be the same.
So please tell me which frames are visually different, and if possible, which frame parameters are different (might need to look on the electric sheep server for the params for each frame).
-
repo owner Think I just found another discrepancy, hold on.
-
repo owner Can you please link me to the original flam3 source frames for this from the electric sheep server?
The issue is with something called "motion magic" which is a seldom used feature.
-
reporter The original flame is available on the sheep server: http://v3d0.sheepserver.net/cgi/dead.cgi?id=14758&detail=genome
-
reporter - attached build4.mkv
Sorry, didn't see your initial response in the email notification - yes, I'm still seeing jumpy frames. The first sign of jumpiness is at frame 17 (1 indexing throughout) with most of it focused around 25-67. Attached is a render.
-
repo owner Here we go again. I found and fixed another bug and after this I could see the jitter going away:
https://drive.google.com/open?id=1maKRqveCBy9FnOfSRBG1lpHeKdwtVOyu
Hopefully this is the last one!
-
reporter Well, fifth time's the charm, as they say.
Or something like that. Anyway, testing now.
-
reporter Aaand something came up and I completely forgot about this. Sorry!
Initial results are very positive; diffs show very little difference between the Ember rendered frames and the frames extracted from the original AVI from the sheep server. There are still differences that are very minor in this sheep; check frame 112:
Might want to open each of those in a separate tab and Ctrl-Tab between them. The differences start becoming visible around frame 84 and become more pronounced towards the end, with a few shapes in the purple ring (kinda looks like the iris of an eye, now that I look at it closely) rotated 3-5 degrees clockwise.
Thanks for your continued fixes
-
repo owner How many frames did you specify when generating this sequence? I need that number to repro the sequence exactly.
I assume it's 160?
-
repo owner I took a look and the parameters to the flames are identical. I think the differences are from some slight fixes I've made to bugs that are in the flam3 code. So I think we can call this one good and close it.
-
reporter - changed status to resolved
I honestly can't tell the difference without flipping back and forth between the two anyway. I don't need perfectly identical results, so I'll close it. Thanks for all your work.
-
repo owner - changed status to closed
- Log in to comment
What is the exact command line you used for this? Like my other posts, I think I inadvertently fixed this with my previous commit. Standby for the next test release if you are not building from source.