FSX Effects in wrong place?

[arno]

Hi Gary,

WGS84 latlong is the best for a background. You only need to determine the size of the plane it should be mapped on. I plan to make a wiki tutorial for this soon.

 

[arno]

Hi,

I have made a tutorial about aligning the background image now:

http://www.fsdeveloper.com/wiki/index.php?title=Align_background_image_in_3D_editor

I hope it makes things more clear.

 

[GaryGB]

Hi Arno:

Thanks for the for the tutorial(s) on this important info for FS Developers.

[EDITED]

http://www.fsdeveloper.com/wiki/index.php?title=Align_background_image_in_3D_editor

http://msmvps.com/blogs/arnogerretsen/archive/2011/08/28/coordinate-confusion.aspx

http://msmvps.com/blogs/arnogerretsen/archive/2011/08/29/coordinate-confusion-part-2.aspx

[END_EDIT]



As a followup of my own on this topic... as discussed here:

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


http://www.fsdeveloper.com/forum/showpost.php?p=243033&postcount=60


http://www.fsdeveloper.com/forum/showpost.php?p=236268&postcount=34


...I believe I may have identified the re-projected format which Sketchup uses when grabbing a 1024 x 1024 tile of imagery and/or terrain as a automatically "geo-located" background for modeling.


IIUC, the reported format used to display imagery in Google Earth / Google Maps is Mercator projection / WGS84 datum.

"Geo-located" tiles grabbed via the built-in File > Geo-location > Add Location GUI import into Sketchup appear to be automatically re-projected to General Perspective Projection / WGS84 datum as max 1024 x 1024 background images.



BTW: These links further discuss the projection and datum standards used by Google Earth / Google Maps and Sketchup:


http://www.google.com/support/forum/p/sketchup/thread?tid=2f278661999ef357&hl=en


http://en.wikipedia.org/wiki/Google_Earth#Imagery_and_coordination


http://en.wikipedia.org/wiki/General_Perspective_Projection


http://en.wikipedia.org/wiki/Map_projection



FYI: The following is an example work-flow of how I generated a "geocentric" background image for modeling in Sketchup


Global Mapper 'Workspace': Main Menu > Tools > "Configuration" > [Projection Tab]

Projection: "Orthographic"

Datum: "WGS84"

Planar Units: "Meters"


...Next I re-projected a GeoTIFF of USDA NAIP imagery from Geographic (Latitude/Longitude) / WGS84 / Arc Degrees to:

Projection: "Orthographic"

Datum: "WGS84"

Planar Units: "Meters"


...Then I exported from Global Mapper a GeoTIFF of that re-projected USDA NAIP imagery with these parameter settings:


Main Menu > File > "Export Raster / Image Format" > [GeoTIFF Options Tab]

File Type: 24-bit RGB

Sample Spacing / Scale:

X-axis: "0.3 Meters" <this is set automatically, and may vary with image size>
Y-axis: "0.3 Meters" <this is set automatically, and may vary with image size>


Always Generate Square Pixels: {"Checked"}

[EDITED]

Compression: "(No Compression)" Default (LZW Compression)

< See: http://www.fsdeveloper.com/forum/threads/blend-water-masks.435509/#post-726137 >

[END_EDIT]


[Gridding Tab]

Grid Layout: No Grid (Just One Export File)


[Export Bounds Tab]

All Loaded Data: {"Ticked"}



Global Mapper Overlay Control Center Metadata / Calculations

NUM COLUMNS=2226 <-- (X-axis Lon Pixel span; may vary with image size)

PIXEL WIDTH=0.3 meters <-- (May vary with image size / projection etc.)

2226 * 0.3 meters = 667.8 meters <-- (X-axis span; may vary with image size / projection etc.)


NUM ROWS=2096 <-- (Y-axis LAT Pixel span; may vary with image size)


PIXEL HEIGHT=0.3 meters <-- (May vary with image size / projection etc.)

2096 * 0.3 meters = 628.8 meters <-- (Y-axis "Height" span; may vary with image size / projection etc.)


NOTE: These dimensions: 667.8 meters x 628.8 meters (derived from 'my' particular example image size via a available Global Mapper workspace data set and desktop area dimensions) ...will be drawn as a rectangle onto the 'ground' in Sketchup.


