Project Update: Entropy Earth

Feature: Applying the Skin(CPU)

It's really early on in the development of applying a correct 3D skin, to my skeleton of a tree which has been generated using an L-System, but as I actually have something new on screen I thought I'd share it with everyone.

So what's wrong with this picture? There is currently no varience in the radius between trunk and branch, there is no code in place either for correct blending between limbs, nor is there any sort of correction to the verts in regards to direction. This is afterall a very early prototype, I am currently more interested in getting features working than getting it to look all nice and pretty.

If the code is written properly, actually getting the L-System to generate a more accurate tree is a matter of L-System construction, so it can all be tweaked later.

Project Update: Entropy Earth

Feature: L-Systems in 3D.

L-Systems on 2D planar surfacesare incredibley easy to construct and manipulate. My system also allows for 3D L-Systems, which when you actually get down to writing one, isn't as easy as a 2D L-System, it requires a more complicated L-System to generate a good result.



So after much adoo, I've created what i would call an acceptable tree structure:

This will be my Base shape, now to slap a nice acceptable skin on it...

Project Update: Entropy Earth

Feature: L-Systems

L-Systems are a funny idea, I personally view them from a perspective of they're a language within a language which writes itself based upon the rules of a said language. Which is exactly what they are... But they're not that complicated at all really.

The process of generating something with an L-System requires that a grammar of some description is defined, and that the elements of that grammar have a result. It's Computer Sciene 101 stuff in alot of ways, and in a bunch of others it more parsing and language translation.

Okay, so I figured that it's probably best to allow whoever is writing said L-System to have absolute control over it so, the grammar is defineable. I'm currently using the following:

'X' ->"D[+X][-X]DX"
'D' -> "DD"

When we construct our string using our defined rewriting rule what we end up with is something like as follows:

X ->"D[+X][-X]DX"
D[+X][-X]DX - > DD[+D[+X][-X]DX][-D[+X][-X]DX]DDD[+X][-X]DX

This string obviously grows and grows at a dramatic rate.

This is a common grammar, we use the initiator X and then set a number of iterations, and as a result I feel a good starting point, which provides a basic 2D result.

While this is obviously a work in progress, it's always nice to have good results early on.

Okay anyways, once the L-System generates it's final resulting string, which may I add over the amount of iterations in the image is a very large string.

The characters of the string are parsed, which gives us our mini-language each character yeilds some manner of result, this is based upon Old Turtle drawing systems.

So I'm using:

{D} -> Draw over a distance.
{+} -> Positive Rotate on Z Axis.
{-} -> Negative Rotate on Z Axis.
{R} -> Right Rotate around Limb.
{L} -> Left Rotate around Limb.
{[} -> Push Data onto Stack.
{]} -> Pop Data off of the Stack.
{(} -> Number Input Begin.
{)} -> Number Input End.

While I'm not currently using all the commands that I have written, I am starting to open up a tremendious amount of power, notice that X isn't a command thus X is ignored when we come to draw out the result.