Long overdue update. Been super busy lately. Let’s get to the good stuff.
Finally got the line drawer tool working.
Having to place each line as a separate prefab and making sure it was oriented the right way, in the right order in the hierarchy etc, was just a massive pain. Glad I don’t have to do that anymore.
Using the line drawer, the line that is formed is just a single mesh. It’s actually pretty similar to the way water is drawn in the game as well. The entire waterfall is one single mesh that’s redrawn every frame.
To use the line drawer, I just have to place down a series of markers:
At each point of the marker, there is a visual peg that helps me see the orientation. This was mainly for debugging purposes when I was first writing the code, just to make sure that the orientation of each marker was correct.
The red arrow is the forward direction of the marker. The white arrow is the right direction. The blue cube is the position of the right vertex and the yellow cube is the position of the yellow vertex.
The tool keeps a list of each marker as it’s placed, and uses their position to calculate whether a bend is right or left and sets the vertices accordingly. For example, if bending to the right, that means the right vertex will be on the inside corner, while the left vertex is on the outside corner.
There’s a bit of list gymnastics with this, where you have to wait until the next marker is placed down before you can set all the info on the current marker. For example, let’s say we’re on marker #5. We don’t know whether marker #5 bends to the right or to the left, or upwards or downwards, until marker #6 is placed. So only after #6 is placed, can we use that info to send the bend on #5.
As you can see, we can also change the normal of the different markers and the tool adjusts accordingly:
Still working on this, but we’re almost there.
David started the tool and got a lot of the basics in place.
Instead of using matrices passing them from parent to child to handle translation and rotation, he set it up so that it’s using the world coordinates to do position offset and deciding which faces to extrude. As such, there is actually no rotation going on.
The key to the tree generator is that it needs to fill in a defined space. I’ll be designing level, and there’ll be a 15 x 30 x 20 volume of space for a tree that goes in. The generator needs to create a tree that fills that. It can be smaller but no bigger.
This is why it doesn’t make sense to use only a pre-made set of trees. We don’t get enough variations for all the different sizes that we need.
The way the algorithm works is using “trunk paths”. A “trunk path” is a single line of vertical and horizontal tree pieces. The further along the trunk path is, the higher the likelihood of a “split”. Once a split happens, we get either 2 or 3 new trunk paths.
The beginning of trunk paths are color coded yellow. Vertical trunk paths are dark blue. Horizontal trunk paths are light blue.
Branches start out as red, and are pink or white, depending on vertical or horizontal.
The end of the branch should always go up and is color coded black.
I need to add a raycast system so branches don’t grow into each other. To prevent tree parts from growing back onto themselves, we use lists to keep track of the direction and then make sure new pieces don’t grow in the direction of the inverse of the last two horizontal directions.
Video Game Art Gallery – Exhibition Opening
Video Game Art Gallery exhibited a number of prints I had made with Manifold Garden two weeks ago.
It was part of the Chicago Architecture Biennial, and was supported by the Graham Foundation.
The opening was on Friday, October 16th. Here are some photos from the event: