ecordell
version of c++
Evan,
I could get the 2010 version of MS visual c++. When I build it I get: 1>------ Build started: Project: ChaosTools, Configuration: Release Win32 ------ 1> ChaosToolsApp.cpp 1>c:\wx29\include\wx/platform.h(247): fatal error C1083: Cannot open include file: 'wx/setup.h': No such file or directory 1> ChaosToolsFrm.cpp 1>c:\wx29\include\wx/platform.h(247): fatal error C1083: Cannot open include file: 'wx/setup.h': No such file or directory 1> gradient.cpp 1>c:\wx29\include\wx/platform.h(247): fatal error C1083: Cannot open include file: 'wx/setup.h': No such file or directory 1> gradientdlg.cpp 1>c:\wx29\include\wx/platform.h(247): fatal error C1083: Cannot open include file: 'wx/setup.h': No such file or directory 1> JuliaThread.cpp 1>c:\wx29\include\wx/platform.h(247): fatal error C1083: Cannot open include file: 'wx/setup.h': No such file or directory 1> MandelThread.cpp 1>c:\wx29\include\wx/platform.h(247): fatal error C1083: Cannot open include file: 'wx/setup.h': No such file or directory 1> optionsdlg.cpp 1>c:\wx29\include\wx/platform.h(247): fatal error C1083: Cannot open include file: 'wx/setup.h': No such file or directory ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
I looked in the indicated directory and did not find the setup.h file either.
I found a "setup.h" in the msw directory
Suggestions?
David Andersen
Did you install and build wxwidgets?
Open wx.dsw (it should be in C:/wx29 or some subdirectory thereof) and select Build > Batch Build. Select the Debug and Release versions of all of the projects, and then build them.
Evan,
I downloaded the application: wxMSW-2.9.0-Setup. I ran the application and it installed into c:wxWidgets-2.9.0. There is no file named wx.dsw in any of its subdirectories.
David Andersen
On Thu, May 24, 2012 at 10:56 AM, ecordell < [email protected]
wrote:
Did you install and build wxwidgets?
Open wx.dsw (it should be in C:/wx29 or some subdirectory thereof) and select Build > Batch Build. Select the Debug and Release versions of all of the projects, and then build them.
Reply to this email directly or view it on GitHub: https://github.com/ecordell/chaostools/issues/2#issuecomment-5910080
David Andersen LSMSA Math/Computer Science 318-357-2533
[image: Inline image 1]
On Thu, May 24, 2012 at 2:12 PM, David Andersen [email protected] wrote:
Evan,
I downloaded the application: wxMSW-2.9.0-Setup. I ran the application and it installed into c:wxWidgets-2.9.0. There is no file named wx.dsw in any of its subdirectories.
David Andersen
On Thu, May 24, 2012 at 10:56 AM, ecordell < [email protected]
wrote:
Did you install and build wxwidgets?
Open wx.dsw (it should be in C:/wx29 or some subdirectory thereof) and select Build > Batch Build. Select the Debug and Release versions of all of the projects, and then build them.
Reply to this email directly or view it on GitHub: https://github.com/ecordell/chaostools/issues/2#issuecomment-5910080
David Andersen LSMSA Math/Computer Science 318-357-2533
David Andersen LSMSA Math/Computer Science 318-357-2533
Ok, Evan, I don't know what I am doing wrong. I decided to remove what I had and start over. After I start git bash, mk dir chaostools, cd chaostools, then type... git remote add origin [email protected]:ecordell/chaostools.git I just get the prompt back. Then I type, git pull origin master Now I get the message permission denied (public key) Fatal: the remote end hung up unexpectedly If I try, git clone [email protected]:ecordell/chaostools.git It first says it is initializing the repository, then gives the same permission denied message. What am I doing wrong?
Sorry for the delay.
A couple of things:
- Install wxWidgets into C:/wx29. You can install it elsewhere, but then you have to change all of the project files to something else. There is a detailed guide here, but basically you need to open the wx project file, and "batch build" all of the debug and release versions of all of the different wxWidgets components.
- mkdir chaostools, cd chaostools, and then
git clone git://github.com/ecordell/chaostools.git. The instructions in the readme were slightly wrong, I apologize.
Evan,
I still don't know how to build wxWidgets. I havn't found the wx.dsw file. The details are on github in issue #2. Maybe if I just download the chaos tools zipped files to my computer and get wxWidgets to build I could get it to compile. I could really use the help. Is there a time when I could call you? I've
still got your number. I'm at LSU now.
David Andersen LSMSA Math/Computer Science 318-357-2533
Evan,
First, the "git clone" command you sent did the trick for the chaos tools. I did install wxWidgets into the c:/wx29 directory, but I still am unsure what you mean by "batch build". I'm looking in the detailed guide to see if I can figure it out. I'll let you know.
Don't apologize! I appreciate all your help and hope I'm not bugging you too much.
By the way. Did the special projects app get finished?
David Andersen
On Mon, May 28, 2012 at 6:30 PM, ecordell < [email protected]
wrote:
Sorry for the delay.
A couple of things:
- Install wxWidgets into C:/wx29. You can install it elsewhere, but then you have to change all of the project files to something else. There is a detailed guide here, but basically you need to open the wx project file, and "batch build" all of the debug and release versions of all of the different wxWidgets components.
- mkdir chaostools, cd chaostools, and then
git clone git:// github.com/ecordell/chaostools.git. The instructions in the readme were slightly wrong, I apologize.
Reply to this email directly or view it on GitHub: https://github.com/ecordell/chaostools/issues/2#issuecomment-5973490
David Andersen LSMSA Math/Computer Science 318-357-2533
Evan,
Well, I opened c:\wx29\build\wx_v9.dsw with msvc++2010 express. I found where the Debug and Release are chosen. But I don't know how to set the MTd and MT options. Also when I tried to build them I got 15 failed. I noticed the documentation said keep building until the failed is zero, but I still need MTd and MT don't I?
David Andersen
Sorry, it's hard for me to know what the problem is since I don't have access to a windows machine right now. I'll update in a couple of days once I get my old laptop up and running and let you know.
All I remember is the MTd and MT are in the project settings somewhere, but I don't remember the specifics.
Evan,
At this point I am still learning CUDA programming and will try to write some simple programs to update memory on the GPU. But, eventually I want to get into the Chaos Tools code and see where I might be able to employ the "parallel programming" ideas that I'm practicing. So if you have the time to help me figure out what the process is to compile the source code, I would greatly appreciate it. I am using the NVidia compiler, NVCC, on a linux Redhat system which seems to be similar to using GCC. I don't know if that will make it easier for you or not.
Thanks for all your help. PS: Is our application from Special Projects going to be available?
David Andersen
On Mon, Jun 4, 2012 at 2:43 PM, ecordell < [email protected]
wrote:
Sorry, it's hard for me to know what the problem is since I don't have access to a windows machine right now. I'll update in a couple of days once I get my old laptop up and running and let you know.
All I remember is the MTd and MT are in the project settings somewhere, but I don't remember the specifics.
Reply to this email directly or view it on GitHub: https://github.com/ecordell/chaostools/issues/2#issuecomment-6108385
David Andersen LSMSA Math/Computer Science 318-357-2533
Evan,
I'm making progress on my own version of deep zooms into the Mandelbrot
Set. How were you choosing your points for the zooming?
David Andersen LSMSA Math/Computer Science 318-357-2533
Evan,
I have the code done for creating a screen for the Mandelbrot set. Now I need to zoom in, keeping the aspect ratio the same, and improving the precision so I can still have points between the max and min screen edges. Do you recall what you did?
David Andersen LSMSA Math/Computer Science 318-357-2533
Sorry I've been so unresponsive, I've been working and travelling a lot.
I found a picture showing where the MT settings are here.
I actually had several "versions" of this app that I would use for different things (they were only for mandelbrot zooming).
One let me drag a rectangle and zoom into it, like you can in ChaosTools. I also had it set up so that I could right click on any point, and it would write the (complex, not screen) coordinates to a file for me; these get so long as you zoom in that just displaying them on the screen wasn't feasible. So that's how I found interesting places to zoom to: I'd drag a square and wait, which could take days as you get deeper and deeper (but then, I only had 4 cores.)
I used the GNU Multiprecision Bignum Library to get higher precision numbers. I ended up using their floating point numbers so I wouldn't have to change my algorithms, even though it'd be faster with ints. I never exactly worked out if you could increase the precision of those datatypes after runtime, so I would basically decide how many decimal places I wanted and then calculate how many bits that would take, add a few more to be safe, and then initialize the GMP numbers with a mantissa large enough to hold them.
As for keeping aspect ratio: I basically forced it to fill up to a 4:3 aspect no matter what you selected. Relevant code with added comments (from ChaosToolsFrm.cpp):
//temporary variables for holding minimum and maximum xy values
double tmanxmin, tmanxmax, tmanymin, tmanymax;
//these functions convert screen coordinates to complex (cartesian) coordinates. event refers to the mouse position.
tmanxmin = toMandelMathX((manxstart<event.GetX()) ? manxstart : event.GetX());
tmanxmax = toMandelMathX((event.GetX()>manxstart) ? event.GetX() : manxstart);
tmanymin = toMandelMathY((event.GetY()>manystart) ? event.GetY() : manystart);
tmanymax = toMandelMathY((manystart<event.GetY()) ? manystart : event.GetY());
//these are the mathematical distances between pixels
double dx = (tmanxmax-tmanxmin)/(plotMandelArea->GetSize().GetWidth());
double dy = (tmanymax-tmanymin)/(plotMandelArea->GetSize().GetHeight());
//this is where we force the aspect ratio to be the same
//we keep adding (or subtracting) dx and dy (1 pixel) to the length and height until the ratio is 4:3
if((tmanxmax-tmanxmin)/(tmanymax-tmanymin) < 4/3)
while((tmanxmax-tmanxmin)/(tmanymax-tmanymin) < 4/3)
if(tmanymax-tmanymin>tmanxmax-tmanxmin)
tmanxmax+=dx;
else
tmanymax+=dy;
else
while((tmanxmax-tmanxmin)/(tmanymax-tmanymin) > 4/3)
if(tmanymax-tmanymin>tmanxmax-tmanxmin)
tmanymax-=dx;
else
tmanxmax-=dy;
//now we store the temporary variables into the variables that define the left, top, right, and bottom of the viewable screen.
manxmin = tmanxmin;
manxmax = tmanxmax;
manymin = tmanymin;
manymax = tmanymax;
Hope that helps :)
Evan,
Thanks for taking time to respond. Sorry to interrupt you holiday, but I'm at LSU working on this since driving back to Natchitoches for one day is not too inviting.
David Andersen
On Wed, Jul 4, 2012 at 10:48 AM, ecordell < [email protected]
wrote:
Sorry I've been so unresponsive, I've been working and travelling a lot.
I found a picture showing where the MT settings are here.
I actually had several "versions" of this app that I would use for different things (they were only for mandelbrot zooming).
One let me drag a rectangle and zoom into it, like you can in ChaosTools. I also had it set up so that I could right click on any point, and it would write the (complex, not screen) coordinates to a file for me; these get so long as you zoom in that just displaying them on the screen wasn't feasible. So that's how I found interesting places to zoom to: I'd drag a square and wait, which could take days as you get deeper and deeper (but then, I only had 4 cores.)
I used the GNU Multiprecision Bignum Library to get higher precision numbers. I ended up using their floating point numbers so I wouldn't have to change my algorithms, even though it'd be faster with ints. I never exactly worked out if you could increase the precision of those datatypes after runtime, so I would basically decide how many decimal places I wanted and then calculate how many bits that would take, add a few more to be safe, and then initialize the GMP numbers with a mantissa large enough to hold them.
As for keeping aspect ratio: I basically forced it to fill up to a 4:3 aspect no matter what you selected. Relevant code with added comments (from ChaosToolsFrm.cpp):
//temporary variables for holding minimum and maximum xy values double tmanxmin, tmanxmax, tmanymin, tmanymax; //these functions convert screen coordinates to complex (cartesian) coordinates. event refers to the mouse position. tmanxmin = toMandelMathX((manxstart<event.GetX()) ? manxstart : event.GetX()); tmanxmax = toMandelMathX((event.GetX()>manxstart) ? event.GetX() : manxstart); tmanymin = toMandelMathY((event.GetY()>manystart) ? event.GetY() : manystart); tmanymax = toMandelMathY((manystart<event.GetY()) ? manystart : event.GetY()); //these are the mathematical distances between pixels double dx = (tmanxmax-tmanxmin)/(plotMandelArea->GetSize().GetWidth()); double dy = (tmanymax-tmanymin)/(plotMandelArea->GetSize().GetHeight()); //this is where we force the aspect ratio to be the same //we keep adding (or subtracting) dx and dy (1 pixel) to the length and height until the ratio is 4:3 if((tmanxmax-tmanxmin)/(tmanymax-tmanymin) < 4/3) while((tmanxmax-tmanxmin)/(tmanymax-tmanymin) < 4/3) if(tmanymax-tmanymin>tmanxmax-tmanxmin) tmanxmax+=dx; else tmanymax+=dy; else while((tmanxmax-tmanxmin)/(tmanymax-tmanymin) > 4/3) if(tmanymax-tmanymin>tmanxmax-tmanxmin) tmanymax-=dx; else tmanxmax-=dy; //now we store the temporary variables into the variables that define the left, top, right, and bottom of the viewable screen. manxmin = tmanxmin; manxmax = tmanxmax; manymin = tmanymin; manymax = tmanymax;Hope that helps :)
Reply to this email directly or view it on GitHub: https://github.com/ecordell/chaostools/issues/2#issuecomment-6763027
David Andersen LSMSA Math/Computer Science 318-357-2533
Another question. Here at LSU, the only windows we use are to see it it's raining. Everything is Linux. What are the steps, if you have them, to compile this with gcc or nvcc?
David Andersen
On Wed, Jul 4, 2012 at 12:40 PM, David Andersen [email protected] wrote:
Evan,
Thanks for taking time to respond. Sorry to interrupt you holiday, but I'm at LSU working on this since driving back to Natchitoches for one day is not too inviting.
David Andersen
On Wed, Jul 4, 2012 at 10:48 AM, ecordell < [email protected]
wrote:
Sorry I've been so unresponsive, I've been working and travelling a lot.
I found a picture showing where the MT settings are here.
I actually had several "versions" of this app that I would use for different things (they were only for mandelbrot zooming).
One let me drag a rectangle and zoom into it, like you can in ChaosTools. I also had it set up so that I could right click on any point, and it would write the (complex, not screen) coordinates to a file for me; these get so long as you zoom in that just displaying them on the screen wasn't feasible. So that's how I found interesting places to zoom to: I'd drag a square and wait, which could take days as you get deeper and deeper (but then, I only had 4 cores.)
I used the GNU Multiprecision Bignum Library to get higher precision numbers. I ended up using their floating point numbers so I wouldn't have to change my algorithms, even though it'd be faster with ints. I never exactly worked out if you could increase the precision of those datatypes after runtime, so I would basically decide how many decimal places I wanted and then calculate how many bits that would take, add a few more to be safe, and then initialize the GMP numbers with a mantissa large enough to hold them.
As for keeping aspect ratio: I basically forced it to fill up to a 4:3 aspect no matter what you selected. Relevant code with added comments (from ChaosToolsFrm.cpp):
//temporary variables for holding minimum and maximum xy values double tmanxmin, tmanxmax, tmanymin, tmanymax; //these functions convert screen coordinates to complex (cartesian) coordinates. event refers to the mouse position. tmanxmin = toMandelMathX((manxstart<event.GetX()) ? manxstart : event.GetX()); tmanxmax = toMandelMathX((event.GetX()>manxstart) ? event.GetX() : manxstart); tmanymin = toMandelMathY((event.GetY()>manystart) ? event.GetY() : manystart); tmanymax = toMandelMathY((manystart<event.GetY()) ? manystart : event.GetY()); //these are the mathematical distances between pixels double dx = (tmanxmax-tmanxmin)/(plotMandelArea->GetSize().GetWidth()); double dy = (tmanymax-tmanymin)/(plotMandelArea->GetSize().GetHeight()); //this is where we force the aspect ratio to be the same //we keep adding (or subtracting) dx and dy (1 pixel) to the length and height until the ratio is 4:3 if((tmanxmax-tmanxmin)/(tmanymax-tmanymin) < 4/3) while((tmanxmax-tmanxmin)/(tmanymax-tmanymin) < 4/3) if(tmanymax-tmanymin>tmanxmax-tmanxmin) tmanxmax+=dx; else tmanymax+=dy; else while((tmanxmax-tmanxmin)/(tmanymax-tmanymin) > 4/3) if(tmanymax-tmanymin>tmanxmax-tmanxmin) tmanymax-=dx; else tmanxmax-=dy; //now we store the temporary variables into the variables that define the left, top, right, and bottom of the viewable screen. manxmin = tmanxmin; manxmax = tmanxmax; manymin = tmanymin; manymax = tmanymax;Hope that helps :)
Reply to this email directly or view it on GitHub: https://github.com/ecordell/chaostools/issues/2#issuecomment-6763027
David Andersen LSMSA Math/Computer Science 318-357-2533
David Andersen LSMSA Math/Computer Science 318-357-2533
Another (Another) question,
How did you zoom? What did you use to "reduce" the window so that your images made a smooth transition? Mine are too fast or too slow or jump.
David Andersen
On Wed, Jul 4, 2012 at 12:45 PM, David Andersen [email protected] wrote:
Another question. Here at LSU, the only windows we use are to see it it's raining. Everything is Linux. What are the steps, if you have them, to compile this with gcc or nvcc?
David Andersen
On Wed, Jul 4, 2012 at 12:40 PM, David Andersen [email protected]:
Evan,
Thanks for taking time to respond. Sorry to interrupt you holiday, but I'm at LSU working on this since driving back to Natchitoches for one day is not too inviting.
David Andersen
On Wed, Jul 4, 2012 at 10:48 AM, ecordell < [email protected]
wrote:
Sorry I've been so unresponsive, I've been working and travelling a lot.
I found a picture showing where the MT settings are here.
I actually had several "versions" of this app that I would use for different things (they were only for mandelbrot zooming).
One let me drag a rectangle and zoom into it, like you can in ChaosTools. I also had it set up so that I could right click on any point, and it would write the (complex, not screen) coordinates to a file for me; these get so long as you zoom in that just displaying them on the screen wasn't feasible. So that's how I found interesting places to zoom to: I'd drag a square and wait, which could take days as you get deeper and deeper (but then, I only had 4 cores.)
I used the GNU Multiprecision Bignum Library to get higher precision numbers. I ended up using their floating point numbers so I wouldn't have to change my algorithms, even though it'd be faster with ints. I never exactly worked out if you could increase the precision of those datatypes after runtime, so I would basically decide how many decimal places I wanted and then calculate how many bits that would take, add a few more to be safe, and then initialize the GMP numbers with a mantissa large enough to hold them.
As for keeping aspect ratio: I basically forced it to fill up to a 4:3 aspect no matter what you selected. Relevant code with added comments (from ChaosToolsFrm.cpp):
//temporary variables for holding minimum and maximum xy values double tmanxmin, tmanxmax, tmanymin, tmanymax; //these functions convert screen coordinates to complex (cartesian) coordinates. event refers to the mouse position. tmanxmin = toMandelMathX((manxstart<event.GetX()) ? manxstart : event.GetX()); tmanxmax = toMandelMathX((event.GetX()>manxstart) ? event.GetX() : manxstart); tmanymin = toMandelMathY((event.GetY()>manystart) ? event.GetY() : manystart); tmanymax = toMandelMathY((manystart<event.GetY()) ? manystart : event.GetY()); //these are the mathematical distances between pixels double dx = (tmanxmax-tmanxmin)/(plotMandelArea->GetSize().GetWidth()); double dy = (tmanymax-tmanymin)/(plotMandelArea->GetSize().GetHeight()); //this is where we force the aspect ratio to be the same //we keep adding (or subtracting) dx and dy (1 pixel) to the length and height until the ratio is 4:3 if((tmanxmax-tmanxmin)/(tmanymax-tmanymin) < 4/3) while((tmanxmax-tmanxmin)/(tmanymax-tmanymin) < 4/3) if(tmanymax-tmanymin>tmanxmax-tmanxmin) tmanxmax+=dx; else tmanymax+=dy; else while((tmanxmax-tmanxmin)/(tmanymax-tmanymin) > 4/3) if(tmanymax-tmanymin>tmanxmax-tmanxmin) tmanymax-=dx; else tmanxmax-=dy; //now we store the temporary variables into the variables that define the left, top, right, and bottom of the viewable screen. manxmin = tmanxmin; manxmax = tmanxmax; manymin = tmanymin; manymax = tmanymax;Hope that helps :)
Reply to this email directly or view it on GitHub: https://github.com/ecordell/chaostools/issues/2#issuecomment-6763027
David Andersen LSMSA Math/Computer Science 318-357-2533
David Andersen LSMSA Math/Computer Science 318-357-2533
David Andersen LSMSA Math/Computer Science 318-357-2533
Ah, I don't actually have an easy way to compile this with gcc. I can work on getting the commands to you, though. I used wxDevC++ (which I think is windows only) as a front-end to gcc and it generated the very long compile commands for me. If you look at the readme, it's on my todo to make a bakefile for this (bakefiles can generate makefiles for tons of different compilers).
Zooming: Each image was defined by the mathematical coordinates of the viewing window. So I had a top, bottom, left, and right value for any given image. The algorithm calculates the cartesian difference between two pixels in the x direction (dx) and y direction (dy). Then I start at the upper left corner of the image, iterate and draw the pixel, and then add dx to that point's x coordinate, all the way across the screen, and then dy when I moved to the next line.
So zooming becomes an issue of figuring out how much to change "the box" for each frame. The simplest way is to subtract dx from the left and right sides, and subtract dy from the top and bottom sides. This contracts the viewing window by 1 pixel and you can get the next frame. This is what I did for all of the videos I made while at lsmsa. (I saved them as .png files and combined them later)
This is not the most efficient thing to do, because the image changes almost imperceptibly with only 1 pixel of difference on each side. In fractal circles online, it's pretty accepted to create several keyframes, and then interpolate between them. Videos made like this are considered "less pure" in some sense, which is why I never bothered with it ;) It's the only good way to get very deep, very fast, though.
I also supersampled them by three, so I would make images three times the size of the video that I wanted, and then sample it down the size I wanted (there are several algorithms but I just wrote a script that used photoshop since that was easier/faster, and photoshops sampling algo is really good). This can remove graininess and make the images antialiased, which isn't possible when you're building the image to begin with.
Also, if you're looking for good points to zoom to for testing, there's always (-2, 0) and (0,1) and (0,-1) - those are all fixed points so you're guaranteed there's always something interesting on the screen. That's how I found out that my aspect ratio was changing over time, for example. (It's harder to tell if you're zooming somewhere that you don't know).
I've been on/off in contact with a guy in texas who does a lot of really good work, his website is HPDZ. He documents everything he does really, really well, so you might find the technical pages interesting.
Evan,
Thanks again for your quick response. The following is just so you know how I'm calculating the Mandelbrot set using CUDA. It's no longer one pixel at a time. I take a 1920 by 1080 grid of threads on the GPU (one thread for each pixel) and with a call to the "kernel" calculate the number of iterations for each pixel all at once. I then write those iteration counts to a text file. I have attached a file of a 16 by 16 grid as an example (hope it doesn't come out as one line). I want to eventually use that to draw the screen in "real time", but now I send that file to gnuplot and create a .jpg. Finally, I take the list of files and combine them with ffmpeg. It seems to work ok, but I need to come up with an algorithm to reduce the size of the window but still use the 1920 by 1080 threads to color the pixels. I have created 1000 images at a time (takes about 13 minutes), but they have not zoomed in enough or have collapsed to a point or a line with the methods I've used so far. Does this make sense?
Any thoughts will be appreciated, David Andersen
On Wed, Jul 4, 2012 at 7:06 PM, ecordell < [email protected]
wrote:
Ah, I don't actually have an easy way to compile this with gcc. I can work on getting the commands to you, though. I used wxDevC++ (which I think is windows only) as a front-end to gcc and it generated the very long compile commands for me. If you look at the readme, it's on my todo to make a bakefile for this (bakefiles can generate makefiles for tons of different compilers).
Zooming: Each image was defined by the mathematical coordinates of the viewing window. So I had a top, bottom, left, and right value for any given image. The algorithm calculates the cartesian difference between two pixels in the x direction (dx) and y direction (dy). Then I start at the upper left corner of the image, iterate and draw the pixel, and then add dx to that point's x coordinate, all the way across the screen, and then dy when I moved to the next line.
So zooming becomes an issue of figuring out how much to change "the box" for each frame. The simplest way is to subtract dx from the left and right sides, and subtract dy from the top and bottom sides. This contracts the viewing window by 1 pixel and you can get the next frame. This is what I did for all of the videos I made while at lsmsa. (I saved them as .png files and combined them later)
This is not the most efficient thing to do, because the image changes almost imperceptibly with only 1 pixel of difference on each side. In fractal circles online, it's pretty accepted to create several keyframes, and then interpolate between them. Videos made like this are considered "less pure" in some sense, which is why I never bothered with it ;) It's the only good way to get very deep, very fast, though.
I also supersampled them by three, so I would make images three times the size of the video that I wanted, and then sample it down the size I wanted (there are several algorithms but I just wrote a script that used photoshop since that was easier/faster, and photoshops sampling algo is really good). This can remove graininess and make the images antialiased, which isn't possible when you're building the image to begin with.
Also, if you're looking for good points to zoom to for testing, there's always (-2, 0) and (0,1) and (0,-1) - those are all fixed points so you're guaranteed there's always something interesting on the screen. That's how I found out that my aspect ratio was changing over time, for example. (It's harder to tell if you're zooming somewhere that you don't know).
I've been on/off in contact with a guy in texas who does a lot of really good work, his website is HPDZ. He documents everything he does really, really well, so you might find the technical pages interesting.
Reply to this email directly or view it on GitHub: https://github.com/ecordell/chaostools/issues/2#issuecomment-6769616
David Andersen LSMSA Math/Computer Science 318-357-2533
Sorry again for the delay. I don't see an attachment (when you reply to the email it posts to github, and I guess drops the attachment?)
I've never used CUDA so I may be missing some important point about how this is implemented, but what I outlined above should work for zooming. A lot of the following is pretty basic and I'm sure you know it, but I'm not sure where we're misunderstanding each other so I'll write it out and maybe you can tell me:
If you have 1920*1080 threads calculating iteration counts, one for each pixel, then presumably you have some way to tell each thread which parameter to use (by that I mean the "c" in "x^2 + c") when iterating? And I assume those c-values are calculated before the threads are all sent to the GPU for processing?
If those assumptions are correct, then you must have a way of specifying the "viewing window" mathematically, i.e. the upper left corner is -2+i, the upper right is 1+i, and so forth. (I imagine you're probably using cartesian coordinates and you have an x and y value for each pixel?) So let's say the window is defined by a 4-tuple - to start with it would be (-2+i, 1+i, 1-i, -2-i). Once you have the mathematical values for each pixel in cartesian coordinates, then taking difference between those values in the x and y directions will give you two values, dx and dy. Then for your next frame, you simply change the coordinates of the viewing window and make it ((-2 + dx) + (1 - dy)i, (1 - dx) + (1 - dy)i, (1 - dx) + (-1 + dy)i, (-2 + dx) + (-1 + dy)i)
Is that helpful? I'm not entirely sure I understand the question.
Evan,
That's what I'm doing (I'm glad you confirmed it). But the "zoom rate" is very slow with this one pixel at a time zooming, so I multiplied the dx and dy by 10. The GPU uses single precision variables, so until I figure out how to use a different type I may not zoom in too far.
Any thoughts can be helpful. Thanks, David Andersen
On Sat, Jul 14, 2012 at 12:30 PM, ecordell < [email protected]
wrote:
Sorry again for the delay. I don't see an attachment (when you reply to the email it posts to github, and I guess drops the attachment?)
I've never used CUDA so I may be missing some important point about how this is implemented, but what I outlined above should work for zooming. A lot of the following is pretty basic and I'm sure you know it, but I'm not sure where we're misunderstanding each other so I'll write it out and maybe you can tell me:
If you have 1920*1080 threads calculating iteration counts, one for each pixel, then presumably you have some way to tell each thread which parameter to use (by that I mean the "c" in "x^2 + c") when iterating? And I assume those c-values are calculated before the threads are all sent to the GPU for processing?
If those assumptions are correct, then you must have a way of specifying the "viewing window" mathematically, i.e. the upper left corner is -2+i, the upper right is 1+i, and so forth. (I imagine you're probably using cartesian coordinates and you have an x and y value for each pixel?) So let's say the window is defined by a 4-tuple - to start with it would be
(-2+i, 1+i, 1-i, -2-i). Once you have the mathematical values for each pixel in cartesian coordinates, then taking difference between those values in the x and y directions will give you two values, dx and dy. Then for your next frame, you simply change the coordinates of the viewing window and make it((-2 + dx) + (1 - dy)i, (1 - dx) + (1 - dy)i, (1 - dx) + (-1 + dy)i, (-2 + dx) + (-1 + dy)i)Is that helpful? I'm not entirely sure I understand the question.
Reply to this email directly or view it on GitHub: https://github.com/ecordell/chaostools/issues/2#issuecomment-6984883
David Andersen LSMSA Math/Computer Science 318-357-2533
Evan,
First, I have attached a file ths time. The last time it was returned for being too large so I have sent a smaller version. It is a text file with a gnuplot script at the beginning (that's how I turn the data into a jpeg). You can see the Mandelbrot set where the higher iterations are. There would at least be a matrix of 1280 x 800 values in the file, not 16 x 16.
On the workstation I am using, Cuda does only single precision floating point math. My window collapses to a point at seven decimal places. You were able to zoom into about 10^-70 th? What number class did you find to perform the arithmetic for the "deep
zooms"?
David Andersen LSMSA Math/Computer Science 318-357-2533
Ah, okay. Yeah, single precision won't get you very far.
I used GMP, the GNU Multiprecision Library, which comes with mpf, a multi-precision floating point data type.
I don't know if it can run on a GPU. It's written in plain C but there are assembly-optimized subroutines for pretty much every major processor so it's quite fast. If you have a way to run C on the GPU then you can use library without any optimizations, but it's really quite slow at that point.
I did find CUMP, though, a similar project aimed at CUDA. Perhaps that will work?
Evan,
Thanks so much. I have been able to use double precision so I'm going further, but it has some problems too. I have been looking for something like CUMP. How do you find this stuff?
Was there an algorithm you used to determine the "correct" number of iterations at each zoom?
David Andersen
On Tue, Jul 17, 2012 at 7:38 PM, ecordell < [email protected]
wrote:
Ah, okay. Yeah, single precision won't get you very far.
I used GMP, the GNU Multiprecision Library, which comes with mpf, a multi-precision floating point data type.
I don't know if it can run on a GPU. It's written in plain C but there are assembly-optimized subroutines for pretty much every major processor so it's quite fast. If you have a way to run C on the GPU then you can use library without any optimizations, but it's really quite slow at that point.
I did find CUMP, though, a similar project aimed at CUDA. Perhaps that will work?
Reply to this email directly or view it on GitHub: https://github.com/ecordell/chaostools/issues/2#issuecomment-7053786
David Andersen LSMSA Math/Computer Science 318-357-2533
I just googled around :) I think I searched for "gmp cuda"
There are two ongoing research interests of mine that I've never managed to come back to: how many iterations does it take to make a "good enough" image at a given level of zoom, and is there an algorithm to find "baby mandels" at a given zoom level.
The first I haven't made any headway on...when I was at lsmsa, I started doing some experiments by making a bunch of frames of the same image of the mandelbrot set but at different iteration counts. Then I compared them pixel-by-pixel to each other and plotted number of iterations vs. number of pixel differences...the graphs were interesting (sort of roughly exponential decay) but didn't end up leading to anything useful. In the end I'm not sure it's possible, because for any given mandelbrot image, the number of iterations required depends on the "amount" of the edge of the set that's in the frame.
I never found a good way to find baby mandels either (the tiny copies of the mandelbrot set) but I did find a paper online that had an interesting algorithm for finding baby mandels on the x-axis.