Hi Everyone,

My, it has been quiet around here since the forum went up, hasn't it?
Anyhoo, for the benefit of those who haven't subscribed to the RSS
feeds for the L3DT forums and/or development log (the best way to
keep in touch with all things L3DT), I'm pleased to announce that
L3DT Release 2.5 is ready. You can read all about it in the release
announcement here:

http://www.bundysoft.com/news/doku.php?id=l3dt:ann:v2.5

Best regards,
Aaron Torpy.

Hello everyone,

For those that haven't visited the L3DT website lately or subscribed
to the automatic news-feeds, you may be interested to know that there
is a new release of L3DT available (v2.4). The main differences with
the previous version (v2.3d) are:

* Improved texture blending, including better high-res detail and
strata effects.
* Better heightfield generation (using a new thermal erosion routine).
* A user-interface for editing climates (still a bit crude, though).
* Some tweaks to the user-interface to make it more streamlined.
* A built-in walk-through guide for new users.
* Better file support, particularly for RAW and images.
* Rudimentary geo-referencing support for the VTP .bt terrain format.
* An improved installer that allows multiple versions to coexist nicely.
* Several messy text-based formats were upgraded to XML.
* There were loads of bug-fixes.

The commercial release of L3DT Professional, as we discussed on this
list late last year, is now available. Interested parties may purchase
a non-expiring license (via PayPal) from the downloads page at a cost
of $25 USD:

www.bundysoft.com/L3DT/downloads/professional.php

The free Standard Edition is also available, and hopefully sufficient
for a lot of people's needs. The current limitations of SE are:

* The maximum size for heightfields and textures is capped at 2048 x 2048.
* Mosaic heightfields are disabled (though mosaic textures are allowed).
* It doesn't do the ultra-high res textures (4x res is the limit).
* It doesn't do high-res light-mapping or bump-mapping.
* It does not include wizard presets (although I may enable this soon
in SE).

Otherwise, it's pretty much the same as Pro.

Finally, I'd like to take this opportunity to sincerely thank all the
members of the mailing list who registered for the beta program and
helped-out with bug reports and feature suggestions. I couldn't have
got to this point without y'all.

Best regards,
Aaron.

Hello All,

I thought I might revive the mailing-list to notify users of a new
beta-release of L3DT (v2.4 beta3). This one includes some recent
improvements to the bump-mapping and texturing algorithms, and also a
swag of bug-fixes. The news announcement is here:

http://www.bundysoft.com/news/doku.php?id=l3dt:ann:v2.4beta3

Cheers,
Aaron.

Hello Karan,

I'll post the latter half of my answer to the mailing
list as well, for the sake of other users:

The final price is probably going to be $25 USD, and
the method of payment will be paypal/credit card (at
least initially).

Cheers,
Aaron.

--- karan amarnath <dude48in@...> wrote:

>
>
> Hi aaron,
> nice work with the 2.3 b version did not try
> 2.3c.Could you send me the 2.3d pro evaluation build
> as well.You already have my details.Another thing
> what
> will the final price for 2.4 and what is the mode of
> payment.
> Thanks
> karan amarnath
>
>
>
>
>
__________________________________________________________
>
> Yahoo! India Matrimony: Find your partner now. Go to
> http://yahoo.shaadi.com
>

Hi aaron,
nice work with the 2.3 b version did not try
2.3c.Could you send me the 2.3d pro evaluation build
as well.You already have my details.Another thing what
will the final price for 2.4 and what is the mode of
payment.
Thanks
karan amarnath




__________________________________________________________
Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com

Grrr,

User banned, message deleted from board. I hate spiced
ham!

Aaron.

--- "diva-bensley281@..."
<diva-bensley281@...> wrote:

