SyntaxHighlighter

Monday 15 July 2013

Day 26: Reboot

Setting up Donald

Arrived at work today and found a lovely surprise waiting for me in the AIG lab - none other than Donald himself! Seems my workplace got a bit of an upgrade then, I copied all the AR stuff off Katy (the previous AR workhorse) and onto the new superfast machine in a jiffy, installed GoblinXNA - followed the installation guide to the letter, no problems to speak of.

A recurring issue during the installation however, is that ALVAR does not set its paths up correctly. I think this is an issue when installing on 64 bit machines (which they should all be nowadays) but is easily corrected by entering the configuration manager in Visual C++ Express: C/C++ -> general -> Include Directories, as well as Linker -> Include Directories and simply fix the paths there.

After Goblin XNA 4.1 was fully set up with .dll's from OpenCV, Alvar, Newton etc all copied properly (all part of the installation guide) I simply copy/pasted the entire project directories for our two XNA projects (LowryDemo aka the standard AR demo program, and ExportJPEGs) into their respective new homes (GoblinXNAv4.1\Projects\) and then built them.

LowryDemo builds without a hitch (after copying the relevant models over to GoblinXNAv4.1\data\models) and runs like a dream - much smoother than on old Katy actually. I noticed it in the bouncing golfball demo, which is somewhat graphically demanding with 15 balls each with shadows and moving about at high speed and everything.

ExportJPEGs also builds flawlessly. It required a coupe Both programs take a very long while to build (understandably, they need to rebuild absolutely everything from scratch)

Productivity just underwent a large boost!

Set about doing task number 1: process the backlog of photos that 123D was too slow to get through on animation day and upload those gifs!

My life for the next few weeks (automation)

So the general task I have right now involves making the entire 123D Catch to AR demo process completely automated so that any user can demo this tech via a simple keypress in future. To do this I need to consider the complete workflow of the 123D-to-AR demo, and work out how to automate every step - and of course remove steps, find better ways of doing things, make it faster and more efficient etc. Lots of fun scripting expected!

