FSDeveloper Wiki - User contributions [en-gb]

Main Page

2006-11-04T20:42:02Z

Nickw:

[[Image:fsdeveloper_logo.jpg]]

= fsdeveloper.com Wiki =

Welcome to the fsdeveloper.com Wiki. In this Wiki you will be able to find the following design related subjects:

* Manuals
* Tutorials
* Code Examples
* Design Examples
* Glossary

At the moment the manuals cover the tools available at [http://www.fsdeveloper.com fsdeveloper.com] only, but the community is free to add manuals for other tools if they want of course. The tutorials cover different subjects, like GMax, BGLC source code tweaking and many other. Everybody is invited to add his own experiences, tutorials and how-to-do's. Finally the glossary provides an overview of some of the more technical terms used in scenery design discussions. This should enable new designers to learn the scenery design slang faster. If you find a term is missing, please add it to the glossary.

As you might have guessed from the above, this [http://en.wikipedia.org/wiki/Wiki Wiki] system allows all users to add and edit new content. Therefore this is a great way to share knowledge within a community. You might wonder if the forums do not provide a similar function? I think this Wiki system can really add something, it is a good place to find article on how to do things. While the forums are more suitable for discussions with other designers and problem solving. A lot of people who do not contribute in forum discussions are looking for flight simulation design information, so I hope this Wiki can provide some of that information.

= A few rules for editing =

As discussed above, everybody can edit articles found in a Wiki system and I would certainly encourage people to do so. But to keep the final articles readable for everybody, there are a few rules for the editing of them:

* Only edit an article if you can improve it. So by adding your way of doing things or clarifying information you found unclear. So do not edit it place a little remark or add "I agree" or "Thank you".
* Do not start discussions in an article. Of course you can add alternative ways of doing things, but if you want to discuss a subject use the [http://www.fsdeveloper.com/forum forums].
* Please make sure that the article is still readable after editing it. So it must consists of sentences, written in understandable English.
* Please add a line to the "Document version information" section that describes you changes and add your signature to it as well

Night texture creation

2006-10-02T19:40:09Z

Nickw:

''Originally posted by "Al" to the forums.''

Though written for Paint Shop Pro use, the concept should be pretty much the same for other 'paint' programs.

This tutorial creates textures for a bank that has a hanging sign on the corner of the building, night lighting on the buildings cornice and doorway night-lights. It is a simple little project intended more on getting your thoughts oriented on what can be done with night lighting.

[http://www.example.com Download PDF]
[[Category:Scenery design]]

Night texture creation

2006-10-02T19:38:41Z

Nickw:

Night texture creation

2006-10-02T19:37:24Z

Nickw:

API macro custom object symbol

2006-10-02T19:34:00Z

Nickw:

== Introduction ==

When you have made an API macro and want to place it with a program like Airport for Windows or FSSC you will often see the shape of the object on the screen. But for some object there is no shape or it is not accurate enough. This is because the object symbol is not defined correctly. In this article I will explain how you can modify the object symbol.

== Code Example ==

The position of the object symbol should be at the top of the API macro, before any of the actual code of the object. Below you see an example of an object symbol.

<PRE>
mif( 0 )
; displays airport symbol
Area( 5 %1 %2 1 )
RotatedCall( :symbol 0 0 %5 )
Jump( :endsymbl )
:symbol
RefPoint( 7 : 0.5 %1 %2 )
Points( 0
-5 0 -5
-5 0 5
5 0 5
5 0 -5 )
Poly( a 0 1 2 3 )
Return
:endsymbl
EndA
mifend
</PRE>

Let's explain what each segment of the code does.

The first command is just the SCASM conditional check. And because there are no arguments attached to it, it will always fail. This means that when compiling this code nothing of it will end up in the BGL you make. It is only used by programs like FSSC.

Following this check you will find the Area and RotatedCall command. This last command is needed to let the symbol rotate when you enter a heading while placing the object.

The next important command is the RefPoint command. The parameter 0.5 is the scale that is used in the rest of the code to define the symbol. If you want to have a symbol that is very accurate you might want to use a lower scale, because now the smallest distance that can be displayed is 0.5 meter. In general this will be enough for a symbol though.

The next command is the point list. In here you need to define all points that you need to define your symbol. In this example I just defined a box of 5x5 meter.

The last command is the Poly command, this draws the actual symbol defining the points that are used. In this case a line is drawn from point 0 to point 1, 2, 3 and then back to point 0. For more complex symbols you might need to use more then one Poly command.

== Example ==

Below you find the example code and a picture of how a more complex symbol could look like. In this case a bigger scale was used for the symbol, because the entire object had been designed for a scale of 0.1.

<PRE>
mif( 0 )
Area( 5 %1 %2 1 )
RotatedCall( :symbol 0 0 %5 )
Jump( :endsymbl )
:symbol
RefPoint( 7 : 1 %1 %2 )
Points( 1
-4 0 -111
1 0 -111
1 0 112
-4 0 112
0 0 -111
160 0 -111
160 0 112
0 0 112
-84 0 -111
-4 0 -111
-4 0 112
-84 0 112
-69 0 -126
-39 0 -126
-39 0 -111
-69 0 -111
)
Poly( a 1 2 3 4 )
Poly( a 5 6 7 8 )
Poly( a 9 10 11 12 )
Poly( a 13 14 15 16 )
Return
:endsymbl
EndA
mifend
</PRE>

[[Image:Object_symbol.jpg]]

[[Category:Scenery design]]

API macro custom object symbol

2006-10-02T19:33:49Z

Nickw:

Flickering ground polygons fix (SCASM tweak)

2006-10-02T19:33:27Z

Nickw:

== Introduction ==

A scenery that worked fine in Fs2000 sometimes has bleed through problems with the ground polygons. Usually these polygons where then made with a program like FSDS. This is because such programs use SCASM code that is meant for 3D objects and when this code is used for ground polygons the scenery engine gets confused.
The fix for the problem is then also to change the SCASM code used to the one for ground polygons. How to do this will be explained in the rest of this document.

== Simple API ==

For a simple API, that is a API that only contains a ground polygon and nothing else, the following changes must be made.

This is an example of the code as FSDS makes it:
<PRE>
Area( 5 %1 %2 %3 )
IfVarRange( :Exit 0346 %12 5 )
PerspectiveCall( :PCall )
ShadowCall( :PC02 )
Jump( :Exit )
:PCall
Perspective
:PC02
mif( %11 )
RefPoint( 2 :Skip %4 %1 %2 E= %11 v1= %10 V2= 400 )
melse
RefPoint( 7 :Skip %4 %1 %2 v1= %10 v2= 400 )
mifend
RotatedCall( :B 0 0 %5 )
Return
:B
Call32( :Part0 )
:Skip
Return
:Exit
Jump32( :End )
;
; Part: Polygon
:Part0
Points( 0
0 0 100 ; 0
100 0 0 ; 1
0 0 -99 ; 2
-99 0 0 ; 3
)
;RGBSColor( ef 121 121 121 )
Dwx( 2d ) ; color command
Dbd( 121 ) ; red
Dbx( ef ) ; flag/transparency
Dbd( 121 ) ; green
Dbd( 121 ) ; blue
Poly( 0 32767 0 0.00 0 1 2 3 )
Return
:End
EndA
</PRE>

To get the SCASM code for ground polygons the PerspectiveCall and the ShadowCall should be replaced by a LayerCall. The beginning of the changed API looks like this:
<PRE>
Area( 5 %1 %2 %3 )
IfVarRange( :Exit 0346 %12 5 )
;PerspectiveCall( :PCall )
;ShadowCall( :PC02 )
LayerCall( :PC02 8 )
Jump( :Exit )
;:PCall
;Perspective
:PC02
mif( %11 )
RefPoint( 2 :Skip %4 %1 %2 E= %11 v1= %10 V2= 400 )
melse
RefPoint( 7 :Skip %4 %1 %2 v1= %10 v2= 400 )
mifend
RotatedCall( :B 0 0 %5 )
Return
:B
</PRE>

In the above code I have commented out the PerspectiveCall and ShadowCall commands, as these are not needed. Also the Perspective command has been commented, because this command is obsolete since Fs2000.
After the ShadowCall I have added the LayerCall, the same label where the ShadowCall refered to is used for the LayerCall and the next parameter is the layer number, 8 in this example. This layer number can of course be changed if another layer is needed in the scenery.

== Complex API ==

For a more complex API the principles are the seem, but in such a macro also other object code is there which should not get a LayerCall. Therefore we need to have both a PerspectiveCall and a LayerCall.

Here is an example of such a code from FSDS:
<PRE>
Area( 5 %1 %2 %3 )
IfVarRange( :Exit 0346 %12 5 )
PerspectiveCall( :PCall )
ShadowCall( :PC02 )
Jump( :Exit )
:PCall
Perspective
:PC02
mif( %11 )
RefPoint( 2 :Skip %4 %1 %2 E= %11 v1= %10 V2= 500 )
melse
RefPoint( 7 :Skip %4 %1 %2 v1= %10 v2= 500 )
mifend
RotatedCall( :B 0 0 %5 )
Return
:B
Call32( :Part0 )
Call32( :Part1 )
Call32( :Part2 )
:Skip
Return
:Exit
Jump32( :End )
;
; Part: Polygon
:Part0
Points( 0
0 0 100 ; 0
100 0 0 ; 1
0 0 -99 ; 2
-99 0 0 ; 3
)
;RGBSColor( ef 121 121 121 )
Dwx( 2d ) ; color command
Dbd( 121 ) ; red
Dbx( ef ) ; flag/transparency
Dbd( 121 ) ; green
Dbd( 121 ) ; blue
Poly( 0 32767 0 -0.00 0 1 2 3 )
Return
;
; Part: Box
:Part1
Points( 0
75 0 -24 ; 0
75 50 -24 ; 1
125 50 -24 ; 2
125 0 -24 ; 3
75 0 25 ; 4
75 50 25 ; 5
125 50 25 ; 6
125 0 25 ; 7
)
;RGBSColor( ef 121 121 121 )
Dwx( 2d ) ; color command
Dbd( 121 ) ; red
Dbx( ef ) ; flag/transparency
Dbd( 121 ) ; green
Dbd( 121 ) ; blue
Poly( 0 0 -32767 25.00 0 1 2 3 )
Poly( 0 0 32767 25.00 7 6 5 4 )
Poly( -32767 0 0 -75.00 5 1 0 4 )
Poly( 32767 0 0 125.00 2 6 7 3 )
Poly( 0 32767 0 50.00 5 6 2 1 )
Poly( 0 -32767 0 0.00 0 3 7 4 )
Return
;
; Part: Box.1
:Part2
Points( 0
-124 0 -24 ; 0
-124 50 -24 ; 1
-74 50 -24 ; 2
-74 0 -24 ; 3
-124 0 25 ; 4
-124 50 25 ; 5
-74 50 25 ; 6
-74 0 25 ; 7
)
;RGBSColor( ef 121 121 121 )
Dwx( 2d ) ; color command
Dbd( 121 ) ; red
Dbx( ef ) ; flag/transparency
Dbd( 121 ) ; green
Dbd( 121 ) ; blue
Poly( 0 0 -32767 25.00 0 1 2 3 )
Poly( 0 0 32767 25.00 7 6 5 4 )
Poly( -32767 0 0 125.00 5 1 0 4 )
Poly( 32767 0 0 -75.00 2 6 7 3 )
Poly( 0 32767 0 50.00 5 6 2 1 )
Poly( 0 -32767 0 0.00 0 3 7 4 )
Return
:End
EndA
</PRE>

In this case Part0 is the ground polygon and Part1 and Part2 are the 3D parts of the object.

The corrected code now looks like this:
<PRE>
Area( 5 %1 %2 %3 )
IfVarRange( :Exit 0346 %12 5 )
LayerCall( :L 8 )
PerspectiveCall( :PC02 )
ShadowCall( :PC02 )
Jump( :Exit )
:PCall
;Perspective
:PC02
mif( %11 )
RefPoint( 2 :Skip %4 %1 %2 E= %11 v1= %10 V2= 500 )
melse
RefPoint( 7 :Skip %4 %1 %2 v1= %10 v2= 500 )
mifend
RotatedCall( :B 0 0 %5 )
Return
:B
Call32( :Part1 )
Call32( :Part2 )
Return
:L
mif( %11 )
RefPoint( 2 :Skip %4 %1 %2 E= %11 v1= %10 V2= 500 )
melse
RefPoint( 7 :Skip %4 %1 %2 v1= %10 v2= 500 )
mifend
RotatedCall( :B2 0 0 %5 )
Return
:B2
Call32( :Part0 )
:Skip
Return
:Exit
Jump32( :End )
</PRE>

Here I copied the structure and the RefPoint information from the PerspectiveCall part and also used that for the LayerCall part. The actual LayerCall is at the top and it calls the code at the bottom. I hope you can spot the differences between the origional and the changed source and that is enough for you to be able to do the same.

[[Category:Scenery design]]

Flickering ground polygons fix (SCASM tweak)

2006-10-02T19:32:57Z

Nickw:

File:Object symbol.jpg

2006-10-02T19:29:59Z

Nickw:

API macro custom object symbol

2006-10-02T19:29:46Z

Nickw:

Non-bumpy taxiways (SCASM tweak)

2006-10-02T19:13:49Z

Nickw:

== Introduction ==

The bumpy taxiways with the clouds of dust behind your wheels are probably familiar to you. One of the solutions that is offered on the internet is adding an invisible runway to your scenery. I don't think this is a very elegant way to solve the problem and there even is a better solution. SCASM does have the command SurfaceType to define the type of surface for a scenery.

== Command to smooth surface ==

This command can be used to create a smooth surface with the following code:
<PRE>
Header( 1 53.3 50.9 6.9 4.3 )
LatRange( 53.3 50.9 )

Area( 5 52.307832 4.765108 20 )

RefPoint( 7 : 1 52.307832 4.765108 v1= 20000 )
SurfaceType( 0 8000 8000 0 )
EndA
</PRE>

This example is a piece of code for Schiphol in the Netherlands. To apply the code to your own scenery you must do the following.

First change the coordiantes in the Header and LatRange commands so that they define the boundary of your own area. Note: if you want to add more airfields to the file, the boundaries should be around all of them.

The next step is to make an Area block for each airfield. Just enter the coordinates of your airfield in the Area and RefPoint commands. Then the SurfaceType command defines a polygon that is smooth. In this example the polygon is 8000 by 8000 meters. You can of course change this to meet your own airfields size.

You must repeat this block for every airfield you want to make smooth. Then save the source code and compile it using SCASM. Now you have a separate BGL that removes the bumps!

If you want the smooth polygon to have the exact shape of the polygons of your airport, you must add a SenseBorder command to check the location of the aircraft. This way you can keep the grass on your airport bumpy, while the taxiways and aprons are smooth. I have made a tool that can generate such code automatically for you. You can find more information about it here.

[[Category:Scenery design]]

Effect placement (SCASM)

2006-10-02T19:09:57Z

Nickw:

A very easy way to place effect files in your scenery using SCASM. In the new SCASM this command is mentioned:

<PRE>
GObj( EFFECT "string1" "string2" )
</PRE>

The use of the different strings is not documentated, but after some trial and error I found that the first string is the name of the effect file (eg. Nova_smoke_one.fx). The second string are additional parameters that can be passed to the effect. If you for example enter MOY=1:6;DOM=1 then the effect will only be visible on the first day of the first 6 months of the year. For more details see the file "Effects Parameters.txt" that is part of the Effects SDK. If you want no additional parameters you can just enter 0 for the string.

All other parameters for the effect file that can be specified in the BGLPlacer tool from the SDK (latitude, longitude, etc) can be specified in SCASM using the normal way (in the RefPoint for example).

This makes it very easy to add an effect to your macro. No need anymore to make a separate macro for the effect or even a seperate BGL using BGLPlacer.

'''Tip:''' Don't forget the Set( fsvers 0x800 ) command in your SCASM source that tells SCASM to use the Fs2002 code, otherwise you will get an error.

[[Category:Scenery design]]

Conditional display (SCASM tweak)

2006-10-02T19:09:40Z

Nickw:

== Introduction ==

With some design programs it is not possible to specify conditions for the display of your objects (or parts of them). But how about the lights that should only be shown at night or the Christmas tree that should be displayed only in December? With a relatively simple modification to the source code it is possible to display the object only when you want it. The structure of the code is as follows:
<PRE>
IfVarRange( :labelname var con1 con2 )
; the code you want only to display in the certain condition
:labelname
</PRE>

== Examples ==

You probably think now that such code is nice, but what do you do with it? Here are some practicle examples how you can use it.

=== Image Complexity ===

If you want your object only to display at a certain image complexity setting you can use the IfVarRange command to display the object only at the settings you want. To do this you need to find the Area command at the begin of your object. This could look something like this:
<PRE>
Area( 5 %1 %2 22 )
PerspectiveCall( :Obj )
ShadowCall( :Obj )
</PRE>
Now at the following line to this code:
<PRE>
Area( 5 %1 %2 22 )
IfVarRange( : 346 3 5 )
PerspectiveCall( :Obj )
ShadowCall( :Obj )
</PRE>
Here a check is made if the variable 346, which is the image complexity setting, is between 3 (dense) and 5 (extremely dense). If that is true the code below it is displayed, if not a jump is made to the label :. This label is a special label that will take you to the end of the file right away.

=== Time of day ===

Another example is where you want to display a certain object only at a certain time of day. Here is a piece of code that displays a light dot:
<PRE>
RGBLColor( EF 195 195 195 )
Dot( 0 10 0 )
</PRE>
To make sure that the dot is only displayed at dusk/dawn and night you can add the following lines:
<PRE>
IfVarRange( :nolight 28C 2 4 )
RGBLColor( EF 195 195 195 )
Dot( 0 10 0 )
:nolight
</PRE>
In this case the variable for time of day (28C) is checked. If the value is between 2 (dusk/dawn) and 4 (night) the light is displayed, otherwise a jump to the label nolight is made.

[[Category:Scenery design]]

Conditional display (SCASM tweak)

2006-10-02T19:08:45Z

Nickw:

Effect placement (SCASM)

2006-10-02T19:03:53Z

Nickw:

Drawing order problems with transparent textures

2006-10-01T20:38:29Z

Nickw: /* Texture types */

== Introduction ==

[[Image:boxcorrect.jpg|200px|Figure 1 - Correct]] [[Image:boxincorrect.jpg|200px|Figure 1 - Incorrect]]

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==
[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]
Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==
[[Image:fig4-trans.jpg||left|thumb|Figure 4 - Behaviour of different texture types]] [[Image:fig5-trans.jpg||right|thumb|Figure 5 - Behaviour of different texture types (cont)]]
The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

Drawing order problems with transparent textures

2006-10-01T20:38:02Z

Nickw: /* Texture types */

== Introduction ==

[[Image:boxcorrect.jpg|200px|Figure 1 - Correct]] [[Image:boxincorrect.jpg|200px|Figure 1 - Incorrect]]

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==
[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]
Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.
[[Image:fig4-trans.jpg||left|thumb|Figure 4 - Behaviour of different texture types]] [[Image:fig5-trans.jpg||right|thumb|Figure 5 - Behaviour of different texture types (cont)]]

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

File:Fig5-trans.jpg

2006-10-01T20:37:19Z

Nickw:

File:Fig4-trans.jpg

2006-10-01T20:36:46Z

Nickw:

Drawing order problems with transparent textures

2006-10-01T20:36:37Z

Nickw: /* Texture types */

== Introduction ==

[[Image:boxcorrect.jpg|200px|Figure 1 - Correct]] [[Image:boxincorrect.jpg|200px|Figure 1 - Incorrect]]

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==
[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]
Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.
[[Image:fig4-trans.jpg|thumb|Figure 4 - Behaviour of different texture types]] [[Image:fig5-trans.jpg|thumb|Figure 5 - Behaviour of different texture types (cont)]]

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

Drawing order problems with transparent textures

2006-10-01T20:36:13Z

Nickw:

== Introduction ==

[[Image:boxcorrect.jpg|200px|Figure 1 - Correct]] [[Image:boxincorrect.jpg|200px|Figure 1 - Incorrect]]

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==
[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]
Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

[[Image:fig4-trans.jpg|thumb|Figure 4 - Behaviour of different texture types]]
[[Image:fig5-trans.jpg|thumb|Figure 5 - Behaviour of different texture types (cont)]]

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

File:Ehamtopdown.jpg

2006-10-01T20:33:49Z

Nickw:

Drawing order problems with transparent textures

2006-10-01T20:32:53Z

Nickw: /* Drawing order */

== Introduction ==

[[Image:boxcorrect.jpg|200px|Figure 1 - Correct]] [[Image:boxincorrect.jpg|200px|Figure 1 - Incorrect]]

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==
[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]
Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

File:Cubetopdown.jpg

2006-10-01T20:32:13Z

Nickw:

Drawing order problems with transparent textures

2006-10-01T20:31:07Z

Nickw:

== Introduction ==

[[Image:boxcorrect.jpg|200px|Figure 1 - Correct]] [[Image:boxincorrect.jpg|200px|Figure 1 - Incorrect]]

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==

Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

Drawing order problems with transparent textures

2006-10-01T20:29:27Z

Nickw:

[[Image:boxcorrect.jpg|middle|200px|Figure 1 - Correct]] [[Image:boxincorrect.jpg|right|200px|Figure 1 - Incorrect]]
== Introduction ==

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==

Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

Drawing order problems with transparent textures

2006-10-01T20:29:02Z

Nickw:

[[Image:boxcorrect.jpg|200px|Figure 1 - Correct]] [[Image:boxincorrect.jpg|200px|Figure 1 - Incorrect]]
== Introduction ==

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==

Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

Drawing order problems with transparent textures

2006-10-01T20:28:46Z

Nickw:

[[Image:boxcorrect.jpg|right|200px|Figure 1 - Correct]] [[Image:boxincorrect.jpg|right|200px|Figure 1 - Incorrect]]
== Introduction ==

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==

Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

Drawing order problems with transparent textures

2006-10-01T20:27:44Z

Nickw:

[[Image:boxcorrect.jpg|left|Figure 1 - Correct]] [[Image:boxincorrect.jpg|left|Figure 1 - Incorrect]]
== Introduction ==

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==

Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

Drawing order problems with transparent textures

2006-10-01T20:26:59Z

Nickw:

[[Image:boxcorrect.jpg|thumb|middle|Figure 1 - Correct]] [[Image:boxincorrect.jpg|thumb|middle|Figure 1 - Incorrect]]
== Introduction ==

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==

Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

Drawing order problems with transparent textures

2006-10-01T20:26:41Z

Nickw: /* Introduction */

== Introduction ==

[[Image:boxcorrect.jpg|thumb|middle|Figure 1 - Correct]] [[Image:boxincorrect.jpg|thumb|middle|Figure 1 - Incorrect]]

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==

Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

Drawing order problems with transparent textures

2006-10-01T20:26:33Z

Nickw: /* Buffeting of the scenery engine */

== Introduction ==

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==

Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

Drawing order problems with transparent textures

2006-10-01T20:25:30Z

Nickw: /* Buffeting of the scenery engine */

== Introduction ==

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==
[[Image:boxcorrect.jpg|thumb|middle|Figure 1 - Correct]] [[Image:boxincorrect.jpg|thumb|middle|Figure 1 - Incorrect]]
To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==

Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

Drawing order problems with transparent textures

2006-10-01T20:24:27Z

Nickw: /* Buffeting of the scenery engine */

== Introduction ==

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

[[Image:boxcorrect.jpg|thumb|middle|Figure 1 - Correct]] [[Image:boxincorrect.jpg|thumb|middle|Figure 1 - Incorrect]]

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==

Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

Drawing order problems with transparent textures

2006-10-01T20:23:52Z

Nickw: /* Buffeting of the scenery engine */

== Introduction ==

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

[[Image:boxcorrect.jpg|thumb|Figure 1 - Correct]] [[Image:boxincorrect.jpg|thumb|Figure 1 - Incorrect]]

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==

Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

Drawing order problems with transparent textures

2006-10-01T20:23:36Z

Nickw: /* Drawing order */

== Introduction ==

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

[[Image:boxcorrect.jpg|thumb|left|Figure 1 - Correct]] [[Image:boxincorrect.jpg|thumb|left|Figure 1 - Incorrect]]

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==

Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

[[Image:cubetopdown.jpg|thumb|Figure 2 - Top Down View of Cube]]

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

File:Boxincorrect.jpg

2006-10-01T20:22:57Z

Nickw:

File:Boxcorrect.jpg

2006-10-01T20:22:48Z

Nickw:

Drawing order problems with transparent textures

2006-10-01T20:21:39Z

Nickw:

== Introduction ==

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occurred when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed through for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparent textures. You expect to see polygons through your transparent polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red colour and for the outside you have used a green transparent texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the different polygons. The order in which the different polygons are drawn is the order in which they are placed in the BGL File. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our File. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL File before the code of the other polygon.

[[Image:boxcorrect.jpg|thumb|left|Figure 1 - Correct]] [[Image:boxincorrect.jpg|thumb|left|Figure 1 - Incorrect]]

In that case the polygon closest to us is drawn First. The polygon further away is drawn after that and this gives a conflict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==

Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A top-down view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

[[Image:cubetopdown.jpg|thumb|left|Figure 2 - Top Down View of Cube]]

== Transparent textures ==

I hope you understand the principle of the polygon hiding by the scenery engine by now. But you will probably think: What has this to do with my transparent texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparent texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparent texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is fine and it looks like you intended.

For the ¯first drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparent textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯fine. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯Figure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparent windows, so you can look at the interior of the pier (see the passengers waiting for your °flight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the different texture types that can be used in Fs2002 sometimes give different results. This will be discussed in this section.

To see this effect I have applied two different textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in Figure 4 and Figure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

Drawing order problems with transparent textures

2006-10-01T20:16:50Z

Nickw:

== Introduction ==

Maybe you started making sceneries before Fs2000 was there? Then you will surely remember how much time it could take to get rid of all those irritating bleed through problems that occured when making a complex object. With the introduction of Fs2000 this problem was solved because the scenery engine now eliminates these bleed throughs for you. But a side effect of this nice new feature is that you sometimes run into trouble when using transparant textures. You expect to see polygons through your transparant polygon, but you look right into nothing. This problem appears relatively often in the scenery design forums and I have the feeling that a lot of people do not understand the underlaying principles that cause it. In this tutorial I'll try to explain where these problems come from and how you can solve them.

== The problem ==

OK, before we start talking about how to solve the problem, let's first get clear what the problem actually is. Assume you want to make a cube. You have painted the inside with a nice red color and for the outside you have used a green transparant texture. Then you would expect the result to be as the left picture in Figure 1, but too often the result looks more like the right one. How can this happen?

== Buffeting of the scenery engine ==

To understand where the problem comes from we have to look at how the scenery engine draws the di®erent polygons. The order in which the di®erent polygons are drawn is the order in which they are placed in the BGL ¯le. So the scenery engine just reads through the BGL and displays the polygons in the order they are found. So assume we have two polygons in our ¯le. One is 50 meter ahead of us and the other is 100 meter ahead of us. Let's also assume that the code of the the polygon closest to us is in the BGL ¯le before the code of the other polygon.

[[Image:boxcorrect.jpg|thumb|left|Figure 1 - Correct]] [[Image:boxincorrect.jpg|thumb|left|Figure 1 - Incorrect]]

In that case the polygon closest to us is drawn ¯rst. The polygon further away is drawn after that and this gives a con°ict. Before Fs2000 this would give a bleed through problem, because a polygon further away is drawn over a polygon closer to us and therefore the order on the screen is wrong.

Since Fs2000 a new feature has been build into the scenery engine that check for these sort of problems and that hides the part of polygon that is further away if it would display over a polygon closer to us. Therefore we don't have those bleed through problems anymore.

== Drawing order ==

Let's assume we have a cube. I'll only consider the four side polygons here. We will call them polygon A, B, C and D from now on. All these polygons are drawn double sides, so they all have an inner and an outer face. I'll call them Ai, Ao, Bi, Bo, Ci, Co, Di and Do. A topdown view of the situation is given in Figure 2.

Now let's assume that the order of the polygons in the source code is like this: Ai, Ao, Bi, Bo, Ci, Co, Di, Do. This is an order that is often used by scenery design programs. If we look from viewpoint 1 (see the arrow) at the cube the scenery engine will hide some polygons for us, to prevent bleedthroughs. The polygon Ci for example is drawn after Ao has been drawn to the screen. So Ci will be hidden to prevent problems.

But when we look from viewpoint 2 you'll see that there are no problems, as Ai is drawn before Co, so there is no problem here. If we consider another option for the order like Ai, Bi, Ci, Di, Ao, Bo, Co, Do, then you will see that there are no conflicts in this case and no polygon is hidden for us. But when we would use Ao, Bo, Co, Do, Ai, Bi, Ci, Di then there is a conflict from each drawing angle and all inner polygons are hidden.

[[Image:cubetopdown.jpg|thumb|left|Figure 2 - Top Down View of Cube]]

== Transparant textures ==

I hope you understand the principle of the polygon hidding by the scenery engine by now. But you will probably think: What has this to do with my transparant texture? Well, actually the scenery engine does not know what kind of texture is applied to your polygon and it will still hide polygons to prevent bleed through problems. Let go back to the cube from the previous section and assume we apply a transparant texture to the outside polygons, while the inside polygons are solid.

If the drawing order is like the last example we considered there (Ao, Bo,Co, Do, Ai, Bi, Ci, Di) then you will see that the scenery engine hides all the inner polygon and through your transparant texture on the outer ones you see absolutely nothing. On the order hand if we use the second drawing order (Ai, Bi, Ci, Di, Ao, Bo, Co, Do) then everything is ¯ne and it looks like you intended.

For the ¯rst drawing order (Ai, Ao, Bi, Bo, Ci, Co, Di, Do) you should by now understand that from viewpoint 2 everything looks like you intended, but from viewpoint 1 you look into nothing again. This shows that the drawing order is really important to prevent problems when you use transparant textures. The general rule is:

''Draw to polygons of the inside before you draw the polygons of the outside''

For most simple objects this works ¯ne. Although it is not always very easy to achieve in scenery design programs. Unfortunately most do not have an option to control the drawing order directly (I believe NOVA is an exception there). So it might require some hand editing of the SCASM (or BGLC) source to get the required results. I will not discuss it in great detail here, but assume you have a really complex object like the terminal of Schiphol I have made. A top down view of a piece of one of the piers is given in ¯gure 3.

[[Image:ehamtopdown.jpg|thumb|left|Figure 2 - Top down view of a pier at EHAM]]

In the current version of the Schiphol scenery this terminal has been made with transparant windows, so you can look at the interior of the pier (see the passengers waiting for your °ight for example) and you can look through it and see what happens on the other side of it. Let's have a closer look at the head of the pier. We will only look at the four polygons named A, B, C and D. And just like the cube before they have an inner and an outer side (Ai, Ao, Bi, Bo, Ci, Co, Di, Do). If we look from
direction 1 (see the arrow) then the optimal drawing order would be: Do, Di, Ci, Co, Bo, Bi, Ai, Ao. But if we look from direction 2 then the optimal order is: Ao, Ai, Bi, Bo, Co, Ci, Di, Do. It is clear that it is not possible to create one drawing order that can satisfy both of these conditions. In this case we would need to make the drawing order dependant on the viewing angle. The SCASM command VectorJump can be used to do this. I will not give more details about how this has been done here1. But I just wanted to indicate with this example that for complex objects it is not always possible to ¯nd one certain correct drawing order.

== Texture types ==

The theory above is always valid, but it has been reported that the di®erent texture types that can be used in Fs2002 sometimes give di®erent results. This will be discussed in this section.

To see this e®ect I have applied two di®erent textures to a cube with a wrong drawing order, one has a semi transparant piece, while the other has a completely transparant piece. The result for the di®erent formats that can be found in ImageTool and support an alpha channel have been given in ¯gure 4 and ¯gure 5.

It is interesting to see that for all textures with a 1 bit alpha channel the problem doesn't appear anymore. So it seems that Fs2002 has an extra feature compared to Fs2000 that prevents the transparancy problem. But for a semi-transparant texture the problem happens all the time. It should be noted that having the correct drawing order will prevent the problem in any case, althought for a 1 bit alpha channel choosing the correct texture format might be a faster way to solve the problem.

Notes:
² For the 8 bit image ImageTool corrupted the alpha channel for the fully transparant texture, this caused it to have also some gray tints and should probably explain the results for it.
² For the DXT 1 image the semi transparant texture is equivalant to the transparant one, because that format only has a 1 bit alpha channel. Therefore the results are also the same.
² For the DXT 3 texture with a 1 bit alpha channel something really strange happens, here the complete texture isn't visible anymore. At the moment I have no clue what is the cause of this e®ect.
² The 555 also has a 1 bit alpha channel like the DXT 1 format, but at DXT 1 my gray color for the semi transparant texture became black, where at 555 one dot became white and the neighbour became black. This explains the di®erent look, but also that the result is still rather OK.

== Comments? ==

I hope this tutorial has helped you in understanding where the problems withtransparant textures come from. But if you still have a question, a comment or a suggestion, please don't hesitate to contact me. You can ¯nd me on the AvSim scenery design forum under the nick arno or mail me at arno@nl-2000.com

File:Season12.jpg

2006-10-01T19:41:52Z

Nickw:

File:Season11.jpg

2006-10-01T19:41:43Z

Nickw:

File:Season10.jpg

2006-10-01T19:41:32Z

Nickw:

File:Season9.jpg

2006-10-01T19:41:19Z

Nickw:

File:Season8.jpg

2006-10-01T19:41:10Z

Nickw:

File:Season7.jpg

2006-10-01T19:41:01Z

Nickw:

File:Season6.jpg

2006-10-01T19:40:51Z

Nickw:

File:Season5.jpg

2006-10-01T19:40:40Z

Nickw:

File:Season4.jpg

2006-10-01T19:40:30Z

Nickw:

File:Season3.jpg

2006-10-01T19:40:17Z

Nickw: