> -----Original Message-----
> From: L3DT_users_group@yahoogroups.com
> [mailto:L3DT_users_group@yahoogroups.com] On Behalf Of monkschain
> Sent: Wednesday, November 16, 2005 3:34 PM
> To: L3DT_users_group@yahoogroups.com
> Subject: Re: [L3DT users' group] SDK progress report
<snip>
> I just wanted to pipe in with a couple of details if that's OK Aaron.
> The most useful short term addition would be the image overlay (with
> transparency) so that terrain could be 'defined' from a topo
> reference. Like tracing over it. I see that that is on the dev
> roadmap so that's great. With this we might be able to go ahead with
> using L3D straight away (without all the other cool stuff mentioned
> of course).

Yeah, this would allow us to be working with L3DT right away, and I have no
doubt it would speed up our work process.

> The abilty to load existing terrain and create in this manner in
> *replace mode*. So one would load up a low res dem with the
> corresponding image overlay (topo map) and then use the elevations of
> that low res dem for reference (one would need some kind of cursor
> feedback for height or something) along with the topo overlay. So one
> would know, here is a mountain and this is it's approx height. Define
> it with the L3D tools and bingo.

It would be nice to also be able to define a maximum deviation (in both
positive and negative elevation, separately) from the base heightfield,
and/or a maximum and minimum height to stay within. Because our base
heightmaps will have a certain level of accuracy, and spot-heights will in
fact be relatively accurate at the given scale, we'll want to maintain the
approximate heights while adding additional detail and variation. It would
be a simple matter to extrapolate a safe range of height variation/deviation
from the known accuracy of the current data. For example if you have
200m/pixel "measured" data, resampled to 20m/pixel, you know that you want
no more than a 100 meter deviation in either the positive or negative. Or at
least that's what makes sense to me. But regardless of whether that's
entirely accurate you *could* easily come up with some similar rules like
that which *would* be accurate. Also it's likely we'll know the heights of
mountains, for example, so if we're working on a particular mountain it
would be useful to be able to define the max height it should reach. Using
this kind of "replace"/augment functionality in addition to the overlay
function mentioned above would be ideal.

> The ability to load up tile sets that are multiples of x Km (on the
> first pass each tile will be 1K px on a side at 1 px= 20m....20 Km on
> a side, on the second pass (down the line) each tile with a factor of
> 10 larger scale- that is, each tile being 1K px still, but at 2m res,
> so 2 Km on a side). This would be really useful as users could work
> on larger areas (which is probably the preferred approach).

With the existing tiled output of L3DT, this seems like it should be fairly
simple to accomplish and would definitely be useful.

> ps Joe Slayton of Wilbur (he's helped us out already). ;)

Ah yes. Thanks. :)

> ps I'm still convinced that L3D could fundamentally change the way
> people build terrain models.

Absolutely. The two major feature additions mentioned above - overlay
support and replace/augment (with deviation/bounds controls) of a loaded
heightfield - would pretty much get us all the functionality we need at
present and would massively speed up our workflow. The terrains coming out
of L3DT ought to be essentially ready for use at the 20m scale. For finer
scales we'd probably want to do some hand editing, but just getting the 20m
done is a big goal for now. And I'm thinking more and more thay doing our
first 20k area up to 20m should be an initial goal, beyond which we should
move on to other areas and do them down to 20m. Once we have the whole of
the planet modeled at that level (a gargantuan task), we can consider going
smaller. And meanwhile spot areas of interest that require more detail can
be done down to 2m or whatever.

- Oshyan