image masking

[monks]

I'm *really* wanting to see image masks as a feature. For instance, import a binary mask, use brush over it- black = no brush effect, white = normal brush effect.
I'm looking to move between a few apps with GC in the middle. I'd like to be able to import river masks into GC and then use the filters (Brush, etc) on them so that I don't add any changes the the rivers.
What about a new tab in the Selectors panel called 'image mask' so you can make a selection based on that?
We're gearing up at ME-DEM to do the 20K dem to a much higher detail in preparation for the procedural zoom later in the year :) We've finally going to have the 20K dem without any seams- yay!

monks

[cajomi]

I think, this will be implemented.

[monks]

Awesome! thanks Johannes.

monks

[Criss]

Speaking of importing import river masks into Geo Control. Is there still going to be a river tool of some sort for version 2. I know this was mentioned some time back.

[cajomi]

Yes, we still need some specialized tools, for ways/roads and for rivers, and I will add them to a own panel beside the isolines. This tools must generate masks for a proper shading afterwords. And the river tool should deliver also a terrain, which can be used as waterterrain. That is the only possbility, to get water with a fine slope.

[SeerBlue]

I have spent a bit of time working on masking for rivers manually, and have found that Cajomi is right on the the fact that the river tool should deliver a waterterrain. When it comes time to render your image i have found that the terrain creation tools do a great job at making the heightfield, the channels bank and flow as the terrain created by water should, but once a water surface is applied to the channel network via a mask , such as with TGTP, you get water that slants from the horizontal as it follows the heightfield exactly.
So a waterterrain is necessary to give you a nice plane between the banks of your channel, in essence to fil in the space the water would occupy. I don't have any programming knowledge , so the rest of my post may be way off,,,but the only way to implement it I could think of was that the ability to read the mask would be needed to identify the channels: ie white is water, black is terrain, then perhaps a iteration of some sort of search window that would identify the x.y, and z of the heightfield that falls within the mask to "plot" the channels.
As channels have banks, and the water level falls below these, it would be necesssary to differentiate between the run, or length of a channel, and its width, so that the waterterrain would be level between the banks for a given point while still following the elevation change throughout its length, but also slightly below the lowest bank.
For example a terrain will have watercourses that run to every possible direction, so some will have the banks that fall on the same x coordinate and some will have banks that fall on the same y coordinate, and I guess the app would have to use that to identify the width of the channel( as width will always be less than length, or fewer white pixels between the black pixels in the mask means width) and build the waterterrain's horizontal (or level) plane from there..otherwise on may end up with a very deep canyon throughout the terrain as the elevation increases.
I currently build a quasi waterterrain from masks generated with SagaGis, converted to a heightfield, and merged with the original terrain, but this is very hit and miss to adjust manually, so I am happy to see it being worked for such a fine app.

[monks]

Hi Seer, yes I think you've been knee deep (or is it neck deep?)in this stuff.hehe We need something that will really help this complex process. Something is needed that will hook up the river in the terrain to the river in the renderer. The isolines tools is halfway there for sure.

I think this is where water heightmaps are extremely useful- however you get them. We have geomorpher's water heightmaps on the TS, but that's using tech that is still a bit off yet and it's still beta anyhow, then there's L3DT- apparently it can output water heightmaps so Aaron said. L3DT is not using next gen algos, so it must be possible in all of the current terrain apps?

All you would need is to be able to export the designated rivers as a surface. So, if you have a special 'River' tool. The output of the heightmap created by that tool should be ideal for exporting to your renderer. It will compliment the accompanying terrain- ie the water will be flat, smoothish and just below the banks or however you intended it.

monks

[cajomi]

Well, I will look for a solution. But it is not planned, to generate such waterterrains from imported masks. To be true, I have to think about it at all, how to implement is best and easyest way.
In general there are two possibilities:
One is, that the user set a starting point, best in the edge of a terrain, and GC then searches for the way, the river would flow. With creating lakes. This would be a slow algorithm.
Second is, that the river tool is to combine with isolines. So the river valleys are constructed using isolines, but the deepest part, the river itself, is drawn with a special isoline. The advantage here would be, that such river can break through a hill line, like it is often in nature.

[monks]

One is, that the user set a starting point, best in the edge of a terrain, and GC then searches for the way, the river would flow. With creating lakes. This would be a slow algorithm.
Second is, that the river tool is to combine with isolines. So the river valleys are constructed using isolines, but the deepest part, the river itself, is drawn with a special isoline. The advantage here would be, that such river can break through a hill line, like it is often in nature.

I think that both of these possibilities basically sums up what is needed. We've found that the 'ideal' toolset is to have:
*) Create river floodplains, valleys manually- ie isoline. You would use a number of isolines on your terrain to create the *main* rivers network.
*) Then when you have hand drawn your rivers with isolines, you want nature to add more detail to the river network; tributaries- the algorithm knows best how to do this and is super efficient.

