It's been more than i year that i had this idea. It started with my LudumDare entry DiggyDig in december 2011.

The idea i had was an image based terrain, where every pixel is handled as a particle, where each material behaves in a predefined way, using cellular automata to animate them. You would dig tunnels and maybe it will collapse behind you. Water would flow in a natural way (as natural as cellular automata can get anyways). I explored this idea in a later LudumDare when i created Unterholz to test scalability for a lot of animated particles. Turns out animating every pixel independently is quite the effort for the cpu. I probably could have utilized OpenCL to outsource the workload to the gpu, and that might have worked fast enough on a bigger scale, but i found pixels to bothersome to work with. And while working in a grid has several advantages, it also has disadvantages. Particles could overlap, not bounce correctly or all sorts of funny stuff.

Another quick adventure was trying to port the idea to a voxelspace with a dense resolution (0.125 per voxel, instead of 1 in minecraft, for reference). Turns out that the amount of data would skyrocket without some sort of compression, and i just felt it wasnt worth it.

Now several month later i thought i should revisit the idea using actual particles. Particle behaviour would be determined by material, as before, the bouncyness and stickyness properties, if they'd flow or tumble.

_________________
Long pork is people!

wzl's burrow

The first test was implementing a basic particle behavior, then adding gravity and some rules to render them inactive. I started by brute-forcing the particle collision (each particle against every other), and rendering particles by using one vbo each. 500 particles was the maximum i could get with that approach so it was time to optimize (early optimization is so good, despite everyone saying it's not! And sometimes can be crucial to prove if a concept can be realized even). I pushed all particles into one vbo, and tried a static render test. 1million at 30fps was a pretty good look-out.

After fixing the mesh upload to not push the total data, but only the changed ranges, i partitioned the space into a grid to reduce the amount of collision tests. Currently it runs with a couple thousand inactive particles, with around 150 being active, at a steady 60fps, so i consider the prototype a success.

I'll stress-test this further to see where the limits are, but i have some optimizations i can yet add.

The game i have in mind would be something probably best described as similar to terraria, but it is so far off that i thought i could make another demo with it.

Do you remember scorched earth? Yes! I'll clone that using the particle terrain.

Super Scorched Earth Ultra HD Clone Remake Deluxe

It will be a fun exercise, testing the terrain features and maybe even make a full-featured game out of it!

_________________
Long pork is people!

wzl's burrow

Looks like you had a lot of fun!

_________________
My project: Messing about in FreeRCT, dev blog, and IRC #freerct at oftc.net

Looking very cool. I never played Scorched Earth as I was an Amiga user, but I did lose many evenings to Pocket Tanks

I often pondered the terrain deformation in PT. I figured that you'd only need to process a vertical strip the width of the weapon affected area. I guess your terrain might have landslides that fall in from beyond the edges of the crater?

_________________
10 PRINT "Bad Monkey ";
20 GOTO 10

Yes it is a lot of fun indeed



Yeah indeed. it's very simple and straight forward. Unlike this beast.
After i finished work last night and didn't run into an immediate wall i was rejoicing. Not so much today.

I was applying some stress tests and i really need to figure out how to further optimize this. I can basically have endless amounts of static particles. More than enough at least.

If it comes to animation only, it seems my current limit is around 1800. A fairly low count really. Not sure what i'm doing wrong here.
If i take collisions into account aswell i can only have 300-400 active particles before frames drop.

I tried a few tiny optimizations here and there, tried to prevent overhead mainly, but that only pushed the limit minimally.

This is a little catastrophe. While around 500active particles might work fine for casual gameplay in a terraria-esque world, it completely annihilates my idea of fluid dynamics (and landslides as codehead mentioned. all sorts of fun stuff).

This is bad news for a tank game aswell. if you shoot a mountain you want it to crumble. It should be a neato techdemo, maybe even a novelty sort of. Not at this point though. I need to figure how to speed things up.

One option will be opencl but i'm a little scared

Anyways, here's what i did today in a nutshell: http://www.youtube.com/watch?v=qRnYDd_nTss

_________________
Long pork is people!

wzl's burrow

By animation you mean the movement of the particles or some more complex dynamics and distortions made out of particles?

_________________
Did you ever wonder, how time works?

Yeah, simple position += velocity movement.

I managed to optimize it a bit more to get around 4k particles before frames start to drop by changing my vector class a bit (the most often called routines in this project) and i changed the mesh upload to be in the render method instead of update (which is called less frequently).

What i will try now is uploading a single point data for each particle and use the geometry shader to create the polygons for me, this should provide a major boost (at least thats what i hope). I wanted to play around with geometry shaders anyways, so thats a good opportunity.

_________________
Long pork is people!

wzl's burrow