Update 40: 06/08/2015Looking absolutely beautiful!
Thanks
---
I took a brief vacation to the beach this weekend, and I haven't been at a computer in a few days.
There isn't a whole lot new, so instead I'll do a 'reverse post' of things I've done in the past for Desolus.
This is mostly a technical post.
I normally gloss over most of the technical details in my DevLog.
If you're a programmer you might find this interesting, although this is for Unity in particular.
---
WARNING, VERY OLD SCREENSHOTS AHEADDisregard the crappy default Unity assets, this was when I first started I talked previously about how I generate objects procedurally.
This entry is a high-level overview of my algorithm, and about an interesting glitch that I encountered a long time ago.
I had a problem with mesh-deformation and corruption. It was rather extreme!
I took this picture probably March 2014, when I first started experimenting with Unity. I saved it because it was so bizarre I found it hilarious.
I was working on trying to generate fractal trees and failed miserably.
I later perfected the algorithm (and use it in game). There are no trees, but I use it for the other objects.
This is what end result of this algorithm was:
---
To generate the fractals, I used an algorithm which recursively clones each fractal iteration from its parent GameObject.A transformation function is applied which changes the size, rotation, and position, of the child object.
The initial parent object, or 'stump' of the tree is a cylinder. In-game I use cubes.
I place the GameObject's position on instantiation relative to the parent's Transform.Position.Forward (as a Vector3) and rotation using Quaternion.Euler(x,y,z) (because ugh quaternions).
That visual glitch comes from recursively copying the parent's transform and then applying transform translations to the parent. If you have a recursive parent/child transform structure, a simple change in size/rotation could *massively* affect objects further 'down' the fractal tree.
I fixed it by avoiding applying any type of mutation to parent transforms.
In retrospect, I should have stored the child GameObject data in an ArrayList, and combined/cleaned up later vs. doing the parent approach.
After generation, I combine the GameObjects.
---
The second part of this algorithm is a mesh merging function.
This reduces draw calls, material count, and GameObjects in scene.
I made a post a long time ago with this code.A high level overview is that the code takes the meshes from each child game object, and combines them into a single mesh. In the actual mesh merging function itself, I had problems in converting world transforms to local transforms (as a vector).
If you look at the code, I set the mesh local position to a Vector3.zero, apply the function, and reset the position to avoid corruption.
Unity's mesh merging function got 'confused' for lack of a better word, when I did not zero out the local position of an object first.
I don't have a picture left-over, but the result was transparent 'ghost' meshes that hovered in the sky.
Spooky.
---
All of the 'tentacle' and Desolus objects are generated with a revised version of this algorithm.I can type in a few numbers as parameters, and infinitely generate permutations of objects.
---
Anyway, next focus for development is improving visual communication for the game.
It's an area the game has always been weak on (new players often can't really tell what's going).
My brain has been regenerated significantly from even a brief vacation and some sun, so I feel good