Question Surface tiles: adjacent tile affect?

[Notebook]

Had a peculiar affect while making surface tiles for Brisbane Airport. One tile appears to alter an adjacent one.

Here are four level 1 tiles around the airport, I'm trying to blend the edges. It worked on the two landside tiles, but I couldn't get the South edge on the SE tile to blend.
http://i89.photobucket.com/albums/k207/Notebook_04/Brisbane_tiles_1.jpg

After a while, I got bored with that and moved onto the tile North of it. When I removed the ";" from the entry in the Brisbane.cfg file to enable it, the other tile came good.
http://i89.photobucket.com/albums/k207/Notebook_04/Brisbane_tiles_2.jpg

As you can see the Southern edge is now blended, and the islands in the estuary are distinct.

Here is the relevant part of the .cfg file:

BEGIN_SURFTILELIST
1 435 -78 3 ;base tile
1 435 -79 3 ;S1
1 436 -79 3 ;S1_E1
1 436 -78 3 ;E1
;1 436 -77 1 ;N1_E1
;1 435 -77 1 ;N1
....

END_SURFTILELIST

Basically, putting a ";" in front of 1 436 -78 3 ;E1 altered 1 436 -79 3 ;S1_E1
?

Most peculiar, has anyone any ideas?

Its a clean install of Orbiter100830 with only Earth091124_11_14 added.
These tiles are DDS type 3, to get the variable transparency/grey-scale in the Alpha map. Using MW DXTBmp, and Painthop Pro 9.

All help appreciated.

---------- Post added at 10:36 AM ---------- Previous post was at 09:21 AM ----------

Well, thats intersting, just did another tile:
http://i89.photobucket.com/albums/k207/Notebook_04/Brisbane_tiles_3.jpg

Blending is exagerated.

Had the same problem, then moved it to the front of the .cfg entries, and came good. I wonder if a dds type 3 tile dosen't like following a type 1 tile?

N.

 

[fort]

I sometimes asked for myself the same question but I never found the answer in the documentation. I did some experiments in this direction - that I've never really finished - and I 've try to see in the bases.cfg made by others (I remember at that moment the tiles made by Artlav for Australia, for example) if the tiles were distributed starting from the lowest levels, first written between begin and end surftiles, to the highest.

level1
level2
level3...

It was often and can be always the case. So I apply this use.

In a field a little different, but it may be something to know: if I create two bases in the cfg of a planet (earth.cfg, for example), base A and base B , bases with the same or nearly the same location for the experimentation, the base listed first - A - will be covered by the B coming second in the order of entries without any dependency in relation to their names in the alphabetical order.

Earth.cfg:
begin bases:
A
B...

 

[Notebook]

Hi Fort, thanks for the input. I think we have had those affects before!

I agree with both your comments; regarding the tile level orders, lowest first and in ascending order. With adjacent bases, I try not to have tiles overlapping.

However, these aren't the problems I'm having.
Its basically because I haven't tried alpha blending of tiles before.

I haven't found a pattern yet why one tile affects the alpha mode of another one.
Might be worth trying it on my other PC.

thanks, N.

 

[fort]

" I think we have had those affects before! ".

Yes, i remember that and i was thinking, again, to it, recently, reading a topic about Heathrow versus Westcott.

I've no idea about the affects between tiles in the case that you show and moreover by the fact that i ususally prefer, at the price of many comments writed in a cfg, to exclude an "object" that i want to hide temporarely from a list, more than to use that diabolics ";" ( or space, or "_" notations ) about wich one i've read at different moments on the french forum some thing not really concluding from my experiment and point of view.

So:
BEGIN_SURFTILELIST
..........................
..........................
.........................
END_SURFTILELIST

; 1 436 -78 3 E1

But i'm sure that one day, i will understand.

 

[Notebook]

I've used the ";" character often to temperorarily remove tiles from the list, and haven't had any problems. I don't think its that.

Odd thing is, it only happens on those two tiles! I've tried other combinations, and they are fine. There are still a lot of tiles to go to level 8, so we shall see how it goes.
I've never tried mixing type 3 and type 1 tiles before, I suspect thats my problem.

N.

 

[fort]

I'll try to remember someday when and why i've use for the first time the type 3 after many trys from black or from colour in DxtBmp. It was with the Artlav addon i think for Australia and for the coast to obtain transparency on water but where i've found the information on the old forum ? I remember Martin Schweiger giving an answer to a person on M6 about that number 3. Something like: " and about that number, euh :facepalm:, i do not remember..."

 

[orb]

If you're talking about the flag as a type of tile then:

