L3DT users' community
Large 3D terrain generator

Special Overlays

Got a problem or need advice?

Special Overlays

Postby monks » Tue Jul 04, 2006 12:16 pm

H Aaron, I'm looking at the special overlays and will maybe include this in the tut. I can't find any documentation on them.

Mountain: how do the Big and Small parameters work?: how do they intereact with any Alt setting (or any oher DM pencil setting), or the Edit pixel attributes dialog?
How does the number of pixels contributing to the special overlay influence height?

Also is there any intended relationship between the DM pixel scale and the vertical scaling of the overlay. I'm thinking it must be a ratio to keep consistency...?

Cheers,
monks
monks
Oracle
 
Posts: 292
Joined: Tue Nov 22, 2005 10:38 pm
Location: Middle Earth

Re: Special Overlays

Postby Aaron » Tue Jul 04, 2006 12:50 pm

Hi Monks,

monks wrote:I'm looking at the special overlays and will maybe include this in the tut. I can't find any documentation on them.


Sorry, no docs. I recommend rampant and reckless experimentation.

monks wrote:Mountain: how do the Big and Small parameters work? : how do they intereact with any Alt setting (or any oher DM pencil setting), or the Edit pixel attributes dialog?


With small, you get a dodgy fractal mountain peak that's a few hundred metres high, and with large, you get a few more hundred metres (and a greater radius, I think). Honestly, I haven't used this feature in years - it's a relic of the old pre-v1.0 code before I had a decent erosion algorithm. I shouldn't think there would be a reason to use a mountain overlay these days.

In case you're wondering, the reason I've retained the special overlay feature is not because they're any good now, but because I plan to allow users to define their own special overlays via plugins/scripting some time down the track, which could be pretty neat.

monks wrote:How does the number of pixels contributing to the special overlay influence height?


Do you mean several design map pixels next to one another with the same special overlay? They might pile-up a little, but there's no real cumulative effect.

monks wrote:Also is there any intended relationship between the DM pixel scale and the vertical scaling of the overlay. I'm thinking it must be a ratio to keep consistency...?


Ah, now that would be sensible, but I'm not sure I was that thorough way back then. The special-overlay code pre-dates the option to change the horizontal scale. This is truely relic code.

Cheers,
Aaron.
User avatar
Aaron
Site Admin
 
Posts: 3696
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Postby monks » Tue Jul 04, 2006 6:07 pm

With small, you get a dodgy fractal mountain peak that's a few hundred metres high, and with large, you get a few more hundred metres (and a greater radius, I think). Honestly, I haven't used this feature in years - it's a relic of the old pre-v1.0 code before I had a decent erosion algorithm. I shouldn't think there would be a reason to use a mountain overlay these days.


So what are the settings? There seems to be some roughness in there- can you remember, does it have fractal noise pre-applied? Sounds like it has. I'm asking because I was trying to use it in combination with straight setting of heights. I got a mass of raised porridge-yum- with the peaks sticking out which suggests it might go further. This is basically what I was looking to do a while back.

In case you're wondering, the reason I've retained the special overlay feature is not because they're any good now, but because I plan to allow users to define their own special overlays via plugins/scripting some time down the track, which could be pretty neat.


Yeah- we talked about this some time ago. I started to wander down that road of thinking of new overlays. For instance, imagine you have your mass of raised terrain from your mountain overlay- lots of adjacent DM pixels. You even have your peaks defined which rise out of it via the Edit pixels function. It's possible to define your ridges- it's quite a strange effect, though not very convincing atmo. This is very similar to some ideas I had for the Mound tool. It would be nice to cut corners and do that via a ridge and valley overlay. I also thing that the curent mountain overlay would benefit from being straight: no noise or such.
The valley and ridge would still be quicker than the DM pencil. The overlays would use adjacent heights to setup their profile. It needn't be too advanced. If you can build a mountain overlay you can build a ridge overlay: it's simply a long thin mountain right? The valley is the inverse.
Also, what would be useful is to have a mountain stamp (set the shape via a lasso tool which snaps to the DM pixels), and then be able to overlap them so that they blended naturally.