> I know some friends already who have met a few nice
> honeys off of this kind of stuff (here is the place
> they use: http://www.onlinechatrooms.info/nsxu , but
> what do you think? I think it is mad cool from what
> I saw at my friend’s house, and am thinking of
> signing up later today. Basically it's a regular
> personalssite, but with an instant message and
> Webcams system built in. Basically you join their
> chat-room on their site it gives you a link to those
> people online in the chat-room, their location,
> their picture, etc and at one click you can start
> chatting to them over Webcam (even if you don't have
> one). Pretty nifty stuff I think!
>
>

Hi Everyone,

There is a new release of L3DT ready!

Please refer to the following URL for further information:

http://www.bundysoft.com/L3DT/news/2006.php#L3DT2.3c

Cheerio,
Aaron.

Hi Everyone,

I've installed a few bits of new software on the ol' server, including
a PHP-based forum, users' gallery and wiki.

If you're interested, check out the news announcement for more details:

http://bundysoft.com/L3DT/news/2005.htm#Nov23

The specific links are:

forum: http://bundysoft.com/phpBB2/
gallery: http://bundysoft.com/coppermine/
wiki: http://bundysoft.com/dokuwiki/

They are still very-much a work in progress, with some rough edges,
but I'd like to give them a good thrashing by the user community to
get some usability feedback and advice. So please, start messing
around with this stuff and tell me what you think.

Cheers,
Aaron.

-yeah I realise the overlay was put in pretty speedily.
OK, can't say fairer than that :)
Cheers.

monks

--- In L3DT_users_group@yahoogroups.com, Aaron Torpy
<aaron_torpy@y...> wrote:
>
> Hello,
>
> > I don't know for sure but the image overlay may be
> slowing
> > down the paint tool process. I think the redraw is
> slower with > the overlay.
>
> Yup, it should slow things down. The overlay code is
> mixing the image-buffers each time the screen is
> drawn, which is not ideal but it was rather easier to
> code than the alternatives. I can look at optimising
> this some time in the future.
>
> > I found that one had to individually click the DM
> pixels
> > because the refresh (or whatever) was too slow to
> keep up even
> > with moderate painting speed.
>
> Yes, I noticed that problem too. As I said, this
> feature is really just a beta, and there are a number
> of optimisations that could be done (given sufficient
> time).
>
> > It *might* be necessary to go to 32 x 32 but I don't
> think any
> > higher than that (out of necessity anyway)
>
> Yeah, I can see that being useful. User-defined
> build-lists would cover this, and are on the to-do
> list somewhere.
>
> > It would be EXTREMELY useful to be able to have the
> last
> > generated contour map (perhaps even just the contour
> lines if
> > possible) from the heightfield operation as an
> additional layer
> > to the DM overlay.
>
> I'm sure that's possible. I'll have a bit of a thinker
> about the best way to implement it.
>
> > Would it be possible to have a selective update (or
> do you
> > already do that ?)- ie only those DM px that were
> changed would
> > be used in the next heightmap operation ? just a
> thought- I
> > don't know what code implications that has. This
> would in
> > theory speed up the heightmap operation.
>
> I would like to do this, but the 'code implications'
> are not nice. This is more of a long-term goal.
>
> > A hotkey for the heightmap operation would be
> > another help.
>
> Sure. I think that's on the to-do list.
>
> > An (optional) altitude display on the pencil cursor
> > itself might be handy as in Wilbur. So that all the
> info was at
> > the pencil point (ie pixel to be set and its current
> height).
>
> Yes, that's definitely on the to-do list.
>
> > A shift click between two points would be handy.
> Vectors,
> > polylines and polygons would be heaven :)
>
> Also on the to-do list.
>
> > Would it be possible to implement a 3D preview, or
> > realtime 3D editing...
>
> Ditto. This is one of my big-ticket goals.
>
> Anyway, thanks a bunch for the feedback and
> suggestions. I would hope that, in the fullness of
> time, they will all be implemented.
>
> Cheers,
> Aaron.
>
> --- monkschain <lingardc@g...> wrote:
>
> > Hello, I've had a chance to look at the image
> > overlay and basically
> > it seems fine in terms of visual use. It's a great
> > help. ;)
> >  There are a couple of minor artifacts in the image-
> > don't know
> > what's causing that, but they haven't affected what
> > I was doing in
> > any way. I don't know for sure but the image overlay
> > may be slowing
> > down the paint tool process. I think the redraw is
> > slower with the
> > overlay.
> >  I've had a crack at reproducing a tile of the
> > ME-DEM topo. This
> > would be typical of the minimum tile size a user
> > would be working on,
> > that is a 1000 px square. (this would exist a 100 px
> > square in the
> > database before being upsized by the user to 1K
> > before editing and
> > resubmitting- in the old proposed setup anyway). I
> > used 16 x 16 DM
> > map with 20m res- ie 20 KM on a side. L3D uses a
> > 1024 tile but we
> > would be presumably importing into L3D a 1K square
> > tile from the base
> > DEM (?). The image overlay was a 1K square jpeg
> > overlay covering 20Km
> > (again this would exist as the corresponding 100 px
> > aquare topo tile
> > before users would upsize it as I did).
> >  It was a basic exercise in transcribing what was in
> > the topo. I'm
> > pleased to say that I got some pretty good results-
> > even at that low
> > DM resolution- though it did take me some time to
> > get there.:).
> > The topo contained simple mountains with ridges and
> > is probably
> > representative of the simple end of the topo's
> > visual complexity
> > scale. It *might* be necessary to go to 32 x 32 but
> > I don't think any
> > higher than that (out of necessity anyway). Having
> > said that, more
> > control is always better.
> >  The method I used was to build up the DM pixels
> > using the altitude,
> > almost exclusively in 200m increments- painterly
> > fashion. The max
> > heights of the terrain I did were reasonable 'real
> > world' and fairly
> > accurate to the topo. I used the peak, fractal
> > roughness and
> > terracing settings from the Fjord tutorial (great by
> > the way). Ditto
> > for the approach with global and targetted erosion
> > (same numbers). It
> > was noob stuff.
> >  I've satisfied myself that it is totally feasable
> > to use L3D as of
> > now for ME-DEM, now that the image overlay is in
> > place. :)
> >
> >
> >  I've got a lot of ideas/ feature suggestions:
> >
> > (Please accept any apologies that might be due for a
> > total noob
> > making such outlandish feature requests :D)
> >
> >  It would be EXTREMELY useful to be able to have the
> > last generated
> > contour map (perhaps even just the contour lines if
> > possible) from
> > the heightfield operation as an additional layer to
> > the DM overlay.
> > Using this painterly method I found myself going
> > back and forth
> > between the DM and HM countless times. This was a
> > direct consequence
> > of the painterly method and the approach we are
> > using- we have less
> > free rein as we are more or less transcribing from a
> > topo, thus  a
> > lot of control over the terrain is needed.
> >  Once I performed the height operation I was having
> > to visually
> > eyeball and commit to memory areas from the
> > contoured heightmap map
> > that I needed to alter for when I got back into the
> > DM map view. If
> > this was implemented it would be useful to have an
> > on/off toggle and
> > independent transparency for any image layers. The
> > coord readout in
> > the heightmap view was of no use here because the DM
> > map coord
> > readout is in DM pixels. It would help if the two
> > could coincide in
> > some way but the overlay would be VASTLY better. ;)
> >
> >  Because I was going constantly back and forth
> > between the design map
> > and heightmap operation would it be possible to have
> > a selective
> > update (or do you already do that ?)- ie only those
> > DM px that were
> > changed would be used in the next heightmap
> > operation ? just a
> > thought- I don't know what code implications that
> > has. This would in
> > theory speed up the heightmap operation.
> >
> > A hotkey for the heightmap operation would be
> > another help.
> >
> >  An (optional) altitude display on the pencil cursor
> > itself might be
> > handy as in Wilbur. So that all the info was at the
> > pencil point (ie
> > pixel to be set and its current height). I didn't
> > find the colour
> > scheme I was using that helpful. I didn't really
> > have a look into the
> > options (I was using classic) but I think this would
> > probably be
> > unchanged for the others because of the precise(r)
> > nature of what we
> > are doing.
> >
> >  Would it be possible to implement a 3D preview, or
> > realtime 3D
> > editing, but using only the Design map pixels down
> > the line. It
> > wouldn't be necessary to have a realtime interaction
> > with the
> > heightmap post heightmap operation. I imagine that
> > this would be easy
> > on the system and a more palatable code pill to
> > swallow. :) The 3D
> > view would consist of the DM pixels but their faces
> > interpolated to
> > smooth them. Any image overlays would function as
> > above (draped over
> > it as a texture say) with individual layer
> > toggles/transparencies.
> >
> >  I found that one had to individually click the DM
> > pixels because the
> > refresh (or whatever) was too slow to keep up even
> > with moderate
> > painting speed. This is the slowing down I
> > mentioned, possibly
> > associated with the image overlay. For a 16 sq map
> > this wasn't too
> > much of a problem, but is for higher res DMs. A
> > shift click between
> > two points would be handy. Vectors, polylines and
> > polygons would be
> > heaven :) [I have a P4, 2 GB RAM and 256 RAM vid
> > card]
> >
> >  I didn't use any of the special overlays so some of
> > the stuff above
> > may be addressed with that. It would great to be
> > able to have a
> > combination of stamp-like tools and the painterly
> > option. I only
> > briefly looked into the mountains overlay yesterday.
> > From that
> > admittedly cursory look I have found so far that I
> > prefer the
> > painterly approach but can see massive advantages of
> > cookie cutter
> > like tools.
> >
> >
> >  I'll post the results on ME-DEM and send you two
> > fellas (Aaron and
> > Oshyan) a couple of pics if you like ;)
> >
> > Cheers,
> > monks
> >
> >
> > --- In L3DT_users_group@yahoogroups.com,
> > "monkschain" <lingardc@g...>
> > wrote:
> > >
> > >  Awesome, thanks for that Aaron. I've downloaded
> > it and will give
> > it
> > > a whirl first chance I get.
> > >
> > > monks
> > >
> > > --- In L3DT_users_group@yahoogroups.com, Aaron
> > Torpy
> > > <aaron_torpy@y...> wrote:
> >
> === message truncated ===
>

Hi Rofar, I don't know if you know of the ME-DEM project. Here's a
link:
http://me-dem.ashundar.com/index.php

  You're welcome to register and get involved. :)

  I had a quick look around the PnP Terrain Creator site (I'd not come
across it before) and it looked pretty promising, especially the
multi user 'server-client' support promised for next year and the
tile abilty.

monks



