The post River – Paths over Time appeared first on Greg Tatum.

]]>This is a coding exploration inspired by flying over rivers while flying. I was inspired by the paths that they traveled and left over time.

The post River – Paths over Time appeared first on Greg Tatum.

]]>The post Wandering Lines – Move Until a Collision appeared first on Greg Tatum.

]]>Having been inspired by the work of Anders Hoff, I decided to try my hand at doing some algorithmic line growth. With this piece lines wander through a 3d noise field until they collide with an existing line. The lines regenerate in a diamond space.

Drawing lines is interesting because the moment you draw more than one, and care about how they interact, you have a fairly intense algorithm to solve. In Big O notation this would be O(n^2). Luckily I remembered a pretty nice write up by Mikola Lysenko on this very subject. Lines are 2 points connected together, and the space they are broken up into can be represented by a box. Game developers have come up with lots of optimizations for this type of set up. I decided to go for an R-tree look-up. Theoretically it can get the complexity down to O(log n). I went with the nice rbush module for my R-tree implementation based on Mik’s write up, which showed some very favorable results.

In general O(n^2) algorithms are pretty scary to write as you can’t add as many entities on the screen at once, so I went ahead and optimized this piece away. The first step was to build up my R-tree graph of line additions as the lines are accumulated on the screen. However, even if the line’s bounding boxes intersect, it doesn’t necessarily mean that the lines themselves are intersecting. The next step was to figure out if two line segments collide. Surprisingly I found this difficult to figure out. It seems like an easy problem, but I had to do lots of searching to finally come to a solution. Ultimately it’s abstracted away to a pretty simple function. After writing some simple test visualizations I was finally on my way to play around with the algorithm.

A favorite trick of mine is to take a multi-dimensional noise function, and then run parameters through it. I took a 3d simplex noise, then fed the X and Y screen coordinate into the first 2 parameters, and then the time through the final dimension. With this nice slowly changing and smooth noise value I determined the heading of the line. With this type of setup the lines tend to converge around the same points, which is aesthetically quite nice. Moving through the noise function over time means that the later generations of lines end up moving counter to the existing long lines creating a complex inner structure.

My initial attempts at solving this tangle of code end up having a pretty horrible performance bottle neck. My laptop probably got the hottest it’s ever been running on this piece, which is saying something. After doing some profiling I found that my draw calls were the limiting factors. I was re-drawing a complex structure in the browser every frame, which ended up being 10,000+ lines. This was a bad idea. Luckily the fix was pretty simple with only drawing the new lines and preserving the previous colors drawn. If the screen was resized then the entire structure has to be re-generated. This can be pretty brutal.

Notice how the FPS go down and down, being blocked by the rendering.

After the fix, it runs fast!

So now I had some pretty lines drawing on the screen that updated real-time. The next trick was ironing out any inconsistencies with being able to perfectly regenerate a simulation through multiple runs. I really like using psuedo-random number generators (PRNG) with my code. You can build something that ultimately is reproducible. The generator takes a seed value from the hash of the URL, or something random that gets logged to the console. If this value is fed back in then the visualization will perfectly be able to recreate the previous scene. This is a nice feature to build in from the beginning, and is easy as only using PRNGs. In my visualization hit the S key to save a random run to the URL to make it reproducible.

Finally I ended up mapping all of the position values to an idealized space of 0 to 1 in the X and Y directions. My visualization was dependent on the screen size to begin with, which was no good. I love the 0 to 1 range for visualizations because then you can scale arbitrary values as you see fit. And finally with my visualization I ended up using a rotation matrix to rotate the results into a diamond shape (it started out as a square).

The post Wandering Lines – Move Until a Collision appeared first on Greg Tatum.

]]>The post Growth – Fungal State appeared first on Greg Tatum.

]]>Growing geometry as I’ve come to find out is a fairly difficult programming problem to solve. Rather than regenerate geometry and figuring out the algorithms for connecting the topology of additional vertices and faces, I’m playing around with the manipulation of existing geometry. This particular algorithm is similar to other fungus-like growth patterns I’ve seen online. While mine didn’t get the same ordered feel as my references, I did quite enjoy the blobby growing effect.

