So, I have been super duper busy the last few weeks, ever since I got back from WWDC, trying to get Snowferno all ready for beta (and ultimately release). If the in house testing goes well then we will be start the beta testing in just a few days.
If you want to beta test, and have an iphone or ipod touch with OS 2.2.1 or better on it, then sign up right now!
Anyhow, as part of the push to get the beta out the door I have made a few more up-to-date gameplay videos/trailers:
"Beware Of Fire":
"Not That Way"
Check them out!
We will have these up on the main site soon, so for now, they are exclusive! (well not really at all, but whatever)
I dont know if I will have time or the inclination to blog every day. but I might as well start now :-)
Just got here on saturday, conference starts monday. Leonie and I wandered down to the convention center to have a look (as you do), and I snapped this photo:
I am posting this sunday morning because I was too tired and couldnt be bothered to walk all the way downstairs to the lobby for free wifi :-) altho the blgo still thinks I am on NYC time.
Astute readers will already know that I am using Unity3d to build a new iPhone game: Snowferno. You might also already know that I do lots of work with multi-touch stuff, and recently have begun to marry the two technologies and use Unity to build multi-touch apps.
This is actually pretty fantastic as it allows you to build MT apps very quickly and they still look cool, and mostly the bugs and stability are handled by someone else (ie the unity guys) so it streamlines the process quite a bit.
Anyway, the reason for this particular post was just to put up some fun stuff I have been doing with Unity this past weekend. Sandor, the man behind all the good ideas, wanted to do some cool stuff with MT and needed some groovy ripples on water effect for a project he is working on. SO I went out to try and find a nice simple solution to do some very basic water simulation.
After finding lots of super duper complicated ways to do realistic fluid simulations that were doing my head in, or lots of crazy custom shaders to do ripple effects (also doing my head in) I found this guys site, which details an old-school method to simulate water ripples.
Old school is more my speed, and this algorithm basically creates a height map that behaves kinda sorta like water might behave. (which is really close enough for me).
So, first up i do what I always do, which is build a test app in the format which I am most accustomed at the moment, which, this week is as a cocoa app. Here are a few screenshots:
Basically it is just the algorithm above applied to a black and white bitmap. pretty standard stuff. If you want, here is the xcode project:
Anyhow, once I worked out all the kinks in cocoa, I moved to the slightly less familiar world of unity scripting. I started with javascript, but the various variable casting that needed to go on (casting floats to ints and back again) were not working the way that I thought they should (I really dont know what javascript is doing) and it was pissing me off, so I switched to using C# to script the object in Unity. Having never used C# before a few of the syntax bits were a bit foreign to me, but at it's heart it is really just C, so that was much nicer in terms of casting variable types and other esoteric stuff like that.
Still shots of the actual effect dont look like anything because you need to motion of the ripples to be able to see it, but you can see the mesh deformation here in unity:
In unity, what I did was build a large mesh (in the case of the pics it was 128 x 128 vertices. (well, technically it was 128x128 sections in cheetah3d, which ends up being 127x127 vertices and something like a kasquillion triangles) but the script works with any planar set of vertices as long as they are evenly spaced.
I removed some of the auto-generated stuff that Unity adds into the projects to keep the file size down a bit. The downside to this pruning is that if you want to see it in action, you need to reattach the script and the texture to the mesh.
Then you can adjust the various settings:
The rows and cols need to match the number of sections the mesh has, (it will actually be one less than the total number of vertices across the plane. It seems a bit odd to do it this way, but that made making the meshes in cheetah simpler (ie mesh in cheetah has X x Y sections, script has X x Y rows)) if the cols dont match it will error out.
The splash force can be anything from 10 - 65000 ish.. it is effectively how hard you hit the mesh when you want to make a splash. ultimately if you have the wave height capped, it will boil down to how long you want the waves to propigate for. I find values in the 1000 - 10000 range seem to make pleasing results.
the max wave height is a cap on the wave height. Again, between 1 and 2 seem to make nice waves, anything over 4 or 5 gets a bit wacky.
The dampner is how quickly the waves get killed. numbers close to 1 make the waves propagate for longer. if you set it below 0.9 the waves barely go anywhere. there is actually a pretty big difference to be found in the very upper limits of the dampner. For instance, set the waves height to 2, the force to 10000 and the dampner to 0.99. Do a splash.. this will keep the mesh moving for about 3 - 4 seconds before it is still again. Now change the dampner to 0.9999 and it will go for about 4 times as long.
Anyhow, here is a short video of the whole process, which mostly survived the youtube compression: (it looks slightly better in high quality, but not much... I could have done a better job of making a high def video, but: too lazy)
Oh, and the tunes in that video are from the Snowferno soundtrack. Brent at Fatlab Music wrote that one, and he gave me special permission to use it for my silly little demo video here, so thanks for that Brent!!
Cheers!
-B
Oh and BTW, there is absolutely no implied warranty or whatever for any of the code above, so if you load it up and your computer gives your cat the pig flu because of it, I cannot be held responsible.
If you are also going to be there, and you want to meet up and get a beer, or talk about anything on my blog or anything else really, then drop me a line at support@benbritten.com, or follow my rarely updated twitter: http://twitter.com/benbritten. I plan to use it during WWDC to help people find me and to help me find people. Otherwise I rarely use it, so dont go looking for profound wisdom from my twitter feed.
Also, we are going to be doing a development blog to talk about how we got to where we are as well as what we are doing as we finish up the game. The first post (by me :-) is here. I will probably cross-post blurbs from the devlopment blog here just to get maximum coverage (in other words: please buy our game once it is out!! :-)
I just put up an update to the xPrexxo code. Now you can do movies as well as static images. More details (tho not many more :-) can be found at the xTuio website.
I must apologize as I have been out of the loop on NUI group happenings for a few months due to high levels of busyness. Luckily, Sandor has pointed me at some TUIO formatting discussions and I am going to try and keep BBTouch up to date with those sorts of things (i fully support expanding the TUIO protocol in a nice standard way, It sounds like tBeta is leading that charge and good on 'em.)
Anyway, from what i can gather in my 5 minutes of research (reading some NUI forumposts) is that currently some of the Quartz composer and Max plugins that NUI group helps maintain are basically advancing in TUIO protocol technology and BBTouch and some of the other 'old' trackers are not working well with them.
This is due to the fact that tBeta is using a slightly newer form of TUIO which includes the height and width of the cursor object in the data stream (ie the blob bounding box) I think this is a great addition and could use it in my own TUIO client apps straight away.
Anyhow, I am going to try and add the height and width params to the BBTouch TUIO stream (in some configurable way so that you can choose to not use them if you are using an older client) hopefully by the end of this week, busyness permitting.
many thanks to ScreamingDrills for finding a nasty little bug: Turns out when you are in the filter config window, you used to be able to put in all sorts of numbers that would break things. I added some nice constraints, but did a poor job of it :-) as of r157 you could still squeeze in a few bad numbers (ie 1 for any of the kernel sizes) so I went and fixed all that up. SO!
update your stuff to r158. (there is a new binary on the opentouch code site)
NOTE: Don't forget that BBTouch requires openCV.framework now. so be sure to grab that as well and stick it into your ~/Library/Frameworks folder. (you may have to make this folder).. It is actually a private framework, and I have been playing around with trying to get it to be part of the BBTouch codebase, but googlecode is not playing nice with it (it claims to be locked, which is possible since I got it from someone else who had compiled it. So anyway, i haven't had the time to go in and see why SVN thinks it is locked and so it is still not technically part of BBTouch, so you have to install it manually, my apologies)
But! if you do not install it, then BBTouch will brash on load. so if you re having crash on load issues, start with openCV. (BTW I uploaded the version that I am testing against to the opentouch downloads page, so you can get it there. (the link to the right that says "Fairly recent binaries").
Anyhow, I am in the process of trying to find the time to get around to thinking about updating the documentation to include the above warning about openCV as well as all the new filtery stuff. But I havent had the chance, so tell your friends.
This is a quick video (slightly better quality than the last one, altho i do manage to get in the way of the camera a few times :-) of one of the apps that i wrote for Sandor at Corporate Design Cologne. It is a combination of multi-touch coverflow (sometimes with actual covers :-) and the light box app (which I have decided is basically like the hello-world of multi-touch apps, everyone needs to write one at least once :-)
Anyhow this is all running on my prototype table which is a diffused illumination setup, the tracker is BBTouch and it is all using TUIO to communicate. The tech is all core animation using CALayers. there is lots of mipmapping going on to keep the performance up even when there are tons of images, and it works quite nicely even on my macbook pro. BBtouch never tops 50% processor and xPrexxo is similar.
I just wanted to take a minute to pimp a cool project that I just found out about:
Some of you may be aware of the monome project: http://monome.org/ I think these guys have a great deal in common with the Multi-touch community :-)
Anyhow, there is a cool iphone port of the monome stuff called Haplome: http://toddtreece.com/haplome/ it allows you to pretend you have a monome button array on your iPhone. fun stuff.
Anyhow, the reason this is topical to my lame site is that he is using BBOSC to help talk to the other OSC apps thet can play nice with the monome stuff. So there you go!
Recent Comments