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.
... Yay! <G> ... Yeah, that would be pretty cool. Then all you need is a program that can load those monster data sets. ;) ... Unfortunately for us that's just...
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...
... <snip> ... Yeah, this would allow us to be working with L3DT right away, and I have no doubt it would speed up our work process. ... It would be nice to...
... both ... heightfield, ... will in ... maintain the ... It would ... variation/deviation ... you want ... negative. Or at ... that's ... rules like ... ...
Hello Monkschain, ... image overlay ... 'defined' from a ... that is ... Okay, I've uploaded an update of L3DT Pro that includes a rough first-attempt at the...
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...
Hello, ... slowing ... slower with > the overlay. Yup, it should slow things down. The overlay code is mixing the image-buffers each time the screen is drawn,...
Hello, ... ;) 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...
... Yeah, only time will make this more feasible. 64 bit OS and hardware, multi-core CPU's, etc. ... Sounds good. I agree that by the time we get enough data...
Hi Oshyan, ... 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...
... 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 ...
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...
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...
Hello, ... 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...
... 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....
Hello, ... causing an ... least it would ... There would also be the option to pre-load the tiles you're going to use. The L3DT subsystems have this capacity,...
... From: "M O" <rhoneranger2001@...> ... Maybe I've misunderstood what you want, but surely the point of the sdk is to allow you to write exporters....
Hello, Okay, one more e-mail before I go to bed. ... True enough. L3DT doesn't use vertex data, but it will be supported indirectly in the SDK, since plugins...
Great Work. For my personal use, i love to have only c++ language, and a simple dll (not com object). I don't know if is usefull to have unicode in the sdk, i...
Hi Andrea, ... Excellent! So far this is 4/4 votes for C/C++, and 4/4 votes for non-unicode (I'm counting myself as the 4th voter in each case, of course)....
... From: "Aaron Torpy" <aaron_torpy@...> ... I think i misunderstood what you meant, I thought you meant including plugins in general, not plugin access...
Wow, I missed so much stuff in one day. Well Aaron for your answers: 1. I think everything I want/need has already been included or mentioned. 2. For standard...
mark troutt
marktroutt@...
Nov 7, 2005 8:44 pm
Hi Mark, ... I'm terribly ignorant of Java, but from what little I have read, it seems that it can be a bit of a pain in importing 'non-managed' functions from...
Well, when I say "besides maybe java" I don't mean to imply that I've ever used it. All I know is that it can be more portable to other operating systems and...
mark troutt
marktroutt@...
Nov 8, 2005 12:37 pm
sorry but java is not faster than c++. it's only clearer,easiest and portable (because have virtual machine). ... From: mark troutt To:...
Oh, then my source was wrong. I was told that it was faster, my mistake. -Mark p.s. Thanks for correcting me. ... -- Gravity. It's not just a good idea, it's...
mark troutt
marktroutt@...
Nov 8, 2005 3:19 pm
Hello, I agree with the C++ is faster than Java bit, but if the Java zealots are to be believed the difference isn't that great these days. It probably depends...