I’m present to support Dr. Bernard Frischer, with whom Stickman partnered some time ago to help in the development of Seymour3D. Seymour3D is an interactive viewer system that combines secure asset management with a WebGL based frontend viewer that uses a little secret sauce we created to offload rendering of high resolution frames of the object or scene (millions of point or polys). Bernie will be speaking on Wednesday at 10:30 in Waterway Ballroom 6. I’ll be there to answer technical questions.

The bills create uncertainty for businesses, with broad language that could give no recourse to bring your online business back. Worse than that, it threatens the very fabric of the First Amendment and what you can say online.

For more information, a list of informative viewpoints from around the web:

• Google – End Piracy, Not Liberity
• Reddit – A technical examination of SOPA and PROTECT IP
• Wired – Why We’ve Censored Wired.com
• PBS – SOPA Blackout Photos
• Wikipedia – SOPA and PIPA – Learn more

Enter, C-Cab Night Drive.

The model, a c-cab delivery van, was designed by David Steele in Maya and exported as obj’s and converted into json files. The model is fairly complicated, which is what gives it’s flexibility in use. The rigging operates like a modern independent suspension car, allowing the wheels to rise and fall independently. This allows the model to take on the hilly terrain and curbs with ease, and allows the cab to sway when turning.

Similarly, the back doors of the c-cab model will swing open and closed based on momentum as you’re driving. Switch to camera view 4, and you’ll nearly fall out if you drive too fast.

The scene offers collision detection on the building and fence (we turned off the lamp posts, you can drive through them if you want). The trees you see on the other side of the fence are randomly generated, instanced and grouped. It makes rendering faster.

We’ve added five different camera views as well, that show you various viewpoints. In camera view #4, you can actually see the steering wheel turn as you turn (a nice rigging touch on David’s part).

The start screen transition actually uses native CSS3 transition as does the HUD, and the progress bar you see if actually an HTML5 progress as well.

There are of course, some gotchas. One, the audio tracks aren’t as tied the car or scene as deeply as they will be in the actual game. You’ll also note that unless you have last nights Firefox patch for bug #449157, the audio won’t loop. If you’re running stable versions of Chrome, the loading progress bar has a tenancy to go too quickly from 0% to 100% (works fine in Chrome Canary and Firefox).

We’re always interested in feedback (especially bugs, we heart the bug reports), so please let us know what you think!

Update

We appreciate all the feedback, and have greatly lowered the overall GPU usage and changed the reverse controls. If you’ve having trouble running the demo, do have a look at the YouTube example video below:

Within the THREE.js github project, under utils/exporter there is a obj conversion tool called convert_obj_three.py. It’s written in python as a command line script, so a python executable is required to make it work. If you don’t have Python, you can download the version appropriate for your platform from python.org. I drop both the python.exe and convert_obj_three.py in the folder where I save my models, just to avoid typing lengthy paths into the command line.

In Maya, there’s a few things which I do to retain consistancy in translations and scaling before importing the model in THREE.js. I ensure that the model’s xyz translation’s and rotation’s values are 0, and the xyz scaling is at 1. The model also needs to be a child of the world and not under any groups or objects, due to inheritated transformations from the parent group or object. At this point I delete any available history of the model, and select “freeze transformations” from the MODIFY menu.

I export the model as an obj (make sure that the plugin(objExport) is loaded) into the folder I have the python converter script in. “All File Type Specific Options” can be left checked.

Run cmd(command prompt). Go to the directory which the models and “convert_obj_three.py” is located and run the exectution line as such for a basic conversion:

-i for import, -o is output, -x is truncation and scaling. I typically use 1000 so it truncates the vertice values as intergers, and rescaling is easy to remember via 10, 100,1000 etc.

Now the exported model is ready for use in THREE.js. If transformations need to be inherrited from Maya, just multiply by 10, 100 or 1000 depending on your preferred scene scaling.

As a heavy user of Google Reader, the recent changes to the way links are shared within the app left me high and dry. I had been consuming the RSS feed from the shared stories blog that was generated, but since that was deprecated and soon to be non-existent, I needed some other way of consuming my shared links for display on blogs or status pages.

Enter Google+. At the moment, Google+ doesn’t do RSS feeds of public streams (and why would it really, given the nature of how Google+ works). There have been a couple of tools that call out and create an RSS stream from a Google+ feed (notably Russell Beattie’s very cool PlusFeed), but that wasn’t going to swing it. What to do? Google APIs.

If you’ve never used the Google APIs, I highly suggest you give the Google Developers site a quick look over. They’ve got articles and tutorials and a whole bunch of very good info on what you can do. Want to test drive the APIs in browser? Use the API Explorer.

Getting the JSON from Google+ API

Getting the JSON from the Google+ API for a public, read-only feed is not terribly hard, you simply run a GET against the properly formed Google API URL. In our case, we limit the verbose data that we get back in the JSON as much as possible for this example by limiting the fields returned.

