Pops

__
POPS - procedural organic propagation samples
------------------

Rocks and trees, wind and breeze, birds and bees. To fully expand the heightmap and featuremap terrain tools, and its propagation methods already developed, the ultimate goal is to fully automate actual assets to provide content to decorate it all with, in a decent and meaningful way, and for this we'll use Blender and 'Evolved TreeIt':-

https://www.evolved-software.com/treeit/treeit

With the recent release of Inifigen from Princeton, it's obvious that procedural tree and foliage generation is a mixed bag of results and use-case expectations, and they all rely on a "Lindenmayer System" to varying degrees and/or photogrammetry, to differing levels of success. On their own, neither of these approaches are ideal, for different reasons. Pure l-system methods result in cheesy outcomes, often much too literal and thus harsh on polycounts, sometimes impossibly so, and the others simply not suited towards LOD and not easily providing enough flexibility for variance. Almost all offer sub-par quality and/or performance drearies. After researching everything, looking through and poking everything possible, free or otherwise, I've found that TreeIt provides the best results because it was intentionally programmed to be used for real-time rendering while also providing a giant range of flexibility and scalability, not to mention it's also legacy-friendly and completely free. It has plenty of its own issues, but those I have conceptualised how to negate, work-around and then fully automate. In order to follow through with this, it's important to really regard only the tree's foliage itself, relying on our own materials and rendering standards, and only use this as a "filler" solution, intended to flesh-out an enormous open world environment but not so much for quality content within the immediate gameplay areas, because we already have higher quality content for a lot of that.

There are some massive problems with trying to do this, however. The most obvious being that TreeIt was never intended for any automation and has no scripting or commandline functionality whatsoever, it's thoroughly designer-software, and a pretty clunky one at that, which isn't good news given the hundred or so options to play with. That itself is a gift and a curse, because while it allows seemingly infinite potential for variance and optimisation, it can take a ridiculous amount of time to wrestle with the interface to finally get decent results. It has certain hard-coded limits to prevent the software from crashing, I presume, which it does quite a lot already. It uses a binary format (although one that we can certainly tame) to store all of these hundred or so parameters, and although it does come with some presets, there isn't some huge community of users who share content and the examples it comes with are about as good as it's going to get. It's not bad, but there's a whole lot of work to be done and a whole lot of tricks we need to use, to get all stars aligned and to achieve visually appealing and well-performing assets that jive nicely with everything else going on. It seems like it can't do bushes, weeds and grass, only trees (which is actually wrong), and the trunk/root system is implemented in a rather ugly way, along with no way to really articulate the lower part of the tree. To top it all off, it's also not spared from the unfortunate side-effect of being riddled with texture seams, which is nay inescapable byproduct of using such a flexible system. None of this needs to stand in our way, however, as several techniques and tools come together to address each of these shortcomings and make this both a hands-off automated procedure, all while not looking too hideous from a visual point of view, yet one which can remain scalable, meticulously curated and fully customisable.

This leads to the first point of concern, a "spectral categorisation" which is fully serialised and thus mathematical, and furthermore instanced and deployed to sets dependently consigned to specific maps. Because this won't include textures themselves, as only materials are serialised but not their contents, this doesn't actually cause as much of an extra mess as it might sound. It will actually do nothing but increase performance, without bloating the base beyond a crumb. Although it entirely makes up for about several hundred different types of assets, the actual materials used are shared across many of them and this is something entirely tweakable and scalable, as higher-end PCs can take advantage of more variation in foliage by simply using more of what's there, but great performance gains can be achieved by narrowing these selections throughout the spectrum, and this is designed to have a few possible steps which makes for a great user option. With each asset having a vector along the spectrum, a rank, and range of other categorisation (see below), those assets can be composed and shared in a mathematically consistent way, which logically compliments the entire propagation system already in place, using featuremaps. Although general use-case is several hundred generated assets, it's not expected for the entire process to take more than several hours. I predict a full persistent open-world RPG full of content could be done in less than a week, and that's only using 1 computer. We're not actually dealing with materials at all here, it's all the geometry that requires processing, a few other bits and pieces, and the few operations required on textures are both automated, procedural and not bulky media, which we come to next.

