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