Zombie Walk

Mixamo Blender Panda3D Character and Animation Pipeline

PRE-REQUISITES:

A basic knowledge of Blender (driving the user interface and installing plugins).

PROCESS:

Mixamo allows you to save models in a variety of formats (FBX, COLLADA, BVH Motion Capture). I began choosing the COLLADA export option.  I do not generally need to model much so I do not have any expensive 3D suites such as 3D Studio or Maya. I instead opted for the free and open-source solution Blender. Upon attempting import of the COLLADA I was greeted by a mess of a model in Blender. Something had gone wrong. Retrospectively, at this point, finding out why it hadn’t worked would have been the best course of action. Instead, I concluded there was some quirkiness going on with COLLADA and switched to the other export option offered by Mixamo – FBX. After a bit of digging I stumbled on an FBX Converter (Windows only sadly). The best option it had (for a format that would include the animations, not just the static model) was, you guessed it, COLLADA. Irritating.

After yet more digging I found what I was looking for on the Mixamo website itself (by fluke, in an “order confirmation” email for a free sample!). I wish they’d put this kind of information more upfront on their website, the “model pipeline” is the first thing anyone will want to know who has an actual use for their creations!  Mixamo offer a free Blender plugin for “Mixamo COLLADA Import”. It is only for Blender 2.49 but that’s a good thing as the same applies to the Chicken Exporter we use later! (in other words, you need Blender 2.49, it should run happily alongside newer versions). I thought COLLADA was COLLADA was COLLADA, y’know, the whole point of it being a standard? Mixamo say their importer conforms to the COLLADA standard. I don’t know what the truth is or why the COLLADA importer that came shipped with Blender didn’t work. Don’t know, don’t care really. The Mixamo importer is Windows or Mac only (as is their site really since it uses the Unity3D plugin). It worked too – or so I thought.

I tried to render a scene in Blender and observed “no textures”. Looking at the console output for the importer there were errors regarding the images not being readable. Long story short, I finally clicked that it could not handle spaces in the file path. So storing the COLLADA file in a “C:\Documents and Settings\….” style path was a problem. Pity the importer didn’t report an error in Blender itself. Once I moved the files to a non-whitespace path (C:\getting-annoyed-now\, for example) it worked perfectly.

Final hurdle. From Blender to Panda3D. There is a Blender plugin called the Chicken Exporter. I installed it and exported from Blender. The resulting EGG file worked – but with no textures or animations. Fixing the textures was easy, I just edited the EGG file directly (it’s a text format file) and fixed the paths by changing them to relative paths (the exporter had added absolute paths such as “c:\getting-annoyed-now\…..” to all the image paths, I was not even on the same machine or operating system at this point, so those files certainly did not exist in an “absolute” position). Fixing the animations was something a bit more involved.

In Blender, select the Armature in the Outliner panel. In the buttons panel you will now see a “Modifiers” tab. In that tab, there is a button “Make Real” (with the text “Armature Parent Deform”). I don’t fully grasp what it is doing when you click this but a “modifier” appears under the Armature in the Outliner. It has something to do with armatures via parenting or modifiers but I’m not a Blender guru (in fact very much a newbie!). Once done, the Chicken Exporter window now shows the option “add animation”.

Ok, now, find out how long the animation runs. Open up the NLA Editor and click right at the end of the animation. In your main Blender window (3D View) the current frame should show up at the bottom left. Cool. Also, in the outliner, note the name of your Armature. In my case it was “Zombie_Hips” (or open up enough panels that you can see all of this information in one screen, like the screenshot below).

Blender

Finally, export via Chicken. Make sure you have done “select all” (hover over the 3D view and hit the ‘A’ key on your keyboard until everything is highlighted) before launching Chicken.  Click the “Add Animation” button. Set the animation name to the same as the Armature/Object name (both set the same for Mixamo imports), set the End frame to the final frame, and export. The job is done, it should all work, 3D character and animation. In Panda3D’s PVIEW, hit “l” to enable lighting else you won’t see the textures.  BTW – that last bit, I just flippantly mentioned (set the animation name to the armature name) is critical.  It cost me hours of head scratching time that!  All being well, you’ll find you have an EGG file that works with animation and texture!

