@Virex: The test was mostly to see if the rocks would flow down the terrain slopes properly, which they thankfully do. It was intentionally made into a herringbone pattern so that I could easily watch the rocks fall and change directions.
@Skyrunner: The rocks actually are textured already
when they are created they are being assigned a random texture from a list of 3 possible ones.
@Mullet Master: Lol, yeah you could say that
My current project is to get appropriate terrain generated using cellular automata using a Quad-tree. Once I have single layer terrain created properly I will then work out how to transfer that into an Octree and create 3D terrrain. I have a prototype of the Quadtree structure laid out and am currently doing testing to see how viable it is to do full tree-leaf traversals to calculate the next steps in cellular automata using a 3,4-alive rule. The research is promising, and supposedly it can be done quickly for 3D terrain to create realistic cave structures.
Once my research phase is completed I will be able to hopefully create a full 3D terrain with only terrain pieces exposed to air (within a boundary) being instantiated and rendered.
Current researched information:
* A quad tree with a layer depth of 10 produces a tree with 1024x1024 leaves and occupies approximately 50MB of RAM at initialization.
* Using a Hashset to contain 1024x1024 Cells with a position value and alive/dead switch takes approximately 1.5 seconds per 5x5 section of cells being calculated per iteration and so would be prohibitively slow to use to appropriately generate terrain of any size
* It takes approximately 3 seconds to generate the initial values and then count all members in a Quadtree with depth of 10 using a 1.5GHz dual core processor
Currently Researching:
* Effectiveness of doing cellular automata calculations over the entire tree.
Theories:
* Generation times for likely cave sizes will be sufficiently low to make this research worth the time to do it.
EDIT:
Just did some testing in Unity on an unrelated thing that I will need shortly after getting the above worked out. This thing is being able to turn the rendering of an object off,while still allowing it to be interacted with (physics, calculations, etc). This will allow me to instantiate the world while hiding (turning rendering off) of the objects that are not visible due to being surrounded by other terrain blocks. I should be able to tie this in also with the camera's view frustrum and make it so that objects within the view frustrum + 10-20% area and within a specific distance are rendered, and are hidden otherwise. This "should" allow me to have a rather expansive scene area without needing to actually view all of it at one time. It may require a large scene wrapper to keep track of all objects firstly within a specific distance of the camera and also a sublist of objects that are just within the frustrum + margin area that can be updated in a realistic amount of time. I would suggest a low resolution "map" that updates itself with distance data relative to the camera periodically and then if the the points are intersected by the frustrum then they are visible and if not then hidden.
I could probably word that better but I am about to go to bed and may not be able to get online tomorrow. I hope I can but not expecting to. If that is the case then I should be on Thursday, and then Friday and/or Saturday.
I will get started on dealing with the camera as soon as I get the terrain stuff (better rendering of objects, cave generation, etc) finished.
EDIT 2:
I should be able to provide more pictures the next time I am online consisting of the bulk of the work I have gotten done recently by Thursday or Friday at the latest