Discussion of 1.2m/px photo scenery

General discussion about Scenery Design. Questions about SBuilder for Flight Simulator FS2004.
Gridley
Posts: 176
Joined: Tue Feb 22, 2005 12:28 am
Contact:

Discussion of 1.2m/px photo scenery

Post by Gridley » Mon Mar 13, 2006 10:19 pm

Because the ability of SBuilder to create high resolution photo scenery is such a very useful tool and the results can be so satifying, I want to get some feedback on some issues that remain unclear to me, and perhaps others. At the end of this, I will compile this info, along with some specific examples, as a tutorial available to all.

We have had some spectacular success using this technique (see http://www.fs-freeflow.com/images/KSFB02.jpg), but some areas continue to be very troublesome.

I will try to post this as an informative summary of some of the key points in the coming tutuorial, but more importantly ask some question with the hope of clarifying some of the outstanding issues I have:

<b>The Basics</b>
SBuilder's high res photoscenery is much different than other photo texturing methods: first, because it generates photo textures that are four times higher in linear resolution than traditional textures (1.2 meters per pixel compared to 4.8 m/px) and second, because the textures appear in the simulator at a defined altitude, not clinging to the underlying terrain.

This is the most important point that a new-comer to this procedure must grasp - the textures appear at a defined altitude - that altitude is <i>NOT NECESSARILY</i> the same as the altitude of the ground surface in the sim. Steps must be taken to ensure that the altitude information used to create the photo textures matches the terrain elevation in the sim. These are two separate things.

Thus, the keys to successfully applying this technology are obtaining good quality imagery that is at least 1.2m/px and using a method to ensure that the terrain altitude in the sim matches the defined altitude of the photo textures.

<b>Altitude</b>
There are two ways to define the altitude of the photo scenery: Force it to be flat using an LWM polygon, or import mesh data in the form of a calibrated map. (There is also a hybrid method which has worked VERY well in our hands - create a fake one-color mesh bmp where the color matches the desired altitude of the photo textures - basically flood a copy of the Photo BMP with a green that matches the desired height in meters).

Some observations:

If you want to use the LWM flatten, best results are obtained with a large LWM poly that fully covers all of the LOD13s that photo textures are being generated for. The reason for this is that erroneous altitude information will be applied where no LWM flatten info exists, particularly along the edges of the flatten, and this results in spikes and other anomalies. Even if parts of the photo will be made transparent using an alpha channel, they should be properly elevated (see last section).

Matching the terrain (mesh) and photo textures:

This is a very important topic, and one which brings to light several issues.

First, the simplest way to match the terrain elevation and the photo textures is to use an LWM flatten to define the altitude of the photo textures, but also compile that LWM polygon and install it in the sim along with the photo.bgl - keep in mind, these are the two steps: define the photo altitude and then cause the terrian in the sim to be the same altitude. By using an LWM flatten to provide the elevation data to the photo textures, then compiling and installing that same flatten in the sim, you've accomplished both, albeit on a flat surface.

A question arises here: What is the vertical resolution of flattens in the sim? If I make a flatten at 1.23456 meters, at what altitude will the terrain be in the sim? How does that compare to the elevation that SBuilder applies to the photo textures - does SB (with the offset bias in the SBuilder.ini file) create textures at exactly 1.23456m ? How would the users' Terrain % settings affect this?

Next, a more thorough way of defining altitude which is required if the area you wish to texture is not flat is by importing DEM data. I have been using SRTM v2 data which is available via seamless or the very hard to get into FTP sites. SBuilder's HGT to BSQ tools are used, then BSQ2BMP to create the mesh BMP. This is then added to the <b>SAME MAP</b> that contains the reference to the photo texture BMP, along with the calibration info (SRTM data is 1x1 degree squares, so calibration is a snap).

Then, it is important that in addition to compiling the photo scenery, that mesh be created from this data, and both be installed into FS.

<b>Some issues/questions regarding mesh:</b>
* What DEM level does SBuilder use for the photoscenery?
* Is there a way to ensure that FS uses the mesh which matches the photoscenery? My understanding is that FS will use the highest resolution mesh available for a region, regardless of scenery area layering. Thus, it would make sense that SBuilder use 19.2m/px for defining the elevation of the photo textures, and come up with a way to upsample SRTM data to that level. Beyond that, is there a way to force the use of a mesh that matches the phototiles?
* What effect does the users' TERRAIN_MAX_VERTEX_LEVEL setting have on rendering of photo scenery?
* Is it possible to combine mesh and flattens, making it easier to handle issues which arise from AFCADs in the same area.
* Should "make flattens" be used in all situations where non-flat photo scenery is desired? In that case, the photo scenery should be made with both the flattens and mesh present at the time of compilation to ensure that no gaps of elevation data occur between the flattens, and that only the flattens be installed into FS as the mesh is not needed.

<b>Some final questions:</b>
* Is it true that "blurry" textures occur when a photo tile becomes burried by the underlying terrain, causing that texture to snap to the lowest resolution MIP? As the scenery moves in/out of the highest resolution DEM data ring, this might change as FS switches mesh data?
* If the above is true, is it likely that even areas of a texture that are transparent because of the alpha channel MUST be properly elevated in order to avoid blurries?
* Are there any considerations regarding AFCADs which you would like to see included in the tutorial?

I hope this starts some discussion about this technique, and helps to clarify it use for many of us. Again, this document is open to anyone who wishes to contribute. I would also gladly share my examples and illustrations if anyone else has been working towards this goal as well...

Best,
sg

Image

User avatar
Luis Sa
Posts: 1736
Joined: Sun May 18, 2003 11:17 am
Location: Portugal
Contact:

Post by Luis Sa » Wed Mar 15, 2006 4:23 pm

Hi Scott,

Thanks very much for the effort of putting together your ideas about high resolution photo scenery.

<font color="red">The Basics
SBuilder's high res photoscenery is much different than other photo </font id="red">

Yes! You can think of high res scenery as any other 3D object. The object itself is a "skin" painted from one side only. And as any other object it is made of points with X Y and Z coordinates. The problem is to enter the altitude coordinate for those points. If less than the existing (and used by FS) mesh bgl, the scenery will be burried; if greater, the scenery will be floating above the terrain

The obvious solution - try to limit the use of high res to flatten areas! More later ...

<font color="red">Altitude
There are two ways to define the altitude of the photo scenery: Force it to be flat using an LWM polygon, or import mesh data in the form of a calibrated map.</font id="red">

There was a BGL altitude reader by Jim Keir but he never released that programme. If I remember it could read a BGL and produce an HGT file. Then you could generate a "SBuilder altitude bitmap" out of it for the high res altitude reading. So, as you can not read BGLs you can generate the mesh BGL yourself. You should do it "LOD8" mesh so that the mesh grid coincides with the points that SBuilder uses for the "skin". But here I never could understand how FS uses meshes. I could not understand if the sampling points (the corners of meshes) are in the intersection of LOD21 grid lines or are the center of the LOD21 quads (and there is a INI parameter about this).

Also there is the "Make Flattens". This will read the altitude of the existing "Sbuilder mesh bitmap" and generate a bunch of LWM3 triangles. So you will have identical triangles - one type will be LWM3; the other type will be the painted (or textured) triangles. Hopefully the LWM3 flatten polygons would force any existing mesh (be it LOD9 LOD10 or else) to follow the altitude pattern of the high res triangles.

<font color="red">A question arises here: What is the vertical resolution of flattens in the sim? If I make a flatten at 1.23456 meters, at what altitude will the terrain be in the sim? </font id="red">

In the sim: LWM3 points have a possible fractional value of 1/128 of a meter. But if you specify 3 points that define a LWM3 flatten (it would be better to call it a tilted triangle) what about in the midle of the triangle?

On the other hand, altitude for the textured triangles are floating point values (you can have any value you want!)

Side note - runways and other "AFCAD polygons" have an altitude that goes on mils of a meter! (or mils of a foot!?) That can be a cause for flicker!


<font color="red">Some issues/questions regarding mesh:
* What DEM level does SBuilder use for the photoscenery?</font id="red">

"LOD8" which translates to : each LOD13 square is made of 128 triangles whose vertices are on the crossing of LOD21 grid lines. QUESTION: are the 64 squares properly divided into 128 triangles? I am not sure, as I could not see how FS uses triangles in the mesh! In fact if I give you a grid of altitude points there are several ways of creating triangles out of these points!

<font color="red">* Is there a way to ensure that FS uses the mesh which matches the photoscenery? </font id="red">

See the make flattens above

<font color="red">* What effect does the users' TERRAIN_MAX_VERTEX_LEVEL setting have on rendering of photo scenery?</font id="red">

It is a nightmare to remember the tests that I made using several settings of this parameters. Very few, if not none, repetitive results I could get!

<font color="red">* Is it possible to combine mesh and flattens, making it easier to handle issues which arise from AFCADs in the same area
* Should "make flattens" be used in all situations where non-flat photo scenery is desired? In that case, the photo scenery should be made with both the flattens and mesh present at the time of compilation to ensure that no gaps of elevation data occur between the flattens, and that only the flattens be installed into FS as the mesh is not needed.</font id="red">

That was the idea but still there problems.


<font color="red">* Is it true that "blurry" textures occur when a photo tile becomes burried by the underlying terrain, causing that texture to snap to the lowest resolution MIP? As the scenery moves in/out of the highest resolution DEM data ring, this might change as FS switches mesh data?</font id="red">

I must confess that I never used this part of SBuilder to produce scenery. So I never really tested this quite well. You said that the format was wrong (now I am generating DXT3!). May be others can jump in and comment on this blurry problem. This has been discussed before.

Regards (and thanks for the tutorial)

Luis

Gridley
Posts: 176
Joined: Tue Feb 22, 2005 12:28 am
Contact:

Post by Gridley » Wed Mar 15, 2006 9:18 pm

Thanks luis- I'm going to take some time and think about all of this.

One quick comment - the format being wrong is more complicated.

If I have an 8-bit alpha bmp and a 24-bit summer texture, when SBuilder makes the textures all is fine, manual conversion to DXT 1 or 3 works perfectly. DXT3 is preferable as smooth blending of the photo texture can be used with a grayscale alpha, rather than just on/off with DXT1.

However, when SBuilder calls imagetool, the black areas of the alpha become incompletely black in the resulting texture bmps. It's as if there's some blending going on which completely ruins the alpha as its not completely transparent. Not clear to me why this should be the case, but I have screenshots in that other thread that illustrate this.

Image

ponyboy
Posts: 138
Joined: Thu Jul 28, 2005 7:08 pm

Post by ponyboy » Fri Mar 17, 2006 4:01 am

I for one am very interested in using SBuilder for Hi-res photo textures. For the last several weeks I have been learning/experimenting/testing to see if I can make it work for my scenery. I have had some success. When it works it's jaw-dropping gorgeous!

Image

Image

but I am seeing many anomilies:

1. Spikes in tile gridlines
2. Instant blurriness then pops back in focus
3. Gridlines on tile borders
4. Default textures bleed through my photo textures
5. Photo textures dissapear completly at a small distance

Image

When I do see such issues I am not sure if it just my inexperience at scenery design, limitations within FS2004, limitations of SBuilder, or perhaps a combination of all three. I've tried so many different methods I am not really sure how I created the first two shots! [:p]

I guess in a way this is sort of a preview of what we might expect with FSX? From what I hear/read MS will impliment 1024 textures.

Just wanted to throw in my 2cents...

Gridley
Posts: 176
Joined: Tue Feb 22, 2005 12:28 am
Contact:

Post by Gridley » Fri Mar 17, 2006 11:22 am

That's some perfect material for discussing in this thread, Ponyboy.

So - the spikes: What method of altitude definition are you using here, mesh? In my hands, if I use a flatten that doesn't completely cover the LOD13 that will be phototextured, the edges of the flatten polygon coincide with where I see spikes. Is it possible that your spikes coincide with an edge of the mesh data? I almost bet that if you solve that issue, at least some of those blurry tiles will resolve too...

Image

User avatar
Luis Sa
Posts: 1736
Joined: Sun May 18, 2003 11:17 am
Location: Portugal
Contact:

Post by Luis Sa » Fri Mar 17, 2006 4:32 pm

Hello,

I would like to tearn more about the "spikes" at the borders problem. Does a rename of the high res BGL cures it? If yes, then there is an error in SBuilder and it could also be confirmed by looking to the intermediate SCASM file. If that is the case I wonder if you could make a small test project and (or) paste here pictures showing the spikes!

Luis


edited - it is better to make a "normal" resolution photo scenery from the same set of bitmaps to get better mixing results

- the disappearing at short distance! could you be more precise!

ponyboy
Posts: 138
Joined: Thu Jul 28, 2005 7:08 pm

Post by ponyboy » Fri Mar 17, 2006 6:26 pm

Yes, I soon discovered after my post that the spikes do appear if I do not fully cover a grid with a flatten. Seems to make sense to me now since if the area has no elevation associated with it, such as a flatten to give it an altitude, the terrain just shoots up into the air into infinity.

But as you can see from the above shot that is not on a fletten but on terrain mesh (or should I say photomesh),which I believe the grid was fully covered. Plan to do more testing on this today.

Another way to stop the spikes I found is to also apply 4.8m textures around or mixed together with the 1.2m tiles. Another side effect of mixing both was if the 1.2m tiles dissappeared the 4.8m tiles would be take their place so at a distance the simmer is fooled and still sees photomesh. Again.. still in the middle of experimenting and what side-effects this may cause I do not know.

Another observation as I work on these. In creating photomesh, it was at very different levels than my regular (or default mesh). That is to say I could slew from a high altitude down to a hill of my photomesh and slew right thru it to where the other mesh appeared. Yet I believe I had created a regular set of mesh from the same data map? So I am not sure why the two meshees do not match up?

Or thinking out loud here, if I create the photomesh with the "make flattens" button am I to create regular mesh also? Or is the photomesh meant to act as a "shell" and hide the normal mesh? Little confused in this area.

Also, I did a test creating a huge flatten of 4.572 meters (15 feet) which covered the proper altitude of my airport and the surrounding city and across the coastline and water. What I thought was odd: I could slew the aircraft down to the water (which should be zero feet) and I did not pass through my flatten? The water and my flatten matched perfectly. In terms of FS, the difference between 0 and 15 feet are negligable?

Gridley
Posts: 176
Joined: Tue Feb 22, 2005 12:28 am
Contact:

Post by Gridley » Fri Mar 17, 2006 6:29 pm

So the 1.2m/px textures will co-exist in an LOD13 with 4.8m/px? That was a question I was going to ask.

Do you get spikes between the "Make flattens" flattens, ponyboy?

Image

Horst
Posts: 137
Joined: Sun Sep 19, 2004 5:08 am
Location: Austria

Post by Horst » Fri Mar 17, 2006 6:33 pm

Hello,
I think, the man can answer all these questions will held a 60 min lecture next week in San Jose, California about the technique used:
http://www.cmpevents.com/GD06/a.asp?opt ... &id=409873
(maybe someone reading is close, and can report later)

I tried it once for a very small island with SB and it worked for me, but I used Jim Keirs tool.
It is similar to Gmax to create an island, with elevation data and the photo as a plane.
I am not a big fan of photoscenery, for the constant ground shadows from objects in this resolution.
And there is no software to manipulate the photos correct. Otherwise you will get aerialphotos (and they are very expensive sometimes) without shadows.
And second the data amount in all seasons, and the work for autogen.

Some thoughts:
Before you use SRTM data version 1 or 2, you have to interpolate the data (for the voids = no data).
For SRTM1 V2 see:
http://pub7.bravenet.com/forum/537683448/fetch/604649/
You have also a different grid.
For example:
When you use 3arc (most of them), it is around 90m, the LOD9 is about 76m.
So resample is the next interpolation to get from the SRTM grid to the FS grid.
(Which resample?)
So the vertex points, created before this process are not correct.
Third interpolation:
When you use Lod9 “mesh” in FS and you raise the TMVL to 20 in the area.
And fourth: the priority of DEM data used in FS.

I think, it is better to wait for FSX and the “flying” birds ;)
http://pip.rubberfeet.org/05/plane.gif

Kind regards
Horst

ponyboy
Posts: 138
Joined: Thu Jul 28, 2005 7:08 pm

Post by ponyboy » Fri Mar 17, 2006 6:58 pm

Ha! Would luv to attend that conference but I am sure most of it would be over my head. [:o)]

boleyd
Posts: 402
Joined: Sun Sep 19, 2004 10:57 pm
Location: USA

Post by boleyd » Sat Mar 18, 2006 1:01 pm

I agree with Horst. The next incarnation of FSxxxx "appears" to have higher resolution of the synthetic terrain/autogen. MAYBE it will also help with 1.2m photo-scenery.

I spent many hours in what I call brute force/random messing with hi-res terrain. I agree that when you carefully place your aircraft it is indeed very attractive. In fact it looks so good that it leads you to spend many hours trying to get it right.

Flattens at airports always caused some problems (fall thru) for me. They did make the flat area look very good and eliminated the "mis-match" between the underlying mesh and the stuff the photo was setting on. By using 4.8 photo under the hi-res photo the problem of the underlying texture "popping thru" the hi-res photo was not too bad. However, I could not tolerate both the blurred hi-res and its failure to appear under some unknown circumstances (angle and altitude). This one seems to defy solution, for me.

My efforts have therefore been to use 4.8m "normal" photo terrain textures in areas that I found interesting. The problem is that there are limited sources of photos that have good color-metrics. Some of the Google Earth photos are so bad that no adjustments with Photo Shop will make them usable. Others are very nice and require no color balancing. Also, as Google adds improved, or new photos, they are not made available through the API as used by Luis in his Google capture program (thanks Luis!). This may change as some dumb marketing type computes the costs of two databases versus the possible purchase of the upgraded photos.

