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.
- 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