FSXA distance controller -> effects at wrong possition

[littleMax]

Hi,

im working on an approachlight system for EDDL and got the effects working and looking good. For the scenario that you fly to the airport i placed extra controllers with distance value at 10000,0.

If I start at the airport the effects show like expected, at the right position and oriantion.
But when i fly to the airport the effects spawn in wrong positions, orientation is correct so far. Intersting is that when i reduce the distance value and so the effects spawn later, the possition is still wrong, but more correct.

To make it mor clear i have two gifs that show this error.

Can somebody explain this or even better help me to fix that?

If you want to test this you can download the file below, it is the scenery with all needed files. The approach light is at EDDL runway 05R. For testing the distance controller just start at EDLN on runway 13 and after teakof fly heading 060.
http://burnbabyburn-clan.de/upload/tom_eddl_ME.rar

IF somebody wants to have a look at the MDL, here it is:
http://burnbabyburn-clan.de/upload/05Rlights.MDL

 

[GaryGB]

Hi Max:

You might wish to review my reply to your post in another related thread regarding your EDDL project:

http://fsdeveloper.com/forum/showpost.php?p=235870&postcount=52


Hope this helps !

GaryGB

 

[GaryGB]

Hi Max:

FYI: It is possible to achieve millimeter-level precision with "XML placement" of Effects; I have done this in rows of Effect lights that are dozens of Meters long (although these were directly placed as "basic" Effects, and did not involve a Controller *.FX file).

However, I'm not sure I understand how having the XML placement BGL "call" a Controller *.FX file rather than a "basic" Effect *.FX file would result in an offset of the displayed Effect itself ?



I'm quoting a post here that I made recently in another thread regarding "precision" placement via sufficient resolution of geo-location by using at least 13 decimal place numbers in LAT-LON coordinates; I believe this merits review when one has FS run-time object placements that have gone awry:

http://fsdeveloper.com/forum/showthread.php?t=18566&page=2

"I have found that it is necessary to use at least 13 decimal places bit depth in Lat-Lon placement to achieve precision results in placement of certain content in FSX.

Interestingly, I have also seen saved flights (in a *.FLT file) which required 14 decimal places to resolve a Start Location with precision.


IMHO, some FS Developers and/or programmers assume that just because most examples shown in the FS SDK docs for ex: XML placement only show 6 to 10 decimal places in their LAT-LON precision, that is an appropriate number of digits to use for coding other FS content output and/or placement scenarios.

This is complicated by use of abbreviated "exponent" format examples (shown in scientific notation) in reference documents or example INFs posted by others on FS web sites... one might not notice the actual precision when scanning posts.


Give me explicit numbers even if they have trailing zeros out to 13 decimal places any day, so I will be less likely to miss something !

Honestly, I don't care if "proper" math formatting would normally 'round off' numbers because decimal places beyond a certain value would be an 'insignificant digit'; I purposely format all my FS spreadsheets to force 13 decimal places... so I will be less likely to miss something when proof-reading tables or ASCII XYZ files, and (in some cases) I'll get better precision outputting certain FS content because I set up the source spreadsheet to allow that extent of precision to begin with. "


BTW: If instead you are 'placing' Effect lights that are "located" in relative proximity to the datum of a 3D model in GMAX using the AttachPoint tool, I'd be uncertain whether one or several factors could influence where Effects end up displayed at run-time in FS.


IIUC, GMAX uses an "offset" calculation to determine location of 3D world XYZ coordinates for AttachPoints; the granularity / precision of scaling or units used in that 3D model may influence accuracy of resulting display of 'attached' Effects in FS.

For example, in FS 3D modeling, there have been scenarios in which it was not possible to achieve certain precise objectives unless the model was originally modeled at 10 to 1000 times the "scale" at which it was intended to be exported for final use in FS.


Additionally, it is also possible that if GMAX export was used to "place" the MDL via BGLComp, XML placement of the model and its 'attached' Effects may not have used ex: at least 13 decimal place numbers in LAT-LON coordinates.

Likewise, if the MDL(s) were compiled into a FS scenery library, subsequent XML placement of the model and its 'attached' Effects via BGLComp may not have used ex: at least 13 decimal place numbers in LAT-LON coordinates.