So, in my opinion, or as they say on the Internet IMHO, if the blurred hi-res problem was solved, and 4.8 was under the hi-res, the general use of hi-res may be tolerable.



Dick Boley near 5G8

ponyboy
Posts: 138
Joined: Thu Jul 28, 2005 7:08 pm

Post by ponyboy » Sat Mar 18, 2006 5:30 pm

Dick, after sevral weeks of testing on my own my results sound very familiar to yours. Just to many anomilies happening beyond my scope of experience to solve them.

If only the issue with those terrain spikes could be solved I think several other side-effects might be cured as well. As I mentioned earlier in the thread (or my other thread), when I did have a tile that worked... it seem to work dead on - no blurrries, distance was better, no spikes. But how to cotinually acheive that is up to guys like Luis, who are on the programming side of this.

For me, it looks like the most reliable way is to use a flatten and combine areas with Hi-res and Low-res to fill gaps and blurries when they appear. This is where I will concentrate my efforts.

At least we will be ready for when FSX arrives! [:p]

boleyd
Posts: 402
Joined: Sun Sep 19, 2004 10:57 pm
Location: USA

Post by boleyd » Sun Mar 19, 2006 1:15 pm

I did make one bad ASSumptive error. The Goggle photo-base only needs one copy since the program for API use simply looks at the photo's date and only uses old stuff for API activities. It would be nice if the FSX team could convince the Terraserver group to update their database which has remained static for a very long time from what I can see. Doug Cox's program can grab very large chunks of the available color Terraserver photos in sizes that will choke your little PC. This makes it easier to create 4.8m texture with a hi-res base. Also no watermarks and the colors are quite good as-is. Just a very limited set of areas compared to Google.

I am betting that the 4.8m limitation may become 2.4m in FSX. That would be nice but the ability to risk PC overload would be a nice option for those that want 1.2m, or maybe better!

This whole simulator thing is mostly visual as Microsoft has come to understand. Flight dynamics are only needed to create the environment for the visual experience. Much like I-Max movies riding through the Grand Canyon in a helicopter. This is further supported by the extremely large number of repainted airplanes and those with maximum visual detail. Many seem to like to collect these "model airplanes". I have always believed that Microsoft could make more money by selling FSXXXX as a geography viewing tool focusing on high resolution terrain and detailed mesh. I think that FSX will be marketed in that direction with emphasis on "flying" over London at 500ft and seeing exactly what you would see in a real flight.

Dick Boley near 5G8

scott967
Posts: 67
Joined: Wed Oct 06, 2004 5:08 am
Location: O'ahu Hawai'i

Post by scott967 » Tue Mar 21, 2006 8:17 am

So far, I have not had problems with spikes. My target area is fairly flat in the existing mesh (using FSG 38M for the area.) I used the USGS NED 1" off of seamless and set up the BSQ in Global Mapper which could be read into Sbuilder as a mesh map. I then generated the LOD8 flattens. I would say about half are LWM2 and half LWM3. I didn't compile any mesh itself, just the flattens which are loaded onto the 38m mesh.