--- In L3DT_users_group@yahoogroups.com, Rofar <rofar@c...> wrote:
>
> My head is spinning trying to follow all this discussion regarding
> Middle Earth DEM.  It's quite interesting and a lot of good
discussion
> going on.  I have seen Wilbur and Leveller mentioned.  I think I
have a
> copy of Wilbur that I d/l some time back but I don't believe I am
> familiar with Leveller.  Have you guys taken a look at PnP Terrain
> Creator?  That tool has a very flexible SDK for plugin creation
(import,
> export, and editing plugins).  As a matter of fact, one of the
import
> plugins that come standard now is one I developed and gave them
that
> imports terrains from L3DT HFF files.
>
> >
> >
> >
> > SPONSORED LINKS
> > Backup software program
> > <http://groups.yahoo.com/gads?
t=ms&k=Backup+software+program&w1=Backup+software+program&w2=Email+sof
tware+program&w3=Audit+program+software&w4=Wedding+program+software&w5
=Maintenance+program+software&w6=Medical+software+program&c=6&s=179&.s
ig=ksxVLoOG1aCxi8xObq5vpg>
> >  Email software program
> > <http://groups.yahoo.com/gads?
t=ms&k=Email+software+program&w1=Backup+software+program&w2=Email+soft
ware+program&w3=Audit+program+software&w4=Wedding+program+software&w5=
Maintenance+program+software&w6=Medical+software+program&c=6&s=179&.si
g=zPJyFcKyh4mqPWyF3FU24Q>
> >  Audit program software
> > <http://groups.yahoo.com/gads?
t=ms&k=Audit+program+software&w1=Backup+software+program&w2=Email+soft
ware+program&w3=Audit+program+software&w4=Wedding+program+software&w5=
Maintenance+program+software&w6=Medical+software+program&c=6&s=179&.si
g=imI-tD8tsyvtvmaT-XXxyw>
> >
> > Wedding program software
> > <http://groups.yahoo.com/gads?
t=ms&k=Wedding+program+software&w1=Backup+software+program&w2=Email+so
ftware+program&w3=Audit+program+software&w4=Wedding+program+software&w
5=Maintenance+program+software&w6=Medical+software+program&c=6&s=179&.
sig=JONMnKutYp4v72JsNxrH_w>
> >  Maintenance program software
> > <http://groups.yahoo.com/gads?
t=ms&k=Maintenance+program+software&w1=Backup+software+program&w2=Emai
l+software+program&w3=Audit+program+software&w4=Wedding+program+softwa
re&w5=Maintenance+program+software&w6=Medical+software+program&c=6&s=1
79&.sig=eLMw918O0s2O4atmCj-FaQ>
> >  Medical software program
> > <http://groups.yahoo.com/gads?
t=ms&k=Medical+software+program&w1=Backup+software+program&w2=Email+so
ftware+program&w3=Audit+program+software&w4=Wedding+program+software&w
5=Maintenance+program+software&w6=Medical+software+program&c=6&s=179&.
sig=UtZNLvdWTPBgEkTZAVvcjg>
> >
> >
> >
> > ------------------------------------------------------------------
------
> > YAHOO! GROUPS LINKS
> >
> >     *  Visit your group "L3DT_users_group
> >       <http://groups.yahoo.com/group/L3DT_users_group>" on the
web.
> >
> >     *  To unsubscribe from this group, send an email to:
> >        L3DT_users_group-unsubscribe@yahoogroups.com
> >       <mailto:L3DT_users_group-unsubscribe@yahoogroups.com?
subject=Unsubscribe>
> >
> >     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >       Service <http://docs.yahoo.com/info/terms/>.
> >
> >
> > ------------------------------------------------------------------
------
> >
>

Hello,

> I don't know for sure but the image overlay may be
slowing
> down the paint tool process. I think the redraw is
slower with > the overlay.

Yup, it should slow things down. The overlay code is
mixing the image-buffers each time the screen is
drawn, which is not ideal but it was rather easier to
code than the alternatives. I can look at optimising
this some time in the future.

> I found that one had to individually click the DM
pixels
> because the refresh (or whatever) was too slow to
keep up even
> with moderate painting speed.

Yes, I noticed that problem too. As I said, this
feature is really just a beta, and there are a number
of optimisations that could be done (given sufficient
time).

> It *might* be necessary to go to 32 x 32 but I don't
think any
> higher than that (out of necessity anyway)

Yeah, I can see that being useful. User-defined
build-lists would cover this, and are on the to-do
list somewhere.

> It would be EXTREMELY useful to be able to have the
last
> generated contour map (perhaps even just the contour
lines if
> possible) from the heightfield operation as an
additional layer
> to the DM overlay.

I'm sure that's possible. I'll have a bit of a thinker
about the best way to implement it.

> Would it be possible to have a selective update (or
do you
> already do that ?)- ie only those DM px that were
changed would
> be used in the next heightmap operation ? just a
thought- I
> don't know what code implications that has. This
would in
> theory speed up the heightmap operation.

I would like to do this, but the 'code implications'
are not nice. This is more of a long-term goal.

> A hotkey for the heightmap operation would be
> another help.

Sure. I think that's on the to-do list.

> An (optional) altitude display on the pencil cursor
> itself might be handy as in Wilbur. So that all the
info was at
> the pencil point (ie pixel to be set and its current
height).

Yes, that's definitely on the to-do list.

> A shift click between two points would be handy.
Vectors,
> polylines and polygons would be heaven :)

Also on the to-do list.

> Would it be possible to implement a 3D preview, or
> realtime 3D editing...

Ditto. This is one of my big-ticket goals.

Anyway, thanks a bunch for the feedback and
suggestions. I would hope that, in the fullness of
time, they will all be implemented.

Cheers,
Aaron.

--- monkschain <lingardc@...> wrote:

> Hello, I've had a chance to look at the image
> overlay and basically
> it seems fine in terms of visual use. It's a great
> help. ;)
>  There are a couple of minor artifacts in the image-
> don't know
> what's causing that, but they haven't affected what
> I was doing in
> any way. I don't know for sure but the image overlay
> may be slowing
> down the paint tool process. I think the redraw is
> slower with the
> overlay.
>  I've had a crack at reproducing a tile of the
> ME-DEM topo. This
> would be typical of the minimum tile size a user
> would be working on,
> that is a 1000 px square. (this would exist a 100 px
> square in the
> database before being upsized by the user to 1K
> before editing and
> resubmitting- in the old proposed setup anyway). I
> used 16 x 16 DM
> map with 20m res- ie 20 KM on a side. L3D uses a
> 1024 tile but we
> would be presumably importing into L3D a 1K square
> tile from the base
> DEM (?). The image overlay was a 1K square jpeg
> overlay covering 20Km
> (again this would exist as the corresponding 100 px
> aquare topo tile
> before users would upsize it as I did).
>  It was a basic exercise in transcribing what was in
> the topo. I'm
> pleased to say that I got some pretty good results-
> even at that low
> DM resolution- though it did take me some time to
> get there.:).
> The topo contained simple mountains with ridges and
> is probably
> representative of the simple end of the topo's
> visual complexity
> scale. It *might* be necessary to go to 32 x 32 but
> I don't think any
> higher than that (out of necessity anyway). Having
> said that, more
> control is always better.
>  The method I used was to build up the DM pixels
> using the altitude,
> almost exclusively in 200m increments- painterly
> fashion. The max
> heights of the terrain I did were reasonable 'real
> world' and fairly
> accurate to the topo. I used the peak, fractal
> roughness and
> terracing settings from the Fjord tutorial (great by
> the way). Ditto
> for the approach with global and targetted erosion
> (same numbers). It
> was noob stuff.
>  I've satisfied myself that it is totally feasable
> to use L3D as of
> now for ME-DEM, now that the image overlay is in
> place. :)
>
>
>  I've got a lot of ideas/ feature suggestions:
>
> (Please accept any apologies that might be due for a
> total noob
> making such outlandish feature requests :D)
>
>  It would be EXTREMELY useful to be able to have the
> last generated
> contour map (perhaps even just the contour lines if
> possible) from
> the heightfield operation as an additional layer to
> the DM overlay.
> Using this painterly method I found myself going
> back and forth
> between the DM and HM countless times. This was a
> direct consequence
> of the painterly method and the approach we are
> using- we have less
> free rein as we are more or less transcribing from a
> topo, thus  a
> lot of control over the terrain is needed.
>  Once I performed the height operation I was having
> to visually
> eyeball and commit to memory areas from the
> contoured heightmap map
> that I needed to alter for when I got back into the
> DM map view. If
> this was implemented it would be useful to have an
> on/off toggle and
> independent transparency for any image layers. The
> coord readout in
> the heightmap view was of no use here because the DM
> map coord
> readout is in DM pixels. It would help if the two
> could coincide in
> some way but the overlay would be VASTLY better. ;)
>
>  Because I was going constantly back and forth
> between the design map
> and heightmap operation would it be possible to have
> a selective
> update (or do you already do that ?)- ie only those
> DM px that were
> changed would be used in the next heightmap
> operation ? just a
> thought- I don't know what code implications that
> has. This would in
> theory speed up the heightmap operation.
>
> A hotkey for the heightmap operation would be
> another help.
>
>  An (optional) altitude display on the pencil cursor
> itself might be
> handy as in Wilbur. So that all the info was at the
> pencil point (ie
> pixel to be set and its current height). I didn't
> find the colour
> scheme I was using that helpful. I didn't really
> have a look into the
> options (I was using classic) but I think this would
> probably be
> unchanged for the others because of the precise(r)
> nature of what we
> are doing.
>
>  Would it be possible to implement a 3D preview, or
> realtime 3D
> editing, but using only the Design map pixels down
> the line. It
> wouldn't be necessary to have a realtime interaction
> with the
> heightmap post heightmap operation. I imagine that
> this would be easy
> on the system and a more palatable code pill to
> swallow. :) The 3D
> view would consist of the DM pixels but their faces
> interpolated to
> smooth them. Any image overlays would function as
> above (draped over
> it as a texture say) with individual layer
> toggles/transparencies.
>
>  I found that one had to individually click the DM
> pixels because the
> refresh (or whatever) was too slow to keep up even
> with moderate
> painting speed. This is the slowing down I
> mentioned, possibly
> associated with the image overlay. For a 16 sq map
> this wasn't too
> much of a problem, but is for higher res DMs. A
> shift click between
> two points would be handy. Vectors, polylines and
> polygons would be
> heaven :) [I have a P4, 2 GB RAM and 256 RAM vid
> card]
>
>  I didn't use any of the special overlays so some of
> the stuff above
> may be addressed with that. It would great to be
> able to have a
> combination of stamp-like tools and the painterly
> option. I only
> briefly looked into the mountains overlay yesterday.
> From that
> admittedly cursory look I have found so far that I
> prefer the
> painterly approach but can see massive advantages of
> cookie cutter
> like tools.
>
>
>  I'll post the results on ME-DEM and send you two
> fellas (Aaron and
> Oshyan) a couple of pics if you like ;)
>
> Cheers,
> monks
>
>
> --- In L3DT_users_group@yahoogroups.com,
> "monkschain" <lingardc@g...>
> wrote:
> >
> >  Awesome, thanks for that Aaron. I've downloaded
> it and will give
> it
> > a whirl first chance I get.
> >
> > monks
> >
> > --- In L3DT_users_group@yahoogroups.com, Aaron
> Torpy
> > <aaron_torpy@y...> wrote:
>
=== message truncated ===

