Jump to content
Sign in to follow this  
rhumbaflappy

Landclass Assistant & Small Areas

Recommended Posts

Guest

Sorry John it was not my intent to infer that Landclass Assistant did not work. I have been looking at all options for getting Midway done. I am sorry I did not contact you first. Not too many people get the whole CFS2 modifying thing... we are gluttons for punishment. Besides you are an Arizonan are you not. ;^) Another good reason not to offend.In fact AF=Midway is an Arizona boy project. The main designer lives in North Phoenix. On the phone with him most every night.You can see one of the reviews here:http://www.sim-outhouse.com/?loc=reviews&page=AF1 I do think that the same landclass theories apply though for CFS2. I also have FSLandClass and was able to redo the landlclass for Oahu. It had issues with Midway as well. I would like to use Landclass Assistant though for redoing the city portions of the island... Honolulu needs to be more accurate.As for the VTP method... well I just dug out all my info and am looking at that right now. I can see some serious things we could do with it as far as laying out the atoll.

Share this post


Link to post
Share on other sites

Crash...My response was directed at Dick... My only concern with your post was the effort to adjust CFS2... I concede it is possible that the undocumented features added to FS2002 may have been present in CFS2. But they certainly aren't present in FS2000. Mesh and landclass are different animals. FS2000's resample.exe most likely contained the undocumented features because CFS2 and FS2002 were under development by the time the FS2000 Terrain SDK was released.I no longer run CFS2.... But assuming the islands are placed accurately and the same in FS2002 and CFS2, send me the .raw and .inf file for your Oahu project. I've written a utility that will adjust the .raw file in case textures are offset--and that can be an issue after my June .inf update, and is one corrected in my beta LCA release. I can also email you the beta lca release...If the textures are offset, we're talking +/- 1.5 km's at most. If your texture coverage is over a larger area, then there may be other issues preventing the LC from displaying...-JohnBTW, wonder if you're talking about Rick? I spent some time on the phone with him getting resample to work with .inf files under XP... I've supported many people professionaly and privately, and Rick was one of the best--and he really helped make LCA available to a wider range of users...

Share this post


Link to post
Share on other sites

Dick...I'm mad at you :)I keep hitting the dang edit key on your posts, instead of reply. My illness over the summer left my right hand a bit paralyzed... Now it even swears :)Although FS2000 uses landclass, the landclass bgl's compiled by resample.exe don't work with FS2000. I can take the Carson City bgl in the LCA tutorial and install it in both sims. It will only appear in FS2002... The same applies to photoreal scenery. While there are photoreal methods available to FS2000 vs. resample.exe, resample had undocumented methods which made photoreal much better in FS2002. These methods were almost dropped from FS2002. There were long discussions between the user community and MS regarding them.... You'd have to go back to some of the archived threads to see some of the issues which were raised.I do concede that CFS2 may support the features, but due to my June .inf update, the "old" lca does offset the textures by 1-2 kms. Not a good thing for little 'ol midway. That's why I've offered the lca beta to Crash.You are more than welcome to email me to try out the beta as well.... I'd like to hear your thoughts, especially in regards to the search/replace features...-john

Share this post


Link to post
Share on other sites
Guest

Yeah I checked the coordinates in both CFS2 and FS2002 last night. Spot on. They both put me in the same place on Eastern Island just south of the main runway. So we should not have any problems there.Glad to hear you are recovering. I have been a big fan of your work with the Phoenix scenery. I will be doing some custom buildings for Phoenix in the future like the Westward Ho, BOB, Bank One tower, Sun Devil Stadium and Veterans Memorial Colliseum.Hmm might even put in Tempe Town Lake...LOL!I grew up on Ed's Field.. EDS just south of Eloy. Really would like to put an Arizona scenery package together.The guy I work with is Gregg Bond. He is not too savvy with the scenery but has touched about every other part of the AF=Midway project. Some fantastic work. Nothing can immerse like scenery though... that is why I'm trying to get this clean.

Share this post


Link to post
Share on other sites

Hi John.As you can tell, I am adamant about a 257x257 source file. If a 257x257 source is used, there is no need for any adjustments. The placement is exact. I re-installed FS2000 to check landclass there, and what you say is true...our landclasses do not behave right. I actually saw the right texture 'pop' on the screen for the midway area, but then disappeared into the ocean. Midway itself is a FS98 style photoreal polygon, but the texture showed briefly at it's edge. :(But CFS2 is another story, as you can see from the above jpeg. And I'm not kidding when I say that the 257x257 array will pass through resample untouched. The original array can be extracted from an uncompressed TMF with a hex editor, and redisplayed in a paint program, matching the original exactly. That cannot be done with any other array size, as resample will alter the original content and size. And that's why you would need an adjustment. If you adopt a 257x257 array, you will need no adjustment.Dick

Share this post


Link to post
Share on other sites

Let me propose this question then....Let's assume I switch to a 257x257 .raw file.... What formula should I use in LCA to feed back the cell values to the user (based on lat/lon?). Even with a 257x257 grid, a formula is required to report back the right vertices to the end user. -J

Share this post


Link to post
Share on other sites

If a 3x3 array of verticies existed, the central vertex ( point(2) ) is positioned as ( point(1) + ( span / 2 )), so as you can see, the span is 256x256 and that's reflected in my INF file. The verticies are always 1 more than the span, as they must enclose the cells. point(257) = ( point(1) + (( span / 256 ) * 256 )) or point(257) = ( point(1) - (( span / 256 ) * 256 )) if point(1) = N42.1875 and we want the southernmost point...( 42.1875 - ((2.8125 / 256 ) * 256 )) = 39.375 for the southern point... which is also the southern bounds.---------------------------point(256) = ( point(1) - (( span / 256 ) * 255 )) ( 42.1875 - ((2.8125 / 256 ) * 255 )) = 39.385986328125 for point 256...Now this gives the vertex assignment. What about the cell? There is no cell. That's the issue. There is a groundtile, generated at runtime, and in FS2002, that groundtile is a blend of the four surrounding verticies. The vertex itself will be the landclass you desire, but midspan, it is a combination of the 4 surrounding assignments.At the edges of the LOD5 area, the BGL cannot blend into the default tiles, and that's what leaves a hard edge ( eliminated if you enclose the entire landclass by transparent values in rows 0 and 257 and columns 0 and 257 ).

Share this post


Link to post
Share on other sites

Here's an odd question then...If you have a row 0 and a row 257, wouldn't that make the ideal .raw file size 258x258? I could code LCA to build a 258x258 .raw file, but only allow access to a 256x256 group of vertices, thus avoiding the "Edge" problem. I see what you're saying...given an example like this:x x x x x xx x x x x xx x x x x xx x x x x xx x x x x xx x x x x xIf this were a "pretend" 6x6 .raw file, the vertices that "make the most sense" should be the inner four. Entering a byte value in location 1,1 would in essence be telling resample to place that byte value in vertice 0,0, giving the "hard edge" result we've both seen.Even with the 256x256 .raw file, placing a value either in the first row/col, or the last, will result in a hard edge. Those results are consistent every time. And the blending still takes place as well.What it comes down to is no matter what type of .raw file you use, you can only get texture placement to within +/- .75 km from where you want it. Whether one calls it a vertice or a cell, texture placement is subject to the blending that FS does on the fly.... It's pretty easy for me to adjust LCA to work with a 257x257 .raw file, but I'm beginning to wonder whether the 258x258 setup would make more sense....

Share this post


Link to post
Share on other sites

2 pics to illustrate the vertex assignment of resample. This is from a 257x257 array for a source.The small pic showing Landcalc2 to derive the vertex point, and a screenshot with a cellgrid bgl activated, to display the LOD13 Areas. The vertex shows quite clearly, blending into the surrounding 4 areas.INF:; Sahara.inf; 257x257 source[Destination]DestDir = "."DestBaseFileName = "Sahara"UseSourceDimensions = 1[source]Type = ClassU8SourceDir ="."SourceFile = "Sahara.raw"Lon = 22.5Lat = 25.3125NumOfCellsPerLine = 257NumOfLines = 257CellXdimensionDeg=0.0146484375CellYdimensionDeg=0.010986328125A 256x256 source will usually look the same. Why? because the LOD13 Areas are filled in latitudinal bands... row 0 is displayed first, starting at the 0 column and ending with the 255 column. Then row 2....If the point is 190,188 it will get displayed there, unless your math is off, or resample decides to move it! resample never moves anything with a 257x257 source. Look with a hex editor. The values of a 257x257 array are unchanged in the uncompressed TMF file... in a 256x256 based TMF, the values may change. And that's why you're going to need an 'adjust' factor of 1 Km with 256x256... because resasmple is deciding the placement, not you.

Share this post


Link to post
Share on other sites

I see one part of the issue, which is why I discuss the need to make calculations in the the program. It all comes down to differing approaches...When I created the LCA docs, my focus was a user who'd blindly pick a lat/lon, and use it to place a landclass texture. Problem is, they are just as likely to not hit a vertice.... So the program which calcs the x,y value has to round to the the closest vertice.... There will always be the chance that they can be off....but....Cellgrid.bgl? Tell me more!

Share this post


Link to post
Share on other sites

Well, based on that link, I'll have to spend the next few days playing around with it.... Just trying to think about how I can adapt the LCA grid to deal with a 257x257 .raw file. It's a no brainer if I restrict access to the last row, col... Personally, I think that'd look better anyway, given the "hard edge" effect caused at the edges. What I can do in the short term is build a conversion utility, to take a 256x256 .raw file and make it a 257x257 .raw file. If I like the results, and find them more accurate, I can incorporate the conversion into a future release of LCA... So far, the 256x256 issue has not been a problem for the users that have stayed in touch with me, and it's not prevented people from putting out some first class landclass updates, like the recent swiss scenery...

Share this post


Link to post
Share on other sites

I agree John. You're program is great, and fills a need many people have. And I like Burkhard Renk's commercial program as well.Using either program, there will be no problems 95% of the time. But occasionally, a problem like James had will pop up, and the resampling of the 256x256 source is the reason. Your program's users may balk at using a 257x257 grid... I'm sure users of FSLandsclass do. All the packs they've bought are based on 256x256! You may decide that the 1 Km 'adjust' option is easier for users to tolerate than switching to a different grid system. And it should be easier for you to go ahead with plans for that, as it will not sidetrack the next edition's release.Your users could be told in a ReadMe file the theory as to why adjusts need to be occasionally made. For me, it is no theory.

Share this post


Link to post
Share on other sites

That's where my next release tries its best. With my last .inf update, I knew there was an issue when I was working on my Mexico City project. So I put in a rounding scheme based on the Lat/Lon, which moves the point being updated to the closest vertex. It's only a big issue if accuracy is a must, such as around airports. With an update as large as Mexico City, it doesn't have the same impact.Hopefully CrashAZ will email me, and I can forward the beta release to see if it allows more accurate texture placement... I still don't want to post the release quite yet... I'd like to add an FSUIPC interface to my proggie, similar to another recent release. But that opens up a can of worms, in the sense that updates to FSUIPC can open up support headaches for me. Still, the idea is interesting. :)

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