erosion wall

The erosion wall, I run in to this more then I’d like. I dought if there is any salution to the problem, other then fixing it in the next build.

I’m certainly aware of this problem, but I actually haven’t had it significantly affect me much, and I do use erosion a lot. Would you mind sending along the illustrated file? I’m curious to see if there’s any particular settings that you may be using that accentuate the effect .

  • Oshyan

illistrated file?
Well, it’s easy enough to figure out, fluvial, inverce and extream. This build just wasn’t going to give me what I wanted so I scraped it. I’ve started a new one, I’m trying to make a rolled stone river bottom. I’m calling it babbling broke. Considerably harder then I thought it was going to be.

I have run in to this before, but it’s only this bad if the erosion settings are too high. You notice the wall runs out at 0 hieght. I’m sure you know the wall is just a 1 pixle line of the uneroded terrain. Nothing major, just an anoyance.

Hi manleystanley…
You may try my macro zoom in (at the bottom of the page), so that the walls get out of the bounds once zoomed.
Hope this helps…

Basically the problem here is that the erosion simulation doesn’t go beyond the edges of the current terrain square we’re working on. If I’m not mistaken this may well be fixed in 1.0, since there seems to be some kind of greater “world explore” feature outside of the current “bounding box”. In any case any fix implemented wouldn’t be much different from Ralph’s zoom macro, in concept at least.

  • Oshyan

I’ll try that zoom macro if I have anymore erosion walls turn up in my terrains. If it’s a public macro I probebly have it; although I may not have used it yet.

As Oshyan says, the wall at the edges is because the simulation only goes up to one space from the edge of the terrain; it can’t operate reliably on the exact edge since there is no terrain on one half of the world. There are workarounds for this, but none are currently implemented in WM. It’s a sort of a low-priority problem for now, although doubtless it will be fixed eventually

Actually, this was easier to fix than I thought. It should be fixed for v1.0.

Cool, can’t wait for the next one.

How about a new sprocket to input a bit map?
ya I know there are other programs to turn a bit map to a ter and then imput the ter, but why not have a sprocket for it?

Or numerical values for the hieght selector and splitor. I like to use the selector for making river beds and banks, it just gets agrevating going back and forth from TG to WM to get the mask right.

or some way to show a paticular hieght on the terrain map. as a black or white horazontel line.

oh, renders done gotta go.

The File Input device would be used for .bmp import. A separate divice is not needed. All that should be done is expanding the in/out format support, which I believe will be a part of 1.0. Probably to a wider range of 16+ bit image formats, as well as more standard image formats like tiff, bmp, png, etc.

As far as numerical values on things like the height selectors, I strongly agree. Not sure if this is planned for 1.0, but I would guess yes as it’s a logical addition. My only additional request would be a meters/“units” switch, like TG. So I can view it in WM’s internal 0-1 range, but also “meters”. This would only really be useful if WM allows an arbitrary meter range in 1.0.

  • Oshyan

Numerical inputs was not planned per se for 1.0, but I’ve just added it per your requests, with one LARGE caveat:

It only will be the case for devices that use the generic dialog manager. Older devices (like Height Selector) won’t have input boxes, since I have to go back and re code each device that uses them. But newer devices and macros will have them enabled.

Allowing meters to be displayed/entered is alot more troublesome, because WM natively doesn’t understand when a float is just a float, and when it is a float that is referring to a height. Doing something like this would require a fair bit of internal reworking, which I don’t think its important enough to justify IMHO.

Anything would be helpful to give me some sort of idea were the water line, or drastic terrain changes take place. I think a white or black line running horazontaly parelel to the terrain base at a selectable hieght, in the 3d view, would be too sweet.