Hello, I've had a chance to look at the image overlay and basically
it seems fine in terms of visual use. It's a great help. ;)
  There are a couple of minor artifacts in the image- don't know
what's causing that, but they haven't affected what I was doing in
any way. I don't know for sure but the image overlay may be slowing
down the paint tool process. I think the redraw is slower with the
overlay.
  I've had a crack at reproducing a tile of the ME-DEM topo. This
would be typical of the minimum tile size a user would be working on,
that is a 1000 px square. (this would exist a 100 px square in the
database before being upsized by the user to 1K before editing and
resubmitting- in the old proposed setup anyway). I used 16 x 16 DM
map with 20m res- ie 20 KM on a side. L3D uses a 1024 tile but we
would be presumably importing into L3D a 1K square tile from the base
DEM (?). The image overlay was a 1K square jpeg overlay covering 20Km
(again this would exist as the corresponding 100 px aquare topo tile
before users would upsize it as I did).
  It was a basic exercise in transcribing what was in the topo. I'm
pleased to say that I got some pretty good results- even at that low
DM resolution- though it did take me some time to get there.:).
The topo contained simple mountains with ridges and is probably
representative of the simple end of the topo's visual complexity
scale. It *might* be necessary to go to 32 x 32 but I don't think any
higher than that (out of necessity anyway). Having said that, more
control is always better.
  The method I used was to build up the DM pixels using the altitude,
almost exclusively in 200m increments- painterly fashion. The max
heights of the terrain I did were reasonable 'real world' and fairly
accurate to the topo. I used the peak, fractal  roughness and
terracing settings from the Fjord tutorial (great by the way). Ditto
for the approach with global and targetted erosion (same numbers). It
was noob stuff.
  I've satisfied myself that it is totally feasable to use L3D as of
now for ME-DEM, now that the image overlay is in place. :)


  I've got a lot of ideas/ feature suggestions:

(Please accept any apologies that might be due for a total noob
making such outlandish feature requests :D)

  It would be EXTREMELY useful to be able to have the last generated
contour map (perhaps even just the contour lines if possible) from
the heightfield operation as an additional layer to the DM overlay.
Using this painterly method I found myself going back and forth
between the DM and HM countless times. This was a direct consequence
of the painterly method and the approach we are using- we have less
free rein as we are more or less transcribing from a topo, thus  a
lot of control over the terrain is needed.
  Once I performed the height operation I was having to visually
eyeball and commit to memory areas from the contoured heightmap map
that I needed to alter for when I got back into the DM map view. If
this was implemented it would be useful to have an on/off toggle and
independent transparency for any image layers. The coord readout in
the heightmap view was of no use here because the DM map coord
readout is in DM pixels. It would help if the two could coincide in
some way but the overlay would be VASTLY better. ;)

  Because I was going constantly back and forth between the design map
and heightmap operation would it be possible to have a selective
update (or do you already do that ?)- ie only those DM px that were
changed would be used in the next heightmap operation ? just a
thought- I don't know what code implications that has. This would in
theory speed up the heightmap operation.

A hotkey for the heightmap operation would be another help.

  An (optional) altitude display on the pencil cursor itself might be
handy as in Wilbur. So that all the info was at the pencil point (ie
pixel to be set and its current height). I didn't find the colour
scheme I was using that helpful. I didn't really have a look into the
options (I was using classic) but I think this would probably be
unchanged for the others because of the precise(r) nature of what we
are doing.

  Would it be possible to implement a 3D preview, or realtime 3D
editing, but using only the Design map pixels down the line. It
wouldn't be necessary to have a realtime interaction with the
heightmap post heightmap operation. I imagine that this would be easy
on the system and a more palatable code pill to swallow. :) The 3D
view would consist of the DM pixels but their faces interpolated to
smooth them. Any image overlays would function as above (draped over
it as a texture say) with individual layer toggles/transparencies.

  I found that one had to individually click the DM pixels because the
refresh (or whatever) was too slow to keep up even with moderate
painting speed. This is the slowing down I mentioned, possibly
associated with the image overlay. For a 16 sq map this wasn't too
much of a problem, but is for higher res DMs. A shift click between
two points would be handy. Vectors, polylines and polygons would be
heaven :) [I have a P4, 2 GB RAM and 256 RAM vid card]

  I didn't use any of the special overlays so some of the stuff above
may be addressed with that. It would great to be able to have a
combination of stamp-like tools and the painterly option. I only
briefly looked into the mountains overlay yesterday. From that
admittedly cursory look I have found so far that I prefer the
painterly approach but can see massive advantages of cookie cutter
like tools.


  I'll post the results on ME-DEM and send you two fellas (Aaron and
Oshyan) a couple of pics if you like ;)

Cheers,
monks