When the above GeoTIFF is imported into Sketchup as a "Image", and 'pinned' to the bottom left corner of that rectangle, the rectangle edges will be used as a guide for precise "sizing" as a background for drawing etc.

The top right corner of the imported and 'pinned' GeoTIFF image will be dragged and scaled until it "snaps to" the endpoint at the top right corner of the rectangle.



But first one must Set Windows Desktop Display properties to at least 1600 x 1200; this allows the Sketchup workspace pixel array to accommodate 2D Graphics at a 'Height' of 1024 pixels; this allows greater legibility of details on-screen while modeling over a background image.


BTW: If Sketchup does a CTD when attempting to import a "larger" background image, see "ADDENDUM in my post immediately below (following this one) :

http://www.fsdeveloper.com/forum/showpost.php?p=244941&postcount=64



...Then:


Sketchup "workspace" configuration

• Sketchup Menu > Window > Preferences > [OpenGL Settings] > Use Maximum Texture Size: {"Ticked"}

• Sketchup Menu > Tools > Select ("Select" tool is the 'Arrow' mouse cursor)

• Sketchup Menu > File > New (...NOTE: Select and 'Delete' / 'Erase' default "person object")

• Sketchup Menu > Camera: Parallel Projection

• Sketchup Menu > Camera > Standard Views > Top

Sketchup Work-flow: "Import" a background image for modeling (using 'my' example image file format and pixel size etc.)


1.) Sketchup Menu > Draw > Rectangle ("Pencil with Rectangle" tool is the mouse cursor)

2.) Hover Pencil-Rectangle cursor over 3D world origin of axes ("Origin" appears over point)

3.) 'Left-Click-Hold' Pencil-Rectangle cursor on point at 3D world origin of axes

.....a.) Drag cursor diagonally towards top-right of Sketchup workspace (rectangle appears / re-sizes as cursor is dragged)

.....b.) Drag cursor to draw a small Rectangle of 'any' size; release mouse button... then:

..........(1.) Immediately type without quotes: "667.8m,628.8m"; press "Enter" (size enters into Sketchup 'VCB' / Measurements box)


NOTE: Rectangle "Face" drawn on 'ground' in Sketchup's workspace is now ready to be 'pinned' with an imported "image"


1.) Sketchup Menu > Tools > Select ("Select" tool is the 'Arrow' mouse cursor)

2.) Sketchup Menu > File > Import (browse dialog opens)

.....a.) Below 'Preview' (under grayed-out "Options" button) set Use As Image: {"Ticked"}

.....b.) Set Files of Type: "All Supported Image Types"

.....c.) Select and 'double-click' [file name] of image file exported as described above (display pauses while processing import)

3.) Back in main Sketchup workspace, imported image is displayed at "arrow" cursor tip

.....a.) Left-Click arrow cursor on point at 3D world origin of axes ('Imported' image "Pins" to Rectangle bottom left corner)

.....b.) Move arrow cursor from that 3D world origin point diagonally towards top-right of Sketchup workspace (image appears / re-sizes)

.....c.) Align arrow cursor over Rectangle top-right corner; when "Endpoint" appears, 'click' that point


NOTE: "Imported" image is now properly 'Pinned' to Rectangle face as a background for drawing in Sketchup !

The example "Orthographic / WGS84 / Meters" background image 'shape' appears in Sketchup with minimal "projectional distortion", and looks similar to that seen when one Geo-locates a downloaded tile of Google Earth imagery onto the 'ground' as a background image.



FYI: I have yet to test making ex: a very long RWY to see if there is a mis-alignment of the modeled object end distant (ex: 500 Meters) to the Reference Point at the 3D world origin of axes after processed via ModelConverterX.

And I also have yet to test ex: "Flat Plane / WGS84 / Meters" to implement background images in Sketchup, as well as making a very long RWY with those settings... to see if there is a mis-alignment of the modeled object end distant (ex: 500 Meters) to the Reference Point at the 3D world origin of axes after processed via ModelConverterX.


BTW: AFAIK, Global Mapper 12 does NOT offer a "Flat Earth" projection, but does offer "Gnomonic", "State Plane Coordinate System", and "Stereographic" as possible true azimuthal vertical perspective projections to be tested in relation to the information cited above regarding how Google Earth Imagery may be 'projected' when 'imported' into Sketchup.

http://en.wikipedia.org/wiki/Google_Earth#Imagery_and_coordination


[EDITED]

However, based on available information thus far reviewed, IMHO it is still unclear whether there may be additional issues involved with establishing the best choice of a projection to use in Global Mapper for export of imagery that will yield precise results when used as a background image for modeling in Sketchup and GMAX / 3DSMAX:

http://globalmapperforum.com/forums/projection-questions/4612-flat-earth-projection-conversion.html


"Autodesk 3ds Max Help > Exporting OpenFlight (FLT) Files > Application menu Export [Files of type]=OpenFlight (*.FLT)

Real World Location group

Projection

This drop-down list chooses the cartographic projection of the coordinate system. You can choose from Flat Earth, Trapezoidal, Round Earth, Lambert Conic, UTM, Geocentric, and Geodetic projection methods. Default = Flat Earth."


http://docs.autodesk.com/3DSMAX/13/ENU/Autodesk 3ds Max 2011 Help/index.html?url=./files/WS73099cc142f48755558158a8119d88fb23c-63ed.htm,topicNumber=d0e424801



"Flat Earth (Cartesian) coordinate transformations can also be made. Set −N and remember that azimuth is clockwise from North (the y axis), NOT the usual Cartesian theta, which is counterclockwise from the x axis. azimuth = 90 - theta.

...and:

"Flat Earth. Make a Cartesian coordinate transformation in the plane. [Default uses spherical trigonometry.]"

http://gmt.soest.hawaii.edu/gmt/html/man/project.html


"In order to work well with the existing commercial APIs, many users who create data designed for use within Google Maps will also use this projection. One prime example is OpenStreetMap, whose raster map tiles are all projected into the ‘spherical mercator’ projection."

http://docs.openlayers.org/library/spherical_mercator.html



Thus, I must respectfully request that we proceed further to more clearly identify what Projection / Datum / Units FS Developers should use with commonly-available GIS software to format aerial imagery for export to a file type they intend to use as a background image for modeling in Sketchup and GMAX / 3DSMAX.


"Flat Earth" is apparently a very general categorical description that seems not to be a named choice in pick lists for GIS apps that I have encountered thus far.


Could we please define more precisely what is meant by this... using more 'current' or 'mainstream' GIS app terms for projection types ?


If we model using a background image properly projected with such a "most compatible" projection type, at what distance in meters from a model's 3D world origin Reference Point can we really expect to achieve predictable placement results ?


Does this mean we really should not expect to be able to model larger / longer objects, or multiple object scenes with objects located at various distances from the 3D world origin... thereby making it impractical to model neighborhoods, cites, or other sites from extruded "footprint" data sets etc. ?


I'd hate to have to manually center every 3D scenery object model, export as *.DAE / *.KML, import to MCX, tweak individually, verify placement via an online map or imagery viewer / create a XML-placement BGL, add to a scenery object library then create that scenery object library BGL!

[END_EDIT]


I hope others here may also be willing to perform some tests with a comparable work-flow, to see if this process either eliminates or produces any continued / different 'mis-alignment'... when ex: "Orthographic / WGS84 / Meters" is used instead of "Flat Earth / WGS84 / Meters" to implement background images in Sketchup and GMAX / 3DSMAX.


Hope this helps !


GaryGB

 

[GaryGB]

[EDITED]

ADDENDUM: [For my post immediately above]:

http://www.fsdeveloper.com/forum/showpost.php?p=244811&postcount=63


If Sketchup does a CTD when attempting to import a "larger" background image, one might wish to set the "LARGE_ADDRESS_AWARE" flag in Sketchup.exe for one's 32-bit or 64-bit windows OS platform.


I've been adding a LARGE_ADDRESS_AWARE flag to 32-bit executables of FS development tools such as SBuilderX, Sketchup, Global Mapper etc. for use on my Windows XP Pro 32-bit 4GB RAM computer system which has the "/3GB switch" and "USERVA" of 2560 set up in my Boot.ini file as discussed here (...for FS, but the process is similar for other 32-bit *.exe's):

http://forum.simflight.com/topic/55994-


Thus far in months of operation, I've seen no problems with having edited the *.exe files in this manner; I anticipate that I might at least get the benefit of better stability, and 'possibly' the windfall of more working memory address space by doing this.