Then after you have applied both tools you have a complete river network.

But say you had rivers that went through a city on your map, you still want to be able to delete any rivers that don't fit into your level map or terrain. Of course, you simply take up the GeoControl Brush, and draw over them! :)
It would also be handy to have input and output of water maps: heightmap (I think GeoControl can already do this in project Layers) and imagemap.

Folks at ME-DEM have talked about an L-Sytem network generator, -I think GeoControl already has something like this for terrain generation. The difference would be is the network generated would be logically distinct (in terms of code description) from the heightfield- maybe as a network of isolines?
For instance, imagine being able to do this:

With isolines, paint in your main rivers- they are all in the correct places.
You then want to add tributaries to these main rivers so you want rivers flowing *into* these main rivers. So, with a special river tool (?), click on any point along the length of the isoline and GeoControl grows another river off that one as far as nature will take it *upstream* (like erosion in reverse but it wouldn't have to erode at all- just like a path finding algorithm). The algorithm stops searching as soon as it can only go downhill. GeoControl could convert these to isolines.
You could keep clicking until you got the complexity of rivers you like.
Basically this would serve to generate river catchment areas that feed into the main watercourses.

-so you get a good balance of artistic input and the power of procedurals.

monks

[cajomi]

Your idea sounds really good. Normal isolines will not be able to do the job, you described, but a more special one, which then can be rubbed for example, the city problem.
Should be possible. I will give it a try.

[monks]

Looking forward to see what you come up with!
There's just one more thing about rivers which I think is the final piece of the puzzle.
Rivers are not always the same width like autobahns, they vary along their course. A general rule of thumb could be the higher the altitude at a vertex/pixel (within the whole terrain span). the narrower the river.
One way of approaching this is to vary the isoline width according to the altitude *within*
that terrain.
Eg, you have a terrain that spans 0 - 3000m. You would want your rivers to vary in width as they start in the mountains as narrow springs and gradually widen as they make their way to the lowest point on that terrain- whether that be sea or not.
But what is the narrowest and what is the widest river on the terrain?
Here's a couple of ideas as ways to approach this.

*) Use an arbitrary slider (0-1) which says narrow or large rivers with no particular
emphasis on real world units or natural phenomena.
*) The other way is to let the user to decide how much water is in the system- the
atmosphere. Is it wet or dry?, permeable rock, impervious rock, what latitude, etc? I'm not
saying use all of these (too complicated!) but you get what I mean.
GeoControl would find the scale of the terrain and determine the maximum width of the river based on the wetness (as supplied by the user). The wetness options the user can choose from could be loosley based on real world; tropical, temperate, desert.
The minimum width is already known- as 1 pixel- or whatever is the easiest small river for
GeoControl to create.

A bit more flexibility would be added if the user could specify the range of altitude that
rivers are to be found in. This way it can be a subset of the total altitude range of the
terrain. Eg, say that my terrain was just midlands (no mountians and no sea), The user could say that the rivers have their beginning and ends *off* the terrain by specifying max and min which are within the height limits of the terrain.
Or perhaps better, the min and max river width?

The best system of deciding how much water is in the terrain I've seen to date is the one used by ViewingDale Geomorpher. It is extremely simple- it simply uses temperature maps to vary rainfall. Anyway, geomorpher could become a terrain physics library that devs can tap into. GeoControl's isolines will give more control over river courses though because Geomorpher doesn't have a UI.

I think once you go to continental sized terrains, you're probably going to end up looking
at something like that -say temperature maps/ climate maps, etc, like L3DT, FT, geo.

Another idea is to use the organisation already present in GeoControl;- the filters. Could GeoControl store a map of where the filters have been applied? Any map area with a mountain filter on it could have river origins within it. I don't think this is that useful for *rivers* but it would be really useful for creating continents and maybe procedural zooming.

So after all this,I think you need a way of varying the width of isolines or the special river isolines that you write. Maybe the river isoline is a distinct kind of isoline? You have the generic isoline, then you could have specialised isolines such as rivers, roads, glaciers, etc.
Could a varying width of river be created by 2 parallel isolines perhaps? Maybe a river isoline is made of 2 isolines in parallel to a central ghost isoline. ie the user specifies the isoline as the middle of the river- this is the ghost isoline. The real isolines would be equally spaced to either side of the ghost. Maybe that's difficult to program, dunno.

Lots of thoughts- apologies- for waffling on! :)

monks

[cajomi]

Well, the fluvial soft erosion has exact the behavior, you are describing. Starts small and width grow, when the flow gets longer.
Before you are thinking to complicate: A continental size terrain needs a relativ low noise in the middle and low parts of the terrain.
So, for generating a continent, best way is simply to use a heightselection for controlling the noise strength. Such a terrain now is optimal to create long flows, down to the ocean, because a low noise produces continous sloping. With the fluvial soft algorithm, you would get at all very convincing rivers. And to take into account, that the higher the rivers are, the less visible they are, you can use a heightselection again, to blend the rivers out in the higher parts.
Of course, defining the continent will need a good isoline work.