--- In L3DT_users_group@yahoogroups.com, "monkschain" <lingardc@g...>
wrote:
>
>  Awesome, thanks for that Aaron. I've downloaded it and will give
it
> a whirl first chance I get.
>
> monks
>
> --- In L3DT_users_group@yahoogroups.com, Aaron Torpy
> <aaron_torpy@y...> wrote:
> >
> > Hello Monkschain,
> >
> > > The most useful short term addition would be the
> > image overlay
> > > (with transparency) so that terrain could be
> > 'defined' from a
> > > topo reference. Like tracing over it. I see that
> > that is
> > > on the dev roadmap so that's great.
> >
> > Okay, I've uploaded an update of L3DT Pro that
> > includes a rough first-attempt at the image overlay
> > feature. I'll send you a direct e-mail with an
> > activation key for the beta-release and instructions
> > on how to download the Pro version.
> >
> > Anyhow, assuming everything else works OK, you can
> > load the overlay image (bmp, jpg or png only, at the
> > moment) using the 'view->overlay image...' menu
> > option. This image will then be blended/stretched over
> > the top of any map that you create/view/edit. You can
> > also set transparency in the control dialog.
> >
> > This is really quite rough, but I thought it might be
> > good to get your feedback before I try to smooth the
> > edges.
> >
> > Cheers,
> > Aaron.
> >
> > PS: I should hopefully have time reply to these posts
> > more thoroughly on the weekend.
> >
> > --- monkschain <lingardc@g...> wrote:
> >
> > > Hello, monks here from ME-DEM. It's great to see
> > > that our lil' baby
> > > elephant still has a caring family- (trumpets
> > > appreciatively) hehe.
> > >  You're right about the l...o...n...g term time
> > > frame- we'll all be
> > > long in the tooth ere the task is done !
> > >  I just wanted to pipe in with a couple of details
> > > if that's OK Aaron.
> > >  The most useful short term addition would be the
> > > image overlay (with
> > > transparency) so that terrain could be 'defined'
> > > from a topo
> > > reference. Like tracing over it. I see that that is
> > > on the dev
> > > roadmap so that's great. With this we might be able
> > > to go ahead with
> > > using L3D straight away (without all the other cool
> > > stuff mentioned
> > > of course).
> > >  The abilty to load existing terrain and create in
> > > this manner in
> > > *replace mode*. So one would load up a low res dem
> > > with the
> > > corresponding image overlay (topo map) and then use
> > > the elevations of
> > > that low res dem for reference (one would need some
> > > kind of cursor
> > > feedback for height or something) along with the
> > > topo overlay. So one
> > > would know, here is a mountain and this is it's
> > > approx height. Define
> > > it with the L3D tools and bingo.
> > >  The ability to load up tile sets that are multiples
> > > of x Km (on the
> > > first pass each tile will be 1K px on a side at 1
> > > px= 20m....20 Km on
> > > a side, on the second pass (down the line) each tile
> > > with a factor of
> > > 10 larger scale- that is, each tile being 1K px
> > > still, but at 2m res,
> > > so 2 Km on a side). This would be really useful as
> > > users could work
> > > on larger areas (which is probably the preferred
> > > approach).
> > >  ps Joe Slayton of Wilbur (he's helped us out
> > > already). ;)
> > >  ps I'm still convinced that L3D could fundamentally
> > > change the way
> > > people build terrain models.
> > >
> > > monks
> > >
> > >
> > >
> > >
> >
>

Hello,

> Ah, sounds delicious. The only issue would be if the
> tile was not local it would have to be downloaded,
causing an
> additional delay in the overall process. But at
least it would
> be automatic.

There would also be the option to pre-load the tiles
you're going to use. The L3DT subsystems have this
capacity, but I've not yet created a user-interface
for it, since there isn't much need at the moment.
However, when maps are loaded over the network this
would be essential, so it's on the to-do list.

> WM's erosion can be pretty extreme though. <G>

