Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:
Tag FS2020 specific questions with the MSFS2020 tag.
Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
Questions about aircraft design can be posted in the Aircraft design forum
Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
Questions about SimConnect can be posted in the SimConnect forum.
Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.
By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.
I have questions concerning "LOD" as it relates to FSX, P3D and MSFS2020. I have made several steam locomotives for Trainz RR simulator and for their simulator you make 3 models of the same engine, each with less detail for "far away" exterior shots. Closeups would have ALL details of the engines, (levers, knobs, ropes, rivets...), a medium distance would have details you cannot see at (say) 100 yards, and lastly anything greater than (say) 150 yards would be the basic engine with absolute minimal details. As you move the exterior view closer to the engine, the details will appear until you see every detail while standing next to it. This procedure is also used for buildings, trees, RR cars, automobiles, literally everything in the sim that would require it. The way Trainz does LOD makes sense and prevents the CPU from generating details that would never be seen from a distance and more CPU power is dedicated to what you can "see".
Does FSX, P3D or MSFS2020 use the same techniques? If so, I have not found any reference to it nor any instructions for it. For FSX / P3D LOD, I've found (example) videos where a firetruck with LOTS of detail was reduced down to minimum polys since it didn't need that level of detail for the scenery, but once the LOD was reduced, that's the way it stayed. From a distance that's ok, but parked next to it would be disappointing.
I have used ModelConverterX to convert P3D aircraft to be used in Blender, and in a lot of cases there is an enormous amount of detailing in each model! I would venture to say that even items that cannot be seen are detailed! This (obviously) would require more computing power to generate, (so why do it?).
I have made several hangars with "actual" corrugated metal sides that look great when parked next to. However, at a distance the vertical lines of the corrugated metal do not transition well and look psychedelic until you get close to them, or if the sun changes position they look psychedelic. If P3D uses LOD like Trainz, it would be (relatively) easy to make hangars, or fire engines, with less detail for distance shots.
So if I read this correctly, you CAN modify the model so the LOD changes as you get closer or further away from the model! Why have I have not seen this done on any of the tutorials I've tuned in to? It would certainly help in my case as my hangars are very detailed (inside and out!) and they do not display properly at a distance. By using Blender to set my LOD's, I can also remove objects from my model as the LOD changes.
ALSO, how do I know what the DISTANCE in P3D is between LOD's? I need it to change relatively quickly, (say 50 yards out, 100 yards out...) Is there a way to do that? I've been experimenting and don't see any difference even when the LOD is set to ridiculous and I back away from the airport using slew. (I'm at least a mile away and zooming in to the aircraft with the hangar in the foreground.) Absolutely no change to the hangar. When I use the LOD creator, does it automatically save the LOD in the model when I export scenery? Or am I missing another step?
The latter questions immediately above would likely be best answered by Arno.
Generally speaking, object size on screen determines a LOD switching- (and associated mapped texture image Material MIPMAP changing-) threshold.
The rendered size on screen in units of texture pixel (aka "texel") dimensions as actually mapped ...is a function of user camera distance from 3D objects.
[EDITED]
FYI: How run time LOD / MIPMAP switching is based on the mapped texture Material "Pixels per Meter":
There is a lot that merits consideration regarding texture image 'pixel dimensions' when mapped onto 3D models.
As Arno alluded to above, run time LOD / MIPMAP switching is based on the mapped texture Material "Pixels per Meter" when measured horizontally in the graphic image being displayed on the monitor screen, although the actual FS run time 3D MDL object 'visual' display radius' distance can be tweaked by several methods.
Arno describes how MCX computes 3D model LOD / MIPMAP switching based on object size / pixel extent ...here:
The run time physical dimensions of a 3D model 'Face' onto which an image (nested within other images on a Texture Atlas / Sheet) is mapped, will determine the actual mapped texture Material display resolution in "Pixels per Meter" more-so than the overall dimensions of all images (and the 'empty' spaces between them) on a ex: 1-piece Texture Atlas / Sheet.
This sets "Pixel Dimensions" in a way comparable to mapping texture images for FS SDK Resample custom photo-real terrain.
The distance between adjacent mapped Texture Pixels (aka "Texels") in an area ...may also be referred to as "Texel Density".
In a 3D modeling application we work with Cartesian Coordinates; with SDK Resample we work with Geographic coordinates.
"QMID (Quad Mesh Identifier) values are an internal system used to optimize the textures required to represent the Earth, depending on the altitude the aircraft is flying at."
AFAIK, "the altitude the aircraft is flying at" is a 'visual display radius' from user aircraft camera to Z-sorted terrain / 3D objects.
Another practical consideration is the FS run time 3D MDL object 'visual' display radius' distance, which although it can be tweaked, will only show higher LODs at closer physical distances between a user aircraft and the 3D model, ex:
As stated by Richard Ludowise (aka "rhumbaflappy"):
"The radius of the LOD20 wouldn't even extend beyond the nose of a large jet... you would never see it from the cockpit !".
"The terrain grid system is radial around the current viewpoint, and, depending on level of detail, radius can be up to 4.5 tiles in either direction, something like 64 tiles. So there is plenty of work to go around. Autogen is more constant, with a 2 km extent being batched."
AFAIK, "with a 2 km extent being batched" means that "Batched" Materials mapped onto 3D models placed as Autogen objects, may 'effectively' result in their being rendered at run time with a texture resolution expressed as Pixels per Meter.
Yet Z-sorted 3D objects with transparency may require multiple "DrawCalls", according to ACES' Adrian Woods (aka "Torgo3000"):
AFAIK, 3D models with "Batched" Materials placed as Autogen are still dynamically switched between LODs / MIPMAPs as a function of visual display radius from user aircraft camera to each Z-sorted 3D object ...just as occurs with terrain objects.
IIUC, for optimal performance in FS at run time when rendering 3D objects placed by BGLComp and/or Autogen annotation, minimal numbers of "batchedDrawCalls" are required, and involves images mapped onto 3D models at UVW coordinates from 1 or more Texture Sheet / Atlas.
Reportedly, LM-P3D now refuses to render Autogen 3D objects unless they are compiled using "Draw Call Batching".
But, IIRC, MS-FS 3D library objects placed as Autogen have always had the 'option' to use minimal numbers of "batchedDrawCalls" from (1) ormore Texture Sheet / Atlas.
However, default FS library objects only have (1) such Texture Sheet / Atlas) UVW mapped onto 3D model 'T-verts':
Also, a wiki here at FSDeveloper discusses the considerations which apply to the factors cited above when 3D modeling:
Modeling and texturing for optimal performance
"For the usage of textures the basic rule is to choose the right resolution for the object you are making and to use a similar resolution on all parts of your object. "
When 3D modeling in Sketchup, one normally is prompted during creation of a new Material, to declare the intended "Real World" size as an "Area" (based on height and width) at which the texture image is to be displayed,
It is easy to overlook this consideration in Sketchup if directly importing a texture image source to be mapped onto a Face.
One 'can' just drag an image across a Face to size it 'closer' to the intended Face size of a desired 'part' within the image.
But... those wanting to be more precise with 3D modeling in Sketchup may wish to use the default Material dialogs to set the intended "Real World" size at which the mapped texture image 'Material' is to be displayed in FS.
Also, a Ruby plugin script "Goldilocks" by Adam Billyard may prove useful in analyzing the texture pixel (aka "Texel") density and relative complexity of a 3D model:
One can then make them 'unique' for the mapped Face, 'combine them for adjacent coplanar Faces, and resize the combined mapped texture image to the desired resolution / Texel density for the finished 3D model at an 'assigned' resolution using a Ruby plugin script "Make Unique Texture++" by Aerilius:
PS: For those wanting to minimize the "cartoonish" or "legacy era" appearance due to a lack of dynamic range in color depth seen in many X-Plane scenery objects, one might wish to use 24 or 32 bit *.DDS textures for final output from ex: MCX ...instead of*.PNG textures which, although non-lossy like LZW compressed TIFFS for overall image storage, *.PNGs do have an inherently lesser bit depth and dynamic range of color fidelity.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
