Hi guys,
I’ve just finished the PPA ridge/valley picker plug-in for WM Pro Beta 5. It is the first part of the terrain synthesis from DEM devices that I am developping. You can download the plug-in (including a simple example) from here. To be able to use the plug-in, you will also have to download some additional dll files which is also listed on the webpage. Please let me know if there is any problem. Thank you.
Go Howard!! 
monks
It says in the Device Help page that when you select Ridge or Valley Terrain Type, the Edge Threshold is automatically set to 1.0 or 0.0. The slider doesn’t alter (though it does seem to be selecting properly).
monks
Thank you, Carl,
I could not figure out how to dynamically reset the slider value, so the slider is set internally when the “Terrain Type” is switched. The slider will be reset if the device is closed and reopened. Any suggestion on how dynamically reset the slider would be greatly appreciated.
Also, this ridge/valley picker device is just an analysis tool. Without the proper support, it would probably be useless. I am working on the rest of the devices, and I will try to keep up with the posted release dates. Thank you.
Great to see that this is really coming together. Nice work!
I’ve only played around a little with this and I know it’s dependent on other devices that haven’t yet been created, but my first thought was to plug it in to a Layout device. Of course this didn’t really do anything useful, but being able to use this thing to generate Layout shapes would be kind of cool. Just a random thought really as I know the other plugins will make that route laborious and frustrating by comparison.
I’m really looking forward to seeing this progress further and I’m very glad you’ve chosen WM to implement in.
- Oshyan
It all seems pretty straightforward to use with lots of control over the networks. I’ve used it on a terrain where I know where the rivers are. It finds them all well enough- and a few (million) more to boot if I want!
I agree, hooking this up with with Layout mode would be great when we have support for vectors with z (shp, or whatever). Even without that support it would be useful as you could manually assign the z info yourself. As Layout Mode interpolates between any vertices not assigned a z value, all you would need to do is assign the end points- certainly not all of them. You could then using fractal breakup and noises on the layout. Lots of possibilities
monks
To add some details on the development plan and also a call for help, I am just gonna shamelessly copy the post I left on the Terrain summit forum here.
"As far as the development plan goes, the next two parts: seam finder and seam remover are, imo, more useful in terms of height field manipulation. When both devices are combined, they act as a height field combiner sort of filter. That is, given two height fields that you want to put together, the seam finder will find the best seam from where the two height fields can be joined (assuming their relative positions are fixed). Once the seam is identified, the seam remover will remove the height difference along the seam while preserving the details around the seam region.
With the experience gained working on the PPA ridge/valley picker plug-in, I am now quite comfortable with converting the rest of my code. However, I am not quite sure how these devices should be integrated into the World Machine work flow yet. I am looking for suggestions on how you may want to use the devices. Especially ideas on how this can be combined with the layout editor, since the last part of my entire algorithm is just a layout planner."
This is why control over the networks in vector form would be ideal for this. If you could convert between the networks in your device to a Layout and vice versa, we
could easily:
-
Draw a layout in vector form. The networks would describe valleys, ridges and river channels. Pass that to the synthesis devices. The device stitches the terrain patches along the vectors.
-
Or take an existing real world dem. Analyse it to produce vector networks. Then alter them manually or insert your own vectors into it to impose features on the terrain where you wanted them. The algo could take terrain patches from the existing dem to do this. That would help the added features sit naturally in the landscape.
-
The networks themselves are created along recognisable fractal forms (I think like plants are different, so differnt bedrocks produce different patterns of stream channels, etc). I’ve tried drawing convincing networks and they are not as straightforward to capture visually as one would first assume. Having used networks from European hydrolic data, I could easily point out where the branches that I had added were- just from visual clues. Obviously practice helps, but I think there are very likely a lot of subtleties to the organisation of terrain on all scales, that is only learned through study. Your devices can already systematise that.
-
Another idea is to use parts of networks: cut and paste, or to integrate the ppa analysis into a nwtwork generator, such as an L-System generator. This would require a tool which grafted networks onto existing networks with a mouse click on a vertex. This would enable you to capture the characteristics of the terrain at a structural level (as opposed to simply small scale noise level). Of course, given enough resolution at the analysis stage, I can see that the ppa algo can actually produce extremely fine grained networks suitable for small scale structures too.
-
The tool could not only capture real world dem characteristics but it could also be useful to define World Machine’s own internal noises and erosions in real world terms? Eg, this macro (noise + erosion) = Karakorum mountains because it’s network shares measurable similarities with the analysed Karakorum area. In fact one could analyse the similarities between the real world networks and WM’s and provide an extremely useful (and in my opinion needed) means of classifying WM’s processes. Then the community could build a library of such macros within that framework. One can even imagine a crawler/script, that: creates WM terrain -> ppa anlysis-> seeks out real world dems: classifises them.
One might argue that once we have terain synthesis, why would we need WM’s internal processes? Well, I don’t think one wil obviate the other. Apart from lots of other
reasons, it may be that World Machine’s internal processes are more efficient than synthesis (for say larger tasks). The terrain synthesis devices could have the option to sequestrating the library of WM macros for patching if that was in some way more useful.
It seems to me that once we have a common language for describing real world terrain and synthetic terrain at the stuctured level (basically like noise signatures), then the two can be much more interchangeable, and the previously used rather abstruse langauge of ‘persistence, lacunarity, etc’ can be replaced with more meaningful
‘terrain-centric’ descriptions such as ‘like the Andes’, ‘Nevada mesas’, because it will all be based on a real world reference.
I’ve not mentioned z info in the networks because currently we’re looking for a vector format that supports per vertex z info/ colour. The only one I know of is the .shp format.
monks
Very interesting thoughts Monks. I suppose most of this is WM-specific (e.g. Layout mode references), so it probably belongs best here and not on the TS. But perhaps we should reference this thread over there?
What you’re talking about is basically one possible implementation or stage of the “terrain sampling” we have discussed previously (on the TS? Or ME-DEM perhaps) that would hopefully lead to more realistic procedural terrain synthesis. You start by sampling real world terrains and storing information about them and then work out how to synthesize similar but unique terrain that shares those characteristics. Much more complicated to do than to describe of course, but again this could be a first step, which in itself is useful too.
- Oshyan
Very interesting thoughts Monks. I suppose most of this is WM-specific (e.g. Layout mode references), so it probably belongs best here and not on the TS. But perhaps we should reference this thread over there?
Yes, It ties directly into the modelling terrain via networks thread,- both layout mode and the ppa analysis.
I’d love to think that the library of terrain signatures could come off. Maybe it will be possible to develop a classification system from the ppa analysis device?
If more devs take up Howard’s code/ approach, it should be more possible to reach a consensus.
I also think that including z info in the network could be another useful (maybe necessary) element to the signature. For eg, change in altitude. Then there are all of the noise descriptors which could be useful- persistence, lacunarity, etc. An important thing for standardising a language will probably be scale issue. Do all dems have a way of automatedly extracting their post spacing? I bet they do.
Joe Slayton mentioned statistical analysis a while back- that was the first I’d heard of it. The thing is there are lots of terrains that don’t have very strong visual structure. I would argue that all terrains do if you look hard enough. I might be totally off here, but the description of terrain in terms of watersheds and divides seems to cover just about every terrain out there: flow divergence and flow convergence.
I guess the analysis device itself will need to be able to deal with those difficult terrains. I’ve just tried both the valley and ridge pickers on a basic perlin at 10m alt range and there are clear signatures there.
Then there’s the question, would people really want to synthesis say salt flats, when WM could do that internally?; probably not. Also, one could maybe use absence of
networks as a metric. Then there’s the fact that most people want to render mountains because they have strong visual structure. It all mitigates this problem.
Of course, it’s doing it that’s the tricky part!! 
monks
I’ve been using the PPA analysis device with Layout mode. I’t was suggested that we have an L System ‘like’ generator to develop river networks, etc in Layout mode.
What I’ve done is draw my main rivers in layout mode and then I’m using the ppa to add to that network. I’m using the combined network as a mask for altering the
shading in the generated terrain texture- nothing fancy at the moment. The problem is, it would be better visually (and more realisitc as a river network) if the network branches that the ppa generated were culled if they did not connect to the existing layout mask; ie, the ppa branch must cross the layout branch at some point.
In other words that would provide a way of acheiving somthing similar to the L System idea, where one would draw the main rivers and procedurally produces more networks attached to theose existing rivers.
Obviously the culled branches would always have to be a subset of the branches in the ppa analysis.
Also, I’d like a way to completely cull the unconnected groups- especially in ‘river’ mode. I know the ppa mode is not actually a river finder but it could be useful for a few things. Is it possible to cull the unconnected groups completely Howard?
With specifically river networks in mind: It also might be possible to use the above idea to generate and cull river networks based on something like Strahler stream order. Where the ppa kept (did not cull) the branches that did not exceed an order in the network. The closest I can see to this in the ppa at the moment is Short Branch Threshold setting. That culls branches based on segments. The above idea would cull branches based on their order in the network.
monks
Hi Monks,
That’s a very interesting idea. Just like what you said, there is currently no concept of order (or structure) in the PPA result. I was looking into how to bring the Strahler stream order to the analysis program, but it got pushed over by other things. However, it’s always something I wanted to try, to give orders to the output of PPA. That way, we might have a culling threshold that makes more sense; that is, instead of removing branches depending on some heuristic threshold (such as the short branch threshold or end point threshold), we can choose not to show the branches with stream orders lower than the threshold.
I am pushing for a tight deadline right now, so I might have to postphone the release of the second module, but hopefully, I will have more time to experiment with this idea after August 7th. If you are interested, I can send you the source code for the PPA procedure. Sorry for the short response, back to work.
Howard
That's a very interesting idea. Just like what you said, there is currently no concept of order (or structure) in the PPA result.
I wasn’t wholly sure if I’d understood the full possiblities of the parameters and controls in the ppa. I’ll certainly include some renders in WM Pro in the near future to illustrate the ppa ‘in situ’.
I was looking into how to bring the Strahler stream order to the analysis program, but it got pushed over by other things. However, it's always something I wanted to try, to give orders to the output of PPA.
At the moment your implementation does allow for a lot of control actually. For the task it was designed for, I can see it’s going to be very interesting (wild!) to use; especially with your other devices.
In terms of network ordering- as we know, valleys and rivers are not the same thing, Rivers have a couple more constraints on them: they must flow downhill and must connect to an outflow (another river or the sea)- although as synthesised networks, gradient isn’t important. Fwiw I think you’re approaching this in the right way: I imagine stream ordering is the more difficult problem (for the analysis at least), but it may be that it’ll be possible to refine the ppa (at some point) to include the stream networks? It strikes me as being a natural progression anyway, but I’m sure it’s a case of time and priorities!
<blockquote>I am pushing for a tight deadline right now, so I might have to postphone the release of the second module, but hopefully, I will have more time to experiment with this idea after August 7th.</blockquote>
Good luck!
If you are interested, I can send you the source code for the PPA procedure. Sorry for the short response, back to work.
We’re all looking forward greatly to what you put together. I regret to say I’m not a programmer (worth a write-up) so the source code wouldn’t come to much good in my hands :lol:
monks