Agreed.

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 10:12 PM
> > To: L3DT_users_group@yahoogroups.com
> > Subject: RE: [L3DT users' group] SDK progress
> report
> >
> > > 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!
>
> Ah, sounds delicious. The only issue would be if the
> tile was not local it
> would have to be downloaded, causing an additional
> delay in the overall
> process. But at least it would be automatic.
>
> > > 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.
>
> Ah, no there hasn't been an update since then. It's
> probably still an issue
> in that case. WM's erosion can be pretty extreme
> though. <G>
>
> - Oshyan
>
>

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

Ah, sounds delicious. The only issue would be if the tile was not local it
would have to be downloaded, causing an additional delay in the overall
process. But at least it would be automatic.

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

Ah, no there hasn't been an update since then. It's probably still an issue
in that case. WM's erosion can be pretty extreme though. <G>

- Oshyan

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

_____

From: L3DT_users_group@yahoogroups.com
[mailto:L3DT_users_group@yahoogroups.com] On Behalf Of Oshyan Greene
Sent: Friday, November 18, 2005 4:32 PM
To: L3DT_users_group@yahoogroups.com
Subject: RE: [L3DT users' group] SDK progress report


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



I've been saying this for several years now. Being half electronic, half
mechanical, and depending on magnetic media, hard drives are the least
reliable piece (except fans) in a computer. Yet it is the only device that a
simple swap cannot instantly restore the system to its state before the
failure. At best you have to restore a backup (time consuming) or at worst,
you've lost everything.

They're faster today, and exponentially larger capacity, but the technology
of a drive today is little different than one made 20 years ago. Why haven't
they developed something solid state yet? (Rhetorical question, I know,
flash ram is expensive, etc.)

That's all for my somewhat off topic rant.



Michael





[Non-text portions of this message have been removed]

My head is spinning trying to follow all this discussion regarding
Middle Earth DEM.  It's quite interesting and a lot of good discussion
going on.  I have seen Wilbur and Leveller mentioned.  I think I have a
copy of Wilbur that I d/l some time back but I don't believe I am
familiar with Leveller.  Have you guys taken a look at PnP Terrain
Creator?  That tool has a very flexible SDK for plugin creation (import,
export, and editing plugins).  As a matter of fact, one of the import
plugins that come standard now is one I developed and gave them that
imports terrains from L3DT HFF files.

>
>
>
> SPONSORED LINKS
> Backup software program
>
<http://groups.yahoo.com/gads?t=ms&k=Backup+software+program&w1=Backup+software+\
program&w2=Email+software+program&w3=Audit+program+software&w4=Wedding+program+s\
oftware&w5=Maintenance+program+software&w6=Medical+software+program&c=6&s=179&.s\
ig=ksxVLoOG1aCxi8xObq5vpg>
>  Email software program
>
<http://groups.yahoo.com/gads?t=ms&k=Email+software+program&w1=Backup+software+p\
rogram&w2=Email+software+program&w3=Audit+program+software&w4=Wedding+program+so\
ftware&w5=Maintenance+program+software&w6=Medical+software+program&c=6&s=179&.si\
g=zPJyFcKyh4mqPWyF3FU24Q>
>  Audit program software
>
<http://groups.yahoo.com/gads?t=ms&k=Audit+program+software&w1=Backup+software+p\
rogram&w2=Email+software+program&w3=Audit+program+software&w4=Wedding+program+so\
ftware&w5=Maintenance+program+software&w6=Medical+software+program&c=6&s=179&.si\
g=imI-tD8tsyvtvmaT-XXxyw>
>
> Wedding program software
>
<http://groups.yahoo.com/gads?t=ms&k=Wedding+program+software&w1=Backup+software\
+program&w2=Email+software+program&w3=Audit+program+software&w4=Wedding+program+\
software&w5=Maintenance+program+software&w6=Medical+software+program&c=6&s=179&.\
sig=JONMnKutYp4v72JsNxrH_w>
>  Maintenance program software
>
<http://groups.yahoo.com/gads?t=ms&k=Maintenance+program+software&w1=Backup+soft\
ware+program&w2=Email+software+program&w3=Audit+program+software&w4=Wedding+prog\
ram+software&w5=Maintenance+program+software&w6=Medical+software+program&c=6&s=1\
79&.sig=eLMw918O0s2O4atmCj-FaQ>
>  Medical software program
>
<http://groups.yahoo.com/gads?t=ms&k=Medical+software+program&w1=Backup+software\
+program&w2=Email+software+program&w3=Audit+program+software&w4=Wedding+program+\
software&w5=Maintenance+program+software&w6=Medical+software+program&c=6&s=179&.\
sig=UtZNLvdWTPBgEkTZAVvcjg>
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "L3DT_users_group
>       <http://groups.yahoo.com/group/L3DT_users_group>" on the web.
>
>     *  To unsubscribe from this group, send an email to:
>        L3DT_users_group-unsubscribe@yahoogroups.com
>      
<mailto:L3DT_users_group-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

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

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

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

Hello,

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

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

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

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.

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

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

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

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

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.

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: Tuesday, November 15, 2005 11:03 PM
> > To: L3DT_users_group@yahoogroups.com
> > Subject: RE: [L3DT users' group] SDK progress
> report
> >
>  > Sounds like the network stuff might be very handy
> > > for the Middle Earth DEM Project.
> >
> > I hope so...ME-DEM was one of the projects I had
> in
> > mind when I proposed the network stuff
>
> Yay! <G>
>
> > (the other main
> > one being Beowulf clustering of map calculations,
> for
> > huge maps in a hurry, and for the 'cool' factor).
>
> Yeah, that would be pretty cool. Then all you need
> is a program that can
> load those monster data sets. ;)
>
> > For the benefit of the group-members not familiar
> with
> > ME-DEM (http://me-dem.ashundar.com), it is an
> > ambitious project to create a digital elevation
> map of
> > 'Middle Earth', from J.R.R. Tolkien's Lord of The
> > Rings, et. al. At my last reading, the goal is to
> make
> > a 20k x 20k pixel final heightmap.
>
> 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. So once
> we have the 20k map, derived from hand-drawn maps of
> various sources (and
> covering only a portion of Middle Earth mind you -
> about 1/4 I think), we
> divide up into 100x100 tiles (I think - or maybe
> 200x200) and scale by 10
> times to get 1000x1000 pixel terrains. Those
> terrains are then refined by
> hand to get more realistic detail at 20m/pixel. Then
> we divide again to get
> the 10m (or better) data and refine again by hand. I
> forget the actual
> numbers but we'll actually end up with literally
> 10's of thousands of
> terrain tiles of 1000x1000 or something. It's pretty
> scary. And that's just
> for 1/4 (or less) of the whole world. :p
>
> > Since the
> > terrain-shaping has to be (at-least partially)
> manual
> > to get the right result, the project will require
> an
> > awful-lot of person-hours to build a map that
> large.
>
> Yeah, multiply "awful-lot" by 1000 given the above.
> <G>
>
> > One of the ideas that's been proposed to help-out
> is
> > the creation of a distributed server/client system
> so
> > that individual contributors can chip away at
> small
> > areas and send back the results without causing
> nasty
> > duplication or edge mismatch problems.
>
> Indeed. Another thing that would help is if we could
> load up our base maps
> in L3DT and use an extension of the current terrain
> definition system to add
> semi-directed procedural detail to our base
> terrains. We're getting closer
> to that now as L3DT gains capability.
>
> > > If we could utilize this to setup a master file
> list
> > on a
> > > server and have a check-in/check-out system,
> simple
> > map-based
> > > GUI tile selection with automated tile
> positioning
> > after edit
> > > and upon export, and perhaps even some way to
> match
> > up
> > > tile edges... well, it'd help us out a
> helluvalot.
> >
> > Hmm...I think I can see how all that would work.
> The
> > tile-edge matching could be tricky, but I guess we
> > could always forbid the editing of a 1px-thick
> border
> > of the downloaded area (if you want to edit those
> > bits, download the surrounding tiles too).
>
> That's kind of a non-ideal solution. It would
> probably result in pretty
> harsh lines if a larger area was not edited. And
> ultimately there will
> always be tile edges, whether you're working with 4
> 1000 pixel tiles (so the
> 4 interior seams are covered, but there are still 4
> edge seams), or a single
> 1000 pixel tile. A better solution is needed I
> think.
>
> > Then-again,
> > there's always the option of linear (or
> non-linear)
> > blending of overlapping tile edges. I'd rather
> avoid
> > this 2nd option, though, since it would add
> > complications to the server.
>
> It may be necessary given the above. 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.
>
> > As for the other stuff, it's conceptually pretty
> neat
> > 'n' tidy. All the network socket code would go
> into a
> > common plugin. The map server could be a
> stand-alone
> > program independent of L3DT, but using the SDK and
> > relevant plugins. The client-side would preferably
> be
> > a plugin for L3DT, but could initially be a
> > stand-alone job too (just to keep it simple).
> > Firewalls/NATs/etc can be worried about later.
>
> Good, good...
>
> > Anyhow, it's a good think that ME-DEM is a
> long-term
> > project, because there's an awful lot of coding to
> > make that stuff work.
>
> Yeah, loooong term. We're definitely on the long
> track. <G>
>
> > I'll start playing around with
> > it early/mid next year, hopefully once I've got a
> nice
> > beta-release of the SDK going.
>
> Sounds great to me! I'm looking forward to it. :)
>
> 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. Maybe
> even commercial endeavors.
> Or it can at least be made general enough that that
> would be the case. 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. ;)
>
> - Oshyan
>
>

Hello,

> Nice, but maybe update the news section at the old
web site
> with this information, since right now the last news
message
> there is still from September 6...

Uh, yeah. I would have liked to, but the old website
has been pulled-down by the host. Our contract was
terminated (on fairly short notice) on or around Sept
6, but they had continued to serve the content for a
couple of months (not quite sure why), although we was
locked-out of ftp, etc. Now that the new website is
up, I sent them a polite reminder to remove the old
stuff.

Anyhow, I apologise to the confusion and frustration
caused by obsolete websites, broken links, and such.
I'll do my best to ensure this shant happen again.

Regards,
Aaron.




--- qdad99 <q-dad@...> wrote:

> Nice, but maybe update the news section at the old
> web site with this
> information, since right now the last news message
> there is still from
>  September 6...
>
> --- In L3DT_users_group@yahoogroups.com, "Aaron
> Torpy"
> <aaron_torpy@y...> wrote:
> >
> > Hi Everyone,
> >
> > I'm very sorry that I've been so quiet of late. If
> I haven't replied
> > to your emails yet, I will try to do so in the
> next few hours.
> >
> > The big news is that L3DT has finally moved to a
> new web-host:
> > http://www.bundysoft.com/L3DT/
> >
> > If you've had trouble downloading the beta
> installer from Yahoo,
> > please try the following options:
> >
> > For a fresh install of L3DT 2.3b Professional:
> >
>
<http://www.bundysoft.com/L3DT/downloads/professional/L3DT
> Pro
> Setup.exe>
> >
> > To update an existing installation to L3DT 2.3b
> Professional:
> >
>
<http://www.bundysoft.com/L3DT/downloads/professional/L3DT
> Pro
> Update.exe>
> >
> > The `standard edition' of L3DT 2.3b has been
> released for public use,
> > but the `professional edition' is still in the
> beta-stage because
> > bug-reports are still trickling in.
> >
> > In other news, there has been quite a bit of
> progress made on the SDK.
> > I'll post another message shortly to explain
> what's happening and
> > what's planned.
> >
> > Cheers,
> > Aaron.
> >
>
>
>
>
>

Awesome, thanks for that Aaron. I've downloaded it and will give it
a whirl first chance I get.

monks

--- In L3DT_users_group@yahoogroups.com, Aaron Torpy
<aaron_torpy@y...> wrote:
>
> Hello Monkschain,
>
> > The most useful short term addition would be the
> image overlay
> > (with transparency) so that terrain could be
> 'defined' from a
> > topo reference. Like tracing over it. I see that
> that is
> > on the dev roadmap so that's great.
>
> Okay, I've uploaded an update of L3DT Pro that
> includes a rough first-attempt at the image overlay
> feature. I'll send you a direct e-mail with an
> activation key for the beta-release and instructions
> on how to download the Pro version.
>
> Anyhow, assuming everything else works OK, you can
> load the overlay image (bmp, jpg or png only, at the
> moment) using the 'view->overlay image...' menu
> option. This image will then be blended/stretched over
> the top of any map that you create/view/edit. You can
> also set transparency in the control dialog.
>
> This is really quite rough, but I thought it might be
> good to get your feedback before I try to smooth the
> edges.
>
> Cheers,
> Aaron.
>
> PS: I should hopefully have time reply to these posts
> more thoroughly on the weekend.
>
> --- monkschain <lingardc@g...> wrote:
>
> > Hello, monks here from ME-DEM. It's great to see
> > that our lil' baby
> > elephant still has a caring family- (trumpets
> > appreciatively) hehe.
> >  You're right about the l...o...n...g term time
> > frame- we'll all be
> > long in the tooth ere the task is done !
> >  I just wanted to pipe in with a couple of details
> > if that's OK Aaron.
> >  The most useful short term addition would be the
> > image overlay (with
> > transparency) so that terrain could be 'defined'
> > from a topo
> > reference. Like tracing over it. I see that that is
> > on the dev
> > roadmap so that's great. With this we might be able
> > to go ahead with
> > using L3D straight away (without all the other cool
> > stuff mentioned
> > of course).
> >  The abilty to load existing terrain and create in
> > this manner in
> > *replace mode*. So one would load up a low res dem
> > with the
> > corresponding image overlay (topo map) and then use
> > the elevations of
> > that low res dem for reference (one would need some
> > kind of cursor
> > feedback for height or something) along with the
> > topo overlay. So one
> > would know, here is a mountain and this is it's
> > approx height. Define
> > it with the L3D tools and bingo.
> >  The ability to load up tile sets that are multiples
> > of x Km (on the
> > first pass each tile will be 1K px on a side at 1
> > px= 20m....20 Km on
> > a side, on the second pass (down the line) each tile
> > with a factor of
> > 10 larger scale- that is, each tile being 1K px
> > still, but at 2m res,
> > so 2 Km on a side). This would be really useful as
> > users could work
> > on larger areas (which is probably the preferred
> > approach).
> >  ps Joe Slayton of Wilbur (he's helped us out
> > already). ;)
> >  ps I'm still convinced that L3D could fundamentally
> > change the way
> > people build terrain models.
> >
> > monks
> >
> >
> >
> >
>

