Lat/Lon Conversion + Grass alpha mask problem

[Amengol]

Hi all,

I would like to know how to convert the format for Latitude/Longitude that is in the .asm files (FS2002 gamepack).

i.e:
For the coord S14* 48.93786 W39* 1.95786 a get in the .asm this line:

dd 0FFE6E07Ah,0E43E538Dh ; latitude,longitude

I tried to convert from hexadecimal to decimal and the results were 4293320826, 3829289869. So ???
I want this because I'm having some discrepancies using the same coords in the FSX Gamepack and FS2002 Gampepack. The objects seem to be a little offset.

 

[arno]

Hi,

The FS2000 SDK lists that they are 48 bit pseudodegrees. So from that I would expect that that if you divide them by the maximum value of a 48 bit signed integer, you get the coordinates in the range of -1.0 to 1.0. Then you can multiply that by 180 or 90 to get the proper degrees.

I remember reading more somewhere else, but I forgot where at the moment.

Also, what kind of objects do you see these offsets for? If you have FS2002 ground polygons that cover a big area, the curvation of the earth might cause these problems.

 

[Amengol]

Hi,

The FS2000 SDK lists that they are 48 bit pseudodegrees. So from that I would expect that that if you divide them by the maximum value of a 48 bit signed integer, you get the coordinates in the range of -1.0 to 1.0. Then you can multiply that by 180 or 90 to get the proper degrees.

I remember reading more somewhere else, but I forgot where at the moment.

Also, what kind of objects do you see these offsets for? If you have FS2002 ground polygons that cover a big area, the curvation of the earth might cause these problems.

Hi Arno,

I'll try some calculation fallowing your directions and see if I get something. I'll post the results.

The object is a grass edge of an asphalt border, and is quite big indeed. The asphalt was made using FS2002 GP, but the grasses, because the alpha channel, I was trying to do with FSX GP. With the fs2002 I got the taxi objects (made in FSX) hidden behind the border of the alpha channel. What suggestion would you propose in this case?

Thank you for helping.

 

[arno]

Hi,

If you whole FS2002 grass is in one RefPoint, I think that is why you see small offsets.

If these are cut into pieces, they will follow the curvation of the earth correctly. But there is an inaccuracy in this code that causes the position to get an error that increases with the distance from the reference point. It is a floating point error (resolution of the float decreases with increasing value).

So I think you can assume the FSX MDL is placed correctly, but the ground polygon gets a small error. The best solution is to cut the ground polygon into different pieces, each with their local reference point. That should make sure the error remains small enough.

 

[Amengol]

Hi,

If you whole FS2002 grass is in one RefPoint, I think that is why you see small offsets.

If these are cut into pieces, they will follow the curvation of the earth correctly. But there is an inaccuracy in this code that causes the position to get an error that increases with the distance from the reference point. It is a floating point error (resolution of the float decreases with increasing value).

So I think you can assume the FSX MDL is placed correctly, but the ground polygon gets a small error. The best solution is to cut the ground polygon into different pieces, each with their local reference point. That should make sure the error remains small enough.

Tanks again, Arno.

Look, the only problem using grass with FS2002 GP is the transparency texture borders that hide all others objects behind it. If I could only solve that, the problem would be finished. Do you think I could get any success using some tweaking like ZBIAS command in the ASM files?

BTW, reading the FS2000 GP I figure out how to convert those Hex coords into decimal:

They are signed integer as you mentioned, but 32-bit. North is expressed as meters north of the equator, and east is expressed as 32-bit pseudodegrees east of the prime meridian (100000000h = 360 degrees).

 

[rhumbaflappy]

I hope you don't mind that I moved this thread to BGLC Tweaking, as it pertains to ASM ( BGLC ) rather than SCASM.

Dick

 

[Amengol]

I hope you don't mind that I moved this thread to BGLC Tweaking, as it pertains to ASM ( BGLC ) rather than SCASM.

Dick

No problem at all!

 

[arno]

Hi,

What is the format you are using for the textures? I think you get drawing order problems because the reference point of the objects behind your grass is closer than the reference point of the grass object. In that case the scenery engine thinks the grass should be behind instead of in front of them.

Sometimes using DXT1 textures can solve such trouble.

 

[Amengol]

Hi,

What is the format you are using for the textures? I think you get drawing order problems because the reference point of the objects behind your grass is closer than the reference point of the grass object. In that case the scenery engine thinks the grass should be behind instead of in front of them.

Sometimes using DXT1 textures can solve such trouble.

Yes, I know, but with DXT1 it looks very bad.

I think it is not a drawing order problem. Look at these two screens:

The grass is rendered correct after the aircraft. Right at it should be.