Cheers,
monks
monks
Oracle
 
Posts: 292
Joined: Tue Nov 22, 2005 10:38 pm
Location: Middle Earth

Postby Aaron » Fri Jul 07, 2006 8:23 pm

Hi Monks,

monks wrote:So what are the settings?


The small mountains were 128x128 pixel fractal overlays, scaled to 400m height. The large mountains were 256x256 fractals scaled to 800m height. In either case the fractal persistence was 0.45 (or 2.22 if you define it 'the other way up').

In any case, I've changed all these settings for the next release, and added erosion to smooth-out some of the high-frequency noise. The height also changes according to the horizontal scale now.

monks wrote:I also thing that the curent mountain overlay would benefit from being straight: no noise or such.


This is what happens when the noise is turned to zero:

Image

Is this what you had in mind? (looks a bit pointy to me)

monks wrote:If you can build a mountain overlay you can build a ridge overlay: it's simply a long thin mountain right?


Oh if it were that easy.

monks wrote: Also, what would be useful is to have a mountain stamp (set the shape via a lasso tool which snaps to the DM pixels), and then be able to overlap them so that they blended naturally.


I'll think about it.

- Aaron.
User avatar
Aaron
Site Admin
 
Posts: 3696
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Postby DeathTwister » Sat Jul 08, 2006 12:30 pm

Humm interesting subject guys,

Aaron Wrote:
In case you're wondering, the reason I've retained the special overlay feature is not because they're any good now, but because I plan to allow users to define their own special overlays via plugins/scripting some time down the track, which could be pretty neat.


Has anyone made any plugins yet for L3DT? I have never seen any posts, so I am assuming that no one has yet? WOW something to look forward to. I bet the viewer will get lots of plugins as well when it starts to get worked on.
Sorry didn't mean to get opff topic, but that got me interested.

DT
User avatar
DeathTwister
Dearly missed
 
Posts: 562
Joined: Thu Dec 15, 2005 12:30 pm
Location: Klamath, CA.

Postby monks » Sat Jul 08, 2006 2:07 pm

DT said:
Has anyone made any plugins yet for L3DT? I have never seen any posts, so I am assuming that no one has yet? WOW something to look forward to. I bet the viewer will get lots of plugins as well when it starts to get worked on.


I don't think they have. Yeah, wasn't Aaron working on setting L3DT up to allow for plugin development?- not sure what the status of this is? The viewer will be pretty cool when it arrives I'm sure. I think that Aaron should follow Wilbur's example maybe, and provide one for both the DM and the HM because unlike most other terrain apps, Wilbur and L3DT have Design modes.
Wilbur's has real time feedback on the DM preview. I can't see any technical reason why L3DT shouldn't opt for one too. It is a real joy to work with and it can handle really large surfaces because it is rendering minimal info.
The way I envisage it, is at its most basic, to have literally a 3D view of the DM pixel blocks. That alone would be incredibly useful. Imagine being able to brush the DM pixels and see the blocks rising and falling.
Then maybe you introduce smoothing to those polygonal blocks. That's fairly strightforward in terms of 3D anyway (he said). Add a few lighting options; that's really it.

For the HM 3D prev, you wouldn't need 3D editing. I don't think it's that necessary to have something like what Leveller has for instance, where it uses a ray trace algo to find where the brush intersects on the 3D prev- it's nice if you have it and every once in a while it does come in handy, but I think that a DM prev editing gives most of what you need.
The HM prev will no doubt have the most development with textures and plugins, etc.


Aaron said:
The small mountains were 128x128 pixel fractal overlays, scaled to 400m height. The large mountains were 256x256 fractals scaled to 800m height. In either case the fractal persistence was 0.45 (or 2.22 if you define it 'the other way up').


I did jot down some heights vs number of pixels: the Mt Big starts out as 400m for 1 px, adding approx 150-200m for every pixel thereafter. It also seemed to give higher mts for larger axes- what I mean is a cluster of 8 px would give a higher mt if you had (3x2+2) rather than 2x4. Presumably because there is a point where the mt is 3 pixels across.
Anyway, it was all rather confusing, so I didn't go on to check the small mt.

