Paavo
Resource contributor
- Messages
- 192
- Country
Hi,
I'm currently working on EEPU scenery. The airport is situated diagonally and at some places trees are quite near to some parts of the apron. I use FS2002-style ground polys for custom ground textures. They are known for creating autogen-free areas around them. In FS2004 and FSX (up to SP1 if I'm correct) there was a solution: placing a dummy RotatedCall command. This hack does not work in FSX SP2.
I've searched through various discussion boards and the only suggestion I found was splitting the ground poly into smaller (say, 100x100m) chunks. Due to the layout of EEPU, I'd have to use 22 polys to get the result. This means 22 polys that need to be cut out and placed precisely.
Well, it seemed like a lot of work. Perhaps there is a way around, I thought. And indeed - there seems to be one more undocumented bug, which can be used to shift autogen-free zone away from the ground poly. EEPU is few kilometers from the sea, so I can easily shift the autogen-free zone onto the sea and retain autogen trees around EEPU.
FSX excludes all autogen objects in a north-facing bounding box, which covers the whole object. Size of the bounding box does not depend on refpoint or any other values; it is calculated based on vertex list.
However, there is a bug.
When vertice are shifted, say, 100m southwards, the bounding box (and thus autogen-free area) is shifted north. The same seems to apply for other directions - autogen-free zone is shifted to the opposite direction.
Here's an image showing the described hack in action:
And here's the source code:
I'm now going to work on the actual ground layout of EEPU to see if this approach is indeed practical.
I'm currently working on EEPU scenery. The airport is situated diagonally and at some places trees are quite near to some parts of the apron. I use FS2002-style ground polys for custom ground textures. They are known for creating autogen-free areas around them. In FS2004 and FSX (up to SP1 if I'm correct) there was a solution: placing a dummy RotatedCall command. This hack does not work in FSX SP2.
I've searched through various discussion boards and the only suggestion I found was splitting the ground poly into smaller (say, 100x100m) chunks. Due to the layout of EEPU, I'd have to use 22 polys to get the result. This means 22 polys that need to be cut out and placed precisely.
Well, it seemed like a lot of work. Perhaps there is a way around, I thought. And indeed - there seems to be one more undocumented bug, which can be used to shift autogen-free zone away from the ground poly. EEPU is few kilometers from the sea, so I can easily shift the autogen-free zone onto the sea and retain autogen trees around EEPU.
FSX excludes all autogen objects in a north-facing bounding box, which covers the whole object. Size of the bounding box does not depend on refpoint or any other values; it is calculated based on vertex list.
However, there is a bug.
When vertice are shifted, say, 100m southwards, the bounding box (and thus autogen-free area) is shifted north. The same seems to apply for other directions - autogen-free zone is shifted to the opposite direction.
Here's an image showing the described hack in action:

And here's the source code:
Code:
Set( LINBUF 10240 )
Set( BUF 6000 )
Set( AREAMX 512 )
Header( 1 N58:25:49.58 N58:24:15.57 E024:28:05.69 E024:28:05.69 )
LatRange( N58:24:15.57 N58:25:49.58 )
Area( C N58:24:47 E024:28:29 100 )
LayerCall( :refpoint 8 )
Jump32( : )
:refpoint
RefPoint( rel :skip 0.50 N58:24:47 E024:28:29
V1= 10000 V2= 0 )
Call( :obj )
:skip
Return
:obj
BGLVersion( 0800 )
MaterialList( 0
; material 0
0.839 0.898 0.651 1.000 ; diffuse color
0.839 0.898 0.651 1.000 ; ambient color
0.000 0.000 0.000 1.000 ; specular color
0.000 0.000 0.000 1.000 ; emissive color
0.000 ; specular power
)
VertexList( 0
-50.000 0.000 -250.000 0.000 1.000 0.000 0.000 1.000 ; vertex 0
-50.000 0.000 -350.000 0.000 1.000 0.000 0.000 0.000 ; vertex 1
50.000 0.000 -250.000 0.000 1.000 0.000 1.000 1.000 ; vertex 2
50.000 0.000 -350.000 0.000 1.000 0.000 1.000 0.000 ; vertex 3
)
SetMaterial( 0 -1 )
DrawTriList( 0
2 1 3 ; 0
1 2 0 ; 1
)
EndVersion
Return
EndA
I'm now going to work on the actual ground layout of EEPU to see if this approach is indeed practical.
Last edited: