photoreal project (size issue)

[Guest artmartin]

Whoa there. I've been using the FSResample Tools over the last month and my aerial shots have been lining up perfectly. What a wonderful product. I'm eagerly awaiting an upgrade. Hope he's still programming. I'm a rank amateur at this and I'm using huge images that are clearly not at the right m/pixel and his program always gets it right on.The main trick I've used to line things up properly has been to have a version of USA Roads loaded. I always use known intersections to align my images by finding an UL and LR reference point. I never have to trim my images or resize them externally. His program uses wonderful filtering to do the resizing. Bottom line.....It's free.Art Martin

[LuisFelizTirado 33]

I must agree with Art. Elrond's utility, like all the others he has provided, is excellent and works very well without any problems at all. Many of us are very grateful to him and wish him all the best with his problems.FS Resample Tools is no different from Misho's Terrabuilder. It is a simple front-end for the Microsoft Resample and will essentially create the inf file from some basic information. In addition, it will resize the source image to a resolution closer to the output (in this case, 4.8 m/p) using much better filters than Resample, thus reducing the distortion or blurriness. Resizing, however, is an option with this tool, and it will invoke the Microsoft Resample without modifying resolution if the user wishes.In any case, it matters little what the resolution of the source image will be, since Resample will "resample" it to the correct resolution as everyone else here has pointed out. Therefore, resizing to 4.8 m/p will not in any way introduce alignment errors. Nor will resizing to 30 m/p or to 1 m/p.In sum, FS Resample Tools cannot possibly be the source of any misalignment of the resulting textures.The only possibilities are user error in entering coordinates (this has happened to me more than once - where did the custom ground go? 2 kms. away!) or, as Dick, Holger, Arno have pointed out, in the projection of the source image (and this has happened to me and many others as well, until Derek came up with a free reprojection tool for us, as we really had no choice but to use UTM projected images).Finally, I would simply like to say that there is no need to get upset or create conflicts here. We are all fans of the same thing, a computer game, and it should be an enjoyable experience for us, not a source of dispute or unpleasantness. I, and probably others here, find it unfortunate that there should be these kinds of episodes. Thankfully, it is very rare in this forum, and it is to be hoped that calm will return and fellowship will spread once again.Best regards.Luis

[rhumbaflappy 113]

This thread has gotten severely off Mitch's topic. I will finish my contribution to it with a last post. I hope I did answer Mitch's question.=========================Any program that relies on using meters per pixel will cause placement problems in the sim. And this list would also include FSSC, Airport for Windows, and SceneGenX ( among others ). Those programs need images NOT of geographic projection.Resample, LWMViewer, TMFViewer, AFCAD2, SBuilder and Ground2k all use images that have geographic projection, and are accurate in the sim.Any attempt to use pixel/meter placement will cause problems... Elrond's program as well, if it uses images that are based on that type of projection.The sim requires placement by lat-long, which is essentially angular measurement. Distance-based measurement applies only to the dimensions of objects or length of runways ( which are basically objects ). Even the placement of those objects requires lat-long placement.This issue comes up every 6 months or so. And the end result is usually the same, as designers square off into supporting fans of their favorite programs, ignoring the basic problem... placement in the sim is based on latitude and longitude. All of our programs' GUIs should be based on latitude and longitude ( angular measurement ). Failure to use this type of placement, or failure to use sources that are geographic in nature ( as opposed to distance-based sources ) will lead to misplacement or distortion in the sim.All of our background images and source images should be based on latitude and longitude ( geographic projection ). Failure to do this will lead to misplacement of distortion in the sim.WGS84 datum, geographic projection is the requirement. It's what MS uses in the sim.As pointed out in an above post, the newer road BGLS actually help these distance-based programs, because over small areas you can cheat, and use the accurate roads to fudge the placement with the GUIs that are not angular-based. You can get close, but the placement will still be off, and it becomes quite apparent over large areas ( greater than 5 KM ). Oddly, the roads are made using data sources that are WGS84 geographic projection! I hope the logical connection is made here.In Dean's case, if he did not know the extent of his source image ( the lat-long description of the corners ), then he most likely had problems aligning the wrongly-projected image using Elrond's tool ( which uses 2-point placement ). If he was lucky, his image was already geographic, and then it is simply a matter of finding the right extents ( which apparently he determined was coincidental with 4.75 meters per pixel rather then Elrond's 4.8 figure ).If you are using AFW or SGX or FSSC or using meter-based source or background images with any program, you will be able to get the images close in placement if the area is small. That is because the placement distortion is more forgiving as the area gets smaller.Using the right projection, Ground2K and SBuilder have no placement problems ( and can use bitmaps from LWMViewer as background images ).I'm not writing any of this to attack anyone, or to attack anybody's favorite program. I'm writing this because it's the truth. If any newer designers pay heed to this, they can avoid lots of problems with terrain or object placement, by using sources with geographic projection, and using programs that support background images with geographic projection. Using imaes from LWMViewer that contain the newer road or water poly data is a great way to georeference placement. A newer beta version of LWMViewer even includes SBuilder-code native output for lines and polys. Very handy!The same is true for any tool builders that are contemplating making new programs that are image based, or use background images. Please make them conform to geographic projection, so we will not need discussions of this type anymore, and we can all enjoy the simple benefit of accurate placement in the sim.Dick