And there is another general problem: We are often thinking in maps.
So, lets us think a moment about scaling. A continent, well let us assume, it has a wide of 2000*2000 km. That would mean, in a 8192 terrain one pixel correpondents to 250 m. Well, 250 for a river would only appear in a delta zone.
Zooming this, or tiling into 16 terrains, would give the max. resolution of 15 m. That is okay for middle wide rivers, they would be represented by a extram small line. While a wide river in the flat continental zone, would span 4 to 8 points. In this resolution still the small rivers, you are thinking of, which starts in the mointains, will still not be visible. They will appear in the next 16 tiling. So, a landscape with conitinental scale and a visible small rivers in the higher regions, would be a set of 256*256 terrains, with 8192 terrains, or 512*512 with 4096 or 2048*2048 1024pt terrains.

I hope you see, that talking about a river creation in continental scale (and 2000 km is a small continent), is absolutly theoretical, when a algorithm should be used to create all: The small, the middle and the wide river parts.

[monks]

Well, the fluvial soft erosion has exact the behavior, you are describing. Starts small and width grow, when the flow gets longer.
Before you are thinking to complicate: A continental size terrain needs a relativ low noise in the middle and low parts of the terrain.
So, for generating a continent, best way is simply to use a heightselection for controlling the noise strength. Such a terrain now is optimal to create long flows, down to the ocean, because a low noise produces continous sloping. With the fluvial soft algorithm, you would get at all very convincing rivers. And to take into account, that the higher the rivers are, the less visible they are, you can use a heightselection again, to blend the rivers out in the higher parts.
Of course, defining the continent will need a good isoline work.

Yes, I just fired off lots of ideas :) I trust that you understand the fine details better than I do :) I think that once these features all come to pass, a small tutorial would help. Everybody wants rivers (or at least river valleys) after all.

And there is another general problem: We are often thinking in maps.
So, lets us think a moment about scaling. A continent, well let us assume, it has a wide of 2000*2000 km. That would mean, in a 8192 terrain one pixel correpondents to 250 m. Well, 250 for a river would only appear in a delta zone.

Yep.

Zooming this, or tiling into 16 terrains, would give the max. resolution of 15 m.


What scheme have you got planned for this? I don't understand how you go from 250m to 15m in one zoom. I thought it would be 250 -> 250/4 = 62m.??
Do you mean 16 x 16 terrains? Yes from reading below I think you do...


That is okay for middle wide rivers, they would be represented by a extram small line. While a wide river in the flat continental zone, would span 4 to 8 points. In this resolution still the small rivers, you are thinking of, which starts in the mointains, will still not be visible. They will appear in the next 16 tiling.

Yes.


So, a landscape with conitinental scale and a visible small rivers in the higher regions, would be a set of 256*256 terrains, with 8192 terrains, or 512*512 with 4096 or 2048*2048 1024pt terrains.

so another zoom gives (16 x16) x 16 = 256 x 256.
Yes, I'm with you now- you can define the tile size before zoooming. This ranges from a zoom of x4 to x8 in your examples above.

I hope you see, that talking about a river creation in continental scale (and 2000 km is a small continent), is absolutly theoretical, when a algorithm should be used to create all: The small, the middle and the wide river parts.

Yes, I totally agree. This is something that has always bugged me. Ideally we need a bit of both. We need procedural zoom- no doubt about it- massive importance. I also think that being able to use scalable vectors would really help. Eg, you define the rivers as an isoline. This isoline can be saved or interpreted by GeoControl as a vector.
So, you draw isoline for the river course. ->Procedural zoom. ->The river course is still the same width on the display-ie a vector line- but it is scaled along the x and y axes with the zoom; it still stretches from mountains to sea. The special isoline (or river isoline/vector) would have additional information stored with it to describe it's width along its course. This would also be scaled with the zoom- the width gets wider. This needn't be visible- still see a vector line, but the increasing width after zoom would be good to see as maybe a shadow or shaded/coloured area.
That sounds a bit complicated but I really think the basic idea of scalable vectors is a good one- especially to solve this particular general problem of *rivers* and *zoom*. Maybe your erosion would take care of the varying width of the river but ideally you want to have some kind of control over the relative width of that river- ie the maximum width at the delta it can reach. After all some rivers are significantly bigger than others- I don't think erosion alone would be enough to give enough control over variation.

monks

[digitalis]

Hi,

I thought of the request for image masking based on isolines, so that specific parts of the terrain can be selected for filtering.
I just read in this forum item that my suggestion (more or less) has been done before.

Anyhow, based on isolines or not, I think GC2 needs a (more) flexible masking tool.

Kind regards.

[cajomi]

There will be no mask from isolines. Not possible. But there will be a tool for drawing masks.
What do you mean with more flexibility?