An insightful tutorial on the Gaea facebook page. What I'm really interested in is the type of Voronoi used here, and I wonder if this would be possible in Terragen. It's in between Voronoi and square noise; ideal for making rocks.
https://www.facebook.com/juan.p.mardonez/videos/pcb.392488228139464/10156634417928049/?type=3&theater&ifg=1
You may be able to get something vaguely similar with voronoi displacement and strata. Hmm. Let me tinker.
So I may be on to something. First of all though I noticed that if you just take a voronoi, and than a merge shader with the A input being a transform of the voronoi with a rotation in Y by 45 degrees or 90, and a scale of 2,2,2 it gives a very similar look to what you show here in displacement.
I'm currently trying to mix a X,Z square noise with a Z,Y square noise with voronoi, and than stratifying on 0 degrees and 45 degrees with variance. Rendering a test now.
I came up with this little doodle earlier. Several flavors of strata in diferent directions, and a mix between voronoi and square noise. First one is the current iteration.
That's the way to go. Problem with mixing and rotating stuff like voronoi diff and smooth voronoi cell is that you easily end up with small areas that are very white/high, and that create unwanted peaks.
Quote from: Dune on July 19, 2019, 02:40:27 AM
That's the way to go. Problem with mixing and rotating stuff like voronoi diff and smooth voronoi cell is that you easily end up with small areas that are very white/high, and that create unwanted peaks.
Oh yes, definitely. It gets frustrating trying to colour adjust everything, than change one thing, and forget about several adjusts you have to... adjust.
Quote from: WASasquatch on July 18, 2019, 06:37:33 PM
I came up with this little doodle earlier. Several flavors of strata in diferent directions, and a mix between voronoi and square noise. First one is the current iteration.
Those are pretty good rock textures. I myself have not been able to create something as in the Gaea example with the techniques I know, and believe me, I tried. Maybe it is possible with a good knowledge of blue nodes. However, the type of voronoi in Gaea seems to come straight out of the box.
A quick google and all kinds of voronoi appear, so it seems that this particular kind of voronoi must be built into the software. If that's true, I have to resign myself to the fact that it's out of my reach.
http://www.neilblevins.com/cg_education/procedural_noise/procedural_noise.html
https://en.wikipedia.org/wiki/Voronoi_diagram
Quote from: René on July 19, 2019, 03:40:06 AM
Quote from: WASasquatch on July 18, 2019, 06:37:33 PM
I came up with this little doodle earlier. Several flavors of strata in diferent directions, and a mix between voronoi and square noise. First one is the current iteration.
Those are pretty good rock textures. I myself have not been able to create something as in the Gaea example with the techniques I know, and believe me, I tried. Maybe it is possible with a good knowledge of blue nodes. However, the type of voronoi in Gaea seems to come straight out of the box.
A quick google and all kinds of voronoi appear, so it seems that this particular kind of voronoi must be built into the software. If that's true, I have to resign myself to the fact that it's out of my reach.
http://www.neilblevins.com/cg_education/procedural_noise/procedural_noise.html
https://en.wikipedia.org/wiki/Voronoi_diagram
I've mentioned some.other flavor noises based on perlin and voronoi and even others not implementee at all but Matt mentioned he had no plans to add any more noises and that with the SDK it was easy enough to add them. Still don't know much about the SDK. If I knew more I may be able to do something based on open source noises, if not have a more professional coding buddy help.
It really seems like a needed featture, more noises. All these programs like Gaea and substance designer have out of the box is tons of noise flavors for interesting mixes without algebra and trigonometry.
There seems to be a heavy wave going about on highly realistic procedurally generated PBR rocks to export and make seemless. Probably cause they look photorealistic without the 3D scanned model price tag.
Additional types of noise via the SDK would not benefit me because I work on an iMac; as far as I know there is no SDK for os x yet.
I learned by now that the type of voronoi I mean is called Manhattan. It seems to me to be indispensable for the creation of credible rocks.
Looking at all the hyper realistic textures of Quixel and Substance makes my mouth water, and they have raised the bar for texture creation.
Well, maybe Matt cóuld add the Manhattan voronoi if it's free and not too complicated. I don't anything about such things. Only that a lot of work is based on rocks, and it would be a very welcome feature. I've been trying this stuff for years too, but it's terribly difficult to get the holy grail.
I realise it could be a cost-benefit issue, but it would make a huge difference to have this kind of noise in Terragen. Moreover, fake stones and the Alpine fractal are also based on voronoi, so there would be interesting possibilities in that area as well.
I agree with every thing said here, it's a desperately needed tool.
I'm going to leave this right here: https://rosettacode.org/wiki/Voronoi_diagram
Matt could make this happen. I see a lot of voronoi diagrams and functions out there. Though I do notice most are just basic grids like vector voronoi we have now, which we can warp... Though not well. It would be nice to have a function that works for stone out the box driven by seed and scale.
Our issues stems from our math abilities to mix these diagrams into something usable for stone.
Mixing stepped voronoi, with scaled rotated voronoi, than stratified at 45 degrees on 90 direction and 45 degrees on 0 direction. Than we mix by highest.
The issue here is the strata isn't lateral, so this effect is lost with actual use in most situations we want it for.
Edit: here is some raw math notes on the l1 norm diagram: https://xlinux.nist.gov/dads/HTML/manhattanDistance.html
And strata is hard edged, and we actually need something like the smooth voronoi.
Quote from: Dune on July 20, 2019, 02:18:01 AM
And strata is hard edged, and we actually need something like the smooth voronoi.
I am going off of L1 Norm or Manhattan noise as shown in Rene's example and tutorials for blender, substance designer etc. It is hard edges. The illusion of soft edges is from underlying displacement and smoothing via subdivision of actual geometry. These voronoi diagrams are all hard edges. Including voronoi in TG such as fake stones. Normal computing and regular smooth displacement rounds them a bit.
This is our biggest limitation without out-of-the-box noises, cause in TG we can't just go in and compute normal everything and round straights, and than we have the issue of no subdivided edges, so they explode (biggest issue working with lateral). It'd be cool to see this sort of stuff in TG but considering the way it handles subdivision on a simple rock pop.... yeah.
Quote from: WASasquatch on July 19, 2019, 01:43:39 PM
I'm going to leave this right here: https://rosettacode.org/wiki/Voronoi_diagram
I'm afraid I don't know any math. At school, I opted for languages - French, German and English - instead of mathematics, which is something I regret to this day.
The right voronoi looks like a derivative of the left one, as if it has been warped towards squareness. That is probably not the case, but it is something worth trying.
Quote from: René on July 20, 2019, 03:40:00 PM
Quote from: WASasquatch on July 19, 2019, 01:43:39 PM
I'm going to leave this right here: https://rosettacode.org/wiki/Voronoi_diagram
I'm afraid I don't know any math. At school, I opted for languages - French, German and English - instead of mathematics, which is something I regret to this day.
The right voronoi looks like a derivative of the left one, as if it has been warped towards squareness. That is probably not the case, but it is something worth trying.
It's the different distance operator, for example, you talked about manhattan, which is the right one. It's how the paths are drawn. These are all just based on diagrams just like this, either coloured or grayscale. Some extra math and functions would be needed to shade the diagram like voronoi diff scalar. Finally, the actual displaced geometry would need to be subdivided and edges smooth. This could be done by blurring the voronoi noise somehow, but it will be uniform with crevices etc and blur them together. The first example you posted would likely have inverting gradients heading towards the path points which would create the heightmap illusion of edges coming out, and flats, etc.
I am no good at math either and have been trying to do a manhattan distance formula in TG but I can't convert formulas to functions worth a penny. I'd need help with the base formula to try and do anything with the noise to make it workable.
If you mix some (stretched) voronoi diffs you should be getting squares as well as other shapes.
Quote from: Dune on July 21, 2019, 01:39:14 AM
If you mix some (stretched) voronoi diffs you should be getting squares as well as other shapes.
How would you go about doing that? Voronoi doesn't stretch well on Y for lateral. It only seems to stretch a tiny bit and than stops, despite ramping up to let's say 100000 lol
Also when mixing X and Z noise it just creates ribbon overlays which aren't useful for anything rock wise -- also can't seem to rotate it for lateral..
I won't spill all my beans, but you can use a vector as size scalar. If I see people on FB seeking for rock structures, but never posting anything here, I tend to not give away too much. After all, I've spent ages to get where I am.
Quote from: Dune on July 22, 2019, 01:40:37 AM
I won't spill all my beans, but you can use a vector as size scalar. If I see people on FB seeking for rock structures, but never posting anything here, I tend to not give away too much. After all, I've spent ages to get where I am.
So, you've figured out square blocky rock displacement? I haven't seen you ever use anything beyond basic voronoi mixes. And if it's something you discovered from incentive from a community topic trying to discover better rock noise, humm.
Constant Vector doesn't help with Y issue, either. Where, let's say a vector at 100 for normal creates straight strata outcrops, the same on Y is just voronoi with the slightest stretch. Seems the only way voronoi work stretched on Y is literally straight sheet 90 degree cliff.
I'm just confused what you're going on. It seems like you made a pitch like you know what and how to achieve the correct blocky noise but pitching same deal we always do. Sure, it's edged, but no blocks.
No blocks indeed. ;)
With voronoi, horizontal and vertical stretched and merged, very interesting textures are certainly possible. With a lot of hassle I managed to get close to square noise a few times. The problem was that the quality depended on the point of view, i.e. you had to find a spot where the texture worked well. It also happened that the texture was not applicable to a new terrain, although you could get lucky.
When voronoi is stretched, its inherent shape becomes a problem; you get very pointed angles in some places.
I guess our ideas of "blocks" are different. There is no way to achieve this with Voronoi stretched from my end, whether a small stretch or long stretch, and again, if your cliff isn't a sheer 90 degree angle you'll just end up with voronoi angles/ends (those points you mentioned). and deep lines on X and Z; ribbons. '
You can use lowest cut away for some block like features, but again, they don't work well on Y due to cliff angle, still get the deep channels that end to hard which can create weird inverted creases if not careful. You'd have better luck with infinite X and Z or Y merged lines, like the square noise function.
This preview is on X and Z though, which looks nice in illusion, but as soon as you go lateral, you got basic voronoi shapes mixed in with blocks on X lol
You'd have to use either cylindrical or mask sets by normal.
After of 2 pages of figure-figure and go nowhere can perhaps Matt say something about this? I am sure he knows the correct answer.
Not to make wrong anybody but on the Blender forum we would have a solution for a mystery like this in about 24 hrs. Not just in writing but with videos.
I think I should have started this topic in Terragen Discussion instead of here, because Open Discussion is after all for non-Terragen related topics.
Maybe someone can move it to the right place. ::)
Quote from: archonforest on July 24, 2019, 04:06:48 AM
After of 2 pages of figure-figure and go nowhere can perhaps Matt say something about this? I am sure he knows the correct answer.
Not to make wrong anybody but on the Blender forum we would have a solution for a mystery like this in about 24 hrs. Not just in writing but with videos.
It would..not to mention tutorials and documentation on everything between. I had hoped Matt would have already chimed in. Perhaps topic location. Manhattan distance on same voronoi shader in a new shader shouldn't be hard to add too if it can't be explained in functions. It's just the distance operator the algorithm uses, rest stays the same from what I've looked at online in almost every coding language it's been used.
I made a square noise Worley/Manhatten function out of blues a few years back, it was horribly slow. It also doesn't get around the problem of diamond shapes on surfaces off x or z axis.
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.
[attachimg=1]
[attachimg=2]
Quote from: Hetzen on July 25, 2019, 02:49:54 PM
I made a square noise Worley/Manhatten function out of blues a few years back, it was horribly slow. It also doesn't get around the problem of diamond shapes on surfaces off x or z axis.
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.
Quote from: Hetzen on July 25, 2019, 03:04:08 PM
[attachimg=1]
[attachimg=2]
Oh wow, these look very promising. Great work, Hetzen. I was wondering if you'd bump in you wizard of nodes.
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.
The voronoi in Gaea seems pretty fast. Has the video been sped up, or is an image map created first? Or am I talking rubbish? That's quite possible of course. :)
https://www.facebook.com/juan.p.mardonez/videos/pcb.392488228139464/10156634417928049/?type=3&theater&ifg=1
Gaea is fast.
Quote from: René on July 26, 2019, 03:30:27 AM
The voronoi in Gaea seems pretty fast. Has the video been sped up, or is an image map created first? Or am I talking rubbish? That's quite possible of course. :)
https://www.facebook.com/juan.p.mardonez/videos/pcb.392488228139464/10156634417928049/?type=3&theater&ifg=1
Gaea may have multi-threaded computation or even off-load to the GPU. But I believe this did use a base image map with the scatterer. All his others seem to that I've watched.
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.
- Oshyan
Quote from: Oshyan on July 26, 2019, 05:08:12 PM
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.
- 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.
That's not how this works. That's not how any of this works. (Sorry, I couldn't resist.)
When the render is multi-threaded, it's calculating different parts of the scene in parallel.
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.
Quote from: Matt on July 27, 2019, 12:41:38 AM
That's not how this works. That's not how any of this works. (Sorry, I couldn't resist.)
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 AM
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.
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 AM
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.
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.
I love to see Manhattan voronoi included. As you say it won't completely solve the issue but it may help.
Quote from: René on July 27, 2019, 04:04:23 AM
Quote from: Matt on July 27, 2019, 12:52:31 AM
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.
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.
The reason why the blue node method is really slow, is because the network needs to check each call every time it hits the Conditional Scalers and when you're checking 9 zones, each Conditional is asking for the result 4 times....
In code, you can cache each of the 9 zones so the Conditional hit will just check those values in memory, therefore speeding up the process considerably.
There was talk of a cache node a while back. Is that still a possibility Matt?
Quote from: Hetzen on July 27, 2019, 09:36:14 AM
Quote from: René on July 27, 2019, 04:04:23 AM
Quote from: Matt on July 27, 2019, 12:52:31 AM
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.
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.
The reason why the blue node method is really slow, is because the network needs to check each call every time it hits the Conditional Scalers and when you're checking 9 zones, each Conditional is asking for the result 4 times....
In code, you can cache each of the 9 zones so the Conditional hit will just check those values in memory, therefore speeding up the process considerably.
There was talk of a cache node a while back. Is that still a possibility Matt?
That would be cool. Though I'm specifically talking about calculations in general within TG's GUI (like 3D previews, etc) and when rendering. Sure it's all split per core, but each core is just working on that slice of geometry, hasn't the math already been worked out to render anything? Lol I'm not sure how it could calculate random parts of the math to render as it goes lol
When working within blue nodes, and previews of shaders, this is all 32bit, there's no way the software can just dynamically pick apart your formula and decide what thread to throw it at (and than competently combine the result back), you'd have to manually that, or it's build into shaders like multi-threaded voronoi pathing, which is a algorithm divided per thread (similar to how rendering is divided up)
I'm not sure of any math tool that can do multi-threaded math without specifically programmed to. Think PC calculators, they don't know how to dynamically breakup your formulas, and thus single-threaded.
This may be why outside of rendering and holding objects in mem, Terragen see's little benefit from 64bit.
Additionally taking a look at the function you shared, you'd think the math for both trees would already be fired before ever being compared, and thus just comparing raster results? That shouldn't be too heavy. And in fact, the slowdown before rendering a preview is there, but the rest of the process is still incredibly slow, long after comparisons finished.
Everything is 64bit WASasquatch, as far is I know. All 64bit is over 32bit is the capacity to have a lot more digits in a number. It has nothing to do with multi threading.
As for my network, there is nothing to tell the Conditional Scalers that they are doing the same calculation several times. The tree just sees the links as another set nodes that need re-working. Hence the reason for sticking a 'Cache Node' in at the end of each of my nine zones, so when the Conditional calls each branch of its inputs, it hits the Cache Node without calculating the whole thing again.
Manhatten noise should have another set of conditionals to the clip I posted. I can post that too for you to have a look at, but it really is unwieldy not just for processing, but also the number of nodes in the scene. It was more of a thought experiment for myself to see if I understood the math and could translate that into TG blues. It really isn't very useful.
Was, 64 bit vs 32 bit has nothing to do with threading or the parallelism of a particular algorithm. I would be more movitated to explain how things work if you were to simply ask, without making pages of assertions on this forum about a whole range of things which you don't understand, and if you had given me much confidence over the years that after I explain it you wouldn't try to say that I'm wrong about the bits you don't understand.
But, in a nutshell, the voronoi algorithms we use in shaders in CG are completely parellelizable - they can be evaluated in many different locations by different threads without (much) loss of efficiency - because they are calculated using a deteministic noise pattern. This is generally true of all the blue function nodes, and most of the shaders too.
Quote from: Hetzen on July 27, 2019, 09:36:14 AM
There was talk of a cache node a while back. Is that still a possibility Matt?
The last time I looked at this it was more difficult than I thought it would be, with lots of corner cases to account for. I might revisit it as part of a refactoring effort but I don't expect it will be very soon.
Quote from: Matt on July 27, 2019, 03:39:37 PM
Quote from: Hetzen on July 27, 2019, 09:36:14 AM
There was talk of a cache node a while back. Is that still a possibility Matt?
The last time I looked at this it was more difficult than I thought it would be, with lots of corner cases to account for. I might revisit it as part of a refactoring effort but I don't expect it will be very soon.
I can imagine there's all sorts of situations this could go wrong and after all it's a pretty niche request so no worries.
Quote from: Matt on July 27, 2019, 03:31:24 PM
Was, 64 bit vs 32 bit has nothing to do with threading or the parallelism of a particular algorithm. I would be more movitated to explain how things work if you were to simply ask, without making pages of assertions on this forum about a whole range of things which you don't understand, and if you had given me much confidence over the years that after I explain it you wouldn't try to say that I'm wrong about the bits you don't understand.
But, in a nutshell, the voronoi algorithms we use in shaders in CG are completely parellelizable - they can be evaluated in many different locations by different threads without (much) loss of efficiency - because they are calculated using a deteministic noise pattern. This is generally true of all the blue function nodes, and most of the shaders too.
Where have I ever said you were wrong, rather trying to point out what I'm trying to describe that you seem to be quoting something else entirely.
There seems to be absolutely zero difference from your Voronoi Algorithm when forced on one thread, to all threads. Can you explain that?
You seem to be explaining the rendering process itself that's already got the calculations to ever render anything?
Hetzen, is there a way to simply make the seams of your square noise soft rather than hard (the square noise function you shared awhile back)? That would solve the block issue in pattern to be augmented. I tried your current function in several instances and it seems to have issues with random hard parallel lines occurring in the soft squares.
The square noise function works well other than it's seams being hard straights (again past one you shared).
And to make things perfectly clear Matt, I'm not talking about render time which I could care less if it takes an hour or 2 days, I'm talking about working with the software and the shaders. 3D Preview Window, 3D Preview of Shaders, working with the actual shaders and manipulating them via other shaders and responsiveness of TG itself.
WAS, I'm not sure why you're getting those edges, maybe I missed something when clipping the network. Below is the full Minkowsky clip I made.
I'd also like to back up Matt a little here, in that you do have a habit of talking in certainties when actually you've been wrong about the terminology you've used to describe your problem/issue. There have been quite a few posts of yours that I've not understood what the fuck you're trying to talk about. A picture is worth a thousand words. We all want to help. So just show it without assuming something is not working in the background. I've been guilty myself.
Quote from: Hetzen on July 27, 2019, 05:19:49 PM
WAS, I'm not sure why you're getting those edges, maybe I missed something when clipping the network. Below is the full Minkowsky clip I made.
I'd also like to back up Matt a little here, in that you do have a habit of talking in certainties when actually you've been wrong about the terminology you've used to describe your problem/issue. There have been quite a few posts of yours that I've not understood what the fuck you're trying to talk about. A picture is worth a thousand words. We all want to help. So just show it without assuming something is not working in the background. I've been guilty myself.
I am scaling the noise here down 0.5 x,y,z 3 times into their own displacements. Perhaps it's being effected. I noticed if I just add a new larger scale, the blocks spacing seems to become exponentially larger from their original positions.
I have dyslexia bad, so terminology in textual form is always going to be a issue. I also often use literal definition meanings of words where people have slang understandings from them, or pertain to some specific field they're part of.
And perhaps sometimes I do not know what I'm talking about, but I spent several hours reading documentation from some university about incorporating voro++ libraries in a ray tracing renderer and how they divided the pathing up on different threads -- entirely independent from the modeling and object creating and rendering of the final scene (which the objects were based on the voronoi similar to how we use displacement). From what Matt said, it sounds like it just renders the voronoi in it's entirety, in that bucket/thread.
Yes, I understand.
The reason for those edges, is that the zones need to be redefined with off 1,1,1 scaling on the Get Position in Texture multiplier I put in that clip. So really it shouldn't be in the first clip.
Easy fix is to put a Transform Input at the end of the tree to stretch things.
Quote from: Hetzen on July 27, 2019, 05:44:37 PM
Yes, I understand.
The reason for those edges, is that the zones need to be redefined with off 1,1,1 scaling on the Get Position in Texture multiplier I put in that clip. So really it shouldn't be in the first clip.
Easy fix is to put a Transform Input at the end of the tree to stretch things.
That's what I did actually, scaled up 10,10,10 than down-scaled by 0.5 3 times.
Yep. I was re-playing things opening up that old scene. Should have left as is. It's difficult getting back into the mindset of something a while old.
Quote from: WASasquatch on July 27, 2019, 04:16:10 PM
There seems to be absolutely zero difference from your Voronoi Algorithm when forced on one thread, to all threads. Can you explain that?
If you mean in the code, then yeah, that's right. The same code is executed on each thread, and the only thing that's different between threads is the position being evaluated for. This is how the algorithm can scale up to an arbitrary number of threads. It is what's known as a "pure function" in the functional programming literature. That is, its behaviour depends only on the input values and, what's critically important here, it doesn't have any effect on anything else in the system. Its scalability comes from the fact that each invocation of the function is its own island. It doesn't have to interact with any other parallel invocation. 100 parallel invocations will get approximately 100 times as much work done in the same time.
If you mean in terms of render/preview time, then yes, it may be that for quick-to-evaluate functions the bottlenecks occur elsewhere, as in my next answer.
Quote
You seem to be explaining the rendering process itself that's already got the calculations to ever render anything?
...
And to make things perfectly clear Matt, I'm not talking about render time which I could care less if it takes an hour or 2 days, I'm talking about working with the software and the shaders. 3D Preview Window, 3D Preview of Shaders, working with the actual shaders and manipulating them via other shaders and responsiveness of TG itself.
We do have some issues with responsiveness when we are multi-threading the previews. Previews involve some things which are less cleanly parallel, and the fact that all running threads have to be able to respond to the user interaction is where things get more tricky. Thankfully, in many cases the shaders themselves don't need to know anything about this complexity, as long as they are "pure functions" like the various noise functions are. But it all runs through a rendering system that has some baggage from being optimized for the days before we had threading. And then there are some shaders which are not pure functions because they have to cache stuff (e.g. clouds), and that introduces extra lag. Definitely there could be some improvements. I think every minor update in 4.x has chipped away at some of these problems, bit by bit, but I'm still working on it.
Quote from: Dune on July 27, 2019, 12:59:35 AM
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.
Wouldn't it be possible to invert the angle of inclination of the terrain, and subtract or multiply it by the displacement of the voronoi?
Maybe you can use a rotate vector, but I think it'll be rotated from 000, so not locally.
Do we have this kind of noise in Terragen? Looks similar to Voronoi.
https://en.wikipedia.org/wiki/Worley_noise (https://en.wikipedia.org/wiki/Worley_noise)
Quote from: D.A. Bentley on July 29, 2019, 05:51:23 PM
Do we have this kind of noise in Terragen? Looks similar to Voronoi.
https://en.wikipedia.org/wiki/Worley_noise (https://en.wikipedia.org/wiki/Worley_noise)
Ive come close with complemented voronoi that had been merged with itself after rotating. Just not as square mostly since mixing totally will just be broken up.
I ran some tests on a Voronoi Manhattan image. I first enlarged it and added box blur in Photoshop to remove the pixelation. Next with curves again added some angularity. I did not bother to remove the seams from the repetition of the image. It's not perfect by a long shot, but I could quickly establish a rocky texture. I've mixed the texture in a variety of sizes.
That's looking really good. 8)
Simple matter of getting a repeating edge to get the seams softened.
Quote from: Hetzen on July 31, 2019, 04:11:01 PM
That's looking really good. 8)
Simple matter of getting a repeating edge to get the seams softened.
Yeah I've tried a few tiled/repeating generators and they don't really work well with Manhattan due to the angular shapes. The final map would need editing which might introduce blurring and odd shapes.
Quote from: René on July 31, 2019, 01:53:41 PM
I ran some tests on a Voronoi Manhattan image. I first enlarged it and added box blur in Photoshop to remove the pixelation. Next with curves again added some angularity. I did not bother to remove the seams from the repetition of the image. It's not perfect by a long shot, but I could quickly establish a rocky texture. I've mixed the texture in a variety of sizes.
How did you export your manhattan?
Here's something that you'd like to check out: http://alexbeutel.com/webgl/voronoi.html (http://alexbeutel.com/webgl/voronoi.html) Would be handy if there's an offline generator...
And here: https://demonstrations.wolfram.com/VoronoiDiagramsInTwoDimensionalRegions/ (https://demonstrations.wolfram.com/VoronoiDiagramsInTwoDimensionalRegions/)
I've regularly used simple patterns to shape rocks. If you mix a few, repetition can be quite avoided. And it works faster than procedural.
Quote from: René on July 31, 2019, 01:53:41 PM
I ran some tests on a Voronoi Manhattan image. I first enlarged it and added box blur in Photoshop to remove the pixelation. Next with curves again added some angularity. I did not bother to remove the seams from the repetition of the image. It's not perfect by a long shot, but I could quickly establish a rocky texture. I've mixed the texture in a variety of sizes.
Would you mind to share a file so I can see how you displace something like this from a single jpg picture?
I think I prefer a squared worley noise to Manhattan - See illustration. OR a mix of both!
and
https://thebookofshaders.com (https://thebookofshaders.com)
Also I like to see ways of flaking away rocks - which is more natural.
Quote from: archonforest on August 01, 2019, 02:49:26 AM
Quote from: René on July 31, 2019, 01:53:41 PM
I ran some tests on a Voronoi Manhattan image. I first enlarged it and added box blur in Photoshop to remove the pixelation. Next with curves again added some angularity. I did not bother to remove the seams from the repetition of the image. It's not perfect by a long shot, but I could quickly establish a rocky texture. I've mixed the texture in a variety of sizes.
Would you mind to share a file so I can see how you displace something like this from a single jpg picture?
Here you go! You can use either of the two images I posted before.
Quote from: mhaze on August 01, 2019, 04:54:29 AM
I think I prefer a squared worley noise to Manhattan - See illustration. OR a mix of both!
and
https://thebookofshaders.com (https://thebookofshaders.com)
This looks like what voronoi billows is already doing in Terragen. It's a matter of mixing and merging.
Quote from: René on August 01, 2019, 07:08:41 AM
Quote from: archonforest on August 01, 2019, 02:49:26 AM
Quote from: René on July 31, 2019, 01:53:41 PM
I ran some tests on a Voronoi Manhattan image. I first enlarged it and added box blur in Photoshop to remove the pixelation. Next with curves again added some angularity. I did not bother to remove the seams from the repetition of the image. It's not perfect by a long shot, but I could quickly establish a rocky texture. I've mixed the texture in a variety of sizes.
Would you mind to share a file so I can see how you displace something like this from a single jpg picture?
Here you go! You can use either of the two images I posted before.
Lovely! Thank you.
Quote from: Dune on August 01, 2019, 02:32:13 AM
Here's something that you'd like to check out: http://alexbeutel.com/webgl/voronoi.html (http://alexbeutel.com/webgl/voronoi.html) Would be handy if there's an offline generator...
And here: https://demonstrations.wolfram.com/VoronoiDiagramsInTwoDimensionalRegions/ (https://demonstrations.wolfram.com/VoronoiDiagramsInTwoDimensionalRegions/)
I've regularly used simple patterns to shape rocks. If you mix a few, repetition can be quite avoided. And it works faster than procedural.
Out of necessity :-[ I started making imagemaps in Photoshop lately. And although that can produce good results, especially when mixed with procedural textures, I find it difficult to predict what it will look like in Terragen. Often very light gray tones that are barely visible have a big influence, and constantly going back and forth between Photoshop and Terragen is very time consuming. I see it as an emergency solution, and it's a lot of hassle. Procedural textures are the power of Terragen, and having Manhattan noise would open up a world of new possibilities, and would certainly make life easier. :)
It can certainly look good (as you show again), but if these noises take so long to compute, it's off-putting too. I think once you have a hang of what works in terms of greyscale and blurryness, it's quite easy to make some standard maps to use.
These sites offer some quite interesting shape generators.
I hope I will be proven wrong though ;)
Quote from: Dune on August 01, 2019, 08:42:05 AM
It can certainly look good (as you show again), but if these noises take so long to compute, it's off-putting too. I think once you have a hang of what works in terms of greyscale and blurryness, it's quite easy to make some standard maps to use.
These sites offer some quite interesting shape generators.
I hope I will be proven wrong though ;)
Euclidean is just as slow as Manhattan from all the tests I did in other languages, and it's noted in documentation about the raw formulas and machine iterations, that they are both slow. So it should be nearly if not just as fast as Voronoi Diff Scalars when incorporated correctly.
Seems the slowness in Hetzen's function is the blue nodes speed themselves when being calculated.
Quote from: mhaze on August 01, 2019, 04:54:29 AM
I think I prefer a squared worley noise to Manhattan - See illustration. OR a mix of both!
and
https://thebookofshaders.com (https://thebookofshaders.com)
Those are just really circles though. Use Perlin Billows or Voronoi Billows or inverted Ridges. In any case, we've had these a long time and I use them all the time in displacement, which
do not create squares.
Their terrain example they haven't gotten into has a good example I'd like to use: https://thebookofshaders.com/edit.php?log=161127200501 (play with the first fraction function for a seed)
The canvas scales to viewport, so you can go into a high resolution and maximize the canvas and save the image.
It remains to be seen how fast or slow Manhattan is, and even if it is slow, everyone is free to use it or not. As said: the Alpine shader was also slow in the beginning, there was even a warning included because of that. And computers are getting faster. :)
Quote from: René on August 01, 2019, 12:46:09 PM
It remains to be seen how fast or slow Manhattan is, and even if it is slow, everyone is free to use it or not. As said: the Alpine shader was also slow in the beginning, there was even a warning included because of that. And computers are getting faster. :)
Hetzen's latest function is effectively a working manhattan noise function. It is slow. We have yet to see what Matt incorporates, yes.
@René have you actually tried mixing together Hetzen's cobble on Y instead of Z (for lateral)? I imagine with some mixing between flatness of cobbles, and some better warping than this quick test with soft perlin warps you could come up with some decent square rocky texture to apply to shapes.
Warping in my quick example is a little too soft imo, and I feel there could be another mix of cobble into there, as well as masking some of the cobble out entirely to create more variance so it's not so square-y.
Oh, yeah, I tried. ;) Sometimes with promising results. The biggest problem, however, was to get more (natural) variation. This was partly because I don't understand much about the node setup and partly because the regular pattern kept returning, no matter how many gobble stones I mixed.
I also realized that having square noise/voronoi is only half the solution to obtaining credible block shapes, although it is certainly easier to do.
I'm also curious about Manhattan noise's ability to make terrains. A blocky terrain is essential to make credible square noise.
Quote from: René on August 22, 2019, 02:51:43 AMI'm also curious about Manhattan noise's ability to make terrains. A blocky terrain is essential to make credible square noise.
Same. I hope it's added.
Your Mesa Squares looks very nice.
I tried some different methods to mask out the squares, so they weren't complete, but it actually proved harder than I thought. Masking them out-right leaves you with holes in the displacement lift which is hard to deal with when mixing different levels of the pattern. I than tried overlaying the same level of scalar into the masked out areas to try and hide cut outs, but that wasn't working right with the later mixes. Difficult stuff, but can come up with some interesting shapes. I think it would honestly be good for those broken up blocking sedimentary layers between larger Manhattan-type layers.
Hey
@Matt is there any update on a native Manhattan noise? I wonder if this topic is of any help with ideas: http://www.pixelninja.design/manhattan-voronoi-approximation/
I don't have an updated on that at the moment.