GDR Forum Index
Podcast Podcast
Dev Dev Logs
Search Search
RSS RSS
Register Register
Log in Log in
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Random "Pattern" Generator
View previous topic :: View next topic  
Author Message
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1617
Location: Your consciousness.
PostPosted: Sun Mar 28, 2010 3:00 am    Post subject: Development Log - Random "Pattern" Generator Reply with quote

I had this idea in one of my dreams a few weeks ago. I woke up that morning and was thrilled to implement it but my back-pains and my coders-arm (from the job) didn't agree.

So well, I kept the idea in the back of my head all the time, kept thinking about it, let it grow a bit and now I'm writing it down in this development log with the hopes that this will nag me enough to eventually start with the implementation.

For the fun of it, look at this concept doodle first, think what it could be doing and only read the description after that and see how close you were. :)
figure 1, concept sketch


Description
The general idea is to generate random patterns (whose shapes I can't begin to imagine, which is why I think this'll be interesting to code) by firing moving particles onto a canvas.

  • the canvas will be bitmap (as in, a grid of pixels with fixed and limited side-lengths, the side lengths can be a paramter)
  • the canvas will start "empty" (white)
  • there will be "pixel emitters", which are objects that have an angle(direction they face), a rotation speed, a movement speed and a path along which they will move
  • for simplicity the path will always be a circle in the first iteration, so each pixel emitter will get a center point and a radius in addition to the above properties
  • the pixel emitters will shoot moving pixels into the direction they're currently facing, whether or not they shoot a pixel at any given timeframe must be decided randomly and with taking a probability into consideration (checking random value from 1 to 100 to be below that probability should do the trick)
  • pixel particles that will never reach the canvas can be discarded immediately (or maybe bounce back on some freely selectable perimeter)
  • a particle that is traveling over the canvas will have a probability (this should probably be very low) to get "stuck" (to vanish and color the last known position on the canvas to black)
  • the probability for a particle to get stuck can be globally set equal for each pixel on the canvas or could also be randomly decided for each pixel within a given range of probabilities
  • a particle also gets stuck on the canvas if any adjacent pixel is not white (this will form clusters of colored pixels)
  • results must be reproducable by using the same set of parameters, the same number of particle emitters and the same seed for the random number generator used for all decisions


Any questions, thoughts, comments?

I'll probably won't find enough time or motivation to start anytime soon, as work and Dwarf Fortress are keeping me quite busy.

ideas for versions after the first one:
  • for added fun, future particle emitters should have other paths to move along (rectangles, lines, curves, polygons) and more control over their facing angle (always face "inside" of path sitting orthogonally to the current path segment, always face "outside", have a fixed orientation angle)
  • add a new particle type for particles that never get stuck themselves but which destroy existing particles again or which shoot these off to become unstuck and moving again
  • give particles and ability to travel over already stuck particles and make them stuck when they're on top of those (and then lighten up the black pixel a bit or even reverse the whole color scheme to use black canvas and gray to white pixels to generate height-maps from the results)
  • make it 3D and only allow initial stuck-ability on certain layers (e.g. initially freely moving particles can only get stuck on a "ground layer" and then things will pile up or grow down from there)
  • head explodes..


If only the implementation parts was as easy as the design/idea part. :)
_________________
0xDB
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9330
Location: Not Finland
PostPosted: Sun Mar 28, 2010 5:28 am    Post subject: Reply with quote

It'll work, and it'll certainly be random. You'll potentially get "clumping" or clusters of pixels if you only use a few emitters.

Odd, I was working on noise generation routines last night. I guess we were operating on a similar wavelength :)
View user's profile Send private message Visit poster's website
sonrisu
Moderator

Joined: 31 Aug 2005
Posts: 4955
Location: Silicon Valley!
PostPosted: Sun Mar 28, 2010 7:36 am    Post subject: Reply with quote

From what I am looking at it seems like it would be fun just to see it in action. Also, it would be cool, if you do implement this, to allow toggling the visibility of the cannons and paths on and off (thus making it look just like the drawing).
_________________
loomsoft :]
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1617
Location: Your consciousness.
PostPosted: Fri May 14, 2010 10:08 am    Post subject: Reply with quote

Finally found the motivation to start on this and here's what I've got so far (after about three hours of work). I've reused all the math and initialization code from TankGame to speed up project-setup a bit. Still, I'm spoiled by all the C# and .NET code I write at the job and forgot over time how tedious all that "low-level"(hah!) C++ can be.

So far there's two hard-coded emitters and a single canvas. There is no logic for the shooting of pixels yet, so currently all they do is move along their paths and rotate their guns (I wanted to get something visible up as fast as possible to keep me motivated).

While I was watching it in action I thought I should do it right from the beginning and make the canvas more like the emitters (as in, there should be an arbitrary number of canvases, freely position-and-sizeable). So first thing next time I work on this will be refactoring the canvas into a separate class.

screenshot:


Also, I've decided the first working version will be completely random/no gui/no user input (because that crap alone will take days to do properly and I just want to see some patterns first).