-just had an idea: couldn't the plateau overlay be used to create a glacier?...

In any case, I've changed all these settings for the next release, and added erosion to smooth-out some of the high-frequency noise. The height also changes according to the horizontal scale now.


Ah- I've yet to really try out the erosion on the overlays, that's next. That's what I was wondering- whether the figures I got above depended on the map scale.

Oh if it were that easy.


:lol: - I'm full of remarks like that....



Is this what you had in mind? (looks a bit pointy to me)


The problem was, the noise on the surface of the special overlay didn't fit with the rest of the terrain. I wanted to set the rest of terain up the same. Alternatively, if the overlay was set to 0 noise, I could control it with the same settings as the surrounding terrain: it would all blend.


I am thinking you will almost always want your overlay to share the same Roughness, Erosion settings, as the immediately adjacent terrain. One approach would be to allow the user to manually set the Roughness, etc of the overlay- or simply 'copy from pixel' or whatever. This would still allow for special cases where it it different from the surrounding terrain such as with Carn Dum (ME-DEM) which is an igneous protrusion amidst masses of limestone.

I realise that a lot of this is academic for the time being but thinking about it, when you get some time, why not experiment with trying the code to place two overlapping overlays but producing two distinct mountains peaks.

I'm presuming, wrongly or rightly, that when you define the overlay, the extents of the selection = the base of the mountain. I think a more intuitive way, when placing two adjacent overlays that consist of many pixels, would have the abilty to overlap them and have some control over that overlap. This way you have some control over how the adjacent
mountains interact with one another. Are they part of a ridge sytem, or are they more distinct and seperate.

I tried this and they always formed (pretty much) just a larger single peak. L3DT has no conception of overlap right? The overlay + the edit pixels did produce the basic effect I was after (I set the edit pixels first), but I think the above suggestion using purely overlays is a much better and quicker way.

Once you have the overlap in place, maybe you could then experiment with introducing the noise back into the mountains- I think L3DT needs a noise function at the DM pixel scale.

We were talking about (parametric) L systems, and wadayaknow GeoControl appears with L-Systems- and it works. I think Wilbur is going down this route too (with some twists of its own). World Machine has splines in the layout mode, that's all I know at the moment. Leveller has suggested it favours custom rasterisable shapes and splines.
My argument is, once you have that basic Stroke (spline) entity, you can then code for procedural L Systems using them. That's the theory anyway :)

Leaving completely new approaches aside, thinking about it, L3DT is perfectly capable of producing very good mountains from:

configurations of DM pixels
noise
erosion

You need to be able to define your mountain overlay and then specify one or more spot height for summits. This is what I was trying to do, and I was getting there.
So the overlay needs to have the DM pixels within it randomised by L3DT to mimic how a user manually defines a mountain. As far as I can see you need:

Rising shape, cone or whatever.

A default summit or a user definable summit.- the combination of overlay and edit pixel produced this, so you kind of have this cracked...? :)

Base: (taken from the surrounding terrain)- you've already solved this too.

Mid-scale structure: ridges and valleys. Even with just suggestions at low res, the DM seems to create them well upon inflation and erosion. If the DM res the user is working at is very low giving mountains of a few pixels, then I imagine Roughness and Erosion would create this. In that case L3DT can't really help the user out too much because they're working at too low a res anyway. If the res is higher because the user wants more control over the shape of the mountain, then the user would create the ridges and valleys themselves. I think L3DT needs to procedurally mimic this somehow.

I found myself working like this to create a mountain range:

Define peaks and valleys with spot heights.
Join up those spots with a main ridge.
Draw a ramp to either side of the ridge to create the overall shape.
Add valleys and ridges coming of the main ridge, essentially breaking up the obvious ramp shape.

So for a single mountain, it might be:
Single peak.
Draw concentirc circles to create the cone.
Break up the shape with raise and lower to create or suggest ridges and valleys (depending on your res).

Could L3DT create this in DM pixels?

