I switched to a blogspot/blogger blog for two reasons. First, it is much easier to post images using Picassa and blogspot. Second, someone else has to deal with server issues.
This image is our first fully rendered terrain generated using our model of surface erosion that admits concave surfaces. It obviously needs some serious smoothing, but it looks more like a Goblin than our last one. (Algorithm: Matthew Beardall, translation to and mock-up in Bryce by Darius Ouderkirk)
This work was done as part of our BYU CS Capstone class on sandstone erosion modeling.
]]>[via Scientists dubious of quantum computer claims - CNN.com]
]]>
Matthew Beardall developed an erosion simulation algorithm which created the following hoodoo-like shape. If you look at it long enough, you can perhaps convince yourself that the algorithm is on the way to generating Goblin Valley Hoodoos (link goes to an image by Eve Andersson).
Those 43 images are part of a collection of about 1,200 images that we have recorded of Mt. Timpanogos over the past 6 months. Each image is paired with weather information for the preceding 36 hours. Ultimately, we will use this collection to learn how to recolor images based on weather conditions.
]]>I haven't bought a new MacBook Pro (or whatever they are called) because they don't make a 12 inch.
However, after reading Phil's article, I am glad I haven't. Another CS faculty is having similar problems with his MacBook.
I don't love OS X as much as Phil and the Dell Windows box I put on my office desk is working fine until the rumored MacBook Pro Slim 12 incher materializes (and I wait a while for the bugs to get worked out).
]]>The next technical challenge was importing from a self-made DLL (created in C++) in a C# application. I set it up and ran the program only to get "entry point not found." The problem was that the C++ compiler mangled the names of my functions. This feature (it's not a bug) was not well documented in the dll-import literature but I suppose I should have known it anyway. There are several ways to get around this.
The first is to enclose funtion headers and bodies in "extern "C"" blocks in the exporting C++ files. This prevents the names from being mangled. This is pretty straightforward.
The second is to use dumpbin.exe to examine function names in the dll. I found dumpbin.exe in C:\Program Files\Microsoft Visual Studio 8\VC\bin but needed to add the location of mspdb80.dll to my path environment variable (that's in Control Panel | System | Advanced) to get the thing to run. dumpbin.exe /Exports and not dumpbin.exe /symbols gave me what I wanted. After finding all that the C# import declarations ...
[DllImport ("mydll.dll", EntryPoint="#2")]
private static extern int myInt();
gave me what Iwanted because myInt was listed second with ordinal #2. Also,
[DllImport("dll-tests.dll", EntryPoint="?myInt@@YAHXZ")]
private static extern int myInt ();
did as well because that was the mangled form of my function name. And, just to bring this full circle, after I added some extern "C" blocks to my exporting C++ files, the import went down as...
[DllImport("dll-tests.dll")]
private static extern int myInt ();
Finally, don't forget to put the dll in the directory that houses your C# executable (or someone on your path).
Now that that's solved, on to exporting CGAL classes (or datastructure or just functions, we'll see) to C#. Our research goal is to use CGAL classes quickly in prototyping ideas. We'll worry about efficiency later.
]]>1. The __declspec(dllimport)int myInt(void); stuff has to appear (a) outside of enclosing namespaces (b) outside of class declarations because (a) putting it in a namespace will cause the linker to not find it and (b) you can't use __declspec (dllimport) within a managed class. The linker was dutifully telling me exactly that but it took me a while to figure out exactly what it meant.
2. You can list the libraries on which your stuff depends under... Project | Properties | Linker Input | Additional Dependencies. This would be where you list the .lib file that comes with your .dll file. It's just a simple text field that you type the name of your lib file into. That's a little odd, but the path will get worked out under the General item in the "Additional Library Directories" field where you do get to browse for a path.
3. The .dll needs to appear in the directory from which your project is executed. This was easy to figure out and solve, but bears mentioning.
4. The linker can be made to create verbose output under Linker | General | Show Progress and this output appears in the buildlog which can be linkto to from the output window (surprisingly). Just as an interesting datapoint: once I got the feedback loop closed by making the linker verbose, it took about 10 minutes to solve all the other problems. You can't fix what you can't see. True statement.
That's about it. Other than those little details, the C++ books, websites and MSFT documentation were all spot on. It may be clear at this point that I am somewhat clueless about VisualStudio as a project development tool. It's true. Although VS is much better than the Makefiles and command line tools that I know and "love", I still know how to do stuff in a Makefile and it takes time to figure out which sequence of mouse clicks are equivalent to 10 characters or less in a Makefile. Even worse, learning Makefiles is easy beacuse you just copy somebody else's. Learning VS click sequences is more painful because there's no flat text files to copy and modify.
]]>Natural Phenomena isn't a hugely hot research area in graphics right now. There's usually a paper in two in SIGGRAPH and there's a Natural Phenomena workshop held with Eurographics each year. I believe that while CGNP is hugely important in visual storytelling, the fundamental algorithms and assumptions haven't changed much in 10 years. Computing technology has come along way since 1996 and it's time to rethink and re-invent CGNP technology. So far, it's been a ton of fun too.
]]>Making a windows machine useful consists of the following:
I could either walk back upstairs and click "commit" before I get in my car. But that would require work.
I could put my windows boxen on public IPs but that would require extra work to keep them ultra-up-to-date and require installing some kind of access client.
So instead I wrote a little C# app that uses Tigris' command line SVN client to do an update, automatically. The problem has now been reduced to the problem of triggering the update. I could just schedule it as the windows' equivalent of a cron job, but that might cause a box to commit when I don't want it to.
So instead, I created a mail rule in Outlook 2007 that runs my command line commit program when it recieves mail with subject "cvn commit at [home|office]"
I was on a roll at that point, so I also wrote some code to send me the output of the commit operation using the Outlook interface in C#.
As a devout operating system agnostic, the appealing part of this project was that it combined the best of two worlds: I wrote my code in C# with a superb IDE (VS.net) and used a great open source tool (the svn client).
]]>1. Get some software. TortoiseCVS, putty.
2. Set up your key pairs. There are many tutorials on this, but the main catches here are: (a) puttygen can be found in C:\Program Files\TortoiseCVS\puttygen.exe (assuming you installed tortoiseCVS in the expected location). (b) Don't save the public key generated by puttygen in a file then scp it over to your server. The line breaks are all wrong. You should do a cut and paste job instead (that's why you downloaded putty.exe, tortoisecvs comes with an ssh client, but it was, um, inadequate). When it says "Public key for pasting into an OpenSSH authorized_keys file" it means it. (c) remember where you save your private key.
3. When you configure your server information for the first checkout, set the protocol to ext rather than ssh. This will simplify passing your private key file as a command line parameter.
4. After tortoiseCVS's reboot (also a good time to finish off those windows updates), right click a folder then select TortoiseCVS|Preferences. In the Tools pane, add the text -i c:\path\to\privatekey\privatekey.ppk to the SSH parameters.
5. That should do it.
]]>[Earth Observatory Newsroom: Blue Marble Next Generation Monthly Global Images]
]]>