> -----Original Message-----
> From: L3DT_users_group@yahoogroups.com
> [mailto:L3DT_users_group@yahoogroups.com] On Behalf Of Aaron Torpy
> Sent: Friday, November 18, 2005 6:17 AM
> To: L3DT_users_group@yahoogroups.com
> Subject: RE: [L3DT users' group] SDK progress report
>
> > 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.

Yes, this is a very good point. It was fairly long ago that we passed the
point where the data transfer capability of the interface surpassed the HD's
ability to serve said data. Faster drives (RPM) tend to be noisier however,
and there is a limit to how dense we can make them. So when will we see a
truly "next generation" storage technology? Optical disk certainly isn't
it...

> > 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 :)

Unfortunately it's not all covered. We really need someone semi-dedicated to
keeping that stuff up-to-date. We've tended to focus information in the
forums and the discussions there tend to give rise to the majority of
understanding on matters like that. But reading each full thread is of
course unnecessary to simply get the gist of what was *concluded*. So a
distillation of the decisions made thus far, and the processes currently in
use, would be a good thing to have. Unfortunately for all of us working on
it right now it is one amongst many demanding projects, so it only gets a
little bit of time.

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

Ah, this is the key here, and it makes it all clear. <G>

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

This only works if you have multiple tiles loaded though, right?

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

I'm not sure if it's a problem in WM actually. I think the erosion device is
"Explorer Friendly", so it shouldn't be a problem. But since WM doesn't have
tiled output yet anyway, it's not really something you can easily test.
Since tiled output is on the to-do list, I'm sure we'll be able to see soon
enough, and given the intended use of that feature it seems likely that
erosion has been made "tile safe".

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

I'm not aware of any other erosion that's as cool as WM's quite frankly. So
don't feel bad. ;)

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

Ah hah! <G>

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

Not to worry.

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

I'll get right to work on it. ;)

- Oshyan