[SHOW] DisplacementMapFilters!

As I've shown already, I'm working on a Geometry Wars clone. Obviously the coolest part of Geometry Wars was how the grid would bend away from powerful attacks or explosions, so I tried to recreate that with DisplacementMapFilters:

http://www.birchlabs.co.uk/GridDisplacement.swf

Now, it's not a perfect recreation of the effect (should be bending away, but instead it's just bending), but I think it's just as cool, and works just as well. In order to properly recreate it, that'd obviously require Drawing API and more complicated maths than I've ever encountered. :)

The difference with this DisplacementMapFilter example (as opposed to, say, the one I tinkered with to make it... not sure who made it, it's been gathering dust in my BitmapData folder for a while) is that it's a lot more optimized. The ripple is pre-rendered (so where there was originally a blur being done in real-time, I'm draw()ing it into an array of BitmapData objects), and I'm using copyPixels() instead of draw() to place the ripple onto the BitmapData object to be displaced.

Nice. I've got a need to do a GWars game too, and I was thinking of displacement maps for the background grid.

Bugger, beaten to it :)

Good work mate,

Squize.

rofl,- that´s a great idea,- that way one could create a tile terraign with heightmap displacement - very cool.

have you used some 3d tools to generate the normal/ displacement maps?- I´ve seen others doing that for generating certain displament effects - though of course it would be even cooler if the displacemet wans´t prerendered but rather interactive - but still very cool

:) Thanks Squizeh. We all know you're still the king when it comes to particles, though. ;)

@Render:

No 3D involved... the DisplacementMapFilter is just a filter you apply to the grid movie clip. This filter is generated from a BitmapData object (easiest to think of it like an alpha channel). The lighter each pixel is in the BitmapData, the more the filter moves down the corresponding pixel in the movie clip. So, for example, if I had a white pixel in the top-left corner of my channel, it'd move the top-left pixel of the grid up by 40 pixels (this value changes depending on the scaleX and scaleY values you choose), and if it were black, the corresponding pixel on the movie clip would be moved down by 40 pixels instead.

In order to get the sloping gradient that the ripple had, I used a blur filter on my channel. :)

As I already said, this exact effect has been shown on FK before (not sure who made it, just found the file in my BitmapData folder)... here's the original file I tweaked:

http://www.birchlabs.co.uk/gridwarp.swf

^ Difference is that I fixed the bugs and optimized it a fair bit. Can't take credit for the blur filter idea, he did it before me.

So as you said, it'd be incredible for heightmapping. I can see some really good hills being made with it, and it's easy as hell to work with. In fact, it'd be very interesting to see it combined with a blurred Perlin Noise effect. :)

I tried doing it the proper way (using the drawing API) just for fun when I was making the original neon, I got it to work, but as expected, it ran at about 10 fps in the standalone flash player. I probably could have optimised it a lot, but obviously it would never have been usable, especially online and with other action going on.

Still this is a nice effect, and sure would look good in game. Good luck with your geometry wars clone :). I still love a good abstract arena shmup, although I've had enough of making neons for the time being.

Ali

no I know how the displacement filter works in Flash,- been playing a year ago myself with it.
I was talking about somethign like this:
http://www3.telus.net/paratrooper/gol_normal_map.jpg

like I said I´ve seen others rendering normal maps or displacement maps as they are called in 2d tools and combining them.
There are even shaders for 3d tools that generate normal map shaders on the fly- just taking a screenshot would be enough.
That way it would distort the image in flash based on the normal map and any projected 3d object could be used as displacement map.

