I just finished working on a MySQL connection tester and configurator for BlenderPeople. The way it works is this: when you run BP, it checks to see if it has MySQL connection info stored. If not, it launches a little GUI that lets you put in host IP addresses, usernames and passwords, then tests the connection for you. Most of the people who had MySQL issues were having simple connectivity problems. This should make that easier to correct.
Anyway, after you get a successful connection, BP stores that particular info and uses it the next time you have a session.
I also added support for the Blender progress bar when running turns. I had done this originally, but something (I suspect a bPython bug) made things run significantly slower when using the progress bar. Not anymore. It updates on every hundredth actor, which seems to give nice feedback on both shorter and longer simulations.
Tomorrow, I'll be trying out the current BlenderPeople codebase on a Mac Dual G5 with 1GB of RAM. It'll be a great test of several things:
1. Easy of use regarding MySQL on different platforms. I don't have MySQL or MySQLdb installed on the Mac.
2. Good test for the new configurator.
3. I'm really eager to see what a modern machine does speedwise, especially a dual-processor one like this. I know that Blender itself is not multi-threaded, but I'm hoping that the system is smart enough to do the Blender/Py stuff on one proc, and leave the MySQL stuff to the other. If so, I would expect to see some dramatically low turn times.
I was doing a simple test tonight (Athlon XP1800, 0.5GB RAM) with 650 Actors, calculating a full second (24 frames) of motion in twenty-eight seconds. Not bad. It was taking three minutes, though, to make one second of motion for a 2,000 Actor sim, which is getting a little bit high for my tastes. I'm hoping the modern hardware will turn those times into cinders.
If I have time, I might throw the MySQL work onto a completely seperate Dual Xeon machine that's connected to the Mac via Gigabit Ethernet. In the past, running the db on a separate machine more than made up for the network downtime on 100BaseT, so this might be even better.