I'm wondering also if the layout in GMAX of the approach lighting were done on a 'background image' of EDDL, was the background image projected in a "Flat Earth Plane" type of geo-rectified image format ?

http://fsdeveloper.com/forum/showpost.php?p=236106&postcount=33


PS: This does not address geo-locating for the "Round Earth" 3D world model in the FSX run-time environment... as discussed here:

http://fsdeveloper.com/forum/showthread.php?p=238333#post238333


I hope consideration of these possibilities might prove helpful !

GaryGB

 

[arno]

Hi Gary,

I think 13 digits is a bit overkill in most situations. You can calculate that with 8 digits, you are already down to an accurate of about 1 mm. I think most people will not see more accurate then that.

But 6 digits is indeed too little, that will give you an accurate of about 0.1 meter.

 

[GaryGB]

Hi Gary,

I think 13 digits is a bit overkill in most situations. You can calculate that with 8 digits, you are already down to an accurate of about 1 mm. I think most people will not see more accurate then that.

But 6 digits is indeed too little, that will give you an accurate of about 0.1 meter.

Hi Arno:

Sometime I'll have to go back and review my tests done last year with XML placement; IIRC, use of 13 decimal places seemed to result in more precise placement when using FSX SP2 BGLComp.


BTW: Getting precision out of FSX SP2 BGLComp is reportedly an issue:

http://www.simforums.com/forums/instant-scenery-problems_topic39789.html


GaryGB

 

[arno]

Hi Gary,

That post is talking about IS, I don't think IS uses BGLComp to do the placement. It seems to be a discrepancy between the live preview and the compiled BGL.

In the other thread about attached effects having a displacement I just posted by results, they are caused by the different earth models used (flat earth vs geocentric coordinates). It might be something similar affects the placement by IS.

 

[GaryGB]

Hi Gary,

That post is talking about IS, I don't think IS uses BGLComp to do the placement. It seems to be a discrepancy between the live preview and the compiled BGL.

In the other thread about attached effects having a displacement I just posted by results, they are caused by the different earth models used (flat earth vs geocentric coordinates). It might be something similar affects the placement by IS.

Interesting... I now have the impression rounding issues with IS could have been due to use of a proprietary compiler by IS to create placement BGLs, since the content in my "precision placement tests" I wrote about above... was all placed via FSX SP2 BGLComp.

 

[littleMax]

BTW: If instead you are 'placing' Effect lights that are "located" in relative proximity to the datum of a 3D model in GMAX using the AttachPoint tool, I'd be uncertain whether one or several factors could influence where Effects end up displayed at run-time in FS.


IIUC, GMAX uses an "offset" calculation to determine location of 3D world XYZ coordinates for AttachPoints; the granularity / precision of scaling or units used in that 3D model may influence accuracy of resulting display of 'attached' Effects in FS.

For example, in FS 3D modeling, there have been scenarios in which it was not possible to achieve certain precise objectives unless the model was originally modeled at 10 to 1000 times the "scale" at which it was intended to be exported for final use in FS.

As i think, the problem lies in this region.
Cause as seen in the MDL, i used attachpoints->attachpoint tool, their XYZ cordinates are scaled down to 1cm.
What i think is that the capability to draw/place the effects of FSX is decreased when an object is in the distance and the attached effects get loaded.

 

[arno]

Hi,

I doubt scaling is such a big issue. Most objects are placed in FS with scale 1, so that means no additional scaling is done.

I am going to do some more testing tonight about the displaced effects.

 

[littleMax]

ähm i used the wrong words, with "scaled down" i meant the accuracy of the values for the attachpoints.

The important thing realy seems to be the distance from where fsx starts to spawn the effect, and cause i/we increased the distance and the effects are placed via the object and not via XML -> offset

I tested the whole thing with splitted up objects/gmax groups, so i had one mdl for the geometry and four for the attachpoints, of couse the result was -> no offset
(But the overall placement is a littlebit tricky)

 

[arno]

Hi Max,

I think the only issues is that the further you get from the reference point you get an offset. What kind effect, etc has no influence. So of course if you split the effect placement in 4 files (each with their own reference point), the distance to the reference point gets smaller and therefore also the offset.