(Video link below.)
The attached project file opens like this:
I'm liking the self-contained projects; they have a short learning curve, and once I understood that saving a JSL file (gray disk icon, 5th from left at top) saves in the temporary location where the project opened, NOT in the project's archive file, everything made sense. The other odd-looking icon, 4th from the left, saves any unsaved JSL files to the temporary location, then rebuilds/saves the project archive. The project has its own namespace; nothing leaks out that I've noticed. I've docked the project's log window on the right.
If you decide to peek at the project, or try to run it, here's an overview of how I used it. First, the Rain Drop Manager builds a huge table of (300 rows per picture times 32768 pictures) rows. This is done in a few hours and has to be done sequentially because it tracks the location of 300 raindrops from frame to frame. Second, the Number Server is started. It opens a GUI window in another tab to manage a farm of Linux machines. The Number Server is actually mostly a Python program that runs a webserver that makes sure each farm machine works on a different picture in the sequence. Third, the GUI launches the farm processes to create the picture using the JSL in Generate Images.
It is a fairly complicated setup but turned out pretty robust. It ran to completion at least three times, about 55 wall-clock hours each time. What turned out to work well: don't use NFS, instead use the windows shared folders. Run Windows in VirtualBox; use VBoxManage to start and stop Windows. Use the Windows startup directory to start JMP(s). Thing I'd add to the GUI if I was going to run it again: a "blue" state to indicate a worker has finished and shutdown.
The distribution of work across the machines in the farm after 55 hours:
The counts represent the number of images each machine created. Each time a machine finishes an image, it asks the Number Server what image it should work on next. Because the raindrop positions are precomputed, and the zoom level is determined by the image number, all the workers in the farm are able to work independently, shoving completed images into a shared folder where they get sorted by their names when the video is assembled. The code is currently set up to make the images in reversed-bit order, generating the middle image, then the 1/4 images, then the 1/8 images ... in the sequence. At the 27 hour mark, every other image has been made, making it easy to see an overview. (Sadly, the problem that required a 3rd 55 hour run could only be seen on adjacent images...sometimes...flickering raindrops!)
I uploaded a 4K 60FPS video. My hardware lets me use either 4K 30FPS or 2K 60FPS, so I've never seen the both at once. If you choose only one, pick 60FPS, it's buttery-smooth.
Remove the .zip extension after downloading and JMP 16 will open it. It will need lots of tweaking to make it work.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.