3rd Order Evolution Of Tilings

[Dinkydau]

Thanks. I have been able to examine a "zoom sequence" consisting of two copies of the kfb file. I will see if I can use this to fix the glitches, but not right now. I don't have enough RAM available.

[Dinkydau]

I was able to load that zoom sequence with Claude's version (20170713 to be exact). It can also be loaded with kalles fraktaler 2.11.1. The eraser (which is a huge fixed size rectangle) can be used to erase a part. However, clicking inside the erased part (or anywhere else) doesn't do anything. No reference gets added.

I tried doing the same with a small test zoom sequence with resolution 640×360, rendered with kalles fraktaler 2.11.1. I could examine it in kalles fraktaler 2.11.1 but not with Claude's version. I also rendered a similar zoom sequence with Claude's version. I couldn't examine it with Claude's version itself, but I could with kalles fraktaler 2.11.1. So Claude's versions can't examine their own sequences, but they can examine my fake sequence of 2 big renders, for some reason.

Anyway, with the small test zoom sequence loaded in kalles fraktaler 2.11.1, I could erase parts. Adding a reference inside an erased part turns the erased parts (all of them) into a different (though the same for each erased part) color. Adding a reference elsewhere in the image turns the iteration band into a different color (that's what it looks like). Changing the main reference turns the whole image into one color. This is what it looks like after a few extra references and erased parts. In this case extra references turned things black and erasing turned things purple but it's not always those exact colors. (The black inside the julia set is a glitch.)


Could it be that other parts of the program changed, affecting examine zoom sequence without anyone noticing? I don't remember seeing this weird behavior that one time, a few years ago, when I used the examine zoom sequence tool to repair an actual zoom sequence.

[Kalles Fraktaler]

The size of the Eraser is the same as the rectangle you get from zooming by holding Control and clicking - Action->Zoom size

When opening the "examine" function, you choose a kfr file, where the location parameters are stored.
The program assumes that the this location is the exact location of the first kfb file, and the following kfb files are following from that.
The zoom size is calculated from the file names that are assumed to have the zoom depth after the underscore.

I am sorry this function is not more intuitive...

[Dinkydau]

Okay, about the rectangle size, that's good to know.

Then the conditions you mention are met, so I don't understand what's wrong. I wouldn't be surprised if only the fake zoom sequence wasn't working. It's just an experiment. But the zoom sequence I rendered using kalles fraktaler 2.11.1 itself is showing this weird behavior. The kfr file and the file names are generated by the program so they must be the correct format. I assume by choosing a kfr file, you mean the one that is saved by the program before rendering starts.

[Kalles Fraktaler]

Okay, about the rectangle size, that's good to know.

Then the conditions you mention are met, so I don't understand what's wrong. I wouldn't be surprised if only the fake zoom sequence wasn't working. It's just an experiment. But the zoom sequence I rendered using kalles fraktaler 2.11.1 itself is showing this weird behavior. The kfr file and the file names are generated by the program so they must be the correct format. I assume by choosing a kfr file, you mean the one that is saved by the program before rendering starts.

Yes, the one saved when the render starts, which have the exact location of the first kfb file...

[claude]

I fixed some bugs with the examine zoom sequence (thanks to Karl for the pointers) in the latest build, kf-2.12.1 at https://mathr.co.uk/kf/kf.html

I haven't tested the glitch correction/eraser though.

[Dinkydau]

Thanks. Correcting glitches with examine zoom sequence doesn't work on frames that aren't the last, but it does work on the last frame. That's enough for what I want to do right now. If all goes well I will post a new version without glitches when it's done. I don't think I still have the gradient so I will have do to my best to recreate it and it may turn out a little different.

[Dinkydau]

Here's a new version that should be completely free of glitches. I also changed the anti-aliasing algorithm to prevent some of the Moiré effects caused by the fine tilings (apparant only in the large version at deviantart: https://dinkydauset.deviantart.com/art/3rd-Order-Evolution-Of-Tilings-703026124).

Thanks a lot Claude and Kalles Fraktaler for the help.



For reference, this is the previous version with glitches:


Settings used for glitch correction:
48 terms
approximation low tolerance OFF like before (otherwise the correction would have taken as long as the whole render)

2 Extra references were required, and the glitches left by the first additional reference were detected. Also the small number of unfinished pixels left when I exported the map at 99% done were rendered, which makes the result exactly how I originally wanted it to be (notice that the new version is slightly wider).