Sign in to follow this  
misho_TerraBuilder

LOD lines and their Pixel #s on 4.8m/px Res. Images

Recommended Posts

I have a question which I haven't been able to find the answer to anywhere, and I would very much appreciate some info on this...I have a large photoscenery project I am building. It consists of exactly 4.8m/px resolution images stitched together into 3326x12233 pixel strips. (This is about as large as I could make them with only 1GB of RAM in my box!)When I compile, the edges are always trimmed, and unfortunately TerraBuilder doesn't elect to tell me how many pixels were shaved off of each compilation. :-( Furthermore, I am unable to use the built-in viewer to closely view where the LOD lines fall, due to the fact that TerraBuilder only wants to show those lines when the zoom is set way back.These are big problems for me, as I am attempting to compile about 10 of these strips side by side into a giant scenery package. In order to make this work, I need to know exactly how many pixels tall and wide each LOD square is.I was going to use the trial & error approach, trimming and recompiling until I found the exact pixel boundary on my images. But this has proven to be a nearly impossible task, as the image processing takes far too long, to say nothing of the time it takes FS2004 to load each time so I can view the results.So I am assuming there is a general rule of thumb out there with regard to this.Any help would be mucho, mucho appreciated. Thanks.SK

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

If you think about this just a bit more, this should be a non-issue. Have your 3326x12233 pixel strips overlap by at least 256 pixels, top, bottom, left, right.Process them.This way, TB will produce identical bitmap chunks, one from first strip, the other from the adjacent strip.The first bitmap chunk will be overwritten by the second. No need to pull your hair out.

Share this post


Link to post
Share on other sites

Thanks for the response Misho, and your suggestion.I am thinking there might be a problem with this though.For instance, when I have another photoscenery package installed directly next to one of my creations, as soon as I get edge-to-edge with the other photoscenery add-in, my package essentially "shuts down" the other package in it's entirety, creating dark-grey, featurless chunks across the entire area of the adjacent ad-in. So I came up with a hypothesis which I have, as of yet, not had time to test.This hypothesis is that, when one compiles a photoscenery using coordinates which fall outside the realm of an LOD line, causing the scenery to be cropped, the original coordinate information is compiled into the .bgl, creating a conflict if those coordinates overlap into another photoscenery installed next to it.It's the only thing I can think of that would explain why my Las Vegas freeware photoscenery is turned grey whenever my photoscenery butts up against it's edge.If this is, in fact, the case, it will cause conflicts when I attempt to place my strips next to one another with overlapping, cropped edges.Is there some other issue at work here, or is there any validity to my hypothesis?Thanks a lot Misho,SK

Share this post


Link to post
Share on other sites

I understand what you're saying but I have no answer to offer. The thing is, there are so many "special cases" possible with this kind of thing that there is no way I could cover them all. It is usually up to a designer to resolve this on trial-by-error basis. I'm not sure if the original coordinates (ones that are outside a whole LOD13 chunk) remain in the compiled bgl - there is no reason for it. BGL only contains a call to a specific LOD section... even the texture name is not referenced, as the texture name itself tells FS engine where to place it. I have had several BGLs compiled into one scenery area and they were adjacent one right next to each other.There is something else conflicting, and it could be the way the LasVegas was produced - perhaps not the same way as Terrain SDK suggests. Let me know if you resolve this, I'd be interested to know what it was.

Share this post


Link to post
Share on other sites

HahahahahahahaOoooh boy... I've done it again, I have. Sorry to have taken up your time with this Misho. Sometimes I just think a little too deeply about problems and I miss the obvious. ;-)What was happening was... I have only used the LV Freeware photoscenery package during this summer, and I almost always fly by the date set in my BIOS. If you'll notice the date of my initial post (Sun Oct-23-05 07:22 PM), it had just turned Fall about a month earlier.When I was doing my first in-sim viewing of my photoscenery project, I hadn't flown in Las Vegas since the middle part of September, when it was still - yes, you guessed it: SUMMER.So it was just by dumb coincidence that all this happened right when I tried to view my scenery tester for the first time. The westernmost portion of the LV Freeware Photoscenery package apparently doesn't have fall textures included with it!I have since tested everything in Summer and all sceneries work together sumultaneously & perfectly. Only one problem: My sceneries are so much better than the LV Freeware package, I'm going to have to re-do all of Las Vegas myself :-) 'Can't say I don't love that!Thanks a bunch Misho,SK

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