NOTE: There is a much simpler process to set a LARGE_ADDRESS_AWARE flag in 32-bit executables for systems using 64-bit Windows with, IIUC, 4GB or greater RAM capacity which enables use of up to 4GB per 32-bit task session... by the same author of the "Explorer Suite" NTCore editing utility:

http://www.ntcore.com/4gb_patch.php

[END_EDIT]



PS: And now for some content... mapped in a "Comedy Relief" projection !


"In 1989 and 1990, after some internal debate, seven North American geographic organizations adopted the following resolution,[18][29] which rejected all rectangular world maps, a category that includes both the Mercator and the Gall–Peters projections:

WHEREAS, the earth is round with a coordinate system composed entirely of circles, and

WHEREAS, flat world maps are more useful than globe maps, but flattening the globe surface necessarily greatly changes the appearance of Earth's features and coordinate systems, and

WHEREAS, world maps have a powerful and lasting effect on people's impressions of the shapes and sizes of lands and seas, their arrangement, and the nature of the coordinate system, and

WHEREAS, frequently seeing a greatly distorted map tends to make it "look right,"

THEREFORE, we strongly urge book and map publishers, the media and government agencies to cease using rectangular world maps for general purposes or artistic displays. Such maps promote serious, erroneous conceptions by severely distorting large sections of the world, by showing the round Earth as having straight edges and sharp corners, by representing most distances and direct routes incorrectly, and by portraying the circular coordinate system as a squared grid. The most widely displayed rectangular world map is the Mercator (in fact a navigational diagram devised for nautical charts), but other rectangular world maps proposed as replacements for the Mercator also display a greatly distorted image of the spherical Earth."

http://en.wikipedia.org/wiki/Gall–Peters_projection#cite_note-ACA1986-4


GaryGB

 

[GaryGB]

This Just In:

Yet another presumably authoritative (but older) source says:

Spatial references, coordinate systems, projections, datums, ellipsoids – confusing?

by Morten 5. May 2007 21:44

"Mercator is the type of projection you see used on Live maps and Google maps, but as many often mistakenly thinks, they do NOT use WGS84 for the projected map, although WGS84 is used when you directly input longitude/latitude values using their API.

http://www.sharpgis.net/post/2007/0...s2c-datums2c-ellipsoids-e28093-confusing.aspx


...Also See:


"The Microsoft Live Maps and Google Maps Projection

by Morten 27. July 2007 05:06

I have lately seen several blogposts confused about which datum and projection Microsoft’s Live Maps (Virtual Earth) and Google Maps use. As most people already know by now, they render the round earth onto a flat screen using a Mercator projection.

I think the confusion comes from that they actually use two spatial reference systems at the same time:

1. Geographic Longitude/Latitude coordinatesystem based on the standard WGS84 datum.
2. Mercator projection using a datum based on WGS84, BUT modified to be spheric.

So when is what used?

The JavaScript API’s use (1) as input when you want to add points, lines and polygons. That is, they expect you to input any geometry in geographical coordinates, and click events etc. will also return geometry in this spatial reference. This is the coordinate system most JavaScript developers will use. The API will automatically project it to the spheric Mercator projection.

If you want to create image overlays, or roll your own tile server on top of the map, you will need to project your images into a spheric Mercator projection. The JavaScript APIs are not able to do this for you."

http://www.sharpgis.net/post/2007/07/27/The-Microsoft-Live-Maps-and-Google-Maps-projection.aspx


...And:


"Spherical/Web Mercator: EPSG code 3785

by Morten 15. May 2008 17:11

I just received an update from the EPSG mailing list:

New to Version 6.15 are (among other things): Added spherical Mercator coordinate operation method and associated CRS as seen in popular web mapping and visualization applications.

It looks like they FINALLY added the spherical Mercator / Web Mercator projection used in Virtual Earth and Google Maps.

This is a big surprise. EPSG’s earlier statement whether to include it was this:

"We have reviewed the coordinate reference system used by Microsoft, Google, etc. and believe that it is technically flawed. We will not devalue the EPSG data set by including such inappropriate geodesy and cartography.”

Guess they changed their mind, or did they just devalue their data set? Then again, judging from the remarks EPSG put in there, their arrogance still shines through. There´s absolute nothing wrong with using a sphere instead of a flattened sphere. Sure it's not as accurate as for instance WGS84, but then again WGS84 is not accurate either - no ellipsoid is. But we know the exact differences between the two, and as always you will need to take these things into account so I don´t see the real issue. Visually the distortion is far less than what you would notice, and when doing area, distance and bearing calculations you would first of all never use the Mercator units without taking the projection distortion into account, and if you do your calculations in long/lat it's more or less just as easy to use WGS84 as a base for your calculations (since no datum transform is really needed)."