I was approached recently by a client wanting a 3D game environment in which players could talk to “bots” (artificially intelligent chat bots) by typing text and receiving replies. The chat bots were to live on a server while players would launch a 3D game client to login to the server. As part of the login process users would select an “activity” (a scene). Each scene was to be populated only by certain chat bots; every chat bot was to have its own ‘AI brain’ and would thus converse differently with the user to other bots.

A tall order! The screen shots below show how it panned out:

The Server

So where to begin? The obvious starting point was the server. All that was required was the ability for it to host bots, allow user login and exchange chat (text). XMPP is a common ‘instant messaging’ protocol – in fact, it is used by Google Talk (on that note, our final software can actually be used with Google services as easily as our own server!). The XMPP protocol was originally named Jabber. Openfire Server is a free, cross-platform, open source Jabber server. It’s what was opted for and installed on the server. It was installed and user accounts created for real players and the non-player characters (NPCs, our bots).

The Bots

With the server up and running the next logical step was a Jabber Bot. No need for 3D at this stage, we just wanted some software that would connect to Jabber, accept messages, process those messages and send back a reply. The simplest starting point is an “echo bot”, a bot that simply repeats back whatever you type to it (very annoying!).

Since it was already known we would be using Panda3D for the 3D engine (see later in this article) it made sense to keep the technology consistent and write out Jabber Bots in the Python programming language. It also turned out there was an excellent Python library for communicating via XMPP called SleekXMPP. A working echo bot was nailed in no time!

The bots now needed some intelligence. The artificial intelligence mark-up language (AIML) was chosen. AIML is simple to grasp and was deemed sufficient for our purposes. Constructing ‘brains’ in AIML (i.e., different bot personalities/responses) consists essentially of copying a set of XML files and modifying them to suit.

There is an ‘example’ of implementing an AIML chat bot in Python called Howie. Essentially, a new generic bot was written (affectionately known as “Bot the Bot”) that was a combination of Howie and SleekXMPP. Bob the bot gets his specifics from a configuration file detailing who to login as, which brain to load etc. Thus, “new bots” are simply “new configuration files for the generic bot”.

The 3D Client

As we noted earlier, Panda3D was chosen as the game engine. The reasoning is outside of the scope of this short article but the short answer would be “Panda3D is awesome!”. There’s not much to discuss in this section – see the screen shots above! Essentially a 3D scene is selected and loaded. The room was created using Sweet Home 3D. The scene is populated by designated bots, our actor models came from Code3D (open source). All of the Jabber functionality comes from SleekXMPP. The rest was just raw coding!

That’s All Folks!

I hope this has been useful to some. I am hopeful of open sourcing the project in the near future, pending consent from my client.

A new venture for FlatCoder Ltd., I would like to present MGF Magazine! “Anyone can make a video game, it’s not that hard!”. A summary is as follows:

MGF ISSUES are organised into VOLUMES.
All of our content makes use of software & tools that are available for free.

VOLUMES
Each Volume completes with a fully finished playable game that will work on Windows, Mac, Linux and can even be run in a Web Browser!

ISSUES
Each Issue has a purpose and point. You will always see progress in the development of your game. Issues are short and snappy, as they should be, backed up by video where necessary.

LEARN TO PROGRAM
Our focus will always be games but the skills taught are very transferable. You will learn computer programming and software engineering using little more than a text editor, the Python programming language and the Panda3D engine. We have chosen Python because it has been used successfully (and commercially) for games, business applications, web applications and most any application you can think of! It’s also a ‘great first language’ for anyone wanting to learn programming.

To learn more, head over to the website: http://www.mygamefast.com

The Problem

One of the recurring issues in my line of work is the storage of sensitive information.  As a freelancer, I am entrusted with a large amount of commercially sensitive information, access details to servers/networks/software and similar.  Obviously, there ends up being far too much to simply remember!  All too often people “solve” this problem by storing information in emails, in a document, on a post-it-note or scrap piece of paper.  Not very secure!  Other approaches I have seen taken include reusing the same password over and over for different things.  Again, easy to exploit, once an individual with malicious intent finds one password – they have much broader access than anticipated.