This example is built ontop of three.js. There aren’t any custom shaders with this one. My first step in the coding process was to generate some geometry. I went with an icosahedron geometry generator, as it creates a more uniform surface layout for the mesh. The slider drives the amount of subdivisions of that surface. No new points are created after this initial generation.

The manipulation of the surface was done through a large amount of bones placed randomly about the surface (which can be seen as small dots on the screen.) These bones represent a matrix transformation, and the geometry’s vertices are each associated with a set of the nearest bones. The weight (how much the bone affects the points) is blended by how nearby the bone is.

Finally I optimized the nearest neighbor lookups for the bones using a kd tree to speed up the expensive problem of finding the nearest bones. The algorithm for moving these bones consists of each individual bone attempting to maintain a set distance from the nearest bones. It begins to move out of the way if a neighboring bone is too close. The growth in the Y dimension is clamped to a lower amount so the growth spreads more horizontally. Finally the distance to check for neighboring points grows by a percentage over time making the growth get larger and larger.

The post Growth – Fungal State appeared first on Greg Tatum.

]]>The post Growth – Incremental Additions appeared first on Greg Tatum.

]]>Growth in life is mesmerizing with the intricacies of the structures that are created. This programming poem series is an exploration of what happens with small incremental additions. The first installment features the dynamic growth of a 3d tree structure.

I knew I wanted to start a growth series, but the topic seemed pretty difficult to even begin, so I started with what was comfortable, trees. I explored the idea of recursive tree functions with my previous Recursivity series. With this new code I took a much more functional approach, which really lends itself towards a recursive tree structure. For me it was a big experiment in abandoning some object oriented approaches that I was really comfortable with. Ultimately I was happy with this more functional direction, but I would change some of the approach now if I were to refactor the code.

The hard problem to solve with growth is how to create new geometry on the fly in a realtime simulation. How do you actually grow a limb on a tree and add these new structures to it in real time? Rather than solve this problem I decided to generate all of the geometry at the beginning. In fact, the tree geometry by itself has no X or Y variation. It’s a tube the shoots straight up in the Z axis. This tube has branching, but each branch shares the same vertical space. This code breaks down into a few simple steps. First create some tube geometry that starts at some value, and then moves up in space a certain length. Then at the end of that tube create 1, 2, 3 or more tubes that all share the same space, and then keep on recursing through these steps until some arbitrary depth is reached.

The next trick is to get these tubes to move in real-time. The solution for this problem is bones. The CPU is relatively slow at performing a very large amount of matrix multiplications, but the GPU is quite fast at it due to its parallel architecture. The vertices in each tube segment are associated with different bones. These bones themselves are essentially transform matrices. All of the geometry and bones are calculated in JavaScript on the CPU. This data is then uploaded to the GPU (with the help of three.js’s skinning system) and used in the shader program on the graphics card to manipulate the individual vertices.

Finally the bone matrices are all packed into a texture and reconstructed in the shader. Each vertex has attribute data that consists of bone indices (to look up which bone to use) and bone weights (to decide how much of that transformation affects that vertex.) During the geometry generation phase it’s necessary to generate these additional values to associate each tube with the appropriate bones within the system. The shader then combines all of these components together in a really fast manner.

Note in that last detail shot that the bone weighting and positioning is only “good enough” and could have been done more “correctly”. Notice how at the base the shares the same vertices.

With this system in place I looped over a growing function that used three.js’s built-in scene hierarchy to dynamically “grow” the tree. The scales and rotations of the root bones affected the transformations of each branch down the line. Scaling down by even a modest amount quickly magnified down the branches of the trees. Additionally I ran the elapsed time value through sin functions with a random time scaling value and random rotation amount to make the tree sway in space. This randomness took the tree from a straight pole of geometry all sharing the same vertical space, to the creepy and dynamic tree structure that is displayed on the screen.

Probably the hardest part of this exercise was figuring out the skinning system within three.js. Luckily I got it all figured out and sent in a pull request with some documentation on how everything works.

