> -----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
> > problems. We figure if the software can be made free
> or open
> > source or something, it'll probably be applicable to
> other
> > people's projects too.
>
> I'm happy to brainstorm ideas, but I can't promise
> that I'll be able to write any huge amount of code.
> We'll see, I guess.

Just figuring out what exactly we need and generally how to do it is really
what I'm most interested in at this point. Getting a coder to do it is
another matter, but it's not really worth worrying about until we know
exactly what we need to do.

> > So eventually it'd be great if you and Ray of
> Leveller and
> > Stephen of World Machine and the Wilbur guy
> (forgetting his
> > name right now) all got together and made us a kick
> ass
> > app/system/framework/dingly. And then I woke up from
> > my beautiful dream. ;)
>
> I think that may stay just a dream, to be honest. I
> can't speak for all the developers you mentioned; but
> I'm pretty sure it would not be in our best interest
> to produce one product that could fundamentally
> undermine the markets for our individual projects.

Joe's Wilbur is not presently commercial, but I certainly see your point,
and honestly I didn't expect anything like that to *actually* happen. I kind
of figured it was over the top enough to show that. ;)

> Making it open-source would only make matters worse,
> in a purely selfish sense, because we would be
> spending a lot of time, donating a lot of IP, and
> profiting very little. I simply can't see the benefits
> (to us, that is).

Well, Ray is already working on potentially open-sourcing Leveller (with a
model that includes a profit base for him however). So it's not necessarily
as crazy as it sounds. But it's not a practical idea in a collaborative
sense, of course. 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. ;)

> Whoa, sorry for that bitter, mercenary cynicism. I
> think I need a lie-down after a long week or
> something.

Hehe, I think it's more like reality. Maybe cynical reality, but reality
nonetheless. And I understood that it isn't something that will ever happen
to begin with. It really was a dream. But it would still be great to have
all of you guys at least talking about it.

> Anyhoo, a one-package approach may not be necessary if
> all the tools you mentioned were more interoperable,
> used common formats, etc. I'm happy to work towards
> this goal.

Agreed, and 3 out of 4 of the products have SDK's too, so it might not be
that hard to get them to all work together nicely.

- Oshyan