FSX Effects in wrong place?

#41
Hi Arno,

I've double checked the position and it is correct.

I did notice that after I click the add position button, enter the lat/lon and click close, if I then go back into the object information option the lat/lon values both appear as zero. Is this just a display issue or are the values not getting set ( or am I entering them wrong :) ). Im using the values 52.4473820 and -1.7374142 respectively.

Cheers

Phil
 
#44
Hello:

I thought it might be helpful to this discussion to post an explanation of some terms and concepts related to decimal places and 32-bit (aka "single precision") versus 64 bit (aka "double precision") floating point numbers:

http://en.wikipedia.org/wiki/Single...rom_decimal_representation_to_binary32_format


NOTE: I found this section particularly interesting:


"IEEE 754 single precision binary floating-point format: binary32

The IEEE 754 standard specifies a binary32 as having:

* Sign bit: 1 bit
* Exponent width: 8 bits
* Significand precision: 24 (23 explicitly stored)

Sign bit determines the sign of the number, which is the sign of the significand as well. Exponent is either an 8 bit signed integer from −127 to 128 or an 8 bit unsigned integer from 0 to 255 which is the accepted biased form in IEEE 754 binary32 definition. For this case an exponent value of 127 represents the actual zero.

The true significand includes 23 fraction bits to the right of the binary point and an implicit leading bit (to the left of the binary point) with value 1 unless the exponent is stored with all zeros. Thus only 23 fraction bits of the significand appear in the memory format but the total precision is 24 bits (equivalent to log10(224)
≈ 7.225 decimal digits)."




http://en.wikipedia.org/wiki/Double_precision_floating-point_format


BTW: I also found this section particularly interesting:

"Double precision binary floating-point format

Double precision binary floating-point is a commonly used format on PCs, due to its wider range over single precision floating point, even if at a performance and bandwidth cost. As with single precision floating point format, it lacks precision on integer numbers when compared with an integer format of the same size. It is commonly known simply as double. The IEEE 754 standard defines a double as:

* Sign bit: 1 bit
* Exponent width: 11 bits
* Significand precision: 53 bits (52 explicitly stored)

The format is written with the significand having an implicit integer bit of value 1, unless the written exponent is all zeros. With the 52 bits of the fraction significand appearing in the memory format, the total precision is therefore 53 bits (approximately 16 decimal digits, 53\log_{10}(2) \approx 15.955).
"


All that linked above being intriguing, I was compelled to chase this link as well: ;)

http://en.wikipedia.org/wiki/IEEE_754-2008

(IEEE Standard for Floating-Point Arithmetic)


Hmmm... I'd hate to have to express numbers in Scientific Notation rather than decimal number format to get accurate results from the FS SDK ! :eek:


Hope this helps ! :)


GaryGB
 
Last edited:

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#45
Hi Gary,

Single precision can indeed easily lead to trouble, especially with lat/lon values that need some accuracy. Although I don't think this is really an issue with the offset of effects, since we don't get so far from the reference point.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#46
Hi,

Can any of you send me an object to test with? I want to double check with more than one object.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#47
Hi,

I tested it again at different locations, but for the object I use now the correction always makes sure that the effect is placed where it should be again. So I am looking forward to seeing some objects where it doesn't help.
 
#50
I also noticed that the correction is not perfect.

A. The effects still are of in the length position. The further away when the distance to the 0-pos. increases.
B. Of to the left when you view at the effect towards the 0-position.

Like I showed here: http://fsdeveloper.com/forum/showpost.php?p=232123&postcount=17 , only A is better now (much better then before ;) ), i would say B is still the same.

Here are my values for the placement:
Code:
   <SceneryObject
      lat="51.2786727784231"
      lon="6.75003488045348"
      alt="0.0M"
      altitudeIsAgl="TRUE"
      pitch="0"
      bank="0"
      heading="52.740002"
      imageComplexity="NORMAL">
      <LibraryObject
         name="{d0d7855e-e5c0-459c-9988-257359fd5f6f}"
         scale="1.00"
         />
   </SceneryObject>
and the two files, the corrected one and the normal, see attachments.

PS: Your process flips the z and y axis of the attachpoint.
 

Attachments

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#52
Hi,

Just a though I had. When you place your object do you give it an additional rotation? I think that will conflict with the correction.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#54
OK, Phil, that is good to know. Because when I rotate them afterwards (I just tested) there is a still an offset. So to apply the offset correctly you would need to account for the rotation before hand.

I feel this correction can end up to be quite tricky. Why did MS not just use the same coordinate system for both?
 
#55
Agreeed Arno, it seems so illogical to have different coordinate systems for objects and effects. If you cracked this though it would be of huge benefits to a number of developers.

There must be some alogirithm that is dependent on distance from the refernece point
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#56
Hi,

I think the algorithm I have now works OK, as long as the user does not rotate the MDL when placing it. And of course you need to specify the lat/lon to the correction.

I am still looking at the issues Phil reported, because there still seems to be some offset without rotation.
 
#57
hm, ok Arno. Of course i roatetet the Object when i placed the MDL (about 52,74°), cause if roatate it in GMAX it gives me bad crash boxes as you know.

Ill will roatate it in Gmax now, but if you know a solution to that in you algorithm, that would be cool!

Thx again
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#58
Hi Max,

I think it is hard to get everything the way we would like it. With this kind of tweaking and corrections that is almost impossible. So when you perform the correction it will only work for one specific heading. I think it would be easier to first rotate the object in GMax/3DS Max/ModelConverterX, but maybe I can let the algorithm do so as well.

Still it will be quite annoying and a lot of tweaking to get everything OK.

I guess a better tip for most people would be to add effects only close to the reference point, since the error is small than. So for a system like your approach lights, it might be easier to split it up in different effects.
 
#59
yeah, i also think that i will splitt them up. The good effect it would have is that i can use some parts 4 times, so for each runway the same. May result in better performance.

PS:
So when you perform the correction it will only work for one specific heading.
I think that would be normal for the use of this tweak/tool. Cause when you have such big objects with effects far away from the reference point, you would only have them ones. Like in EDDL i have the approach lights, the Apron Lights and the Terminal that suffers from this effects. All are single objects that are used ones.
 
Last edited:
#60
Hello:

As a followup on my post above http://www.fsdeveloper.com/forum/showpost.php?p=239339&postcount=33, I found this interesting information which led me to further wonder what might be the best "projection" format to use for background imagery when 3D modeling:

"...a projected coordinate system (UTM, national grid, stateplane, etc.) is preferred over a geographic coordinate system (latitude-longitude). This is because pixel dimensions vary with latitude in geographically projected data."

http://www.google.com/support/mapcontentpartners/bin/answer.py?answer=144284


GaryGB
 
Top