- Forum
- General C++ Programming
- zooming into Koch fractal
zooming into Koch fractal
Hello friends, I have written a program which draws a Koch fractal. But it's very memory consuming. Each step of further depth level consumes four times more memory, hence I cannot render deeper than level 5. But that's sufficient for getting a resolution smaller than pixel size.
But I want to be able zooming in and therefore I need to render deeper levels, although I need to draw only some part of the fractal. But I have no idea how I could select the lines which would get to draw (or which lines I could discard).
Any ideas how I could tackle this?
But I want to be able zooming in and therefore I need to render deeper levels, although I need to draw only some part of the fractal. But I have no idea how I could select the lines which would get to draw (or which lines I could discard).
Any ideas how I could tackle this?
there are several ways you can do this.
one way is to just cheat (graphics programs often 'cheat' for efficiency).
a fractal zoomed in is the same as it was zoomed out, right? So you can just keep showing the same thing when they zoom in or out, drawing it once.
you can also try to figure out what exactly is burning your memory. If this is the snowflake, its like 5 points (2 values each) per level, and even multiplying it should take a while to burn up a gig or 2 of memory. its 4 line segments each becoming 4 and so on, right? so starting from the segment that is _A_ shaped, you have 4 segments. next is 16. Its 4^n... 4 to the 5 is only 1024, not even a megabyte of memory stored as points?
you can also store it as some sort of trimmable tree structure or something so that digging deeper on one branch drops the other branches. This is a fair bit of work, though ... I would attempt to reduce the footprint of your data so you can generate deeper levels first.
you might also zoom out to begin with. If 5 iterations is sub pixel, then you should make the original iteration zero line 10 times longer or something.
one way is to just cheat (graphics programs often 'cheat' for efficiency).
a fractal zoomed in is the same as it was zoomed out, right? So you can just keep showing the same thing when they zoom in or out, drawing it once.
you can also try to figure out what exactly is burning your memory. If this is the snowflake, its like 5 points (2 values each) per level, and even multiplying it should take a while to burn up a gig or 2 of memory. its 4 line segments each becoming 4 and so on, right? so starting from the segment that is _A_ shaped, you have 4 segments. next is 16. Its 4^n... 4 to the 5 is only 1024, not even a megabyte of memory stored as points?
you can also store it as some sort of trimmable tree structure or something so that digging deeper on one branch drops the other branches. This is a fair bit of work, though ... I would attempt to reduce the footprint of your data so you can generate deeper levels first.
you might also zoom out to begin with. If 5 iterations is sub pixel, then you should make the original iteration zero line 10 times longer or something.
Last edited on
| a fractal zoomed in is the same as it was zoomed out, right? |
Not all fractals, but this one is.
Let's say you have the normal Koch fractal (not full snowflake).
_ --> _/\_
As jonnin said, 4^5 is only 1024....
start with 1
iteration 1: 4
iteration 2: 4 * 4 = 16
iteration 3: 16 * 4 = 64
iteration 4: 64 * 4 = 256
iteration 5: 256 * 4 = 1024
That really, really shouldn't take up that much memory. That being said, it is exponential growth, so you do have to be careful with the number of iterations. Are you using the stack or the heap? For any significant amount of data, be sure to use the heap to avoid stack overflow.
But, as far as your problem of "let's try to limit the number of lines drawn".
Let's say you have each line. Each line needs to store at least its starting (x, y) position so that we know about where it is. If we have a vector (or other container) of these lines, we can "trim" off the lines that go well beyond the border of what you're rendering.
_ --> _/\_
As jonnin said, 4^5 is only 1024....
start with 1
iteration 1: 4
iteration 2: 4 * 4 = 16
iteration 3: 16 * 4 = 64
iteration 4: 64 * 4 = 256
iteration 5: 256 * 4 = 1024
That really, really shouldn't take up that much memory. That being said, it is exponential growth, so you do have to be careful with the number of iterations. Are you using the stack or the heap? For any significant amount of data, be sure to use the heap to avoid stack overflow.
But, as far as your problem of "let's try to limit the number of lines drawn".
Let's say you have each line. Each line needs to store at least its starting (x, y) position so that we know about where it is. If we have a vector (or other container) of these lines, we can "trim" off the lines that go well beyond the border of what you're rendering.
Topic archived. No new replies allowed.