$myGooglePlusQuery = "https://www.googleapis.com/plus/v1/people/" . $myGooglePlusUser . "/activities/public?alt=json&maxResults=" . $myGooglePlusMaxResults . "&fields=items(object(attachments(categories%2Ccontentsource%2CdisplayName%2CobjectType%2Curl)%2Curl))&pp=1&key=" . $myGoogleAPIkey;

You’re notice some PHP variables in there, defining the Google+ user we want to get the data for, the max results, and our API key (which you generate in the Google API console). This is going to return the items which have attachments, which is what we want in this case (our shared links). You can get all kinds of data (shared photos and what not), but I’m keeping this simple.

Caching the JSON with PHP

The Google+ API has a courtesy limit of 1,000 queries per day, so we use a bit of PHP to call our Google API query and than cache it for 10 minutes (see gist of entire PHP script on demo page). It’s not very fancy and could be duplicated in any shape and form in any language you want; the only thing it’s doing is a call out and writing to a file.

Displaying the data with jQuery

For a bit of fun, instead of muxing the JSON on the server side into a slightly slimmer profile, I decided to have fun with jQuery AJAX converters to convert the JSON to a custom datatype called JSONG. I check the 20 results in the converter, verify their type (I only wants articles) and then return this new set of data into $.done(). This is then displayed out to the page using jsRender (overkill for this simple example mind you).

The end result

The end result is a simple way to get, cache and display content from a public Google+ stream and display it where ever or how ever you want. The demo page shows this simple case in action, along with the code that generates it for my Google+ user.

As you can see, it doesn’t take a lot of code to work with the Google+ API, nor does it require loads of heavy lifting in jQuery to display that data out. Hopefully this will inspire you to write your own little connectors to keep information flowing from Google+ to your home pages.

Given that we’re working on a couple of in house games as well as a conversion to the HTML5 space, this seemed like just the place to exchange ideas and hear some new ones.

If you happen to run into the guys, ask them for a Stickman sticker. Everyone loves stickers.

We’ve recently been building a few applications for PQ Labs multitouch overlays. It’s a very sweet piece of hardware offering 12 simultaneous touch points, a solid SDK, big sizes, and TUIO support.

While a native SDK is nice, if there’s one thing we love it’s the open web. We set out to start writing a few web apps that could be run either locally from the connected machine or from the web that would offer the ability to use the multitouch aspects of the overlay in a web browser.

One particular use case (soon to be tested in the field) was an event based guest book. Walk up to the screen, enter your details, (yada yada more features yada), and away you go. Stores the data via localStorage (no internet access required for the device) and can be dumped for review later on.

The problem with this idea in a browser was that the onscreen keyboard of choice just doesn’t work as seamless as we’d like. It’ll hide itself when not in use, you can lose it behind the browser if you touch focus away, you can’t have three of them in use at once. So, we decided to roll our own onscreen, in browser keyboard that supports multitouch.

To do this via desktop Chrome or Firefox, you need TUIO support. Just so happens there is a npTuioClient NPAPI plugin that offers the very support that we need. For us, the testing is easy because we have the big ‘ol overlay to work with. But if you want to test our demo on your desktop sans the overlay, Boris Smus wrote a sweet article on the topic you should read: Multi-Touch for your Desktop Browser.

Which gets us to the nuts and bolts. The onscreen keyboard uses a couple different things. One, it uses the touch events API, and two, it use’s Smus’ MagicTouch.js polyfill to convert the npTuioClient callbacks to the compatible touch events as defined by the touch events API.

