The first part of the tree is below. I've taken out the next stage of comparison due it being HORRENDOUSLY sloowww... and just added a few triangles to the pattern.

I've been playing around with another technique which works with surface normals, but don't have anything to show right now, as I'm getting lighting issues on the surfaces that don't look good.

From testing in a few languages now, and looking at documentation the Manhattan distance formula is a slow, but they also mention in various places euclidean is as well, which is what TG uses, so there must be optimizations that can be done somewhere. I wish I was some help. I've been trying to formulate stuff. I actually have a question out to someone who may be able to write new power fractal shader. I gave him so refs to see if he can before setting having him contact Matt about the SDK.

In general I have a lot of very unique and powerful natural noises in raw formulas that could be translated for a new power fractal shader alone outside of the Manhattan and a couple other paths for voronoi diagrams.

Thanks for chiming in, Jon. Interesting shapes. Slowness is indeed a problem. And especially if you also use water in front of a complicated cliff (testing one right now), it'll take ages. I think it would be a lot easier to just use plain image maps in warped and resized combinations to take out repetitions. I know it's not a purist approach, but what the hell.

Gaea is multithreaded, but so is Terragen. Gaea uses minimal GPU at present, according to Dax Pandhi. My impression in that video is the entire network is already pre-calculated and he is just clicking on various nodes in the network to show the terrain result at that part of the network. It is not having to recalculate these each time they are clicked, they are cached.

Quote from: Oshyan on July 26, 2019, 05:08:12 pmGaea is multithreaded, but so is Terragen. Gaea uses minimal GPU at present, according to Dax Pandhi. My impression in that video is the entire network is already pre-calculated and he is just clicking on various nodes in the network to show the terrain result at that part of the network. It is not having to recalculate these each time they are clicked, they are cached.

- Oshyan

You're probably right about caching in the video. Though if I'm not mistaken the voronoi algorithm can't just be slapped on multiple cores to achieve it's calculations, you'd have to write the algorithm to use multiple threads.

I'm fairly certain (though I haven't decompiled the software in awhile to peak) that the voronoi algorithm is the same from 32-bit.

To be multi-threaded the algorithm would need to divide the pathing to threads specifically. TG just being 64bit won't do that.

I wonder if blue nodes are even calculated by multiple threads, TG would need to be aware of every formula and how to properly divide it to cores and than merge for the absolute final result. Not sure there. Hetzen's example for simple square noise seems to indicate it is not multi-threaded. It's painfully slow, and the math there from what I gather at least (no whiz by a long shot) isn't too complex for shape drawing.

Manhattan distance could be added to the existing Voronoi functions as an option. I'll see if I can squeeze that in to an update. Unfortunately it doesn't really solve the squareness problem on slopes.

Maybe a combination of masked strata and this noise can pull certain blocks straight up from a slope. Though most blocks of rock may be sloped too, like here. And this can be done with smooth voronoi combinations.

When the render is multi-threaded, it's calculating different parts of the scene in parallel.

Lol So how does it work?

It seems you're just stating the whole formula is calculated per bucket, on each thread, which is still single threaded for that bucket (inherently by design)?

I'm trying to find the website I read this on, but I read of a true multi-threaded voronoi implementation, and to be truly multithreaded the pathing formula is divided per thread and combined. This maximizes the computation across all threads to achieve the paths much quicker.

Maybe this isn't possible in TG but think of it like other 64bit software vs 32bit when TG is rendering. If you open something else like 32bit photoshop, it's pretty slow. But if you run 64bit photoshop while rendering, it scales rather nicely being able to toss itself around on all cores just like TG. With 32bit it's only chugging on my first core, and struggles with priority (like a calculation of that voronoi on that thread while doing everything else too)

Quote from: Dune on July 27, 2019, 12:59:35 amMaybe a combination of masked strata and this noise can pull certain blocks straight up from a slope. Though most blocks of rock may be sloped too, like here. And this can be done with smooth voronoi combinations.

I'd rather see it done than trying to say it can. I have yet to see what Manhattan angles achieve in other software, which also have euclidean and specifically not used...

It's also cool that I've seen some clamped mixed Manhattan voronoi used to do all sorts of stuff from cities to Death Stars. It'd be super cool in TG.

Quote from: Matt on July 27, 2019, 12:52:31 amManhattan distance could be added to the existing Voronoi functions as an option. I'll see if I can squeeze that in to an update. Unfortunately it doesn't really solve the squareness problem on slopes.

That would be great, even if it is slow (Alpine fractal was also slow 10 years ago). Even if you don't get great results right away, it would be very good to be able to experiment with it to assess the pros and cons. And you never know what people will come up with.