If I am not mistaken the previous author (the one you got a flash file from ) rendered the normal map as well.
here is a read on normal maps in the 3d package modo (but almost any propper 3d tool will do [max,maya,lightwave(with plugin),...]

I'm using essentially the same system as the previous author, and this is the displacement map I'm using:

http://www.birchlabs.co.uk/DisplacementMap.png

Not sure if that's what you're talking about, but I didn't use a 3D program, and neither did he. :s

And returning to your comment on how it'd be cooler if it were interactive rather than pre-rendered, it can be (original file was). Just wouldn't be as fast.

well it seems that you have just a greyscale (each R,G,B value set equal)- wich is just a height map as it only displaces pixels in 1 direction.

A normal/displacement map with the use of different colors for different push- directions could blow the to be diplaced image with more volume.

I used the displament filter in flash for a panorma effect- where I combined color 2 gradients to fake the spheric volume. Something like that wouldn´t be possible with just a greyscale displacement map (displacing like a sphere with volume)
I found a pretty good explaination that explains what I did too:
http://objectpainters.com/blog/?m=200701

I just mentioned 3d applications because they are truly improving rapidly on that topic where most 2d applications still dont have propper support for it. On the nVidia website there is a plugin for photoshop that lets you convert alpha maks to normal maps on the fly - with 3d preview.

Quote:

---

Originally Posted by renderhjs

well it seems that you have just a greyscale (each R,G,B value set equal)- wich is just a height map as it only displaces pixels in 1 direction.

---

It can displace in 2 directions,i mean, in the x and y axis, even if colorX and colorY have the same value, and also can change the powerX and powerY to make one direction to go more then another

Anyway, that tutorial is good, but when comes the part
'apply the base map(see resource for the map or the creation mechanism)'
it could talk a little more...seems to be the most important step...

all you ever need to know about displacement maps is in the docs:

Quote:

---

dstPixel[x, y] = srcPixel[x + ((componentX(x, y) - 128) * scaleX) / 256, y + ((componentY(x, y) - 128) * scaleY) / 256]

---

no need for tricks, just do the math.

V, what framerate you getting if you set it to 120 mate ?

I'm working on a scripted version, and I'm struggling to get it over 50fps atm ( Although that's with a bit of motion blur ).
I know yours is going to be quicker, I'm just interested to see by how much ( It'll mean if I spend more time on this or not ).

Current project is 3 weeks behind, and I'm dicking around with a grid :S

Squize.

:) You know my computer's not famed for being fast, no framerate readings I could give you would be reliable.

I always did know one more way to make it faster; previously, the filter area was the entire stage. This is ideal if we don't know how big the channel was going to be (for example, if we had multiple ripples in different places, we wouldn't know what dimensions we'd need for the BitmapData to fit them in; strictly speaking, we can work this out with simple addition and subtraction, but I didn't consider that at the time). If we are to assume that we're only going to use one ripple animation in the channel (like in this case), we don't need to worry about combining all the ripples into one BitmapData, we can just use the ripple's BitmapData directly.

Anyway, long story short, I saw a major new optimization I could make, so I decided to do it before I shared the source. Added an FPS counter, too. And yes, it's commented to bits. :)

http://www.birchlabs.co.uk/GridDisplacement.zip

I've made the optimizations to the online version, too. If you don't see the FPS counter, you need to refresh:
http://www.birchlabs.co.uk/GridDisplacement.swf

I'm getting 40-60 fps in the browser (just to give you some scope, I'm still on the same Mac I used to work on Polarity ;)), and a constant 60 fps in the standalone player.

runs faster now here (28 fps),- and that on a very old computer, good job :D

That frame counter looks familiar :)

Got mine running at 60/70 ( Forgot to lock() the bitmap, which gave me a boost ), not sure how much more I can get out of it ( Although it handles multiple ripples ).
As soon as it's in a fit state I'll post it up.
Just to flag it up a lot of the clever stuff came from a fla on liquid journey.

Yours is running much quicker than mine, slowest is mid 80's, but in the 100's a lot. I'll have to check your code and see what I can borrow :)

Squize.

:) thanks guys. Glad I could be of service, Squize. ;)

(Would've edited the previous post instead of double-posting, but obviously I can't)...

Made a few changes. The engine now supports multiple objects (just two for the moment, but this can be rectified fairly easily, just need some loops in there):

