I think this article about compressive sensing is not overly difficult: your_link_text Even if it is I have some very simple Moving Average Filter Compressive Sensing code here: your_link_text I hope that makes it easier. Sean O'Connor

What's the point? Where would you use this in a game?

Well compression of terrain maps. Compression of game state for transmission over the internet. Game AI where you would learn low dimensional manifolds from large but sparse data sets. What's the use in getting out of the bed in the morning?

Quote:Original post by redtea
Well compression of terrain maps. Compression of game state for transmission over the internet.

I don't think the cited technique is suited for these tasks which already benefit from traditional compression methods. As far as I can tell the main benefit is to avoid requiring a high resolution (and largely redundant) sample up front, which is not a problem with the examples given.

I'm a rational person (I like to think). Maybe CS is not particularly relevant to games but it is better than another message on A* is it not?
I present it as an intellectual curiosity, if you like.
If you can use CS/Random projection to learn low dimensional manifolds then that is potentially a disruptive technology. We do live in a sparse world, the number of 256*256 images that represent anything understandable divided by the number of 256*256 images you can make at random is a number very, very close to zero.
However I take it a practical point that there may be nothing in CS that is of use in games yet.

Quote:Original post by alexjc
Once again, would it be fast enough for animation decompression at runtime, and does motion capture data fit well with the assumptions made by CS?

To me, CS seems very cool, but for your mocap example it looks like a round peg in a square hole. It's not meant to be a general purpose compression algorithm, but a smart way of -- as the name says -- doing sensing.

The whole point of compressive sensing is that you can avoid taking tons of samples of the environment. A motivating question is, "Why do digital cameras acquire millions of samples of an image only to throw most of that data away with JPEG compression?" But for your mocap example, you already have the samples!!

Anyway, to answer your questions...

Sampling with CS is very fast of course, but reconstruction is the solution to a convex optimization problem and therefore slower*. Also, it's a batch process; it works on signals-as-a-whole, not individual samples. This throws a small wrench into your "on the fly" idea. That said, you could of course chop a signal into chunks or otherwise limit the support of your basis vectors, and operate on pieces independently.

* That said, convex optimization can be done quite fast these days!! In fact I attended a presentation by Stephen Boyd where he talked about a "convex program compiler" (I don't remember his precise phrase) that generates C code tailored to the specific sparsity patterns of a given convex optimization problem; with this he was able to generate each sample of a control signal for a mechanical system (at some reasonably-high rate) as a solution to a separate convex problem. So it is possible to do this quite fast.

Would y'all agree with this assessment?