Here's an overview of how we did it at Animation13. This is what we want to automate and improve (I posted this in a previous blog post somewhere too): 
  1. At the 123D Catch machine, take bunch of photos, run 123D Catch on them and export a model.
  2. run the put.ftp script to upload the model and its texture to our file store.
  3. On the AR machine go to C:\Export\toby, run get.ftp (this script pulls the 123D models from our file store somewhere)
  4. rename texture file to "t1.jpg" so now we have e.g. 1.fbx and t1.jpg
  5. Use regex to replace 4 lines in fbx
  6. place them both in C:\Users\ARdemo\Desktop\ARdemo\GoblinXNAv4.1\projects\ExportJPEGs\ExportJPEGs\ExportJPEGsContent
  7. Open ExportJPEGs.sln project in VS C# Express (once its opened leave it open for the next model cycle), import 1.fbx, update code to load "1.fbx", run in debug mode.
  8. JPEGS are now in C:\Export, make gif by running the script "./convert.sh 1.gif" in cygwin, this automatically uploads the gif to the webserver where it displays on the rotating heads web gallery, (important that gif names don't clash!)
  9. copy 1.xnb and 1_0.xnb from C:\Users\ARdemo\Desktop\ARdemo\GoblinXNAv4.1\projects\ExportJPEGs\ExportJPEGs\ExportJPEGs\bin\x86\Debug\Content (these were generated as a byproduct of step 5)
  10. paste the xnb's you just copied, into C:\Users\ARdemo\Desktop\ARdemo\GoblinXNAv4.1\bin\Content\heads
  11. Hit the M then the Z key on LowryDemo to load the next model
On every cycle increment the model number (e.g. in steps 4, 7, 8, 9 replace the 1 with 2, 3 and so on). This is very important as LowryDemo is programmed to take models named exactly the right number, and that number is 1, 2, 3 and so on. If you misname the models you will waste a head spot.

There are some issues with automating this demo. Mainly that it can easily go wrong - and a simple restart is not possible. If you mess up you have to manually recover the heads that have already been done and restart the AR demo application yourself and do a few more steps. An educated user (at the moment that definition only refers to me) can recover the AR demo up to where the problem occurred within about a minute. Trying to automate such a recover seems like it'll be pretty hard, but we'll tackle that when we get there.

Automate Tasks 1 - 5: Running 123D Catch and getting the model to the AR machine in the correct format

For this part of the workflow some manual intervention of the user will be necessary. We will assume the user demoing the new 123D-AR demo will take pictures of the subject and copy them onto the 123D machine.

Currently there is no way to run 123D Catch from the command line. Will it be possible to tell windows to walk itself through a full 123D capture up to the exporting of the model? I highly doubt that will work because 123D is very inconsistent. It randomly crashes at random times, and on the other hand the user needs to fix up the meshes on the returned scan anyhow. For this reason I will also assume that the user will run the 123D program himself. Full instructions will be provided so that anyone with very basic computer knowledge can operate the program.

The extent of the compulsory actions of the operator now include: taking pictures, copying them to the 123D machine, running 123D Catch on the pictures, fixing the final mesh, and exporting the model correctly named (meaning the first one is 1.fbx, then 2.fbx, and so on) and sticking it in the OUTGOING directory (we'll make one).

Which means I need to automate the following: upload model&texture from OUTGOING to the filestore, download model&texture from the filestore, open fbx and replace some strings using regular expressions.

Methinks this is a job for cygwin.

Notes:

Current put.ftp script (on the 123D machine) gets everything in the current folder and sticks it in the file store (toby@kiss.cs.man.ac.uk:public_html/123/incoming).

On the AR machine, current pull.sh uses scp to grab everything in the filestore, and there is a delete.sh meant to be manually run immediately after a successful pull.sh which deletes everything in the file store (so the next pull.sh doesn't grab anything it's already previously grabbed). This is meant to be run every few minutes by the user of the AR machine.

To automate it:
Found great resource: winscp program for windows! It has a "synchronize" command (click for details) that means: "Get an exact copy of a directory transferring new and modified files only. Delete unwanted files." which is perfect for what we want. Set synchronize to upload from the 123D machine, and download on the AR machine.

An issue: winscp is obviously Windows based and won't work on Mac or Linux. Perhaps write my own script that uses the Unix ftp command and can thus be executed on any system (on Windows via cygwin), then write a wrapper to make it easier for the user to run on Windows (so they don't have to open cygwin and all that)?

On this train of thought I have come across rsync: Unix command that does exactly that.

Can't get it to work on cygwin. Running:
rsync -avzun toby@kiss.cs.man.ac.uk:public_html/123/incoming/ /cygdrive/c/Export/toby/.

gives random errors: 
bash: rsync: command not found
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: remote command not found (code 127) at /home/lapo/package/rsync-3.0.9-1/src/rsync-3.0.9/io.c(605) [Receiver=3.0.9]
No clue what is wrong. The shell definitely sees rsync and I can run simple rsync commands successfully, but not over ssh (i.e. with a remote server). It works with other servers on the domain (e.g. my username at lf032) so it looks kiss is rejecting rsync. Security issue? Researching.

Automating Tasks 6 - 10: Building .xnb files ahead of time

The automation of the compiling of .xnb files. If I can compile them from the command line then I can automate the running of the Visual Studio programs (ExportJPEGs and LowryDemo) without requiring user intervention. Otherwise a user HAS to open the .sln project, manually import a model into the content, and then do stuff with it. This way the importing is no longer necessary. Solving this problem will aid in automating tasks 6, 7, 9 and 10.


Looks like a standard "MSbuild" run will compile anything that XNA would, so I need to learn how to run an MSbuild from the command line. It needs some XML messing about to get it working, researching now.

No comments:

Post a Comment

Note: only a member of this blog may post a comment.