http://www.sharpgis.net/post/2008/05/15/SphericalWeb-Mercator-EPSG-code-3785.aspx



< Ahem > ...Global Mapper also doesn't (as of this date) offer a "Spherical Mercator" projection.



Would someone please be so kind as to lend a hand here, so we can properly sort out this subject ?


PS: I noted from a page "source" code view that Arno is tracking this thread via a "MyStatus.Skype.com" beacon, but it keeps crashing my FireFox browser while I am attempting to work in the "Post Reply" editor mode.


Is there a problem with the JavaScript coding of that particular extension when added to this web forum software ?


Thanks in advance for some help tackling these issues !

GaryGB

 

[arno]

Hi Gary,

Would someone please be so kind as to lend a hand here, so we can properly sort out this subject ?

Humm, to be honest I am a bit confused by the overload of information you have been throwing into this thread. What do you want to sort out?

I think it is quite clear now what coordinate systems FS2004 and FSX are using when rendering your models in the world.

For your "input" source data you are most likely to find thousands of different projections and coordinate systems being used. Some might be UTM, or a specific national projection or LCC or ..... I see Google Maps, Bing, etc also as just inputs. So whenever you use data from a specific source you need to know what the coordinate system is that it uses. After that GIS software should be able to convert it to what FS needs. But like with resample, it will come down to reproject it to WGS4 geodetic (lat/long).

What more is there to figure out?

PS: I noted from a page "source" code view that Arno is tracking this thread via a "MyStatus.Skype.com" beacon, but it keeps crashing my FireFox browser while I am attempting to work in the "Post Reply" editor mode.

Might be the Skype icon we have in the postbit. But I think that is standard forum functionality.

 

[preynolds]

You guys lost me about 10 posts ago .....all I want is my effects to line up!!

Phil

 

[GaryGB]

Hi Arno:

Thanks for your reply, and I'm sorry for not explaining better the basis for some of the info I had posted above; and thanks as well, for so courteously replying to what eventually became "sub-topic" content submitted on my part.


I believe at least some of the info I had cited above will ultimately prove to be an important consideration for the modeling process within both GMAX / 3DSMAX and/or Sketchup... and to subsequent issues with placement of both models and their "attached" effects.


However, due to the complexity involved in that "sub-topic" material < and my limited energy as I continue to recover from a transient viral illness that has kept me from being at my best for the last week or so >, I must say that it is probably best to address this issue later via a separate dedicated thread... so that the message I meant to convey can be more clearly communicated.



Please be assured that I sincerely appreciate your generous ongoing efforts with expanding the feature set of ModelConverterX, and admire the way you have been able to so quickly implement changes for working around numerous challenges to productivity that FS Developers incur from both the requirements of- and shortcomings in- the FS SDK; I'm confident that we will see even more enhancements in MCX in the future.


When I get some more time and energy, I will likely edit my posts here to remove and/or restructure some of my voluminous content, particularly that which I had posted into this thread, so as to avoid digression of readers and thread participants from the important main topic of... solving FS Effect misplacement issues which had impacted "preynolds" and "littleMax" with their current projects involving, IIUC, Effects attached over the expanse of longer airport object spans... with the result being that Effect AttachPoint distances offset substantially from a central model RefPoint became "visibly problematic" when rendered at run time in FS .


However related I had personally felt the info I posted might prove to be at the time you seemed to be reconsidering some of your programming for MCX, I must acknowledge that, given the challenges I've been coping with this week or so, it is apparent such info just was not presented by me... in a manner conducive to having its relevance understood by you or others participating in this thread.


And since there are additional pertinent details which, IMHO, need to also be presented in conjunction with the info I had already endeavored to bring to light within the context of this thread, I now see that it really would be best to defer taking up discussion of the "sub-topic" which had concerned me.

I'll do so hopefully in the near future... elsewhere, in another thread, when I have more time and energy available to give the matter the undivided attention which I believe it deserves.


I hope at that time you may be inclined to consider the ideas I present, and offer feedback based on your considerable insight with all matters involving FS.