Hi David,

Map stitching is on my to-do list and I will get to it
in turn. However, the writing of the SDK is taking
precedence over just about everything, so it's
unlikely that I'll have something to show until next
year.

> I see no reason that if you can create that vast
array of
> smaller tiles you can't bring them in together in
say, a series
> of rows and then write them out as a single giant
RAW file...
> read in a row of tiles, then then read across each
row of
> pixels in each file writing them out to a single RAW
file.

I might pencil that in as a little demo for the SDK,
either as a standalone app or as a plugin. It's fairly
straightforward, as you say.

Coincidentally, it is possible to export mosaic
terrain maps as one big RAW file using the standard
export wizard in L3DT, although you can't do it
row-by-row.

Cheers,
Aaron.


--- ddougher <ddougher@...> wrote:

> I have seen some discussion in the boards about what
> I think of as a
> terrain stitcher" that is, the ability to work with
> a set of small tiles
> which would then stitched together to make a larger
> terrain.  This might
> solve some of the issues with trying to get the
> detail into the game world
> we are seeking.  I am sure it creates a number of
> problems, not the least of
> which is getting the tiles to come together so that
> the seams are reasonably
> placed without giant tears.  It would be a useful
> feature.  I think it would
> fit into the overall desire to be able to create
> really large terrain and
> terrain textures.  So it is one thing that gets my
> vote -- along with being
> able to stitch together mosaic tiles and textures
> under export.  I see no
> reason that if you can create that vast array of
> smaller tiles you can't
> bring them in together in say, a series of rows and
> then write them out as a
> single giant RAW file...  read in a row of tiles,
> then then read across each
> row of pixels in each file writing them out to a
> single RAW file.  In the
> end, you would process through all the tiles row by
> row and end up with one
> single file.  Since RAW has not special embedded
> info anyway, you then just
> need to close the file when you have finished the
> last row of mosaic tiles.
> This could even be done as an external utility...
> Hmmm. Makes a note to look
> at the SDK when it is ready...
>
> <unsolicited plug to the guys who are looking at the
> project for recreating
> Middle Earth terrain>
>  We are working with the new Atlas terrain engine in
> GarageGames' new Torque
> Shader engine.  It is the first terrain engine that
> I have seen than can
> handle the size terrains that you are proposing to
> create at real world
> framerates.  It still has some issues with
> generating the terrain and the
> import.conversion of the texture to lay on the
> terrain, but overall it is a
> marvelous piece of work...  You might want to check
> it out.
>
>
>
> [Non-text portions of this message have been
> removed]
>
>

I have seen some discussion in the boards about what I think of as a
terrain stitcher" that is, the ability to work with a set of small tiles
which would then stitched together to make a larger terrain.  This might
solve some of the issues with trying to get the detail into the game world
we are seeking.  I am sure it creates a number of problems, not the least of
which is getting the tiles to come together so that the seams are reasonably
placed without giant tears.  It would be a useful feature.  I think it would
fit into the overall desire to be able to create really large terrain and
terrain textures.  So it is one thing that gets my vote -- along with being
able to stitch together mosaic tiles and textures under export.  I see no
reason that if you can create that vast array of smaller tiles you can't
bring them in together in say, a series of rows and then write them out as a
single giant RAW file...  read in a row of tiles, then then read across each
row of pixels in each file writing them out to a single RAW file.  In the
end, you would process through all the tiles row by row and end up with one
single file.  Since RAW has not special embedded info anyway, you then just
need to close the file when you have finished the last row of mosaic tiles.
This could even be done as an external utility... Hmmm. Makes a note to look
at the SDK when it is ready...

<unsolicited plug to the guys who are looking at the project for recreating
Middle Earth terrain>
  We are working with the new Atlas terrain engine in GarageGames' new Torque
Shader engine.  It is the first terrain engine that I have seen than can
handle the size terrains that you are proposing to create at real world
framerates.  It still has some issues with generating the terrain and the
import.conversion of the texture to lay on the terrain, but overall it is a
marvelous piece of work...  You might want to check it out.



[Non-text portions of this message have been removed]

Hello Monkschain,

> The most useful short term addition would be the
image overlay
> (with transparency) so that terrain could be
'defined' from a
> topo reference. Like tracing over it. I see that
that is
> on the dev roadmap so that's great.

Okay, I've uploaded an update of L3DT Pro that
includes a rough first-attempt at the image overlay
feature. I'll send you a direct e-mail with an
activation key for the beta-release and instructions
on how to download the Pro version.

Anyhow, assuming everything else works OK, you can
load the overlay image (bmp, jpg or png only, at the
moment) using the 'view->overlay image...' menu
option. This image will then be blended/stretched over
the top of any map that you create/view/edit. You can
also set transparency in the control dialog.

This is really quite rough, but I thought it might be
good to get your feedback before I try to smooth the
edges.

Cheers,
Aaron.

PS: I should hopefully have time reply to these posts
more thoroughly on the weekend.

--- monkschain <lingardc@...> wrote:

> Hello, monks here from ME-DEM. It's great to see
> that our lil' baby
> elephant still has a caring family- (trumpets
> appreciatively) hehe.
>  You're right about the l...o...n...g term time
> frame- we'll all be
> long in the tooth ere the task is done !
>  I just wanted to pipe in with a couple of details
> if that's OK Aaron.
>  The most useful short term addition would be the
> image overlay (with
> transparency) so that terrain could be 'defined'
> from a topo
> reference. Like tracing over it. I see that that is
> on the dev
> roadmap so that's great. With this we might be able
> to go ahead with
> using L3D straight away (without all the other cool
> stuff mentioned
> of course).
>  The abilty to load existing terrain and create in
> this manner in
> *replace mode*. So one would load up a low res dem
> with the
> corresponding image overlay (topo map) and then use
> the elevations of
> that low res dem for reference (one would need some
> kind of cursor
> feedback for height or something) along with the
> topo overlay. So one
> would know, here is a mountain and this is it's
> approx height. Define
> it with the L3D tools and bingo.
>  The ability to load up tile sets that are multiples
> of x Km (on the
> first pass each tile will be 1K px on a side at 1
> px= 20m....20 Km on
> a side, on the second pass (down the line) each tile
> with a factor of
> 10 larger scale- that is, each tile being 1K px
> still, but at 2m res,
> so 2 Km on a side). This would be really useful as
> users could work
> on larger areas (which is probably the preferred
> approach).
>  ps Joe Slayton of Wilbur (he's helped us out
> already). ;)
>  ps I'm still convinced that L3D could fundamentally
> change the way
> people build terrain models.
>
> monks
>
>
>
>

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