The aircraft is behind the grass and is being hidden by the alpha mask of the grass.

So, I just need to solve this problem to get it all working.


Just a screen of my project (Ground Level yet):

.

 

[arno]

I do think it is a drawing order problem. The grass is also one big file with a single reference point?

What I did once was use DXT1 for a texture, but then double the size. Then the result looked OK and I solved my drawing order problems.

If using DXT1 is not an option, you will have to split the grass up into smaller objects. But that will not be easy either.

 

[Amengol]

I do think it is a drawing order problem. The grass is also one big file with a single reference point?

Yes.

What I don't understand is why it is drawing in the right place. What I mean is, the grass, in the second screen, is drawing in front of the airplane, just because the airplane is indeed behind it. If I remove the alpha mask, it should render perfectly in front of the aircraft, hiding it. Am I wrong to think that a drawing order should be if, even the aircraft is located behind the grass, it appears instead of being hidden by it?

 

[arno]

Hi,

What you see is this (I think).

The aircraft is quite close to you, the reference point of the grass is much further away. That is why FS thinks the grass is also further away than the aircraft. All objects are drawn from back to front so:

• If the aircraft is before the grass, the grass is drawn first and then the aircraft. This makes that everything shows OK.
• If the aircraft is behind the grass, the drawing order is still the same. So first the grass and then the aircraft. But in that case things go wrong as the aircraft is actually behind. While rendering the grass with its alpha channel all objects behind it have been tested to see if they appear through it or not. At that point the aircraft was not yet rendered and therefore it is no dissapearing.

When you use DXT1 as texture format the scenery engine does some extra work to prevent such trouble. For all other formats you have to make sure that the drawing order is OK.

 

[Amengol]

Hi,

What you see is this (I think).

The aircraft is quite close to you, the reference point of the grass is much further away. That is why FS thinks the grass is also further away than the aircraft. All objects are drawn from back to front so:

• If the aircraft is before the grass, the grass is drawn first and then the aircraft. This makes that everything shows OK.
• If the aircraft is behind the grass, the drawing order is still the same. So first the grass and then the aircraft. But in that case things go wrong as the aircraft is actually behind. While rendering the grass with its alpha channel all objects behind it have been tested to see if they appear through it or not. At that point the aircraft was not yet rendered and therefore it is no dissapearing.

When you use DXT1 as texture format the scenery engine does some extra work to prevent such trouble. For all other formats you have to make sure that the drawing order is OK.

Arno, thank you very much for your explanation. Now I understand perfectly.

So, it might work if I make the engine believes that the grass has always the closest reference point? How could I do that?

 

[arno]

That would work, but than the reference point really has to be the closest there is no way to fake that. So that would mean splitting everything up in multiple reference points.

I would try to get DXT1 textures working though, that saves you work. Maybe if you increase the texture size a bit they will look acceptable?

 

[Amengol]

I'll try DXT1 and see the results. I'll post here too.

One more question. What is in the FSX Game pack that makes it show right, even if the grass is just one object?

 

[Amengol]

Hi Arno,

I got it working with FS2002 SDK and gray scale alpha. I’ve simply modified the .asm code with the same command that is used to make ground polys, the ADDCAT (with a layer).

Look:

Also I had to tweak some normals to make it show properly.

Now the question is, in the fallowing code, after the 3 normal parameters, what are those two for?



VERTEX_DEF -1766.712158, 0.096000, -70.264008, 0.000000, 1.000000, 0.000000, -33.500011,0.005977 ; 0 part= 1 prim=0

I'm just curious!

.

 

[arno]

Hi,

One more question. What is in the FSX Game pack that makes it show right, even if the grass is just one object?

There are special options in the FSX material that allow you to control the drawing order better. That way the problem described above can be prevented. But these are in the FlightSimX material, so can't be done with the older gamepacks.

I got it working with FS2002 SDK and gray scale alpha. I’ve simply modified the .asm code with the same command that is used to make ground polys, the ADDCAT (with a layer).

Ah, I guess for low objects like this that should work. Treating buildings as ground polygons can give strange results, but for grass so close to the ground it apparently works. Good find!

Now the question is, in the fallowing code, after the 3 normal parameters, what are those two for?

There are the texture mapping coordinates. So that determines which texture pixel is mapped on this vertex.

 

[Amengol]

There are the texture mapping coordinates. So that determines which texture pixel is mapped on this vertex.

Thank you again, Arno.

Is there a way to change the topic title, just to match what we discuss here? It were much further than the Latitude Longitude conversion. Some like "Lat/Lon Conversion + Grass alpha mask problem (solved)" would be more suitable, don't you think?

Best regards,

Amengol.