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