The biggest problem with TreeIt, and almost all other similar software, is the base of the tree. Having what appears to be a boring popsicle stick injected directly into the terrain with infinitely sharp seams of contrasting materials is not something acceptable at all, in my opinion. Not for a very long time. For this concern, we'll use what I call "baskets" and some tricks toward articulation of the base of the trunk, to possibly create an elaborate (although not finely aritculated) root-like structure that blends more gently into the terrain and has a extra benefit of helping to hide some texture seams, which is also important. As mentioned earlier, we should only be visually satisfied with the upper-tree and foliage from the outset, as the base of the trunk is where almost all of the tricks will occur as to solve each of these problems and artifacts, and so despite all the challenges we face here, I think the software is capable of some pretty nice usable results after all. A method is used to measure the tree from top to bottom, isolate the trunk and boolean it into halves, all minus the foliage and branches. This is done by measuring the geometry and deriving that math to generate an exact proportioned and positioned custom piece of geometry to automatically boolean and recombine as separate geometry with not only separate materials, but another material atop all of that that itself is procedurally generated, and that is placed on the "basket". This basket is expanded outward to create a shell around the trunk that matches any potential permutation of asset, even something like a cactus, or draping foliage like that of a willow tree, even one with thick gnarly roots. Baskets allow the two benefits of having something that is customisable as related to the theme, to provide a gentle visual transition into the terrain, and to disguise the texture seams where they are the most needed, which is in close proximity to the audience view. Baskets might be textured to have the dust of the desert caked and sprinkled around, or vines and moss crawling up, or ice and frost biting at its toes, or anything you can possibly imagine since the baskets are independent objects in every sense and even possible to use the terrain itself to assign their materials via vertex-colour influence on the basket. The bottom half of the tree trunk is also given a unique instance of its material, which allows some different displacements to occur which allows for the optional root-like structures, while also allowing for other custom lumps, dents, holes or breaks that can easily be painted and sculpted in, as it is now a unique asset in the base. The basket can be used to decorate even itself, using each vertex as a point from which to sprout a small piece of grass or other tiny feature, which will help to really make it look a lot more naturally integrated into its environment as a complete asset. All of these same procedures would work on other organic solids such as rocks, other things possible to fully automate for propagation. This might sound all too good to be true for a variety of technical reasons, but Blender's ability to automate some complex UV unwrap techniques and usable boolean subtractions, remeshing and shrinkwrapping, along with a reasonably modern groundbreaking tool released which will be used to further remove all potential seams of these instanced assets, we can really make up for the areas where this approach would otherwise not be substantial for use as clean professional development quality.
https://cragl.cs.gmu.edu/seamless/