Separately (but in the same project) I set up my 4.8m VTP photo tiles with night/seasons. These work really well since you don't have to mask out the water if you use the right layer. But I did use an alpha gradient mask in order to blend in with the landclass at the edge of the project. In previous 4.8M photo work, using resample, I did the blending in the actual photo image, rather than using alpha (for this, of course, you have to have 1 bit alpha to mask water).

After getting user feedback, I have been studying my project: so far just the 4.8 VTPs. As near as I can tell they are working at desired.

Back to the project: After getting the VTP photos working well, I then did 1.2m ground objects. For these I let Sbuilder create the textures, then manually added the alpha data in DXTBmp. As noted by others, you have grid lines in the sim where the photo objects aren't created or displayed. This isn't a problem with the VTP photo "underneath". The biggest problem is the ground photo going blurry. I have not yet tested enough to truly characterize what causes the "change to blurry".

Another aspect of the project: a chunk of my photo is over water (Potomac River and some tributaries). Both the VTP and ground photo are masked off on the water (except I left pictures of the bridges. I have never really liked the FS9 3d bridges. Unless you are on a float plane, the drawn-on bridge doesn't look all that bad to me.) The bigger problem was that the LWM flattens created walls in the river. So I culled out all the LWMs which were completely in water. There still are some which are part-water, and these still create an artifact. compounding the problem is that I am using UT USA, and their approach was to float the fiver on the mesh, so the river isn't flat, but at least it undulates rather than having a wall (the wall is typically 1 m so it isn't horrible. I think the "true fix" will be to flatten the entire river in the project area.

I also spent some time getting the seasons right for the ground photos (it works on auto for the VTP photos). The seasons are constructed using a set of If/Then statements in the SCASM that select on julian day of the year (this functionality is within sbuilder, you just need to compute the dates). Unfortunately, I have been unhappy with the hard winter/ ordinary winter in default seasons.bgl and have since built replacement seasons for Nov-Mar of the year. It would be nice if there was a variable that could be tested to determine which season was active in an area, rather than being stuck with fixed dates. I need to go back ond change the dates for the texture changes. What I would really like is to create some Cherry Tree objects that I could get to bloom next week, but that's out of scope of Sbuilder.

BTW, can someone explain how to get images displayed in posts? I figured out the clique aqui para fazer o upload de uma imagem part, and I think I can upload the image, but don't know how to get it into the post.

scott s.
.

ponyboy
Posts: 138
Joined: Thu Jul 28, 2005 7:08 pm

Post by ponyboy » Wed Mar 22, 2006 4:49 am

Scott, your observations are very interesting since the fact you have no spike issue. Even when I used a relatively flat area (base area of Kowloon) I would still see lots of them. And I would say that area is no more hilly that D.C. (I used to live there). So it could very well be my process creating these spike to appear.

Regarding uploading screenshots, I don't think you can here. For mine, I placed a link to my website. If you wish, you can send me the shots and I will post them as I would like to see your results.

One note scenery I have come across was KSNA (Santa Ana, California),by Shez. He has several hi-res tiles in his scenery yet they never get blurry from what I recall. (need to look again). True, these are not on mesh but the blurriness seeems to appear either way.

Post Reply