<res> <lng-idx> <lat-idx> <flag>
{...}
<flag> is a bitflag (bit 0 = 1: render tile; bit 1 = 1: tile contains transparency in the alpha channel).

So type 1 would be non-transparent tile, and 3 would be a tile with transparency.

But if you're talking about DXT format then:

For each tile entry, a corresponding texture file in DDS format (DXT1 or DXT5) must exist in the Textures subdirectory {...}

(or in Textures2 subdirectory)

 

[fort]

Hi orb,

Yes i've often read the pdfs coming with Orbiter for many reasons and i remember that. The question here refer to the first part of your message. But - i'm not sure and do not really remember - i think that a alpha from colour or black can render transparency with a bitflag set to 1. I've made some trys with that but it's far away in the past. The pdf is not clear for me about that. And nothing about the number 3, that i use actually with grayscaled alpha. For sure, if 1 is for tiles without transparency, 3 must be for the others...

It's in my intention, from a certain time, to find in my documents, the one in wich one i've read for the first time something about it.

 

[orb]

The pdf is not clear for me about that. And nothing about the number 3, that i use actually with grayscaled alpha. For sure, if 1 is for tiles without transparency, 3 must be for the others...

Flags field is binary, and weights of bits are: bit 0 = 1 decimal, bit 1 = 2 decimal, so with "bit 0 = 1: render tile; bit 1 = 1: tile contains transparency":

• flag = 0 is a non-rendered tile without transparency (binary 00),
• flag = 1 is a rendered tile without transparency (binary 01),
• flag = 2 is a non-rendered tile with transparency (binary 10),
• flag = 3 is a rendered tile with transparency (binary 11).

It's easier and faster to list flags as bits, hence there is nothing about number 3 there.

 

[fort]

Thank you orb,

It's not the first time that i read something like that considering flags as bits but it is not in my mind and my practice so...

And certainly the reason why i was uncapable to read that part of the pdf correctly.

Nevertheless, i will make a try with a black and white chanell , on water in Orbiter, to see if there could be some interaction between the alpha of the tiles in the tex files and the alpha of a surftile on it and a number 1 as flag. I must say that my first experience with that was made in a certain confusion until the day i've seen the transparency appearing. But i do not really to what, at that moment, i had to give the credit of the success.

edit:

Does this mean too that i can use a flag 2 in Orbiter ? If i want to render only a transparency or does that potential possibility is not implemented ?

 

[Notebook]

Hi fort.

As Orb has pointed out above in #9, the flag = 2 will not render your tile. Same with flag = 0. I don't know why they have these values, I can't see the use of making a tile, then not rendering it!? I'm sure someone will tell us though...

I don't want to make this more complicated than it is, and I won't be chasing this problem up as I think its deep inside DX7 and Orbiter.exe. Martins has told us to use surface tiles at our peril before, here be dragons.

As long as we are aware that when you are making a type 3 dds surface tile, adjacent tiles can affect how it appears in Orbiter, I think thats good enough?
It would be very frustrating for someone experimenting with variable transparency to think they are getting it wrong when they aren't.

Of course if anyone wants to pursue this peculiarity I'll help with what I can.

N.

 

[fort]

Hello Notebook,

I was making some test this morning and i wanted to wait to give a complete report of them but my curiosity this time was on my old experiences with transparency from a 1 as a factor. I've made it with tiles that i usually use with a 3 factor. Dxt 5 with grayscaled alpha. At first sight, if i change the 3 value for a value 1, the transparency is still there. For the moment it seems to me that there is an imbroglio on that. I'll post my test later here and, as yourself, i do not want to spend to much time on that but that seems to confirm some trys i have made two or three years ago when i was experimenting for the first time alpha chanells.

 

[Notebook]

We have to be careful with what we mean by transparency, I find. Most of the time I use type 1 surface tiles, and just have black and white in the alpha channel.

This is fine for making rivers and coastlines, as I'm sure you know.

Here is a level 4 tile around the Brisbane area in MW's DXTBmp program:
http://i89.photobucket.com/albums/k207/Notebook_04/Brisbane_tiles_4.jpg

To get that I made an alpha template from the menu:
http://i89.photobucket.com/albums/k207/Notebook_04/Brisbane_tiles_5.jpg
http://i89.photobucket.com/albums/k207/Notebook_04/Brisbane_tiles_6.jpg

You can send that grey-scale direct to your paint program from DXTBmp:
http://i89.photobucket.com/albums/k207/Notebook_04/Brisbane_tiles_7.jpg

Then its White for land, and Black for water, save it back to DXTBmp, and save as a DXT1 type file:
http://i89.photobucket.com/albums/k207/Notebook_04/Brisbane_tiles_8.jpg