With trunks hopefully a lot more visually pleasing, the overall asset still needs everything it can get to provide variance in every other conceivable way. Maximum variation is what will give the entire scene its lustre and realism overall as an environment as a whole. While TreeIt has an impressive number of options already and will be made use of, we can push it all to the limits with better software such as Blender and Meshlab, although we still can change anything in the binary TRE files using hexadecimal byte-editing via advanced data management, and we definitely will. We still need a range of randomisations and influences, and way to then optimise everything in a robust and fluid way, and some solution to managing absolutely everything in a user-friendly way, both before and after the entire procedure. One process is to assign vertex-colours, to the trunks, branches and all types of foliage with intense hues, and in different ways to correspond with a combination of variations such as health, season, theme and terrain. Extra foliage-bending is better achieved in Blender using rigidbody physics with forces while anchored to their origins as individual objects, keeping them upon the branches while flourishing the foliage with extra thickness and variance, which is one way of exceeding the limitations imposed by TreeIt. The foliage materials themselves are dispersed around the volume of the foliage, both as mirrored UVs, along the spectrum as assets, and concerning health, as all foliage materials are automatically provided with various degrees of damage as their own texture sets, for this purpose. All of this is done to both allow even more scalability, as well as helping in exceeding limits imposed by TreeIt and then counterwise having more meat on the bone in terms of potential fluid optimisations. We can flex the foliage material alphatest parameter to scale with the LOD stages to compensate for perceptual apparent density as a visual volume, this is done to ensure minimal disparity when considering such intense scalable exploits. This leads to perhaps the most important process and why foliage amounts can be throttled so much, which is "applecore-optimise" technique which lowers the population of individual foliage units from the inside of the volume to the outside shell in small delicate iterations. It does this by measuring the volume, using various silhouettes of the volume, creating a manifold representation of the volume's shape and using that as a way to select individual foliage units in a few iterative ways of its own, which is a sneaky but highly effective and elaborate approach to optimisation. This applecore trick is fairly sketchy but absolutely helps to flesh out all of the full range of LOD stages and allow for smooth distancewise transitions, all the way down to a flat sprite, an "imposter" which, yes, shall also be entirely automated as its own process directly from the asset. The final thing to mention is software to curate and categorise absolutely everything involved in this entire technique, along with manage the entire automation process. Like a poker machine in a casino, one can choose which results remain in the entire set for a map and automate only a subset of the content one wishes to refresh, and keep hitting the deck again and again, pulling that lever. Eventually more satisfactory results with higher ranks will accumulate and, over time, very little may even need to be processed since great results may already be available in the base. The proposed application will be designed to handle all of this in the most straightforward way and with visual feedback so that mappers can have the clearest vision on what they want and what to expect, and all entirely scalable.

That about wraps it all up, for good. What is really needed, that I can imagine from here, is a functional "auto-bandaid" solution. All ugly intersections nice disguised. The baskets are already incredibly complicated, but achievable and in a way a very simplistic form of an automatic bandaid, and although a first step down that path with everything considered, some auto-bandaid has been on my mind but is another order of magnitude in difficulty. I must draw a line in the sand and cannot do it alone. While I have some ideas about taking those further steps, the technical complexity and mathematics is beyond me and my time all alone. This is much like the extended stencilmap-autoknife technique, also an auto-chamfer technique that may or may not work, it's all bouncing around in my head but requires too much research and experimentation, and dealing with mathematical concepts I am not psychologically able to burden nor afford the time on a scale that concerns my very existence. Just as Homer Simpson, by this time in my life, everytime I learn something new it pushes some old stuff out of my brain. I need what I have and can no longer fit anything more, anyway, a combination of memory problems and poor mental health. I might type up my detailed thoughts on these later, but I doubt even that will happen for a very long time, and only for theoretical purposes, if so. If I can ever collaborate with a genius programmer and mathematician who can understand the concepts, I'm sure we could make that magic happen, but I can guarantee that will be the only opportunity I have to ever see it eventuate in my remaining time on this planet. In the meantime, anyhow, I think what has been planned out is extremely exciting and I personally am very happy, especially with heightmaps and "featuremaps" being able to become fully factored from GIS, I feel very confident about everything.
https://www.violae.net/wiki/tiki-index.php?page=Terrain-feature
___
"spectral categorisation"
-----------

theme x5 (/11+)
tier x3
class x5
size x3
vary x3

...themes:-
- tundra
- alpine
- woods
- bushland
- swamp
- jungle
- tropical
- coastal
- wasteland
- desert
- volcanic

...tiers:-
- healthy
- dry
- decayed

...classes:-
- tree/boulder
- bush/rock
- shrub/stone
- weed/pebble
- grass/rubble

...sizes:-
- big
- medium
- small

...variance:-
- 1
- 2
- 3

(...=~666!)

.
.
.