Part 5

Greedy meshing algorithm implementation -- entirely in blueprints!

Are you thinking what I'm thinking? This is crazy!

This needs to be refactored, because the whole has become the unit. I need to do this for a couple reasons.

  • I can't call delay() from within a function. I need to do so from the EventGraph.

  • Breaking things up into small pieces makes it easier to organize and test. I'm not going to add any functionality, I'm just moving the BIG method into the event graph and breaking it down into smaller functions.


It's worth noting that macros are way easier to implement in the event graph than functions--for one main reason. Creating local variables within the scope of a function is time consuming. Macros bypass that by allowing the use of their parent variables.

My first time trying to introduce a block outside of my pre-defined quad surfaces, I ran into a weird looping issue. Aside from this working incorrectly, this is an indicator that perhaps my algorithm is running one more instance than I intended it to.

Ah, sneaky bugger! It turns out the algorithm is not running quite like I planned. Need to make some modifications. While I'm glad I discovered this, it took me far to long to realize what was going on. I need to display in wireframe more often.

Coincidentally, this means that my algorithm is generating wayyyy more faces than necessary. The interplay between X and Y scanning (and subsequent 'deletion' of faces in the arrays) is failing. This should be easy to fix now that I know what's actually wrong.

A hard lesson learned: just because it looks correct doesn't mean it is.

After LOTS of fuss, I now have something that is slightly cleaner... but still doing just a few more iterations than it should. I'm happy that it knows when to skip a single row, but that big section should be only one mesh. Once we get that figured out we will be in a really good place.

The many refactorings I did also greatly increased performance. I now don't get absolute frame death when doing a 16x16 array, and I can still introduce another delay() node on the event graph if I really need to.

One thing I've noticed is that ANY logging causes huge framerate drops when doing calculation intensive tasks like these algorithms. I'll have to make sure to strip those before I release.

It was a simple fix...

I was incrementing Height on the loop() portion of the foreach statement. Incrementing after completed was the only fix it needed.

We now have a working Greedy Mesh implementation. There are still some networking considerations that will take another huge leap to implement, but it's always good to celebrate the victories as they come.