The post Growth – Incremental Additions appeared first on Greg Tatum.

]]>The post Low Poly Washington appeared first on Greg Tatum.

]]>The post Low Poly Cardinal appeared first on Greg Tatum.

]]>The post Low Poly Trees appeared first on Greg Tatum.

]]>The post Debug Landscape appeared first on Greg Tatum.

]]>The post Debug Landscape appeared first on Greg Tatum.

]]>The post Polar Space – A Retro Space Game appeared first on Greg Tatum.

]]>I’m straying a little bit from my programming poem metaphor, and dipping a toe into online gaming. I’m taking a similar approach to my poems and iteratively developing levels for a space shoot ’em up. It works on mobile and desktop.

The post Polar Space – A Retro Space Game appeared first on Greg Tatum.

]]>The post Gravity #4 – Self Attraction with Friction appeared first on Greg Tatum.

]]>This poem doesn’t follow as strictly to the rules of Gravity. There is some friction that was tuned to make the arrows behave in an interesting manner, otherwise they didn’t stick together enough to be visually appealing.

The post Gravity #4 – Self Attraction with Friction appeared first on Greg Tatum.

]]>The post Adventures of Mr Rat – Episode 1: “Frack” appeared first on Greg Tatum.

]]>The post Adventures of Mr Rat – Episode 1: “Frack” appeared first on Greg Tatum.

]]>The post Wind-Up Smasher of Oz appeared first on Greg Tatum.

]]>The post Wind-Up Smasher of Oz appeared first on Greg Tatum.

]]>The post The Wind-Up Bird appeared first on Greg Tatum.

]]>The post The Wind-Up Bird appeared first on Greg Tatum.

]]>The post Journey of Oz appeared first on Greg Tatum.

]]>The post Journey of Oz appeared first on Greg Tatum.

]]>The post Gravity #3 – Directed Gravitational Paths appeared first on Greg Tatum.

]]>NASA calculated orbital paths using slide rulers, this programming poems uses the mouse to direct arrows at “planetary” bodies. I enjoy trying to see how many loops I can make with it.

The post Gravity #3 – Directed Gravitational Paths appeared first on Greg Tatum.

]]>The post Recursivity #5 – Draw a colorful 3d tree appeared first on Greg Tatum.

]]>This poem adds another dimension to the 2d tree drawing poem. I love how these ideas can grow upon themselves.

The post Recursivity #5 – Draw a colorful 3d tree appeared first on Greg Tatum.

]]>The post Recursivity #4 – Repeating Circles appeared first on Greg Tatum.

]]>This poem is built on a simple rule, take a circle, divide it in half, and then create two more circles. Every time you click, it goes down another level. I also paired it with some WebAudio generators. The circles are slightly offset in their rotation making the circles appear to have been drinking (go home circles, you’re drunk!)

The post Recursivity #4 – Repeating Circles appeared first on Greg Tatum.

]]>The post Gravity #2 – Multiple Black Holes appeared first on Greg Tatum.

]]>After creating the initial setup, the best thing to do is add even more to it. The first simulation used only one “black hole,” but this one uses 5 randomly spinning holes. I ended up changing the behaviors of the arrows a little bit as well.

The post Gravity #2 – Multiple Black Holes appeared first on Greg Tatum.

]]>The post Recursivity #3 – Draw a beautiful fractal tree appeared first on Greg Tatum.

]]>I’m quite happy with the way this particular poem turned out. It’s very satisfying taking an idea and iterating on it enough to where the result becomes an entirely new experience. What’s funny about this particular piece is that I spent more time creating a specialized line simplifying algorithm that could draw cool bezier curves. I ended up throwing away most of that (beautiful) code and going for a much simpler solution.

The post Recursivity #3 – Draw a beautiful fractal tree appeared first on Greg Tatum.

]]>The post Gravity #1 – Black Hole appeared first on Greg Tatum.

]]>After reading Neal Stephenson’s Anathema a second time, watching Cosmos, and of course that one movie with Sandra Bullock, I’ve spent some time thinking about gravity. This is my first in a series on exploring the math and physics behind it. I’m finding it pretty mesmerizing so far.

The post Gravity #1 – Black Hole appeared first on Greg Tatum.

]]>