Hi all,I've sent an email to John about the issue and will let you know his response; he's been very responsive to suggestions and questions and I'm sure he'll fix this "bump" too ;-)Please keep in mind that simple linear interpolation of larger voids will yield poor results when applied to mountainous areas (see example below). The ability to compute more realistic (looking) fill areas is what makes Blackart unique and VERY useful for mesh designers. And, no, I don't own any shares of Blackart Corp. ;-)Cheers' Holger http://forums.avsim.net/user_files/72365.jpg

;-DThanks Holger,I sent John an email stating my SRTM-loading problem before joining this forum, but he never came back. I am happy that he's been more responsive to you. BTW, there is another very annoyng issue that you might be interested to pass - the BMP generated by blackart is VERY uncomfortable for processing by a graphic application due to the fact that it translates the pixels index (altitude) directly into the pallette. This creates the artificial "seams" that appear when an index moves from - for example RGB - 00FH to 010H. Everything seems to be mapped to Blue, but when "falls" from full intensity to 0 creates a dark pixel and the "count" goes on. It would have been simpler to have a fully coloured altitude mapping which can lend itself to some "fine-tuning". Oh and the Grey scale does not work (for me?). And last - some documentation regarding the matrix/filter manipulations - what they do and why. That's all for now ;-)I hope I made sense and that my suggestions hasn't overlooked some other critical points.BTW, the linear interpolation seems to be excellent for generating Escher-like scenery. I really like the pic you sent. Seems to be right out of the Lord of The Rings .Best Regards,Al

Hi all,just received a response from John about the below-sealevel issue and I'm supposed to pass it on:"BLACKART in general cannot interpolate negative elevations if LSQR iterations are specified. The problem is apparently caused by the not completely adequate way that I formulated the matrix multiplication algorithms that the LSQR solver needs to compute the interpolation. I attempted to pinpoint the problem recently but unfortunately was unable to find it in the short time I had to look at it.. It will probably require some major grief to tear into this complicated solver to find the bug."Um, yes, just what I thought... ;-)John goes on to say that he has other commitments in the next few months and that he doesn't anticipate fixing this particular bug before sometime this summer."On the plus side, I am almost finished with the SRTM30 interpolation/patching utility and hope to post version 3.76 next week with this feature completed."Sorry, Al, I had sent me email before your last post. But I'll pass along your questions with the next one.Cheers, Holger

I don't know if this idea would work, but could he find the lowest elevation in the file, raise all the data points in the file by that amount, do the interpolation, then subtract all the data points by that amount?So if your file has its lowest elevation at 140 feet, he could add 140 to all the data points, interpolate, then subtract 140 back off all the data points.Alternatively, is there a way that we could add the offset to the data file, run Blackart on it, then subtract the offset back off ourselves?It's just a thought ... that's a nifty trick I've used in several computer engineering applications, and I thought maybe it could work here, too.

>So if your file has its lowest elevation at 140 feet, he could>add 140 to all the data points, interpolate, then subtract 140>back off all the data points.What I meant to say, of course, is assume that your file has its lowest elevation at -140 ...

Hi John,clever idea! If MicroDEM was able to write out .hgt format we could follow this procedure outside of Blackart (it's possible to do global add/subtract in MicroDEM). In any case, I forwarded your idea to John; let's see what he thinks about it.Cheers, HolgerP.S. Did you ever complete your airport-to-terrain mesh editing utility?

> Did you ever complete your airport-to-terrain mesh editing utility?I haven't touched it since I sent you an alpha copy.I'm just starting to inch my way into the world of Blackart, but it looks like it can't read any format that I'm working with. I was hoping that Blackart could interpolate the void polygon around the airport that my utility makes, but it seems that I'd have to export it in a different format. :(So for now, the utility is only useful for north-oriented rectangles.

>Sorry, Al, I had sent me email before your last post. But I'll>pass along your questions with the next one.>>Cheers, Holger Hi Holger,Thanks for the answers - not very encouraging but still - there is hope. Blackart is by far the most accurate SRTM manipulation - apart from the below sea level issue. I was able to circumvent it but this is due to the relatively easy topology. I wonder about the mesh accuracy created by people using the "fire and forget" method for areas which are not personally known by the developers. I've came to respect the SRTM data - it is very accurate and yet treacherous for people who do not closely know the targeted topology.Blindly running apps like Terragen, Blackart etc. without close and smart inspection of the results comparing against real topographic maps will create a lot of junk meshes, and that will make people lose their confidence in the developers and the SRTM data.Some food for thought.Best,Al

Hi all,Al, I much agree with your concerns about the lack of (or desire for) quality testing! In many cases the mesh maker doesn't even have to know the area to tell - when checking in LWMViewer or TMFViewer - whether the output is usable or not. For example, this is La Palma (Canary Islands) as depicted in a recently uploaded freeware mesh. The open caldera, the defining feature of the island, is completely missing in the raw SRTM data and a simple interpolation algorithm like SRTM2BGL or SRTMFill makes it look like this: http://forums.avsim.net/user_files/73663.jpghttp://forums.avsim.net/user_files/73664.jpgAgain, this is easy to spot and can be avoided by using better tools (even MicroDEM did a much better job in this case).Cheers, Holger

Howdy,more feedback from John Childs:Re the altitude mapping:"I understand the problem with the direct mapping. I plan to improve this soon. As far as the gray scale issue - you must remember that BLACKART is a schizophrenic application that started out as an interpolation algorithm, then became a contour line extraction/interpolation application which then became a contour line extraction/interpolation DEM interpolation application. The grayscale feature was added to help in the contour line extraction process and it, like many other menu selections was not intended to be relevant to the DEM patching process and will not work in this case. I plan to rework the menus to make it clearer which utilities apply to which process."Re the matrix/filter manipulations:"I will add some information regarding the Saunders-Paige solver to the Help file when I rework that code. In the meantime you can search those words and discover the source line at the Dr. Saunders Stanford website. He provides a terse explanation of the main components of the computation."John also agrees that John Taylor's idea - raise, interpolate, lower - would probably be a suitable work-around to the issue of below-sealevel data.Last but not least, version 3.76 has just been released - http://www.terrainmap.com/ - and I'd like to remind all users that there are at least three places to look for new/additional information about Blackart: (1) the in-built help text, (2) the Blackart sections on John's website, and (3) the FAQ section - http://www.terrainmap.com/ - where John summarizes specific questions and issues.Cheers, Holger

Wow.Yeah, I'm very wary of downloading mesh based on SRTM data for these reasons, plus the fact that a lot of them aren't seamless.

WOW! You are a bearer of good news ;-). I'm happy that John plans to support blackart despite the fact that releasing it to the "general public" seems to have been almost an afterthought. I for one, will be looking forward to its future releases.Hmmm. A though has just crossed my mind. I have the odd feeling that MSFS 2006 will come on DVD(s) and will cover the world with SRTM3 and USA with SRTM1 meshes... MS will have simply no choice after users have been already spoiled .We're marching slowly but surely towards a full photo-realistic/accurate mesh worldwide scenery in one of the future MSFS releases - when the mainstrem HD capacity would be @10Terabytes and RAM will be @100MB - not to mention Pentiums or AMDs running at a "cool" 50GHz.OK - time to wake-up.Best,Al