That system worked fine for me, once I'd got into it. The fun started trying to blend the edges of the tiles. Here is one of the blended tiles alpha map:
http://i89.photobucket.com/albums/k207/Notebook_04/Brisbane_tiles_9.jpg

That was saved as a type 3 tile, 4bit transparency. You can see the variations in level quite nicely. Just realised it looks like a cat...should get out more.
Anyway, it was then that the problem in #1 above cropped up. Don't know if its my system, or maybe the order of tiles in the .cfg file. Either way, as long as we now about it, hopefully it can be got round.

N.

 

[orb]

I can confirm that transparency flag no longer matters in Orbiter 2010.

In Orbiter 2010 surface tiles always use transparency, either the flag is 1 or 3. But if you check your base configuration on Orbiter 2006 with transparent tile and flag 1, there will be no transparency there. Most probably the transparency flag is deprecated now (or it's a bug).

 

[Notebook]

Well, thats interesting Orb. So its just the type of dds file that dictates the transparency, or rather the alpha map is always active?

N.

 

[fort]

We have to be careful with what we mean by transparency, I find. Most of the time I use type 1 surface tiles, and just have black and white in the alpha channel.

I use DxtBmp as you do in all its options depending of what i want to create ( and sometime dds converter 2 - i've not photoshop - when i want to choose - by the fact: reduce - the number of mipmaps in the dds if necessary ; but i can do it, also, with mipedit from MWgraphics ).

http://eliteforce2.filefront.com/file/DDS_Converter;29412

Either way, as long as we now about it, hopefully it can be got round.

In all circumstances it's also my philosophy. And more. Denis Diderot or Shakespeare ( i never remember in spite of the fact that some give that words to Jean Cocteau , and i think that it's false ):

"Since these mysteries are beyond us ( surpass us ? ), let's pretend that we were ( pretend to be ? ) the organizers."

( "pretend": the original verb is to feign )



But if i've time, i will try also, orb, with orbiter 2006 and patch. I've a doubt (... greyscaled or black and white chanell).

 

[orb]

So its just the type of dds file that dictates the transparency, or rather the alpha map is always active?

Yes. Whether it's a binary transparency (DXT1), 4-bit alpha (DXT3), or interpolated alpha (DXT5), the surface tile using it, is always rendered with that transparency, either with flag 1 or 3 (tested with Orbiter 101016). But if you want the same configuration file to be used with Orbiter 2006 (for backwards compatibility), you need flag 3 for tiles to have transparency there (i.e. in Orbiter 2006).

 

[Notebook]

Tenuous linkl to this thread, but I was using DDS type 5 transparency to try to blend the lowest level tiles on the RAAF Amberley base. Seems to work ok.

http://i89.photobucket.com/albums/k207/Notebook_04/RAAFAmberley.jpg

http://i89.photobucket.com/albums/k207/Notebook_04/RAAFAmberley_1.jpg

I've tried this before, and always have the same problem. Where do you stop blending edges?
If its overdone, you waste half the active area of the tile and it just looks soft and washed out. Not enough, and you have hard edges.

Any magic formula for this, or is it just "art"?

N.

 

[fort]

It is possible, too, with mipedit - or the nvidia plugin for photoshop - to to set individually the transparency of each alpha chanell associated with each mip map of a dds. And, in particular, to darken - thus making the image associated more transparent from far - the alpha(s) chanell (s) corresponding to the distant (s) vision (s) of a dds. And thus conceal in an improved way the effects of blending.

It's something I experienced and it's really pleasing to the eye to see appear a scene when the colors of it, very gradually, take precedence over the one's of the .tex, this in combination with osize.

I've not made it exactly in that intention - but by the fact for reducing blinking from far - but that can serve ( servir in french ) also for that.

For the scenery on wich one I still work, I noticed that the launch of mip map, from the closer to the farther, followed roughly these values (in fovea 40 and a certain... osize...do not remember):

mip 0 (largest): present between 0 and 37 km in distance.
mip 1: present between 18 and 75 km.
mip 2: present between 37 and 150 km.
mip 3: present between 75 and 300 km.

Post number 6

http://orbiter-forum.com/showthread.php?t=14186

I think this is an important and hard job with many dds - as with your addons - but it may be a curiosity to visit at least once.

 

[Notebook]

Hello fort, and thanks for reminding me about that post. I didn't understand your point about mipmaps then, they are a bit too clever for me!
Altering their transparency is something I wouldn't have thought of, but it seems ideal for what I would like to do. I'll give it a go and see what occurs

It could take some time, I've just started using the grey-scale brushes in PSP 9...

Thanks, N.