Hi Oshyan,

> Yeah, only time will make this more feasible. 64 bit
> OS and hardware, multi-core CPU's, etc.

Yup, and I'm hoping and praying for faster hard-disks
too. The disk-fetching delay can be a real pain when
you’re dealing with so much out-of-core data, even
with clever caching and multithreading.

> That is essentially what we've done, although it's
not nearly
> as rough as that. But the principle is the same as
far as I can
> tell.

Oh good. Perhaps I should read the ME-DEM FAQ more
closely :)

> The key here is "unless you do something do one tile
that
> doesn't 'leak across' to neighboring tiles". With
manual
> editing I don't see how there is a way to avoid
doing so.

This isn’t a problem, so long as the program can load
multiple tiles at the same time, and knows how they
join up. It's not easy, but it can be done. A quick
count shows that it takes a bit over 4000 lines of
code in L3DT, and around 3000 in the SDK (which is a
more efficient revision).

> How is it ensured that the effects leak across
tiles?

The map-wrapping class I use effectivley ‘hides’ the
map-tiling from the calculation algorithms, handling
all the tiling in the background. This means that the
overlays work the same for tiled and non-tiled maps,
so effects naturally ‘leak across’ tile borders as if
there was no tile border there.

> I am still not seeing how manual editing in
particular, and
> certain effects like erosion, could carry across
tiles
> appropriately ... Logically that canyon opening
should be
> receiving sediment from "upstream", but since the
tile ends
> there, it won't.

This may be a problem in WM, but you won’t see any
seams or creases in eroded heightmaps from L3DT.
Sediment can cross tile borders with no problems.

(To be fair, I’ll admit that Stephen’s erosion still
looks better than mine in every other respect.)

> I agree, that's the ideal solution, if it can be
made to work.
> Perhaps if the editor worked on arbitrary areas, but
stored and
> downloaded the terrain in tiles...?

Exactly!

> I didn't expect anything like that to *actually*
happen. I kind
> of figured it was over the top enough to show that.
;)

Yeah, I thought as much, but I felt it might be best
to make things explicit. I’m sorry if I was a bit too
gruff about it.

> Unless I could pay you all. <G> Dream #2: the
ultimate
> landscape application development house, with all 4
of you guys
> going at it full-time and paid. ;)

Ah, now that does sound like a nice dream!

Cheers,
Aaron.


--- Oshyan Greene <oshyan@...> wrote:

> > -----Original Message-----
> > From: L3DT_users_group@yahoogroups.com
> > [mailto:L3DT_users_group@yahoogroups.com] On
> Behalf Of Aaron Torpy
> > Sent: Thursday, November 17, 2005 11:24 PM
> > To: L3DT_users_group@yahoogroups.com
> > Subject: RE: [L3DT users' group] SDK progress
> report
> >
> > Yeah, that would be pretty cool. Then all you need
> > > is a program that can load those monster data
> sets.
> > ;)
> >
> > Hardware is the problem here. L3DTVi2 can load big
> > mosaic maps (I've looked at 32k x 32k maps
> before),
> > but you still have to keep your horizon-distance
> > relatively short because there isn't enough RAM to
> > view any further. Fancier algorithms might help
> (eg.
> > using pre-calculated low-resolution meshes for
> LOD,
> > etc), but ultimately you are always going to be
> > limited by how much RAM you've got. Of course,
> clever
> > procedurals have no RAM-problems, but they are
> > effectively just offloading the problem to the
> CPU, so
> > again you've got a hardware-limited problem.
>
> Yeah, only time will make this more feasible. 64 bit
> OS and hardware,
> multi-core CPU's, etc.
>
> > > Unfortunately for us that's just the very first
> > stage.
> > > That's our starting point. It just gets worse
> from
> > there, hehe.
> > > The 20k map is I believe 200 meters per pixel.
> We
> > want to cut
> > > that down to about 10 eventually.
> >
> > Other than the human-time involved in editing a
> > monster like that, this size shouldn't be a
> serious
> > problem. By the time you get to that resolution a
> > couple of hundred TB won't be a lot of disk-space.
> > L3DT can already handle maps that large (the
> texture
> > size-limit is 2M x 2M, and that can be increased
> to
> > about 1G x 1G if required). The SDK will also
> handle
> > terapixel maps out-of-the-box.
>
> Sounds good. I agree that by the time we get enough
> data to worry about
> space, we ought to be seeing 1TB HD's on the market
> at reasonable prices. By
> then I'll probably just build us a server with 10TB
> of space or something.
> :p We'll also probably be looking at home
> connections that are 10mbit
> bi-directional within 5 or so years. I'm already on
> 6mbit download, 600kbit
> upload...
>
> > > That's kind of a non-ideal solution. It would
> > probably result
> > > in pretty harsh lines if a larger area was not
> > edited.A better
> > > solution is needed I think.
> >
> > I might have another try at explaining this, if
> you
> > don't mind.
> >
> > I think you'll have trouble with editing map tiles
> > piece-wise and gluing them together afterwards.
> That
> > is a hard problem. What I propose is that you
> start
> > off with a really coarse map, like 50 x 50, that
> > covers the whole world. Something rough that could
> be
> > bashed-together in a couple of hours.
>
> That is essentially what we've done, although it's
> not nearly as rough as
> that. But the principle is the same as far as I can
> tell.
>
> > Then, using an interpolation algorithm, inflate
> the
> > whole thing by, say, 100x (splitting it into tiles
> if
> > required). Now, you can refine the heightmap using
> > some manual tools (eg. Wilbur), or whatever
> procedural
> > overlays you have at hand. Since you're editing a
> > heightmap that is already continuous and
> seam-free,
> > there won't be any seam problems unless you do
> > something to one tile that doesn't 'leak across'
> to
> > the neighbouring tiles. The method I described
> > previously is a way to prevent this.
>
> The key here is "unless you do something do one tile
> that doesn't 'leak
> across' to neighboring tiles". With manual editing I
> don't see how there is
> a way to avoid doing so. With procedurals it can
> obviously work just fine.
> But with effects like erosion it's easily possible
> to again run into
> problems, unless you're actually working on tiles
> that include overlap or
> something.
>
> > Anyhow, once everyone involved has finished
> refining
> > their patches of the heightmap, inflate the bugger
> > again and repeat.
> >
> > This method is what L3DT uses to generate
> heightmaps,
> > although the inflation is usually at steps of 2x
> and
> > all the editing/effects are handled automagically.
> And
> > it works on large maps too, without seams, since
> the
> > effects and overlays do indeed leak across tiles
> > appropriately.
>
> How is it ensured that the effects leak across
> tiles?
>
> > Anyhoo, there is no technical reason
> > that this method can't be modified to use larger
> > inflation steps with manual editing in-between.
> >
> > Did that make any sense, or am I still talking
> crap?
>
> Makes sense in general - although what you said
> previously made sense as
> well. I am still not seeing how manual editing in
> particular, and certain
> effects like erosion, could carry across tiles
> appropriately. For a specific
> example, let's say you have a canyon that spans
> several tiles and you want
> to erode it. At the bottom of the canyon you'll get
> sediment deposit and it
> will run downhill. Let's say the right edge of your
> tile has a canyon
> opening that runs downhill across the terrain to the
> left. Logically that
> canyon opening should be receiving sediment from
> "upstream", but since the
> tile ends there, it won't. It seems like that kind
> of thing would cause
> issues.
>
> > > Or some sort of overlap system perhaps?
> Ultimately
> > we want to
> > > have a bunch of equal tiles that can be
> downloaded
> > and glued
> > > together to form one contiguous terrain covering
> any
> > area you
> > > want, without seams. So the seam issue is
> critical.
> >
> > It is much harder to fix seams than it is to
> prevent
> > them from forming. You need an editing strategy
> that
> > forbids the formation of seams, as the above
> method
> > does (I think, unless I've missed something).
>
> I agree, that's the ideal solution, if it can be
> made to work. Perhaps if
> the editor worked on arbitrary areas, but stored and
> downloaded the terrain
> in tiles...?
>
> > > I'll tell you right here ideally we'd like to
> get
> > several
> > > developers involved, brainstorming on how to
> address
> > these
>
=== message truncated ===