Solutions

Attempts have been made to develop software for the sole purpose of securely storing passwords.  Some are pretty good for the single user environment – i.e., a single application to download and use on a single PC.  Some have network support and the notion of multiple users.  Some are free, some are open source, others are commercial.  As always, selection depends on requirements, but a few of the more popular are KeePass, 1Password and LastPass.

I looked at several but the biggest initial short coming, for me, was the lack of a Web Browser interface.  In this instance, my reasoning was because I am in the process of building my own Intranet with many tools accessible via browser grouped into a neat portal style application.  Having said that, a browser solution is preferable to many organisations for a number of reasons.  First of all, for each client or user, there is no need to install anything.  The sole requirement is a web server on the internal network (which most companies, these days, would already have) and a web browser on each client.  In larger scenarios this is fantastic, solutions can be rolled out “company wide” in one swoop, completely non-intrusive to everything else on the network or its clients.  This offers a further advantage in that updates to software, access controls/users and content can be administered at the server and again instantly go company wide.  Lastly, such a solution offers platform independence, you could even access your password repository via your mobile phone.

So, off I ventured for web based solutions.  The pickings are comparatively slim but there are a few.  One example is PasswordSafe, another is Secret Server.  Then I remembered something I used to use while fully employed:

The History of Magpie

Back when I was working for a company called Accelerate4, we used a piece of software on our Intranet called Magpie.  It had been developed by one of the guys I was working with.  At the time, it was fairly simple, nothing special to look at, but very capable and a perfect fit for our needs.  Developers loved it and it became used extensively and exclusively internally for its designed purpose.

The original developer, as it turns out, has not abandoned Magpie and when I contacted him was in the process of beta testing a new release.  I was more than happy to get involved as it allowed me some input in terms of extra functionality and the future “wish list”. 

Magpie Today

Is very well evolved and is the choice I have made for the FlatCoder Intranet.  There are a number of reasons for this decision, the highlights listed succinctly below:

• Browser based, as noted.
• Great organisation and grouping of data.
• Ability to define teams as well as users, fine granularity control and view of  “who knows what”.
• Multilingual
• Ability to restrict/control access via IP address.
• Bundled web server for Mac OS X, MS Windows and Linux allowing for rapid and easy installation.
• Ability to integrate with other/existing web servers such as Apache or IIS.
• Options for authentication methods (e.g., htaccess).
• Options for encryption schemes using symmetric ciphers (IDEA, DES3, Blowfish, Rijndael (aka AES)).
• Public/Private key encryption using RSA or DSA.

In short, never email a password again, email a link!  Magpie is both highly secure and a pleasure to use!  Future enhancements are also planned including the ability to store file attachments (great for server/client keys and similar).

To find out more about Magpie visit the Official Site over at Pismo Software Ltd.

A Secure Linux Kiosk OS

The Problem

The original requirement was for a collection of 4 touchscreen information stands in an NHS hospital (providing information such as maps/”You are Here”, patient information etc.).  It was absolutely critical that the system could not be hacked and that content was limited.  The kiosks were to serve information from a local web server but some of the content being provided was from pages on the Internet.  To that end, a further requirement was locking access to sites, only sites and content in a safe “whitelist” were to be served, making it necessary to block attempts to retrieve any other Internet content.

Approach

A custom distribution of the Linux Operating System was built called KiOS (abbreviation for Kiosk Operating System).  KiOS is a custom distribution of Linux (based on SuSE / built using SuSE Studio) intended for usage in the Kiosk environment.  There are 2 variants, one for the clients and one for the server.  Rolling back in time, the solution “rough cut” was as follows:

1. Content via web browser. Browser must not have any controls (file menu, address bar, right click etc.), downloads or similar.
2. The Kiosk must not allow access to the underlying operating system and the browser must not be closed.
3. The Kiosk will connect to the network via DHCP.
4. The Server will always assign the same IP address to the same MAC (allowing for “you are here” to function).
5. The Server runs a whitelist of allowed sites, requests to any other content are denied.
6. The Server acts as a web proxy to cater for the “Internet Down” scenario.

The KiOS Operating System (for clients)

The base distribution began as follows:

1. KiOS was built using SuSE Studio ( http://www.susestudio.com ).
2. A base template “JeOS” (Just enough Operating System) was used.
3. X11 was added as a package. Note that NO WINDOW MANAGER was used. This gives an advantage in that no window manager keyboard shortcuts are available/no update manager alerts are given etc.
4. The Flash player was also added (optional and not necessarily desired in every scenario).
5. The firewall was setup to block ALL incoming requests. NO PORTS are open.
6. The OS was set to load at run level 3 (normal non-graphical console).

The KiOS disk image is written to a USB pendrive. The system is set to boot off USB. No hard disk is required. This also benefits in that the “worst case scenario” typically requires just a reboot. If that fails, the pendrive can be removed and inspected or simply re-flashed. The pendrive in the real kiosk is locked away behind a secure panel.

The first time the OS boots it performs setup (network, graphics etc.). We then run a script to secure the GRUB boot menu and make the “default” option boot immediately:

if [ -f /etc/init.d/suse_studio_firstboot ]
then
# Lets protect our lovely grub...
echo "Running KiOS first boot script..."
cat /boot/grub/menu.lst | grep -v timeout > /boot/grub/menu.tmp
cat /home/kiosk/menu.lst /boot/grub/menu.tmp > /boot/grub/menu.new
mv /boot/grub/menu.lst /boot/grub/menu.old
mv /boot/grub/menu.new /boot/grub/menu.lst
fi

In short, remove the standard timeout of 10 seconds. Then paste the contents of a second file at the start of the menu. The second file contains the following:

timeout 0
hiddenmenu
password --md5 <hash>

Effectively hiding the menu by default, causing immediate boot to the default option, and (worst case) if someone does intercept the menu a password is required to edit any options.

Also, on first boot, a number of files are overlaid into the operating system:

The user can still Ctrl-Alt-F1 (etc.) but the terminals are all dead aside from the one running Opera. Anything killing Opera results in a logout/login/startx/start opera. In the real world – the keyboard on the kiosk has no Ctrl or F keys – but, it is still better to cater for every eventuality (keyboard!).

KiOS without a Server

If KiOS is to be used in an environment without a server Opera can be configured to handle the whitelist/blacklist:

1. Exit Opera
2. Define a filter file in opera:config
3. Create a filter file if it does not exist already
4. Make an [exclude] section listing the URLs to block
5. Make an [include] section listing the URLs to allow
6. Restart Opera

Example limiting access to just one site:

[prefs]
prioritize excludelist=0

[include]

http://???.opera.com/*

[exclude]
*

Dealing with the USB stick and what happens if SuSE remove the Studio service?

The raw disk image is written to the USB stick with the following command:

sudo dd if=/home/garyr/Desktop/KioS/KiOS.i686-1.1.11.raw of=/dev/sdb bs=4k

If the USB will not boot:

umount /dev/sdb1
fdisk /dev/sdb
\tp     «--- print partition table
\ta     «--- activate partition (bootable)
\t1     «--- partition 1 is bootable
\tw     «--- write changes to partition table

The disk image can be modified without using Studio as follows:

mount -oloop,offset=32256 discimage.raw /mnt/

Key File Contents

.bashrc:

clear
exec startx

.xinitrc:

opera -kioskmode -nowin -resetonexit -nosplash -nosave -noprint -nomenu -nomaillinks
-nomail -nokeys -nocontextmenu -kioskresetstation -nodownload

inittab (selected entries only):

id:3:initdefault:
...
1:2345:respawn:/sbin/mingetty --noclear --autologin kiosk tty1
...
#2:2345:respawn:/sbin/mingetty tty2
#3:2345:respawn:/sbin/mingetty tty3
#4:2345:respawn:/sbin/mingetty tty4
#5:2345:respawn:/sbin/mingetty tty5
#6:2345:respawn:/sbin/mingetty tty6

xinitrc.common (basically delete a block):

#
# Error, no Window Manager found.  Normally the exit
# raises the fallback trap of the sourcing script.
# ...error dialogue removed leaving just:
exit 1

menu.lst and first boot:

See earlier

opera6.ini (selected entries only, proxy settings also go in here):

[User Prefs]
Language File=/usr/share/opera/locale/en-GB/british.lng
Preferences Version=2
Has Restored MIME Flag=1
Trust Server Types=0
Check For New Opera=0
DevTools Splitter Position=500
History View Style=0
Open Page Next To Current=0
Last Used Auto Window Timeout=60
Enable Wand=0
Show Startup Dialog=0
Startup Type=2
Home URL=http://www.google.com
Ignore Target=1
Target Destination=3
Ignore Unrequested Popups=0
Keyboard Configuration=/usr/share/opera/ini/standard_keyboard.ini
Enable Gesture=0
Mouse Configuration=/usr/share/opera/ini/standard_mouse.ini
Window Cycle Type=0
Use Thumbnails in Window Cycle=0
Use Thumbnails in Tab Tooltips=1
Activate Tab On Close=0
...snip...
Visited Pages=0
Accept Cookies Session Only=1
Enable Cookies=3
Toolbar Configuration=/home/kiosk/.opera/toolbar/standard_toolbar_1.ini
AddressBar Alignment=0

[State]
Accept License=1
Reading Plugins=0
Run=0

[Disk Cache]
Size=20000
Enabled=1
Empty On Exit=1
Images Expiry=18000
Other Expiry=18000
Docs Modification=1
Figs Modification=2
Other Modification=2

[Special]
Go Home Time Out=60

Closing Notes for the Client

• The host PC should be set to boot from USB!
• The host PC should have a BIOS password to prevent changing of the boot order.
• It may ultimately be worth disabling Ctrl-Alt all together.
• Still need to investigate SysRq ( http://en.wikipedia.org/wiki/Magic_SysRq_key ) though on first inspection the only combination that works is Alt-SysRq-o to power down.
• Navigation Issues. There is no home button, back/forward etc. In the initial application of KiOS this is not an issue as the web page being used will handle it. In other scenarios, a navigational IFRAME could be used or limited toolbar buttons re-enabled.
• Customer did not want a screen saver kicking in, the screen stays on with “touch here to start”. This was fixed by adding “xset -dpms” and “xset s off” to the xinitrc before the Opera call.
• Touch screen drivers. The package x11-input-evtouch was added to the build in SuSE Studio.

The KiOS Server Configuration

Broadly speaking, the steps involved were:

• Setup the router (firewall, make it keep IPs per MAC address etc.).
• Setup server OS including web server.
• Write the kiosk client image to USB sticks.
• Edit the USB client sticks setting the Homepage and the proxy settings:

[Proxy]
Use HTTP=1
Use HTTPS=1
Use FTP=1
Use GOPHER=1
Use WAIS=1
Use Automatic Proxy Configuration=0
HTTP server=192.168.1.3:3128
HTTPS server=192.168.1.3:3128
FTP server=192.168.1.3:3128
Gopher server=192.168.1.3:3128
WAIS server=192.168.1.3:3128
Automatic Proxy Configuration URL=
Enable HTTP 1.1 for proxy=0
Use Proxy On Local Names Check=0
No Proxy Servers=
No Proxy Servers Check=0

• We then setup Squid (the web proxy software) to run on its default port (3128).
• Configure the white list/ACL using Squid so only sites stated are allowed:

http://en.kioskea.net/faq/sujet-804-ubuntu-installing-an-http-proxy-server-squid
http://beginlinux.com/server_training/121-proxy-server/1051-squid-acls

• You can do that in your squid.conf using an acl such as:

acl whitelist dstdomain "/etc/squid/whitelist"
http_access deny !whitelist

...and a whitelist that looks like...

.slashdot.org
.linuxquestions.org

• Another option would be to use an acl with “dst (ip-address/netmask)” instead of “dstdomain (.linuxquestions.org)”. Modify to your needs,
  there are tons of other options described in the squid.conf comments.
• Custom 404/redirect to HOME for sites not accessible.
• Firewall Server OS except for port 80 (web) and 22 (ssh for remote admin – will require port forwarding in router – no other outside ports should be accessible).
• Confirm all of this via both internal and external NMAP scans.
• Deploy the content to the server.  Tweak as necessary.  Server should be only MAC with Internet access.  Everything else via proxy.
• Check IP assignment in router, force it to stay the same always, and update the “where am I” configuration accordingly
• Check squid logs to make sure clients are indeed going via proxy.

Clarity for Software Shoppers

The Problem

Here’s an example.  The system requirements for Assassin’s Creed 2 on the PC are:

• Processor: Dual core processor 2.6 GHz Intel® Pentium® D or AMD Athlon™ 64 X2 3800+ (Intel Core® 2 Duo 2.2 GHz or AMD Athlon 64 X2 4400+ or better recommended)
• RAM: 3 GB Windows XP / 2 GB Windows Vista
• Video Card: 256 MB DirectX® 10.0-compliant video card or DirectX 9.0-compliant card with Shader Model 3.0 or higher
• Sound Card: DirectX 9.0 or 10.0-compliant sound card (5.1 sound card recommended)
• DirectX Version: DirectX 9.0 or 10.0 libraries (included on disc)
• DVD-ROM: DVD-ROM dual-layer drive
• Hard Drive Space: 12GB

Here’s the specification of  a PC currently on the market:

• Processor :  AMD Athlon™ II X3 425 Processor, 2.7 GHz, 2.0 GHz HT (4000 MT/s), 3 x 512 KB L2 Cache
• Operating System:  Genuine Windows® 7 Home Premium
• RAM:  3072 MB DDR2
• Graphics card:  NVIDIA GeForce 7100 integrated graphics

See the problem?

To some people, the information above is fine.  For the majority of people, it is not (if I called my Mum and asked her what graphics card she had I’d get an “eh?  a what?”).  So why, in 2010, have we not come up with a cleaner mechanism for hardware and software requirements instead of obfuscated blurbs like the above?  The problem is really a simple one – a customer walks into a shop, wants to buy some PC software and wants to know/confirm it will run adequately on the PC they own.  Simple enough, so can we simplify the jargon?

The Solution

Here’s how I would do it.  I think.  Let’s face it – the critical aspects in terms of specification, these days, are Operating System, CPU, Graphics Card and RAM.  We can pretty much disregard hard drive space, I haven’t had a disk space issue since the 1990s, disks are cheap as chips these days.  Likewise, I’ve not run into a PC without a sound card for even longer, nor had an issue where a sound card would not be up to the job (yeah, we can have surround if we like, dolby 5.1 blah blah, but essentially, the base is still a sound card and a couple of speakers).

We can capture what’s needed in a 3 point number and an Operating System indicator.  For example, the back of the box for “some game” might give an “SR” (System Requirements) Score of:

2.3.1

(or possibly a “minimum” and “recommended” set of values)

First we give the OS as an icon.  Windows, Mac, Linux, others and variants (e.g. XP/Vista/…):

Next, a 3 digitnumber, in order:

1. The System Level
2. The Graphics Card Level
3. The RAM Level

So, 2.3.1 means a System level of 2 or more, a Graphics card level of 3 or more and a RAM level of 1 or more.

Et Voila.  PCs should come out of the shop with a nice “SR” sticker instead of all those badges for Intel, nVidia, ATI or whoever.  Likewise, software boxes would have a simple panel on the back giving a rating.  No more confusion for anyone, you can tell at a glance if your system is up to the job of the software you’re buying – all you have to ask is “is that SR number bigger than mine?”. If it is, move along, that software isn’t for you.

Under the Hood

System level, what does that mean?  Hypothetical example:

• System 1:   At least 1Ghz processor
• System 2:   At least 2Ghz
• System 3:   At least Dual Core, 2Ghz
• (etc.)

The Graphics level:

• GPU 1:  3d 64MB shared memory or more
• GPU 2:  128MB dedicated memory or more
• (etc.)

Lastly, memory (RAM) level:

• RAM 1:  1GB or more
• RAM 2:  2GB or more
• (etc.)

Examples

Assuming:

My PC is Windows XP 2.4.3

OS is confirmed by icon (software runs on XP), software of:

• 2.3.2  would run fine
• 2.5.2  would struggle with graphics
• 3.4.3 would struggle generally (CPU not fast enough)
• 2.4.5  would struggle generally (not enough memory)
• etc.

Simples