--- In L3DT_users_group@yahoogroups.com, "Oshyan Greene"
<oshyan@s...> wrote:
>
> > -----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>

> > The abilty to load existing terrain and create in this manner in
> > *replace mode*....

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

Yeah, the deviation/constraints is a good idea. I imagine it's not
an ideal situation for a programmer to have a 'base dem' which to
replace/augment, (easier to start from scratch maybe ?) but even
though on the face of it it may seem like the base dem gets in the
way, it does have a LOT of information in it, and importantly, self-
consistent and consistent with our global info too. I think this was
the only feasable approach via the tiling route. The other one is to
do the whole thing from scratch in one go or a few pieces...yikes!


> > ps I'm still convinced that L3D could fundamentally change the
way
> > people build terrain models.
>
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.


Yes, I think I'm with you on that. With the 2m thingy I was reading
the script more to give Aaron an idea of the overall algorithm as it
were. Now that we have the 'globalisation' issue pretty much sussed
(ie, we can safely interpret Tolkien's wishes that Middle Earth is a
parallel Earth, ergo we use an Earth globe which brings many
technical advantages, and we have candidates for datums
(Numenor/Rivendell) and the configuration of the continents), it
would be more elegant (top-down approach again) to do that. We have
TGD and Leveller moving in the georef direction which helps. Plus it
has practical advantages- by the time we come to the monstrous 2m
datasets, we should have an easier time of it. We're operating on the
bounds of the 32 bit OS I feel with this.
The programmer collaboration between those luminaries Oshyan is
indeed a sweet dream :)