> -----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>
>  I just wanted to pipe in with a couple of details if that's OK Aaron.
>  The most useful short term addition would be the image overlay (with
> transparency) so that terrain could be 'defined' from a topo
> reference. Like tracing over it. I see that that is on the dev
> roadmap so that's great. With this we might be able to go ahead with
> using L3D straight away (without all the other cool stuff mentioned
> of course).

Yeah, this would allow us to be working with L3DT right away, and I have no
doubt it would speed up our work process.

>  The abilty to load existing terrain and create in this manner in
> *replace mode*. So one would load up a low res dem with the
> corresponding image overlay (topo map) and then use the elevations of
> that low res dem for reference (one would need some kind of cursor
> feedback for height or something) along with the topo overlay. So one
> would know, here is a mountain and this is it's approx height. Define
> it with the L3D tools and bingo.

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.

>  The ability to load up tile sets that are multiples of x Km (on the
> first pass each tile will be 1K px on a side at 1 px= 20m....20 Km on
> a side, on the second pass (down the line) each tile with a factor of
> 10 larger scale- that is, each tile being 1K px still, but at 2m res,
> so 2 Km on a side). This would be really useful as users could work
> on larger areas (which is probably the preferred approach).

With the existing tiled output of L3DT, this seems like it should be fairly
simple to accomplish and would definitely be useful.

>  ps Joe Slayton of Wilbur (he's helped us out already). ;)

Ah yes. Thanks. :)

>  ps I'm still convinced that L3D could fundamentally change the way
> people build terrain models.

Absolutely. The two major feature additions mentioned above - overlay
support and replace/augment (with deviation/bounds controls) of a loaded
heightfield - would pretty much get us all the functionality we need at
present and would massively speed up our workflow. The terrains coming out
of L3DT ought to be essentially ready for use at the 20m scale. For finer
scales we'd probably want to do some hand editing, 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.

- Oshyan

Hello, monks here from ME-DEM. It's great to see that our lil' baby
elephant still has a caring family- (trumpets appreciatively) hehe.
  You're right about the l...o...n...g term time frame- we'll all be
long in the tooth ere the task is done !
  I just wanted to pipe in with a couple of details if that's OK Aaron.
  The most useful short term addition would be the image overlay (with
transparency) so that terrain could be 'defined' from a topo
reference. Like tracing over it. I see that that is on the dev
roadmap so that's great. With this we might be able to go ahead with
using L3D straight away (without all the other cool stuff mentioned
of course).
  The abilty to load existing terrain and create in this manner in
*replace mode*. So one would load up a low res dem with the
corresponding image overlay (topo map) and then use the elevations of
that low res dem for reference (one would need some kind of cursor
feedback for height or something) along with the topo overlay. So one
would know, here is a mountain and this is it's approx height. Define
it with the L3D tools and bingo.
  The ability to load up tile sets that are multiples of x Km (on the
first pass each tile will be 1K px on a side at 1 px= 20m....20 Km on
a side, on the second pass (down the line) each tile with a factor of
10 larger scale- that is, each tile being 1K px still, but at 2m res,
so 2 Km on a side). This would be really useful as users could work
on larger areas (which is probably the preferred approach).
  ps Joe Slayton of Wilbur (he's helped us out already). ;)
  ps I'm still convinced that L3D could fundamentally change the way
people build terrain models.

monks

> -----Original Message-----
> From: L3DT_users_group@yahoogroups.com
> [mailto:L3DT_users_group@yahoogroups.com] On Behalf Of Aaron Torpy
> Sent: Tuesday, November 15, 2005 11:03 PM
> To: L3DT_users_group@yahoogroups.com
> Subject: RE: [L3DT users' group] SDK progress report
>
  > Sounds like the network stuff might be very handy
> > for the Middle Earth DEM Project.
>
> I hope so...ME-DEM was one of the projects I had in
> mind when I proposed the network stuff

Yay! <G>

> (the other main
> one being Beowulf clustering of map calculations, for
> huge maps in a hurry, and for the 'cool' factor).

Yeah, that would be pretty cool. Then all you need is a program that can
load those monster data sets. ;)

> For the benefit of the group-members not familiar with
> ME-DEM (http://me-dem.ashundar.com), it is an
> ambitious project to create a digital elevation map of
> 'Middle Earth', from J.R.R. Tolkien's Lord of The
> Rings, et. al. At my last reading, the goal is to make
> a 20k x 20k pixel final heightmap.

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. So once
we have the 20k map, derived from hand-drawn maps of various sources (and
covering only a portion of Middle Earth mind you - about 1/4 I think), we
divide up into 100x100 tiles (I think - or maybe 200x200) and scale by 10
times to get 1000x1000 pixel terrains. Those terrains are then refined by
hand to get more realistic detail at 20m/pixel. Then we divide again to get
the 10m (or better) data and refine again by hand. I forget the actual
numbers but we'll actually end up with literally 10's of thousands of
terrain tiles of 1000x1000 or something. It's pretty scary. And that's just
for 1/4 (or less) of the whole world. :p

> Since the
> terrain-shaping has to be (at-least partially) manual
> to get the right result, the project will require an
> awful-lot of person-hours to build a map that large.

Yeah, multiply "awful-lot" by 1000 given the above. <G>

> One of the ideas that's been proposed to help-out is
> the creation of a distributed server/client system so
> that individual contributors can chip away at small
> areas and send back the results without causing nasty
> duplication or edge mismatch problems.

Indeed. Another thing that would help is if we could load up our base maps
in L3DT and use an extension of the current terrain definition system to add
semi-directed procedural detail to our base terrains. We're getting closer
to that now as L3DT gains capability.

> > If we could utilize this to setup a master file list
> on a
> > server and have a check-in/check-out system, simple
> map-based
> > GUI tile selection with automated tile positioning
> after edit
> > and upon export, and perhaps even some way to match
> up
> > tile edges... well, it'd help us out a helluvalot.
>
> Hmm...I think I can see how all that would work. The
> tile-edge matching could be tricky, but I guess we
> could always forbid the editing of a 1px-thick border
> of the downloaded area (if you want to edit those
> bits, download the surrounding tiles too).

That's kind of a non-ideal solution. It would probably result in pretty
harsh lines if a larger area was not edited. And ultimately there will
always be tile edges, whether you're working with 4 1000 pixel tiles (so the
4 interior seams are covered, but there are still 4 edge seams), or a single
1000 pixel tile. A better solution is needed I think.

> Then-again,
> there's always the option of linear (or non-linear)
> blending of overlapping tile edges. I'd rather avoid
> this 2nd option, though, since it would add
> complications to the server.

It may be necessary given the above. 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.

> As for the other stuff, it's conceptually pretty neat
> 'n' tidy. All the network socket code would go into a
> common plugin. The map server could be a stand-alone
> program independent of L3DT, but using the SDK and
> relevant plugins. The client-side would preferably be
> a plugin for L3DT, but could initially be a
> stand-alone job too (just to keep it simple).
> Firewalls/NATs/etc can be worried about later.

Good, good...

> Anyhow, it's a good think that ME-DEM is a long-term
> project, because there's an awful lot of coding to
> make that stuff work.

Yeah, loooong term. We're definitely on the long track. <G>

> I'll start playing around with
> it early/mid next year, hopefully once I've got a nice
> beta-release of the SDK going.

Sounds great to me! I'm looking forward to it. :)

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. Maybe even commercial endeavors.
Or it can at least be made general enough that that would be the case. 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. ;)

- Oshyan