In the mean time, I do hope that your most recent modifications to MCX will prove to have satisfactorily met the immediate needs of Phil and "littleMax"; I hope that my interjected "subtopic" did not cause too much initial consternation or prevent them from completely solving the problems they experienced by using Effects via 'AttachPoints' ...rather than via direct XML placement.



PS: One of the browsers I use at FSDeveloper apparently does NOT crash when I edit posts, so perhaps I may have a malfunctioning FireFox add-on; I'll follow-up to advise you of anything else I can consistently trace the crashes to.


Regards,

GaryGB

 

[GaryGB]

You guys lost me about 10 posts ago .....all I want is my effects to line up!!

Phil

Hi Phil:

Sorry for my digression(s) above into a (IMHO) "related sub-topic".


Please tell us whether you have- or have not- yet achieved a satisfactory resolution of your "attached" Effects mis-placement issues via use of Arno's recent mods to the MCX feature set?


GaryGB

 

[preynolds]

Hi Gary,

Hi Phil:

Sorry for my digression(s) above into a (IMHO) "related sub-topic".

No problem, it's good that threads evolve...

Please tell us whether you have- or have not- yet achieved a satisfactory resolution of your "attached" Effects mis-placement issues via use of Arno's recent mods to the MCX feature set?

GaryGB

No, I just re-checked with the latest development build and the effect position still doesn't line up. Arno has copies of the mdl I was working on - I don't think he's posted any updates since then.

Cheers

Phil

 

[littleMax]

Arg.. i also thought: Lets check back if arno finished of the last edges of the replacement thing for the attachpoints.

And now i see all this (maybe) offtopic stuff by Gary.
Dont get me wrong gary, cause all this maybe full of information that is usefull, but in the end i think it is to far away from the topic.

So maybe somebody splitt this thread and sort it in "Effects in wrong place" and "object placement - projection" (??)

The questions that stays:
Arno, did you put an eye on the last tweaks for the correction tool?

referring to this post:

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.

 

[GaryGB]

So maybe somebody split this thread and sort it in "Effects in wrong place" and "object placement - projection" (??)

Hello:

I shall implement some edits to my latter posts here which will split off sub-topic content into a new thread in the near future.



Now I have a question for both Phil and "littleMax"


...May I please inquire:

• What is the distance from the 3D world central Reference Point in GMAX / 3DSMAX at which your respective lines of Effects begin to show "visible" offsets from where they are intended to appear ?

...and:

• What Projection and Datum did you use for your background images in GMAX / 3DSMAX while drawing your respective models which have these Effect mis-placements ?

NOTE: This subject was addressed by Arno and me in this thread, as well as by others in this thread here:

http://www.fsdeveloper.com/forum/showpost.php?p=236073&postcount=32



Thanks in advance for your replies to these questions !

GaryGB

 

[preynolds]

• What is the distance from the 3D world central Reference Point in GMAX / 3DSMAX at which your respective lines of Effects begin to show "visible" offsets from where they are intended to appear ?

The one shown in my example screenshots was approximately 20m away. The offset isn't huge, but is very noticable to the end user when viewed in FSX - in my opinion. All effects are visibly offset to a certain degree (unless placed exactly at the refpoint) I guess it's subjective on whether you think an amount of error is acceptable or not ( unfortunately I'm a bit of a perfectionist )

• What Projection and Datum did you use for your background images in GMAX / 3DSMAX while drawing your respective models which have these Effect mis-placements ?

I'm not sure that has any relevance, as the issue is not about the position of the model on the underlying ground, it's only about the positioning of the effect relative to the 3D model in the MDL

Phil

 

[arno]

Hi Phil,

No, I just re-checked with the latest development build and the effect position still doesn't line up. Arno has copies of the mdl I was working on - I don't think he's posted any updates since then.

I still need to do some more research on this. I tried it with one of my own effects and after the correction it looks OK. But from a distance it seems the effects always get an offset.

Also your object is quite close to the origin, so the offset it not that big at all.

 

[arno]

I'm not sure that has any relevance, as the issue is not about the position of the model on the underlying ground, it's only about the positioning of the effect relative to the 3D model in the MDL

In the end the offset of an effect or an MDL object is all caused by the same things. It is understanding what FS uses to render to world and thus how you need to adjust your reference material to that.