Another thought along these lines is to step back again and look at mountain chains. You can define the 'main ridge' of the mountain chain, even setting the pixel heights just as you would use the pencil now to define a line of pixels. The heights would control the general rise and flow of lower and higher mountain areas.
Then, you use the mountain overlay to manually place your mountains along that ridge. L3DT would take care of the generation of each individual mountain. It would have to create individual mountains. But then, if you had quick fire mountains, would you really need this?

I'm going to have a bit more of a play with the overlay- see what happens,

Cheers,
monks
monks
Oracle
 
Posts: 292
Joined: Tue Nov 22, 2005 10:38 pm
Location: Middle Earth

Postby monks » Sat Jul 08, 2006 8:22 pm

I tried spot heights with the big mt overlay again and tried a mountain chain. I really had to whack up the erosion on the overlay surface- it is at 10 in the pic. The actual spot heights are at erosion=6. I also added some roughness and fractal to the overlay, but I'm not sure if it had a real effect.

as you can see, very wizard's hat:

Image


I'm not quite sure how to judge how much higher the peaks are than the overlay surface- it might be possible to create valleys too. The peaks are at 2500m+.

I also had a problem when placing lots of plateau overlays in adjacent pixels. I got the following:
CMapWrap:SetPixel[can't read this bit!]
-invalid index

monks
monks
Oracle
 
Posts: 292
Joined: Tue Nov 22, 2005 10:38 pm
Location: Middle Earth

Postby Aaron » Sun Jul 09, 2006 11:53 am

Hello,

No, no plugins as yet. I had a plugin system going about 6 months ago (in a stripped-down L3DT build), but to be ready for general use I'd have to spend a few solid weeks (or months) on it.

Monks wrote: I did jot down some heights vs number of pixels: the Mt Big starts out as 400m for 1 px, adding approx 150-200m for every pixel thereafter. It also seemed to give higher mts for larger axes- what I mean is a cluster of 8 px would give a higher mt if you had (3x2+2) rather than 2x4. Presumably because there is a point where the mt is 3 pixels across.
Anyway, it was all rather confusing, so I didn't go on to check the small mt.


The overlays are wider than 1 DM pixel, so they overlap a little and add together.

Monks wrote: -just had an idea: couldn't the plateau overlay be used to create a glacier?...


Sorry, no.

Monks wrote:
The problem was, the noise on the surface of the special overlay didn't fit with the rest of the terrain.


They're less noisy in the next build.

Monks wrote:
One approach would be to allow the user to manually set the Roughness, etc of the overlay- or simply 'copy from pixel' or whatever.


I'll think about it. I hadn't put any effort into the special overlays for about the last two years, so they probably do need a bit of work.

Monks wrote:
I think a more intuitive way, when placing two adjacent overlays that consist of many pixels, would have the abilty to overlap them and have some control over that overlap. This way you have some control over how the adjacent mountains interact with one another. Are they part of a ridge sytem, or are they more distinct and seperate.


More intuitive, but harder to program. I'll think about it.

Monks wrote:
I tried this and they always formed (pretty much) just a larger single peak. L3DT has no conception of overlap right?


They are overlapping - that's why they form one big one. I guess it depends on what you mean by overlap.

Monks wrote:
My argument is, once you have that basic Stroke (spline) entity, you can then code for procedural L Systems using them. That's the theory anyway


Sorry Monks, I have no intention of adding splines any time in the foreseeable future. There are more pressing matters IM(not so H)O.

Monks wrote:
Could L3DT create this in DM pixels?


I think you could draw it manually, yes.

Monks wrote:
as you can see, very wizard's hat:


Agreed, pretty crappy looking.

Monks wrote:
I also had a problem when placing lots of plateau overlays in adjacent pixels. I got the following:


What version are you running? (check in the help->about box.)

Cheers,
Aaron.
User avatar
Aaron
Site Admin
 
Posts: 3696
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Postby monks » Sun Jul 09, 2006 3:17 pm

Release no: 2.4 Rev. 16
Build date: 03-July-06


The overlays are wider than 1 DM pixel, so they overlap a little and add together.


That's what I mean by the overlap. Where they overlap, I'm thinking they shouldn't add together, I think the operation is union or something? If both share the same height at a pixel, then set to that height, otherwise no height at all.

I didn't thimk for one minute that you were in a position (even if you were interested in the technology) to think about L Systems- just thought I give you the word on the terrain street - gives his best Huggy Bear impression :lol:

Righty-O- I'll quit harping for now :) I'm moving on to Leveller shortly anyway. I got some nice terrain out of L3DT and comparatively speedily too. I reallly wanted to continue right the way through with the terrain and do the whole area, but gotta be realistic.
The plateaus did give quite an interesting effect- they looked like broken up ice- seem to remember Mauro may have used them for this?

Cheers,
monks
monks
Oracle
 
Posts: 292
Joined: Tue Nov 22, 2005 10:38 pm
Location: Middle Earth

Postby Aaron » Sun Jul 09, 2006 4:31 pm

Hi Monks,

monks wrote:Release no: 2.4 Rev. 16
Build date: 03-July-06


Hmmm...What map size were you using?

That's what I mean by the overlap. Where they overlap, I'm thinking they shouldn't add together, I think the operation is union or something? If both share the same height at a pixel, then set to that height, otherwise no height at all.


Okie dokie. I can add a combiner such as that, but it would roughly double the RAM requirement during heightfield generation. Hmmm...unless I create a swap mosaic...lemme think about it.

I didn't thimk for one minute that you were in a position (even if you were interested in the technology) to think about L Systems


Cool. Sorry, I guess I mis-read.

The plateaus did give quite an interesting effect- they looked like broken up ice- seem to remember Mauro may have used them for this?


Yes, true. However, I think they're far from ideal for this application. A proper glacier overlay would need to be based on snow deposition/flow to get the correct directionality. In contrast, plateau overlays are basically mountain overlays that have been clipped-off at the top, which means they're always going to be round-ish and very un-glacier-like.

Cheers,
Aaron.
User avatar
Aaron
Site Admin
 
Posts: 3696
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Postby monks » Sun Jul 09, 2006 6:43 pm

Hmmm...What map size were you using?


It was the 4096 one. I basically put a plateau on every pixel to see if they combined somehow. It happened on the two plateau size settings I tried. The error log came up during the last Special Overlay sequence in the build.

Okie dokie. I can add a combiner such as that, but it would roughly double the RAM requirement during heightfield generation. Hmmm...unless I create a swap mosaic...lemme think about it.


I've not worded that corectly, it should read: if both share the same height at a pixel, then set to that height, otherwise keep the heights of the respective mts the same. Anyway, it is a union.

I think this would produce the effect because it seems very similar to how the mound tool can operate. Basically it means that when you overlap mounds, you can more or less guage where the lowest point will be (the saddle), so you can make mountains that stand off one another or cram right together.

Yes, true. However, I think they're far from ideal for this application. A proper glacier overlay would need to be based on snow deposition/flow to get the correct directionality. In contrast, plateau overlays are basically mountain overlays that have been clipped-off at the top, which means they're always going to be round-ish and very un-glacier-like.


What I was thinking of doing- the thought only occured to me in that post- was to overlay the plateau and then go on to put the flow in elsewhere. At the moment, there's no one application that can do the entire thing. It's either put the flow in with a brush, or fake it at render time. The problem is the flow. If you look at a glacier, there is virtually no flow from the mts onto the glacier, it's all very decidedly down the glacier. Considering that a glacier, tends to fall off laterally, this makes it surely impossible for erosion to create these striations and lateral morraines, because the erosion would flow from the hump down to the sides. I suppose the difference is that if it to be considered terrain, it is moving terrain.

Thanks for the patience Aaron, I think out loud and they must sound like feature requests piling up- they're not, I'm trying to see where you're interested in taking L3DT in theory and I likea to talka a lotta crap hehe

monks.
monks
Oracle
 
Posts: 292
Joined: Tue Nov 22, 2005 10:38 pm
Location: Middle Earth


Return to Help and support

Who is online

Users browsing this forum: No registered users and 9 guests

cron