[Guest flightsimstudios]

Yeah thanks guys... yeah my images are WGS4 compliant, and as you said Dick, FSRT totally messes it up when I've used it's reprojection calculator. As Dick mentioned I kinda knew the corner extent of my image, but it was for the top left corner...For some reason, what was correct in the sim the other day, I've now gone into the sim and reloaded old data, and something happened with it all, it's now off? I don'r know what's going on, whether somehow FS is caching old images or what, but I've got the exact same error now across the board... I'm now left scratching my head. I thought it might have been a boundary issue but I think I can rule that out...Thanks too on the info about FSRT. You've been able to clear that whole issue up.Now, I need to start hand coding stuff... How can I find the LOD U,V location quickly and easily step by step?I've got a bunch of tools to use, but seem to lack wisdom on how to find the U,V #... I've used TCalc, which part of it will tell me the U,V #? Is it the x,y number next to th 256 pixel square calculations?I'm curious too, what is the LOD for one photo tile (i.e. LOD 13 is the level for each photopixel).I'm still scratching my head over how my photoscenery has magically moved in the sim... ??? Any clues on that one? I found error in my last build, went back to an archived copy of an old correct one, now that one is off!!!

[Guest griss0m]

Whew, looks like my return to avsim caused quite a stir! ;) Thanks for the answer Dick, just what I was looking for. :)My other gripe was no LightMaps due to the requirement of all season textures but I think an accurate placement of autogen houses will do the trick! I remember reading somewhere that it was "possible" to have roads appear on top of photoreal too. Can anyone confirm this?After all this is done the only thing left is ground polygons!one step at a time... rgdsMitch

[Guest flightsimstudios]

I have heard that and I believe someone confirmed it... And from what I read today someone noted that phototerrain is just a landclass value so if that's true it should be, just need to choose a level that's high enough to show over the terrain...

[arno 1]

Roads will only appear on top of your photo scenery if it has been placed as VTP polygons. Placing it with resample directly does not allow any other lines or polygons to be shown on top.

[Guest griss0m]

>Roads will only appear on top of your photo scenery if it has>been placed as VTP polygons. Placing it with resample directly>does not allow any other lines or polygons to be shown on>top.Thanks Arno.Following your post I tried Sbuilder.exe but couldn't get it to load, "Path not Found" (will check this out later). I then gave ground2k4 a whirl, this worked and I downloaded the ground2k tutorial.I've searched the forums and I might be asking a really dumb question here so be kind! I got a single VTP2 poly working with custom textures in one LOD13 cell but I want to include around 8 LOD13 cells in a project. How is this done in ground2k4? Can a poly be done including all these cells?I've only ever used resample.exe with my photoreal project so this is a bit of a change for me!Kind RegardsMitch