http://www.birchlabs.co.uk/GridDisplacement3.swf

Now, this is using the entire stage as a displacement filter, so that's 220,000 pixels being displaced. Not ideal. So I optimized it a bit more:

http://www.birchlabs.co.uk/GridDisplacement4.swf

This example culls any unnecessary pixels. :) Was devillishly tricky to get working, loads of local and global coordinate headaches. But the end result is, it's no longer displacing the whole stage - just the area of the two animations and anything in between.

Although, as I write this, I can still think of one more speed boost. Instead of combining the animations into one channel, in some cases (ie, when they're not overlapping too much) it would be faster to just displace both of them separately. I'll try that later today... :)

looks good, but can you slow it down. I can't actually see the effect well :D

if you're looking at ripples, look into the convolution filter, there's some sequence you can plug in which simulates a ripple effect (no displacement) but it looks really nice.

On version 4 it's running mid 40's for me ( Great, means mine isn't that bad :) )

I'm close to reaching the limit with the way mine's set up, I've even speeded up the bitmap line drawing routines ( Based on the class at bytearray.org ).

Squize.

Here's what I've managed to come up with:

http://blog.gamingyourway.com/content/binary/GWars.swf

And for anyone wanting to grab the line plotter code,

http://blog.gamingyourway.com/Defaul...c-8f2a757c3d9b

Squize.

Quote:

---

Originally Posted by Squize

On version 4 it's running mid 40's for me ( Great, means mine isn't that bad :) )

---

Speed is proportional to how far apart the two animations are (the filter covers both animations and all pixels in between). Try it with both on top of each other. For version 5, I'll be making it calculate whether it'll be faster to render both object separately or together (all depends on how big the overlap is). Should speed it up a lot in the more extreme cases.

Great work VENGEANCE MX! This is very interesting stuff you've dug into and its really fast.

Quote:

---

Originally Posted by Squize

I've even speeded up the bitmap line drawing routines ( Based on the class at bytearray.org ).

---

Are these different form the ones I'm using?
graphics.drawCircle(x, y, z);
graphics.beginFill();
graphics.endfill();
and others... Would this be a solution to an extremely fast drawing routine istead of those that I'm using? Squize if you could please provide a link or a demo of it in action that would be great.

Sorry for this turning into a slight hijack V, at least it's the same subject :)

Xploder I posted links to both the current demo, and the line drawing code on the last page.
I've been playing with it more, and the raster based approach is actually quite a lot slower than the drawingAPI version, which came as a bit of a surprise.

In saying that, I've altered the lines to dots, 4 pixels apart ( I thought I should actually look to see how GWars looks rather than doing it from memory ) and the raster version is much, much quicker than using the dashTo prototype ( Which uses the drawing API, it's on adobe's site somewhere if you're interested, it's what I used in the dot vector demo in my sig ).

So if you want to draw lines which need to be cleared every frame, stick with the normal way of doing it. If you need dotted lines, or don't need the lines removing, then use the raster version ( The full version of which is at http://www.bytearray.org/?p=67 ).

Squize.

<hijack>Ah, I see. Must of missed that link. So when it's about drawing Quads and Circles its best to stick with the drawingAPI. Thanks for the explanation.</hijack>

VENGEANCE MX, it's running at 45fps pretty constantly with the spinny thingy. Without it, it was at 60fps and above.
Now, there're so many more game ideas poping up with the use DisplacementMapFilters. Who needs 3D... when you can create an interesting game in 2D... 3D will be a piece of cake.

I hearts my hijack tag

Xploder, the speed drop (as I said) is because the bigger the displacement channel is, the more pixels need to be processed. You'll probably find that the framerate decreases as you move the cursor further away from the spinning line... because the channel will be bigger. It's a rectangle that encompasses both animations, so it'll get bigger if they're further apart (bigger = more processing, of course).

Tomorrow (because tonight I'm watching Heroes :) ) I'm going to further minimize the area which has to be processed, so that in the event of two objects being far away from each other, the pixels in between them will be ignored. If they're overlapping significantly, they'll be combined into one channel, whereas if they're separated enough, they'll be processed separately.

Yes, lots of games could use this effect (would love to see some, and once I've made the final optimization, I'll comment it again and release it), but while we're getting pretty decent framerates with it, you'd still have to be careful what you do alongside it.

Squize, dots sound like they'd look better anyway... the lines at the center of the ripple seemed to get kinda tangled.

Whoa! cool.

I was about to say I had a similar idea last year then noticed the gridwarp example I built. I'd totally forgot that I shared it... my memory must be going.

http://board.flashkit.com/board/showthread.php?t=688299

I'm glad you managed to improve it.. I actually had a similar thing in mind when I built it (a very cool looking g-wars style background) but I gave up in the end. The biggest barrier being that in g-wars the grid can warp so much that it folds over itself. I had an idea that setting multiple displacement maps might get over that... but I was wrong.

Squize, that example looks a lot closer to the technique actually used in the game, but IIRC it wasn't something that could be done fast enough in flash. Each of the points in the grid has it's own gravity and repulsion and affects every other point on the grid... Bit-101 did some experiments a while back using this principle, but with only a couple of hundred points.

I think it might be more feasable in as3 though.

Good work.

Ah, was wondering who made the original file. :)

Alright, I'll start work on the final optimization now...

Oh, btw, I made a mistake when I said that GridDisplacement4.swf was the faster version... 3 is actually the fast one, I made 4 to see how much faster 3 was. :p

lesli, yeah the original effect is really complicated, it's like a material texture effect, with ripping and warping. Looks so stunning.

This is what I finished with last night,
http://blog.gamingyourway.com/conten...y/GWars_v2.swf

Squize.

That looks very cool.

I'm still not clear on how you're doing that, you're not using a displacement filter?....just plotting a distortion for each point from variables?

I'm gonna have to have another go at this I think.

http://www.birchlabs.co.uk/GridDisplacement5.swf

This is REALLY hard to explain, so bear with me.

Version 5's optimization stems from further culling the area that has to be displaced. If we have two objects, we would originally be drawing a rectangle that encompasses both objects, and using that as our filter. However, if the objects are significantly far apart, this rectangle will become very big, with lots of grey pixels between the two objects. This means big slowdown. So in the event that they become that far apart, we use two separate displacement filters (one for each object) rather than one that encompasses both.

Here's how the 'close' routine works (ie, if the size of the encompassing rectangle would be smaller than the sum of the two objects' areas):

Make a new BitmapData (coloured #808080, the 'neutral' displacement colour), big enough to encompass both objects.
copyPixels() both animations onto it (they have alpha channels, so they'll mix rather than overlapping).
Displace the grid by this BitmapData.

Here's how the 'separate' routine works (used when the encompassing rectangle would be bigger than the sum of the two objects' areas):

Imprint both animations onto neutral grey backgrounds, this time without any alpha channel (strictly speaking I do this as part of the pre-rendering loop)
Displace the grid twice (once for each BitmapData).

All in all, it turned out to be a lot more hassle than it was worth. I only see a significant speed boost when the objects are _very_ far apart (as in, a couple of hundred pixels off-screen far apart, and realistically we wouldn't plot them in this situation anyway). However, it does mean that if we get several objects on opposite sides of the screen, we won't need to waste time plotting the area in the middle of the stage.

Next (and I'm assuming final) step is to make the engine support multiple objects more gracefully... currently it's kinda hard-coded, lots of copying and pasting. I need to put some loops and functions in there instead.

Good work V :)

I'd like to see your approach adapted to work with damage maps, which would give blitted displays a nice boost ( So the display would be double buffered in code, and only the damaged / dirty areas on each of the two pages would need updating. It would cut down the number of pixels which would need plotting ).

Squize.

:( 'fraid I've never heard of a damage map, can you elaborate?

It's a way of storing what has changed between frames.

Say you have a static background. When you go to blit a sprite on it, you store the original background away ( ie, a rectangle the size of your sprite ), and then plot the sprite. When you then have to move the sprite, you delete it by replacing it with the original image ( From your damage map, an array pointing to the stored away bitmaps ) and so on.

With the advent of everything being plotted into one bitmap rather than using Flash's own sprites / layers / etc. it may be quicker, you won't be plotting every pixel every time.
It's how things used to be done in the good ol' Amiga days. I don't know how relevant it is to Flash, but it could be worth playing with.

Squize.

Very clever... I think the speed boost in this case would be so fractional that it wouldn't matter (copyPixels() is hella fast, it's the displacement filter that's causing any slowdown).

In terms of the blitting tests... might be worth a look. :) Pretty worn out from coding at the moment, might try it later today, but maybe not.

http://www.birchlabs.co.uk/Invasion5DM.swf

^ Proof that damage maps don't help in Flash. Although admittedly it was probably foreseeable that 7,000+ extra copyPixels() calls and a pool of 7,000+ BitmapDatas would be slower than a single fillRect() call.

Here's the fillRect() version, for comparison:

http://www.birchlabs.co.uk/Invasion5CP.swf

"admittedly it was probably foreseeable..."

It was just a theory I was putting forward blue. If I put 20 ideas forward, law of averages say that 1 of them will be quite good :)

I guess your sprites are all in 1 sprite bitmap, ie the background is in it's own, so you can just run a fillRect to clear it. I'm still confident that if it was all in 1 bitmap you'd get a saving ( Although not 100% confident ;) ).

Nice work in trying it though.

Squize.

have any of you tried simply manipulating the grid without a displacement map. Just using a loop and maths

http://www.sebleedelisle.com/?p=76

I used to have some source files on a magnetic grid/wobbly grid, i reckon with AS3 you could just use that. I'll see if i can find it

nice work though

:) Actually I don't think that's the problem. The main issue is that the arrows are PACKED together (one pixel apart, each with a 13x13 boundary box), so many of the sprites will be clearing a region that's already been covered.

Let's assume we have about 7,000 arrows at all times. 7,000*13*13 = 1,183,000. That's more than 4 times the area of the stage, 700*400 = 280,000 pixels.

Now let's assume that we have one twentieth the number of arrows, so they're no longer packed together 1 pixel apart, and we don't get so much overlap... 350*13 = 4,550. That's significantly less than the stage area!

So, I guess what I'm saying is... it might save us some speed if the sprites don't overlap so much. However, you've got to consider that there's an extra copyPixels() routine being performed per sprite per frame. Might negate the speed boost given by ditching the fillRect().

However, I doubt we even lose much fps from doing a single 700x400 fillRect() per frame. Might be a different story if everything was all in one bitmap (wouldn't do that anyway, though. I like having layers :P), then we'd be doing a 700x400 copyPixels() per frame, but these tests have proven that copyPixels() is at least fairly fast. :)

In conclusion, I guess the reason damage mapping worked well in old games is that there weren't as many sprites being chucked around. There was a much higher proportion of the screen which didn't need to be redrawn and, crucially, there weren't loads of sprites packed together so that the same parts of the map would needlessly get plotted multiple times.

Had a quick go at making a psychedelic effect with the DisplacementMapFilter test (for fun, and for a friend who asked me to). If anyone in the vicinity is vulnerable to seizures, it's probably best not to click the link (doubt it'll do any harm, though):

http://www.birchlabs.co.uk/ForDuncan.swf

Enjoy. :)

how about experimenting with google earth images :p,
or skin photos ._. - like a game where you need to destroy all the insects that move under the skin of a hand before they take over he body

hehe, that reminds me of a doco i saw, some heroin addict thought that there were little mice running around under his skin and he kept trying to scratch them out. Wasn't pretty

anyway...