Hello,

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

Yes, but the tile-loading is automatic when you
read/write to a pixel in a tile that's not in memory.
This means that the program itself (and the user
too...) doesn't need to specify or even know which
tiles are loaded. It's all part of the mosaic-map
magic!

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

Oh, I recall reading on the WM forum that strong
erosion in explorer-mode caused seams/lips at tile
edges. That was back when WM1.0 was released, so maybe
there's been an update that I missed.

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