I work more and more with HTML these days, which means I’m constantly finding solutions to little issues that are new to me.
Today I found quite a big issue however, and that has to do with communication between an iframe and its parent document when the two are living on separate domains.

As you may or may not know, cross-domain communication is always an issue. The reason for that is security (you don’t want open access to domain A from doman B), so I’m quite alright with options being limited, as it means data is safer as a result. However, these limitations can obviously work against you if you want to achieve even seemingly simple tasks.

What I needed to do was to have an iframe in a page on one domain, that loads in a page on another domain, and that iframe is shown as a full overlay on the original page. Naturally, you want to be able to close the overlay, for which we included a close button in the iframe.
However, due to these cross-domain communication restrictions, I couldn’t let the iframe content tell the parent document to remove the iframe. What now?

There is a recent solution for that, window.postMessage, that allows you to perform just this kind of simple messaging, but the catch is that it’s HTML5, and I want it to work on the older IE browsers as well. So that’s no go.
Then there’s JavaScript libraries that try to work around this issue, but I’m not satisfied with the extra code that implementing these cost me, so I decided to try a little bit of hacking…

I started thinking about the root of the issue, and that is that only scripts that originate from the same domain can safely communicate with each other. So any script on domain A can interact with another script on that domain. Now, what I need to achieve is really really simple: I have a page on domain A, that contains an iframe that lives on domain B, and I want to tell domain A to remove the iframe when interacting with the page on domain B. Now, we know that we can embed pages across domains using iframes, that’s exactly what we’re doing already. Sooo… why not load a close button from domain A in an iframe on domain B? That’s right, domain A contains an iframe from domain B, which in turn contains an iframe from domain A. That way, the close button can safely communicate with the parent document, as they both live on the same domain!

What does this mean in practice?
Well, the parent page (say http://domainA.com/parent.html) loads the remote page (http://domainB.com/remote.html) in an iframe, passing along a GET variable that passes the URL for the close button (http://domainA.com/close.html). The remote page can then add this in its own iframe, and presto!
To keep it neat (or as neat as hacks get), the close button HTML only contains a transparent div, so the actual visuals aren’t divided over different domains. It only provides a handy clickable but invisible overlay that acts as a close button.

I’ve been playing around with WebGL lately, just because it’s awesome, and that has resulted in what I think is quite an interesting experiment.

A while ago, my colleague Mike Pelletier at Random Studio showed me how to add an OpenGL displacement filter to a 3D mesh in OpenFrameworks.
Well, I figured that would make for a cool thing to try and replicate using WebGL.

These past weeks I’ve been dealing a lot with animated 3D models in Flash, and learning a big deal about the (im)possibilities of the different file formats and render engines.
I will try to bring some of this newly gained knowledge across, because I found it quite hard to find out what I needed to know just by Googling for it. Hopefully this way I can spare some of you the same frustration I had.

First off, the premise: I needed to create an interactive, animated 3D character in Flash, responding to mouse over events on its various limbs.

Basically, there are two main options in terms of file format: MD2 and Collada. MD2 is smaller, and it basically contains a timeline animation of the model, whereas the Collada format is bigger in size, but can contain an animated IK rig with bones attached to skins and all. This can be useful if you want to interactively control movement of the rig, although that was unnecessary in this case.
The rollover behavior of the limbs wás important however, and MD2 models being one single mesh, this option soon got scratched. Collada it was.

Now, when creating Collada files to load into Flash, you need a quite specific setup. Apparently, the best export plugin to use for this is ColladaMaya or ColladaMax. Turns out however that the most recent version of that plugin is no longer available for free, and furthermore it has turned out that the supplier doesn’t sell it anymore! So unable to find this ‘NextGen’ version of the plugin, we referred to an older version, but that one only works with 3DS MAX 9 and lower. Not 10, which our 3D animator uses. So lots of headaches there, but finally we managed to get our hands on the NextGen version of the plugin (here).

So, exports working, one down. Now for the correct Flash 3D engine.
At that time, I was using Away3D as I gathered that its performance is better than that of PaperVision3D. Initially I was using Away3DLite, but then I wanted to use AS3Mod to dynamically bend 3D planes, and that doesn’t support Away3DLite, just regular Away3D. So alright, I switched.
Then, just when we got all that exporting stuff to work, I discover that Away3D has a REALLY hard time correctly parsing our animated 3D models. What’s up with that? Imagine my annoyance when, after a day of toiling to get this to work, I desperately implement PaperVision3D as a last resort, and it works out of the box with our Collada files! Animation and all. Thank god for that!

Next day. More 3D modeling, texture wrapping, animating, that kind of stuff. Happy that we can finally get on with actually producing stuff.
A few hours into the day I get the latest Collada exports with textures and animation, so that I can start implementing it.
Cue a nearing depression when the animation is not working at all! At this point I’m pulling out my hair, because production is interrupted yet again by the failure of our tools to do the job we expect them to do correctly! No offense Away3D, PaperVision3D and ColladaMax teams, you have done awesome work, but when I can’t simply get a textured 3D character to animate in Flash while observing all the rules we know of and can find online, I tend to lose my nerve a bit. I’m sure you understand.

As it turns out, our model and animation works fine in PaperVision3D when we remove the texture and uv mapping on it. But obviously we need textures.
So right now, I’m sick of all this screwing around with plugin version such and 3ds max version so, render engine this and file format that.
I’ve opted to go for the most solid implementation I know, and that is the MD2 file format in combination with Away3D. Screw mouse overs on limbs, I’ll just fake it with a transparent 2D overlay on top of the 3D scene. I’m done, I have to get some work finished.

UPDATE
———

I have received a tip to check out the AWD project on http://code.google.com/p/awd/
At first glance this looks very promising, although I haven’t played with it a lot yet. I have exported to this format once, and that export ignored any animation, so I’m not sure if it can do that at all or not. But if you’re stuck, by all means try it!