Jump to content
Sign in to follow this  
Holger

Editing LWM and VTP *.asm files FS2004

Recommended Posts

Guest Freddy Wilhelmsen

Hi!With LWMviewer I managed to decompile two BGL`s for a certain area. HL954060.bgl, and HP954060.bgl ( in FS2004SceneryEureScenery )Case is I have made a mesh (LOD 10, form 10 meter DEM data) for the island covered by 5 areas see image of area. ( dont have the numbers in my head, I am at work ).http://forums.avsim.net/user_files/60166.jpgProblem is that the default HP954060.bgl and HL954060.bgl file cuts off my coast, and I get ugly cliffs. I know the SDK isnt available yet, so the approach to edit the LWM, VTP and coastlines, is to edit the HP*, and HL*. Files...Here is the question. How to edit ASM source files ?. I tried to eliminate the BeginData, and EndData rgd the 5 areas in use, but it resulted in numerous peaks og mesh going up to eg 4000 feet. and even outside the Area I have cut away from the ASM file?. I used BGLC to recompile back to BGL format ( no errors compiling ). Is there maybe a program where i could import the ASM file and edit the existing points ?Holger and Rhumbaflappy, I know you gurus have an idea :)Best RegardsFreddy Wilhelmsen

Share this post


Link to post
Share on other sites
Guest simagic3d

> Case is I have made a mesh (LOD 10, form 10 meter DEM data)Why are you resampling a LOD 12 data source (your 10 m dem) toa LOD 10 destination (38.2 m)? You're basically throwing away73% of your dem data by doing so. Well, what I mean is, whybother getting 10 m data in the first place when 30 m is a wholelot smaller in filesize to manage and you would be losing only21% of that 30 m data resampling down to LOD 10 instead of 73%.As for the topic of this thread... no clues as i've never donesuch.

Share this post


Link to post
Share on other sites
Guest sgreenwood

Perhaps I can explain.It is important to distinguish between detail and accuracy.Resample uses the source data to create an entirely new model of the terrain, based on its own grid (LOD-based) system. The more accurate the source data, the more accurate the model Resample can construct from it.Of course, mesh at any given LOD will have the same amount of detail, regardless of the amount of detail in the source data. Since the sim limits the amount of detail we can preserve, there is little value using an LOD of 12. So, 10m data produces more accurate terrain than 30m data, and LOD10 optimizes the trade-offs in the sim: maximum detail rendered, mesh file size, performance, and range where the mesh is rendered below the aircraft.Regards,Stevewww.fs-traveler.com

Share this post


Link to post
Share on other sites
Guest simagic3d

> It is important to distinguish between detail and accuracy.I understand those differences. That's why I was curious aboutsuch a large difference. You may want to define what you mean byaccuracy. the elevations values are going to be the same whetherit's 30m or 10m data... that is, a mountain peak at 2,000 m in a30m dem is going to be 2,000 m in a 10 m dem. The only improvementin accuracy would be in the finest of the detail. I look at it froma digital imaging perspective since most dem viewers can represent thedata as a grayscale image. Now, a 30 m dem does "look" a little"fuzzier" or "out of focus" compared to 10 m since the 10 m can resolvefiner details, obviously, but the gross elevations are still the same.So, understanding that and the fact that resample is going toaverage together neighboring points to create/conform an elevation toit's own internal LOD grid spacing, thus further lowering the resolution(making the "image even fuzzier"), I don't see how giving resample 10points of elevation between it's internal grid points is going to makethe resulting singular point more accurate than if you fed it 3 points.Maybe you can assist my understanding further, Steve. Thanks!

Share this post


Link to post
Share on other sites

Hi:if I may jump in...The difference between 10-m mesh and 30-m mesh is in the accuracy of each elevation measurement, both vertically and horizontally. Consider that different DEMs have to confrom with different accuracy standards. For example, if the accuracy standard required the DEM to be within 5% of the true location of a given feature, then a mesh with a 30-m grid would allow for +/-1.5m deviation and a 10-m grid for +/- 0.3m. Similarly, high-res DEM will have smaller error allowances for elevations than mid-res DEMs. In other words, in a 30-m DEM the 2000-m peak might be considered within mesh specs if it was between 1950 and 2050 meters but in a 10-m DEM it would have to be between 1990 and 2010 meters.Whether the higher accuracy translates into a visible difference in a LOD9 or LOD10 FS mesh is a different question but Steve's point about the differences between 10- and 30-m source data are correct.Ergo, a peak that is 2000m in reality may (and will) have quite different elevations in source data of different resolution.---Re your original question about LWM and VTP editing: Gilles Gauthier and myself have both hand-edited these kinds of files to make lakes and coastlines conform with add-on mesh. We even wrote up a tutorial but the changes in FS9 and the rapid advancement of new tools (e.g., LWMViewer) has made the draft outdated before we uploaded it. However, the text does describe the structure of the disassembled .asm files. If you're interested, and your ISP can deal with 2.5MB attachement, send me a PM with your email address and I'll forward you a copy of the draft.Cheers, Holger

Share this post


Link to post
Share on other sites
Guest sgreenwood

"Maybe you can assist my understanding further"Well, I'll share a few of my own impressions, but no guarantees. "define what you mean by accuracy"I suppose I mean an accurate representation of real-world elevations and their locations in the sim. (Recognizing the many limitations encountered when rendering the data as mesh in the sim.)"the elevations values are going to be the same whether it's 30m or 10m data... that is, a mountain peak at 2,000 m in a 30m dem is going to be 2,000 m in a 10 m dem."That's not entirely true. 10m data has 9 data points for each point in 30m data. This means there is a far greater chance that one of them will be close to the actual 2000m peak. So the recorded location and elevation of the highest point (local maximum) will be more accurate. "The only improvement in accuracy would be in the finest of the detail."True. But this matters to some of us. I spend much of my time flying at or below tree-top level, so any additional detail I can provide matters to me. This discussion is irrelevant to those flying in the cockpit at 35K ft."I don't see how giving resample 10 points of elevation between it's internal grid points is going to make the resulting singular point more accurate than if you fed it 3 points."One point actually, vs nine. My statistics is a bit rusty, but as I recall, estimate errors (SE of the estimate) are often proportional to 1/(square root of n), where n is the sample size. In our situation, the (error in a) range of values estimated using sets of single data points will be about 3 times greater than the estimates developed from sets of 9 data points. Sure, you may get lucky once in a while, but ..."resample is going to average together neighboring points"I'm sure the algorithm Resample uses is more complex, weighting nearby points more than those more distant when computing "averages". This means that all those extra more heavily weighted 10m data points nearby provide more accurate information about both elevation and slope of the terrain around the point to be created. So you can see a difference between LOD10 mesh constructed from 10m and 30m data. Whether you can tell which is which and whether it matters are entirely different questions.Steve

Share this post


Link to post
Share on other sites
Guest Freddy Wilhelmsen

Hi all!Nice to see so mane replies in such short time.Let me explain a bit about our project( Me an a friend, Tor Egil Johansen ).Our goal was to make a good mesh of the Island we live on ( mager

Share this post


Link to post
Share on other sites

Hi Freddy.There is no good way to remesh. We have tried many ways and they all fall short.So, I convinced Edgar Knobloch to add FS9 LWM code to his CFS2 LWM converter:http://library.avsim.net/esearch.php?CatID...Scen&DLID=43104This will take FS2002 or FS9 LWMpoly ASM data ( like that produced by LWMViewer when looking at HP*.bgl ), and convert it to CFS2 compatible LWMPoly1 code. That code is water and land polys without flattening.So you can convert an entire FS9 HP file to mesh-clinging. They are about an LOD5 size. Load the default HP bgl into LWMViewer, and save the source. Then convert it, recompilre it, and replace the default HP file... just rename the old with a BAK extension to deactivate it.Does the mesh-clinging water look odd? Yes, in some areas it is quite odd... but that is because the default sizes and shapes are wrong. But your new polys will look great with the new mesh. The HL shorelines can overwrite the defaults using Grouns2K4 or defarea, by Christian Fumey.Christian has been working on a utility ( GrdLWM ) that can change X,Y data to a Ground2K4 LWM file... so the shoreline, road, stream data could be automatically made into separate Ground2K4 projects.By working between Edgar's utility, Ground2K4, Christian's GrdLWM utility, Jim Keir's LWMViewer, and GIS programs, I've got the LOD8 area near my home pretty good.If you have a GIS program that can display the XYZ data for lines and water polys, it should be able to export a georeferenced image of the lines ( make sure they are WGS84/geographic projection ). That image could be made to 8-bit ( 256 color ) bitmap, for use with Ground2K4.http://forums.avsim.net/user_files/60706.jpghttp://forums.avsim.net/user_files/60707.jpgDick

Share this post


Link to post
Share on other sites
Guest Freddy Wilhelmsen

Hi!Thx Dick!. Will certainly try that tonight when I get home from work.Will let you know of my progress :)Freddy.

Share this post


Link to post
Share on other sites
Guest vlada stoje

Hi all,I agree with Steve and Holger, the better resolution of the source helps the SDK resampler to resize the source in some standard geographical resolution to the special LOD resolution. It seems that the SDK resamplers are not able to estimate the peaks between the source points and create new local extremes. They are just weight-averaging the source points. I tried prepare twice denser source from the 3 arc sec SRTM by bicubic splines (which are able to create new local extremes) and support the SDK this way. On the picture there is visible the sum effect of the splines together with the sharpening deconvolution matrix filter (in this case the size 7x7, the frames from the center to the border 192,-12,3,-1, division factor 120)http://www.volny.cz/stoje/scen/cr_srtm_sharpen_01.gifThe SRTM and the standard SDK resampling brings finally the flat bumps precisely on the places, where we are expecting our little hills, but there is the need to compensate the complex flattening (both the averaging of the original 1 arc sec to published 3 arc sec and the specific processing and rendering in FS) with some sharpening steps in the preprocessing phase. Theoretically, the best way would be to pass the SDK resampler, calculate precisely the LOD points in the preprocessing phase and use the SDK just to copy the values between the new LOD source and the same LOD tmf, but perhaps the "bicubic" thickening of the source could help quite sufficient (Steve, considering the FL350!)

Share this post


Link to post
Share on other sites

Hi Vlada:great post as always! How do you do these comparison shots - are they animated gifs?If I understand your procedure correctly, the moving-window filter "rebuilds" some of the detail lost in the 1-arcsec to 3-arcsec generalization and/or compensates for the smoothing effect of the FS display engine. How do you know that the emerging details are, in fact, more accurate than the mesh data without pre-processing, considering that local (or global) filters are not "intelligent". Also, what influence does the TMVL parameter have on the results?Cheers, Holger

Share this post


Link to post
Share on other sites
Guest vlada stoje

Hi Holger,the experiments are based mostly at the discussions here on this forum, thanks for all mesh fans! The happy mesh creators inside the dry land, without the problems with the SRTM sea noise! So I tried turn the button tone on the repro to the right instead to the left. I agree with you, the reconstructions of the short waves can't be fully correct, but the results can look good. First attempts already for Gtopo30 on the 8-bit level (in PaintShopPro 1. Image

Share this post


Link to post
Share on other sites

Hi Vlada:thanks for the images and feedback - looks like your approach is something to keep in mind. I particularly like the idea of using it for enhancing low-res data before merging with high-res data. John Childs' Blackart does something like that for GTOPO30 data but I don't know whether he uses a high-pass filter.Seems like you're in need of some landclass updates, particular something with rape seed fields in it ;-)Cheers, Holger

Share this post


Link to post
Share on other sites
Guest vlada stoje

Hi Holger,yes the Blackart is very useful for FS creators, big thanks to John Childs for his programs and the terrainmap website! I have the latest version of Blackart 3.51 now and there is already the menu entry for the sharpening filters, it is promising!The exact LWM, VTP2 and landclass elements made in Ground2k4 will be here soon for big part of Czech Republic http://sweb.cz/z_pokorny/msfs/ and also Slovakia http://www.simworld.szm.sk/sk-lod8.htm , I believe that the rape seed fields will be there! (For now some problems with the childpoints in the VTP2 structure, but I think the program chptconv by Edgar Knobloch already solved the unwanted autogens).Cheers Vlada

Share this post


Link to post
Share on other sites

Hi Vlada.You can also avoid VTP2 unwanted autogen by using names for the roadlines:VTPTexStart label word VTPTextureListHeader 1,VTPTexListStart, VTPTexNameStart, VTPTexNameEndVTPTexListStart label word VTPTextureListEntry VTPTexNameStart, VTPTexName0, VTPTexName1VTPTexNameStart label wordVTPTexName0 label word VTPTextureName "roadssu.bmp;roadshw.bmp;roadssu.bmp;roadssu.bmp;roadssu.bmp;roadslm.bmp" VTPTextureType 2, 0, 0, 4VTPTexName1 label wordVTPTexNameEnd label wordThis way there are no electric poles or road signs ( very framerate friendly ). I have had some problems with Edgar's childpoint utility in that the visual roadends are not squared up. This isn't a problem unless your roadline data is in short line segments.I've suggested a cure, but Edgar may have lost interest in developing the program... just an alternative idea. I am replacing a default set of lwm-vtp BGLs ( 924160 LOD5 in size ) with US TIGER data.. one LOD8 area at a time. That BGL set is 66 LOD8 areas. The mesh is NED data, rather than the SRTM data.Dick

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...