current to-do list (by priority):
* make canvas class ("stickability" / position / size)
* make pixel-particle class (position / velocity)
* implement pixel/canvas moving/sticking/clumping logic (hehe, moving canvases would be cool as well and moving emitters (their central points moving) too...)
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1617
Location: Your consciousness.
PostPosted: Fri May 14, 2010 2:21 pm    Post subject: Reply with quote

Few hours later and I've got the canvas class, pixel particles and all the basic sticking logic in there.

The next step will be to find interesting parameters. Currently it doesn't seem all that very random and the pixels tend to clump along the emitter paths and the canvas edges (which makes sense thinking about it).

I should probably let the stick-ability for each canvas not be a constant throughout the whole run-time but rather let it swing back and forth between two boundary stick-probability values to prevent that path clumping. Another idea is to let pixels have a probability to tunnel through existing clumps to allow them to travel further into the heart of any given canvas (to prevent the clumping on the edges). Then again, with moving canvases and emitters, maybe these problems would go away without further tweaks... will try everything but not today anymore.

another screenshot:

_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1617
Location: Your consciousness.
PostPosted: Sat May 15, 2010 2:56 am    Post subject: Reply with quote

I have changed the sticking behaviour to allow/force pixel particles to travel across already stuck ones as I noticed the clumps stopped growing after some time (which was because pixels got stuck on the same position where there already was a pixel set).

I'm getting unexpected results (at least *I* didn't expect any of it) which makes it fun to experiment more with this.

Next I will implement moving emitters and moving canvases, which will hopefully eliminate those strange stalactite-like formations...

screenshot 03 (two canvase, three emitters):


screenshot 04 (same as 03 display, only canvases displayed and after more iterations):


screenshot 05 (single canvas, single emitter):


screenshot 06 (same setup as 05 but with changes to the pixel emitting probability, movement and rotation speed/direction):

_________________
0xDB
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9330
Location: Not Finland
PostPosted: Sat May 15, 2010 6:28 am    Post subject: Reply with quote

Ah, now we're starting to get some interesting results. You've gotten some nice moire patterns in that last shot.
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1617
Location: Your consciousness.
PostPosted: Sat May 15, 2010 1:37 pm    Post subject: Reply with quote

I only hope they'll get more interesting and varied as I go along.

Not making much progress as I'm wasting hours and hours just changing parameters and watching it run. Only new features I've got in now is a linear swing back and forth between two different radius values for the emitter paths. The speed at which the radius changes from the smaller to the bigger and back is also a parameter.
Also, pixels do now bounce back from the screen borders instead of just being deleted then.

While I'm working on this I'm hacking in a lot of stuff in a pretty dirty and unstructured way, so I'm starting to want to clean it all up, maybe even restart/refactor it so I can have much more cool stuff (like "PropertyAnimator" classes of which an arbitrary number of them could be attached to basically any property of any other object and manipulate it on every tick... this way I could easily make movements non-linear and much more interesting... think of the unlimited possibilities!).

I'm also thinking of rotating canvases and rewriting the whole visualization part to allow zooming in and out... and other fun objects like particle bouncers (what the screenborder does now, just with arbitrary shapes (maybe circles and rectangles to keep things simple for a start).

With an open space I would have to give particles a lifetime though, so they wouldn't go on forever voyaging into the nothing if they went off away from the action. (This could be useful right now as well as I sometimes get particles that never hit the canvas and just bounce back and fourth happily between screenborders.)

I need more time for this.

Oh, screens...

screenshot 07 (with the new feature of animated radius property and particle bouncing):


screenshot 08 (the black started to feel menacing on me):


screenshot 09:

_________________
0xDB
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9330
Location: Not Finland
PostPosted: Sat May 15, 2010 2:47 pm    Post subject: Reply with quote

Damn, shot #9 is very cool. It almost looks like a pile of letters all jumbled up, especially toward the edges.
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1617
Location: Your consciousness.
PostPosted: Sun May 16, 2010 1:16 am    Post subject: Reply with quote

To me it looked like a dissolving flower. Hehe, I have a feeling this will be a bit like watching cloud formations or Rorschach images.

...

She's spinning! Spinning!! wheee!

screenshots 12 and 13:

_________________
0xDB
View user's profile Send private message Visit poster's website
n29
Developer

Joined: 13 Sep 2005
Posts: 879

PostPosted: Sun May 16, 2010 4:06 am    Post subject: Reply with quote

Cool, some of those look like plots of vector fields for differential equations (screenshot 6). So apparently your technique is solving differential equations somehow.
View user's profile Send private message
Gil
Developer

Joined: 14 Nov 2005
Posts: 2341
Location: Belgium
PostPosted: Sun May 16, 2010 9:49 am    Post subject: Reply with quote

Just regular old Moiré patterns, I'm afraid, they occur in lots of things.
_________________
PoV: I had to wear pants today. Fo shame!
View user's profile Send private message Visit poster's website
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Random "Pattern" Generator
Game Developer's Refuge
is proudly hosted by,

HostGator

All trademarks and copyrights on this page are owned by their respective owners. All comments owned by their respective posters.
phpBB code © 2001, 2005 phpBB Group. Other message board code © Kevin Reems.