Once that’s up and working, we can now track multiple touches on the screen, which makes things like the shift key work really nice (as seen in the video below), but also allows us to run multiple keyboards on the same screen (which is for an HTML5 game we’re doing a little something something on…that’s a video for another day .

The demo on the lab page is the most basic version. The keyboard is defined via an object (you could technically load it up from a JSON file very easy like), the layout can be defined at the keyboard level or set to a global default, the click sound is just an HTML5 audio element. We designed it with flexibility in mind.

As for the touch support, you can sorta run the lab demo on an iPad or Xoom/Tab, but it’s laggy with the full keyboard set (not to mention the wrong size for those screens). That’s really not what it’s designed for, but could be tweaked to make it work.

If you don’t want to setup the emulation of multitouch on your desktop or don’t want to fire up your overlay, than have a peak at the video below to see it in action in Google Chrome

In character animation within the 3-D realm, blend(morph) targets are used to tween the surface of a shape’s vertices or control points to another destination using a duplicated shape different topology.  Typically morph target’s for facial rigging don’t act as the sole tool, usually its combined using other tools for deformation such as clusters or skeletal(joint) system.

We looked at various libs when we started working on the tools for WebGL, and settled on THREE.js. THREE.js has morph target capabilities so it became my tool to move the shapes for the facial rig from Maya into WebGL.

I’m not going to go into the from-Maya-to-three.js right now, I’ll cover that in a different post.

The goal was to see if I could get multiple morphtargets active at one time with the same values combined, ending with a result that acts the same in WebGL as in Maya. It’s close.

THREE.js morph targets are strictly linear, so I need to make “in-between” targets to aid in altering a linear path from a vertice’s point A to point B.  A good example is Ginger’s jaw movement. Using a linear morph path her jaw would open straight into it’s end pose, not rolling into its end pose.  So a partially opened mouth position was used to simulated a in-between target, to aid in the downward rolling moment into the fully open jaw’s end pose.

I’ll follow up with more detailed posts and information as we continue working on the toolset. For now I need to finish me coffee. -David Steele

Meet Ginger.

Ginger is a facial rig that utilizes 25 or so morph targets that get powered by three.js in WebGL. The facial features of the model can be shifted into different forms and expressions using the jQuery UI sliders (we originally had html5 range inputs, but wanted to get some love for Firefox out there which doesn’t quite support them yet).

The demo works pretty well in the latest versions of Chrome and Firefox (sorry IE users…no WebGL for you).

The models where designed by our resident Chief Artist David Steele in Maya (he also did all the conversions and a significant portion of the JavaScript for this particular demo). He’ll be getting into more of the technical details of the models in Maya and the three.js action in a later post.

While the demo offers simple functionality, the overall toolset that we’re working on has to deal with creating easier animation tools for the cutting edge of the web in canvas and WebGL. But we’ll get into that later.

In the mean time, enjoy playing with the demo, and stay tuned from some cool tools in the pipe!

NOTE: if the demo isn’t loading (and in certain cases with video drivers being blacklisted in Chrome/Firefox that will be the case), you can see the demo in action in the YouTube videos below. For comparison purposes, we did videos in both Firefox and Chrome.

In Firefox

In Chrome

Earlier this month, it was widely reported that timthumb had a security vulnerability (see Mark Maunder’s announcement or Ben Gillbanks followup) that would allow an attacker to push files into your WordPress install. subsequently, timthumb 2.0 came out and solved the issue, but alas not all theme’s or plugins updated to this version.

It appears now that attacks utilizing this vector are now bot automated (or someone has a lot of time on their hands), because the phone has been ringing today. How to deal with this and recover? The following is a general action plan you can use as a base. It’s not the end all solution; you’ll have to adapt to your specific case of infection.

NOTE: let me repeat: the following instructions are NOT the end all solution in most cases: you have to adapt them to your particular case. We offer no warrenty if you screw something up.

BACKUP NOW! if you have not done so, please backup your files and data. You should be doing this already, but do it one more time just in case.

Fire up your SSH to your server, and get ready from some command line action.

First, find if you’ve where your timthumb is installed (might be a theme, might be a plugin)

grep -ri -l "timthumb" /path/to/blog/folder

After you’ve found it (sometimes the file itself is not named timthumb.php, so make note), go get the latest version of timthumb from trunk:

wget http://timthumb.googlecode.com/svn/trunk/timthumb.php

You’ll need to sort out the particular settings that the old version used (some installs use the sidecar timthumb-config.php for that, others have it defined within their version of timthumb). Once you have that sorted, copy/move that file into place, destroying the old file:

mv timthumb.php /where/ever/old/file/located/thumb.php

Great, timthumb should feel better. Now let’s cleanup other damage.

Several of the sites we looked at today had a variation of a redirect to securesoft.ru, which was being reported by Google Chrome as containing malware. The first thing you have to do is sort out where that’s coming from. Let’s find it:

grep -ri -l "securesoft" /path/to/blog/folder

This for us returned the root level .htaccess file in the wordpress directory. Chances are, you’ll note that it the modified date was recent and that it’s larger in size than usual. If you open it, it’ll probably look like the normal version your wordpress install uses. It’s not; the file is padded with space to hide the new redirect rules. Basically, you have two options: scrub the bad rules out or simply delete the .htaccess and replace with a fresh version. Your choice.

Second, let’s look for changed files that the attacker may have uploaded.

find /path/to/blog/folder -mtime -2

That find command will look for files that have been modified within the last 2 days. You can change the days span by simply updating the “-2″ to what ever number you want. In our case, this returned two files in most cases, wp.php and script_new3.php in the theme that was compromised (this was also noted on ServerFault yesturday). Remove these two files.

At this point, you should be generally back to normal. Login into your WordPress Admin, change all your passwords for all users and update any and all plugins, themes, and WordPress files as needed.

Again, I cannot stress this enough: this is general. You should check your logs to verify if any other activity that may have taken place and evaluate if any other files changes may occurred. But hopefully this will help get you started.